消息推送算是產(chǎn)品設(shè)計中最常見的功能點之一，但是這小小的功能點總是有人在不斷犯錯。那么，我們在設(shè)計消息推送的時候，都需要注意哪些點呢？

“喂，有個需求！這里我們需要發(fā)送一條消息觸達用戶，消息文案等會給你，麻煩盡快搞下。”

一句話需求，如果你是開發(fā)GG，你接這樣的需求么？

不接，為啥？

其實，細細想下這個需求，有很多問題：

1. 消息以什么渠道通知到用戶？
2. 發(fā)送的頻次控制是多少？
3. 合適的消息觸達用戶時間段？
4. 消息文案是固定的還是半固定半配置的？
5. 觸達至哪些用戶？

…

另外，上述的問題再作拆解，還會衍生出更多的細節(jié)問題，那這些將會在下面一一詳述。

觸達渠道

渠道？Channel。很簡單，今天我要從出發(fā)地A到目的地B，選擇交通工具：自行車，公交車，出租車，動車，飛機…那這些交通工具其實就是Channel。

同理，今天定義從平臺側(cè)發(fā)送至用戶側(cè)的一條消息，消息渠道：電話，短信，郵件，客戶端。比如說，在使用釘釘?shù)摹癉ing一下”功能時，會提供你選擇消息觸達的方式。

但有一個問題需要考慮，就是當(dāng)渠道不單一情況下，如何恰當(dāng)?shù)剡x擇渠道就要強依賴于消息的需求背景。比如，這條消息是交易相關(guān)，涉及到資金變動的通知，那么選擇短信渠道則可能是最為合理和穩(wěn)妥的方案，注意前提是你需要“知道”用戶的手機號。

但如果消息對于用戶側(cè)的重要性來說較弱，可能選擇客戶端PUSH的方式更加適合，因為畢竟走短信渠道，還要涉及到預(yù)算控制。

觸達時間

消息什么時間觸達至用戶側(cè)比較合適？事件即時觸發(fā)還是定時消息推送。

即時觸發(fā)，也就是當(dāng)定義的“事件”發(fā)生時，系統(tǒng)直接推送消息至用戶側(cè)。優(yōu)點是即時性強，尤其對于特別緊急重要的消息，會更傾向于選擇這種模式。但缺點就在于引致較差的用戶體驗。比如用戶在深夜2點收到平臺推送的消息，如果是你，你會不會抓狂？

定時推送，顧名思義，定義消息推送的時間。優(yōu)點是過程可控，比如考慮到用戶的工作和生活習(xí)慣，將消息推送的時間控制在10:00-20:00范圍內(nèi)，會降低用戶對于消息推送的負(fù)面情緒。另外，當(dāng)消息內(nèi)容或通知渠道出現(xiàn)重大變更時，可控性和靈活性都是ok的。但缺點在于，往往會造成消息積壓，隊列往往會導(dǎo)致消息延時。

所以更合理的方案，就是視不同的消息需求背景，來選擇不同的推送時間模式。

頻次控制

頻次控制，又稱疲勞度控制。什么意思？就是今天我要通知你一件事情，通知1次還好，但是同樣的消息我在一天之內(nèi)通知了你10次，你煩不煩？

同樣，消息的觸達頻次上一定要作好合理控制。否則，久而久之，一是體驗上的問題會引來投訴，從而造成用戶體驗損傷；二是引致用戶對消息無感，無意或有意忽略消息通知。

就問你一個問題，現(xiàn)在手機垃圾短信泛濫的今天，你還會看短信內(nèi)容么？或者一個微信群，積壓的200+條會話，你還會點擊進去滑屏瀏覽么？

目標(biāo)用戶

這條短信發(fā)送給誰？群發(fā)還是單點傳遞。如果是單點傳遞，還要考慮如果線上維護的客戶資料信息中，對于同一用戶ID有多個手機聯(lián)系方式，應(yīng)該通知到哪個手機號碼。

這種情況下，我們默認(rèn)選擇取第一個手機號碼。那如果你問，假如該手機號碼已作停用，用戶接收不到消息怎么解決？不能解決。畢竟不可控制，哪怕做金融產(chǎn)品，也允許有一定的資損率出現(xiàn)。

但如果是通過客戶端發(fā)送消息，可能這種問題出現(xiàn)的概率比較低，唯一的風(fēng)險就在于用戶把手機應(yīng)用卸載了。

變量配置

什么情況下會存在變量配置的問題？消息文案定義上屬于半固定半配置。

舉個例子。描述一個消息場景：當(dāng)用戶成功關(guān)注XXX公眾號后，平臺想要發(fā)送一條消息告知用戶關(guān)注成功。那這條消息一定是有幾個關(guān)鍵性變量需要配置的。

#Nickname#，你好。你已于#Operate_time#成功關(guān)注XXX公眾號。這是阿里Mant.君的個人公眾號，我知道你會陪我走下去。

注：變量參數(shù)Nickname代表用戶昵稱，變量參數(shù)Operate_time代表關(guān)注時間。

其實，給出消息文案并不是技術(shù)同學(xué)關(guān)注的問題，反而文案里的變量參數(shù)才是技術(shù)同學(xué)重點關(guān)注的對象。因為，變量參數(shù)的設(shè)定決定了事件的關(guān)鍵屬性，影響著參數(shù)傳遞和獲取問題。你現(xiàn)在Get到開發(fā)的點了么？

所以，下次開發(fā)再催你給消息文案時，為了不影響研發(fā)進度，先把參數(shù)變量給到他們，然后再慢慢思考短信內(nèi)容如何定義，這是我總結(jié)的一條小tip。

當(dāng)然，如果消息內(nèi)容是固定的，變量配置也就無需考慮了。

嘚吧嘚了這么久，不難發(fā)現(xiàn)，其實一句話需求距離代碼可落地實現(xiàn)，差的真不是一丁半點。

所以，多提靠譜需求，否則小船說翻就翻。

題外話

嗯，結(jié)合今天的文章內(nèi)容，拋個“通信系統(tǒng)”給大家了解下。

下圖表示了一個典型的通信系統(tǒng)，包含了Roman Jackson提出的通信六要素：發(fā)送者（信息源）、信道、接收者、信息、上下文和編碼。

感興趣的同學(xué)，可以自行了解。

作者：饅頭（微信公眾號：PRODUCTER，公眾號ID：ProStory），阿里巴巴產(chǎn)品經(jīng)理

本文由 @饅頭 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。