編輯導語：消息推送功能是App的基礎功能之一，能在業務進程發生變化時及時通知用戶，提升用戶體驗；也能促進用戶活躍，提升App基礎數據指标。在這篇文章裡，作者總結了關于消息推送項目的經驗，希望能給你帶來收獲。

由于筆者身處行業的特殊性，消息推送項目在經曆了一系列波折之後終于上線，感慨萬千之餘，将項目上線的經驗進行總結，希望能給需要的小夥伴提供幫助。

一、需求分析

消息推送功能是App的基礎功能之一，一方面，在業務進程發生變化時及時通知用戶，提升用戶體驗；另一方面，推送運營類消息可促進用戶活躍，提升App基礎數據指标。

結合筆者所負責的App的實際情況，在需求池衆多嗷嗷等着上線的項目中，消息推送項目具有較高優先級。

二、成本分析

筆者負責的App可以投入該項目的開發團隊連視覺加測試總共不足10人，服務器資源對公司來說是較大一筆開支。

且消息推送内容的風控處理、消息防重複推送機制等又需要比較深入的研究，公司對上線時間也有一定的要求，從性價比的角度考慮，想自己去打通各設備廠商進行消息推送的方案顯然投入産出比極低。

因此在與領導建議之後，最終我們選擇采購第三方服務商的消息推送服務。

第三方服務商的消息推送服務有收費版和免費版的，原先App已接入過免費版的服務，但接入時間較早，圖文消息等功能均未面對我們App開放，且免費版共用推送通道，難以滿足數百萬用戶的運營推送需求，因此确認采購收費版本的消息推送服務。

三、風險分析

1. 合規性風險

2021年11月1日，《個人信息保護法》正式實施，對App及其使用的第三方SDK、第三方接口等采集使用的用戶信息進行嚴格的規定要求。

這邊梳理出以下幾個合規性方面的實操建議供大家參考：

1）協議保障

市面上第三方消息推送服務，往往會采集使用和分析客戶的用戶信息。因此采購第三方消息推送服務時，建議在合同中約束采集數據的歸屬問題、明确數據安全、數據合規方面的責任歸屬。

可能有的第三方消息推送服務商會給你一份模闆合同，說公司合同都這麼簽的。實際上作為消費者，我們在簽署合同方面的話語權必然是有的，該堅持的要堅持，如果說服不了你，銷售為了拿下你這一單，他會自己在公司内部解決領導和法務的問題。

2）關閉安卓設備的保活機制

安卓設備消息推送的保活機制，不滿足個保法的要求，若采購第三方消息推送服務，建議要求服務商關閉相關功能。

保活機制是安卓特有的，開啟保活機制的App隻要有一個在線，就能夠喚起其他App。

優點是隻要你堅持推送消息，用戶沒打開App的情況下App也會運行，可以把用戶活躍數據刷好看點，對于初創公司可能是能快速見效的促活手段，缺點是存在合規性風險。

暫未能确定第三方安全保障機構能否将安卓保活的情況檢測出來（如果能，那麼工信部網信辦就一定能），但是對于移動終端的深度用戶或者從業者，在使用過程中能觀察出App是否啟用了安卓保活機制。如所處行業比較敏感，建議能關則關。

3）SDK收集、使用信息的确認

首先是按照個保法要求，盡到監督義務。

目前中小型公司缺乏對第三方SDK收集使用數據方面的技術監控能力，因此建議與第三方消息服務提供商确。

目前使用的SDK版本采集使用了用戶的哪些信息，最好以書面的形式提供材料，或與對方确認，是否完全以SDK的隐私政策為準，以證明己方已盡到監督的義務。

如公司行業比較敏感且有一定預算，可采購第三方數據安全保障機構的檢測服務進行檢測。

普通公司與第三方消息推送服務商溝通确認後在隐私政策中披露，并在己方App的隐私政策中闡述以SDK服務提供商的隐私政策為準，在當前個保法推進階段基本可滿足SDK信息披露的要求。

其次需要關注SDK的版本，根據個保法推進的情況來看，不少第三方消息推送服務商應該在2021年推出了新的SDK版本，減少了敏感信息的收集使用。

同理可檢查App使用的其他SDK是否也有類似的更新，如有，建議全面更新SDK版本，盡可能規避合規性風險。

4）消息推送

主要是三部分内容。

一是權限管理，市面上App主要管理權限包括：

• 手機自帶的消息推送設備權限，就是一般App打開之後會普遍詢問的權限，在20年11月之前的調研中發現，也有的App在某些設備機型是默認打開消息推送權限的。
• 分類消息的推送權限，支持用戶按照消息分類選擇性接收消息推送。
• 分類消息的提醒權限，支持用戶按照消息分類選擇接收但不對消息進行通知欄、未讀消息小紅點的提醒等。
• 按照個人特征進行個性化推送的權限，在個保法推行之前市面上相關的産品方案已經比較成熟，保持和大家方案一緻即可。

二是推送頻次，根據個保法的要求，原則上不應頻繁推送打擾用戶。

目前暫未發現有關部門通報哪家産品消息推送過于頻繁打擾到用戶的，大家酌情控制推送頻次即可。

三是推送内容，主要參考材料為《網絡信息内容生态治理規定》。正常業務推進的時候一般不會犯這種敏感又低級的錯誤，但是實操方面，各App測試消息推送發生生産事故的案例确實不少……

所以一是提醒大家做好流程管理和賬号權限管理，專人專事，減少出錯機會；二是在第三方消息推送服務商的後台可配置相關敏感詞，消息提送時可直接過濾帶有敏感詞的推送内容。像黃賭毒之類的敏感詞，一般第三方消息推送服務商會自帶風控過濾機制。

2. 其他風險

我們在推進項目的時候主要關注接口并發，不過因為第三方消息推送服務商的能力已經比較成熟，确實也沒辦法實現可驗證該說法的壓測，所以對基礎能力這邊僅做了風險性的評估。

此外，關于消息存儲方面，需要考慮到消息在服務器存儲多久、消息推送量大概多久等問題，需要根據App的實際情況與開發溝通後确定需求和資源。

四、實操過程

1. 了解消息推送的實現原理

在我們研究消息推送實現原理之前，首先需要明确，我們通常所指的消息推送是什麼。

1）通知欄消息（PUSH)

一般我們收到消息時，App頂部會彈出消息，然後在設備的通知欄可查看未點擊的消息。這種消息我們定義成通知欄消息，也就是一般大家所說的消息PUSH。

①iOS：實現消息推送是最簡單的，不論App是在線狀态還是離線狀态，消息推送至iOS的APNS服務器，APNS再根據設備标識推送至指定設備，用戶即可接收到消息。

大緻鍊路為：業務系統（發起推送）——第三方消息推送服務商的服務器（推送邏輯控制、推送下發）——蘋果APNS服務器——指定用戶設備。

②安卓：安卓因為廠商衆多，廠商能力不同，所以實現方式也不一緻。

安卓大廠如華為、小米、VIVO、OPPO，和iOS實現邏輯和效果基本一緻，我們稱之為消息推送通過廠商通道推送。

但是需要申請開發者賬号并綁定App，在開放平台開通廠商通道推送的權限。

這類廠商機型支持在線離線狀态的消息推送。消息推送大緻鍊路為：業務系統（發起推送）——第三方消息推送服務商的服務器（推送邏輯控制、推送下發）——廠商服務器——指定用戶設備。

像一些小衆手機的安卓廠商，不具備廠商通道推送能力，需要依賴于App的在線狀态。隻有在服務器能夠保持鍊接狀态的時候，設備才能接收到通知欄消息。

消息推送大緻鍊路為：業務系統（發起推送）——第三方消息推送服務商的服務器（推送邏輯控制、推送下發）——指定用戶設備。

離線狀态且未開通安卓設備保活機制的時候，設備終端是無法收到消息的。

順便提一下，如果消息下發時，App離線，消息可根據需求配置保存的時間，如在保存的時間範圍内App打開變為在線狀态，此時第三方消息推送服務商會将消息重新下發進行推送。

感興趣的小夥伴可網上搜索“消息推送實現原理”了解更多。

2）消息中心的消息

有一個大坑，在了解消息推送的原理之前，筆者一直以為消息是推送到消息中心的，直到自己在第三方消息推送服務商的平台嘗試推送消息，發現消息中心壓根收不到消息……

實際上消息中心的消息一般處理方式都是保存在自家的服務器端的，進入消息中心的時候去服務器端拉取數據。

所以通過第三方消息推送服務商的平台發的消息直接發到設備，消息中心根本查不到數據。

理論上消息發到客戶端可以讓客戶端做一下保存，但是實際卸載或者清除緩存之後，曆史消息就完全沒有辦法查看到了。基于App需要對消息進行留存的需求，該分支方案未再深入進行研究。

2. 選擇第三方服務商、進行商務談判

1）服務商選擇标準

客觀來說，如果沒有在多家公司實施多個同類項目的經驗，壓根是不知道哪家第三方服務商更好的。所以我們明确目标——第三方服務商的産品和服務能夠滿足我們的要求即可，并不一定需要業内最好。

我個人選擇服務商，主要參考以下标準：

• 服務商的行業經驗：越久深耕的，一般産品越成熟。
• 服務商的行業口碑：一般去知乎上就能看到，不過也有水軍，但是有一家大家都知道是水軍知乎都在罵水軍和罵他家産品的也是挺離譜的。需要自己判斷，沒人說好的未必不好，有人說好的未必真的好。順便互聯網群多一點，去群裡吼一聲問問大家，有沒有此類項目實施經驗、服務商産品和服務如何，基本就可以得出自己的判斷了。
• 商務對接感受：如果對接期間商務讓你覺得不專業、有顧慮，那基本建議不要考慮了，除非已經鐵了心就決定是這家了。合作洽談階段如果問題都沒辦法得到順暢的解決，那如何能指望付完錢之後對方優質的服務能力呢？

根據以上标準，我選擇的服務商，在施行項目對接時，基本能做到快速回複和要求的滿足，售後問題的對接也順暢。

2）商務談判

确認好意向服務商之後，就要進行商務談判，确認服務和最終報價了。

因為個人有在SaaS公司從業的經曆，所以我很明确的一點是：像消息推送這種标準化的産品，成本主要在前期的研發上，後面每增加一個新的客戶，所投入的成本基本都是邊際效應遞減的。

這種情況下，銷售為了業績，基本在定價方面都是比較自由的，也就是同一個産品，賣給A客戶可能是十幾萬，賣給B客戶可能是幾十萬。

所以如何能知道對方的價格底線呢？這種情況建議：

• 多家服務商對接，了解業内定價範圍，并通過自己作為價格敏感性的客戶，讓商務的報價“卷”出一個盡可能的最低價。
• 群裡問問其他小夥伴。

處于為公司省錢的立場，我在多輪談判後，把價格壓到了首次報價的1/4不到，完成了服務的采購。

不過價格方面是否需要壓到盡可能低，大家可以根據自己面臨的實際情況評估。

3. 産品需求設計

這裡沒什麼好說的，按部就班進行前後台功能設計即可。

稍微複雜一點的是需要理清App外未讀消息通知、消息中心、消息分類未讀消息的邏輯以及各權限的控制問題。

4. 需求評審和實現方案評審

在大公司，一般技術實現方案會由技術負責人負責，産品經理是不用管技術實現的。

但是因為筆者的公司沒有技術負責人的角色，因此需要筆者在進行需求方案評審時同步與開發團隊确認具體的技術實現方式。

小公司的産品經理有的時候也必須對技術方案進行把控，好處是能多了解一些技術知識，更好地把控項目推進；壞處是人的精力畢竟是有限的，主要看公司需求。

5. 測試用例評審

正常組織開發和測試進行用例評審，根據測試用例再一次與開發和測試确認需求宣講想表達的信息是否到位，并确認測試提供的用例，是否盡可能覆蓋了全部場景。

6. 項目上線

完成開發、清掉所有bug之後，産品走一遍主流程。找開發評估一下安全風險和性能風險，沒有問題，發布生産環境，項目就上線了。

7. 項目複盤

1）對業務的支撐和數據表現

項目上線後沒多久，公司進行活動推廣，正好用上了我們的功能……還算是實現了對業務的支撐吧。

因為項目時間緊，我們沒有做數據統計相關的功能，隻使用第三方消息推送服務商的平台進行查看發送、送達、打開的數據。

實際對業務的促進作用，沒有很多直觀的數據可以展示出來。目前消息推送對業務的支撐數據需求清單已經列出，預計在疊代的版本進行統計。

2）項目推進周期複盤

原則上如果筆者沒有死磕，希望找到業内盡可能好的服務商談到盡可能優惠的價格，在采購階段的時間應該可以省個半周時間。

而最終的結果是，雖然談到了筆者所認為的業内盡可能好的服務商和盡可能優惠的價格，但是公司基本不care，這點值得反思。

以上是個人對消息推送項目推進的實操和個人理解，如有不正确的，歡迎大家指出、溝通讨論。

最後，特别感謝獅廠的前同事提供的建議和幫助。

本文由 @胖大星 原創發布于人人都是産品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議。

,