從這3個方面告訴你，產品經理應該如何寫週報

產品經理每週都要進行產品相關的資料進行統計並彙總，以週報形式遞交。在寫週報過程中，或多或少會遇到很多方面的問題。這篇文章將會從寫週報的目標、意義、誤區、策略及行動指南等方面，進行闡述，供大家一同學習和參考。

產品週報是產品經理每週所要針對業務或產品的目標，所進行一系列資料統計的報表。

對資料的處理是資料分析師或資料工程師所要做的工作，產品週報其實可以簡單的對本週的工作進行總結即可，為何還要寫作一份基於資料維度的統計週報呢？

招聘網站上關於產品經理的崗位要求，其中涉及到“資料”這一塊的要求則是：“具備較強的資料分析能力”“研究和分析日常產品效果資料、使用者反饋、跟進產品的體驗完善，不斷最佳化產品”……

可見，資料思維是一個產品人必須要掌握的技能。

產品經理每週在固定時間對上週資料進行彙總和統計，主要的原因包含以下幾個方面：

總結上週的產品資料相關情況，瞭解產品最佳化、迭代後的效果

透過週報資料的分析，獲得了產品功能受歡迎程度、投入產出比等效果的反饋，方便進行復盤、分析

基於對資料的分析和洞察，找到最佳化點並形成下一步的迭代方案或處理機制

從資料中發現機會

其他的目標（例如：對投入產出比的計算、ab測試的短期驗證、埋點資料的統計和分析、彙總資料上傳至企業戰略層做產品路線的修正最佳化等）

透過資料化的分析，產品有了資料的量化印證，可以精確的進行迭代和最佳化，在實踐過程中也可提升產品經理對資料的處理能力、洞察能力。寫好一份週報，這本身是產品修煉的基本功之一。

01 策略：基本要求

什麼是一份好的週報呢？好的週報一定是有標準和原則的。根據筆者參與過寫作的週報，透過對實踐過程的進一步的提煉和最佳化，得出以下的幾個規則：

1。 週報必須是真實客觀的

什麼是真實客觀？為什麼要真實客觀？可以說，真實客觀是週報原則裡最基本的要素。

所謂真實客觀，就是資料不弄虛作假、有缺漏、不確定，要反應真實的使用者使用產品的情況。

產品週報將應用於產品或業務的決策。如果這點做的不好，我想應該可以面壁思過了。

2。 週報的資料是要量化的

什麼是量化的？“道生一，一生二，三生萬物”。萬物是多少的數量呢？無窮無盡，這裡沒有一個數字能指代。但產品週報的資料需要量化，量化本身是統計的尺度。在文字描述中我們用的較多的“大約”“可能”等模糊詞彙，在週報中便要避免使用。

資料上的模稜兩可，看不到實際的最真實的效果，讓產品的決策變得複雜，甚至是難以說服自己和領導層相信，這個資料為什麼能夠支撐起企業百萬、千萬或更大成本或使用者量的決策依據？

3。 週報的資料統計是基於目標、詳略得當的

不同的企業由於所在階段、使用習慣等，有些企業習慣使用BI作為資料統計的方式，而有些企業則透過技術或第三方平臺進行資料統計，但總體而言，產品的歷史需求是不斷累積的，時間越久，歷史所累積的資料會越多。

資料是金礦，因此要全方位的對所做過的產品需求的資料進行統計。在週報這裡並不成立。”亂花漸欲迷人眼“，資料統計越多，會造成決策的分析成本會越大。

什麼是“詳略得當”的統計呢？詳略得當的含義，就是不需要進行全部的統計。只需要針對產品核心的業務目標進行的資料統計，有相關的產品業務線交叉，這部分的資料也應統計。臨時類資料（例如埋點，ab測試，某個運營活動）、效果類資料（轉化率、引流效果、使用者量、購買率）等方面的資料，也需要進行統計。

一般而言，如果企業把較大範圍、多個業務線的資料進行統計，一般是由多個產品經理進行負責並同時輸出和彙總。期間，有一套相對契約的統計規則幫助產品人對資料處理。筆者曾經負責過的進行週報資料統計的業務線，則是同時進行統計和彙總。

4。 週報的資料應該全面的

這裡指的是關鍵產品目標資料。例如：需要對電商平臺的訂單進行統計，其中的一項關鍵指標就是使用者的頁面轉化率（從產品詳情頁進入到訂單結算頁）。拿到了轉化率，可瞭解詳情頁帶給使用者的實際購買轉換情況，這是作為決策的依據之一。

更復雜點，還要從使用者進入訂單頁到結算完成的使用者事件之間轉化率進行統計。這樣，如果要提升購買的轉化率，則分別從商品詳情頁進入訂單頁、訂單頁到購買完成的轉化率入手，透過資料指標進行分析，產品根據分析的結論，後續對產品進行了下一步最佳化。

以上4點原則是寫週報的一些基本要求。從實踐角度而言，由於涉及到資料的精準量化統計，極易出現各類的統計問題。在闡述如何寫好一份資料週報前，我們應該認識一些常見的錯誤。知道什麼是錯誤的，可以更好的讓我們避免寫週報過程中的一些雷區。

02 誤區：容易發生的錯誤原因

我把寫週報過程中容易發生的錯誤原因，劃分為了三個方面：工具性統計錯誤、方法性統計錯誤、人性統計錯誤。

1。 工具性統計錯誤

例如：埋點錯誤造成的資料統計錯誤。產品安排技術進行埋點時，錯誤的把埋點的頁面區域位置上升了一層，導致實際的使用者行為資料比真正要統計的目標資料還要大。

統計對使用者的性別構成佔比。技術層面可以拿到相關的性別這是最好，如果不能獲得使用者授權，則無法體現性別。此時，統計了性別構成佔比，需要增加第三個維度：未知性別。否則，把“未知性別”維度去掉，所得到的佔比資料就是不精準的。

再如：在資料後臺上統計的資料中，發現某個維度的資料為空，一般用符號”\“或者”/”或者為空進行展示。產品人如果不注意這類工具性錯誤，那麼就會造成統計錯誤。碰到此類情況，需要把資料反饋給技術部門進行排查，找到資料不顯示的原因，再對該批資料進行統計。

工具性統計錯誤一般是透過技術性、異常性等原因造成，遇到此類情況，首先要確認資料錯誤的原因，待資料完善後再進行彙總。否則，資料的統計就是不準確的。

2。 方法性統計錯誤

所謂方法性錯誤，即產品經理使用了不正確的方法對資料進行統計和處理。

例如：對資料定義的錯誤理解，造成的統計錯誤。比如：當統計使用者的平臺登入數時，要確定這個數字是點選了登入按鈕的PV、UV，還是點選登入併成功登入的人數。對定義的錯誤理解，統計到的資料自然是不正確的。

再如：還是針對上文提到的案例。使用者從產品詳情頁進入訂單頁付款購買完成。此時需要統計訂單轉化率。如果產品經理把轉化率的計算公式定義為：

訂單轉化率 = 使用者進入詳情頁的uv / 使用者進入訂單頁的uv

那麼，這就是錯誤的轉化率統計方法。

又或者：產品經理需要對海量資料進行統計時，採用資料透視表的功能。統計某個維度的資料後，沒有清空篩選條件，再對下一批不同類的資料進行統計，就會出現多重篩選的錯誤。

再如：對不同維度的資料需要進行彙總在同一個列表上對比展示，其中涉及到部分的資料動態計算處理。那麼，直接複製貼上的方式，獲得的資料實際上是有誤的（計算公式的原因）。對資料處理的方法有一定的技巧，如果不能注意，那麼就容易造成了統計錯誤的情況了。

3。 人性的統計錯誤

在《歡樂頌》電視劇裡，劉濤飾演的安迪作為一家企業財務負責人，針對其他的企業進行一項收購案中，部門下的同事對其中某個資料統計時出現了重大錯誤，如果按照該資料方案執行，會讓讓財務併購案的成本增加了10倍。這種資料的統計的原因，就涉及到了“粗心”的範疇。

資料統計不全面、計算錯誤等方面的問題，可以認為是人性方面的原因。從結果維度看，這本書也是能力上的一種體現。因此，涉及到這方面的問題的產品人，更需要進行刻意練習。

03 行動指南：如何避免問題？

以上所列舉的週報的資料統計中常見的一些問題。這些問題應該怎麼避免呢？從所統計資料的定義、方法、習慣和事後檢查等方面，可以有效的避免這些問題的產生。

一般在統計週報的時候我們會使用已有統計的方式，在統計完成之後似乎是萬事大吉了。這是資料的獲取和展示階段，還有一個重要環節，就是檢查資料。檢查即是為了修正、檢查和完善資料。

如何檢查資料呢？筆者從檢視資料—瞭解資料—質疑資料-判斷資料的角度去給出一些建議。

檢視資料：對展示的資料進行整體的觀察。

瞭解資料：對觀察到的資料進行了解其前後文、定義和起伏波動等量化和流程性指標。

提出質疑：對所瞭解的資料進行質疑。例如：上週的轉化率波動異常，其環比值有較大提升。我們需要對該資料進行質疑：“資料為什麼會突然間上升？會不會是統計錯誤？可能是哪些因素導致的？這個狀況是不是其他地方也有？使用者行為反應了什麼情況？。。”透過自我提問和質疑資料是否統計準確的方式，獲得對資料的根本判斷。

判斷資料：針對資料完成其真實性、前後文等進行的判斷。需要對資料進行流程化的判斷和思考，從而為後續的洞察週報的資料做好準備。

完成了基本對週報資料的4個基本動作後，就需要對資料進行洞察。洞察是為了幫助產品經理更好的使用資料進行決策、分析和制定下一步的產品最佳化方案。

洞察資料的維度可包含以下幾個方面：

理解指標的意義及走勢情況：包含對比、環比、升降、轉化率、佔比等方面。

從資料前後文發掘資料在整體流程上的情況：如資料所在位置和流程、 資料所在的盈利鏈條、資料所承載的目標和作用

理解和洞察。例如：我們對資料從業務目標、所代表的背後含義、反應了使用者的行為/動作/趨勢/喜好度等方面入手。

洞察資料後，瞭解其成因和所代表的使用者行為等方面，就可以為後續的產品最佳化、產品決策做好準備。

最後

以上是從資料的洞察方面進行了總結和概括。筆者認為，產品經理寫好了一份資料後並不代表週報已經完成和結束了，而是讓我們從資料思維角度，去做下一步產品最佳化的開始。

只有儲存對資料的敏銳度、提升從資料中捕捉需求、瞭解反饋、洞察未來的能力，才能成為一個不斷升級打怪產品人的必經之路，是為後續高階的產品之路做好鋪墊。從週報見方法、見自我之性格、見習慣，這更是自省反思及提升的實踐之路。

本文由 @阿藝師傅 原創釋出於人人都是產品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基於CC0協議。