推送系統從0到1（三）：推送任務的建立
如何保證把內容準確無誤地投遞給想要投遞的人，這將會是推送系統通訊層面的難點。
上一篇文章已經講述瞭如何選擇推送服務，並梳理了使用者與裝置、Token之間的關係，用裝置號才能精準的標識使用者。如果還無法清晰的瞭解這三者的關係，可以回顧上一篇文章：推送系統從0到1（二）：瞭解你的使用者
本篇主要為大家剖析推送任務的建立，如何在搭建推送系統中設計任務建立的過程，同時也可以瞭解各大推送平臺的運作方式。作為系統的設計者，我們除了知道給什麼使用者在什麼時間推送什麼內容以外，更重要的是如何保證把內容準確無誤的投遞給想要投遞的人，這將會是推送系統通訊層面的難點。
一. 建立自帶過濾及淨化器的使用者池
為了實現把推送內容準確無誤的投遞給想要投遞的使用者，需要滿足以下幾個條件：
- 使用者是不變的
- 使用者的‘通訊裝置’（裝置）是不變的
- 使用者的‘聯絡方式’（Token）是不變的
這也是大多第三方推送平臺的弊端，當用戶‘通訊裝置’或‘聯絡方式’發生改變的時候，部分第三方推送平臺會把該使用者當成‘失聯’的使用者，再也無法聯絡上該使用者，此時使用者變成為無效使用者。因此運營童鞋經常會發現，推送效果越來越差，到達率、點選率越來越低，其實是其中的許多使用者已經失聯，再也無法把訊息傳送給該使用者。這些無效使用者既然收不到推送，也自然不會產生點選，但是卻會讓推送的目標使用者數虛高。所以這三點在推送任務建立之前，必須通過產品設計的角度，讓其成為“不變的”。
建立使用者、裝置、Token的繫結機制
如果閱讀過我上一篇文章就會知道，我把使用者、裝置、Token的關係比喻成使用者、電話、電話卡之前的關係。想要使用者永遠不換電話或者不換電話號碼似乎並不現實，所以改變是必然存在的，重要的是通過我們對其關係的梳理，即便發生了改變，我們仍然知道這個使用者是誰，用的是哪個裝置，如何聯絡該使用者。所以首先我們建立三者的繫結機制。
以上三種情景在實際過程中經常會出現。除此以外還有第四種情景，即裝置及Token未發生改變，但使用者發生了變化，此情況多出現在使用者在同個裝置上登陸多個賬號時出現，該方式主要的處理辦法為賬號資訊同步，在此不做過多的闡述。以上方式能夠解決大部分情況下由於裝置或Token發生改變時，該使用者變成了無效使用者的問題。那麼綜合以上三種情況，我們在設計使用者繫結機制時，應當設計成以下方式。此方式可以最大程度的保證你推送的使用者是有效的，真實的，且是你認知的那個使用者。
- 一個使用者對應多個裝置，一個裝置對應唯一的Token。
- 當Token發生改變，則用新的Token替換原來的Token，並與裝置繫結。
- 當裝置發生改變，Token未變時，則用新的裝置繫結舊Token及使用者。
- 當裝置發生改變，Token發生改變時，使用新的裝置（及其對應Token）繫結使用者，同時舊裝置可做有效性檢測（如模擬傳送測試等），若舊裝置無效則解除與使用者繫結。
具體流程可見下圖：
按照以上方式，即可儘可能的保證使用者的“不變”，不管使用者裝置或‘通訊方式’如何更換，該使用者仍然是原來認知中的使用者，並且有‘最新最有效的聯絡方式’。該方式如同一個自帶過濾和淨化器的池子，儘可能的保證池裡的‘生物’健康有效的存活。但是即便如此，在建立推送任務時，還是需要做有效使用者的篩查。因為仔細研究上述方式，就會發現一個弊端，不管哪種方式重新繫結或者替換，都建立在使用者‘主動’告知其裝置資訊發生改變的前提下。若使用者不告知，則系統仍無法進行過濾和關係的重建。所以有效使用者的篩查就很有必要。
二. 有效使用者的篩查
在建立推送任務時，進行有效使用者的篩查就是針對類似於使用者解除安裝APP後，Token已經失效，但是使用者無法回報該資訊。此時我們仍把這個使用者當作是有效使用者進行傳送，最後的結果就是該使用者收不到。這是大多數推送系統在建立推送任務時一定會做的有效使用者的篩查（甄別）。
建立推送任務時，我們會選擇目標使用者，此時根據條件在上述構建的使用者池中撈出我們的目標使用者。這些目標使用者在我們帶有過濾系統的使用者池中已經擁有最新的聯絡方式了。但就像我所說，即便如此，仍可能存在使用者的裝置或Token已經失效，但無法及時彙報給系統的情況，例如APP解除安裝、APP重灌但未開啟、更換裝置後未登入過等。所以把使用者撈出來後，首先要做的就是有效使用者的篩查。我們可以通過以下方式判斷該使用者的裝置或Token是否有效：
- 查詢裝置的瀏覽情況，此方式需要提前埋點記錄使用者行為（後續做精準推送的必要條件）。
- 查詢裝置的賬號登陸情況，若裝置關聯賬號已經發生變更，可能該裝置已屬於其他使用者。
- 查詢該裝置上次推送，上次推送服務返回的狀態可以檢測Token有效性的。
- 疑似無效裝置的預推送，在與客戶端預先約定好的情況下，傳送推送測試來檢查Token有效性，但需要在使用者裝置不會受干擾（不會顯示）的前提下。
通過上述方式，可以把無效的使用者進行標記，從本次推送任務中刪除，並進入黑名單。關於黑名單機制在後續文章中將會詳細講解。此時便完成推送任務的第一步，從使用者池中撈出使用者，並進行有效性的篩查。在完成以上步驟後，推送訊息的下發成功率將達到95%以上。（蘋果返回的下發成功情況沒有參考價值，部分第三方平臺返回的下發成功情況也存疑）當我們儘可能準確的選出有效使用者之後，如何把準確的訊息發給這些使用者呢。
三. 推送任務的建立
像小時候學習寫作文，記事文的幾個要素：時間、地點、人物、事情。那麼建立推送任務也是如此，上述我們已經講了人物的部分，我們已經把有效的使用者確定了，如果想要給不用的使用者傳送不同的內容，後續文章講解精準推送的部分將會詳細講到，本次不在闡述。那麼此時需要確定的是傳送時間、傳送裝置、傳送內容。
- 傳送時間：從傳送時間開始，推送任務開始執行，批量/逐個傳送到使用者的裝置上。
- 傳送裝置：上述篩出有效使用者的裝置，裝置系統（Android、IOS、PC等），通知推送的方式（應用內推送暫不闡述）。
- 傳送內容：推送通知的標題、內容、圖片、其他富文字、推送的著陸頁等
梳理上述內容及推送任務之間的關係，可以從下圖中看出來，設定傳送時間，將會作為任務執行時間，而傳送裝置決定了使用者在哪個裝置上接受什麼型別的訊息。傳送內容中的通知資訊將會在使用者的裝置上的通知欄展示。設定著陸頁將會是使用者點選之後跳轉的頁面。
此時在設定好這些內容後，推送系統將按照時間執行任務。使用者收到訊息將會看到你設定的通知內容，若使用者有興趣點選，將會跳轉至你設定好的著陸頁。此時推送任務的建立即完成。關於內容的設計，蘊含很多運營知識，將會在後續介紹推送運營的時間進行詳細介紹。不過值得注意的是，推送內容如標題、內容、圖片等等，會因為裝置端的展示限制和系統支援的富文字情況將有所區別，如果IOS 10及以上系統支援富文字推送，Android系統支援自定義通知欄。運營人員在使用個性化的推送內容展示時需要與客戶端有所約定，關於客戶端所支援的通知內容展示情況，將會在下一篇中進行詳細介紹。
四. 推送任務如何傳輸
在推送任務建立之後，通知訊息經過推送系統的幾個過程最終達到使用者的裝置上，訊息是如何從推送系統到達使用者的裝置上的？通知訊息在傳輸的過程中是否會遇到困難，訊息在裝置上是如何展示的？請期待下一篇“推送系統從0到1（四）通知訊息如何達到裝置”。
五. 總結
本篇文章主要闡述了建立有效過濾機制的使用者池到建立推送任務的過程，歸納成以下3點：
- 建立有效的使用者池：獲得使用者最新的‘聯絡方式’
- 建立有效性篩查機制：無效裝置統統剔除
- 建立推送任務的要素：推送時間、推送裝置、推送使用者、推送內容（標題、文案、圖片、其他富文字、著陸頁）
題圖來自Unsplash，基於CC0協議