在去年負責過用戶的召回，用戶召回其實很大程度上就取決于消息推送，即：將合(he)適(shi)的(de)內(nei)容通過合(he)適(shi)的(de)渠道在(zai)合(he)適(shi)的(de)時間推送(song)個合(he)適(shi)的(de)人，合(he)適(shi)的(de)內(nei)容、合(he)適(shi)的(de)渠道都(dou)是挺簡單(dan)的(de)事，難點就在(zai)合(he)適(shi)的(de)時間，以及合(he)適(shi)的(de)人（例如(ru)激活 App 次數以及連續兩周(zhou)下降(jiang)的(de)大 V 用(yong)戶）
最近又體系化的優化過消(xiao)息推送(song)，所以決定來聊(liao)聊(liao)消(xiao)息推送(song)。
對于消息推送優化，我們先有個明確的目標，是優化最終效果，但最終效果=推送人群 * 推送成功率* 觸達率 * 點擊率 * 用戶與內容匹配度。
所以想要(yao)優(you)化(hua)(hua)最(zui)終(zhong)的推送(song)(song)效果，就(jiu)得從以上(shang)每(mei)一步都(dou)進行優(you)化(hua)(hua)，及(ji)優(you)化(hua)(hua)公式右(you)邊的每(mei)一個元(yuan)素，及(ji)增加推送(song)(song)人(ren)群、提升推送(song)(song)成功率、提升觸達率、提升點擊率、提升用戶與內容匹(pi)配(pei)度，這樣一拆解下(xia)來目標是(shi)不是(shi)明(ming)確多了？
那下面(mian)就(jiu)將消息推送按時間順(shun)序列(lie)需要的操(cao)作(zuo)講(jiang)一講(jiang)，看哪些步驟可(ke)以提升上(shang)面(mian)的數字，按時間順(shun)序可(ke)分(fen)為：
——推送前：消(xiao)息制作、選擇推送人群、選擇推送渠(qu)道
——推送中：消息推送
——推送后：消息收到(dao)、消息點(dian)擊、數據反饋（根(gen)據數據反饋可進行優化）
文章其實(shi)兩(liang)條(tiao)線，一(yi)(yi)條(tiao)是(shi)將(jiang)消息推送(song)按公式拆(chai)分成觸(chu)達(da)率(lv)、點擊(ji)率(lv)、轉化率(lv)等，一(yi)(yi)條(tiao)是(shi)將(jiang)消息推送(song)按時間維度拆(chai)分成每一(yi)(yi)步，然后可以(yi)在每一(yi)(yi)步來看，可以(yi)怎樣(yang)優(you)化第一(yi)(yi)條(tiao)線的各種數據
提幾個需要注意的(de)(de)點，推送的(de)(de)封面(mian)圖(tu)怎么(me)樣？推送的(de)(de)標(biao)題質量(liang)是否(fou)(fou)(fou)能吸引？推送內(nei)容(rong)(rong)質量(liang)怎么(me)樣？標(biao)題、內(nei)容(rong)(rong)是否(fou)(fou)(fou)熱點內(nei)容(rong)(rong)？標(biao)題、內(nei)容(rong)(rong)是否(fou)(fou)(fou)跟當下相關？標(biao)題、內(nei)容(rong)(rong)是否(fou)(fou)(fou)考(kao)慮手機尺寸來顯示？是否(fou)(fou)(fou)定義好landingpage？
這一步要做到選擇對應人群其實挺難的，需要在推送系統上創建各種標簽，每次通過選擇這些標簽取交集、并集等來決定推送用戶。
也(ye)可(ke)以(yi)通過創(chuang)建(jian)用戶集，來避免(mian)每次都(dou)需要重新(xin)選(xuan)中(zhong)多個標簽的交集或并集，例如選(xuan)擇等級大(da)于 3 級 ∩ 男 ∩ iOS 系統(tong) ∩ 最近三(san)天(tian)有付費行為的用戶，如果你(ni)常常會給這類用戶發送(song)消息，則可(ke)以(yi)將其創(chuang)建(jian)一個用戶集，每次推送(song)時選(xuan)擇那個用戶集即可(ke)。
再來說說這些標簽應該如何來定義。
網絡上說的最多的當然是通過人口學角度來分，例如城市、年齡、性別等，但實際在做的過程中會發現，如果僅以人口學角度來分的話，會顯得特別不合理，還需要增加很多和業務相關的分類，例(li)如在(zai)直播(bo)中有(you)打賞(shang)、在(zai)動態中有(you)打賞(shang)、在(zai)私聊中有(you)打賞(shang)。這些(xie)篩選條件(jian)一共(gong)可分(fen)為：
——版本條件(jian)：可篩選具體的(de)某(mou)個(ge)版本
——系統(tong)條件：可篩選 Android、iOS
——用戶條(tiao)件：人(ren)口(kou)學的(de)一些(xie)維(wei)度，如年(nian)齡、性別、城(cheng)市等
——賬戶條件：總(zong)賬戶，或某個(ge)業務的賬戶余額，例如篩選錢包(bao)是(shi)否還(huan)有(you)錢、背包(bao)是(shi)否還(huan)有(you)禮物等
——付(fu)(fu)費行為：是(shi)否有付(fu)(fu)費，付(fu)(fu)費多(duo)少，在哪個渠道付(fu)(fu)費
——活(huo)躍行(xing)為：激(ji)活(huo) App，發(fa)動態等——內容消費：進入直播(bo)間(jian)，動態進行(xing)互動等
具(ju)體會怎么會根據你(ni)自己的產品來決定(ding)的，篩(shai)(shai)選(xuan)條(tiao)(tiao)件一般由三部分構成(cheng)：大(da)篩(shai)(shai)選(xuan)條(tiao)(tiao)件、子(zi)(zi)篩(shai)(shai)選(xuan)條(tiao)(tiao)件、時間(jian)，例如(ru)付(fu)費(fei)行為可篩(shai)(shai)選(xuan)有或無，可在(zai)子(zi)(zi)條(tiao)(tiao)件中篩(shai)(shai)選(xuan)付(fu)費(fei)金額范圍，以(yi)及付(fu)費(fei)金額渠道（例如(ru)直(zhi)播間(jian)、動態、私聊），在(zai)時間(jian)維度可篩(shai)(shai)選(xuan) 1 天、2 天、3 天......以(yi)及自己輸(shu)入天數。
篩選條(tiao)件的顆粒度是(shi)否要做的這么細，根(gen)據(ju)產品階(jie)段以及具體產品來決定，沒有一個通用的公式。
除了以上篩選標簽推送，也需要支持輸入 ID進行推送
推送渠道選擇(ze)挺簡單的(de)，一般(ban)就那幾個，短信(xin)、站內信(xin)、郵件(jian)、push
對(dui)于大一點的公司，發送推送消息(xi)可能(neng)(neng)需(xu)要審批好幾層(ceng)，而不是(shi)創建后就能(neng)(neng)立馬(ma)推送出去。
還(huan)有就是對用戶(hu)來說的(de)時間(jian)限制，需要限定哪(na)(na)些時間(jian)段不能推送，哪(na)(na)些時間(jian)段可以推送，這(zhe)需要根據自己產品(pin)的(de)用戶(hu)具體使(shi)用場景來決定，但(dan)一(yi)般是 7-11 點（想象一(yi)下凌晨兩點收到一(yi)條推送通(tong)知把(ba)你(ni)吵醒了，你(ni)會說怎樣的(de)反(fan)應？）
對于發(fa)送時(shi)間(jian)的限制(zhi)(zhi)需要考慮哪些(xie)消(xiao)息應(ying)(ying)該計算到限定(ding)時(shi)間(jian)中，哪些(xie)消(xiao)息不應(ying)(ying)該計算在內，例如(ru)廣告營銷消(xiao)息不能再 23-7 點(dian)(dian)之(zhi)間(jian)推送給用戶，但(dan)是驗證碼(ma)不會限制(zhi)(zhi)，你總(zong)不能超過 23 點(dian)(dian)就(jiu)不讓(rang)用戶收到驗證碼(ma)吧(ba)
先來(lai)說(shuo)下消(xiao)息推(tui)送流程(cheng)上是怎樣到達用戶手機上的，Android和 iOS 有些小差別：
iOS消息推送流程：
——運營手動推送：發起推送請(qing)求（自有服務器，或第三方(fang)）→APNS（蘋果服務器）→iPhone（終端(duan)）→彈(dan)出新(xin)消息（終端(duan)）→打開App（移動應用(yong)）→進入landingpage（移動應用(yong)）→開始活(huo)動內(nei)流程（移動應用(yong)）
——觸發式推送(song)：事件觸發（自有服(fu)務(wu)器，或第三方）→APNS（蘋果服(fu)務(wu)器）→iPhone（終(zhong)端(duan)(duan)）→彈出新消息（終(zhong)端(duan)(duan)）→打(da)開App（移動(dong)應用）→進入landingpage（移動(dong)應用）→開始(shi)活動(dong)內流程（移動(dong)應用）
Android消息推送流程：
——運營手(shou)動推(tui)送：發(fa)起推(tui)送請(qing)求（自有服務器(qi)，或第三方）→Android（終端）→彈出新消息(xi)（終端）→打開(kai)App（移動應用(yong)）→進(jin)入landingpage（移動應用(yong)）→開(kai)始活(huo)動內流程（移動應用(yong)）
——觸(chu)發式(shi)推送(song)：事件觸(chu)發（自(zi)有服務器，或第(di)三(san)方(fang)）→Android（終(zhong)端(duan)）→彈出新消息（終(zhong)端(duan)）→打開(kai)App（移(yi)動(dong)(dong)應(ying)用(yong)）→進(jin)入landingpage（移(yi)動(dong)(dong)應(ying)用(yong)）→開(kai)始(shi)活動(dong)(dong)內(nei)流程（移(yi)動(dong)(dong)應(ying)用(yong)）對(dui)于 iOS 還好(hao)一(yi)點(dian)，都(dou)是蘋果自(zi)家的產(chan)品，最(zui)多就是用(yong)戶關閉了通知(zhi)權限，導(dao)致無法收到(dao)；
Android 的(de)(de)幺蛾子(zi)可(ke)就(jiu)多了，結束(shu)進程是(shi)收不(bu)到(dao)的(de)(de)，關(guan)閉通知(zhi)權限(xian)也是(shi)收不(bu)到(dao)的(de)(de)，如果集(ji)成廠商推送（好(hao)處是(shi)結束(shu)進程也能推送到(dao)用戶(hu)手機(ji)(ji)上(shang)），壞處是(shi)有可(ke)能如果只(zhi)接入一家廠商，有可(ke)能其他(ta) Android 手機(ji)(ji)品牌是(shi)接受不(bu)到(dao)的(de)(de)，例如接入 OPPO，華為手機(ji)(ji)可(ke)能是(shi)收不(bu)到(dao)的(de)(de)。
這里只是考(kao)慮了(le)讓Android 用戶在結束進程能(neng)收到(dao)消息，在消息推(tui)送(song)過程中還有很多問(wen)題要(yao)考(kao)慮，我列下來你可以去考(kao)慮下。
例如：接(jie)(jie)入(ru)哪(na)家第三方(fang)公司？接(jie)(jie) push 的公司和 im 公司是否有(you)沖突（我司接(jie)(jie)入(ru)的極光和云信是有(you)沖突的，不能同接(jie)(jie)入(ru)）？支持多少并發量(liang)？用戶(hu)接(jie)(jie)收(shou)到消息會有(you)延遲幾小時嗎(ma)？各(ge)廠商的政策怎樣(yang)？
主要是幾(ji)個問題，先列出這幾(ji)個問題，然后展(zhan)開來講一下
——頻率(lv)限制(zhi)
——相(xiang)互喚醒
——推送的影響
——App 內引導打開通知權限(xian)
1）限制頻率
舉個極端點的例子(zi)，如果淘寶每天給你推送(song) 500 條信息，你會怎樣？可(ke)能就(jiu)是直接卸載了，所(suo)以(yi)對用戶的消息推送(song)需要(yao)考慮頻率(lv)。
例如每天最多(duo)給用戶推送兩(liang)條(tiao)，如果超過兩(liang)條(tiao)之后，自動推送不(bu)成功(gong)。
但是需要考(kao)慮哪些消息應該(gai)計(ji)算(suan)到條(tiao)數中(zhong)，例如(ru)廣告營(ying)銷應該(gai)計(ji)算(suan)在內，驗(yan)證碼不應該(gai)計(ji)算(suan)在內，用(yong)戶(hu)每(mei)天獲取 5 條(tiao)驗(yan)證碼可能都算(suan)是正(zheng)常的。
一(yi)(yi)個注意的點(dian)，一(yi)(yi)些(xie)同學可(ke)能會想，別家的 App 都每天(tian)推送十幾(ji)條，我只推送一(yi)(yi)兩條，豈不是(shi)占(zhan)用用戶的時(shi)間就少了嗎？
消息推送可不能按照(zhao)公地(di)(di)悲(bei)劇的(de)思路來思考（可以去百(bai)度下公地(di)(di)悲(bei)劇），對于用戶使用 App 來說，他是可以選擇卸(xie)載(zai)或(huo)者關閉通(tong)知權(quan)限(xian)的(de)，不想公地(di)(di)悲(bei)劇中沒有選擇。
2）App之間相互喚醒
假設即(ji)刻 App 和他趣(qu)(qu) App 都接入了(le)同一家(jia)(jia)第三方(fang) push 廠家(jia)(jia)，如果即(ji)刻沒(mei)有(you)結束進程，他趣(qu)(qu)結束了(le)進程，在推送給他趣(qu)(qu)消息(xi)(xi)時(shi)，即(ji)刻會喚醒他趣(qu)(qu)，使他趣(qu)(qu)能(neng)收到消息(xi)(xi)。
但是這(zhe)種(zhong)喚醒機制在 Android N 的(de)時候，谷歌已經限制了不(bu)能這(zhe)樣(yang)做，所以這(zhe)種(zhong)方式可以不(bu)用考慮了，現(xian)在采(cai)用的(de)更多是接(jie)入手機廠(chang)(chang)商，通過廠(chang)(chang)商推送(song)比較靠譜。
3）推送的影響，有好處也會有壞處
好處：信息告知(zhi)與(yu)提(ti)醒(xing)、促進活躍，增強粘(zhan)性、喚醒(xing)沉默用戶，提(ti)升留存、提(ti)高(gao)功(gong)能模塊使用率
壞處：騷擾(rao)用(yong)戶，提高卸載率、信(xin)任透支(zhi)，“狼來了”的(de)故事(shi)、過多(duo)無價(jia)值內容(rong)，造成用(yong)戶反感甚至麻木(mu)
4）App 內引導打開通知權限
這是一個iOS、Android 都(dou)(dou)會(hui)存(cun)在的問題，如果用(yong)戶手(shou)動(dong)關閉了通知(zhi)權(quan)限，那是無(wu)論如何都(dou)(dou)是無(wu)法將(jiang) push 推(tui)送到用(yong)戶手(shou)上的，所以(yi)在用(yong)戶使用(yong) App 是你需要盡量的引導用(yong)戶開通權(quan)限。
如(ru)果用戶已經(jing)關閉了通(tong)知，則需(xu)要在某(mou)些地方判(pan)斷是(shi)否已經(jing)關閉通(tong)知權限，如(ru)果已經(jing)關閉了則需(xu)要引導用戶打開(kai)。
消(xiao)息(xi)點擊需要考(kao)慮的(de)點：內容質量怎樣？標題是(shi)否(fou)(fou)(fou)(fou)吸(xi)引？用戶與內容匹(pi)配度？是(shi)否(fou)(fou)(fou)(fou)熱點內容？通知中帶有用戶昵(ni)稱等個性化(hua)內容？是(shi)否(fou)(fou)(fou)(fou)支持跳(tiao)轉對應頁面？跳(tiao)轉是(shi)否(fou)(fou)(fou)(fou)流暢？落地(di)頁質量怎么樣？
這(zhe)(zhe)里(li)其實已經是結(jie)果(guo)了，這(zhe)(zhe)里(li)的結(jie)果(guo)好壞會取決于發送前的幾步，篩選用(yong)戶時(shi)是否將對(dui)于信息發送給對(dui)于用(yong)戶，消息制作(zuo)時(shi)質量怎么樣等
發送后(hou)需(xu)要(yao)統計每一步(bu)的數(shu)(shu)據(ju)，在和行(xing)(xing)業(ye)內(nei)(nei)進行(xing)(xing)對(dui)比，以及(ji)和自己進行(xing)(xing)環比、同(tong)步(bu)看數(shu)(shu)據(ju)，需(xu)要(yao)統計的數(shu)(shu)據(ju)例(li)如有應發人數(shu)(shu)、實發人數(shu)(shu)、發送成功用(yong)(yong)(yong)戶(hu)(hu)(hu)數(shu)(shu)、觸達成功用(yong)(yong)(yong)戶(hu)(hu)(hu)數(shu)(shu)、點擊用(yong)(yong)(yong)戶(hu)(hu)(hu)數(shu)(shu)、跳轉(zhuan)至落地頁后(hou)的每一步(bu)轉(zhuan)化人數(shu)(shu)，除(chu)了這些數(shu)(shu)據(ju)之外還需(xu)要(yao)關注下用(yong)(yong)(yong)戶(hu)(hu)(hu)的卸載率（收到(dao)推送后(hou) 1 小(xiao)時內(nei)(nei)卸載 App 的用(yong)(yong)(yong)戶(hu)(hu)(hu)數(shu)(shu) / 收到(dao)推送的用(yong)(yong)(yong)戶(hu)(hu)(hu)數(shu)(shu)）。
設計消息推送系統時(shi)，一部分(fen)(fen)是(shi)消息推送，還有(you)另外一部分(fen)(fen)是(shi)推送之后的(de)消息記錄，這就(jiu)是(shi)畫畫原(yuan)型，很簡單的(de)事，只提一下需要注(zhu)意的(de)幾個點就(jiu)好
——推送進度，例(li)如創建成(cheng)功（支(zhi)持取(qu)消推送）、推送中、推送成(cheng)功、已刪除等狀態
——單條消息推(tui)送(song)之后的數(shu)據，例如點擊率(lv)、轉化率(lv)、推(tui)送(song)用戶數(shu)等
——怎樣監控(kong)卸(xie)載(zai)率（我也(ye)不知(zhi)道）
——怎樣確定消(xiao)(xiao)息(xi)優(you)先級，因為每天(tian)有限制消(xiao)(xiao)息(xi)推送的頻率(lv)，那肯定是(shi)優(you)先推送優(you)先級高的消(xiao)(xiao)息(xi)
——怎樣(yang)使每(mei)(mei)個用戶(hu)(hu)都收(shou)到他能(neng)承(cheng)受(shou)的最(zui)大條(tiao)(tiao)(tiao)數（例如有的用戶(hu)(hu)每(mei)(mei)天(tian)(tian)最(zui)多能(neng)接(jie)受(shou) 2 條(tiao)(tiao)(tiao)，超過(guo) 2 條(tiao)(tiao)(tiao)之后他就會卸載(zai)App，那(nei)就每(mei)(mei)天(tian)(tian)給他推(tui)送(song) 2 條(tiao)(tiao)(tiao)就好；有的用戶(hu)(hu)每(mei)(mei)天(tian)(tian)最(zui)多能(neng)接(jie)受(shou)8 條(tiao)(tiao)(tiao)，超過(guo) 8 條(tiao)(tiao)(tiao)之后他就會卸載(zai) App，那(nei)就每(mei)(mei)天(tian)(tian)給他推(tui)送(song) 8 條(tiao)(tiao)(tiao)）
——怎樣做 A/Btest，例如(ru)抽 10% 的(de)(de)(de)用戶出來，將寫好的(de)(de)(de) 5 條文(wen)案分(fen)別推(tui)送(song)(song)給(gei) 2% 的(de)(de)(de)用戶（10%/5=2%），較(jiao)短的(de)(de)(de)一段(duan)時間來看哪(na)一條文(wen)案的(de)(de)(de)點擊率比較(jiao)高，然后將這條文(wen)案推(tui)送(song)(song)給(gei)剩(sheng)下的(de)(de)(de) 90% 用戶
——區分(fen)(fen)手動(dong)推送(song)(song)(song)和觸(chu)發式推送(song)(song)(song)，以上說(shuo)的大多屬于手動(dong)推送(song)(song)(song)，還有(you)一(yi)種(zhong)分(fen)(fen)類屬于觸(chu)發式推送(song)(song)(song)，也是(shi)滿足(zu)各種(zhong)條件（一(yi)個(ge)事(shi)件），就(jiu)給用戶推送(song)(song)(song)一(yi)條消息，例(li)如今天(tian)(tian)你生(sheng)日、聯系 3 天(tian)(tian)未登錄 App、充值(zhi)成(cheng)功、優(you)惠券(quan)到期等場景
——如果移動端和 PC 端同(tong)時在線(xian)，推送邏輯(ji)是怎樣的
