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

“喂，有個(gè)需求！這里我們需要發(fā)送一條消息觸達(dá)用戶，消息文案等會(huì)給你，麻煩盡快搞下?！?/p>

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

不接，為啥？

其實(shí)，細(xì)細(xì)想下這個(gè)需求，有很多問題：

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

…

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

觸達(dá)渠道

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

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

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

但如果消息對(duì)于用戶側(cè)的重要性來(lái)說(shuō)較弱，可能選擇客戶端PUSH的方式更加適合，因?yàn)楫吘棺叨绦徘溃€要涉及到預(yù)算控制。

觸達(dá)時(shí)間

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

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

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

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

頻次控制

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

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

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

目標(biāo)用戶

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

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

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

變量配置

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

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

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

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

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

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

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

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

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

題外話

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

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

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

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

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