為什麼大多數資料分析都失敗了？（2）

上篇點選標題，本文是續篇，有關領域事件的詳細設計，沒有良好的DDD設計，就沒有良好的大資料結果，就沒有良好的資料工程，這也是大多數資料分析都是失敗的原因：

下面是幾個快速示例顯示了意圖→成功→失敗的事件旅程：

• 示例一
  • 意圖：新增新付款方式並新增已提交的新付款詳細資訊
  • 成功：新增新付款方式成功
  • 失敗：新增新付款方式失敗
• 示例二
  • 意圖：建立已選中的發票→新發票已啟動→聯絡人搜尋
  • 成功：收件人已新增到發票→發票已傳送
  • 失敗：已儲存發票草稿（預設操作）

2A - 成功事件

我首先仔細考慮成功事件。成功事件是指產品中的操作已成功完成。這些事件源於我在第一步中收集的業務目標。成功事件的示例可能包括：

• 付款成功
• 註冊成功
• 發票已傳送
• 已完成預訂

為了不過度跟蹤所有內容，我用一個問題對每個事件進行壓力測試。“想象一下，我確實跟蹤了這個，99%的使用者做到了，我會怎麼做？它告訴我什麼？”如果我無法找到可以極端操作的東西，那麼這個事件可能沒有幫助。

2B - 意向性事件

然後，對於每個成功事件，我都會仔細考慮意圖事件。意向性事件通常是任何成功事件的前身所需的一步。跟蹤意向事件對於理解圍繞成功事件的“原因”至關重要。

意向事件告訴我，使用者如何“受過教育”和“有動力”完成我希望他們完成的操作的一些步驟。實際上，一切都是下一個事件的故意事件——但我們通常只認為它們是“目標”，這阻礙了我們準確跟蹤它們。例如，在騎行共享應用程式中，選擇目的地是一個目標，但需要選擇騎行型別的意圖/設定事件（在舊的Lyft/Uber流程中）。然後，預訂某個騎行成為目標，但需要從搜尋/歷史等中找到目的地的意圖/設定事件......

為了想出有意圖的事件，我問——為了完成成功事件，我必須完成哪些步驟？常見的示例包括：

• 在我們的第一個旅程示例中，我們注意到了“新增新付款方式已選擇”和“新增新付款詳細資訊已提交”的意圖事件
  • 請注意，我們這裡有兩個層次的意圖——高意圖，即使用者正在積極提交付款詳細資訊，以及低但指示性的意圖，即使用者選擇是通過銀行還是信用卡新增付款詳細資訊。在這些事件之間投遞會導致團隊可以執行的後續步驟：要麼使用者發現輸入欄位令人生畏，要麼當時沒有這些資訊。我們現在知道他們是否選擇了銀行或信用卡付款方式，並可以跟進更多資訊和個性化內容，以幫助使用者完成此步驟。

我還使用Intent Events意圖事件來識別使用者在完成操作時自然採取的路徑。例如，使用我們的發票和賬單支付應用程式，使用者是先匯入聯絡人還是先建立發票來傳送發票？隨著我們的賬單支付網路的增長，這種行為會有什麼變化？

同樣，在Gojek的食品配送產品中，我們注意到我們最成功的使用者是那些已經知道自己想吃什麼的人，他們來Gojek只是為了完成送貨服務。這些使用者的意圖是搜尋特定的餐廳，找到他們想要的選單項，最後設定他們的送貨詳細資訊。然而，隨著這些使用者的成熟，我們注意到，隨著使用者開始更多地使用Gojek作為發現新餐廳的手段，而不是滿足他們已經認識的餐廳，最普遍的使用者意向之旅發生了變化。現在，意向性活動包括滾動瀏覽朋友的食物提要、瀏覽折扣交易或使用“附近”功能。

這些意向性事件對於理解Bangaly Kaba（Reforge EIR，Instagram前增長主管）所謂的相鄰使用者至關重要。隨著使用者的成熟和市場的擴張，這些旅程會隨著時間的推移而演變，我們的產品也應該通過匹配新使用者的意圖和成熟的使用者的意圖來實現。

2C - 故障事件

失敗事件是指發生在意圖事件和成功事件之間，阻止使用者取得成功。在意圖事件和成功事件之間存在許多使用者可能會遇到的故障路徑。瞭解失敗路徑對於理解成功路徑同樣至關重要，因為它們為我們提供了關於如何改進成功事件的可操作資訊。要想出故障事件，我問-哪些可能阻止使用者完成目標？有兩種型別的故障事件：

• 隱含失敗是指在成功完成目標之前發生的掉期。使用者只是從我們的旅程中“消失”。在我們上面的兩個旅程示例中，事件的跟蹤方式提供了兩個隱含的故障指標：
  • 執行Create Invoice Selected但沒有在5分鐘內執行New Invoice Started的使用者表示我們的啟用旅程失敗。
  • 執行聯絡人搜尋但在5分鐘內未執行收件人新增到發票的使用者表示我們的搜尋結果或搜尋歷史記錄失敗。使用者可能沒有足夠的動力從頭開始建立聯絡人，或發現令人困惑的結果。
• 顯式故障是指預期體驗出錯的事件。
  • 訂購外賣時，Lyft上的“騎行取消”或“訂單取消——餐廳關閉”等事件是明顯失敗的例子
  • 在Honeydu中，新增新付款方式失敗和支付發票失敗是事件跟蹤練習中經常被遺忘的兩個例子，因為它們是對使用者行為的響應，而不是產品內實際採取的行動。但是，如果您的網路/移動應用程式收到錯誤並將其顯示給您的使用者，這些錯誤應該易於跟蹤和記錄以進行監控。將這些錯誤響應訊息儲存為事件屬性是快速診斷為什麼常見的使用者旅程可能突然失敗的簡單方法。

3 - 屬性

一旦我們成功、意圖和失敗事件，下一步就是找出我們要與事件關聯的屬性。屬性再次成為實現我們兩個主要目標的關鍵，即提供正確的抽象水平並使資料可操作。

屬性本質上是我想分割事件的方式。一個關鍵錯誤是將分割跟蹤為事件本身。例如：

• 良好：註冊選擇（事件）、來源（財產）、Facebook（財產價值）
• 錯誤：Facebook註冊已選擇

瞭解您可能需要跟蹤哪些屬性的一個關鍵來源是您在第一步中發現的問題和假設。

• 問題示例：使用者更喜歡如何新增聯絡人？
  • 屬性示例：來源→歷史記錄/匯入/手動輸入
• 假設示例：與選擇構建自己的發票的使用者相比，初次自由職業者更有可能使用模板開始使用模板，並且需要更多的入職才能獲得核心價值。
  • 屬性示例：模板名稱→（空）/基本發票等。

我喜歡問一些高階問題，以確定哪些屬性很重要：

• 我如何細分變得沮喪和無私的使用者？
• 我如何識別成熟使用者和臨時使用者使用的不同路徑？
• 這是否給了我足夠的細微資料來比較和對比成功使用者和下車使用者？
• 如果這是我最後一次從使用者那裡跟蹤的事件，我想知道關於使用者在這個螢幕上的體驗嗎？

屬性往往落入少數常見的桶之一。為了確保我徹底，我使用這些桶來檢視我是否遺漏了什麼：

使用者配置檔案屬性

最常見的屬性集是與使用者配置檔案相關的屬性集。這可能是人口統計或公司資訊。一些例子：

• 城市
• 年齡
• 公司規模
• 角色
• 產品等級

通常情況下，這些都是您希望能夠從屬性更改之前永久分割使用者和事件的東西。一些平臺，如Mixpanel，包含超級屬性等功能，允許您輕鬆做到這一點。要問的問題，以弄清楚要跟蹤以下哪些屬性：

• 如果我是這個使用者的個人助理，我需要了解哪些關於他們的偏好才能提供幫助？
• 哪些人口統計資訊可能會影響使用者的行為？

營銷屬性

第二組最常見的屬性是那些可能影響或影響使用者行為的與營銷相關的屬性。這可能包括以下內容：

• 來源
• 競選活動
• 條目頁面

使用者操作屬性

另一組屬性是與使用者操作相關的屬性。例如：

• 首次購買日期
• 第一種服務型別
• 訂單總數

在這裡，區分兩種型別的屬性很重要：

• 設定和忘記-這些屬性是您設定過一次，但之後不會更改。例如，首次購買日期、首次註冊署名和出生日期。
• 追加/增量-這些屬性用於細分和建立相關的個性化使用者體驗。增量屬性可以是購買總量、總收入等。新增（和刪除）使用者屬性使團隊能夠快速識別他們已經表示感興趣的促銷、新更新和體驗的相關使用者。例如，例如您已經從中購買的餐廳列表（食品配送）、您最喜歡的商店列表（超本地POI），或使用者使用的功能。

行為屬性型別

大多數事件都有與它們相關的型別。區分型別對獲取可運算元據很重要。一些例子：

• 騎行已取消：使用者發起與系統發起
• 已選擇付款：信用卡與電匯
• 上傳的照片：相機與畫廊
• 登入成功：谷歌對臉書對電子郵件對電話

為了弄清楚我問的問題型別，例如：

• 誰負責這種轉換（或失敗）？
• 什麼原因導致了這種轉換（或失敗）？
• 這個使用者在完成此操作時有哪些偏好？
• 我如何描述此操作最重要的使用者旅程路徑？
• 我還可以使用哪些其他資訊來預測此使用者基於此操作的未來操作？

上下文屬性

上下文屬性是那些幫助我理解哪些因素可能會影響使用者完成或不完成目標的動機。一些例子：

• 螢幕上的驅動程式數量
• 顯示的商家型別
• 搜尋結果的編號

我發現有助於發現上下文屬性的問題可能包括：

• 什麼因素會影響使用者完成目標的動力？
• 我如何區分動機的增減？
• 想象一下，這是我們從使用者那裡跟蹤的最後一個事件。關於這次經歷，我們想知道什麼？