從0到1,快速實現用戶群定義與查詢器設計

PMBear

本文筆者將根據客流軌跡分析產品的用戶群定義、查詢器組件的設計的實踐經驗來與大家分享:如何快速實現用戶群定義以及查詢器設計?

關鍵詞

查詢器用戶群定義,諸葛IO內容分析,2B產品,數據分析產品

最近,筆者指導果果同學完成了一個客流軌跡分析產品的用戶群定義、查詢器組件的設計。在這個過程中,果果同學表顯出了這樣幾個問題:

  • 對於組件的套路缺少本質的認識(這是最關鍵的);
  • 組件邏輯不清晰,設計存在歧義;
  • 依壺畫瓢,組件流程不閉環,查詢場景不能全覆蓋;
  • 粗枝大葉,字段未做明確,開發無從下手。

今天咱們就來說說“客群定義”與“篩選”的設計方法和規範!

應用範圍

  • 用戶分析類產品(諸葛IO、易觀方舟等)
  • LBS客流分析類產品(客流軌跡分析平台、高德位智等)

三大板塊說清設計套路

從0到1,快速實現用戶群定義與查詢器設計

(查詢器組件設計框架)

什麼是對象?

——作為一款用戶分析產品,對象當然是人!只要不涉及到人的範圍變小,都是對象定義的一部分。時間或是其它的條件,只是分析同一群人在不同時間的變化,並沒有改變用戶群的範圍。

什麼是分析項?

——就是要對已選擇人群,進行何種分析。分析項與具體的功能模塊緊密相關,例如漏斗分析,那麼分析項就是不同的漏斗實例。

什麼是篩選?

——對指定的用戶群進行指定的分析項分析后,如果人群範圍依然過大,則需要通過篩選,縮小用戶群範圍。

什麼是細分?

——對指定的用戶群進行指定的分析項分析后,如果粒度依然過高,則需要向下鑽取。例如我們看到的是全年齡段的用戶數趨勢圖,如果按年齡細分,將會看到不同年齡段的趨勢圖。

舉一個鮮活的例子:

張三去醫院體檢,查了心電、驗了血,不滿服務態度,打了醫生。

在這個語義中明確了:

  • 對象:張三
  • 檢查項:心電、驗身
  • 行為:打醫生

解析諸葛IO

接下來咱們就用這個套路來分析一下諸葛IO,看看他們是怎麼實現的。

從0到1,快速實現用戶群定義與查詢器設計

“優秀者抄襲、偉大者偷竊”

明確結構

先別著急去分析諸葛IO的查詢場景、邏輯以及設計理念,在你沒有深入的去了解組件的每一個細節前,得出的結論都不會太準確。對於這類數據較多,結構較複雜的組件先進行拆解,使用思維導圖工具十分方便。

接下來,我們使用套路中的組件四要素來繪製每個要素的思維導圖。

這個過程的要點是:

  • 不要放過每一個細節,對每一個狀態、字段、數據都需要分析其來源、用處(當然,明顯同一類的選一個代表就可以,節省時間);
  • 將每一個要素內的邏輯整理成更為簡潔清晰的邏輯表達式。

自定義用戶群(對象)

在分析框架中,組件的第一要素就是分析對象,諸葛IO是一款用戶行為分析產品,因此將對象實例化后就是“用戶群”。

從0到1,快速實現用戶群定義與查詢器設計

(諸葛IO自定義用戶群 產品截圖)

從0到1,快速實現用戶群定義與查詢器設計

(諸葛IO 客群定義信息結構)

通過對前述結構的理解,我們可以用如下的表達式來進行歸納:

從0到1,快速實現用戶群定義與查詢器設計

每一類表達式的詳情如下:

從0到1,快速實現用戶群定義與查詢器設計

用戶定義設計的要點是:

  • 可以將用戶定義理解為用戶畫像,用一組畫像信息來定義一個客群;
  • 作為用戶畫像,最基本的需要包含用戶屬性、用戶行為事件;
  • 畫像信息能夠實現用戶描述的全場景覆蓋;
  • 表達式的邏輯是閉環的,且利於開發的實現。

分析項

諸葛IO分析項較為全面,有如下的一些大項:

從0到1,快速實現用戶群定義與查詢器設計

大項下會有實例可選擇,例如指標分析舉有:

從0到1,快速實現用戶群定義與查詢器設計

分析項目來源於產品的需求,PM 需要根據自身產品的分析需求,建立分析項體系。

篩選

在多維的數據中,增加新的維度進行篩選,本質上是對數據的分片。諸葛IO通過長期的產品演進,已經具備豐富的、成體系的篩選條件。對於新產品,可以不用着急上全,逐步演進,PM的對產品的理解也需要在演進的過程中去提升。

從0到1,快速實現用戶群定義與查詢器設計

(諸葛IO 篩選 產品截圖)

從0到1,快速實現用戶群定義與查詢器設計

(諸葛IO 篩選 功能信息結構)

從思維導圖的折解中我們查看到可以統一歸納為如下表中的表達式:

從0到1,快速實現用戶群定義與查詢器設計

在這裡有一個很重要的細節,也是一個在我們自己工作時,細化方案的一個重要部分——事件的屬性!

諸葛IO事件中定義了多種行為:

從0到1,快速實現用戶群定義與查詢器設計

每一類行為也有着不同的屬性:

從0到1,快速實現用戶群定義與查詢器設計

這些定義好的行為及行為屬性在自定義用戶群中的事件中也會使用到。因此,在自身產品過程中,定義清晰的行為及屬性是PRD中十分重要的組成部分,需要產品經理結合自身業務的需要,制訂具有意義的用戶行為。

篩選設計的要點是:

  • 不同的分析項可能會存在不同的篩選條件,需要對每一類分析項進行單獨的思考。
  • 不同的行為,一般都會有不同的屬性,需要為每一行為建立屬性。

細分

細分的本質是對數據的鑽取,這是數據分析領域的一個名詞,前提是產品的數據具e有足夠的厚度,而不止於太過於扁平。注意是厚數據,而不是寬數據,寬數據在數據分析領域中使用的方法是切片!

從0到1,快速實現用戶群定義與查詢器設計

(諸葛IO查詢器-細分 功能信息結構)

“細分”的功能信息結構與”篩選“相似,就不再詳細的講解。

在沒有進行細分的時候,趨勢圖上只有一根曲線,但是當我們選擇了按性別進行細分時,在趨勢圖會出現三根曲線——男性一根、女性一根、總量一根。

當我們掌握了這些事實后,我們要來尋找其中的邏輯關係

清晰的定義是團隊協作的保障

在完成了信息的採集及歸納后,咱們要開始下定義了,明確的定義既有利於PM不斷的思考問題,升華認識。也有利於團隊內部的溝通,保證理解一致性。

這個過程的要點是:

  • 保持用語的在全文一致性;
  • 對每一個名詞進行詳細的定義及舉例說明;

用戶

諸葛IO對於用戶的理解是從三個維度:用戶屬性、用戶行為序列、頻次。

事件

用戶在產品上的行為,簡單的說就是點擊在不同頁面功能中不同的意義,例如,在登陸功能中的點擊就是”登陸行為“,在支付頁面,就是”付款“行為,但頁面停留不是一種行為,因為用戶實際上什麼也沒有做。

時長、頻次

——屬於用戶的屬性而非行為。

功能和數據中找到邏輯:

從0到1,快速實現用戶群定義與查詢器設計

(諸葛IO 查詢操作 流程圖)

從0到1,快速實現用戶群定義與查詢器設計

(邏輯圖)

在諸葛IO的組件設計中,選擇用戶群對象作為流程的第一步,但在處理時並不是展開與其它的查詢條件同時運算。而是將用戶群中選擇的條件進行運算得到用戶群,再分析中間用戶群在具體分析項中的表顯。

同時,咱們還需要理解數據關係:

在查詢器及自定義客群的設計中,本質上就三部分數據:用戶屬性、行為序列及屬性、觸發環境。

  • 觸發環境是與用戶無關的數據,因此只會出現在查詢器功能中,不會出現在自定義客群中。
  • 用戶屬性、行為序列及屬性會出現在自定義客群及查詢器中。

在整個查詢的過程中需要注意分析的對象只能有一個,如果在同一個分析功能中存在多個分析對象,則會存在歧意,無法清晰的理解行為等的作用對象。

理解參考品的設計理念

我們可以看到一些其它的互聯網用戶分析產品(如易觀方舟)對於自定義客群也採用了“用戶屬性+事件+頻次”的設計方式。我們可以這樣來理解:對用戶的描述不僅只是行為和屬性,與用戶密切相關並且對分析者十分關注的信息都可以,並且應當用於描述用戶。

  • 始終將”人“作為分析的對象;
  • 在事一個分析功能中只能同時出現一個分析對象;
  • 用戶的定義本質上就是用戶的畫像,因此不局限於屬性+事件,可以加入更多與業務相關的數據進行描述;
  • 減少誤操作,提高心理預期,高耗時操作通過按鈕觸發。

查詢器與用戶群定義設計的總結

說說我們自己的實踐過程吧!

查詢器的設計的核心是:根據業務的需求構建全場景覆蓋的條件表達式,以及構建沒有歧義的運算邏輯。

根據咱們的實踐經驗,具體的設計要點有:

  • 理清對象 |在設計的初期我們將客群與空間混為一談,導致同時出現空間對象與客群對象;
  • 運算邏輯要可行| 構建一個可行無歧義的表達式,否則程序猿會和你急;
  • 確定對象的畫像 |在設計的過程中,我們一段時間未能完全清晰的理解,從那些維度描述對象,盲目抄襲;
  • 根據查詢場景構建查詢維度 |我們的產品既需要以空間為對象也需要以人為對象;
  • 閉環的表達式 | 查詢最終都是通過表達式落地,對於表達式及其屬性、值的設計一定要是閉環的。

這些都是 PM 工作過程中常見的坑,需要PM在交付成果前反覆的盤它。

對象定義的要點是:

  • 從行業中去尋找共識 | 先別花太多的時間去思考,去看看行業里大家如何制訂對象的畫像;
  • 找出差異進行訂製 | 世間沒有完全一樣東西,我們需要理解自己分析對明與其它產品的差異,尋找適合自己的定義方法。

在初期咱們使用屬性、事件行為進地客群的定義,在過程中,我們逐步理解到客群的定義本質就是客群的畫像,通過畫像來篩選出所需的客群。因此,我們開始將關心的顧客信息加入到畫像中,形成了我們自己即有共性,又獨特的對象定義體系。

我們是一款客流軌跡分析產品,就叫“CK”吧,產品含蓋三個板塊:看板、場分析、顧客洞察。

從0到1,快速實現用戶群定義與查詢器設計

(功能需求示意表)

不同於互聯網產品,“CK”是一款面向線下商業體的分析產品,面向的是實體,存在:“人”、“貨”、“場”三個維度的分析需求。對於“貨”的分析超過了我們現在的能力,因此“CK”即需要從“場”的角度出發(商場分析),也需要從“人”的角度出發(用戶洞察)。

從0到1,快速實現用戶群定義與查詢器設計

當我們心有了這個框架套路,一切就簡單了

明確查詢場景

建立明確的查詢場景是設計查詢器的起點。

從0到1,快速實現用戶群定義與查詢器設計

明確的查詢場景可以用來驗證設計是否能夠滿足,但這只是事後驗證,在事前指導設計上,查詢場景的價值在於:通過歸納得到滿足需求,系統中需要的查詢條件。

從0到1,快速實現用戶群定義與查詢器設計

(需要具備的查詢項示例)

About 客群定義

在模板中我們給出了:屬性、行為,做為用戶群描述的兩個維度,在參考品諸葛IO中,增加了頻次這個維度。

對於線下商業體有一條準則:吸引顧客多來商場、增加在場內的停留時間,以達到增加消費的目標。試想:逛10分鐘和逛兩小時,誰更容易產生消費行為?

將這個準則翻譯過來就是:到訪頻次、駐留時長,這是描述顧客的關鍵要素,因此,我們定義的顧客群包含四個維度:屬性、行為、頻次、時長。

About 對象

“CK“的查詢器設計有一些差異,主要集中在對象上。

  • 當進行商場分析時,分析的對象是”場“的要素:商場、樓層、店鋪、POI、業態;
  • 當進行用戶洞察時,分析的對象是”人“的要素:差異化顧客群。

如果不進行區分,在”CK“產品中將會同時出現兩個對象,顧客群對象、場內空間對象。

About項

兩個板塊都根據自身的需求,擁有不同的分析項。商場分析以空間分析為主,包含:動線分析、熱力分佈、路徑分析等。

用戶洞察以顧客群分析為主,包含客群分析、客群分佈等。

About篩選

在互聯網產品中,篩選往往有觸發環境、用戶屬性、事件屬性等多維數據。出於對我們自身技術特性的考慮,無法獲了到觸發環境,因此我們僅從用戶屬性、事件屬性上去設計篩選。

About 細分

當前我們的數據層級並不深,數據較為扁平,不需要再進地細分。因此未考慮此功能,待”CK“產品將來更上一層樓,數據層次更加豐富時再進行設計。

 

PMBear

发表评论