编辑导语：消息推送功能是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协议。