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

發(fā)布人：數(shù)據(jù)派THU 時間：2022-01-13 來源：工程師

加入技術(shù)交流群
- 掃碼加入
  和技術(shù)大咖面對面交流
  海量資料庫查詢

發(fā)布文章

作者：Crystal Widjaja

翻譯：殷之涵

校對：王可汗

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

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

1）簡單

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

2）可操作性

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

3）可視化

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

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

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

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

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

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

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

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

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

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

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

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

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

例子三：（NUX）新用戶中開始使用****模板的百分比。

3. 圍繞這些目標的產(chǎn)品體驗是什么？

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

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

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

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

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

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

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

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

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

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

2、是旅程而不是指標

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

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

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

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

例子一：

意圖。選擇了新的付款方式和提交了新的付款細節(jié)。

成功。添加新的付款方式成功。

失敗。添加新的付款方式失敗。

例子二：

意圖：選擇創(chuàng)建**** → 開始填寫新**** → 搜索聯(lián)系人。

成功：收件人被添加到****上 → 發(fā)送****。

失敗：****草稿已保存（默認動作）。

2A-成功事件

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

付款成功

注冊成功

發(fā)出****

預訂完成

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

2b-意圖事件

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

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

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

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

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

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

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

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

2c - 失敗事件

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

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

用戶如果執(zhí)行了 "選擇創(chuàng)建****"，但沒有在5分鐘內(nèi)執(zhí)行 "開始新****"，表示激活過程中失敗。

用戶如果搜索了聯(lián)系人，但沒有在5分鐘內(nèi)將收件人添加到****中，表明我們的搜索結(jié)果或搜索歷史失敗。用戶可能覺得沒有足夠的動力去新建一個聯(lián)系人，或者沒看明白搜索結(jié)果。

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

像Lyft的"Ride Cancelled"（取消行程）或在訂購食品快遞時的"Order Cancelled - Restaurant Closed"（取消訂單-餐館打烊）等事件都是明確失敗的例子。

在Honeydu中，"添加新的付款方式失敗 "和 "支付****失敗 "是兩個事件的例子，它們經(jīng)常在事件追蹤工作中被遺忘，因為它們是對用戶行為的反應，而不是在產(chǎn)品中采取的實際行動。然而，如果你的網(wǎng)絡/移動應用程序收到錯誤并顯示給你的用戶，這些應該很容易跟蹤和記錄，以便監(jiān)測。將這些錯誤響應信息存儲為事件屬性，是快速診斷用戶旅程突然失敗的原因的簡單方法。

3、屬性

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

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

好做法：選定的注冊（事件），來源（屬性），F(xiàn)acebook（屬性值）。

壞做法：選擇Facebook為注冊方式。

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

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

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

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

屬性示例：模板名稱 → (null)/基礎****模板/其他。

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

我該如何區(qū)分那些失望和不感興趣的用戶？

我怎么才能識別成熟用戶與臨時用戶使用APP時的不同路徑？

這是否給了我足夠細致的數(shù)據(jù)來比較和對比成功用戶和掉線用戶?？

如果這是我從一個用戶那里追蹤到的最后一個事件，我想知道用戶在這個屏幕上的體驗是什么？

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

用戶檔案屬性

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

城市

年齡

公司規(guī)模

職位

產(chǎn)品層級

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

如果我是這個用戶的個人助理，那么我需要了解他們的哪些偏好，以便為其提供幫助？

哪些人口統(tǒng)計信息可能會影響用戶的行為？

營銷屬性

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

來源

活動

進入頁面

用戶操作動屬性

另一組屬性是與用戶的操作有關(guān)的屬性，例如：

首次訂單日期。

首次服務類型。

總訂單數(shù)。

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

設置并忘記（Set and Forget）型屬性：這些屬性一經(jīng)設置就不再改變。例如首次購買日期、首次注冊類型和出生日期。

附加/增加（Append/Increment）型屬性：這些是你用來細分和創(chuàng)建相關(guān)的、個性化的用戶體驗的屬性，如總購買量、總收入等。添加（和刪除）用戶屬性可以讓團隊快速識別相關(guān)用戶的促銷活動、信息更新，以及他們已經(jīng)表示感興趣的體驗。具體地，例如已消費餐廳的列表(外賣)、喜歡/收藏過的商店列表、或用戶使用過的功能。

操作屬性的類型

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

取消乘車-用戶發(fā)起/系統(tǒng)發(fā)起。

選擇付款-****/電匯。

上傳的照片-拍照上傳/從相冊選擇。

登錄成功-谷歌/Facebook/電子郵件/手機號。

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

誰應該對這一轉(zhuǎn)換（或失敗）負責？

是什么原因?qū)е铝诉@種轉(zhuǎn)換（或失?。?？

這個用戶在完成這個動作時有什么偏好？

如何描述這個行動的最重要的用戶旅程路徑？

有哪些額外的信息來預測這個用戶基于此行動的未來行動？

情境屬性

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

屏幕上的司機數(shù)量。

顯示的商戶類型。

搜索結(jié)果的數(shù)量。

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

什么會影響用戶完成目標的積極性？

我怎樣才能區(qū)分動機的增加或減少？

想象一下，這是我們從用戶那里追蹤到的最后一個事件，那么關(guān)于這次經(jīng)歷我們想要了解些什么？

4、壓力測試

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

測試理解程度

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

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

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

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

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

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

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

3. 新員工

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

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

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

測試可操作性

了解數(shù)據(jù)只是第一步，我們?nèi)孕枰獙?shù)據(jù)是否可操作進行壓力測試。在這里，我們應該回顧一下第一步中生成的“問題和假設”清單，選擇其中的一個樣本，并就我們可能如何回答這些問題和假設進行壓力測試。

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

因此，我們需要測試這些團隊和用例的可操作性，提出我們?nèi)绾螐牟煌嵌确治鰡栴}的不同假設。我們是否可以將司機分成易于常人理解的群體，如五星級司機、長途司機，或者按服務類型劃分等。

5、追蹤 "沒有數(shù)據(jù)而做出的決策"

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

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

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

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

成功的持續(xù)信號

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

糟糕信號

只有一個人知道如何進行數(shù)據(jù)追蹤——沒有人知道如何編寫事件規(guī)范。

即使是非?；镜姆治鲆残枰獢?shù)據(jù)分析師親自進行。

事件名稱和屬性名稱出現(xiàn)多處重復（例如，Sign up和Sign Up）。

每季度的非數(shù)據(jù)驅(qū)動型決策的數(shù)量不斷增加。

分析工具的使用率很低。

當新的功能和產(chǎn)品被添加時，事件追蹤并沒有更新以反映新的路徑。

出現(xiàn)了違反邏輯的漏斗數(shù)據(jù)（例如，做步驟2的用戶比做步驟1的還多）。

良好信號

很多團隊都在使用事件追蹤表和分析工具（要像追蹤你的產(chǎn)品使用情況那樣追蹤分析工具的使用情況）。

其他團隊也為分析工具做出了貢獻，并努力跟上產(chǎn)品的新進展。

隨著應用中新功能、新方法的實現(xiàn)，事件追蹤表也被同步更新。