上文分享了此次拼多多雙12案例的一些相關(guān)活動信息，包括業(yè)務(wù)的數(shù)據(jù)需求，以及埋點方面的基礎(chǔ)認(rèn)知?？梢詼毓室幌掳咐枨螅?a href="http://m.codemsi.com/pd/3270340.html" target="_blank" rel="noopener">埋點設(shè)計指南：拆解拼多多雙十二營銷活動（上）。那么本下文將針對之前分析的內(nèi)容，介紹如何從0到1搭建埋點設(shè)計方案，以及需要關(guān)注的一些埋點準(zhǔn)則（避坑）。

一、埋點設(shè)計——規(guī)范、鏈路設(shè)計

1.1 埋點拆解

回到最初的表格，梳理了一些業(yè)務(wù)的數(shù)據(jù)需求。但顯然，有些是不適合使用埋點方式采集統(tǒng)計的。就以“我的1212”為例，實際這個頁面很多功能是與“登錄”用戶綁定的。

所以后續(xù)分析，十分關(guān)聯(lián)實體賬戶的金額、交易筆數(shù)等需求，將不參與埋點設(shè)計。

1.2 埋點規(guī)范

既然開始設(shè)計埋點，就需要先建立規(guī)范。就好比需求文檔明確一些全局樣式一樣，埋點也需要定義一下規(guī)范。因為提交埋點需求、執(zhí)行埋點開發(fā)都是多人協(xié)同的，我們需要建立規(guī)范好便于管理維護。通常地，我們需要注意模塊分類、命名規(guī)范、具體定義等等，做這些是方便于管理，以及不同的人都能快速解讀。

• 版本記錄：主要是記錄文檔從建立到完成的過程，包括內(nèi)容、時間、操作者等，這個跟需求文檔一樣，好讓其他人知道這個過程的歷史變化；
• 模塊分類：一般埋點都會分模塊整理，因為項目一大，不同的業(yè)務(wù)就會獨立管理，這樣分工也更明確些。而分類的標(biāo)準(zhǔn)主要看團隊習(xí)慣或業(yè)務(wù)性質(zhì)，有些是基于整個鏈路做模塊分類，比如整個購買到支付路徑等。有些則基于前端頁面分類。
• 命名規(guī)范：一般埋點都是遵循一定的命名格式，這樣的好處除了便于管理之外，其次就是在大家后續(xù)進行數(shù)據(jù)統(tǒng)計分析的時候，能清楚了解對應(yīng)哪個位置，快速關(guān)聯(lián)起來。大多數(shù)埋點的命名都是不同的字符組成，中英文、數(shù)字或者特殊字符都可以，主要取決于業(yè)務(wù)習(xí)慣。但是在這里建議設(shè)定一些特殊的命名規(guī)則，比如0131&DDXY，這樣能夠僅限于少范圍人清楚里面的意思（即所謂波斯密碼），保證一定的安全性
• 狀態(tài)：即指當(dāng)前埋點的狀態(tài)，包括新增、刪除還是修改。因為隨著活動迭代，有些埋點已經(jīng)不需要了，可以進行刪除，而有些因為需求變更，就需要更改埋點的一些信息。
• 埋點定義：每個埋點都需要注明定義，這樣開發(fā)者才能知道你到底想如何埋點，畢竟僅從埋點名稱別人是不知道你想獲取哪些數(shù)據(jù)。所以這時候就需要定義這個埋點的行為是什么樣的，比如進入一個頁面，點擊某個按鈕等等；
• 平臺類型：由于前端平臺有多種，不是所有埋點都一樣的，所以就要基于IOS、安卓、H5等分類記錄，當(dāng)然也有完全按照獨立的表格文檔整理。
• 屬性/擴展字段：因為埋點不僅僅滿足某個用戶行為的獲取，也可以基于這個行為順帶獲取一些業(yè)務(wù)關(guān)注的數(shù)據(jù)，前提是能拿到，比如一個登錄用戶點擊首頁，除了埋一個點擊首頁的事件，還可以收集一個“userid“的參數(shù)，此時點擊的時候就會把當(dāng)前登錄用戶的賬號ID也上傳進去。這樣就可以知道，區(qū)分是哪些游客和登錄用戶在點擊首頁。
• 日期：就是每個埋點的最新時間，基于狀態(tài)的變化而定

1.3 埋點梳理

到了這里，就可以差不多進行埋點方面的輸出了，在這里仍舊按照業(yè)務(wù)需求分模塊一一來整理。

1.3.1 活動整體

首先，先從活動整體來做設(shè)計，因為這些涉及基礎(chǔ)指標(biāo)。

（1）活動用戶

在這里有個特征，就是特別區(qū)分了內(nèi)部和外部,目的主要是想?yún)^(qū)分多少是因為此次活動吸引APP游客/登錄用戶參與的，以及多少完全拉新進來。那么該如何統(tǒng)計區(qū)分呢，通常這時候埋點就可以設(shè)計“channelid”的屬性，本身活動頁面在平臺上線是個鏈接，通過鏈接配置一個“channelid=APP“，那么當(dāng)用戶觸發(fā)埋點時，則帶著這樣的標(biāo)識去統(tǒng)計。

（2）分享

可以關(guān)注到，整個活動的每個頁面都是有分享功能的，所以外部引流空間是很大。但是點擊分享，選擇渠道，完成分享，才是一個真正連貫的路徑操作，所以埋點就需要針對這幾個路徑進行埋點設(shè)計。

另外，由于有幾個的明確渠道（微信、QQ等）。通常情況針對這4個分享途徑，開發(fā)都會提前配置這個帶有渠道屬性的不同值，這樣分享出去的頁面，當(dāng)用戶打開，就可以知道是哪些渠道來源。像微信，就會配置成“https://pinduoduo……/channelid=weixin”，那么用戶分享出去就會一直帶有這個微信渠道標(biāo)識的鏈接，埋點就可以采集這樣的信息。

1.3.2 主會場

作為此次活動首頁也是最重要的頁面，其中涉及的需求會相對更多更關(guān)鍵。

（1）整體頁面

通常情況下，主模塊下的一級頁面都會做一個整體的數(shù)據(jù)分析，這時候關(guān)注頁面的PV和UV就十分關(guān)鍵。而這里值得注意的是，“主會場”頁面訪問有可能會存在比點擊底部tab更多，因為活動默認(rèn)進入的首頁即主會場，即用戶只要打開從一級入口進入則無論如何都會先曝光主會場。

（2）秒殺萬人團

萬人團的重要性這里不多說了，總之我們對于這塊的埋點設(shè)計就需要精細(xì)到諸多的可觸控埋點。

而這里分別展示了3個“入口”展示團購商品，而由于這些位置明確重要且有限可數(shù)，所以在埋點設(shè)計可以進行具體位置埋點，即進行第1、2、3號位埋點。為什么做這樣的設(shè)計呢。因為萬人團不同時間段展示的團購商品都是不同，這是無法預(yù)測的，所以如果埋點成“點擊耳機xx團購”，能埋得了1個埋不了第2個，所以干脆進行位置模塊形式埋點。

位置形式確定了，其次我們不妨再回想剛剛提及的內(nèi)容，這個位置很重要，轉(zhuǎn)化率極高，再聯(lián)系下業(yè)務(wù)對商品交易鏈路的關(guān)注需求，那么我們就很清楚，這里需要對用戶接下來操作的每個步驟（點擊、拼單、支付等）都有梳理逐一埋點，最終形成一個可轉(zhuǎn)化分析的漏斗型埋點路徑。

同時，我們也可以增加一些屬性類型，比如“product”、“price”等，了解用戶對哪些商品十分感興趣，對價格的敏感度有多高。

（3）品類頻道

這個模塊在主會場位于最后位置，且展示了此次參與雙12活動的全品類商品，所以各類商品的曝光、點擊和轉(zhuǎn)化等數(shù)據(jù)都是琢磨不定的。因為種類太多，曝光位置靠后，是否能觸達用戶、以及用戶能否從中快速篩選感興趣商品都無從得知。那么我們就可以對頁面的固定區(qū)域進行特殊埋點，以加強數(shù)據(jù)監(jiān)測。

所以在這里對用戶的瀏覽路徑做了埋點設(shè)計。主要從品類選項欄、停留區(qū)域、停留時長等方面做了特定條件的埋點定義。

在這里值得關(guān)注的是，為什么會增加了“停留時長”的限制，因為一般用戶滑動過程中，都多少會瀏覽到這些商品內(nèi)容，這是無效數(shù)據(jù)居多，只要用戶真正聚焦并停留一段時間，才真正代表感興趣，這才是有意義的曝光。

所以在這里進行停留時長的限制，只有滿足條件才算是真正的曝光。而至于如何界定時長的長度，則主要以業(yè)務(wù)和平臺用戶總體習(xí)慣為主，并沒有標(biāo)準(zhǔn)，1s也可以，10s都可以。

1.3.3 我的1212

這樣頁面接近于APP的個人中心頁，通常情況下反而是打開相對較少的頁面，除非發(fā)生購買交易，需要登錄或查看訂單之類的行為，基本是很少被用戶打開。另外，由于這里有登錄態(tài)和未登錄態(tài)，所以有些埋點是需要注意在登錄情況下才會發(fā)生的。

（1）登錄

還記得前面提及到用戶轉(zhuǎn)化鏈路的場景嗎？這里登錄模塊就十分關(guān)鍵了。因為這是整個埋點路徑中驗證目標(biāo)達成的最后一環(huán)。所以這里分別對一級頁面的“登錄點擊-登錄頁面訪問-成功登錄”做了關(guān)鍵鏈路埋點監(jiān)測。

同時還收集了用戶中途離開及登錄異常的兩種轉(zhuǎn)化失敗的情況，便于后續(xù)可以進行二次喚醒轉(zhuǎn)化，挽留流失用戶。

另外，這里還有一個關(guān)鍵的屬性“usertape”，主要是收集用戶注冊登錄的類型，并統(tǒng)計不同類型下的轉(zhuǎn)化表現(xiàn)。從此次活動可知，拼多多提供了3種方式，分別是微信、QQ、手機號。而微信和QQ由于是采用騰訊開放接口，獲取授權(quán)信息會多一些，比如性別、地域、昵稱等，這是便于做深度的用戶畫像。

（2）補貼金額

大多數(shù)情況下，在登錄態(tài)之后，有些與賬戶關(guān)聯(lián)的數(shù)據(jù)用后臺來記錄更為精準(zhǔn)，比如紅包個數(shù)、金額等等，因為領(lǐng)取了之后，但是用戶不曾在此頁面觸發(fā)任何埋點，是無法準(zhǔn)確獲取這些數(shù)據(jù)的。所以這樣的功能頁面，在埋點設(shè)計方面主要關(guān)注頁面的點擊和瀏覽情況。這些核心的數(shù)據(jù)需要借助后臺方面進行記錄。

但是因為后臺以用戶賬戶作為存儲對象的，那么又如何與埋點的設(shè)備賬戶關(guān)聯(lián)呢？這時候埋點中的一個屬性就很重要了，“userid”，當(dāng)假設(shè)用戶在登錄態(tài)，埋點設(shè)計了需要上傳該賬戶的userid，那么久可以知道這一系列的行為路徑不僅僅是這名設(shè)備用戶，還知道對應(yīng)上后臺記錄的“user用戶”

1.4 埋點準(zhǔn)則

我們在設(shè)計埋點的時候，多遵循一些原則，避免入坑。

• 注意渠道的來源追蹤，有效甄別用戶的轉(zhuǎn)化和質(zhì)量表現(xiàn)
• 反復(fù)測試驗證，避免遺留
• 業(yè)務(wù)導(dǎo)向為主，多與業(yè)務(wù)溝通，充分了解對平臺規(guī)則的使用
• 注意跨設(shè)備口徑的一致性，善用userid
• 不是所有埋點都需要埋，需要兼顧性能和價值等
• 利用好埋點屬性，可以進行更深度分析
• 模擬用戶行為路徑，去設(shè)計關(guān)鍵的核心埋點
• 埋點注意加密存儲，以密鑰方式進行上報
• 埋點只是數(shù)據(jù)采集的一種方式，需要結(jié)合多種技術(shù)特點協(xié)同實現(xiàn)
• 一般數(shù)據(jù)最終呈現(xiàn)BI報表，需要先在測試環(huán)境模擬是否符合業(yè)務(wù)需求，而不是以單個觸發(fā)點來驗證。
• 上產(chǎn)線后，數(shù)據(jù)持續(xù)跟蹤，發(fā)現(xiàn)并不理想或者不符合業(yè)務(wù)訴求，需要及時調(diào)優(yōu)更改方案

好了，一份基本的埋點方案差不多成型，剩下的就是交給研發(fā)去實現(xiàn)。

二、最后總結(jié)

1. 一份合格的埋點方案，需要結(jié)合業(yè)務(wù)訴求、產(chǎn)品技術(shù)能力、數(shù)據(jù)分析等方面綜合輸出，而不是單方面的想當(dāng)然；
2. 多建立核心用戶路徑模型，有利于快速搭建關(guān)鍵埋點，便于后續(xù)的數(shù)據(jù)分析工作；
3. 人無完人，再詳盡的方案也難免會有錯留，作為一名數(shù)據(jù)分析從業(yè)者，需要走進“用戶”，努力還原用戶的真實場景，這樣對埋點設(shè)計是有十分幫助的。
4. 以上只是一些基本的埋點方法，要想運用得十分到位，還需要結(jié)合業(yè)務(wù)場景的實際情況，制定更為復(fù)雜的方案。

關(guān)于埋點涉及的場景十分多，不同的場景有不同的埋點設(shè)計，以及需要關(guān)注如何達成業(yè)務(wù)需求。本文主要從通識性針對大眾場景去埋點設(shè)計，以此篇文章更適合于精細(xì)化運營的案例場景學(xué)習(xí)。

后續(xù)有機會分享更多埋點設(shè)計個案，包括流失挽留、渠道效果、產(chǎn)品迭代優(yōu)化等。

作者：A.D，數(shù)據(jù)產(chǎn)品一枚；公眾號：吾某

本文由 @A.D. 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。