渠道幾乎是整個運營體系里,最最最依賴數據驅動的業務(重要的字眼說三遍)。 對于用戶的理解,產品的理解,市場和行業趨勢的理解往往可以憑天份(天啦嚕,天份是個什么鬼,見過我天份的同學請和我打聲招呼)。 但就是渠道,繁雜零散地分布在各個流程環節中的渠道,會沒有一點點防備也沒有一絲顧慮就突然出現在用戶面前的渠道,由于產業標準沒有,質量參差不齊,水平波動劇烈,使得渠道成為一個完全依賴數據運營的業務領域 Part0:我錯了前一篇《史上最全的運營指標體系詳解:基礎概念篇》少了APP端的基礎指標,但是講到移動端渠道運營的基礎數據又不得不將這基礎指標在此補上,移動端判定真假用戶往往就是在這些移動端運營的基礎指標上做文章; 首先要進行設備唯一標識的基礎概念普及——Android手機和越獄iPhone通常有IMEI,CUID兩種方式定義唯一設備 IMEI:IMEI(International Mobile Equipment Identity)是移動設備國際身份碼的縮寫,IMEI由15位數字組成
CUID:CUID (Called User Identification number) 被叫用戶識別號 由于IMEI碼在山寨機中存在重疊的問題,另外由于市場潛規則決定了IMEI生成器的存在,IMEI號并非區分唯一設備的最佳標準,在此基礎上,部分有定價權的大公司(說的就是BAT)指定了CUID的計算規則,簡單的說是用IMEI號+時間戳+安卓系統標示 計算出來的數值 設備唯一標識的痛——iOS真是放蕩不羈愛自由,每一次IOS升級都是數據統計者心中的痛 CFUUID從iOS2.0開始,CFUUID就已經出現了。它是CoreFoundatio包的一部分,因此API屬于C語言風格。CFUUIDCreate 方法用來創建CFUUIDRef,并且可以獲得一個相應的NSString, 獲得的這個CFUUID值系統并沒有存儲。每次調用CFUUIDCreate,系統都會返回一個新的唯一標示符。如果你希望存儲這個標示符,那么需要自己將其存儲到NSUserDefaults, Keychain, Pasteboard或其它地方。 NSUUIDNSUUID在iOS 6中才出現,這跟CFUUID幾乎完全一樣,只不過它是Objective-C接口。+ (id)UUID 是一個類方法,調用該方法可以獲得一個UUID。 跟CFUUID一樣,這個值系統也不會存儲,每次調用的時候都會獲得一個新的唯一標示符。如果要存儲的話,你需要自己存儲。在我讀取NSUUID時,注意到獲取到的這個值跟CFUUID完全一樣(不過也可能不一樣): IDFA: identifierForIdentifier這是iOS 6中另外一個新的方法,advertisingIdentifier是新框架AdSupport.framework的一部分。ASIdentifierManager單例提供了一個方法advertisingIdentifier,通過調用該方法會返回一個上面提到的NSUUID實例。 跟CFUUID和NSUUID不一樣,廣告標示符是由系統存儲著的。不過即使這是由系統存儲的,但是有幾種情況下,會重新生成廣告標示符。如果用戶完全重置系統((設置程序 -> 通用 -> 還原 -> 還原位置與隱私) ,這個廣告標示符會重新生成。另外如果用戶明確的還原廣告(設置程序-> 通用 -> 關于本機 -> 廣告 -> 還原廣告標示符) ,那么廣告標示符也會重新生成。關于廣告標示符的還原,有一點需要注意:如果程序在后臺運行,此時用戶“還原廣告標示符”,然后再回到程序中,此時獲取廣告標示符并不會立即獲得還原后的標示符。必須要終止程序,然后再重新啟動程序,才能獲得還原后的廣告標示符。 針對廣告標示符用戶有一個可控的開關“限制廣告跟蹤”。。將這個開關打開,實際上什么也沒有做,不過這是希望限制你訪問廣告標示符。這個開關是一個簡單的boolean標志,當將廣告標示符發到任意的服務器端時,你最好判斷一下這個值,然后再做決定。 IDFV: identifierForVendor這種叫法也是在iOS 6中新增的,不過獲取這個IDFV的新方法被添加在已有的UIDevice類中。跟advertisingIdentifier一樣,該方法返回的是一個NSUUID對象。 蘋果官方的文檔中對identifierForVendor有如下這樣的一段描述 :
如果滿足這樣的條件,那么獲取到的這個屬性值就不會變:相同的一個程序里面-相同的vendor-相同的設備。如果是這樣的情況,那么這個值是不會相同的:相同的程序-相同的設備-不同的vendor,或者是相同的程序-不同的設備-無論是否相同的vendor。 一個Vendor是CFBundleIdentifier(反轉DNS格式)的前兩部分。例如,com.doubleencore.app1 和 com.doubleencore.app2 得到的identifierForVendor是相同的,因為它們的CFBundleIdentifier 前兩部分是相同的。不過這樣獲得的identifierForVendor則完全不同:com.massivelyoverrated 或 net.doubleencore。 如果用戶卸載了同一個vendor對應的所有程序,然后在重新安裝同一個vendor提供的程序,此時identifierForVendor會被重置。 UDID在之前的版本中是可用的,但是在iOS5以及之后的版本中,以及被棄用了。雖然,這個UDID用得很廣泛,但是,不得不說的是,它在慢慢的遠離開發者,不能在考慮使用UDID了。 OpenUDID在iOS 5發布時,uniqueIdentifier被棄用了,這引起了廣大開發者需要尋找一個可以替代UDID,并且不受蘋果控制的方案。由此OpenUDID成為了當時使用最廣泛的開源UDID替代方案。OpenUDID在工程中實現起來非常簡單,并且還支持一系列的廣告提供商。 OpenUDID利用了一個非常巧妙的方法在不同程序間存儲標示符 — 在粘貼板中用了一個特殊的名稱來存儲標示符。通過這種方法,別的程序(同樣使用了OpenUDID)知道去什么地方獲取已經生成的標示符(而不用再生成一個新的)。 之前已經提到過,在將來,蘋果將開始強制使用advertisingIdentifier 或identifierForVendor。如果這一天到來的話,即使OpenUDID看起來是非常不錯的選擇,但是你可能不得不過渡到蘋果推出的方法。 度過了枯燥又乏味的基礎設備識別篇,接下來仍然是枯燥又乏味的未完成的Part0的部分,對于手機端產品常用的基礎統計指標,不過我會盡量說人話!!! 下述的數量統計均以上面提到的唯一設備標示為去重標準
到這里為止,有沒有發現——下載量、成功下載量、安裝量、新增量、有效新增是個流量漏斗的關系?流量漏斗就不在這里贅述了;重點說三遍,基礎數據指標重要的是嚴謹!嚴謹!嚴謹!上述5個指標均沒有描述去重的時間段,比如昨天安裝了,今天刪了后天有安裝了腫么搞?~所以在統計基礎指標的時候與數據庫負責人溝通清楚去重時間段非常重要,有條件的APP運營可以選擇對歷史庫全部去重,數據量太大以至于無法全量去重的APP運營可以選擇對過去365天的歷史庫去重,用戶換機周期現在差不多是1年+,365天也闊以了。 活躍:活躍指標也區分為日活DAU,月活MAU,你想搞個周活躍WAU也是可以的,不同時間維度的活躍統計表明了去重的時間周期
留存:仍然有時間維度的關鍵因素,有前置和后置兩種算法
留存和活躍都涉及到設備維度的唯一標識去重,所以數據統計量也是剛剛的 Part1:渠道基礎指標即不區分網站和客戶端的渠道類型下的通用指標 渠道標識: 不論是PC還是移動端都需要給渠道來源打上清晰的標示,簡而言之就是渠道號,渠道號的價值就是唯一識別流量來源,并且同時作為結算的憑證 渠道類型: 對渠道應該保留渠道類型的字段,醬紫未來可以整體看不同類別的渠道效率具體有什么樣的差別,對于管理渠道成本投放可以做的更有規劃和有的放矢,渠道類型在網站業務中有:SEM,SEO,知識問答渠道,社區BBS,聯盟,EDM短信,線下;在APP業務中有:ASO,應用市場,品牌廠商,方案商,刷機商,運營商,賣場,第三方聯盟,廣告平臺,積分墻等 渠道ROI 有營收的渠道要看看哦~
Part2:網站渠道指標
Part3:客戶端渠道指標
渠道運營指標具體腫么用,會在起點學院的渠道運營課程里細細闡述。。。 今天搞了這么多字,我也累了,洗洗睡了 接下來搞市場活動基礎數據,敬請期待么么噠。 |
2025-07-15
2025-07-15
2025-07-14
2025-07-14
2025-07-12
友情鏈接