作者：Crystal Widjaja
翻譯：殷之涵
校對：王可汗

本文約7700字，建議閱讀15+分鐘
本文將從作者的親身經歷循序漸進地帶你定位大多數事件分析出錯的根本原因并給出解決策略。??

一個好的事件跟蹤字典是什么樣的？

你的字典可能有一套和上述模板不同的字段。但這里提供幾個關鍵點，能使其成為一項能夠幫助團隊協同的良好資產。

1）簡單

字典至少得簡單、容易被理解。諸如明確的命名規(guī)則，這些是最基本的東西。但真正的考驗是，第一次進入公司的人能否通過事件追蹤器迅速將事件映射到他們在產品中的行動中去，而不需要閱讀每個事件的定義。

2）可操作性

事件追蹤器的商業(yè)用戶需要實現從表格到數據再到決策的過程，而這一過程不需要數據分析師的大量參與——很多時候這被稱為正確的全面性水平（comprehensiveness）。追蹤的事件太少，所收集信息的完整性不足以支持做出決策；追蹤的事件太多，則會讓人不知所措。

3）可視化

每一個被追蹤的事件都應該有屏幕截圖。雖然人們可以用很多不同的方式來解釋事件的名稱和描述，但視覺上的表現依舊非常重要。

1、商業(yè)用戶的心態(tài)

正如我前面提到的，大多數分析系統(tǒng)的終端用戶是商業(yè)用戶。我們需要建立一些能與這些終端用戶產生共鳴的東西，而這意味著將數據和分析過程變得更加人性化。這影響到我們如何選擇使用的工具、追蹤的事件、如何命名事件、以及需要什么樣的屬性。上述這些事項值得投入大量的時間，就像我們對一個新產品進行客戶研究一樣。

為了理解商業(yè)用戶的心態(tài)，我經歷了四個層次的問題。對于每個問題，我都提供了一些來自我最近合作的產品的例子，該產品名為Honeydu，提供能讓公司免費在線發(fā)送和接收發(fā)票的服務。

1. 業(yè)務目標是什么？

業(yè)務和執(zhí)行團隊正在優(yōu)化的關鍵結果和指標是什么？這些信息的來源是當前和歷史上的OKR、季度和年度規(guī)劃文件、以及董事會的文件。

例子一：到2020年第四季度末，有X個新用戶收到/發(fā)出發(fā)票。

例子二：向新用戶發(fā)送的發(fā)票中，有X%導致了新用戶的注冊。

例子三：到2020年第4季度末，有X張周期性發(fā)票呈現活躍狀態(tài)。

2. 每個團隊的目標是什么？

僅僅是公司層面的目標是不夠的。每個團隊通常都會有一套目標，層層遞進以達到公司層面的指標。為了了解這些目標，你可以尋找每個團隊的OKR、與團隊領導交談等。在這里，你既要了解歷史上不同時間段的目標，又要了解團隊領導對未來不同時期對目標的看法。

例子一：（新用戶增長）在前7天內發(fā)出2張發(fā)票。

例子二：（支付整合）85%的新增支付方式被成功驗證。

例子三：（NUX）新用戶中開始使用發(fā)票模板的百分比。

3. 圍繞這些目標的產品體驗是什么？

接下來，對于每個目標，我都會確認并驅動與這些目標相對應的產品體驗。重要的是，不僅要確定產品或預訂渠道的具體屏幕展示是什么，還要確定可能影響目標或行動體驗的背景。例如，在像Uber這樣的乘車共享產品中，如果產品體驗是預訂乘車，那么除了預訂乘車的渠道之外，我可能還想了解地圖上有多少司機、或者估計的時間是多少。

第一步：有很多不同的因素可能導致Honeydu用戶發(fā)送他們的第一張發(fā)票，這些因素就意味著我們的核心行動。我們會問自己以下問題：

當用戶選擇一個聯系人來發(fā)送發(fā)票時、當一個聯系人在用戶的歷史業(yè)務列表中可用時還是當他們需要搜索時，他們更有可能成功？

有哪些支持性的操作可以幫助用戶創(chuàng)建和發(fā)送他們的第一張發(fā)票？發(fā)票模板是加快寄送時間的好方法嗎?還是先導入他們的聯系人更重要？

第二步：下一步是思考那些可能阻礙用戶達到我們的目標的經驗。在Honeydu的案例中，我會問：為什么一個新用戶沒有成功創(chuàng)建他們的第一張發(fā)票？他們是否查看了不同的模板，卻沒有找到與自己相關的模板？他們是否嘗試從頭開始創(chuàng)建一個發(fā)票、卻發(fā)現回到我們的模板目錄太難了？我們的激活用戶進行了哪些非激活用戶無權執(zhí)行的操作？

第三步：最后，想象一下，任何事件都可能是我們在產品中跟蹤用戶的最后一個事件。我們想知道關于這次經歷的哪些內容？我們需要知道他們在搜索聯系人后是否出現了"無結果"的頁面，或者在添加新的支付方式時出現了錯誤，并根據這些事件的高發(fā)程度對用戶體驗中的問題進行分流。

4. 圍繞這些目標和產品體驗，我/他們可能想要回答的問題/假設是什么？

接下來，我思考他們（或我）圍繞這些目標可能存在哪些問題或假設。同樣，我們需要與團隊中的相關人員談談他們面臨哪些問題。但也要通過自己的思考提出問題的假設，并與該團隊驗證這些問題的重要程度。

例子一：Honeydu上的一個關鍵目標和產品體驗是用戶“首次發(fā)送發(fā)票”。我會問這樣一個問題，需要發(fā)生什么樣的體驗才能讓人愿意給企業(yè)發(fā)送發(fā)票？像"用戶需要用到一個行業(yè)標準模板"或“他們看到業(yè)務已經在Honeydu網絡中列出”這樣的假設，表明我們需要能夠被跟蹤的經驗，以便量化分析并將假設推廣至相關性/因果關系。

例子二：通過Honeydu付費的用戶越多，我們產生的收入就越多。我們應該跟蹤用戶在什么時候最可能支付發(fā)票，問自己 "用戶什么時候最可能通過Honeydu支付發(fā)票？當它今天或者明天到期時？" 通過追蹤“支付發(fā)票成功”這一事件的到期日剩余天數（daysTillDueDate）屬性，我們可以在不過度打擾用戶的前提下，為那些沒有注意到發(fā)票到期日的用戶提供推送通知和電子郵件提醒服務。

2、是旅程而不是指標

我在前文討論的關鍵之一是要在事件中達到正確的抽象水平，其基礎是追蹤旅程，而不是指標。

雖然我們使用第一步中提到的那些目標作為追蹤過程的輸入，但僅僅停在那里并不能避開糟糕的事件追蹤。糟糕的事件追蹤就好像一個人問自己 "我可以用這些指標來計算我所有的OKR嗎"，例如，#用戶點擊注冊，#完成訂單，注冊和完成之間的轉換。這樣做的問題是，它會帶我們走進死胡同——你只能知道"50%的用戶注冊了"，但卻無法知道為什么。

要回答 "為什么？"的問題，你首先需要了解旅程的意圖、其成功和失敗意味著什么，然后了解旅程中每個事件的背景（我們將在第三步用屬性來跟蹤）。

舉幾個簡單的例子來說明意圖→成功→失敗的事件歷程。

例子一：

意圖。選擇了新的付款方式和提交了新的付款細節(jié)。
成功。添加新的付款方式成功。
失敗。添加新的付款方式失敗。

例子二：

意圖：選擇創(chuàng)建發(fā)票 → 開始填寫新發(fā)票 → 搜索聯系人。
成功：收件人被添加到發(fā)票上 → 發(fā)送發(fā)票。
失?。喊l(fā)票草稿已保存（默認動作）。

2A-成功事件

我首先思考的是成功事件，一個成功事件是指產品中的一個動作已經成功完成，這些事件源于我在第一步收集的業(yè)務目標。成功事件的例子可能包括以下這些：

付款成功

注冊成功

發(fā)出發(fā)票

預訂完成

為了不過度追蹤所有的事情，我用一個問題對每個事件進行壓力測試。"如果我確實跟蹤了這個，而且99%的用戶都做了這個，我會怎么做？它能告訴我什么？" 如果我無法在上述這種極端的情況下找到可操作的東西，那么追蹤這個事件很可能是無益的。

2b-意圖事件

對于每一個成功的事件，我都會考慮到意圖事件。意圖事件通常是作為任何成功事件的前驅。跟蹤意圖事件對于理解事件成功的"原因"至關重要。

意圖事件告訴我，用戶是如何"被教育"和"被激勵"來完成我希望他們完成的行動的某個步驟的。每件事實際上都是其下一個事件的意圖事件——但我們往往只把它們當作 "目標"，這使我們無法準確地跟蹤它們。例如，在一個搭車應用中，選擇目的地是一個目標，但需要一個“選擇搭車類型”的意圖/設置事件（在舊的Lyft/Uber流程中）。然后，預訂實際的旅程成為目標，但需要從搜索/歷史中找到目的地的意圖/設置事件等。

為了找到意圖事件，我會問：為了完成成功事件，我必須完成哪些步驟？常見的例子如下：

在我們的第一個旅程例子中，我們注意到了"選擇添加新的付款方式"和"提交新的付款細節(jié)"的意圖事件。

請注意，我們在這里有兩個級別的意圖——高的意圖，即用戶主動提交他們的付款細節(jié)；以及低的、但具有指示性的意圖，即用戶正在選擇是否通過銀行或信用卡添加他們的支付詳情。這些事件之間的延遲會導致團隊采取可操作的后續(xù)步驟:用戶要么覺得要輸入的字段太多太麻煩，要么當時手頭上并沒有這些信息。我們既然知道他們是否選擇了銀行或信用卡支付方式，那么就可以提供更多的信息和個性化的內容，幫助用戶完成這一步驟。

我還使用 "意圖事件 "來確定用戶在完成一個動作時的自然路徑。例如，在我們的發(fā)票和賬單支付應用中，用戶是先導入聯系人，還是先創(chuàng)建并發(fā)送發(fā)票？隨著我們賬單支付網絡的發(fā)展，這種行為是如何變化的？

同樣，在Gojek的外賣產品中，早期時我們注意到最“成功”的用戶是那些已經知道他們想吃什么的人，他們來Gojek只是為了完成配送服務。這些用戶的意圖是搜索一個特定的餐館，找到他們想要的餐品，最后設置他們的收貨信息。然而，隨著這些用戶逐漸成熟，我們注意到最普遍的用戶意圖旅程發(fā)生了變化，用戶開始使用Gojek來探索新餐館，而不是僅僅滿足于他們已經知道的餐館?，F在的意圖事件是用戶瀏覽他們朋友的美食打卡/測評記錄和餐館折扣，或使用“附近”功能。

這些意圖事件對于理解Bangaly Kaba（Reforge EIR，Instagram前增長主管）所說的“相鄰用戶”至關重要。隨著用戶的成熟和市場的擴大，這些旅程會隨著時間的推移而演變，我們的產品實現也應該注重分別匹配新用戶和成熟用戶的意圖。

2c - 失敗事件

失敗事件是發(fā)生在意圖事件和成功事件之間的事情，它使用戶無法獲得“成功”。在意圖事件和成功事件之間，存在著一些用戶可能遇到的失敗路徑。理解失敗路徑對于理解成功路徑同樣重要，因為它們?yōu)槲覀兲峁┝岁P于如何改進成功事件的可操作信息。為了找出失敗事件，我會問自己：有哪些可能的事情會阻止用戶完成目標？有兩種類型的失敗事件，隱性失敗與顯性失敗。

隱性失敗是指在成功完成目標之前的放棄行為。用戶就這樣從我們的流程中 "消失 "了。在前文的例子二中，事件的跟蹤方式提供了兩個隱性失敗指標。

用戶如果執(zhí)行了 "選擇創(chuàng)建發(fā)票"，但沒有在5分鐘內執(zhí)行 "開始新發(fā)票"，表示激活過程中失敗。
用戶如果搜索了聯系人，但沒有在5分鐘內將收件人添加到發(fā)票中，表明我們的搜索結果或搜索歷史失敗。用戶可能覺得沒有足夠的動力去新建一個聯系人，或者沒看明白搜索結果。

顯性失敗是指預期體驗出錯的事件。

像Lyft的"Ride Cancelled"（取消行程）或在訂購食品快遞時的"Order Cancelled - Restaurant Closed"（取消訂單-餐館打烊）等事件都是明確失敗的例子。
在Honeydu中，"添加新的付款方式失敗 "和 "支付發(fā)票失敗 "是兩個事件的例子，它們經常在事件追蹤工作中被遺忘，因為它們是對用戶行為的反應，而不是在產品中采取的實際行動。然而，如果你的網絡/移動應用程序收到錯誤并顯示給你的用戶，這些應該很容易跟蹤和記錄，以便監(jiān)測。將這些錯誤響應信息存儲為事件屬性，是快速診斷用戶旅程突然失敗的原因的簡單方法。

3、屬性

一旦我們有了成功、意圖和失敗的事件，下一步就是弄清楚我們想要與事件相關聯的屬性。屬性是實現我們以下兩個主要目標的關鍵——“提供正確的抽象水平”和“使數據可操作”。

屬性的本質是我們分割事件的潛在方式。一個典型的錯誤是把“分割”作為一個事件本身來追蹤，例如：

好做法：選定的注冊（事件），來源（屬性），Facebook（屬性值）。
壞做法：選擇Facebook為注冊方式。

可以把你在第一步中發(fā)現的問題和假設作為起點，了解你可能需要跟蹤哪些屬性，例如：

問題：用戶更喜歡以什么樣的方式添加聯系人？

屬性舉例：來源→歷史/導入/手動輸入。

假設：新用戶更傾向于使用模板來入門，與選擇自定義發(fā)票的老用戶相比，他們需要更多的新手培訓才能充分利用發(fā)票工具。

屬性示例：模板名稱 → (null)/基礎發(fā)票模板/其他。

我喜歡問自己一些宏觀層面的問題來確定哪些才是重要的屬性：

我該如何區(qū)分那些失望和不感興趣的用戶？
我怎么才能識別成熟用戶與臨時用戶使用APP時的不同路徑？
這是否給了我足夠細致的數據來比較和對比成功用戶和掉線用戶?？
如果這是我從一個用戶那里追蹤到的最后一個事件，我想知道用戶在這個屏幕上的體驗是什么？

屬性往往會落入幾個常見的分桶中。為了確保這個流程沒有遺漏，我使用以下這些分桶來查看我是否遺漏了什么：

用戶檔案屬性

最常見的屬性集是那些與用戶基本情況有關的屬性。這可能是人口統(tǒng)計學或公司統(tǒng)計學信息，舉例如下：

城市
年齡
公司規(guī)模
職位
產品層級

通常情況下，上述這些屬性幾乎能夠永久地對用戶和事件進行細分（基礎信息通常很穩(wěn)定），直到屬性被改變。一些平臺（如Mixpanel）會包含一個“超級屬性”的功能，可以讓你輕松做到這一點，所以關鍵是要弄清楚哪些屬性需要被追蹤?？梢詥柸缦聠栴}：

如果我是這個用戶的個人助理，那么我需要了解他們的哪些偏好，以便為其提供幫助？
哪些人口統(tǒng)計信息可能會影響用戶的行為？

營銷屬性

第二組最常見的屬性是那些與營銷有關的屬性，可能會影響到或影響用戶的行為，例如：

來源
活動
進入頁面

用戶操作動屬性

另一組屬性是與用戶的操作有關的屬性，例如：

首次訂單日期。
首次服務類型。
總訂單數。

區(qū)分以下兩種類型的屬性很重要：

設置并忘記（Set and Forget）型屬性：這些屬性一經設置就不再改變。例如首次購買日期、首次注冊類型和出生日期。
附加/增加（Append/Increment）型屬性：這些是你用來細分和創(chuàng)建相關的、個性化的用戶體驗的屬性，如總購買量、總收入等。添加（和刪除）用戶屬性可以讓團隊快速識別相關用戶的促銷活動、信息更新，以及他們已經表示感興趣的體驗。具體地，例如已消費餐廳的列表(外賣)、喜歡/收藏過的商店列表、或用戶使用過的功能。

操作屬性的類型

大多數事件都有一個與之相關的類型，區(qū)分類型對于獲得可操作的數據很重要，例如：

取消乘車-用戶發(fā)起/系統(tǒng)發(fā)起。
選擇付款-信用卡/電匯。
上傳的照片-拍照上傳/從相冊選擇。
登錄成功-谷歌/Facebook/電子郵件/手機號。

為了弄清這些類型，我會考慮如下這些問題：

誰應該對這一轉換（或失?。┴撠?？

是什么原因導致了這種轉換（或失?。?？
這個用戶在完成這個動作時有什么偏好？
如何描述這個行動的最重要的用戶旅程路徑？
有哪些額外的信息來預測這個用戶基于此行動的未來行動？

情境屬性

情景屬性是那些可能影響用戶是否能完成目標的動機的屬性，例如：

屏幕上的司機數量。
顯示的商戶類型。
搜索結果的數量。

我發(fā)現有助于發(fā)現情景屬性的問題可能包括：

什么會影響用戶完成目標的積極性？
我怎樣才能區(qū)分動機的增加或減少？
想象一下，這是我們從用戶那里追蹤到的最后一個事件，那么關于這次經歷我們想要了解些什么？

4、壓力測試

一旦你定義了你的一組事件和屬性，你應該對理解和可操作性進行壓力測試。

測試理解程度

一個事件或屬性對我們來說可能是有意義的，但問題是它對你的最終受眾有意義嗎？如果人們不理解基礎知識（比如“事件”是什么），那么實際的分析就無從談起。這里的關鍵是，你應該和商業(yè)用戶而非開發(fā)者的達成共識。

在Gojek，一開始所有的東西都是由移動應用開發(fā)者構建的。他們?yōu)槲覀兊囊苿討贸绦騽?chuàng)建了事件名稱，如"注冊處理程序（Signup Handler）"或"緩存結果反饋（Cached Result Feed）"。這些事件命名方式對他們來說很合理，但對商業(yè)用戶來說卻是十分陌生的語言。由于其晦澀難懂，因此沒有人愿意使用我們的分析工具。

為了便于理解，我建議測試以下幾個受眾:

1.?接近產品開發(fā)的商業(yè)用戶

你應該測試的第一個群體是接近產品開發(fā)的商業(yè)用戶——通常是產品經理。那些接近產品開發(fā)的人往往對產品的工作原理有更多的了解。因此，如果他們都不太理解產品的使用邏輯，那么那些對產品了解更少的人就更難以理解了。

2.?離產品開發(fā)較遠的商業(yè)用戶

下一個群體是離產品開發(fā)較遠的商業(yè)用戶——通常是市場營銷人員或客戶支持人員。他們通常對產品的工作原理沒有那么細致的了解，但應該能夠理解所有的事件和屬性意味著什么。

3.?新員工

下一個群體是新員工。新員工還沒有習慣于公司的內部術語或特定縮寫，但我們希望這些新員工能夠在沒有大量實踐培訓的情況下理解事件和數據。

在Gojek，我為用戶搭建了一個"快速測試"，以獲得對我們分析工具的訪問。如果用戶無法"通過"測驗，這就意味著我們的事件跟蹤十分混亂。因此，我建議如果能把新員工的"入職測試"換成"內部事件工具產品測試"就再好不過了!

在任何情況下，如果你發(fā)現一些讓終端用戶感到困惑的東西，只需一個簡單的問題就可以幫助你找到合適的命名辦法，那就是 "當客戶在[產品的某個部分]上[做某個動作]時，你會怎么填入方括號中的內容？"

測試可操作性

了解數據只是第一步，我們仍需要對數據是否可操作進行壓力測試。在這里，我們應該回顧一下第一步中生成的“問題和假設”清單，選擇其中的一個樣本，并就我們可能如何回答這些問題和假設進行壓力測試。

在Gojek，產品、運營、財務和研究團隊共同提出的一個問題是："是什么讓一個司機變成了一個[最好的/最快樂的/最具生產力的]司機？"這里的關鍵是，對于財務團隊和司機福利團隊來說，“快樂”的定義是不一樣的；同理，對于運輸團隊和視頻配送團隊來說，“最具生產力”的定義也是不一樣的。

因此，我們需要測試這些團隊和用例的可操作性，提出我們如何從不同角度分析問題的不同假設。我們是否可以將司機分成易于常人理解的群體，如五星級司機、長途司機，或者按服務類型劃分等。

5、追蹤 "沒有數據而做出的決策"

無論你關于上述過程的工作做得有多詳盡，總會有一些變化需要額外工作來應對。業(yè)務、目標和產品都在不斷變化、產生新的需求。你永遠無法預料到所有需要回答的問題和假設。

我建議數據團隊定期進行一項簡單的練習——"無數據決策"。每個季度，我們都會把更多的團隊在沒有數據的情況下所做的決策列出來。

例如，在Gojek的時候，“更快地支付給司機是否能促進司機留存”是我們所關注的一個問題。當時，我們并沒有跟蹤合適的數據來回答這個問題，因此有人根據自己的直覺和推理得出了相關論證以支撐決策。發(fā)現這個沒有數據支撐的決策后，我們開始追蹤一些新的數據，這樣我們就能確認支付速度確實能促進司機留存，并圍繞它制定具體的產品和營銷措施。

這個練習可以幫助你發(fā)現那些被你忽略的、沒有預料到的、或在業(yè)務中改變的東西。要明確的是，我并不是說一切決策都必須在有數據的情況下才能被做出。任何快速發(fā)展的公司都面臨一個現實——有些決策就是需要在沒有數據的情況下被做出。但是，這個清單有助于我們發(fā)現“缺乏數據支撐”的情況，而這些數據本可以對關鍵決策有所幫助。

成功的持續(xù)信號

在一個組織中創(chuàng)建一個優(yōu)秀的數據系統(tǒng)需要持續(xù)迭代的努力。當你在內部工具和系統(tǒng)上工作時，你的客戶是另一組員工而不是公司的最終客戶，此時并沒有收入或其他指標的直觀反饋來告訴你，你做得算是糟糕、良好還是優(yōu)秀。下面列出的一些信號將有助于你了解事情的進展：

糟糕信號

只有一個人知道如何進行數據追蹤——沒有人知道如何編寫事件規(guī)范。
即使是非?；镜姆治鲆残枰獢祿治鰩熡H自進行。
事件名稱和屬性名稱出現多處重復（例如，Sign up和Sign Up）。
每季度的非數據驅動型決策的數量不斷增加。
分析工具的使用率很低。
當新的功能和產品被添加時，事件追蹤并沒有更新以反映新的路徑。
出現了違反邏輯的漏斗數據（例如，做步驟2的用戶比做步驟1的還多）。?

良好信號

很多團隊都在使用事件追蹤表和分析工具（要像追蹤你的產品使用情況那樣追蹤分析工具的使用情況）。
其他團隊也為分析工具做出了貢獻，并努力跟上產品的新進展。
隨著應用中新功能、新方法的實現，事件追蹤表也被同步更新。
對于業(yè)務團隊來說，相比寫交易相關的查詢，在分析平臺上直接提取數據更易于尋找問題的答案。

優(yōu)秀信號

事件追蹤被嵌入到你的常規(guī)目標設置中，以確保各團隊擁有合適的信息。
離開發(fā)過程更遠的團隊（例如最遠端的客戶支持團隊）也經常使用這些工具，同時不需要經過大量的培訓。
即使產品出現了重大的改版，事件追蹤也能沿用原有的事件名稱和屬性邏輯。
團隊可以將資金投入其中——可以信任事件跟蹤來細分用戶并分配用戶獎勵(如推薦、折扣、促銷)。

本文作者Crystal Widjaja是東南亞最大的超級應用之一Gojek的前增長和商業(yè)智能高級副總裁。Crystal幫助Gojek從每天2萬份訂單擴大到500萬份。

原文標題：

Why Most Analytics Efforts Fail

原文鏈接：

https://www.reforge.com/blog/why-most-analytics-efforts-fail

編輯：于騰凱

校對：林亦霖

譯者簡介

殷之涵（Jane），康奈爾大學生物統(tǒng)計與數據科學專業(yè)，A La Lune London戰(zhàn)略總監(jiān)。曾在騰訊&京東任職數據科學家，主要負責用戶增長&市場營銷數據科學方面的工作，通過指標體系搭建、統(tǒng)計分析、數據挖掘和機器學習建模來驅動決策、制定并落地億級用戶的精細化運營策略。

翻譯組招募信息

工作內容：需要一顆細致的心，將選取好的外文文章翻譯成流暢的中文。如果你是數據科學/統(tǒng)計學/計算機類的留學生，或在海外從事相關工作，或對自己外語水平有信心的朋友歡迎加入翻譯小組。

你能得到：定期的翻譯培訓提高志愿者的翻譯水平，提高對于數據科學前沿的認知，海外的朋友可以和國內技術應用發(fā)展保持聯系，THU數據派產學研的背景為志愿者帶來好的發(fā)展機遇。

其他福利：來自于名企的數據科學工作者，北大清華以及海外等名校學生他們都將成為你在翻譯小組的伙伴。

點擊文末“閱讀原文”加入數據派團隊~

轉載須知

如需轉載，請在開篇顯著位置注明作者和出處（轉自：數據派ID：DatapiTHU），并在文章結尾放置數據派醒目二維碼。有原創(chuàng)標識文章，請發(fā)送【文章名稱-待授權公眾號名稱及ID】至聯系郵箱，申請白名單授權并按要求編輯。

發(fā)布后請將鏈接反饋至聯系郵箱（見下方）。未經許可的轉載以及改編者，我們將依法追究其法律責任。

點擊“閱讀原文”擁抱組織

獨家 | 一個好的事件跟蹤字典是什么樣的？

Why Most Analytics Efforts Fail

獨家 | 一個好的事件跟蹤字典是什么樣的？