創業公司做資料分析（五）微信分享追蹤系統
作為系列文章的第五篇，本文重點探討資料採集層中的微信分享追蹤系統。微信分享，早已成為移動網際網路運營的主要方向之一，以Web H5頁面（下面稱之為微信海報）為載體，利用微信龐大的好友關係進行傳播，實現宣傳、拉新等營銷目的。以下圖為例，假設有一個海報被分享到了微信中，使用者A與B首先看到了這個海報，瀏覽後又分享給了自己的好友，使用者C看到了A分享的海報，瀏覽後繼續分享給了自己的好友。這便形成了一個簡單的傳播鏈，其中蘊含了兩種資料：
- 行為，指的是使用者對微信海報的操作，比如開啟、分享。
- 關係，指的是在海報傳播過程中，使用者之間形成的傳播關係，比如使用者A將海報傳播給C。
這樣的資料的意義在於：第一，統計分析各個渠道的海報的傳播效果；第二，對傳播貢獻較大的使用者發放微信紅包獎勵，提高使用者的分享積極性。微信分享追蹤系統，便是完成對這兩種資料的採集和儲存。在過去的一年裡，受到公司業務和運營推廣方向的影響，這部分資料驅動了近一半的推廣業務。
熟悉微信開發的朋友應該知道，第一，每個微信使用者在某個公眾號下都擁有一個唯一的open_id，開啟微信海報時，可以通過OAuth2靜默授權在使用者無感知的情況下拿到其open_id；第二，通過微信JS-SDK，我們可以捕捉到使用者對海報頁面的分享事件；第三，拿到使用者在公眾號下的open_id後，便可以對該使用者發放微信紅包了。基於這三點，我們便可以實現相關的資料追蹤和分享獎勵了
首先要說一點的是，其實微信分享追蹤系統本身並不複雜，但是與複雜的產品業務結合到一起，就變得越來越複雜了。如何做到將資料邏輯與產品業務邏輯剝離開，以不變應萬變，就是這裡要說的方案演進了。
1. 早期服務
早期的微信分享追蹤系統，筆者曾經在淺談微信公眾號營銷背後的技術一文中介紹過，其時序圖如下所示。基本流程是：第一，使用者開啟海報時，通過OAuth2授權，將open_id加入到頁面連結中；第二，前端上報瀏覽事件，需要帶上open_id和傳播鏈資訊；第三，使用者分享時，需要在分享出去的連結中加上傳播鏈資訊，所謂傳播鏈資訊，就是每個分享過的使用者的open_id組合，比如“open_id_1;open_id_2”；第四，上報使用者的分享事件，需要帶上open_id和傳播鏈資訊。後端收到上報資料後，根據不同的功能需求，將資料儲存到不同的資料表中，用於後期消費。隨著業務的發展，這個系統暴露出一些問題：
- 隨著推廣活動的調整，統計和獎勵政策也隨之變化，比如有的依據一度分享者的分享次數進行獎勵，有的依據一度、二度分享者帶來的瀏覽量進行獎勵等等，還有需要根據上報的引數不同做不同的處理。所有邏輯都在上報的API請求中處理，來一個需求加一段邏輯，導致該請求的功能不斷膨脹，而且一些推廣活動已經下線了，相關的邏輯也沒有清理掉。
- 引數比較混亂，頁面URL中攜帶了不同的引數，包括微信相關引數、產品相關引數，前端上報時需要攜帶不同的引數，而前端頁面太多，經常搞錯。
2. neo4j的嘗試
於是，我們思考，有沒有可能在後端直接構建完整的傳播資訊，後期使用時直接根據條件就可以查詢出所需的資料，前端上報時也不用攜帶傳播鏈資訊，我們想到了圖形資料庫儲存技術
圖形資料庫是一種非關係型資料庫，它應用圖形理論儲存實體之間的關係資訊。在文章開頭的那張傳播圖中，使用者的行為資料其實可以歸結為使用者與海報之間的關係資料，這樣，這個系統其實就包含兩種實體：使用者、海報，三種關係：使用者開啟海報、使用者分享海報、使用者之間的傳播。在諸多圖形資料庫中，我們決定選擇比較成熟、文件相對豐富的neo4j來做DEMO。採用neo4j的查詢語法，很簡單的就可以查詢出所需資料，簡單示例一下。
# 查詢1度分享者
MATCH (u:User) - [:FORWARD] -> (p:Poster) RETURN u
# 查詢瀏覽情況
MATCH (u:User) - [:OPEN] -> (p:Poster) RETURN u下圖呈現基於neo4j儲存的新系統時序圖，在OAuth2授權的重定向過程中，建立User和Poster節點資訊，以及二者之間的OPEN關係資訊，並且對頁面URL計算hash值（去除無用引數資訊），然後將使用者open_id和URL的hash值加到頁面URL中返回給前端。使用者分享時，把該使用者的open_id作為parent欄位值，加到分享連結中，新使用者開啟該連結時，會根據該值來建立User與User節點之間的SPREAD關係資訊。在使用者分享的事件中，做一次資料上報，攜帶open_id和頁面URL的hash值即可，後端拿到資訊後，便可以建立User與Poster之間的FORWARD關係資訊。如此，便可以建立完整的微信分享追蹤資料了。
然而，一切並非預期的那麼完美，在DEMO過程中，我們發現有兩點問題不能很好的滿足我們的需求：
- 無法根據時間條件快速查詢資訊，比如查詢出昨天的一度分享者。
- 在查詢使用者間的關係時，會發生誤判。比如在下圖所示的傳播關係中，UserA和UserC的傳播關係是發生在海報PosterA上的，在PosterB上並沒有，但是當我們嘗試查詢二度分享者時，會將UserA->UserC->PosterB誤判為二度分享。
# 查詢2度分享者
MATCH (u1:User) - [:SPREAD] -> (u2:User) - [:FORWARD] -> (p:Poster) RETURN u2, p
雖然這些問題可以想辦法繞過去，比如根據時間建立不同的實體節點等等，但是這樣會把資料儲存做複雜化，經過權衡，我們暫時擱置了這個方案。
3. 基於使用者行為資料採集系統的方案
在創業公司做資料分析（三）使用者行為資料採集系統一文中，曾經提到早期的資料採集服務是分散在各個業務功能中的，後來我們重新構建了統一的使用者行為資料採集系統。在完成這個系統後，我們開始考慮將上述的微信分享追蹤系統併入其中，主要工作有：
- 資料上報的流程與早期的系統一致，但是更換原有的上報方式，採用使用者行為資料採集系統的方案統一上報微信分享的資料；
- 資料接入Kafka後，一方面直接將原始資料儲存到Elasticsearch，另一方面，以worker的形式來消費資料，根據相應的業務需求提取出所需的資料存入格式化資料表中，用於統計和獎勵活動。當某個推廣活動結束後，將其所屬的worker停掉即可。
通過這樣的改進，我們暫時解決了前端上報混亂和後端業務邏輯膨脹的問題，將資料上報和業務需求隔離開。資料方面，實時資料流在Kafka中，歷史資料也在Elasticsearch中有儲存；業務需求方面，來了一個新的需求後，我們只需新增一個新的worker來實現消費邏輯，活動結束後停掉worker。