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