資料指標的定義，是培養資料思維要闖的第一道關。比如常見的以下指標定義：
1、啟用，如何定義乙個啟用？
2、新增使用者數，多維度區分
如果把新增使用者定義為新註冊的user_id，簡單粗暴，但市場的同事首先不答應。
另外乙個維度是版本。每個版本發布時，市場可能會帶一波量，需要觀察版本新增使用者的推廣成本、轉化、arpu值等。我們可以通過version_id來區分版本。
以上，通過channel_id、product_id、version_id的區分和篩選，市場部的同事就可以知道，每個渠道下的每個產品的每個版本的新增使用者情況。
維度區分清晰了，除了在一定程度上，提高市場推廣效率外，甚至能預防資料異常的發生。筆者所在公司是做公積金查詢的，查詢數/新增使用者數，是一項重要的指標。有天突然查詢數/新增使用者數斷崖式**，一開始，大家都以為是查詢成功率下降導致查詢數（分子）下降，拼命分析影響成功率的因素，卻始終無解。
後來才發現，是新增使用者數（分母）的暴增導致了比率的**。新增使用者數暴增，查詢數成功率正常，查詢數卻沒有增加，什麼鬼？其實這是個偽暴增。新增使用者的統計口徑，納入了錯誤的product_id，而id對應的產品剛好正在大力推廣……
如果能在資料指標定義時，清晰地劃分出可能的維度，類似耗費時間與溝通成本的資料異常問題就不會發生。
定義活躍，不能粗暴地只定義乙個使用者日活指標，可以先從轉化的角度進行使用者層級的劃分。
跟蹤以上指標，能得到比單純的使用者日活指標更豐富的資訊。
另外，活躍也不一定以日為單位。從行為頻率上來看，查詢公積金可能是1次/月，申請貸款可能是1次/日。那麼，公積金匯入使用者，月活可能更適合作為活躍指標；而對於申請貸款的使用者，則日活更適合。
在和同事討論7日留存率的定義時，出現了分歧。有人認為7日留存率指的是，新使用者在第2-7日的活躍數/新使用者數；而不同意見表示是新使用者在第7日的活躍數/新使用者數。老鐵們也可以發表下自己的意見，你們支援哪種，理由呢？
至於選擇次日留存率、7日留存率還是30日留存率作為唯一關鍵指標，多少留存率為目標，要根據產品特性與市場環境作具體分析。
從定義上看，流失和留存貌似是兩兄弟。有7日留存率，就有7日流失率，兩者的分子加起來等於首日的新使用者。但新使用者在第7日未活躍，就定義為流失使用者，未免太過草率。由於回流使用者的存在，定義流失使用者的週期一般比留存使用者的長。比如，定義90日內未活躍的使用者為流失使用者，更為合適。
最後強調一點，定義資料指標不能無的放矢。
如果是為了解決乙個問題，那我們先明確問題，分析可能的原因，再去定義指標。
如果是為了驗證設計方案的優劣，那我們先明確設計方案的目標，圍繞目標去對比上線前後的資料，或者做a/b test。
如果是為了**，那我們先摸索現有的資料規律，找到規律的自變數，再進行推演。
如果是為了預警，那我們先制定資料基線以及浮動範圍，並根據實際情況的變化靈活調整。
指標類資料標準如何定義？
指標類資料標準是資料基礎上按照一定業務規則加工彙總的資料，如kpi指標資料。我們通常從4個屬性組來定義。基礎屬性 資料標準編碼 根據資料標準編碼命名規則進行編寫。中文名稱 資料標準中文名稱。英文名稱 資料標準英文名稱。應用場景 該指標適用於什麼場景。資料版本 該資料標準的版本資訊。資料體系分類 根據...
指標實現層級 如何定義產品的資料指標？
大海航行靠舵手，而舵手需要根據天上的星辰和 六分儀 等工具來判斷位置，並結合航海圖的終點來確定船的走向。某種程度上來說，產品運營與航海在實踐上具有相同的業務邏輯，二者都需要乙個統一的方向和目標。根據這個方向和目標，企業可以更好地指導產品的具體運營工作。一款產品上線之後，需要不同部門之間的通力協作，產...
如何定義結構體指標
想要定義結構體型別的指標一定要用typedef 寫法1 typedef struct node nodeptr nodeptr head new node node head1 new node 兩種寫法等價 寫法2 struct node typedef node nodeptr nodeptr ...