本帖由東南亞最大的超級應(yīng)用程序之一Gojek的商業(yè)智能BI前高級副總裁Crystal撰寫。以下是摘要，原文點擊標(biāo)題：
Gojek成為東南亞最大的消費交易技術(shù)集團(tuán)，其超級App應(yīng)用包括訂購食品、交通、數(shù)字支付、超本地送貨和十幾項其他服務(wù)。Gojek每天完成的食物訂單比Grubhub、Uber Eats和DoorDash的總和還要多，每天的旅行次數(shù)也比Lyft多。
Crystal幫助Gojek將訂單從每天2萬份增加到500萬份。商業(yè)智能團(tuán)隊從0到100人，全部在4.5年內(nèi)實現(xiàn)增長。
當(dāng)我第一次加入時，有個“IT”家伙正在運行SQL查詢。在第一周內(nèi)，我意識到其中大多數(shù)數(shù)據(jù)是都相當(dāng)不準(zhǔn)確，大多數(shù)人不明白數(shù)據(jù)到底是什么。事實上，有人給了我一張便利貼，告訴我如何確定完成的訂單是什么（flag_booking = 2和 booking_status = 4）。沒有數(shù)據(jù)基礎(chǔ)設(shè)施，所有查詢結(jié)果都被復(fù)制/粘貼到Excel報告中，該報告被手動通過電子郵件發(fā)送給高管。
我雇傭了3名數(shù)據(jù)倉庫團(tuán)隊成員。我實施了一項策略，使用Pentaho ETL將所有內(nèi)容放入一個Postgres數(shù)據(jù)倉庫。但考慮到我們的規(guī)模和增長，這在8個月內(nèi)變得毫無用處。然后，我們遷移到谷歌云平臺，并實施了BigQuery、BigTable、Data Flow、Airflow等。
我們還瀏覽了我們公平份額的可視化工具。我們從Tableau開始，然后是Metabase，然后在大約3年時轉(zhuǎn)向內(nèi)部工具。我們的實驗平臺從手動CSV上傳到BigQuery表，再到更接近Airbnb的ERF的內(nèi)部系統(tǒng)。
從那以后，我一直在幫助Carousell、Cashdrop、CRED、Celo、紅杉投資組合公司和其他公司等初創(chuàng)企業(yè)在迷宮中導(dǎo)航。
除了所有工具外，還有一個基礎(chǔ)的事情可以促成或破壞公司內(nèi)部的任何數(shù)據(jù)倡議：您如何思考跟蹤什么，如何跟蹤它，以及如何隨著時間的推移對其進(jìn)行管理。
如果你把這些原則方法弄錯了，世界上最好的工具不會拯救你。
在本帖中，我分析了：
- 數(shù)據(jù)癥狀 - 團(tuán)隊在數(shù)據(jù)問題方面最常見的癥狀。
- 數(shù)據(jù)問題的根本原因 - 這些癥狀的實際根本原因。
- 分步流程-我逐步了解如何思考要跟蹤的內(nèi)容，如何跟蹤它，以及如何隨著時間的推移對其進(jìn)行管理，并配有事件跟蹤器模板，以幫助指導(dǎo)流程。
大多數(shù)公司可能會將自己的數(shù)據(jù)描述為“混亂”。當(dāng)他們這么說時，他們通常指的是少數(shù)常見癥狀之一：
- 缺乏共享語言
- 知識轉(zhuǎn)讓緩慢
- 缺乏信任
- 無法快速處理數(shù)據(jù)
缺乏領(lǐng)域共享通用統(tǒng)一語言：
在應(yīng)用程序中描述相同體驗的方法有很多。如果您問您的團(tuán)隊“用戶如何結(jié)賬？”——在許多情況下，沒有人會使用相同的術(shù)語說出相同的步驟集。
當(dāng)應(yīng)用程序中有多種方法做同樣的事情時，或者當(dāng)導(dǎo)航選項卡是未命名的圖標(biāo)時，這主要是個問題。例如定價頁面可以是定價概覽或詳細(xì)定價。是描述文件還是帳戶設(shè)置？這些聽起來可能相同，但在許多產(chǎn)品中有所不同。
缺乏共享語言開始使數(shù)據(jù)變得無用。與其他團(tuán)隊就數(shù)據(jù)進(jìn)行深思熟慮的討論或?qū)?shù)據(jù)的實際含義達(dá)成共識需要花費更多時間。更糟糕的是，當(dāng)團(tuán)隊真的不理解時，他們可能會認(rèn)為他們有一個共同的理解。這種摩擦通常會導(dǎo)致沮喪和完全避免使用數(shù)據(jù)。
上述挑戰(zhàn)在于它們只是癥狀。許多團(tuán)隊試圖通過以下方法解決癥狀：
- 新工具
- 更好的/更多的培訓(xùn)
- 要求更高的技術(shù)/分析標(biāo)準(zhǔn)來招聘
但通常，這些事情可能會浪費時間和金錢，因為你沒有解決根本原因和實際問題。相反，根本原因通常源于以下一個或多個：
- 分析指標(biāo)，而不是如何跟蹤指標(biāo)。
- 開發(fā)者/數(shù)據(jù)思維與業(yè)務(wù)用戶思維。
- 抽象程度錯誤。
- 僅書面與視覺溝通
- 數(shù)據(jù)作為一個項目與正在進(jìn)行的倡議
了解它們對于成功團(tuán)隊和失敗團(tuán)隊分開很重要，所以讓我們單獨檢查每個團(tuán)隊。
許多團(tuán)隊認(rèn)為，數(shù)據(jù)分析的目標(biāo)是跟蹤指標(biāo)。然而，真正的數(shù)據(jù)分析目標(biāo)是分析這些指標(biāo)。
這兩件事非常不同。
后者是我們?nèi)绾问剐畔⒖刹僮鳌Ｊ剐畔⒖刹僮餍圆皇菆蟾孀瞿呈碌娜藬?shù)，而是我們?nèi)绾螀^(qū)分成功人士和失敗者在我們的產(chǎn)品中做什么，以便我們能夠采取措施進(jìn)行改進(jìn)。這種細(xì)微差別通常會消失，但正如您將看到的那樣，我們?nèi)绾翁幚砀櫟膬?nèi)容和跟蹤它的方式發(fā)生了根本變化。
跟蹤最難做的事情之一是正確地抽象了跟蹤的內(nèi)容。糟糕的跟蹤是指當(dāng)我們的領(lǐng)域或界面事件過于抽象寬泛具有普遍性，良好的跟蹤是指當(dāng)我們的領(lǐng)域或界面事件比較具體，出色的領(lǐng)域或界面事件設(shè)計是指當(dāng)我們平衡這兩者。
讓我們考慮一個常見的用戶注冊事件。
- （壞）“Facebook注冊”或“谷歌注冊”-在這種情況下，我們根據(jù)“來源”將事件命名為來自“Facebook注冊”和“谷歌注冊”。然而，它太寬泛了。這是否意味著只是在界面選擇selected注冊按鈕但是沒有點擊？或已經(jīng)是注冊成功完成？如果注冊嘗試卻失敗了怎么辦？僅僅通過查看事件名稱，我不知道這些問題的答案。此外，如果我想知道這些注冊中有多少次，我需要單獨添加所有這些獨特的事件，使任何潛在的分析對任何PM來說都乏味和令人望而卻步。
- （好的）“注冊已點擊”-在這種情況下，我們對事件非常具體。在這里，我至少確切地知道事件發(fā)生時意味著什么。挑戰(zhàn)在于，如果我想查看所有選定的注冊來源。我不知道存在哪些來源，也很難做出實際決定。雖然我們有通過事件行為行為的“癥狀”，但我們沒有能力通過參數(shù)值“診斷”。
- （很棒）“注冊已選中”-在本例中，我們有正確的抽象水平。事件是明確的，已經(jīng)選擇了注冊方法，我對源事件需要設(shè)立有一個專門來源屬性，以便在需要時可以追溯。
通過設(shè)計事件字典統(tǒng)一領(lǐng)域語言：
事件跟蹤詞典中的字段屬性有專門規(guī)定，像一部字典一樣，字典中的基礎(chǔ)字段是：
- 事件名稱 - 操作的名稱。最佳使用特定短語命名，這些短語可能由資深用戶用來描述他們的行為
- 當(dāng)...觸發(fā)時-作為此事件及其屬性發(fā)送到我們?nèi)罩镜目煺盏奶囟ˋPI響應(yīng)、用戶操作或事件。
- 屏幕 - 顯示觸發(fā)操作時用戶位置的截屏或圖像
- 屬性-將隨此事件一起跟蹤的屬性名稱列表（例如源，isLoggedIn）
- 屬性值示例-最好詳盡無遺地完成，上面每個屬性下的潛在值列表。在潛在價值集有限的情況下（例如Facebook、電子郵件、google等潛在的注冊來源），最好在這里列出它們。
- 數(shù)據(jù)/屬性類型-每個屬性都應(yīng)限制為一種數(shù)據(jù)類型，如布爾值、字符串、數(shù)字、緯度和經(jīng)度或浮點。
- 描述 - 您如何描述此事件被記錄給以前從未使用過該產(chǎn)品的人？使用此字段消除未來使用該字段的業(yè)務(wù)團(tuán)隊和執(zhí)行這些規(guī)范的工程團(tuán)隊之間任何錯位的可能性。
- 技術(shù)評論-OAuth、API和內(nèi)部服務(wù)可以有自己的怪癖，你想在這里詳述。像將2XX個響應(yīng)聚合到單個“成功”值這樣的規(guī)范可以在這里進(jìn)行。
- 測試評論-這是一個活生生的、令人呼吸的文檔。當(dāng)新功能發(fā)布時，最好通過QA并確保事件在必要時引發(fā)。在這里傳達(dá)更改和問題可以快速解決問題。
團(tuán)隊拓?fù)渑c產(chǎn)品管理：
大多數(shù)分析系統(tǒng)的最終用戶都是業(yè)務(wù)用戶。我們需要構(gòu)建一些與該最終用戶產(chǎn)生共鳴的東西。這意味著使數(shù)據(jù)和分析過程人性化。這會影響我們?nèi)绾芜x擇要使用的工具、要跟蹤的事件、如何命名事件以及需要什么屬性。在這里花費有意義的時間是值得的，就像我們在新產(chǎn)品的客戶研究中一樣。
為了進(jìn)入業(yè)務(wù)用戶的心態(tài)，我經(jīng)歷了四個層次的問題。對于每個問題，我都提供了我最近合作過的一個名為Honeydu的產(chǎn)品中的一些示例，Honeydu是公司在線免費發(fā)送和接收發(fā)票的一種方式。
- 業(yè)務(wù)目標(biāo)和目的是什么？業(yè)務(wù)和執(zhí)行團(tuán)隊正在優(yōu)化哪些關(guān)鍵結(jié)果和指標(biāo)？這些信息的來源將是當(dāng)前和歷史的OKR、季度和年度規(guī)劃文件以及董事會甲板。示例一：X個新用戶在2020年第四季度末之前收到/發(fā)送發(fā)票示例二：發(fā)送給新用戶的發(fā)票的X%會導(dǎo)致新用戶注冊示例三：2020年第四季度末活躍的X張經(jīng)常性發(fā)票
- 每個團(tuán)隊的目標(biāo)和目的是什么？公司的高水平目標(biāo)是不夠的。每個團(tuán)隊通常都有一套目標(biāo)和目的，這些目標(biāo)和目的可以提升到公司級別的指標(biāo)。要了解這些目標(biāo)和目的，您可以找出每個團(tuán)隊的 OKR，與團(tuán)隊領(lǐng)導(dǎo)交談等。在這里，您想了解他們在歷史上的幾個時間段時間段，以及團(tuán)隊領(lǐng)導(dǎo)在將來的幾個時間段時間里的想法。示例一：（新用戶增長）前7天內(nèi)發(fā)送2張發(fā)票示例二：（付款集成）85%的新付款方式已成功驗證示例三：（NUX）以發(fā)票模板開頭的新用戶百分比
- 圍繞這些目標(biāo)和目的，產(chǎn)品體驗有哪些？接下來，對于每個目標(biāo)/目標(biāo)，我確定與推動這些目標(biāo)/目標(biāo)對應(yīng)的產(chǎn)品體驗。重要的是，不僅要識別產(chǎn)品或漏斗的特定屏幕，還要識別可能影響目標(biāo)或行動的體驗背景。例如，在優(yōu)步這樣的拼車產(chǎn)品中，如果產(chǎn)品體驗是預(yù)訂拼車，除了預(yù)訂拼車的漏斗外，我可能還想知道地圖上有多少司機(jī)？或者，預(yù)計時間是多少？第1步：在Honeydu中，許多不同的因素可能導(dǎo)致用戶發(fā)送他們的第一張發(fā)票，這是我們的核心行動。我們會問自己：
- 當(dāng)用戶選擇要向其發(fā)送發(fā)票的聯(lián)系人時，當(dāng)用戶的歷史業(yè)務(wù)列表中有聯(lián)系人時，或者當(dāng)他們需要搜索時，他們更有可能成功嗎？
- 哪些支持操作可以幫助用戶創(chuàng)建和發(fā)送他們的第一張發(fā)票？發(fā)票模板是加快發(fā)送時間的好方法嗎？還是更重要的是，他們的聯(lián)系人首先導(dǎo)入？
第2步：下一步是思考可能阻止用戶實現(xiàn)我們的目標(biāo)和目的的經(jīng)驗。在Honeydu的案例中，我會問：為什么新用戶沒有成功創(chuàng)建他們的第一張發(fā)票？他們是否查看了不同的模板，但沒有找到與他們相關(guān)的模板？他們是否嘗試從頭開始創(chuàng)建發(fā)票，發(fā)現(xiàn)回到我們的模板目錄太難了？我們已激活的用戶執(zhí)行了哪些操作，而未激活的用戶沒有執(zhí)行？
第3步：最后，想象一下，任何事件都可能是我們在產(chǎn)品中從用戶那里跟蹤的最后一個事件。關(guān)于這次經(jīng)歷，我們想知道什么？我們需要知道他們在聯(lián)系搜索后是否獲得了“未找到結(jié)果”頁面，或者在添加新付款方式時出錯，并利用這些活動的受歡迎程度開始對我們用戶體驗中的問題進(jìn)行分類診斷。
- 我/他們可能想圍繞這些目標(biāo)和產(chǎn)品體驗回答哪些問題/假設(shè)？接下來，我想一想他們（或我）在這些目標(biāo)或目的周圍可能有什么問題或假設(shè)。同樣，在這里，與團(tuán)隊領(lǐng)導(dǎo)或團(tuán)隊中的個人貢獻(xiàn)者討論他們面臨的問題。但也請自己思考，提出問題的假設(shè)，并與該團(tuán)隊驗證這些問題的重要性水平。示例一：Honeydu上的關(guān)鍵目標(biāo)和產(chǎn)品體驗之一是有人發(fā)送他們的第一張發(fā)票。我想問一個問題，我認(rèn)為需要哪些經(jīng)驗才能有人對向企業(yè)發(fā)送發(fā)票有信心？像“他們需要使用我們行業(yè)批準(zhǔn)的模板之一”或“他們看到Honeydu網(wǎng)絡(luò)中已經(jīng)列出的業(yè)務(wù)”這樣的假設(shè)表明，我們需要能夠跟蹤經(jīng)驗，以便量化并從假設(shè)轉(zhuǎn)向?qū)ο嚓P(guān)性/因果關(guān)系的信心。示例二：通過Honeydu支付發(fā)票的用戶越多，我們產(chǎn)生的收入就越多。我們應(yīng)該跟蹤用戶最有可能在什么時候支付發(fā)票，問問自己“用戶什么時候最有可能通過Honeydu支付發(fā)票？今天什么時候到期？明天？”通過跟蹤Pay Invoice Success事件上的 daysTillDueDate屬性，我們可以為那些沒有自然地看到發(fā)票到期日而不在自然傾向之外發(fā)送垃圾郵件的用戶提供信息并構(gòu)建我們的推送通知和電子郵件策略。
下面是幾個快速示例顯示了意圖→成功→失敗的事件旅程：
- 示例一
- 意圖：添加新付款方式并添加已提交的新付款詳細(xì)信息
- 成功：添加新付款方式成功
- 失敗：添加新付款方式失敗
- 示例二
- 意圖：創(chuàng)建已選中的發(fā)票→新發(fā)票已啟動→聯(lián)系人搜索
- 成功：收件人已添加到發(fā)票→發(fā)票已發(fā)送
- 失敗：已保存發(fā)票草稿（默認(rèn)操作）
2A - 成功事件
我首先仔細(xì)考慮成功事件。成功事件是指產(chǎn)品中的操作已成功完成。這些事件源于我在第一步中收集的業(yè)務(wù)目標(biāo)。成功事件的示例可能包括：
- 付款成功
- 注冊成功
- 發(fā)票已發(fā)送
- 已完成預(yù)訂
為了不過度跟蹤所有內(nèi)容，我用一個問題對每個事件進(jìn)行壓力測試。“想象一下，我確實跟蹤了這個，99%的用戶做到了，我會怎么做？它告訴我什么？”如果我無法找到可以極端操作的東西，那么這個事件可能沒有幫助。
2B - 意向性事件
然后，對于每個成功事件，我都會仔細(xì)考慮意圖事件。意向性事件通常是任何成功事件的前身所需的一步。跟蹤意向事件對于理解圍繞成功事件的“原因”至關(guān)重要。
意向事件告訴我，用戶如何“受過教育”和“有動力”完成我希望他們完成的操作的一些步驟。實際上，一切都是下一個事件的故意事件——但我們通常只認(rèn)為它們是“目標(biāo)”，這阻礙了我們準(zhǔn)確跟蹤它們。例如，在騎行共享應(yīng)用程序中，選擇目的地是一個目標(biāo)，但需要選擇騎行類型的意圖/設(shè)置事件（在舊的Lyft/Uber流程中）。然后，預(yù)訂某個騎行成為目標(biāo)，但需要從搜索/歷史等中找到目的地的意圖/設(shè)置事件......
為了想出有意圖的事件，我問——為了完成成功事件，我必須完成哪些步驟？常見的示例包括：
- 在我們的第一個旅程示例中，我們注意到了“添加新付款方式已選擇”和“添加新付款詳細(xì)信息已提交”的意圖事件
- 請注意，我們這里有兩個層次的意圖——高意圖，即用戶正在積極提交付款詳細(xì)信息，以及低但指示性的意圖，即用戶選擇是通過銀行還是信用卡添加付款詳細(xì)信息。在這些事件之間投遞會導(dǎo)致團(tuán)隊可以執(zhí)行的后續(xù)步驟：要么用戶發(fā)現(xiàn)輸入字段令人生畏，要么當(dāng)時沒有這些信息。我們現(xiàn)在知道他們是否選擇了銀行或信用卡付款方式，并可以跟進(jìn)更多信息和個性化內(nèi)容，以幫助用戶完成此步驟。
我還使用Intent Events意圖事件來識別用戶在完成操作時自然采取的路徑。例如，使用我們的發(fā)票和賬單支付應(yīng)用程序，用戶是先導(dǎo)入聯(lián)系人還是先創(chuàng)建發(fā)票來發(fā)送發(fā)票？隨著我們的賬單支付網(wǎng)絡(luò)的增長，這種行為會有什么變化？
同樣，在Gojek的食品配送產(chǎn)品中，我們注意到我們最成功的用戶是那些已經(jīng)知道自己想吃什么的人，他們來Gojek只是為了完成送貨服務(wù)。這些用戶的意圖是搜索特定的餐廳，找到他們想要的菜單項，最后設(shè)置他們的送貨詳細(xì)信息。然而，隨著這些用戶的成熟，我們注意到，隨著用戶開始更多地使用Gojek作為發(fā)現(xiàn)新餐廳的手段，而不是滿足他們已經(jīng)認(rèn)識的餐廳，最普遍的用戶意向之旅發(fā)生了變化。現(xiàn)在，意向性活動包括滾動瀏覽朋友的食物提要、瀏覽折扣交易或使用“附近”功能。
這些意向性事件對于理解Bangaly Kaba（Reforge EIR，Instagram前增長主管）所謂的相鄰用戶至關(guān)重要。隨著用戶的成熟和市場的擴(kuò)張，這些旅程會隨著時間的推移而演變，我們的產(chǎn)品也應(yīng)該通過匹配新用戶的意圖和成熟的用戶的意圖來實現(xiàn)。
2C - 故障事件
失敗事件是指發(fā)生在意圖事件和成功事件之間，阻止用戶取得成功。在意圖事件和成功事件之間存在許多用戶可能會遇到的故障路徑。了解失敗路徑對于理解成功路徑同樣至關(guān)重要，因為它們?yōu)槲覀兲峁┝岁P(guān)于如何改進(jìn)成功事件的可操作信息。要想出故障事件，我問-哪些可能阻止用戶完成目標(biāo)？有兩種類型的故障事件：
- 隱含失敗是指在成功完成目標(biāo)之前發(fā)生的掉期。用戶只是從我們的旅程中“消失”。在我們上面的兩個旅程示例中，事件的跟蹤方式提供了兩個隱含的故障指標(biāo)
- 執(zhí)行Create Invoice Selected但沒有在5分鐘內(nèi)執(zhí)行New Invoice Started的用戶表示我們的激活旅程失敗。
- 執(zhí)行聯(lián)系人搜索但在5分鐘內(nèi)未執(zhí)行收件人添加到發(fā)票的用戶表示我們的搜索結(jié)果或搜索歷史記錄失敗。用戶可能沒有足夠的動力從頭開始創(chuàng)建聯(lián)系人，或發(fā)現(xiàn)令人困惑的結(jié)果。
- 顯式故障是指預(yù)期體驗出錯的事件。
- 訂購?fù)赓u時，Lyft上的“騎行取消”或“訂單取消——餐廳關(guān)閉”等事件是明顯失敗的例子
- 在Honeydu中，添加新付款方式失敗和支付發(fā)票失敗是事件跟蹤練習(xí)中經(jīng)常被遺忘的兩個例子，因為它們是對用戶行為的響應(yīng)，而不是產(chǎn)品內(nèi)實際采取的行動。但是，如果您的網(wǎng)絡(luò)/移動應(yīng)用程序收到錯誤并將其顯示給您的用戶，這些錯誤應(yīng)該易于跟蹤和記錄以進(jìn)行監(jiān)控。將這些錯誤響應(yīng)消息存儲為事件屬性是快速診斷為什么常見的用戶旅程可能突然失敗的簡單方法。
3 - 屬性
一旦我們成功、意圖和失敗事件，下一步就是找出我們要與事件關(guān)聯(lián)的屬性。屬性再次成為實現(xiàn)我們兩個主要目標(biāo)的關(guān)鍵，即提供正確的抽象水平并使數(shù)據(jù)可操作。
屬性本質(zhì)上是我想分割事件的方式。一個關(guān)鍵錯誤是將分割跟蹤為事件本身。例如：
- 良好：注冊選擇（事件）、來源（財產(chǎn)）、Facebook（財產(chǎn)價值）
- 錯誤：Facebook注冊已選擇
了解您可能需要跟蹤哪些屬性的一個關(guān)鍵來源是您在第一步中發(fā)現(xiàn)的問題和假設(shè)。
- 問題示例：用戶更喜歡如何添加聯(lián)系人？
- 屬性示例：來源→歷史記錄/導(dǎo)入/手動輸入
- 假設(shè)示例：與選擇構(gòu)建自己的發(fā)票的用戶相比，初次自由職業(yè)者更有可能使用模板開始使用模板，并且需要更多的入職才能獲得核心價值。
- 屬性示例：模板名稱→（空）/基本發(fā)票等。
我喜歡問一些高級問題，以確定哪些屬性很重要：
- 我如何細(xì)分變得沮喪和無私的用戶？
- 我如何識別成熟用戶和臨時用戶使用的不同路徑？
- 這是否給了我足夠的細(xì)微數(shù)據(jù)來比較和對比成功用戶和下車用戶？
- 如果這是我最后一次從用戶那里跟蹤的事件，我想知道關(guān)于用戶在這個屏幕上的體驗嗎？
屬性往往落入少數(shù)常見的桶之一。為了確保我徹底，我使用這些桶來查看我是否遺漏了什么：
用戶配置文件屬性
最常見的屬性集是與用戶配置文件相關(guān)的屬性集。這可能是人口統(tǒng)計或公司信息。一些例子：
- 城市
- 年齡
- 公司規(guī)模
- 角色
- 產(chǎn)品等級
通常情況下，這些都是您希望能夠從屬性更改之前永久分割用戶和事件的東西。一些平臺，如Mixpanel，包含超級屬性等功能，允許您輕松做到這一點。要問的問題，以弄清楚要跟蹤以下哪些屬性：
- 如果我是這個用戶的個人助理，我需要了解哪些關(guān)于他們的偏好才能提供幫助？
- 哪些人口統(tǒng)計信息可能會影響用戶的行為？
營銷屬性
第二組最常見的屬性是那些可能影響或影響用戶行為的與營銷相關(guān)的屬性。這可能包括以下內(nèi)容：
- 來源
- 競選活動
- 條目頁面
用戶操作屬性
另一組屬性是與用戶操作相關(guān)的屬性。例如：
- 首次購買日期
- 第一種服務(wù)類型
- 訂單總數(shù)
在這里，區(qū)分兩種類型的屬性很重要：
- 設(shè)置和忘記-這些屬性是您設(shè)置過一次，但之后不會更改。例如，首次購買日期、首次注冊署名和出生日期。
- 追加/增量-這些屬性用于細(xì)分和創(chuàng)建相關(guān)的個性化用戶體驗。增量屬性可以是購買總量、總收入等。添加（和刪除）用戶屬性使團(tuán)隊能夠快速識別他們已經(jīng)表示感興趣的促銷、新更新和體驗的相關(guān)用戶。例如，例如您已經(jīng)從中購買的餐廳列表（食品配送）、您最喜歡的商店列表（超本地POI），或用戶使用的功能。
行為屬性類型
大多數(shù)事件都有與它們相關(guān)的類型。區(qū)分類型對獲取可操作數(shù)據(jù)很重要。一些例子：
- 騎行已取消：用戶發(fā)起與系統(tǒng)發(fā)起
- 已選擇付款：信用卡與電匯
- 上傳的照片：相機(jī)與畫廊
- 登錄成功：谷歌對臉書對電子郵件對電話
為了弄清楚我問的問題類型，例如：
- 誰負(fù)責(zé)這種轉(zhuǎn)換（或失敗）？
- 什么原因?qū)е铝诉@種轉(zhuǎn)換（或失敗）？
- 這個用戶在完成此操作時有哪些偏好？
- 我如何描述此操作最重要的用戶旅程路徑？
- 我還可以使用哪些其他信息來預(yù)測此用戶基于此操作的未來操作？
上下文屬性
上下文屬性是那些幫助我理解哪些因素可能會影響用戶完成或不完成目標(biāo)的動機(jī)。一些例子：
- 屏幕上的驅(qū)動程序數(shù)量
- 顯示的商家類型
- 搜索結(jié)果的編號
我發(fā)現(xiàn)有助于發(fā)現(xiàn)上下文屬性的問題可能包括：
- 什么因素會影響用戶完成目標(biāo)的動力？
- 我如何區(qū)分動機(jī)的增減？
- 想象一下，這是我們從用戶那里跟蹤的最后一個事件。關(guān)于這次經(jīng)歷，我們想知道什么？
