分析清單:測量和尋找哪些方面

當你發(fā)布一個應用程序或更新時，你經(jīng)常希望獲得新用戶和/或更多的收益。 Google Play Developer Console一直為你追蹤這些指標，但無論你是看到你喜歡的數(shù)字還是不喜歡的數(shù)字，但是你仍然不知道是什么驅(qū)使的他們。

Analytics，一般情況下，我使用它收集使用和錯誤數(shù)據(jù)，它能幫助你了解痛點和你的應用程序的用戶，讓您專注于清除障礙和更好地服務(wù)于用戶的需求。反過來，這也會提高用戶滿意度，產(chǎn)生更高的使用率和新用戶，以及每個用戶的更高收入。

特別是，Google Analytics配備了一個Android SDK，網(wǎng)絡(luò)接口已經(jīng)被許多企業(yè)用戶所熟知，使它成為一個實現(xiàn)分析策略的強大工具。在Android開發(fā)者網(wǎng)站上有一節(jié)專門講述了它的特點。這是一款非常強大的工具，它可以給你關(guān)于你的用戶的“開箱即用的”數(shù)據(jù)。讓我們先暫時撇開實施細節(jié)，先關(guān)注如何衡量和尋找……

識別功能問題

• 崩潰——如果你沒有存在這個問題，定期在Google Play Developer Console上檢查異常和ANRS報告。

• 捕捉異常——有一些異常是預期要發(fā)生的，但是你應該了解它們，因為可能會在你的應用程序中顯示一個潛在的問題。

• 服務(wù)器通信——對于提供一個快速，平穩(wěn)，高效的應用程序，背景同步是至關(guān)重要的。你調(diào)用服務(wù)器需要多久呢？你的調(diào)用以IO 異常結(jié)束或響應時間超過10秒的情況占多數(shù)比例呢？你的用戶在使用WiFi，4G，3G和2G的比例有多大呢？關(guān)系到本地緩存和服務(wù)器同步發(fā)生具體異常（例如SQLExceptions）的頻率有多少呢？

• 定位、定位、定位——對于你捕捉到的異常，他們是否是特別針對對于一個給定的時區(qū)和語言而發(fā)生？Android是當今世界上最流行的移動平臺，所以你不能假設(shè)你的用戶生活都處在你所在的國家，說著你所說的語言。

• 搜索——用戶是根據(jù)你所期望的方式搜索嗎？在他們查詢過程中，他們做出錯誤的拼寫時，適當?shù)慕ㄗh可以減少錯誤拼寫嗎？

識別UI問題

至少，你應該追蹤你的用戶的交互活動，他們在每個畫面花費多長時間，以及每個活動之間的流程，以確定以下問題。

• 畫面UI層次結(jié)構(gòu)——你ActionBar真的需要這些圖標嗎？你是否應該或高或低地移動屏幕上的一個按鈕（特別是需要較長滾動的屏幕）？

• UX流程——如果很多用戶需要經(jīng)過屏幕A -> B -> C -> D，是否需要為他們設(shè)定一個A -> D的屏幕過渡方式？此外，你可以考慮具體的追蹤來幫助你發(fā)現(xiàn)潛在的問題。

• 慢畫面初始化——你在onCreate中加載的一些數(shù)據(jù)，是否應移出主線程？

• 滾動——如果你有很長的屏幕，你知道你的用戶需要滾動多少嗎？你為你的用戶設(shè)計的數(shù)據(jù)加載速度夠快嗎？

理解你的用戶

收集了解UI問題的數(shù)據(jù)也將幫助你了解你的用戶。

• 未發(fā)現(xiàn)的功能——你可以通過著眼于結(jié)合用戶評論和點擊數(shù)據(jù)實現(xiàn)評估用戶未發(fā)現(xiàn)的功能。

• 未使用的功能——你可以通過著眼于結(jié)合點擊數(shù)據(jù)和一個特定的畫面時間實現(xiàn)評估未使用的功能。

下一步，根據(jù)基本的理解通過分組劃分用戶段，例如重度使用者，中度使用者和罕見的用戶。對于每一段，你需要自問的基本問題是：

• 你的用戶使用該應用程序有多頻繁？

• 他們在哪里花費了時間？

• 最常見的界面流程是什么？

• 是否有某些功能未被發(fā)現(xiàn)？

• 是否有某些功能未被使用？

• 您的用戶如何與你的推送通知互動？

核心原則是為你的用戶創(chuàng)建一個豐富、有意義的體驗，在正確的時間提供正確的信息。一旦你了解了你的用戶，你可以考慮圍繞廣告、內(nèi)容和個性化方面設(shè)計有針對性的策略。例如，你可以：

• 專注于某一段和你的應用程序廣告等。

• 當進行了某些特定的行為時，在你的主屏幕上提供上下文幫助，這是游戲在玩家低等級時經(jīng)常采用的策略。

• 個性化你的主屏幕，例如，通過根據(jù)用戶類型適應不同截面的位置。

在應用程序中創(chuàng)建和維護強大分析的技巧

• 寫下你的假設(shè)——用你的詳細的路線圖，史詩或簡單的長期目標以呈現(xiàn)你對你的用戶的假設(shè)。

• 為每個假設(shè)分配風險——你的依賴于這一假設(shè)的長期目標中有多少是真實存在的？

• 考慮你如何能確定每個假設(shè)的有效性——開始于你的最危險的假設(shè)，考慮從你的應用程序中收集的數(shù)據(jù)以幫助你確定或消除每個假設(shè)

• 從現(xiàn)在開始，設(shè)身處地為你自己考慮六個月——想象一下，到那時，你的應用程序是完全無bug，有足夠的用戶來證明你的投資將產(chǎn)生一輪又一輪的大發(fā)展。你的各種選項是什么？你需要知道哪一個是最好的？

• 部分功能的實現(xiàn)分析——由于太容易對功能急于求成，而忘記分析。然而，你怎么才能衡量你的新功能的影響？

• 重復你的分析——當你獲得對當前用戶的相關(guān)認知后，毫無疑問你會問自己很多關(guān)于他們的問題。就像你重復使用你的應用程序，同時重復你的分析。

用戶的隱私數(shù)據(jù)

是的，收集數(shù)據(jù)是為了更好地服務(wù)于你的用戶，但不要忘記你的用戶的隱私，所以匿名化你收集到的數(shù)據(jù)。特別是，請確保你遵守開發(fā)者分發(fā)協(xié)議的第4.3節(jié)。

一些數(shù)據(jù)，如用戶的位置是特別敏感的，所以你可能想把你的數(shù)據(jù)集分成兩組。第一組不需要用戶的同意就可以收集，它將使用匿名的IP，并且是一般的事物信息，如一般用戶細分、點擊事件和屏幕。第二組需要用戶的同意，它不使用匿名的IPs，并且可能包括諸如用戶位置等信息。

實施建議

• 定義一個接口——為了獲得最大的靈活性，為你的分析方法創(chuàng)建一個接口，一個一般的實現(xiàn)類（從你的代碼中調(diào)用），一個實現(xiàn)類用于你所選擇使用的提供程序。通過這種方式，你應該決定改變分析提供程序，你可以簡單地為新的提供程序添加一個實現(xiàn)類，并改變你的一般實現(xiàn)類的代碼用于替代這個提供程序。

• 為屏幕和事件定義枚舉——每個枚舉分別為畫面或事件發(fā)送完整的數(shù)據(jù)到分析服務(wù)，使你的應用程序中的分析代碼非常簡潔和易于維護。

• 開發(fā)設(shè)置——分析也需要被測試，所以，為你的開發(fā)構(gòu)建使用不同的分析ID。你一旦在你的應用程序中完成分析，確保你的業(yè)務(wù)團隊能夠訪問開發(fā)分析數(shù)據(jù)，以確保他們能理解它。

• A/B測試——完成這項測試的一種方式是在毫秒系統(tǒng)中對當前時間使用模數(shù)函數(shù)，以確定用戶測試組ID，然后將它保存在一個共享的首選字段里。這應該在你的應用程序類onCreate方法中完成，僅進行一次。例如，如果你要發(fā)送90％的用戶到ID1的組和10％的用戶到ID2組，你會如下編寫代碼：

int userTestingGroupId = System.currentTimeMillis()%10 != 0? 1:2;

請記得

• 親自做可用性測試——這可以通過你的應用程序的一個原型完成。親自進行可用性測試是你的第一個調(diào)用端口，用以識別UI問題。

• 做手工和自動化測試——應用程序測試是你的第一個調(diào)用端口，用于識別函數(shù)問題。

• 在Google Play Developer Console上使用 α/β發(fā)行渠道——在你的所有用戶體驗它們之前，最好能捕捉功能和UI問題。你可能會考慮分割你的alpha/beta渠道以匹配特定的用戶細分，例如只有重度使用者可以成為alpha測試者，只有中度使用者可以成為beta測試者。