一、解決方案

1. 埋點歷程

（1）無日志采集

2013 年以前，抖音集團自身不收集流量日志，而是依賴于外部工具做統計與流量數據分析。

（2）Log 1.0

2013 到 2016 年期間，開始復用友*事件格式，自己做采集，主要是為了支撐推薦場景和圍繞推薦的分析場景。在這些場景下，流量的埋點主要用于構建推薦系統，對數據分析的支持則較為有限。

（3）Log 2.0（未上線）

2015 到 2016 年期間，是業務的高速發展階段。除了推薦系統外，各種業務場景也陸續加入，引發了對分析歸因的需求。在這個過程中，埋點側嘗試使用 Log 2.0。Log 2.0 是從底層出發的框架升級，引入了統一的頁面標識，并對其中所有模塊的傳遞方式進行了強約束。

但當時還面臨著兩個重大問題，其一是業務在迅速地發展，此時從底層推動框架落地，即使是一個看似完美的框架，也會帶來巨大的投入成本；其二是各團隊缺乏配合，埋點是一個廣泛的業務場景，基本上會涉及所有端團隊。如果沒有團隊配合，項目既難以落地，也無法獲得足夠的推動資源。因此，最終該項目未能上線，數據團隊將其定義為一次失敗的經歷。

（4）Log 3.0

2017 年至今，數據團隊則一直處于 Log 3.0 狀態。Log 3.0 汲取了 Log 2.0 失敗的原因，進行了大幅度簡化。其核心分為兩塊，一塊是事件，另一塊是參數。簡化的定義使 Log 3.0 更為靈活，且約束性更小。

底層的參數管理并未通過框架來實現，而是通過相應的埋點平臺進行。使用方可以在埋點平臺上注冊事件、約束參數，從而提高整體約束能力，實現更好的適配。在足夠靈活和適配的情況下，大家的切換成本就會降低。

舊的 Log 1.0 在這個足夠靈活的版本中完全兼容。此外還可以通過埋點平臺對后續新增的埋點進行管理。在此階段，除了底層的埋點平臺的約束外，還有適配的行為分析平臺來形成一整套解決方案，提供從管理到分析的所有流量日志相關能力。

2. 場景迭代

（1）從推薦信息流到綜合性生態

在一個綜合性 APP 的發展過程中，功能日益強大，內容越發豐富。在其電商場景下，用戶操作路徑和鏈路的復雜度也逐步提升。

場景變化導致了用戶鏈路深度增加，鏈路復雜性提升，電商場景的用戶鏈路涉及到商城、搜索，而且在這個過程中還會有很多大促和營銷活動不斷推出新的頁面，迭代頻繁。

（2）變化引發的問題

在場景迭代下，業務的分析訴求主要集中在整個流量場的承接轉化和交易的拆分歸因上，因此需要具備對應的歸因能力。在 Log 3.0 時代，這種強烈的訴求導致了埋點的變化，即參數變得復雜，而整體長鏈路的傳參訴求也隨之增多。

場景、分析訴求和埋點的三方面變化帶來了以下問題：

• 質量問題開始凸顯，漏傳、錯傳現象頻繁發生，進而引發線上事故；
• 歸因未知場景增多，業務分析困難；
• 維護成本高，埋點效率低下。

3. 電商業務痛點

在電商場景中，數據埋點遇到的問題可大致歸為用戶、分析、工程和數據三個層面。

（1）用戶層面

埋點除了供給數據分析外，還可能對線上推薦產生影響。如果埋點參數錯誤，則可能導致推薦相關鏈路的訂單交易下滑。此外在分傭場景中，如果未埋對參數，那么帶貨達人的利益收入將會降低，從而導致大量資損和客訴。

（2）分析層面

電商場景的歸因需要進行拆分，例如，一筆訂單究竟是如何產生的？是商城帶來的，還是搜索帶來的？是某個活動帶來的，還是某些轉化卡片帶來的？

在進行拆分后，還需要進行靈活的歸因分析，這類似于路過原則的分析。通過這些分析，我們的數據現狀暴露出“未知”情況越來越多的問題，即當前的規則無法識別這筆訂單是由哪個來源所帶來的。

如果“未知”占比在 1% 以下，則可以先忽略，但這個占比可能會逐漸增加到 5%、7%。那么這種模糊不清的情況將給業務帶來痛點，最終影響業務的分析和決策。

（3）工程和數據層面

工程和數據層面的主要問題在于，整體維護成本很高，埋點流程效率很低下，新增參數所涉及到的前端團隊會越來越多。例如，增加一個埋點，以期在交易上識別由搜索新增場景帶來的影響。那么搜索的前端同學就需要進行埋點，而商詳的前端同學和交易鏈路的同學也都需要介入，由此導致整體成本和迭代效率低。

二、解決方案

1. 總體框架

在從 Log 1.0 迭代到 3.0 的變化背景下，電商數據團隊針對前述問題，構建了一套解決方案。

解決方案框架示意圖

• 埋點管理
  解決方案框架的底層主要是管理埋點，并通過 BTM 和 BCM 的定義來建立規范，確保相關信息的透出能夠得到充分約束，還會針對一些關鍵事件，如頁面訪問和商品曝光點擊信息等進行優化，然后將其輸出到 SDK 中。
• SDK
  多個前端團隊協同合作，其實并不是實現目標的可靠方式。因為參與者越多，不可控性就越高。因此引入了通用化能力，選擇以 SDK 來簡化這部分的實施過程。
• 歸因平臺
  實際上，在抖音集團內部的工程團隊、分析師團隊、策略團隊和數據團隊的協作過程中，經常會出現信息遺漏和關鍵迭代無法同步的問題，此時，會通過歸因平臺來解決這些問題。
• 分析產品
  框架的最上層原本由行為分析平臺提供支持，但針對電商埋點升級的情況，可以利用新定義的 BTM、BCM 和 SDK 的鏈路生成能力，提供更簡化的分析，降低用戶的分析和操作門檻。

2. 埋點管理

埋點管理分為 BTM 和 BCM，BTM 參考了 SPM（Swift Package Manager） 的概念進行設計，而 SPM 則由業務、頁面、區塊、坑位這四個點位組成。

來看一個例子：btm:a5425.b8692.c2154.d8060，其中的 a5425 代表一個電商的點位，b8692 是個人頁的信息，c2154 是訂單模塊，d8060 是待評價的按鈕。通過這些點位信息，我們就能夠清楚地描述出整個頁面上的固定位置信息。

BCM 希望能夠統一關鍵信息，關鍵信息主要指的是數倉中的維度信息，如 product_id、shop_id、author_id、promotion_id 等。這一行為的核心目的是避免關鍵參數的同義不同名表達，類似于在數據表中進行維度命名的統一。通過統一關鍵參數的命名，我們能夠在全局范圍內收斂核心關注點，降低理解和處理關鍵信息的成本。

這一套定義和約束即作為我們的治理基礎，用以解決商品曝光的下列問題。

• 事件名稱不統一
  Log 3.0 是一個事件加參數框架，其下有大量的事件發生。以商品曝光事件為例，該通常命名為 show_product，而搜索前端團隊則的埋點則命名為 search_result_show。電商團隊購買商品卡時，會命名為 show_ecom_card。
  由于不同的前端團隊以及其自身的架構層面不屬于同一架構下，存在理解不統一、規范不統一的問題，造成了很高的事件處理成本。此外，重復發送事件也會帶來額外的成本。
• 事件參數雜亂
  事件參數雜亂的主要原因是命名規則不一致。比如，搜索、猜你喜歡、商業化等各業務都會獨立設計參數傳遞方案，盡管有時大家的訴求是一致的，但由于規則不統一，仍然需要重復開發，造成了額外的成本。
  那么，不一致的訴求會如何影響埋點呢？目前各團隊都是各自添加自己的埋點，導致整體埋點參數瘋狂膨脹。這不僅增加了傳輸成本，還可能導致用戶體驗卡頓。當卡頓達到一定程度時，就需要進行治理。此外，傳輸還會帶來數倉的存儲成本。在流量很大且參數很多的情況下，存儲成本會非常高。
• 發送時機不統一
  以商品曝光為例，來理解發生時機的不統一，即不同業務團隊對于商品曝光的上報有不同定義，到底是每次展示都上報，還是僅首次展示上報，亦或只要有加載就上報（虛曝光）？
  這就可能導致三種不同的上報邏輯。此外，上報的比例也可能不同，到底是展示 25%，還是 50%，亦或 100% 上報，也并未達成一致?？赡苊總€團隊的邏輯都不統一，而這種不統一在數據層上可能影響不大，但在業務層上就可能導致某些 AB 實驗或分析無法達到預期效果。

上述的一切雜亂問題，要求我們統一事件名稱；將整體參數從雜亂變為有序；統一整體發送時機；并治理整體商品曝光。這些操作聽上去自然而然，但如何實現輕量化，避免過多前端團隊的高投入，就涉及到 SDK 能力。

3. SDK 能力

（1）傳統長鏈路參數層層透傳的局限

傳統的參數傳遞方式是通過 URL 一層一層向下傳遞的。

例如，在頁面 1 調用頁面 2 時，會在 URL 中拼接一些參數。頁面 2 的同學再調用頁面 N ，將這些參數一層一層向下傳遞，最終傳遞到提單頁。提單頁將這些信息導入訂單后，埋點側就能夠識別一筆訂單的來源。

然而，在電商場景中，這種長鏈路可能導致新問題隨新頁面增加而產生。如果某個頁面沒有傳遞參數，就會變成一個未知問題。如果傳遞的參數被覆蓋，就會導致歸因混亂，增加了查問題的難度。

SDK 能夠統一處理鏈路信息，其底層是 BTM Mode，其核心作用是將頁面之間的層級通信轉化為 BTM Mode 之間的信息傳遞。具體來說，頁面 1 和頁面 2 不再直接相互通信，而是將通信內容告知 BTM Mode，由 BTM Mode 來組織和傳遞這些信息。

（2）SDK的三大能力

從整個框架的角度來看，SDK 具備以下三大能力。

①關鍵事件處理

例如，若要上報產品曝光內容，調整 SDK 即可。SDK 會負責將產品曝光的所有內容進行上報。同時，SDK 還具備實現各種約束的能力，SDK 能夠對“首次曝光上報，還是上報單位體積內的曝光次數”等內容進行整體約束處理。

②串聯鏈路、整合參數

SDK 具備串聯鏈路和整合參數的能力。BTM Mode 能獲知并將整個鏈路上的參數層層傳遞，最終將所需信息提供給相關頁面。在信息從頁面 1 到頁面 2，再到頁面 N ，最終到提單頁的過程中，即使中間經過了 N 個頁面，也無需擔心信息丟失。BTM Mode 會處理好信息傳遞的問題，確保信息能準確無誤地到達提單頁。這樣一來，前端團隊就不再過分依賴其他團隊幫忙傳遞參數。

③整理鏈路、輸出歸因

舉例而言，在頁面 2 和頁面 3 都想為訂單打上標記的情況下，在過去，頁面 3 的標記可能會覆蓋頁面 2 的標記，導致頁面 2 的歸因出現問題。

但現在，SDK 可以處理并得出所需的結果。即假設提單入口在頁面 2，那么最終的提單頁面在頁面 3，SDK 能夠整理并輸出這樣的歸因結論。

（3）SDK 統一處理鏈路信息

如何理解不同用戶的操作鏈路？先以 PC 端瀏覽器這一比較復雜的程序為例，當用戶打開一個網站首頁時，可能看到一個感興趣的視頻。用戶可以點擊進入這個視頻頁面，也可以右鍵新開一個窗口。在新開窗口后，用戶還可以回到之前的窗口繼續瀏覽。

在這個過程中，用戶操作路徑是不可控的，埋點側無法知道用戶當前聚焦在哪個頁面，以及從哪個頁面發起新的頁面操作。對于用戶在不同使用場景的操作鏈路，會進行抽象處理。

• APP 動線抽象處理
  APP 相對 PC 來說比較簡單，一次只能顯示一個頁面，若要查看之前的頁面，則只能回退操作。由于用戶只能聚焦在一個頁面，可以將其理解為一個隊列的數據結構。用戶可能進入 A ，然后進入 B ，再返回 A ，然后進入 C ，進入 D，可以把它理解為一個簡單的進出原則，SDK 會處理這些進出信息。
• WAP & PC 抽象處理
  在抽象 WAP&PC 時，由于用戶可以多窗口操作，每個窗口也可以有自己的鏈路，所以用戶動線可以抽象為一棵“樹”的數據結構。用戶進入 A 后，可以打開一個新頁面 B，也可以在 A 上直接進入 C，然后回到這個 A 里面，可能去打開兩個不同的頁面。
  按照樹的結構，至少能夠有一個推導的過程。例如從 K1 路徑來看，經過了 A、B、D、E 四個節點，最后進入 K1。于是我們就無需糾結頁面關閉或重新加載的問題。在此情況下，我們可以將重新加載視為仍在當前頁，而非新頁面，從而簡化用戶的動線。

通過這樣的抽象處理，可以發現其中一個關鍵內容，即每個節點都要與 SDK 交互，而 SDK 能夠通過處理獲取它的訪問路徑，以及根據規則處理過程中 BCM 的傳遞更新。

在 SDK 中使用任意一個節點進行調試，都可以發現節點的來源路徑。因為前面有 A 節點、C 節點的調用，所以當 E 節點進行調用時，就可以知道可能的來源路徑是 ACE，也知道整體 ABDE 的路徑。

整體來看，通過對鏈路進行數據格式的抽象，將其添加到隊列存儲數，并在 SDK 中存儲這些數據格式，從而最終實現了用戶路徑的還原。

（4）SDK 歸因處理

SDK 按照規則輸出歸因結果，適用于規則穩定、通用性強的場景。電商場景會進行體裁判斷，這個判斷主要是用來確定一筆訂單是由直播、短視頻還是貨架場的商品卡帶來的，以上三個題材也是電商場景的主要關注點。

這是一個固定的規則，適用于任何場景。基于這個規則，我們可以通過用戶路徑，將規則的結果直接在 SDK 中進行封裝處理，而不涉及數倉加工。

SDK 能夠直接告知該筆訂單的具體類型，這 SDK 較為重要的一項能力。這意味著它能夠輸出你所需的歸因結果，并對整個鏈路進行相應處理。但需要注意的是，SDK 處理規則最好保持相對穩定，否則 SDK 處理規則可能需要頻繁變更或調整。

SDK 直接輸出用戶關鍵路徑信息，由數據側按照業務口徑加工歸因結果，這適用于調整頻繁、定制化強的場景。舉個例子，如果某個用戶的操作路徑非常復雜，SDK 會對其進行裁剪，通過隊列或樹狀結構，去掉閉環鏈路或不必要的返回鏈路，最終得到一個較為純粹的用戶訪問路徑鏈路。

基于這樣的鏈路，數倉就可以進行歸因分析。無論是首次歸因、末次歸因、線性歸因還是 U 型歸因，只要提供相應規則，都可以基于 SDK 給出的完整用戶路徑進行加工，而無需考慮關聯或頁面推導成本。

4. 歸因平臺

（1）歸因平臺的構建原因

歸因平臺目前仍處于落地過程中，下文主要對當前較為明確的方向進行闡述。

首先，要明確構建歸因平臺的原因，這主要是為了解決以下兩個問題：

• 產品的迭代影響歸因邏輯，歸因數據問題滯后。
  產品迭代會影響歸因邏輯，數據問題通常出現較晚。當前產品有許多策略，如調整用戶路徑結構、增加實驗等，但這些實驗往往無法及時同步到數據側處理。只有當需要查看數據時，才會發現并詢問數據缺失或錯誤的問題。
  這種后置問題會給數倉帶來很高的成本，一種情況是埋點遺漏，需要通過其他參數來彌補；另一種情況是雖然進行了埋點，但規則沒有更新，因此需要更新規則，并涉及數據回溯。電商擁有龐大的流量數據，問題發現得越晚，處理回溯的成本就會越高。下游鏈路有上萬個任務，我們需要決定是全部回溯還是只回溯其中一部分，這就會帶來巨大的成本，因此我們需要建立一個流程來評估和審批相關點位變更。
• 歸因策略只能靠文檔管理，口徑不易理解，問題難排查。
  在歸因的落地過程中，數據團隊發現很多歸因口徑只能通過文檔來管理。業務方通常會提供一份歸因說明文檔，這是一份業務層面的說明，并非代碼層面的說明。負責代碼編寫的同學可能會有自己的一套代碼化口徑理解，二者之間有時會出現無法對齊的情況。
  此外，當遇到問題時，工程師往往無法直接從文檔中查詢到答案，而只能去查看代碼，再層層分析數據，最終才能定位問題。因此從整體來看，我們希望有一套易于維護的歸因策略配置信息。

基于以上兩個問題的解決訴求，電商數據團隊正在構建歸因平臺。在埋點平臺上，將進行點位信息的新增和變更。由于 BTM 和 BCM 的框架限制，埋點側希望這些點位信息的新增和變更能夠同步到整個歸因平臺。

（2）歸因平臺的核心要素

歸因平臺主要通過 3 個核心要素來解決整體的歸因問題。

• 標簽化
  對于新增的點位，需要確定它的性質。如果在業務層面上不涉及任何歸因，那么它可能只是一個路過頁。歸因平臺會提供豐富的標簽，為這個點位打上合適的標識，比如入口頁或末次歸因等。
• 對應策略配置
  根據不同的頁面類型，需要決定如何處理。例如，當遇到一個入口頁時，是將其截斷，還是根據其類型定義相應的業務邏輯，這可能涉及到因子數的配置。
• 生成對應數據加工任務
  最后，將入倉的硬編碼轉化為整個歸因平臺上的配置信息，然后通過 UDF 管控進行落實。

5. 分析產品

（1）頁面模塊分析

以下將提供一段代碼示例來說明“如何基于新規則提供低操作成本的分析能力”。該示例類似于訪問事件集，可以根據這個訪問事件集和 BTM 的命名信息（頁面、區塊、坑位），加工出一個模塊的效果數據，包括 PV 數據、UV 數據、停留時長數據和頁面流失率等。

代碼示例

其核心能力可分為 3 個部分：

• 首先將訪問明細表進行拆分，通過 A 點位就能夠獲取到頁面力度的基本信息和站點信息；
• 框選到 B 點位時，可以獲取頁面信息；
• 框選到 C 點位時，可以獲取模塊信息。

這個簡化能力在原有的行為分析平臺上是缺失的，產品相當于將其補充完整了。

（2）路徑分析

前文提到，SDK 可以處理一些復雜鏈路的最終輸出，那么如何對復雜鏈路進行路徑分析呢？以“XXXSXXXXSXXXE”這樣一個路徑過程為例，假設我們想找一個以 S 開頭、以 E 結尾的路徑段，我們應該如何去截取呢？這其實比較復雜。

下面提供了一個案例，對于許多這類相似路徑，如何進行解體和管理是不可控的。正由于用戶的訪問動線不可控，埋點側需要進行信息收斂，以確保最終輸出的數據相對結構化。

這里存在一個完整的處理過程，首先找到所有的終點（E 點），然后找出所有的起點（S 點），再找出所有 E 節點中最近的 S 節點。

接著通過反向查找，將找到的起點和終點進行匹配，確保每個起點都能與終點一一對應。這其中會涉及到一些解析過程，也就是用戶路徑收斂的過程。最終，將得到一個簡化后的用戶路徑。

然后，基于簡化后的用戶路徑，可以通過樹形結構進行反饋。將第 1 到第 4 個節點視為根節點，第 5 到第 8 個節點為一級節點，第 9 到第 12 個節點為三級節點。通過節點整合，能夠將用戶路徑進行抽象，從而明確起點和終點，進行分析。

根據強大的聚合能力，可以得知可能有多少用戶是通過什么路徑進入訂單頁面的，例如可能有 50% 的用戶是從商城進入商品詳情頁面，然后提交訂單，這種路徑分析能力有助于產品規劃。

此外，產品能力可支持通過點擊一個路徑來查看具體的用戶信息，以及他們在何種設備或情境下訪問該路徑。同時，也支持用戶屬性篩選或頁面篩選，以協助信息整合。

三、總結規劃

收益總結

• 埋點質量提升
  在業務層，“其他”分類降低，無法歸類的數據控制在 0.X% 以下，與原數據規模（X%）相比，實現了大幅減少。由于埋點質量有保障，埋點所引起的線上事故大大減少，歸因系統的相對穩定性也得到提升。
• 開發效率提升
  歸因平臺目前還在落地階段，但在整個約束落地之后，分析師將通過該平臺，在口徑制定、端上埋點實施以及數倉加工等方面實現成本降低。
• 歸因能力提升
  過去，數據團隊根據業務需求，通過這些參數層層傳遞信息，最終生成訂單。但現在，相關數據團隊有能力提供各種歸因口徑的支持，這得益于還原用戶訪問路徑的能力。