統計數據出問題,產品經理應該怎么辦?
上個月咱們了解到埋點數據從上報到生成報表大體分為五個關鍵環節:
埋點->上報->后臺記錄日志->計算&入庫->展示
今天咱們介紹下統計數據出問題后,一般的原因有哪些,應該如何跟進。
1、報表數據為0
一天,韓梅梅找到李雷
韓梅梅:『老李啊,咱們這個版本新加的埋點怎么報表上都是0???』
李雷(驚訝的):『???我看看!』
老李為啥會『驚訝』呢,因為這個數據的上報在版本上線前已經測試通過了。不過,為了保持程序猿做事的嚴謹性,老李還是通過『抓包』或者『查日志』的手段確認了客戶端功能無誤,然后果斷的找到負責后臺數據統計的同學,將問題拋給了他們。
小編點評:
數據有上報而報表數據為0,這種問題一般會出現在『計算&入庫』和『展示』環節。因為『上報』和『后臺錄入日志』這兩個過程是與具體的埋點功能無關的,它們對應的邏輯和功能相對穩定。而『計算&入庫』和『展示』環節則多需要根據不同的統計需求做修改,所以在驗證客戶端埋點功能正常后,最有可能出問題的就是這兩處。如果出現這種異常,向韓梅梅一樣,先找到李雷確認功能正常后,再聯系后臺負責數據統計的同學跟進,一般情況下,異常的數據都是可以恢復的。如果不幸確實由于客戶端的Bug導致數據沒有上報,那數據就只能等下個版本修復了。(韓梅梅:『胡說,不是還有熱補丁嗎?』好吧,產品會技術,誰也擋不住,小弟佩服?。?/p>
2、報表數據大面積突降
韓梅梅:『老李啊,怎么今天咱們的日使用、在線時長、點擊量…(此處省略一萬個數據名詞)都比平時少了一半?』
李雷(胸有成竹地):『我找人幫你看看!』
老李從運維同學處了解到,昨天對服務器上的日志進行了遷移,由于遷移數據遷移過程太長導致一些日志沒有參與『計算&入庫』,等下會重新部署昨天的統計任務,恢復數據。
小編點評:
如果已經穩定很久的報表,突然出現大范圍的數據突降,先找找運維同學吧,看看最近日志分析系統有做策略調整或者日志遷移,導致報表中只收錄了部分日志的數據。如果是的話,不用擔心,即便你不找上門,運維同學也會主動跟進,把數據恢復的。
3、報表數據突增
韓梅梅:『老李啊,這兩天咱們沒做什么推廣,怎么天天亂跑的下載量突然上漲了好幾倍?是不是你又出Bug了?』
李雷(無辜地):『怎么可能!』
老李當然無辜了,心中一萬匹羊駝:『產品沒做推廣,我們程序猿也改不了線上版本的代碼啊,前幾天還正常運行的統計邏輯,突然到某一天錯亂了,你以為我寫的是『千年蟲』啊』。
小編點評:
線上的單個數據或者相關的幾個數據突然出現異常增長,很有可能是被人惡意刷量。要確定這種問題,直接找數據組的同學查下原始日志,確認下是不是有個別IP或者用戶ID對應的PV數量明顯異常。如果這樣都查不出來異常原因,恭喜,你提前完成了KPI!
4、歷史數據出現問題
韓梅梅:『老李啊,今天做數據對比的時候,發現去年3月份的曝光量數據好像不大對,你快幫我看看啥原因?』
李雷:。。。
其實老李想說『你把我小時候弄丟的奶嘴找回來,我就幫你找曝光量不對的原因!』
小編點評:
要確認問題的原因,上報數據的原始日志是十分重要的線索。報表中的數據,可以追溯到幾年前,但是原始日志由于數據量太大,可能只會在服務器存儲幾個月甚至幾天。所以,對于這種要求,程序猿只能說『臣妾做不到?。 ?。
5、報表數據明顯低于預期
韓梅梅:『Lucy,昨天咱們的新版本訪問這個頁面的只有6人,看來咱們高估了用戶的需求?!?/p>
Lucy:『是啊,太出乎意料了,我預計至少應該有3000人訪問呢?!?/p>
李雷聽到了韓梅梅和Lucy的對話,默默的在開發中的版本上修復了這個關鍵路徑數據漏報的Bug。
小編點評:
這種問題找負責埋點同學準沒錯,肯定是遺漏了重要的用戶路徑,重新埋點吧。
6、業務流復雜的漏斗統計數據異常
在一個韓梅梅剛剛建立的群中
韓梅梅:『@all 昨天投放的天天亂跑推廣Banner只帶來了5個新增,請大家幫忙看下原因!』
群里的一百多號人認真的讀完了韓梅梅發來的消息后,就各自繼續忙自己之前的工作去了。
小編點評:
從push下發banner數據到用戶成功安裝應用,中間需要經過多個業務能力的配合,如果漏斗中的數據出現異常,只需要逐級找相關負責人確認數據即可。一股腦將所有相關不相關的人員全部拉到一起,只能證明自己業務能力的低下,而且這樣做往往會導致事情變得負雜,降低問題跟進的效率。實在不了解整個流程的話,找個負責任的開發協助你一下吧。
小編總結:
常言道,常在河邊走,哪能不濕鞋。常年埋統計數據,咋還能不讓數據出個錯呢。然而如果產品經理如果能做到以下幾點,隨不說可保萬無一失,即便遇到問題也必定游刃有余,應對有方:
- 及時關注重要數據,有問題及時發現、反饋,有助于程序猿找Bug。
- 影響埋點數據的因素考慮清楚,如果數據出現異常,原因是否可追溯,如有需要,可以多設置幾個輔助埋點。
- 一些重要的數據埋點可以跟技術同學一起討論制定。
- 除了熟悉自己負責的業務外,外圍業務也要了解。
- 多關注『給產品經理講技術』中的技術科普性文章(我很認真的哦~),增強自己對問題的認識、分析能力。
相關閱讀:
PS:
如果一個穩定了很久的數據報表在某一個天突然發生異常,看看那幾天有沒有一下情況出現:
- 客戶端或者前端發布新版本
- 后臺日志系統是否近期有調整
- 數據統計服務是否近期有調整
如果數據異常事件正好與上述三個事件中的某一個重合,數據異常的原因十有八九就是它造成的了??捎浐昧伺叮@個訣竅一般人我不告訴他~
#專欄作家#
給產品經理講技術,微信公眾號(pm_teacher),人人都是產品經理專欄作家。資深程序猿,專注客戶端開發若干年,對前端、后臺技術略懂,熱衷于對新的科技領域的探索。
本文原創發布于人人都是產品經理,未經許可,不得轉載。
- 目前還沒評論,等你發揮!