品牌行銷策略，產品行銷與設計，各類型行銷推廣案例分享-品牌行銷點點讚
編輯導讀：虎撲APP作為一個以體育賽事和日常生活為主的社區網站，一直頗受用戶喜歡。本文作者以虎撲APP球隊頁為例，對其功能重構進行分析，希望對你有幫助。
一、需求背景
公司足球業務終止與A的數據供應合作關系，之后和B達成合作關系，因兩個供應商提供的接口字段不同且面臨接口java化的背景，所以決定直接重構底層數據和前端樣式：其中主要需求包括球員詳情頁、球隊詳情頁重構以及修正后臺搭建。
二、前端頁面重構思路
1）我們能給的不一定是用戶想要的
首先整理了球隊頁整體的DAU、PV、瀏覽時長、前向來源等數據以及各個子tab下的點擊、訪問、曝光情況。以PV為標準：新聞tab>賽程tab>球員tab>數據tab>資料tab>轉會tab、以CTR為標準：新聞tab>球員tab>轉會tab>數據tab>賽程tab>資料tab。球隊詳情頁產生之初，出發點是我們能提供什么樣的能力和服務，所以逐漸把頁面做的繁冗復雜，同時維護資源跟不上導致用戶反饋激增，這次重構就是需要獲取到各層級的用戶數據，并根據數據去推測用戶需要的是什么以化繁為簡。（球隊頁結構見下圖）
2）求同存異定產品設計原則
這次主要是選擇了騰訊體育、懂球帝、PP體育、直播吧、球會體育、雷速體育做為競品來拆解，會發現各家對球隊頁的子tab拆分都無外乎是從資料、數據、陣容、賽程、資訊和轉會維度出發（我理解這是用戶瀏覽球隊頁最基礎的需求，也是理解成本最小的一種分類方式），但不同的是各家對球隊頁的header以及子tab中放置的字段與排列樣式有著不同的想見解，組件間的交互也迥然不群（例如切換到賽程tab，錨點定位在哪個賽程卡片）。球隊頁作為一個信息聚合頁面，它既需要具備數據展示和查詢的工具屬性，也需要具備新聞和討論的社區屬性。
所以這次的重構也是以此為切入點，需要貫徹以下兩個原則：高效的數據信息展示效率，流暢清晰的交互。
3）用戶是重構的重要方向導航
第三點還是一個老生常談的方法就是去收集用戶反饋，我一直認為現在市面上沒有幾家公司可以做到產品給什么，用戶就用什么。大多數的我們還是需要去“認真聆聽”用戶的吐槽并服務好他們。用戶罵得越兇，罵得越多，重構的方向就越明確，也就越證明重構本身是正確的。
例如用戶會“告訴”我：右上角的關注按鈕有什么用？我點了可以干嘛？也沒有toast提醒我？專區的入口這么小，我哪知道可以點？點擊排名會跳轉至二級頁面，為什么點身價就不會跳呢？怎么有的球隊頁新聞都沒有，我明明看到有很多新聞報道這個俱樂部？為什么中超球隊改名后詳情頁的新聞就沒有了？為什么有些新聞里的球隊標簽點擊不會跳轉至球隊詳情頁？有這么多問題是因為球隊頁單獨來看是很簡單，但是把它放在整個App中的時候就會發現他的鏈路之長，牽一發而動全身，有一些問題是bug，有一些問題是當初的產品設計問題，所以我們在重構的時候很重要的一個任務就是需要去處理掉它們。
以之前的資料頁為例，當時它的定位是對球隊基本信息的整合，包括成立時間、所在地區等和榮譽記錄，用戶瀏覽的情景無非是忘了或者不了解這個球隊的基礎信息，然后來看一眼就走了，然后再對應之前拉過的數據也發現這個tab的用戶瀏覽數也只有兩千多，從數據上來看其實是完全可以把這個tab下線或者合并至其他tab中。
但是在新版中（見下圖，左舊右新）我們賦予了這個tab新的定位-“主會場”。從錨點上來看，老版默認定位在新聞tab，新版定位在主頁tab；從內容上來看，新版的主頁主要包含了四個模塊：第一是賽程卡，因為我們希望用戶可以在進來的第一眼就可以實時且重要的信息，具體賽程卡顯示哪一場比賽以及樣式就不展開來說了，其中的邏輯也是相對復雜； 第二個模塊是轉入轉出球員，老版本中轉會是有個單獨tab的，但是瀏覽的用戶數過低，所以我會判斷這個板塊并沒有持續瀏覽需求，只會在交易前后的那段時間激增，所以把這模塊按照轉入球員和轉出球員區分展示，用戶既可以在主頁中看到最近轉會的球隊信息，也可以點擊頭像進入球員頁獲取更多的信息。第三四個板塊才是之前老版的基本資料和榮譽，同時在展示上也做了一些更快獲取信息的樣式變動。
包括數據tab的改動，都是圍繞著“高效的數據信息展示效率”原則來進行的，將數據項劃分為不同的類型，關鍵球員的展示效率提升了超過50%同時兼具美感。這次重構中，除了解決部分歷史問題和反饋，同時也沒忘了做一些“秀肌肉”的功能，例如賽季和賽事的篩選，用戶可以看到球隊的歷史數據。
三、后臺搭建思路
1）后臺搭建的背景
首當其沖就是我們為什么要去搭建這個后臺，原因主要是新接入一套數據源的時候，我們無法去預估實際數據出問題的頻率，直接去聯系數據源修改接口的時間鏈路太長，若是故障型的bug出現是來不及解決的，開發也不可能時刻聯系改庫，特別是國際足球的比賽都集中在凌晨的情景下，所以我們需要一套運營和產品可以直接修改球隊詳情頁的后臺，這也就要求了這個后臺需要在前端上線之前完成。
2）后臺架構梳理
因為這個后臺的搭建是做在已有的大后臺中，所以省去了很多用戶、權限、節點的工作量。我這邊只需要梳理足球通用配置后臺如何實現球隊詳情頁的修改生效。（見下圖）
在梳理的時候，可以清楚的看到修改某個數據，可以有三種方法：第一是供應商直接修改接口中的字段、第二是服務端在吐給前端的接口中改庫；第三就是這次要實現的通過后臺改庫從而修改前端頁面，在第一版的設計中，賦予了后臺數據添加、修改和屏蔽的功能。但是在此思考后會發現這個設計缺少了最重要的一步：數據覆蓋的控制。有一種情況是數據源給球隊的賽程接口中提供錯了比分，但是這個接口是每秒輪詢一次，我們在后臺改動的是服務端自己的接口，即使在后臺把這個比分字段該為正確的之后也會被數據源給的錯誤字段給覆蓋，于是這個后臺等于沒用。
3）后臺搭建規劃
雖然后臺設計的時候，定義的是一個后臺。但是拆解任務的時候會發現一期完成這個龐大的工作是不太可能的，除了工作量大這個原因外，還有一個更重要的原因就是數據也有不同的類型，對不同類型的數據處理方式是不唯一的，我們把整個后臺拆為了三期來完成。
第一期主要是完成靜態數據的后臺管理，這一部分的字段主要是球隊的基礎信息，例如球隊中文簡稱、logo、成立時間、所在地區等，我們對其的要求是僅初始化同步一次，后續的管理需要人力來維護，主要原因也是因為足球球隊數量極多且是相對靜態的，這樣只需要人力維護一次，以及球隊改名需要少量的維護就可以完成，而不再受數據源影響。
第二期是完成對動態數據的后臺管理，例如賽程、球員球隊榜和積分榜等數據，這部分數據更新頻率普遍在1min-10mins，這也代表著不能和靜態數據一樣靠人工維護。那這一塊我們做數據覆蓋控制問題的時候，還需要確認一個問題是：新覆蓋的數據需要【先審后發】還是【先發后審】。先審后發的實現方式是對比前后兩個字段，若有不一樣的時候，在釘釘群和后臺發送提醒信息，運營需要點擊通過或不通過來確認是否需要覆蓋，這樣保證的是準確性；先發后審是供應商的數據先覆蓋，運營再去處理同步錯誤的字段，這樣保證的是實時性。
第三期是完成實時數據的后臺管理，實時數據主要包括的是直播間的數據。例如機器直播和比賽數據更新，這一塊的策略是先審后發是為了符合直播間最基礎的時效性，所以這塊需要在后臺設置一鍵切換為人工直播，為了以防直播間數據大面積出錯的情況。
四、踩雷和反思
反思一：做需求切勿囫圇吞棗
- 以繁化簡。因為后臺涉及到足球所有相關數據頁面，一個迭代（兩周）完不成，跟不上前端上線的速度，應該挑重要字段/容易出錯字段的管理先上線。
- 謹防需求遺漏。需求一大，就容易出現產品規劃遺漏東西，開發理解需求文檔的效率也很低，所以盡量拆分為數個小需求分期進行開發。
- 針對性后臺設計。數據本身有特性，有靜態數據，例如國籍、出生日期等；有動態數據，例如積分榜，助攻榜等；有實時數據，例如直播間的數據統計，不同特性的數據要求的同步機制不同，即可以此為劃分不同階段的界線。
反思二：前端設計的時候可以“理想主義”，但收攏的時候一定要仔細對好新數據源接口的字段
- 先發散。在重構前端頁面的時候要盡量去滿足用戶瀏覽和產品秀肌肉需求，不要被接口提供的能力給限制了。在前期理前端頁面需求的時候，會對照著接口文檔提供的字段畫原型，這樣一是速度特別慢，二是頁面就局限了。因為當方案足夠合理（符合用戶需求），即使數據源沒有提供該字段也可以通過其他路徑滿足，例如爬蟲、向數據源提需求、合作其他數據源……
- 后收攏。發散后需要根據頁面數據和用戶反饋來做減法，清晰簡潔才是王道。
反思三：后臺架構很重要，想清楚會事半功倍
1. 后臺設計可能需要花很多時間，把這個鏈路梳理清楚也不是一個簡單的事情，但是真的很有必要，當把后臺的生效機制理清楚之后，會發現對后臺的理解會上一個新的臺階。
2. 運營也是我們的用戶，所以我們也要讓運營用的方便，后臺的交互也是十分重要的，而不只是停留在可以用的階段。
反思四：后臺需要不斷的積累
我接觸產品經理的這個時候，一直接觸到的都是c端的產品，剛開始接觸后臺的時候，對后臺的設計總是會漏洞百出，這也是需要我們不斷的取試錯，快速的積累。（下面是整理的后臺用例表格）重構的工作是不容易的（前人埋坑后人淚目）所以這要求我們在產品設計之初的時候，一定要把視線放長遠，預埋好足夠的擴展空間避免重復造輪子。
本文由 @OTTIS 原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash，基于 CC0 協議