用户運營之觸達系統搭建

編輯導讀:用户運營的方式有很多,但是都是以用户為中心,根據用户的需求來制定的。觸達,就是其中的一種,在適當的時機,把信息以恰當的方式展示給用户。本文作者從自身工作經歷出發,分析如何從0到1搭建觸達系統,希望對你有幫助。

用户運營之觸達系統搭建

基於自己搭建觸達系統的相關經驗,總結從0-1搭建觸達系統的一些想法。本篇更多的還是探討基礎功能搭建,從1-100的完善本篇暫未涉及。

一、業務簡述1.1 用户運營與觸達

什麼是用户運營,從百科的定義來看:

以用户為中心,遵循用户的需求設置運營活動與規則,制定運營戰略與運營目標,嚴格控制實施過程與結果,以達到預期所設置的運營目標與任務。

在這裏有三個關鍵詞:用户、活動、目標。

這裏我們借用一下增長裏的AAARR概念説一下用户運營的目標:

AAARR模型

要想達到以上目標,需要對用户進行精細化的運營。首先需要了解自己的用户,而海量用户“逐一清點”顯然是不現實的,所以我們需要通過用户的基礎屬性和行為將用户分羣。

活動形式就多種多樣,包括促銷、優惠券等電商基礎玩法、各種遊戲化的玩法等。

而觸達,簡單來説,就是把用户需要的信息,在合適的時機,以恰當的形式展示給用户,它是將活動和用户進行連接的一種方法。

1.2 觸達的分類

1.2.1 通過操作方式分為自動化和手動

手動,是運營人員在日常活動中,根據當前的目標,結合活動向用户定向發送相關營銷類信息,一般有單品的活動信息、或一些品類、公司級的促銷推送;

自動,一些是系統類的推送,比如交易物流、客服助手等消息通知,還有一些是可根據一些手動化效果比較好的場景,做成可配置化提取。

1.2.2 通過觸發形式,可以分為定時型和觸發型

定時型為指定固定時間發送。

觸發型為指定條件進行觸發。本篇主要講述定時型任務。

1.3 觸達系統概況
用户運營之觸達系統搭建

業務藍圖

搭建一個觸達系統主要分為以下幾個重要部分:

  1. 觸達任務管理:增刪改查、審核、發送等。
  2. 自定義用户羣:基於一定條件進行用户分羣。
  3. 數據反饋:觸達一定要有數據閉環,基於數據反饋業務觸達如何進行提升。
  4. 場景設置、A/B測等工具輔助指標提升。
二、觸達任務管理2.1 觸達任務的主要信息
用户運營之觸達系統搭建

觸達任務的主要信息

2.1.1 形式決定時間的選擇

定時型可以分為單次和週期。單次需要固定一個時間點,週期則是指定在一個時間段內的週期反覆的時間點,比如每天9:00,或每週一9:00。

觸發型則需要規定觸發的活動時間段、觸發條件、

2.1.2 發送人羣

本次設計把人羣是做的單獨模塊,好處其實在於後期擴展中,人羣的可複用性。比如,我們針對同一羣人,可以在這一時期做觸達,後期做一些單獨的促銷。也可針對人羣做一些人羣的畫像,方便我們制定多種運營策略。

2.1.3 渠道決定內容

比如短信,主要注意字數和短鏈接的問題,還可能存在部分廠商限制運營類短信,近期有消息要出台相關政策限制運營類短信的發送,站內信的模塊可能會越來越重要。

比如push,除了標題和內容吸引用户的點擊外,落地承接頁一定要注意留住用户,畢竟push的每一次點擊都比較難得。

比如微信生態一定注意微信的要求,具體解讀不在這裏解讀了。

2.1.4 藍色是必須內容,綠色是非必須

定向優惠一般是結合券和促銷,對於人羣同時完成定向促銷+觸達的設置;

目標則是除了我們基本統計外,業務人員可能對於單條任務有些外需要統計的數據,則可針對此任務設置一個目標,後期可查看完成目標的人數。

2.2 防擾設計

2.2.1 全局觸達限制

限制用户總共收到的任務數、各渠道收到的任務數。需要分析用户收到消息與退訂率之間的關係,制定此條件。

另外注意,如果多個任務設置在同一時間點發送,需要根據相應策略進行排重篩選。可根據人羣的偏好表現來決定觸發在哪個任務中。

2.2.2 單任務限制

對於一些週期性任務,在滿足全局觸達限制的基礎上,還需要限制此任務的觸達,避免出現一個用户週期內不斷收到同樣的消息觸達。比如本週每天對於昨天加購未購買的用户進行引導購買,全局觸達限制1天1條,但是此任務循環發送,只想讓單用户在本週收到一條,可限制此任務7天收一條。

2.3 資源管控

如果是內部使用,需要注意部門的預算和資源控制。

如果是開放給商家,需要先進行短信資源包的購買,而push一般不對商家進行開放。如果有投放平台的相關功能,可考慮在整體投放策略中增加push的資源,但不對商家單獨進行開放。

2.4 審核和權限

主要依據公司內部規定執行即可。系統可複用公司內部現成的審核和權限系統。

三、兩種“觸達用户篩選”的設計思路3.1 通過基礎標籤和行為信息來圈定用户,比如:神策

神策將篩選用户的條件分為三類:用户屬性、用户行為和行為序列。行為序列是一種基於用户行為的更高級的篩選,從根本上來説還是用户屬性和用户行為。

用户運營之觸達系統搭建

神策的觸達用户篩選

用户屬性:用户的基礎屬性和標籤。

用户行為:基於神策的行為埋點事件,並可根據事件屬性進行篩選。

支持組間的且/或關係,以及組內多個條件的且或關係,以及添加下篩選項的且或關係。

3.2 將行為標籤化圈定用户:京東為商家提供的功能

將所有行為標籤化,簡化操作,多個條件且的關係。

用户運營之觸達系統搭建

京東商家的用户人羣篩選

3.3 兩種方式的對比
用户運營之觸達系統搭建

對比

3.4 實際操作中的設計

在實際操作中,目前做的是為公司內部人員使用的,筆者選取了兩種方式的優點進行了結合。

需要注意的事,為了更好理解,我們將用户行為和交易信息進行了拆分。

  • 用户行為指註冊、登錄、瀏覽、搜索、收藏、加購等售前和售中行為,主要篩選項為商品和頁面信息;
  • 交易信息指提交訂單、支付、訂單完成、取消、退換貨等售後行為,主要篩選項為商品和訂單的信息等;

踩過的坑:

在第一版設計:開始的設計和京東/淘寶一樣,左側點擊在右側添加一個篩選條件,標籤的順序是點擊的順序。

由於<1>各條件的計算先後順序後影響結果;

用户運營之觸達系統搭建

不同計算順序的結果差異

<2>如果按照頁面的先後順序,會出現【用户屬性】且【用户行為】非【用户屬性】這樣的組合。開發沒辦法一次性的在一個表中把數據都取出來做且或非的關係,其中有的表需要取多次,會影響人羣計算效率。

故我們考慮業務的理解成本和技術表設計合理,將固定標籤類的放在一組,將行為信息放在一組。兩組之間有且/或/非的關係。組內的條件也有且/或/非的關係。

第一版設計:

用户運營之觸達系統搭建

未分組,按點擊順序

第二版設計:

用户運營之觸達系統搭建

按照行為和標籤分組

四、數據統計4.1 基礎數據

觸達任務的基礎考核數據有發送量、點擊量、點擊率、產生轉化的用户數、轉化率等。點擊率主要取決於觸達的內容,而轉化率則是承接頁主要考慮的問題。統計時,還要注意渠道的區別,短信中的url一般會較少的點擊,可以考慮接收到短信的用户與未接收到短信的用户的活躍變化差異做對比。

一般來説,任務發送者僅考慮單條任務的轉化效果。而運營方則需要考慮一定週期內的觸達效果,故還需要為運營方提供相應的週期內的觸達效果統計,注意任務之間的效果排重。另外,運營方還需要關注退訂率的變化。這也是運營方需要注意的指標。

4.2 A/B測

A/B測是對於觸達提升比較好用的工具。網上關於a/b的説明很多。一般這是數據部門開放的一個通用化的工具,考慮觸達系統和A/B系統做對接即可。如果公司還沒有a/b測工具,可以考慮人工做一些A/B策略,一些基本的A/B測的方面有文案的測試、人羣的測試等。在這裏就不贅述了。

五、自動化觸達任務

自動化觸達任務主要分為兩大類,一種是通知類消息,是由業務系統觸發,比如訂單通知、客服消息等,此類除了對外的統一消息接口外,還需要考慮消息模版的設計。

第二類則是自動化的運營類消息。此類一般是針對一些人工發送效果比較好的任務,做成系統自動化發送,但一般這種都需要藉助算法。

舉個例子,在日常的發送中,我們發現單品類的秒殺活動的推送的點擊率和轉化率效果都比較好,想做成自動化的發送形式。我們會基於全站的秒殺活動計算優質的秒殺,然後找到合適的用户,基於用户的歷史數據,計算最優的商品進行推送。在承接落地頁除給予最優品的最大曝光之外,還會接推薦模塊,多一些轉化用户的機會。

自動化策略的兩大好處:第一是藉助算法提升轉化率,第二是節約運營人員人工成本。

六、總結

系統還處於從0-1但是距離100還有很大的差距的過程,希望有機會迭代優化和大家繼續分享踩過的坑。

本篇為系統的搭建,關於運營策略基本沒有涉獵。

觸達只是用户運營中的一小部分,但也是屬於比較重要的功能。此篇也基本在於push和短信,接下來會繼續思考在站內用户的路徑上增加觸達的相關策略。希望能和大家做探討。

本文由 @舉個栗子 原創發佈於人人都是產品經理,未經許可,禁止轉載

題圖來自 Unsplash,基於 CC0 協議

版權聲明:本文源自 網絡, 於,由 楠木軒 整理發佈,共 3471 字。

轉載請註明: 用户運營之觸達系統搭建 - 楠木軒