作為系列文章的第五篇，本文重點探讨資料采集層中的微信分享追蹤系統。微信分享，早已成為移動網際網路營運的主要方向之一，以web h5頁面(下面稱之為微信海報)為載體，利用微信龐大的好友關系進行傳播，實作宣傳、拉新等營銷目的。以下圖為例，假設有一個海報被分享到了微信中，使用者a與b首先看到了這個海報，浏覽後又分享給了自己的好友，使用者c看到了a分享的海報，浏覽後繼續分享給了自己的好友。這便形成了一個簡單的傳播鍊，其中蘊含了兩種資料：
<b>行為</b>，指的是使用者對微信海報的操作，比如打開、分享。
<b>關系</b>，指的是在海報傳播過程中，使用者之間形成的傳播關系，比如使用者a将海報傳播給c。
這樣的資料的意義在于：<b>第一，統計分析各個管道的海報的傳播效果;第二，對傳播貢獻較大的使用者發放微信紅包獎勵，提高使用者的分享積極性</b>。微信分享追蹤系統，便是完成對這兩種資料的采集和存儲。在過去的一年裡，受到公司業務和營運推廣方向的影響，<b>這部分資料驅動了近一半的推廣業務。</b>
熟悉微信開發的朋友應該知道，第一，每個微信使用者在某個公衆号下都擁有一個唯一的open_id，打開微信海報時，可以通過oauth2靜默授權在使用者無感覺的情況下拿到其open_id;第二，通過微信js-sdk，我們可以捕捉到使用者對海報頁面的分享事件;第三，拿到使用者在公衆号下的open_id後，便可以對該使用者發放微信紅包了。基于這三點，我們便可以實作相關的資料追蹤和分享獎勵了，本文主要是總結我們在微信分享追蹤上的方案演進。
首先要說一點的是，其實微信分享追蹤系統本身并不複雜，但是與複雜的産品業務結合到一起，就變得越來越複雜了。如何做到将資料邏輯與産品業務邏輯剝離開，以不變應萬變，就是這裡要說的方案演進了。
<b>1. 早期服務</b>
早期的微信分享追蹤系統，筆者曾經在淺談微信公衆号營銷背後的技術一文中介紹過，其時序圖如下所示。基本流程是：第一，使用者打開海報時，通過oauth2授權，将open_id加入到頁面連結中;第二，前端上報浏覽事件，需要帶上open_id和傳播鍊資訊;第三，使用者分享時，需要在分享出去的連結中加上傳播鍊資訊，所謂傳播鍊資訊，就是每個分享過的使用者的open_id組合，比如“open_id_1;open_id_2”;第四，上報使用者的分享事件，需要帶上open_id和傳播鍊資訊。後端收到上報資料後，根據不同的功能需求，将資料儲存到不同的資料表中，用于後期消費。随着業務的發展，這個系統暴露出一些問題：
随着推廣活動的調整，統計和獎勵政策也随之變化，比如有的依據一度分享者的分享次數進行獎勵，有的依據一度、二度分享者帶來的浏覽量進行獎勵等等，還有需要根據上報的參數不同做不同的處理。所有邏輯都在上報的api請求中處理，來一個需求加一段邏輯，導緻該請求的功能不斷膨脹，而且一些推廣活動已經下線了，相關的邏輯也沒有清理掉。
參數比較混亂，頁面url中攜帶了不同的參數，包括微信相關參數、産品相關參數，前端上報時需要攜帶不同的參數，而前端頁面太多，經常搞錯。
<b>2. neo4j的嘗試</b>
于是，我們思考，有沒有可能在後端直接建構完整的傳播資訊，後期使用時直接根據條件就可以查詢出所需的資料，前端上報時也不用攜帶傳播鍊資訊，我們想到了圖形資料庫存儲技術。
圖形資料庫是一種非關系型資料庫，它應用圖形理論存儲實體之間的關系資訊。在文章開頭的那張傳播圖中，使用者的行為資料其實可以歸結為使用者與海報之間的關系資料，這樣，這個系統其實就包含兩種實體：使用者、海報，三種關系：使用者打開海報、使用者分享海報、使用者之間的傳播。在諸多圖形資料庫中，我們決定選擇比較成熟、文檔相對豐富的neo4j來做demo。采用neo4j的查詢文法，很簡單的就可以查詢出所需資料，簡單示例一下。
下圖呈現基于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誤判為二度分享。
雖然這些問題可以想辦法繞過去，比如根據時間建立不同的實體節點等等，但是這樣會把資料存儲做複雜化，經過權衡，我們暫時擱置了這個方案。
<b>3. 基于使用者行為資料采集系統的方案</b>
在創業公司如何做資料分析（三）使用者行為資料采集系統一文中，曾經提到早期的資料采集服務是分散在各個業務功能中的，後來我們重新建構了統一的使用者行為資料采集系統。在完成這個系統後，我們開始考慮将上述的微信分享追蹤系統并入其中，主要工作有：
資料上報的流程與早期的系統一緻，但是更換原有的上報方式，采用使用者行為資料采集系統的方案統一上報微信分享的資料;
資料接入kafka後，一方面直接将原始資料存儲到elasticsearch，另一方面，以worker的形式來消費資料，根據相應的業務需求提取出所需的資料存入格式化資料表中，用于統計和獎勵活動。當某個推廣活動結束後，将其所屬的worker停掉即可。
通過這樣的改進，我們暫時解決了前端上報混亂和後端業務邏輯膨脹的問題，将資料上報和業務需求隔離開。資料方面，實時資料流在kafka中，曆史資料也在elasticsearch中有存儲;業務需求方面，來了一個新的需求後，我們隻需添加一個新的worker來實作消費邏輯，活動結束後停掉worker。
<b>作者：mr-bruce來源：36大資料</b>
點選檢視：<b></b>
<a href="https://yq.aliyun.com/articles/73497" target="_blank">創業公司如何做資料分析（一）開篇</a>
<a href="https://yq.aliyun.com/articles/73618" target="_blank">創業公司如何做資料分析（二）營運資料系統</a>
<a href="https://yq.aliyun.com/articles/73671" target="_blank">創業公司如何做資料分析（三）使用者行為資料采集系統</a>
<a href="https://yq.aliyun.com/articles/73698" target="_blank">創業公司如何做資料分析（四）elk日志系統</a>
<a href="https://yq.aliyun.com/articles/73818" target="_blank">創業公司如何做資料分析（六）資料倉庫的建設</a>