導讀 畫像平臺是一個在中臺側應用非常廣，在業務側依賴很重的產品。本文將分享快看在建設畫像平臺方面的一些經驗。
分享將會圍繞下面四個方面展開：
1. 畫像平臺產品架構
2. 快看的建設經驗
3. 畫像平臺應用案例
4. 總結和展望
分享嘉賓｜屈世超 快看漫畫 資料研發負責人
編輯整理｜吳葉國 微言科技
出品社群｜DataFun
畫像平臺產品架構
上圖是基於快看資料中臺畫像平臺產品的理解和定位整理出來的產品架構。畫像平臺首先是服務於業務的，運營可以基於畫像平臺對單個使用者或者人群包做畫像的洞察，平臺服務的業務應用層包含：（1）個性化推薦：它對畫像的使用是非常重的，能夠基於每個使用者的畫像去做千人千面的內容分發。（2）精細化運營：產品運營對使用者做精細化營銷的時候，會使用畫像平臺的人群圈選，依賴平臺的人群洞察分析能力。（3）精準營銷：商業化側如精準營銷，會依賴畫像平臺，針對內容或者產品特點，精準觸達一定偏好的使用者，提高營銷效率。（4）獲客推廣：渠道獲客推廣對畫像平臺的應用也非常多，依賴也很重。（1）人群圈選：指根據使用者畫像的標籤或者特定的維度篩選出需要使用的人群包，然後對人群包中的使用者做一些特定的操作。（2）人群計算：對多個人群包進行交、差、並等操作。（3）人群洞察：對特定的人群包基於使用者的標籤或者維度去分析其分佈以及特點規律。（4）人群包管理：畫像平臺上能夠清晰有效的管理建立出的人群包，進行體系化的管理和展示。（5）標籤管理：畫像平臺最重要的資訊就是使用者的畫像標籤，需要對這些標籤進行一個體系化的管理。（6）Look-alike：快看資料中臺在建設畫像平臺的時候，這方面的訴求不多，公司的廣告業務自己實現了 Look-alike 功能，因此這裡不做詳細說明。（7）功能 API 和畫像查詢 API：畫像產品和業務的對接中，會收到業務側對畫像平臺功能 API 和查詢 API 等 API 介面的需求。有了 API，運營系統或營銷系統能夠便捷的接入畫像平臺的特定功能，使用畫像平臺的人群畫像。建設畫像平臺，需要實現對資料生產、數倉建模以及標籤資料體系的管理。我們基於資料倉儲模型，對畫像資料進行體系化的管理，主要有三部分：（1）資料域建模：首先基於資料倉儲對多條業務線的資料進行分資料域的建模管理。主要是對公司資料進行數倉的分層，並在數倉的 DWD/DWS 偏底層的部分，對我們的業務資料域進行分域的管理，以保證不同業務線的資料能有清晰的管理儲存以及位置查詢。（2）標籤計算和挖掘：有了基礎資料之後，需要進行標籤計算和挖掘，生產標籤。（3）畫像主題建模：生產的標籤會儲存在數倉的主題層。快看建設了專門的畫像主題，畫像主題對畫像平臺所有的標籤體系以及使用者標籤相關的資料，進行了建模和管理。再下面就是資料採集層，包括埋點平臺、業務日誌、業務 DB 資料以及三方資料。把資料採集上來，進行資料側的 ETL 清洗提取，轉化成資料倉儲模型裡面的基礎資料。一般來說，這是畫像平臺從業務側到資料採集側全鏈路的產品架構。
討論完產品架構之後，繼續探討另外一個話題，公司內部什麼樣的組織適合搭建畫像平臺，以及它的定位是什麼？（1）業務內自建平臺。在很多公司，一些比較大的業務線，是有能力去建設自己的畫像平臺的，特點是畫像平臺建設是服務於本業務線的，在本業務線內去使用。一般要求業務線能夠具備相對比較完善的資料平臺能力，資料倉儲建模能力以及一定的資料探勘能力，這些是進行畫像平臺資料生產的基礎。另外，業務內自建畫像平臺因為只服務於單條業務線，往往會和自己業務運營的營銷系統或者 BI 報表或者資料監控平臺等有相對比較重的耦合性。耦合性是指業務自建畫像平臺會在平臺內部把運營能力（比如說配置能力或者分發能力），營銷能力（比如 PUSH 或者說簡訊觸達）以及精細化運營和精準營銷的資料回收計算、指標展示、監控等功能都糅合到畫像平臺中。（2）中臺型畫像平臺。快看有自己的資料中臺，各個業務也沒有足夠人手建設業務內自建畫像平臺，所以快看的畫像平臺是由資料中臺部門建設的。它服務於多條業務線，每條業務線都可以基於自己的業務場景和訴求去使用。一個特點是平臺資料來源是來自於多條業務線，所以資料來源的標準性和一致性不好把控；另外因為業務和業務之間的差異很大，資料差異也非常大，不同領域資料模型的差異也非常大，所以數倉建模的複雜度是非常高的；再一個特點是中臺畫像平臺，要求平臺能力盡量和業務的運營系統，營銷系統或者其他的報表平臺能夠做功能的解耦，因為如果中臺畫像平臺和某一個或者幾個業務的業務系統能力耦合過重，擴充套件性就會不好，平臺產品能力過於定製化是非常不利於將來的功能擴充和迭代設計最佳化的。這是不同的公司在不同的階段可能會面臨的一個選擇，大家可以根據自己公司實際的痛點問題選擇合適的自建方式。
首先來介紹一下快看畫像平臺建設的背景，快看成立於 2014 年，是漫畫垂類下使用者體量最大的平臺，目前總使用者量近 3 億，主要業務有漫畫閱讀、二次元社群以及商業化等。（1）快看的業務發展非常快，業務線的數量和業務線的規模都在快速擴張，目前中臺支援了十多條業務線，公司還在不斷的孵化新的業務線，公司的業務規模也是不斷變化的。（2）從 2018 年、2019 年之後，移動網際網路市場的使用者量增長就非常緩慢了，再加上短影片行業的興起，使用者時間被短影片行業搶佔了很多，移動網際網路市場已經變成了一個存量使用者競爭的紅海市場。各個 ToC 的產品為了能夠吸引使用者、提升使用者時長，各個業務對存量使用者的精細化運營和精準營銷的需求越來越多了。前面的分析中可以看出各個業務對資料的依賴，對精細化運營操作的訴求，快看各個業務也會面臨這些問題和訴求。資料中臺作為公司裡面去統一承接各個業務，各種資料場景，各種資料類需求的部門，在長期的對接中，逐漸感受到大家對畫像標籤的依賴越來越重，因此從各個業務對畫像平臺的通用訴求中提煉出最常見的對於畫像平臺一些依賴的能力以及對標籤的依賴的需求。快看中臺從 2016 年初就開始建設，大資料平臺的能力是比較完善的。對於資料採集、資料 ETL、數倉建模這些方面都是有自己的模型以及方法論建設的，而且開發能力也相對比較完善。
上圖是快看畫像平臺的功能以及產品的介面，因為時間有限，分享的重點不在於我們每一個功能產品設計的邏輯，或者一個功能的具體實現，而是想著重的跟大家去介紹一下我們在建設中臺型畫像產品的時候，遇到的 4 個比較難的問題，或者說我們認為一些關鍵的點。我們的產品能力前面已經介紹過了，也都是比較通用的能力，因為我們做的是中臺型的畫像產品，建設目標就是為了滿足業務對畫像平臺、畫像標籤的通用需求。我們平臺的功能可以概括為：標籤管理、人群圈選、人群上傳、人群計算、人群洞察和人群包管理。接下來分享我們在快看建設中臺型畫像產品過程中遇到的 4 個比較有意思的問題。（1）實踐1：弱登入型別 App 建立裝置 ID 標識
第一個問題是弱登入型別 App 建立裝置 ID 標識。弱登入型別的特點是使用者不需要強制登入也能夠使用這個平臺的一些核心產品能力產品功能，像內容型和工具型的 APP，大概都會符合這個特點。為了使用者能夠快速使用我們的核心功能，提高使用者轉化，產生使用者的啟用留存，很少強制使用者授權登入，所以允許使用者不需要登入也可以使用 APP。但是，各個業務又希望能夠對新使用者以及拉活召回的使用者快速的產生深度連線，讓使用者能夠快速的產生興趣和粘性，這就需要做精細化運營或者精準營銷，而這些動作，都是要針對於非登陸使用者，基於裝置的 ID 做一個動作。所以裝置的唯一性識別在畫像的建設中極其重要。如果裝置的唯一性識別的準確性不高，將會產生比較大的問題。而提高裝置 ID 的識別度，有以下的難點：① Android/IOS 的 IMEI、IDFA、OAID 的獲取受限以及頻繁變更。Android 和 IOS 從系統層面對使用者隱私的保護機制是越來越強。以 Android 來說，從 Android 10 之後是不允許獲取使用者 IMEI 的，現在的新系統都是獲取不到的。以 IOS 來說，14.5 版本之後，獲取 IDFA 都需要彈窗使用者授權。在中國，華為、小米、OPPO、VIVO 等組成的廣告聯盟一起協作出了一個 OAID 作為廣告標識。上面這些 ID 或者不能獲取了，或者就是獲取的時候需要使用者授權，造成一定的損失；再或者像 IDFA 和 OAID 面臨頻繁變更的情況，使用者是可以主動重置的，包括重置系統，刷機，重灌 APP 等都可能造成 ID 的變更。這是是我們保證裝置 ID 唯一性最大的困難。② ID Mapping 的變更。各個業務希望基於各自對 ID 的依賴去做 ID Mapping。以廣告業務為例，廣告業務目前去做廣告投放或者廣告回傳效果監測的時候，對 IMEI 和 IDFA 的使用現在還是很重的。他們希望不管你內部使用哪種 ID，但是你需要能夠基於 IMEI 或者 IDFA 和本部門完成廣告投放方面的協作或者資訊的打通回傳。如果我們對裝置 ID 的獲取的覆蓋率以及它的變更無法精準識別，那當進行外部協作，比如與廣告業務的外部協作就會產生很大的折損，對效率造成影響。作為中颱部門，我們在構建畫像平臺的時候，首先需要解決這個問題，如果不解決，剛才提到的難點在業務側會產生很大的影響，我們的解決方案主要是兩個方向：① 第一，快看能夠維護每個裝置各個 ID 的對映和變更關係，我們把這些 ID 儘可能都收集上來並且去維護它的對映和變更關係，並且基於收集資訊去自建快看的 KKDID。生成快看自己的 ID 之後，我們對裝置的唯一性就有了自己的識別體系，對它的質量也有了自己的保證。② 第二，在建設的過程中，可以藉助行業內的第三方反作弊平臺，利用它的唯一 ID 的識別能力，提升自建裝置 ID 體系的準確性。我們在 Android/IOS 兩個平臺分別採取了很多判斷邏輯去構建自建的 KKDID 體系，在構建自己的 ID 體系的過程中，需要做非常複雜的唯一性識別和判斷。需要平臺根據自己產品的特點以及收集的使用者資料，制定適合自己業務的定製化判斷邏輯。下面列出一些快看自建 KKDID 後在公司內部的效果，這裡只列出重點，我們其實有完整的評估報告：① 第一，為安卓提升了約 2.2% 的 IMEI 填充率。比如我們有 3 億裝置，裡面有一部分安卓，乘以安卓的比例，然後再乘以 2.2%，這部分裝置原來是沒有 IMEI 或者 IMEI 的識別是有問題無法精準匹配的，但是透過唯一 ID 識別，可以把這部分 IMEI 的填充率提升上來。如果有很多重複裝置被識別成不同的裝置會導致安卓的 IMEI 填充率降低，但是我們透過裝置的唯一識別，可以提升其填充率。② 第二，對比第三方反作弊平臺，我們的唯一裝置識別率提升了 1.5%。我們行業內的第三方反作弊平臺，他們在裝置唯一識別上也是存在很多 bad case 的，我們在構建的過程中發現了這些問題，即使是行業內 Top1/Top2 的反作弊平臺。③ 第三，我們在搭建了 KKDID 之後，還做了 KDDID 和 IMEI、IDFA、OAID 之間的兩兩對映，提升了各個業務在不同場景下使用對接上的準確性。這是我們解決的第一個問題，也是我們構建畫像平臺的一個基礎。首先要能夠精準的識別唯一的裝置，然後才能去對這個裝置進行畫像。這裡重點提了裝置 ID，但不同的業務對裝置 ID 的重要性依賴度是不一樣。像很多商業化，使用者只有登入後才能進行商業化的操作，如果對它做精準營銷，只依賴使用者登入後的登入 ID 就可以了，反而不那麼關注裝置層面的畫像，所以需要根據不同的業務去思考這個問題。當然，KKDID 是一個通用能力，供大家參考。
接下來介紹第二個經驗，中臺型的畫像平臺對接的業務方非常多，會面臨如何管理非常混亂的資料來源的問題。為了解決這個問題，我們用了分層建模以及資料域和主題去分層管理的思路，特點是數倉有兩個明確的業務資料域層和畫像主題層兩個明確的分層。底層的業務資料域，DWD/DWS 層負責清洗和管理各個業務資料域內的明細層資料。以付費域來說，使用者或者會員的付費，我們會在付費資料域把付費相關使用者的行為全部在付費域裡面進行建模，然後建不同的寬表進行儲存和管理。對使用者域、流量域甚至其他域都是用同樣思路去建設的，不承擔直接的畫像計算或者挖掘任務。在這之上我們建設了專門的畫像主題，在數倉裡面對應的是 DM/APP 層，承擔著整個畫像平臺的畫像標籤體系的管理，以及標籤資料的儲存管理，以及寬表的建模。畫像主題的資料來源頭是各個底層的業務資料域，需要哪一個，可以從管理好的業務資料域裡面對相應的資料進行提取和應用。這樣做的優點是業務域的資料條理比較清晰，畫像主題的資料能夠統一管理，實現標籤體系和標籤底層資料的統一管理。這是資料的儲存和生產應用規範，能夠在資料生產流程中形成這樣一個標準，能夠提升標籤生產的效率。在數倉建設，比如一些資料產品建設的時候，如果面臨這類問題，解決方案可以通用。第二個經驗實現了對我們畫像平臺標籤生產效率的支撐。
作為中颱型畫像平臺，我們會自己生產標籤，同時各個業務線也有基於中臺或者基於自建的資料平臺定製化標籤生產的訴求。各個業務線生產的標籤能否在畫像平臺中使用呢？我們的第三個經驗就是能夠支援多業務標籤在畫像平臺裡面做增量融合。如上圖的左面部分所示，數倉裡面有各個業務自己的資料域裡面的資料，都做了數層分層管理和寬表建模的建設，業務開發同學或者產品同學基於建設好的資料，在業務內可以做一些開發和標籤的生產。比如增長業務、基礎業務或者廣告商業化業務，用自己業務資料域的資料，生產一些複雜的定製化的標籤。在這個過程中，中臺側可以定義標籤生產和融合的規範：比如標籤生產的命名、準確性、覆蓋率以及標籤取值（碼值）需要符合哪些規範；然後標籤內容的儲存位置、儲存形式、儲存格式也有一定的規範。業務線標籤生產完成後，中臺會有對應的標籤融合的任務，把業務生產的定製化標籤，自動融合到畫像主題。融合之後，還會觸發標籤的自動化管理，在標籤的體系中，把業務側生產的標籤也融合進去，做統一的管理。這樣做的優點是作為中颱，我們把畫像平臺的標籤生產能力開放給業務，能夠提升標籤的生產效率，也能夠給業務方的開發側或業務側進行賦能。
第四個是偏產品功能上的一個創新。在畫像平臺的迭代中發現，使用者除了對一些簡單標籤的使用之外，在業務的精細化運營、精準營銷的過程中，對非常複雜的標籤的使用是很頻繁的，希望我們能夠對很複雜的篩選條件做支援，分更多的維度對篩選的使用者做不同維度的計算。經過這部分功能的提煉之後，我們發現可以透過面向特定業務的某一個使用者的行為去做一些符合標籤型別的支援。上圖左面是我們畫像平臺後臺截的一個比較有代表性的例子，這裡的標籤是近 90 天使用者消費和充值明細，它是對使用者近 90 天的行為做了維度的聚合，並且支援把篩選條件也糅合到標籤裡面。我們在畫像後臺使用這個標籤的時候，就可以使用該標籤下面特定的條件做篩選，甚至做一些複雜的篩選條件。比如近 90 天的使用者，他的訂單日期相對於當前時間是大於 30 天的，然後訂單型別是充值型別，貨幣型別是人民幣，對這個人群的標籤，我們希望對它的金額維度做一個求和計算，得出求和後的結果，這是一個具體的例子。它的優點是提升了標籤計算的靈活性，能夠固化高複用的複雜標籤，降低開發成本。對資料產品來說，需要對業務高頻的標籤使用場景有比較好的分析和洞察，才能夠提煉出他對複合標籤的真正訴求，從而把複合標籤提煉出來。所以複合標籤的生產需要，對產品側的業務理解和分析洞察能力要求比較高，但它確實可以大大降低開發成本，提高標籤的複用性，在業務側看來這個能力是很方便的，可以對篩選條件和維度做很靈活的篩選和統計分析。下面分享一下快看畫像平臺的應用案例，這裡分享兩個例子。
第一個案例是助力使用者充值付費業務線的精準營銷。精準營銷應用畫像平臺之後，流程形成了一個營銷的閉環。（1）首先使用者可以基於畫像後臺去做人群包的篩選，對於不同的營銷活動，基於複合標籤或者特定標籤篩選出人群包。（2）在運營後臺，對人群包以及投放的特定活動做相應的操作配置，運營後臺透過畫像平臺的功能 API 把相應的人群包或需要依賴的資料拉取到後臺，基於我們營銷後臺的能力，對特定的人群包做特定的分發和營銷活動的操作展示。（3）對營銷活動的資料進行採集，生成 BI 報表。（4）運營人員可以根據 BI 報表中的指標資料觀察每一個營銷活動效果，根據效果的反饋，對自己的營銷活動方案或者對人群包去做出相應的調整或最佳化。這個閉環，在付費會員側營銷活動中的使用目前已經例行化了，也是使用畫像平臺的一個非常重的業務。上圖右側是在畫像平臺擷取的一個篩選條件的截圖。
第二個案例是快看作為內容型的平臺產品使用畫像平臺進行內容精準宣發的例子。精準宣發業務是指什麼呢？比如有一個新的漫畫作品，平臺想給其作者一定的扶持，讓它的受眾使用者能夠快速觸達，從而能夠對這個作品產生興趣開始閱讀，給作者和作品積累一定的人氣。這個操作過去經常出現的情況會對所有的使用者做千人一面的分發，所有的使用者看到的是同一個宣發的作品，這樣的做法，造成很多非受眾使用者也會看到，分發效率有很大的可提升空間。使用這個畫像平臺，就一定程度上可以解決這個問題。宣發運營側對內容精準宣發的流程是什麼？（1）基於畫像平臺去圈選出特定內容偏好人群包。使用者閱讀打分類下的使用者標籤裡面會有他的偏好，根據要宣發的漫畫作品的品類和特點去匹配相應偏好特徵的人群包，運營後臺基於畫像平臺的功能 API 去獲取人群包。（2）在運營後臺的配置中，配上相應的人群包和資源位，對該人群包的人群做定向的宣發。（4）根據 BI 報表的反饋和分析，驅動內容運營策做出相應的調整和最佳化。我們畫像平臺的功能是比較通用的，在廣告業務場景中以及渠道業務場景中，因為業務邏輯和流程的鏈路是非常長的，對畫像平臺的依賴會有很多偏定製化的需求。對於這樣的場景，建議在他們的廣告業務和渠道業務的資料平臺中去建立畫像模組，這個畫像模組可以和自己業務的資料產品做很重的耦合，因為它就是服務於該業務的。畫像模組可以把中臺畫像產品的基礎能力甚至基礎資料進行打通應用，這樣可以極大提升畫像建設速度，同時不需要關注畫像是怎麼生產，畫像標籤是如何管理的，畫像的功能 API 是怎麼樣的，只需使用可依賴的介面，把更多的精力去投入到自己業務側資料產品的流程和邏輯中。最後介紹一下我們總結的一些經驗，以及我們未來的發力方向。
（1）中臺型畫像，要重點關注業務側的通用訴求，做一些通用能力的提煉。（2）大資料平臺、數倉建模和資料探勘的基礎能力是畫像平臺的基本保障。這些能力是必備的，畢竟一旦涉及到畫像的話，資料量會比較大，使用者體量也比較大，對計算能力、資料採集、ETL 和建模能力的要求是很高的。使用的越重，這一側整個全鏈路的要求也會越高。（3）畫像平臺的核心能力是人群圈選、計算、洞察、複雜標籤支援、標籤融合體系等。（1）加強標籤的系統性管理，自動建立的效率更高一些，目前有一些人工操作和干預。（2）更完善的服務化能力建設。服務化是剛才提到的畫像平臺的功能 API 和查詢 API，服務的穩定性保障以及響應及時性都有一些最佳化空間。（3）實時畫像與離線畫像融合。目前實時畫像的應用場景比離線畫像要少很多，但未來實時畫像的應用會越來越多，因為現在大家已經不太滿足於 T+1 小時這樣的資料產出效率了，更希望在分鐘以內的延遲生產實時畫像。後面我們會加強實時能力，並與離線畫像進行一些融合。05
Q1：底層使用者 ID 生成的規則能不能分享一下？
ID 的生成規則，最基礎依賴是先要把所有的 ID 收集上來。需要首先和法務、使用者產品側去討論可以收集哪些 ID，因為不同產品的定位不同，能收集的 ID 也不一樣。確定了能收集的 ID之後，需要思考的第二個問題是不同的 ID 的變更頻次也即它的可靠性是怎麼樣的？首先安卓和 IOS 是有區別的，然後安卓和 IOS 內部每一個 ID 的變更頻次或可靠性也是不一樣的，這裡建議優先使用內部採集的 ID，對內部採集的 ID 優先使用可靠性更高、變更頻次更低的。如果可靠性更高的 ID 是空的或者有問題，再去找次優的可靠性低一些的 ID，經過這樣的一個優先順序的次序去逐步判斷每一個 ID 在我們的 ID 庫裡面是否存在過，和我們已有的唯一裝置是否有某一個 ID 的重合，這個是做裝置唯一識別的一個很重要的點。使用內部採集的 ID 做完優先順序的判斷之後，如果我們還採用了第三方的反作弊平臺，最後可以使用第三方反作弊平臺向我們開放他們內部的唯一 ID。我們使用他們的內部唯一 ID，在我們存下來的外部 ID 裡面做去重判斷，對我們自建 ID 的邏輯進行補充。基本上是以這樣流程逐漸的積累。ID 體系的建立，除了剛才提到的採集和規則的判斷，很重要的一點就是如何把歷史裝置的資訊回溯重建，因為歷史裝置資訊也是需要基於同樣的體系構建出來的，這是一個難點。另外就是如何能夠持續積累，並且唯一 ID 如何能夠在裝置上逐漸提升覆蓋率，只有有了足夠的覆蓋率之後，在公司內部才能產生足夠多的應用場景，覆蓋度不高的話，很多業務沒有辦法直接使用這個唯一 ID。A2：這個很依賴運營策略，體現了運營策略對於精細化的運營是如何理解的。重要的一點就是如何判斷運營策略是有效的，同時也不過度影響使用者。我自己的一個經驗是這樣的，對運營部門的精細化運營策略或者階段性的目標做評估的話，從這個部門的角度，可以建立一個完整的運營策略評估指標體系，而不是隻看運營策略的直接效果指標。比如透過 PUSH 希望能夠提升使用者的點選率，提升使用者的每天開啟人數。如果只看這個的話，透過 PUSH 頻次的提升，或者對 PUSH 的文案做一些技巧性的最佳化，是很有可能帶來效果的。但是如何減少對使用者的打擾，對 PUSH 的場景來說，需要加一些圍欄指標，就是限制指標，PUSH 不能夠導致圍欄指標的下降。比如使用者對 PUSH 開啟的長留（長期留存），比如接收到這樣 PUSH 訊息之後，對使用者 PUSH 的觸達率是否有影響。如果 PUSH 經常推垃圾訊息或者說很有欺騙性、誘導性的文案，但使用者又感受不到實際的資訊和價值，那麼他後面可能就把 PUSH 訊息接收關掉了或者說根本不看了，這樣肯定會影響未來的觸達以及 PUSH 點選的一個長期留存。所以我建議如果要減少使用者的打擾，我們沒有辦法從全域性去求每一個策略都考慮得非常深，而且也不可能盯得太細，但是我們可以用一些圍欄指標去限制運營側的人員去深度思考後再做出精細化運營策略的制定和執行，可能效果會好一些。Q3：公司從 0 到 1 搭建畫像平臺，標籤體系初期構建的時候有什麼需要提前注意的點嗎？A3：我可以大概的積累一下可能會有哪些方面我們踩過的坑。首先從 0 到 1 去建設，一定會伴隨著你對業務的逐步的理解，以及業務訴求方面的積累。如果我們是一箇中臺側，對於單個業務提的需求，我們需要能夠有一定的宏觀視角去看，它是屬於畫像平臺的哪些能力，或者說標籤體系的哪一部分有這樣的訴求，他的訴求是長期的需求，還是短期的需求。對於我們是要構建一個長期的能力支援，還是臨時性的一個支援，這個分析是蠻重要的。這對於我們畫像平臺的一些需求能力的提煉是一個逐漸的積累的過程。前期在對接單個業務的時候，從整個資料中臺側我們產品同學在遇到這類需求的時候，可以適當的考慮用一些臨時性的方案去支援臨時性的需求，然後業務的臨時性需求，有了一定的固定頻次去對接的時候，再去思考如何將它固化下來，以及是否適合固化到畫像平臺裡面。有一個經驗就是多個業務線裡面和使用者相關的需求，在前期都可以往畫像平臺構建的能力上多去思考能不能去做一些支援的。如果單個業務有很頻繁的對使用者這方面的一些畫像並且比較固化，畫像平臺的建設就可以逐步啟動去支援了。從產品側我們還需要考慮的一點，大資料平臺、數倉建模和資料探勘基礎能力，是畫像平臺的基本保障。在有了一個通用或者需要固化的需求之後，我們對產品也有了初步的思考和設計，我們還要從底層思考我們當前有沒有這樣的資料能力去支撐我們去做畫像平臺的建設，需要和開發側去做方向或者目標的討論，看他們能不能提供相應的能力和人員的支援。這可能是從 0 到 1 搭建的時候，對外以及對內的資料側需要討論的。如果我們屬於業務部門，想從 0 到 1 搭建畫像平臺，標籤體系的話有什麼要注意的點？我個人覺得如果這個業務是有一定規模的，包括人的規模以及業務體量都比較大的話，才是業務線內搭建畫像平臺的一個起點或者基礎。在搭建畫像平臺的時候，思路就不是做一個大而全的畫像平臺，可能要先跑一些畫像平臺的功能性的 MVP。畫像平臺哪個能力目前需求是最強烈的，使用者的使用會是最頻繁的，我們先把這個功能性的 MVP 跑通，這是我們業務內去搭建的一個原則。在業務內搭建的時候可以多和運營系統或者資料後臺多做一些聯動，去看看有沒有產品已經有了類似的能力或者規劃，如果有能力有規劃的話，我們和他們一起去分析，這樣的產品能力在哪做更合適，和哪些平臺打通互動，各自該如何定位。這些討論清楚也是我們從 0 到 1 計劃去搭建畫像平臺的一個基礎。另外業務內也非常需要關注業務內現有的資料能力，我們平臺能力是否足夠完善，否則可能我們做完了產品方面的思考規劃之後，發現專案沒法啟動，因為開發人力或者資料基礎是不足的。這是我覺得起步階段可能需要注意的一些點，包括我們過去也踩過一些坑。Q4：H5 的 Cookie ID 是否可以作為使用者標識，基於 Cookie ID 的標籤計算是不是有意義？A4：我們的很多活動都是基於 H5 做的，因為 H5 的開發短平快，一個活動下線之後也就不再用了，做到 APP 裡面成本會高，H5 的開發效率會更高，迭代速度也會更快。但它的一個問題就是 Cookie ID 的變更會很頻繁，而且 H5 頁面現在會面臨一個難題，現在很多 APP 內嵌了瀏覽器，很多 H5 頁面在自己內嵌的瀏覽器開啟之後，在自己的瀏覽器裡面很可能是有特定的 Cookie ID 的，那麼對於同一個頁面同一個裝置，我用 UC、用百度、用微信、用釘釘開啟，它的 Cookie ID 很可能是有很大差異的，或者根本就不一樣，我們用 Cookie ID 去唯一標識這個裝置的話，幾乎是不可能的。快看 APP 內嵌的 H5，我們有一套機制，H5 和我們安卓 /IOS 做資訊介面的打通，把我們裝置層面的 ID 一定要傳到 APP 內嵌的 H5 上。這樣，我們內嵌的 H5 的活動也好，或者說各種頁面，上報的很多資訊，其實都是攜帶了我們的裝置 ID 的，裝置 ID 會比 Cookie ID 的穩定性要高很多。甚至我們自建的 KKDID 都可以傳上來，當然這個依賴你們有沒有自建的 ID，它的穩定性會更高。對於很多快看 APP 外的 H5 頁面，沒有我們的裝置 ID 可以獲取。像小程式會好一些，對直接使用它的 Open ID，每個小程式都有自己的 Open ID 體系，都是可以獲取的，作為匿名使用者的一個標識是可以的。但是對非小程式類的採集就會很難，個人經驗，PC Web 或者 H5 頁面，它的使用者的訪問習慣是用完即走的，包括你的活動應該基本上也都是短期的。所以我覺得這類活動，我們的目標前期不要設定成期望使用者多麼頻繁，有多麼高留存，有次日、7 日、14 日都能夠使用我的 H5 頁面。我們更多的可以在使用者首次訪問的時候，就抓住使用者，啟用他的興趣，從而把他引導到我們的 APP，這是可以重點考慮的方向。因為不管是 PC Web 還是 H5，目前所有的資料平臺都是一個難題，你包括友盟也好、百度統計也好，他們對於這種 Web 類頁面的使用者識別以及使用者的一個累積，歷史使用者的識別都不重視，也沒有這樣的能力，所以我建議自建資料產品的時候，也可以吸取比較好的經驗，不用過度的去想 H5 頁面在站外的唯一使用者標識，以及後續如何長期去做使用者的識別，做精準分發。我覺得這個可能是一個行業難題。Q5：人群效果是針對單個業務場景的回收，還是已經做了通用功能，所有的場景都能用呢？A5：對於快看中臺的畫像產品，我們沒有做人群包應用效果的 track，因為每個人群包在業務內的使用場景以及使用邏輯，包括資料統計的指標以及報表展示的邏輯都會有挺大差異的，通用能力很難提煉。當然會有一些很基礎的效果的展示，但是我覺得意義並不大，對業務來說你給我了我也用不到，我更想看的是這個人群包在業務場景中，精細化的每一個關鍵鏈路的轉化漏斗也好，各種人群行為分析也好，做一個更精細深層次的洞察，這不是中臺型畫像產品能提供的，所以我們是沒做這個能力的。如果想對你們的精細化運營效果做精準 track 的話，根據快看資料中臺產品側的經驗，其實可以從分析師和資料產品側協作，去把你們特定的營銷活動的整個的資料產品側的邏輯梳理一下，然後用 BI 報表或者說自建報表的形式，把它的整個分析模型以及它的核心指標固化下來，這個可能是一個更有效的一種手段。Q6：人群精細化運營中人群的覆蓋度和準確率是如何進行平衡的？A6：這個應該是基於精細化運營在業務側應用的角度去問我們如何去做人群圈選，能夠對我們精細化運營的這些活動或者場景產生更高的準確性，同時就是整體的運營效果會更好。所謂的精細化運營，他一定會越做越細，我們能夠在我們運營的過程中逐漸發現人群裡面存在的規律，就是哪一類人有什麼樣的規律，這些規律會以什麼樣的規則去確定下來這一人群，它是一個應該越做越細的過程。為什麼會需要這樣？因為精細化運營如果始終處於某一個使用者運營的力度上，就會眉毛鬍子一把，始終在這個力度上，我們對人群的區分始終不會做得更細。我們很多活動的策略，針對的人群不一定是它非常精準的受眾人群，所以效果可能會存在一定的瓶頸。我個人的經驗就是我們在運營的過程中，對每次精細化運營效果，人群投放效果多做一些分析，為什麼有的投放沒有效果，這部分沒有效果的人群和有效果的人群，有一些什麼樣的差異。我們找到的差異就是我們下次精細化運營投放的時候，篩選人群包可以多加的規則，下次投放的時候加上這些篩選規則，人群的投放會更加的精準，效果也會好一些，轉化率也會高一些，業務的指標可能也會更高。這裡面又引出一個問題，我們做的越來越細的話，這些人群的一個覆蓋率就變低了，我們活動效果的總 UV 或者說我們的總的 GMV 或者總收入下降了，這也不是我們想要的效果。能不能平衡？其實我覺得做的越細和覆蓋率指標它不是矛盾的，首先做細的過程中，會逐漸細化出越來越多的人群包，不僅是對原來的人群包加條件讓這個人群包越來越小，而且是建立越來越多精細化的人群包。一個好的方向，使用者存在的特徵，我們認識的越來越細，透過這些特徵我們篩選的人群包越來越精準，數量越來越多，當然最好他們之間的重合度會低一些。不同的人群包之間是明顯的特徵差異，可以針對他們做更加有效的策略的制定和投放。這樣我們就能夠兼顧使用者人群的覆蓋性以及策略的有效性。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/70024420/viewspace-2939564/，如需轉載，請註明出處，否則將追究法律責任。