【產品分享】產品需求文件裡的一些易遺漏點
CC是個半路出家的電商產品經理，之前對電商的理解只停留在做馬爸爸背後的女人上，因此當自己角色轉換後，遇到了不少困難。
今天就來跟大家分享下市面上產品經理書籍中不大會提及產品需求撰寫點，希望能幫剛轉行或者想跳坑的小夥伴一些新的角度。
我在考拉海購APP上挑了個非常簡單的活動頁作為參考，給大家作下分析。
考拉活動連結： https://dwz.cn/4e7v8x51
（非考拉產品經理，也非託，僅僅選了個可在微信中開啟的網頁）
接下來的內容就講講，如果我是這個活動頁的產品經理，除了我們在一些書籍上看到的內容之外，我還會補充哪些產品需求，供大家參考。
一、註冊、登入
首先需要考慮的是使用者的註冊/登入功能，這類功能會隨著運營需求和活動指標的不同而不同。現在很多電商產品大都採用延後登入的模式，即使用者可以直接開啟瀏覽，當需要購買、領券時，再提示註冊、登入。
當主要的拉新載體來自基於微信的H5和小程式時，尤其是自有的電商平臺比較輕，不主求訂單轉化，而是先拉新混個臉熟，思路可以稍微轉換下。
大家都知道微信授權登入還是比較方便的，有些平臺就會在活動頁進入之際要求先授權登入，然後獲取使用者的openID，頭像和暱稱，在頁面展示上會比未登入的頁面更加完善一點。
具體選擇哪種方式，主要看接到的專案情況。
微信授權登入提示頁（使用者端）
二、頁面展示和互動
考拉這個活動頁比較簡單，主要分了4個活動專場分頁，然後在專場內根據品類又作了分頁，分頁中根據促銷資訊分成了3截。
考拉海購活動頁結構簡析
關於頁面設計在這裡就不贅述了，上圖展示了這個活動頁的三級分類，基本上已經確定了頁面的展示層級和對應的框架。
接下來，就需要對這個頁面進行一些細節上的設定：
1、商品是根據邏輯自動展示，還是運營手動後臺配置
前者產品需要提供展示商品的策略，前端寫死，主要工作在產品和開發。優點是運營工作少，上線快，缺點是對產品策略要求、商品資料化程度要求比較高，比如說有些平臺對商品、使用者的標籤比較少，用這類方式展示，使用者會覺得推薦的東西不合心意，從而影響商品購買轉化。
後者需要再設計對應的後臺產品，並向運營確定好對應的維護人，主要工作在開發和運營。優點是通過人工可以提升商品購買轉化（全看運營的能力），缺點是運營工作會比較繁重，活動越多，手工活越多，影響運營的創造力和工作激情，後面能不能達到效果也就很難保證了。
現在有些平臺採用了兩者結合的方式，即建立商品模組，如自建熱銷榜、人氣榜這樣的模組，然後運營對這類榜單進行後臺配置，然後再根據活動再調整展示規則，在減少工作量的基礎上，保證了推薦的可靠性。
2、商品展示規則
接下來就是商品展示的一些細節問題。
（1）商品基礎資訊
（2）排序方式
排序如果是運營後臺手動設定的話，就不需要考慮了。若是自動/半自動的排序方式，就需要去了解下活動規則和使用者體驗。
舉個例子，一般來說，使用者會喜歡很多人買的商品，如果從平臺購買轉化角度來講的話，那商品排序按銷量多→少排序，是沒什麼問題的。
但是這樣容易出現馬太效應，對一些小商家來說不是太友好，比如說淘寶這樣的平臺，推出了競價排行，在綜合推薦的基礎上，還插了幾個競價的商品。
同時按照單一維度排序還需要考慮一些極端情況，比如說有些商品做得特別好，如果採用的分頁榜單是按照日銷量、周銷量、月銷量來倒序的，它都能霸榜，那對使用者來說就不是太友好了，他會看到不管怎麼切換都是那些商品，所以還需要新增其他排序維度，比如說品類、好評率、加購量等，也可以採用微博等新聞資訊流的方式，加個時間衰減權重，或者在榜單裡面插幾個上新商品，具體操作可以根據實際情況調整，主要需要以活動規則、運營需求、使用者體驗等多目標為準。
（3）載入方式
載入方式算是CC踩過的大坑了，未做產品之前以為產品天天做市場調研、使用者畫像等高階活，做了之後發現天天解決首頁打不開的問題，說多了都是淚。
比如說考拉這樣的活動頁，商品量還是非常多的，如果進入後頁面商品全部載入展示，那除非使用者手機效能贊，網路飛一樣，要不然輕則載入慢，嚴重就是老是載入失敗，那還要不要賣東西了。
所以大家可以觀察下考拉這個活動頁，它採用的方式是懶載入，即優先前2行商品的商品名和價格，商品圖用預設圖展示，同時預載入下方2行商品，使用者滑動時再展示後2行商品，對使用者來說，可能只延遲了肉眼可見的不到1秒時間，還是可以接受的。
還有些活動可能會做些商品預存，不是每次直接從商品庫裡面調，而是另外預存載入，這樣商品展示時呼叫起資料來，速度會快很多。
畢竟對使用者爸爸來說，超過2秒就要關頁面了。
如果給使用者一些有趣的載入提示，讓使用者內心不崩潰，也是個不錯的方式。
此外，如果商品上展示標籤、營銷資訊過多，因為涉及多張表，也會造成商品載入時間延長，這時候就需要和運營小夥伴商量，能不能把提升使用者體驗放在首位，或者找後端小夥伴處理這類情況，保證使用者爸爸們能快速開啟頁面，開開心心shopping。
（4）頁面提示
頁面上的有效反饋可防止使用者心態崩潰，具體需要根據使用者的場景，在提需求之前儘可能的做好羅列，並撰寫對應情況下的頁面提示，引導使用者進行相應的操作。
具體的案例就不舉了，花瓣上有很多有意思的設計，可以自行搜尋一下。
在此簡單講下前端需要注意的場景，比如說使用者未登入狀態下，怎麼展示頁面，使用者點選某些元素時需要使用者先授權，如何引導授權，斷網的時候如何引導檢查網路，載入失敗情況下怎麼提示使用者重新整理且不要心態爆炸，或者前端怎麼做對應的檢測，然後後臺自動重連。
實際情況會比上面說的複雜很多，到時候被開發和使用者吊打的時候大家就知道了。Orz
三、資料統計
我發現每個產品經理說到資料模組都有種欲哭無淚的表情，其實我也是Orz
在此給大家簡單介紹下一個活動頁需要埋點的資料欄位和維度，實際工作中需要的資料量可能更大一點。
根據CC目前的工作來說，運營比較關注的是拉新（渠道來源、轉化）、促活（使用者活躍資料、前後活躍量對比、某類使用者的啟用情況）和轉化（活動相關的營銷指標完成情況），而作為產品，還需要去了解下參與活動的使用者裝置、使用者路徑、使用者人群等資料，幫助自己更好地迭代產品。
四、商品和媒體管理
除此之後，還有一些後臺商品管理、媒體管理需求，如何做到和C端產品欄位一一對應，如何在保證活動營銷性和有效性的前提下，儘可能減少運營維護成本，防止他們內心崩潰，具體可以開個淘寶店鋪、有贊店鋪學習下。需要注意的是，每個平臺因為屬性不同，對於產品形態的要求是不一樣的，比如說淘寶商品上架所需要的資訊是非常多的，有些商家甚至需要安排1-2個人專門做上新，那像CC家的導購小平臺就大可不必做那麼複雜，甚至直接寫邏輯讓開發從合作方那邊調資料過來就好了。
因為CC是C端、後臺產品一起做的，不存在溝通問題，有些公司是分開的，就需要做好產品間的溝通，尤其是一些細節上保持一致，避免出現類似後臺商品標題限制字數10字，C端限制15字，到時候就會出現詭異的情況了。
結語：關於產品需求文件的遺漏點就分享到這樣，歡迎大家留言補充，一起進步，寫出更靠譜、落地的產品需求文件。