一、解決方案

1. 埋點(diǎn)歷程

（1）無(wú)日志采集

2013 年以前，抖音集團(tuán)自身不收集流量日志，而是依賴(lài)于外部工具做統(tǒng)計(jì)與流量數(shù)據(jù)分析。

（2）Log 1.0

2013 到 2016 年期間，開(kāi)始復(fù)用友*事件格式，自己做采集，主要是為了支撐推薦場(chǎng)景和圍繞推薦的分析場(chǎng)景。在這些場(chǎng)景下，流量的埋點(diǎn)主要用于構(gòu)建推薦系統(tǒng)，對(duì)數(shù)據(jù)分析的支持則較為有限。

（3）Log 2.0（未上線(xiàn)）

2015 到 2016 年期間，是業(yè)務(wù)的高速發(fā)展階段。除了推薦系統(tǒng)外，各種業(yè)務(wù)場(chǎng)景也陸續(xù)加入，引發(fā)了對(duì)分析歸因的需求。在這個(gè)過(guò)程中，埋點(diǎn)側(cè)嘗試使用 Log 2.0。Log 2.0 是從底層出發(fā)的框架升級(jí)，引入了統(tǒng)一的頁(yè)面標(biāo)識(shí)，并對(duì)其中所有模塊的傳遞方式進(jìn)行了強(qiáng)約束。

但當(dāng)時(shí)還面臨著兩個(gè)重大問(wèn)題，其一是業(yè)務(wù)在迅速地發(fā)展，此時(shí)從底層推動(dòng)框架落地，即使是一個(gè)看似完美的框架，也會(huì)帶來(lái)巨大的投入成本；其二是各團(tuán)隊(duì)缺乏配合，埋點(diǎn)是一個(gè)廣泛的業(yè)務(wù)場(chǎng)景，基本上會(huì)涉及所有端團(tuán)隊(duì)。如果沒(méi)有團(tuán)隊(duì)配合，項(xiàng)目既難以落地，也無(wú)法獲得足夠的推動(dòng)資源。因此，最終該項(xiàng)目未能上線(xiàn)，數(shù)據(jù)團(tuán)隊(duì)將其定義為一次失敗的經(jīng)歷。

（4）Log 3.0

2017 年至今，數(shù)據(jù)團(tuán)隊(duì)則一直處于 Log 3.0 狀態(tài)。Log 3.0 汲取了 Log 2.0 失敗的原因，進(jìn)行了大幅度簡(jiǎn)化。其核心分為兩塊，一塊是事件，另一塊是參數(shù)。簡(jiǎn)化的定義使 Log 3.0 更為靈活，且約束性更小。

底層的參數(shù)管理并未通過(guò)框架來(lái)實(shí)現(xiàn)，而是通過(guò)相應(yīng)的埋點(diǎn)平臺(tái)進(jìn)行。使用方可以在埋點(diǎn)平臺(tái)上注冊(cè)事件、約束參數(shù)，從而提高整體約束能力，實(shí)現(xiàn)更好的適配。在足夠靈活和適配的情況下，大家的切換成本就會(huì)降低。

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

2. 場(chǎng)景迭代

（1）從推薦信息流到綜合性生態(tài)

在一個(gè)綜合性 APP 的發(fā)展過(guò)程中，功能日益強(qiáng)大，內(nèi)容越發(fā)豐富。在其電商場(chǎng)景下，用戶(hù)操作路徑和鏈路的復(fù)雜度也逐步提升。

場(chǎng)景變化導(dǎo)致了用戶(hù)鏈路深度增加，鏈路復(fù)雜性提升，電商場(chǎng)景的用戶(hù)鏈路涉及到商城、搜索，而且在這個(gè)過(guò)程中還會(huì)有很多大促和營(yíng)銷(xiāo)活動(dòng)不斷推出新的頁(yè)面，迭代頻繁。

（2）變化引發(fā)的問(wèn)題

在場(chǎng)景迭代下，業(yè)務(wù)的分析訴求主要集中在整個(gè)流量場(chǎng)的承接轉(zhuǎn)化和交易的拆分歸因上，因此需要具備對(duì)應(yīng)的歸因能力。在 Log 3.0 時(shí)代，這種強(qiáng)烈的訴求導(dǎo)致了埋點(diǎn)的變化，即參數(shù)變得復(fù)雜，而整體長(zhǎng)鏈路的傳參訴求也隨之增多。

場(chǎng)景、分析訴求和埋點(diǎn)的三方面變化帶來(lái)了以下問(wèn)題：

• 質(zhì)量問(wèn)題開(kāi)始凸顯，漏傳、錯(cuò)傳現(xiàn)象頻繁發(fā)生，進(jìn)而引發(fā)線(xiàn)上事故；
• 歸因未知場(chǎng)景增多，業(yè)務(wù)分析困難；
• 維護(hù)成本高，埋點(diǎn)效率低下。

3. 電商業(yè)務(wù)痛點(diǎn)

在電商場(chǎng)景中，數(shù)據(jù)埋點(diǎn)遇到的問(wèn)題可大致歸為用戶(hù)、分析、工程和數(shù)據(jù)三個(gè)層面。

（1）用戶(hù)層面

埋點(diǎn)除了供給數(shù)據(jù)分析外，還可能對(duì)線(xiàn)上推薦產(chǎn)生影響。如果埋點(diǎn)參數(shù)錯(cuò)誤，則可能導(dǎo)致推薦相關(guān)鏈路的訂單交易下滑。此外在分傭場(chǎng)景中，如果未埋對(duì)參數(shù)，那么帶貨達(dá)人的利益收入將會(huì)降低，從而導(dǎo)致大量資損和客訴。

（2）分析層面

電商場(chǎng)景的歸因需要進(jìn)行拆分，例如，一筆訂單究竟是如何產(chǎn)生的？是商城帶來(lái)的，還是搜索帶來(lái)的？是某個(gè)活動(dòng)帶來(lái)的，還是某些轉(zhuǎn)化卡片帶來(lái)的？

在進(jìn)行拆分后，還需要進(jìn)行靈活的歸因分析，這類(lèi)似于路過(guò)原則的分析。通過(guò)這些分析，我們的數(shù)據(jù)現(xiàn)狀暴露出“未知”情況越來(lái)越多的問(wèn)題，即當(dāng)前的規(guī)則無(wú)法識(shí)別這筆訂單是由哪個(gè)來(lái)源所帶來(lái)的。

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

（3）工程和數(shù)據(jù)層面

工程和數(shù)據(jù)層面的主要問(wèn)題在于，整體維護(hù)成本很高，埋點(diǎn)流程效率很低下，新增參數(shù)所涉及到的前端團(tuán)隊(duì)會(huì)越來(lái)越多。例如，增加一個(gè)埋點(diǎn)，以期在交易上識(shí)別由搜索新增場(chǎng)景帶來(lái)的影響。那么搜索的前端同學(xué)就需要進(jìn)行埋點(diǎn)，而商詳?shù)那岸送瑢W(xué)和交易鏈路的同學(xué)也都需要介入，由此導(dǎo)致整體成本和迭代效率低。

二、解決方案

1. 總體框架

在從 Log 1.0 迭代到 3.0 的變化背景下，電商數(shù)據(jù)團(tuán)隊(duì)針對(duì)前述問(wèn)題，構(gòu)建了一套解決方案。

解決方案框架示意圖

• 埋點(diǎn)管理
  解決方案框架的底層主要是管理埋點(diǎn)，并通過(guò) BTM 和 BCM 的定義來(lái)建立規(guī)范，確保相關(guān)信息的透出能夠得到充分約束，還會(huì)針對(duì)一些關(guān)鍵事件，如頁(yè)面訪(fǎng)問(wèn)和商品曝光點(diǎn)擊信息等進(jìn)行優(yōu)化，然后將其輸出到 SDK 中。
• SDK
  多個(gè)前端團(tuán)隊(duì)協(xié)同合作，其實(shí)并不是實(shí)現(xiàn)目標(biāo)的可靠方式。因?yàn)閰⑴c者越多，不可控性就越高。因此引入了通用化能力，選擇以 SDK 來(lái)簡(jiǎn)化這部分的實(shí)施過(guò)程。
• 歸因平臺(tái)
  實(shí)際上，在抖音集團(tuán)內(nèi)部的工程團(tuán)隊(duì)、分析師團(tuán)隊(duì)、策略團(tuán)隊(duì)和數(shù)據(jù)團(tuán)隊(duì)的協(xié)作過(guò)程中，經(jīng)常會(huì)出現(xiàn)信息遺漏和關(guān)鍵迭代無(wú)法同步的問(wèn)題，此時(shí)，會(huì)通過(guò)歸因平臺(tái)來(lái)解決這些問(wèn)題。
• 分析產(chǎn)品
  框架的最上層原本由行為分析平臺(tái)提供支持，但針對(duì)電商埋點(diǎn)升級(jí)的情況，可以利用新定義的 BTM、BCM 和 SDK 的鏈路生成能力，提供更簡(jiǎn)化的分析，降低用戶(hù)的分析和操作門(mén)檻。

2. 埋點(diǎn)管理

埋點(diǎn)管理分為 BTM 和 BCM，BTM 參考了 SPM（Swift Package Manager） 的概念進(jìn)行設(shè)計(jì)，而 SPM 則由業(yè)務(wù)、頁(yè)面、區(qū)塊、坑位這四個(gè)點(diǎn)位組成。

來(lái)看一個(gè)例子：btm:a5425.b8692.c2154.d8060，其中的 a5425 代表一個(gè)電商的點(diǎn)位，b8692 是個(gè)人頁(yè)的信息，c2154 是訂單模塊，d8060 是待評(píng)價(jià)的按鈕。通過(guò)這些點(diǎn)位信息，我們就能夠清楚地描述出整個(gè)頁(yè)面上的固定位置信息。

BCM 希望能夠統(tǒng)一關(guān)鍵信息，關(guān)鍵信息主要指的是數(shù)倉(cāng)中的維度信息，如 product_id、shop_id、author_id、promotion_id 等。這一行為的核心目的是避免關(guān)鍵參數(shù)的同義不同名表達(dá)，類(lèi)似于在數(shù)據(jù)表中進(jìn)行維度命名的統(tǒng)一。通過(guò)統(tǒng)一關(guān)鍵參數(shù)的命名，我們能夠在全局范圍內(nèi)收斂核心關(guān)注點(diǎn)，降低理解和處理關(guān)鍵信息的成本。

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

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

上述的一切雜亂問(wèn)題，要求我們統(tǒng)一事件名稱(chēng)；將整體參數(shù)從雜亂變?yōu)橛行?；統(tǒng)一整體發(fā)送時(shí)機(jī)；并治理整體商品曝光。這些操作聽(tīng)上去自然而然，但如何實(shí)現(xiàn)輕量化，避免過(guò)多前端團(tuán)隊(duì)的高投入，就涉及到 SDK 能力。

3. SDK 能力

（1）傳統(tǒng)長(zhǎng)鏈路參數(shù)層層透?jìng)鞯木窒?/span>

傳統(tǒng)的參數(shù)傳遞方式是通過(guò) URL 一層一層向下傳遞的。

例如，在頁(yè)面 1 調(diào)用頁(yè)面 2 時(shí)，會(huì)在 URL 中拼接一些參數(shù)。頁(yè)面 2 的同學(xué)再調(diào)用頁(yè)面 N ，將這些參數(shù)一層一層向下傳遞，最終傳遞到提單頁(yè)。提單頁(yè)將這些信息導(dǎo)入訂單后，埋點(diǎn)側(cè)就能夠識(shí)別一筆訂單的來(lái)源。

然而，在電商場(chǎng)景中，這種長(zhǎng)鏈路可能導(dǎo)致新問(wèn)題隨新頁(yè)面增加而產(chǎn)生。如果某個(gè)頁(yè)面沒(méi)有傳遞參數(shù)，就會(huì)變成一個(gè)未知問(wèn)題。如果傳遞的參數(shù)被覆蓋，就會(huì)導(dǎo)致歸因混亂，增加了查問(wèn)題的難度。

SDK 能夠統(tǒng)一處理鏈路信息，其底層是 BTM Mode，其核心作用是將頁(yè)面之間的層級(jí)通信轉(zhuǎn)化為 BTM Mode 之間的信息傳遞。具體來(lái)說(shuō)，頁(yè)面 1 和頁(yè)面 2 不再直接相互通信，而是將通信內(nèi)容告知 BTM Mode，由 BTM Mode 來(lái)組織和傳遞這些信息。

（2）SDK的三大能力

從整個(gè)框架的角度來(lái)看，SDK 具備以下三大能力。

①關(guān)鍵事件處理

例如，若要上報(bào)產(chǎn)品曝光內(nèi)容，調(diào)整 SDK 即可。SDK 會(huì)負(fù)責(zé)將產(chǎn)品曝光的所有內(nèi)容進(jìn)行上報(bào)。同時(shí)，SDK 還具備實(shí)現(xiàn)各種約束的能力，SDK 能夠?qū)Α笆状纹毓馍蠄?bào)，還是上報(bào)單位體積內(nèi)的曝光次數(shù)”等內(nèi)容進(jìn)行整體約束處理。

②串聯(lián)鏈路、整合參數(shù)

SDK 具備串聯(lián)鏈路和整合參數(shù)的能力。BTM Mode 能獲知并將整個(gè)鏈路上的參數(shù)層層傳遞，最終將所需信息提供給相關(guān)頁(yè)面。在信息從頁(yè)面 1 到頁(yè)面 2，再到頁(yè)面 N ，最終到提單頁(yè)的過(guò)程中，即使中間經(jīng)過(guò)了 N 個(gè)頁(yè)面，也無(wú)需擔(dān)心信息丟失。BTM Mode 會(huì)處理好信息傳遞的問(wèn)題，確保信息能準(zhǔn)確無(wú)誤地到達(dá)提單頁(yè)。這樣一來(lái)，前端團(tuán)隊(duì)就不再過(guò)分依賴(lài)其他團(tuán)隊(duì)幫忙傳遞參數(shù)。

③整理鏈路、輸出歸因

舉例而言，在頁(yè)面 2 和頁(yè)面 3 都想為訂單打上標(biāo)記的情況下，在過(guò)去，頁(yè)面 3 的標(biāo)記可能會(huì)覆蓋頁(yè)面 2 的標(biāo)記，導(dǎo)致頁(yè)面 2 的歸因出現(xiàn)問(wèn)題。

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

（3）SDK 統(tǒng)一處理鏈路信息

如何理解不同用戶(hù)的操作鏈路？先以 PC 端瀏覽器這一比較復(fù)雜的程序?yàn)槔?，?dāng)用戶(hù)打開(kāi)一個(gè)網(wǎng)站首頁(yè)時(shí)，可能看到一個(gè)感興趣的視頻。用戶(hù)可以點(diǎn)擊進(jìn)入這個(gè)視頻頁(yè)面，也可以右鍵新開(kāi)一個(gè)窗口。在新開(kāi)窗口后，用戶(hù)還可以回到之前的窗口繼續(xù)瀏覽。

在這個(gè)過(guò)程中，用戶(hù)操作路徑是不可控的，埋點(diǎn)側(cè)無(wú)法知道用戶(hù)當(dāng)前聚焦在哪個(gè)頁(yè)面，以及從哪個(gè)頁(yè)面發(fā)起新的頁(yè)面操作。對(duì)于用戶(hù)在不同使用場(chǎng)景的操作鏈路，會(huì)進(jìn)行抽象處理。

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

通過(guò)這樣的抽象處理，可以發(fā)現(xiàn)其中一個(gè)關(guān)鍵內(nèi)容，即每個(gè)節(jié)點(diǎn)都要與 SDK 交互，而 SDK 能夠通過(guò)處理獲取它的訪(fǎng)問(wèn)路徑，以及根據(jù)規(guī)則處理過(guò)程中 BCM 的傳遞更新。

在 SDK 中使用任意一個(gè)節(jié)點(diǎn)進(jìn)行調(diào)試，都可以發(fā)現(xiàn)節(jié)點(diǎn)的來(lái)源路徑。因?yàn)榍懊嬗?A 節(jié)點(diǎn)、C 節(jié)點(diǎn)的調(diào)用，所以當(dāng) E 節(jié)點(diǎn)進(jìn)行調(diào)用時(shí)，就可以知道可能的來(lái)源路徑是 ACE，也知道整體 ABDE 的路徑。

整體來(lái)看，通過(guò)對(duì)鏈路進(jìn)行數(shù)據(jù)格式的抽象，將其添加到隊(duì)列存儲(chǔ)數(shù)，并在 SDK 中存儲(chǔ)這些數(shù)據(jù)格式，從而最終實(shí)現(xiàn)了用戶(hù)路徑的還原。

（4）SDK 歸因處理

SDK 按照規(guī)則輸出歸因結(jié)果，適用于規(guī)則穩(wěn)定、通用性強(qiáng)的場(chǎng)景。電商場(chǎng)景會(huì)進(jìn)行體裁判斷，這個(gè)判斷主要是用來(lái)確定一筆訂單是由直播、短視頻還是貨架場(chǎng)的商品卡帶來(lái)的，以上三個(gè)題材也是電商場(chǎng)景的主要關(guān)注點(diǎn)。

這是一個(gè)固定的規(guī)則，適用于任何場(chǎng)景?；谶@個(gè)規(guī)則，我們可以通過(guò)用戶(hù)路徑，將規(guī)則的結(jié)果直接在 SDK 中進(jìn)行封裝處理，而不涉及數(shù)倉(cāng)加工。

SDK 能夠直接告知該筆訂單的具體類(lèi)型，這 SDK 較為重要的一項(xiàng)能力。這意味著它能夠輸出你所需的歸因結(jié)果，并對(duì)整個(gè)鏈路進(jìn)行相應(yīng)處理。但需要注意的是，SDK 處理規(guī)則最好保持相對(duì)穩(wěn)定，否則 SDK 處理規(guī)則可能需要頻繁變更或調(diào)整。

SDK 直接輸出用戶(hù)關(guān)鍵路徑信息，由數(shù)據(jù)側(cè)按照業(yè)務(wù)口徑加工歸因結(jié)果，這適用于調(diào)整頻繁、定制化強(qiáng)的場(chǎng)景。舉個(gè)例子，如果某個(gè)用戶(hù)的操作路徑非常復(fù)雜，SDK 會(huì)對(duì)其進(jìn)行裁剪，通過(guò)隊(duì)列或樹(shù)狀結(jié)構(gòu)，去掉閉環(huán)鏈路或不必要的返回鏈路，最終得到一個(gè)較為純粹的用戶(hù)訪(fǎng)問(wèn)路徑鏈路。

基于這樣的鏈路，數(shù)倉(cāng)就可以進(jìn)行歸因分析。無(wú)論是首次歸因、末次歸因、線(xiàn)性歸因還是 U 型歸因，只要提供相應(yīng)規(guī)則，都可以基于 SDK 給出的完整用戶(hù)路徑進(jìn)行加工，而無(wú)需考慮關(guān)聯(lián)或頁(yè)面推導(dǎo)成本。

4. 歸因平臺(tái)

（1）歸因平臺(tái)的構(gòu)建原因

歸因平臺(tái)目前仍處于落地過(guò)程中，下文主要對(duì)當(dāng)前較為明確的方向進(jìn)行闡述。

首先，要明確構(gòu)建歸因平臺(tái)的原因，這主要是為了解決以下兩個(gè)問(wèn)題：

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

基于以上兩個(gè)問(wèn)題的解決訴求，電商數(shù)據(jù)團(tuán)隊(duì)正在構(gòu)建歸因平臺(tái)。在埋點(diǎn)平臺(tái)上，將進(jìn)行點(diǎn)位信息的新增和變更。由于 BTM 和 BCM 的框架限制，埋點(diǎn)側(cè)希望這些點(diǎn)位信息的新增和變更能夠同步到整個(gè)歸因平臺(tái)。

（2）歸因平臺(tái)的核心要素

歸因平臺(tái)主要通過(guò) 3 個(gè)核心要素來(lái)解決整體的歸因問(wèn)題。

• 標(biāo)簽化
  對(duì)于新增的點(diǎn)位，需要確定它的性質(zhì)。如果在業(yè)務(wù)層面上不涉及任何歸因，那么它可能只是一個(gè)路過(guò)頁(yè)。歸因平臺(tái)會(huì)提供豐富的標(biāo)簽，為這個(gè)點(diǎn)位打上合適的標(biāo)識(shí)，比如入口頁(yè)或末次歸因等。
• 對(duì)應(yīng)策略配置
  根據(jù)不同的頁(yè)面類(lèi)型，需要決定如何處理。例如，當(dāng)遇到一個(gè)入口頁(yè)時(shí)，是將其截?cái)啵€是根據(jù)其類(lèi)型定義相應(yīng)的業(yè)務(wù)邏輯，這可能涉及到因子數(shù)的配置。
• 生成對(duì)應(yīng)數(shù)據(jù)加工任務(wù)
  最后，將入倉(cāng)的硬編碼轉(zhuǎn)化為整個(gè)歸因平臺(tái)上的配置信息，然后通過(guò) UDF 管控進(jìn)行落實(shí)。

5. 分析產(chǎn)品

（1）頁(yè)面模塊分析

以下將提供一段代碼示例來(lái)說(shuō)明“如何基于新規(guī)則提供低操作成本的分析能力”。該示例類(lèi)似于訪(fǎng)問(wèn)事件集，可以根據(jù)這個(gè)訪(fǎng)問(wèn)事件集和 BTM 的命名信息（頁(yè)面、區(qū)塊、坑位），加工出一個(gè)模塊的效果數(shù)據(jù)，包括 PV 數(shù)據(jù)、UV 數(shù)據(jù)、停留時(shí)長(zhǎng)數(shù)據(jù)和頁(yè)面流失率等。

代碼示例

其核心能力可分為 3 個(gè)部分：

• 首先將訪(fǎng)問(wèn)明細(xì)表進(jìn)行拆分，通過(guò) A 點(diǎn)位就能夠獲取到頁(yè)面力度的基本信息和站點(diǎn)信息；
• 框選到 B 點(diǎn)位時(shí)，可以獲取頁(yè)面信息；
• 框選到 C 點(diǎn)位時(shí)，可以獲取模塊信息。

這個(gè)簡(jiǎn)化能力在原有的行為分析平臺(tái)上是缺失的，產(chǎn)品相當(dāng)于將其補(bǔ)充完整了。

（2）路徑分析

前文提到，SDK 可以處理一些復(fù)雜鏈路的最終輸出，那么如何對(duì)復(fù)雜鏈路進(jìn)行路徑分析呢？以“XXXSXXXXSXXXE”這樣一個(gè)路徑過(guò)程為例，假設(shè)我們想找一個(gè)以 S 開(kāi)頭、以 E 結(jié)尾的路徑段，我們應(yīng)該如何去截取呢？這其實(shí)比較復(fù)雜。

下面提供了一個(gè)案例，對(duì)于許多這類(lèi)相似路徑，如何進(jìn)行解體和管理是不可控的。正由于用戶(hù)的訪(fǎng)問(wèn)動(dòng)線(xiàn)不可控，埋點(diǎn)側(cè)需要進(jìn)行信息收斂，以確保最終輸出的數(shù)據(jù)相對(duì)結(jié)構(gòu)化。

這里存在一個(gè)完整的處理過(guò)程，首先找到所有的終點(diǎn)（E 點(diǎn)），然后找出所有的起點(diǎn)（S 點(diǎn)），再找出所有 E 節(jié)點(diǎn)中最近的 S 節(jié)點(diǎn)。

接著通過(guò)反向查找，將找到的起點(diǎn)和終點(diǎn)進(jìn)行匹配，確保每個(gè)起點(diǎn)都能與終點(diǎn)一一對(duì)應(yīng)。這其中會(huì)涉及到一些解析過(guò)程，也就是用戶(hù)路徑收斂的過(guò)程。最終，將得到一個(gè)簡(jiǎn)化后的用戶(hù)路徑。

然后，基于簡(jiǎn)化后的用戶(hù)路徑，可以通過(guò)樹(shù)形結(jié)構(gòu)進(jìn)行反饋。將第 1 到第 4 個(gè)節(jié)點(diǎn)視為根節(jié)點(diǎn)，第 5 到第 8 個(gè)節(jié)點(diǎn)為一級(jí)節(jié)點(diǎn)，第 9 到第 12 個(gè)節(jié)點(diǎn)為三級(jí)節(jié)點(diǎn)。通過(guò)節(jié)點(diǎn)整合，能夠?qū)⒂脩?hù)路徑進(jìn)行抽象，從而明確起點(diǎn)和終點(diǎn)，進(jìn)行分析。

根據(jù)強(qiáng)大的聚合能力，可以得知可能有多少用戶(hù)是通過(guò)什么路徑進(jìn)入訂單頁(yè)面的，例如可能有 50% 的用戶(hù)是從商城進(jìn)入商品詳情頁(yè)面，然后提交訂單，這種路徑分析能力有助于產(chǎn)品規(guī)劃。

此外，產(chǎn)品能力可支持通過(guò)點(diǎn)擊一個(gè)路徑來(lái)查看具體的用戶(hù)信息，以及他們?cè)诤畏N設(shè)備或情境下訪(fǎng)問(wèn)該路徑。同時(shí)，也支持用戶(hù)屬性篩選或頁(yè)面篩選，以協(xié)助信息整合。

三、總結(jié)規(guī)劃

收益總結(jié)

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