一、解決方案

1. 埋點(diǎn)歷程

（1）無日志采集

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

（2）Log 1.0

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

（3）Log 2.0（未上線）

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

但當(dāng)時(shí)還面臨著兩個(gè)重大問題，其一是業(yè)務(wù)在迅速地發(fā)展，此時(shí)從底層推動(dòng)框架落地，即使是一個(gè)看似完美的框架，也會帶來巨大的投入成本；其二是各團(tuán)隊(duì)缺乏配合，埋點(diǎn)是一個(gè)廣泛的業(yè)務(wù)場景，基本上會涉及所有端團(tuán)隊(duì)。如果沒有團(tuán)隊(duì)配合，項(xiàng)目既難以落地，也無法獲得足夠的推動(dòng)資源。因此，最終該項(xiàng)目未能上線，數(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)行了大幅度簡化。其核心分為兩塊，一塊是事件，另一塊是參數(shù)。簡化的定義使 Log 3.0 更為靈活，且約束性更小。

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

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

2. 場景迭代

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

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

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

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

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

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

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

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

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

（1）用戶層面

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

（2）分析層面

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

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

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

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

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

二、解決方案

1. 總體框架

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

解決方案框架示意圖

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

2. 埋點(diǎn)管理

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

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

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

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

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

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

3. SDK 能力

（1）傳統(tǒng)長鏈路參數(shù)層層透傳的局限

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

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

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

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

（2）SDK的三大能力

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

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

例如，若要上報(bào)產(chǎn)品曝光內(nèi)容，調(diào)整 SDK 即可。SDK 會負(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)頁面。在信息從頁面 1 到頁面 2，再到頁面 N ，最終到提單頁的過程中，即使中間經(jīng)過了 N 個(gè)頁面，也無需擔(dān)心信息丟失。BTM Mode 會處理好信息傳遞的問題，確保信息能準(zhǔn)確無誤地到達(dá)提單頁。這樣一來，前端團(tuán)隊(duì)就不再過分依賴其他團(tuán)隊(duì)幫忙傳遞參數(shù)。

③整理鏈路、輸出歸因

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

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

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

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

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

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

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

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

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

（4）SDK 歸因處理

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

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

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

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

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

4. 歸因平臺

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

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

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

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

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

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

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

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

5. 分析產(chǎn)品

（1）頁面模塊分析

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

代碼示例

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

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

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

（2）路徑分析

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

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

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

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

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

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

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

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

收益總結(jié)

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