<del id="957j9"></del>
<listing id="957j9"><listing id="957j9"></listing></listing>
<ruby id="957j9"><ins id="957j9"></ins></ruby>
<menuitem id="957j9"><ruby id="957j9"></ruby></menuitem><listing id="957j9"><del id="957j9"></del></listing>
<menuitem id="957j9"></menuitem>
<menuitem id="957j9"><cite id="957j9"></cite></menuitem>

產品經理如何有效避開數據分析常見的坑?

不懂技術怎么做產品?15天在線學習,補齊產品經理必備技術知識,再也不被開發忽悠。了解一下>

對產品經理來說,以各項指標為對象展開數據分析,并做出對應應對策略是家常便飯的一件事。不過,在數據分析的時候,我們總會遇到數據異?;蛘邤祿Σ簧系膯栴},而本文就分享了如何從源頭規避這些坑的方法。

做數據統計和分析,是一項嚴密和邏輯性很強的工作。如果平時不多加注意,就會出現一些不好解釋的問題。

比如發現報表數據對不上或者有些數據漲跌的原因無從解釋,這時不僅需要耗費很多精力去排查,還有可能會誤導我們后續的迭代,作出一些不正確的決策。

下面我就重點講講,怎么從源頭來有效規避這些坑。

01?數據埋點的坑:埋點不全面和上報邏輯不一致

1. 數據埋點不全面、范圍錯誤或上報邏輯不準確

(1)數據埋點不全面

就是有遺漏的埋點,這個可能直接導致重要的數據沒有辦法采集,是需要盡快排查并完成補救的,否則會對數據分析影響較大。

埋點不全通常包括兩方面:

1)點位缺失

比如某個頁面、某個按鈕的點擊位沒有加等,這個會造成數據缺失,必須重新打點才能補救;

2)參數遺漏

比如少加一個渠道的參數,這個只是對數據的對維度分析有影響;

(2)取數據范圍錯誤

比如統計活動頁面的發帖,如果無法區分內容是來自活動頁面那就沒法做后續的分析。

(3)上報邏輯不準確或不一致

比如發布按鈕是點擊就上報,還是發布成功時再計數?點贊是生效才計算,還是只要點擊都算?這些上報邏輯的確定對后續的數據分析有很大影響,一旦不一致就會出現數據對不上的問題。

2. 如何規避埋點問題,確保打點完整和上報統一

這塊需要建立完整的埋點實施流程和打點模版。

(1)確立埋點實施的流程和規范化操作

在產品需求方案完成后必須開始設計埋點方案,而不能拖到開發階段,具體流程和事項包括:

  1. 明確當前版本的核心數據指標,做好指標定義,并梳理對應的核心頁面和功能點;
  2. 埋點事件設計,明確事件類型(訪問、曝光、點擊),事件點位以及細分維度(來源、用戶設備)等;
  3. 前端或服務端打點拉通和實施,確定相應規范;
  4. 測試排查機制和上線驗證;

數據埋點流程

(2)建立打點模板,做好聚類、參數命名和規則定義等

進行具體的埋點設計,需要建立項目匹配的埋點模板,做好規范化管理。

數據埋點模板

02?建報表的坑:數據統計口徑錯誤或者不一致

1. 數據統計口徑不一致通常表現為:數據來源不一致、數據指標定義和公式拆解不準確

1)首先,口徑不一致最普遍的坑,就是取數據的來源不一致

這點很好理解,通常我們建報表都要和BI同學溝通數據是從哪里取,是從前端的打點取還是服務端的表里取。如果前期沒有明確出來,后面很可能造成數據上來源不一致的問題。

比如社區的發帖數據,發帖UV和發帖率,如果取前端數據可能會不準確,而服務端更精準一些。

如果現有報表存在不一致,需要立即修改。

2)其次,是數據指標定義不對

比如內容社區,拿對內容生產這個指標的定義來說,是否應該包含評論內容必須明確好。不能說內容生產包含評論,互動指標里也有評論,那就有點自欺欺人了。

比如對業務新用戶的定義,很多非app的業務很難以注冊和激活app來定義新用戶的,這個時候就需要明確的定義,是從來沒有使用過,還是某個時期內,如一年內新訪問業務的用戶;

再比如流失用戶,我們通常定義可能是1個月甚至更短時間沒有啟動app就算了,但是對于低頻的應用,或者像教育類app存在寒暑假,你很難這么去定義;

3)還有可能,是數據指標公式拆解不對

比如人均發帖究竟應該是發帖量比上整體的UV還是應該比上發帖UV?如果你比上前者你就發現人均發帖量很小,你就會很困惑,困惑就是因為我們的公式錯了。我們其實要的是發帖這些人,平均會發多少條。

通常我們的數據指標公式,比如:

  • 訪問滲透率=當前頁面的訪問UV/上一頁面的訪問UV;
  • 點擊滲透率=當前位置的點擊UV/當前頁面的訪問UV;
  • 參與率=活動參與的UV/當前頁面的訪問UV;
  • 人均訪問=訪問PV/訪問UV
  • 人均發布=發布PV/發布UV

2. 如何規避?確定數據來源,明確數據指標的定義以及換算公式

針對數據統計口徑容易出現的問題,我的解法是:

1)在前期建報表需求的時候,一定要梳理好指標項,并對指標做好明確的定義,明確數據來源,和對應的換算公式。

2)建數據報表前期一定做好統計口徑的溝通,明確哪一部分的數據從哪里???是取前端的打點還是取服務端的數據;

通常的原則是:頁面展現、點擊、本地播放或者停留時長等數據可以取前端數據,數據上報依賴網絡,且用戶刪除自己操作記錄時也會有數據丟失的情況,所以前端打點存在延遲和不準確、不完整的缺點;

而安裝數據、內容生產、互動數據可以使用服務端數據,更為精準;實時性好,不存在延時上報。

3)做好公示拆解和定義。如果公式錯誤,在數據分析時就會出現歸因錯誤,所以一定要在前期規避。

這里我提供一份建表的需求模板,通常這樣完整提供給BI最保險。

數據報表需求模板

03 數據分析的坑:數據指標看絕對值,忽略鏈路和技術因素

坑1:數據指標看絕對值,對比也看絕對差值

看絕對值的坑主要表現為:指標觀察看絕對值和數據間對比看絕對差值。這塊應該改為指標優先側重比率指標。另外,做數據對比,一方面要使用比率指標來看產品的效果。

比如內容社區的發帖數,如果要看這個指標的情況,不論是前后數據對比還是設立分桶做同步對比,因為漏斗的上一層(訪問UV)肯定存在不一致的情況,所以此時使用發帖率來評估效果才是更準確的。

并且,看發帖率的漲跌對比,也要看相對比值,而不是看絕對差值。

比如之前的發帖率2.4%,現在的發帖率是1.2%,從絕對值來看不多啊,才降了1.2個百分點,但是實際降了100%;

坑2:只針對單一指標進行分析

這里的坑是將指標分開單一看,忽略多環節或者鏈路指標的分析,這時候其實根本不明白數據是因為哪里才發生了變化。

還是以內容社區產品為例,比如我們要看回復框的發帖成功率,你會發現在評論詳情頁的回復框的發布成功率比帖子詳情頁回復框的發布成功率要高。

但其實這并不能證明后面的回復框就好,其實回復框樣式通常是一樣的,只是因為進入評論詳情頁且要評論的用戶忠誠度更高,且真有評論的需求。

并且有時所說總指標看是漲的,但漏斗某一指標卻跌了,所以數據分析時整體鏈路上的指標都是需要我們關注的。

可以說只通過對單一數據指標的對比,通常是無效的。我們需要兼顧多種因素以及評估整個功能鏈路或者漏斗模型的數據指標情況。

坑3:沒有考慮技術因素帶來的波動等

有些數據波動可能是由于網絡或數據接口等技術原因,對打點造成的影響,這塊需要考慮并作出優化實驗;

比如我之前做ab實驗時,發現新版的留存就是比舊版要低,但是低的幅度很小,都是在1%以內。

按理說新版的體驗比舊版要好很多,從用戶定性反饋和訪問、生產、消費等定量數據指標都能看出來。但唯獨留存略低,經過排查發現,新版的首頁的接口數量增加了,請求時長變長,頁面打開成功率降低,造成新版留存略低。

所以整體上,對于微小的波動如果確實找不到原因可以忽略,但是對于大的波動一定要考慮技術等因素。

04 小結

數據統計和分析的避坑卡片

總之,在數據統計和分析時,我們只有有效避開這些常見的坑,才能更好得出我們想要的分析結果,指導我們的后續迭代。

#專欄作家#

阿外,微信公眾號:波悟館,人人都是產品經理專欄作家。10年互聯網產品經歷,關注社交/教育和新消費領域,聚焦行業分析和產品力建設。

本文原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協議

給作者打賞,鼓勵TA抓緊創作!
評論
歡迎留言討論~!
圈子
關注微信視頻號
大家都在問
江西十一选五-一定牛