起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識獲獎作品｜騰訊移動分析MTA產品評測：我的數據驅動實戰分析
本文作者將在此與大家分享其對MTA進行的產品評測，以及結合自身運營經驗講述他的數據驅動實踐分析。enjoy~
隨著移動互聯網下半場的到來，產品運營日趨精細化，類似增長黑客、數據驅動的意識越來越深入到每一個互聯網人的心中。與此同時，為了滿足我們數據驅動的訴求，移動統計平臺也越來越多，擺在我們面前的是兩個主要問題：
- 如何辨別和選取一個好平臺？
- 是自建平臺還是接入第三方？
筆者有幸在負責運營的過程中，接入并體驗過多個數據平臺，最終我們還是選擇了騰訊移動分析MTA和自建平臺相結合的方式。這篇文章我將帶著這兩個問題來進行MTA的評測并講述我的數據驅動實踐分析。
一. MTA是否稱得上好平臺？
個人認為一個好的平臺應該是要做好下面4個方面：
- 數據定義明確，且能針對各個類型的應用進行特殊化處理；
- 數據采集的實時性、準確性、穩定性和個性化；
- 數據維度足夠廣；
- 數據深度足夠深。
那么，MTA在這4個方面體驗又如何呢？具體說一下我的感受：
1. 數據定義方面
數據定義是一個很容易被使用者忽略的問題，但是卻是一個很關鍵的問題。你不妨反問自己一句，什么是活躍用戶？如果讓你來定義，你會如何定義？
剛剛接觸的時候，我覺得只要打開過APP的用戶就算是活躍用戶。事實遠比我最初想的要復雜，我們可以看到MTA的在這一塊做的還是很細致的。
主要表現在兩個方面：
（1）定義非常細致和詳細；
（2）支持自定義日志活躍。
圖1
圖2
如上圖，活躍的定義就涉及到7種不同的日志類型，而大多數被理解的活躍往往只是7種中的1種——頁面瀏覽日志。也正是因為定義涉及的細節很多，所以我們需要明確的定義和自定義的活躍方式，而很多平臺的定義不細致，至少沒有給出。
總的來說，定義明確且細致解決的隱藏痛點在于：
- 若平臺之間存在活躍數據差異，我們至少能明確可能是哪里存在匯報不一致、統計口徑不一致等問題；
- 如果你的應用存在非應用內觸發的功能，你可以知道并定義它是否應會為活躍。比如WiFi萬能鑰匙只需要有人在用它的功能并不一定需要打開頁面就可以算為活躍，類似這樣的場景和技術處理有很多；
- 加強我們對數據擁有更強的把控力。類似活躍這種基礎數據了解不清楚會直接影響多維度的數據（如留存、人均時長等的數據）的判斷。
所以，MTA在數據定義和數據個性化方面的細致成為了我選擇的原因之一。
2. 數據采集方面
（1）實時性層面
秒級的數據更新速度足以滿足開發者的需求。對應的維度支持新增、活躍、啟動次數等主要數據的更新，同時支持快捷添加看板便于開發者系統的、及時的了解到產品的動態?？偟膩碚f，速度靠譜，維度中規中矩。
圖3
（2）準確性層面
本來依托于騰訊大數據就具有一定說服力，又曾對比過其他平臺和MTA之間的用戶畫像差異，再結合主觀判斷（自身產品有微信登錄功能），明顯選擇相信MTA更接近真實值。此外騰訊作為第三方平臺，可以確保跟渠道結算激活時的公正性。
圖4（MTA）
圖5（百度統計）
（3）采集時效層面
據觀察，MTA采用的是7天內持續匯報的策略來確保數據盡可能接近真實值，即只要是7天內產生過數據的，即使是在第7天客戶端日志才上傳至MTA，也會更新數據。
為便于理解，我補充解釋一下：
用戶在1月28日使用了產品，但是因為突然發現沒流量了，然后關掉了流量，在2月1日再打開，這時候如果采用延遲匯報的策略就能確保類似的用戶數據不會被舍棄。沒準還能幫你沖一波KPI呢！
（4）穩定性層面
從筆者使用MTA的情況來看，數據還是非常穩定且保留時間非常長的。目前仍可追溯到3年以前的數據表現。這也是我們選擇MTA的另一個原因。當然若MTA能夠提供接口供開發者獲取數據，供我們保留，那更好不過。
（5）個性化層面
不得不說做的非常細致。比如：MTA可以開放給開發者選擇頁面數據匯報的權限，也就是說每個開發者可以覺得自己哪些頁面應該作為時長統計。說一個我的親身經歷：因為我們的APP中有一個頁面是在外部生成的，類似一個小彈窗，但并不能代表用戶的真實使用，且觸發頻率極高，最開始我們并未在意，最終產品上線之后才發現，原來僅僅是這個頁面產生的時長數據就導致了時長翻了5倍以上。雖然看起來是好事且拿出去給人看倍有面子，但是卻會影響你之后對時長數據的判斷和敏感度，這是作為數據運營者不能忍的。
3. 數據維度
目前MTA已有的維度從數據概覽到反作弊，覆蓋8個大的方面，對比其他平臺（如下圖），會發現MTA在數據維度上會更全面，且覆蓋的產品、運營場景更加豐富。
圖６（左1左2為MTA，左3為百度統計，左4為諸葛IO）
從分析用戶生命周期的角度來看，MTA包含的數據維度有活躍度、活躍天數、留存率、流失與回流數、使用時段、用戶構成；而百度統計僅有新用戶留存和活躍用戶留存，相比之下略顯單薄。
4. 數據深度
數據深度總體上能滿足大多數的數據分析需求。我們可以用5W1H的方法去思考：即盡可能了解到who（用戶特征）在when（時間點/時間段）在where（渠道）以how（功能）的方式做了what（用戶行為記錄），而why可能更多是產品、運營者需要考慮的，這是一條完整的鏈條。雖然4W1H的數據MTA幾乎已經全部覆蓋，但卻沒有完全串聯起來。
所以在筆者的實際運營過程中，它能幫助解決大多數需求，但少數情況仍無法解決。這時候基本要靠自建平臺獲取源數據才能解決，去在原始數據里給每一個CID（用戶）對應上各種tag和type字段，這樣就能精確定位每一類人的做了什么。這是第三方平臺目前都很難做到的，但個人認為這也是未來的一個方向。
總的來看，MTA算是市面上已有的“好平臺”，但還仍存在一些不足。除了剛剛所談論到的，下面也有筆者一些拙見：
二. 對MTA的Redesign想法和建議
1. Redesign的想法
（1）安裝來源分析
【安裝來源分析】的功能模塊目前的設計并不是太理想，存在的問題和重新設計的結果如下：
①與所選平臺類型不相符。如圖，我是安卓APP 類型，顯示的卻是PV/UV的數據。故第一個需求就針對不同平臺類型自動匹配對應的功能模塊。
圖７
②目前實時效果展示并無數據主體。個人的想法是直接重新換成如下原型展示形式：
圖８
- 所包含的維度為：訪問時間、版本、渠道、設備品牌、設備型號、聯網方式、地域、操作系統、分辨率、運營商、內存等；
- 點擊編輯按鈕可以增刪部分維度，最多展示8個維度；
- 每個維度下可以選中屬性值，支持單選或多選，如多選華為、OPPO、vivo、小米；
- 支持直接導出CSV。
如此一來，開發者可以更清晰明了地知道自己的用戶從哪里來，具有什么樣的屬性；甚至能解決刷量判斷、團隊地推效果管理等問題。
（2）數據看板
目前【數據看板】的雞肋在與：數據類型基本都有，但維度不夠自由、展示時不夠定制化。如：我想看A渠道和B渠道下的新增用戶趨勢，卻無法實現。
圖９
個人想法是：
- 維度自由定制。可以基于渠道或版本去看新增活躍等數據，也可以基于新增、活躍等數據去看渠道或版本的數據。
- 看板大小可以在更大范圍內，每次以固定的距離上下左右自由調整，以此便于各種場景展示，如匯報會議、周會等。
- 入口：在新建看板的時候設置是基于哪個維度看哪些數據。
（3）用戶屬性
目前的【用戶屬性】更加復雜，我覺得可以簡化，把屬性作為成一個基本維度。
用戶范圍可以變為非必選項，直接選擇用戶屬性、設備屬性、自定義事件等，再基于這些看其他數據。
圖10
如：用戶屬性選擇華為手機，安卓7.0以上，打開過應用的(自定義事件)；然后再基于這些屬性去看新增、活躍、留存、時長等數據。可以理解為在渠道和版本的維度上多了一個用戶群維度。
圖11
2. 測評建議
圖12
（1）【自定義事件相關1】在不需要切換頁面且不需要改變時間、渠道、版本維度的情況下，能快速更換自定義事件，查看數據。
比如：能否將紅框內的自定義事件做出一個下拉框并附帶搜索按鈕，以便于保留原選中維度的情況下快速查看其它自定義事件的數據表現。
（2）【自定義事件相關2】只要是代碼中已埋的埋點，不論何時在MTA添加，都可以查到從代碼埋點開始時的數據，以避免因產品/運營導入時漏了或缺失的情況。
（3）【自定義事件相關3】參數明細統計時可以同時多選渠道和版本，目前不每次只能選取一個渠道，疑似BUG。
圖13
（4）賬號權限管理中報表查看可以選定渠道和版本下的數據，以便跟渠道合作時用來統一校對數據。
圖14
（5）在渠道/版本的分類下也添加“全部”選中功能，點擊后可以選中該分類下的全部渠道/版本。
圖15
三. 數據分析實戰：加需求真的可以“為所欲為”
先簡單介紹一下事情的背景：
恰逢公司戰略轉型，工具類轉型內容型工具，大改版之際，老大從戰略層面的高度直接拍板，壯士斷腕，一波帶走了很多原來的功能，簡化操作弱化功能。產品上線，數據下滑，而我又只能憑直覺和用戶反饋確定其中的“浮動通知“的功能是不能砍掉的。因為涉及產品大改版，多維度的論述并證明這個功能的必要性成了必然（因涉及內部數據保密，對數據進行了相對調整，但符合原數據的推理邏輯和結果）。
在整理前，為了確保數據足夠有說服力，需整理了一下思路和細節：
前提：能確保當時該功能上線后，無其他干擾因素或該干擾因素可以忽略。
因在樣本數據的選取上，不同類型數據不同，主要的注意點如下，后續不再贅述數據細節：
- 渠道。所選取渠道應相同，若為多個渠道綜合數據，應確保渠道新增來源無較大變化。
- 時間段。所取時間段不宜過長，要減少市場變動等因素影響。不同數據對比時，需要選取的時間維度也不一樣。
- 版本。對應時間段內，所取版本必須為單一版本。
- 所有數據都來源于MTA，同平臺能確保數據的可比性。
1. 歷史留存
要了解“酷炫通知”功能的成功性，就必須追溯到該功能首次上線后的表現。
在MTA上，我們可以輕松地按時間、版本、維度選取酷炫通知功能上線前后的數據進行計算。
當時選取對應版本的應用市場全部渠道數據如下：
表1
圖16（注：圖中留存波動與2.6發布時間相同）
從圖表中我們可以很明顯地看出，最初此功能上線后留存明顯提升，30日留存提升14.05%，且進一步確認是全渠道數據同步提升以及2.6版本僅添加了酷炫通知和對機型做了兼容。
得出結論1：酷炫通知在當時能顯著提升30日留存，提升約14%。（對新增也有一定刺激作用，此處不做討論）
2. 歷史使用程度（自定義事件，需埋點）
接下來通過對此功能被砍掉之前的使用度進行分析，思路：
- 找到最能代表核心功能被使用的埋點；
- 進行橫向和縱向對比查看。
具體數據如下（僅展示Top5）：
表2
圖17（注：用戶參與度=事件觸發用戶數/活躍用戶數）
除被刪除的功能外，其他功能和tab都只進行了調整，但未刪除。
通過自定義事件很明顯會發現，橫向“酷炫通知”功能有約12%的活躍用戶在使用，且縱向來看使用主功能的人有約22%的人在使用此功能，且超過其他核心功能的使用度。使用程度高，就意味著被刪除后，用戶流失的程度也會越嚴重。同時該功能在被刪除之前反而還有略有上升趨勢。
得出結論2：酷炫通知功能使用度僅次于核心功能1，若刪除可能會導致活躍用戶流失超過12%。
3. 用戶反饋
之后再整理收集上線后一個星期內的1010條反饋內容，如下圖：
圖18（注：反饋來源為應用市場評論、APP內部反饋、粉絲群反饋等）
得出結論3：反饋用戶中，有約40%的用戶期望加回的酷炫通知功能。
4. 用戶畫像變化
再通過MTA整理了版本更新前后的用戶畫像變化，去檢驗是否符合戰略定位的期望。最終發現男女比例變化較小，而17歲以下的用戶減少約5%。
圖19
得出結論4：低齡用戶對個性化功能需求比較強烈（酷炫通知本身也是因為過于個性化且加大產品復雜度，而被刪除），與我們產品定位于95后年輕用戶的意愿相違背。（95前的我們依舊年輕?。?/p>
5. 設備畫像變化
進一步從通過設備畫像的變化，我們可以看數據發現：OPPO用戶流失最多，華為其次。
圖20
圖21
得出結論5：OPPO、華為作為出貨量TOP3的手機廠商，其用戶的流失，非常不利于我們在該類渠道拉新。
6. 相關功能使用情況（自定義事件）
結合前5個結論，目前我們基本能得出酷炫通知功能加回的必要性。接下來可以再通過了解原酷炫通知功能系列下的各個小功能的使用情況，給產品和老板更多建議，畢竟仍能要滿足功能簡化，弱化工具屬性的要求。
數據如下：
表3
給出建議：可以考慮刪除彈框模式和透明度。
最終結果當然是功能如愿加回，且數據表現亦證明該功能加回去的成功性。
在這個問題的數據分析過程中，還有很多類似數據需要從結果數據和趨勢數據上分析，以及數據的深度還可以更進一步，如酷炫通知下的每一個小功能都有對應的參數數據。通過參數數據可以分析用戶的主要選擇（如透明度數據是大部分用戶喜歡76%的不透明度），進而可以對部分設置進行默認化。
不得不說，老板在大方向的方面會有很多真知灼見，轉型也是必然，但并不是當時所有的決策都是對的，諸葛亮也有錯用馬謖的時候。作為員工，我們有更多的時間身處前線，我們不妨把自己對用戶的動態、需求的理解不時去反饋給老板，做老板的好助手，少抱怨，這樣才能讓產品少走彎路。
寫在最后
個人覺得，如何選擇第三方和自建數據平臺，取決于你們的團隊是否有能力做好。如果能，自己做當然更個性化一點且數據分析起來會更加順心，但我相信絕大多數團隊沒有這么多的人力和時間來做到極致。這種難度的差異幾乎是自建一個商超和去一個現成的商超里買東西一般。所以，個人建議還是接入MTA這樣的第三方，有條件可以配合自建平臺吧。
相關閱讀
作者：冰雁，獨立運營并負責過多款APP（涉及安卓、iOS、小程序），最高的月活百萬級，“打雜”型運營，借助技術實現數據運營自動化
本文為「人人都是產品經理」社區和騰訊移動分析聯合主辦的“騰訊移動分析測評大賽”中的二等獎作品，未經許可，禁止轉載。
題圖來自 Pexels，基于 CC0 協議
筆者在什么單位就職啊。