每天針對使用者的推送訊息可以引導使用者參加活動、閱讀資訊、檢視賬單等行為，是一塊重要的流量入口，推送是推動業務目標的達成的重要手段。

搭建一套較為完善的公司內部訊息推送管理平臺，對公司內部各業務線、產品線的訊息推送進行統一管理，統一發送；這樣既提高了公司的運營效率，又保證了使用者體驗。

一.瞭解APP PUSH推送機制1.1 APP PUSH定義與價值

APP PUSH的定義為在手機終端鎖屏狀態下通知欄展示或在操作前臺頂端彈出的訊息通知，點選後可喚起對應的APP，並在APP內跳轉到指定頁面。

push訊息是通知使用者，引導使用者進行參與活動、購買產品的重要手段，而且PUSH訊息也可以引導使用者檢視訊息，喚起APP提高日活，是一塊重要的流量。

每種型別APP對PUSH的需求也不同，IM類APP追求實時、穩定的觸達，此類APP一般透過自己的長連線進行訊息推送，保證使用者在收到訊息的時候能夠實時地接收訊息訊息。另外，一些安卓廠商也會給予頭部APP的程序一定保護，對相關的程序納入白名單，在清理程序的時候予以忽略。

新聞資訊類的APP與工具類APP的PUSH推送機制基本一致，僅在頻率控制上有差異，新聞資訊類由於新聞資訊較多，需要將突發新聞及時推送給使用者。

由於目前工具類的APP佔大多數，本文將主要講解工具類APP的常見推送機制。

1.3 PUSH 流程

PUSH訊息在訊息系統建立好後進入傳送階段，服務端需要根據使用者終端資訊進行路由，如果是IOS系統，那麼會呼叫蘋果自身的推送通知服務（APNs）,如果使用者的手機是安卓系統，那麼根據不同的廠商去呼叫不同的廠商SDK。

對於不同的系統版本，支援的訊息展示形式也是不同，比如IOS10之後，當APP在前臺時，是否通知欄展示；此樣式可以根據產品需求來選擇，有服務端傳輸相應通知方式的值即可。如果使用者的手機非五大廠商內的手機，可以透過自己搭建的長連線或者使用第三方服務進行推送。

如果不是自己直接對接廠商通道，那麼內部的服務端可能無需做過多較為複雜繁瑣的開發工作，透過接入第三方訊息推送平臺來實現訊息的推送，比如信鴿、個推等。多數的通道會將訊息是否成功推送到客戶端SDK的回執資料反饋給傳送方，需要提供回撥地址。

1.4 底層通道說明1.4.1 推送方式

通道型別一般分為三類：廠商通道、第三方推送服務平臺、長連線。

第三方推送平臺是推送服務公司自己搭建相關的訊息服務。並且各個APP使用了同一個平臺的推送服務時，客戶端都是整合同一個第三方推送平臺的SDK，因此形成了一個推送聯盟，當聯盟中的其中一個APP的訊息程序沒有被殺死的時候，其他的APP也可以利用進行通知使用者，形成了相互喚起，提高觸達率。經過一些場景的測試，相互喚起的成功率並不是很高，需謹慎結合自身場景評估。為了提高觸達率，第三方推送平臺也會整合各大廠商的SDK進行推送。

長連線就是建立手機與服務端的一條鏈路進行訊息資料推送，透過長連線也可以進行APP狀態監控，但完全由長連線推送且保證觸達的穩定，需要投入的研發資源較多,且需儘量避免自己的長連線程序不要被作業系統殺死。

1.4.2 優劣勢對比

APP push功能的搭建需要依據產品自身的情況和公司可投入的資源成本為主，在不同的階段應該追逐不同的目標。

1.5 下發推送1.5.1 推送賬號

推送時客戶端的PUSH SDK均會根據使用者的裝置號生成一個對應關係的TOKEN。在SDK內部，如果使用的是第三方推送服務，則去第三方的SDK註冊；如果是廠商，則去商城SDK註冊；如果使用自己長連線，則去自己的SDK進行註冊，作為後續推送的標識使用者的唯一ID。

1.5.2 訊息路由

訊息路主要見上述推送流程的講解，此處主要講解根據不同的業務場景，可能會定向推送給不同版本APP的使用者。因此服務端在通道能力路由的時候，不僅需要能夠區分通道，還要進一步能夠針對使用者的手機終端進行更加精細化的差異推送。

此外，訊息通道並一定是100%穩定，如果下游通道出現問題，服務端需能夠將由於通道問題導致的訊息路由到備用通道去傳送，以保證業務穩定觸達。

1.5.3 全量推送

一般來說，對於公司內部運營或公司的相關資料均是以產品的customer id為準，使用者資料系統對接訊息系統時也多為customer id，因此需建立customer id與推送TOKEN的關係，便於運營針對使用者進行推送。但對於一些場景會需要針對未登入的使用者也進行推送，即全量推送；比如突發重大新聞資訊、大促等活動，所以運營系統需要提供全量推送功能，針對所有TOKEN進行推送。

對於所有方式的觸達訊息，都離不開觸達與點選，觸達的資料透過廠商的需要廠商回撥上報，點選資料可以由SDK上報服務端。對於push的關閉，也是需要進行考量的，來評估push是否過度傳送，打擾到了使用者。關閉資料有兩部分，一部分為app內部的關閉，sdk直接上報給服務端即可；另一部分為使用者在手機作業系統上關閉了對應app的push，需要APP在前臺時，sdk呼叫手機終端相關方法獲取該使用者是否關閉了系統通知，然後上報至服務端。

註冊資料即使用者首次啟動APP時，去相關sdk註冊token。

一般來說，使用者退出賬號時，sdk需要上報服務端，解除token與customer id的繫結關係。

1.7、PUSH特點1.7.1 強提醒 不留痕

push由於是app自己的通知渠道，是運營的一個重要工具。如果使用者未關閉PUSH通知的話，push可以從通知欄彈出進行訊息顯示，具有一定的強提醒性，但PUSH點選跳轉後便消失，沒有痕跡，因此針對於重點的通知訊息，需要在APP內設定訊息中心，在PUSH的同時留下通知記錄。

1.7.3 IOS和安卓

由於APP是基於手機作業系統，因此對於IOS和安卓的推送的流程及功能基本相同，只不過細節和方法上略有不同，且國內安卓產商都在安卓系統上進行了一定改造，導致國內安卓廠商標準各不相同，需要開發同學仔細對接各個廠商。

1.8 觸達率的提升

觸達率的提升需要從訊息建立到實際通知到使用者的建立完整流程，細化每一個互動環節，發現影響觸達率的主要瓶頸，並針對性地進行解決或最佳化方案。除此之外，未採用廠商通道的訊息也可以採用自己的長連線和其他推送平臺服務同時多條推送，在客戶端的SDK內增加針對同一罅隙流水號的去重，這樣可以也可以提高一部分訊息的觸達率。

二.從0到1搭建訊息管理平臺2.1 推送系統流程

一般來說，訊息推送有2種傳送方式，一種方式為運營活動批次定時投放，需提供系統功能方便運營篩選使用者，然後編輯文案，經稽核通過後進行傳送。另一種是需要實時觸發的訊息，比如支付成功通知、驗證碼獲取、滿足某種條件觸發的營銷活動等訊息，這類時效性要求較高且每個使用者傳送的訊息內容中涉及到差異化的引數，需要業務應用實時觸發。觸發的訊息需經過一定的過濾與攔截規則，針對於短期內已經覆蓋過使用者進行過濾，異常或者不合規的訊息進行攔截，按照設定好的渠道進行推送。

2.2 資料準備

對於訊息推送系統，需要獲取投放的目標使用者的賬號資料，往往公司產品的customer ID和對應推送渠道的賬號不一致，需要獲取繫結關係，比如簡訊需要手機號，push需要SDK上報的token，微信需要使用OPEN ID，相關資料的採集在各個渠道的傳送機制的文章裡進行闡述。

2.3 訊息建立2.3.1 投放人群選擇

日常的運營活動為了更加精準，提高貨多功能轉化率，運營同學會根據一些使用者的特徵進行篩選，比如北京地區使用者，近3天內有登入過APP的使用者等等，因此訊息投放系統需與公司內部資料部門的標籤系統進行對接，提供運營同學投放人群選擇。介面實時觸發的訊息，一般需要業務系統監控到使用者行為，將使用者賬號與需要的引數透過MQ或者介面傳遞至訊息推送系統進行傳送。

也需提供使用者賬號檔案上傳功能，以便突發事件需要及時告知使用者，避免來不及對涉及使用者資料錄入標籤系統等問題。

2.3.2 訊息型別與等級劃分

訊息的型別的應以訊息內容的目的進行劃分，大類可分為通知、營銷、驗證碼等型別。

例如，簡訊行業內分為通知、營銷、驗證碼型別的訊息， 該型別的劃分主要為方便路由簡訊至SP服務商不同通道，不同的通道觸達率也不同，為了保證重要簡訊的觸達率，需要將各個內容的簡訊路由至不同的通道傳送。

結合個人經驗，公司內部可以根據實際情況進行更細粒度的劃分，比如增加通知+營銷型別，可能場景為使用者支付成功後，在表述完使用者支付成功資訊後，結合適當場景增加領取優惠文案，引導使用者向其他活動轉化。對於金融借貸類的機構，也可增加還款通知型別，主要為使用者產生逾期行為需要提示還款的訊息；原因為特殊期間，還款通知類簡訊可能會受特別的管制，單獨出來可以進行較好的監控與處理。

對於通知類的訊息，也應該按照等級進行劃分，比如使用者支付成功提示訊息和優惠券到賬通知訊息，顯然不應該是同一等級。支付訊息涉及使用者資金變動，通知等級較高；優惠券到賬訊息更偏營銷型別，通知等級較低。為避免對使用者產生更多幹擾，需要分級進行控制，必要的時候降低等級較低的訊息的推送頻率。

2.3.3 訊息內容

不同的渠道的訊息，所需要的訊息內容不一樣，簡訊內容僅需要簡訊對話方塊內的文案即可，PUSH需要展示標題與內容摘要；微信有模板訊息與圖文、語音等多型別的訊息內容。在產品設計時，選擇了對應的投放渠道後，應展示對應渠道所需的欄位，且為必填項。

2.3.4 訊息跳轉

訊息觸達到使用者後，對於感興趣的使用者需要進一步瞭解資訊，那麼目前各類訊息的載體不是有足夠的空間來展示所有的資訊，因此需要跳轉到落地頁進行詳細資訊獲取。簡訊型別的訊息需要將長鏈轉化成短鏈再進行傳送，一是為了節省成本，因為簡訊是按照字元數進行收費的，二是為了使用者體驗，使用者在手機上看到的不應該是一對長的亂碼。PUSH需要根據跳轉的不同的頁面設定不同的跳轉型別，如H5頁面和原生頁面，跳轉協議由客戶端提供，訊息系統只需要將其配置到系統上，運營同學可以選擇就可以。微信的訊息內容一般模板訊息條狀到H5的活動頁，圖文訊息跳轉到文章詳情，文字訊息中也可以新增超連結，跳轉到小程式。

產研負責人：在訊息傳送之前應該記錄好每個任務或模板，對應業務線的產品、研發實際訊息的負責人，當訊息發生客訴時，透過訊息記錄查詢功能，便可迅速定位訊息的產研負責人，緊急確認對應訊息是否有異常並解決。

2.3.6 推送時間設定

對於不同傳送形式的訊息，推送時間不同。建立的訊息任務可以預定時間進行傳送；對於已經固化下的營銷場景，需設定週期性任務，設定初始執行時間與執行週期，降低運營操作成本。介面觸發的時間一般為實時觸發，觸發時間由業務系統決定。

2.3.7 線上測試

當訊息任務設定好後，需要驗證訊息投放出去後展示的效果與相關跳轉是否正常，避免造成線上推送事故。測試需要傳送運營設定好的真實內容，推送物件為內部訊息建立者。為避免出現訊息誤發，測試傳送的文案前應新增“測試”，或設定測試白名單，不在白名單內的賬號無法進行測試。

2.4 訊息稽核

當訊息任務或者訊息模板建立好，需要經過謹慎稽核後才能傳送，避免出現工作失誤產生不良影響。

稽核級別一般需要業務線內部負責人稽核與公司平臺或者對應職能部門稽核。稽核要點主要為：訊息文案是否符合廣告法、訊息跳轉是否正常、傳送頻率、時間是否合適等。

2.5 訊息過濾與攔截

訊息過濾主要針對營銷型別訊息，時段限制（早上9點至晚上8點之間可傳送）、頻率限制（使用者7天內只能收到1條簡訊，針對於週期性任務，同一任務觸達過的使用者可以進一步擴大過濾週期，）、黑名單限制（使用者退訂）。

訊息攔截主要為限制傳送量級，比如每個業務線針對同一使用者每日最多傳送5條簡訊；公司整體對同一個使用者最多傳送30條簡訊；短時間（時間可設定，如300S）內同一使用者重複內容過濾；量級的控制只要為避免由於業務系統故障造成的對使用者訊息轟炸，產生不良影響。

關鍵詞攔截，如包含違法、暴力等詞彙。

不同的場景使用的過濾頻率可做適當調整，比如使用者對簡訊訊息的容忍度比push的容忍度較低，因此簡訊頻率應該更加嚴格。

2.6 訊息傳送

目前經過種種邏輯的處理，訊息終於到了傳送環節。傳送環節主要後臺邏輯，重點要最佳化訊息傳送的效能，提高訊息傳送的穩定性，避免業務損失。傳送環節應該新增監控並且適當列印日誌，以便及發現異常並定位問題。

2.7 訊息路由

簡訊、安卓push均可接入多個渠道，搭建分發叢集。可以根據業務業務邏輯指定通道傳送，也可以根據下游通道狀態自動路由。

如果涉及訊息對APP進行導流，提高APP活躍，也許統計各訊息為帶來APP喚起次數。

對於簡訊來說，涉及到簡訊費用，需要針對渠道和成功觸達條數進行計費，設計對賬看板。

簡訊退訂、PUSH關閉等等使用者行為資料也需要進行分析，便於調整後續觸達策略。

2.9 後臺管理2.9.1 通道路由配置

對於簡訊型別的訊息，涉及到簽名與通道，不同的業務場景需要不同的簡訊簽名，需要將某些賬號、某些模板的訊息路由至固定通道側。以及系統需要根據下游通道效能或狀態自動路由訊息。

2.9.2 訊息傳送記錄查詢

針對於近期傳送出去的相關訊息，需提供客服側或運營側一定的查詢功能，以便使用者來電諮詢相關訊息問題，比如未收到驗證碼訊息、沒有進行操作卻收到訊息等等情況。

2.9.3 黑名單

黑名單功能主要應用於訊息過濾，當用戶投訴或退訂後，避免再給使用者傳送訊息，遮蔽的粒度需根據訊息型別進行遮蔽，可適當根據內部業務劃分。

2.9.4 過濾與攔截規則配置需針對同一使用者設定訊息傳送上限，避免由於業務系統異常導致對使用者造成轟炸。重複內容攔截，需設定一定時間內，完全相同內容進行攔截，避免重複傳送。關鍵詞攔截，需針對於違規、違法的關鍵詞進行攔截，避免出現運營事故。針對於營銷訊息，需根據不同的觸達方式，控制觸達頻率，避免對使用者造成干擾，反而讓使用者對品牌產生反感心理。2.9.5 上行管理

上行管理主要應用於簡訊訊息，使用者回覆退訂或辦理業務的關鍵詞。由於從運營商到傳送者的上行過程不能精確到使用者回覆的是哪條訊息（也可能使用者主動給某些號碼傳送簡訊），為了保證各場景不互相影響，需控制上行關鍵詞唯一。