一套完整的APP推送体系方案|附思维导图

联想到自己当初作为实习菜鸟也犯过类似的推送事故，好在补救处理尚可，最终结果不错。这次仔细看了问题下的每一条回答，发现不少用户认为push是骚扰，且因不堪忍受push干扰而选择屏蔽推送功能或删除APP……对于产品和运营来说，这很是一件脑壳疼的事情。所以，结合这两年来的推送经验，就如何搭建APP推送体系做了一次全面复盘，旨在为大家提供一条完整思路。

获取下文中APP推送体系完整高清版思维导图请在后台回复关键词【push】

一、APP推送路径及常见问题

APP推送的本质是让APP与用户之间的连接更加友好、紧密，提升用户体验并促活。然而执行起来并不容易，效果也通常不尽人意，用户更是不堪其扰。那么，如何保证用户的良好推送体验呢？我想，这个问题还是得从推送流程中运营及用户的行为路径说起。

如图，可以看到，推送通知从运营发出到触达用户的过程中，经历了内容筛选、文案提炼、时间选择、频次管理、用户授权、效果监测等6个环节。这些环节中的用户行为，也折射出了APP推送面临的5个主要问题：

1．用户设备未设置允许推送权限；

2．推送内容与用户偏好不匹配；

3．推送时间点不当，时效欠缺；

4．推送过于频繁，造成骚扰；

5．推送文案缺乏点击欲。

所以，接下来，我将从推送渠道搭建开始，为大家一一梳理APP推送体系中的各个环节，以及对应问题的处理策略。

二、搭建推送渠道

推送是通过渠道承载的，而一个完整的APP推送渠道，应该包含APP自有渠道和第三方渠道两个方面。

1.APP自有渠道

所谓APP自建渠道，指基于自家产品的APP推送，主要作用于产品现有存量用户。按技术可划分为运营推送、系统通知、交互通知三大类：

运营推送是运营人员为达到促活、留存等目的而配置的个性化推送，含活动通知、热点资讯等。这是体现运营水准的重要方式，也是本文的重点。

系统通知是经由技术代码写进产品程序中，当用户触发一定条件而接收的系统自动推送。例如系统更新等，大家收到的消息都一样。

交互通知严格来说，也属于系统通知，只不过触发机制源于用户的交互行为，比如发布内容后获得的点赞/评论/收藏/关注/转发等系统通知；根据用户交行为有明显的个性化差异。

2.第三方渠道

第三方渠道是借住第三方平台展开的推送，也是用户未开通APP推送权限时常用的触达手段。包含短信、邮件、以及以微博、微信公众号为代表的自媒体渠道等。产品是否展开第三方推送渠道运营？是主打单个渠道还是兼顾多个渠道？如何规划第三方渠道的运营节奏？这是企业在搭建推送渠道时都需要思考的问题。

三、获取推送权限

无论是APP推送还是第三方渠道推送，实现推送的前提是获得用户允许推送权限。

如今安装APP时，基本都会有授权提示——是否允许推送，选择允许，可接收APP推送通知；选择不允许，一般不接收APP推送通知。但即使用户在安装APP时选择了允许推送，若后续体验不佳，也可随时关闭推送权限甚至卸载APP。

那么，如何引导用户开通允许推送权限呢？这个问题网上很少被提及，现行方案主要是弹窗引导，通过弹窗让用户了解允许推送，会有什么好处。比如，会收到哪些重要信息！会得到哪些有价值奖励（比如积分、红包、体验卡、优惠券等）！虽然，弹窗引导的原理大家都一样，但细节决定成败！展示界面、提示文案、弹出场景都是可以发力的地方。

而对于第三方渠道而言，所受的推送权限设置主要来于账号关注、内容拦截、以及次数限制。当前以双微为代表的自媒体渠道在粉丝管理及推送上已经有相对完善的体系，缺点就是用户捏在第三方手中，推送次数、内容、用户深度管理等都会受到限制。比如微信订阅号推送限1天1次，微信服务号推送限4次/月，且不得诱导用户分享。而短信，则是经常被拦截或被当做垃圾短信过滤掉，被用户看到的几率不高，邮件则更是如此。

无论是APP自有推送，还是第三方渠道推送，充分了解并持续优化有关授权影响因素，是获取持续推送权限必须考虑并解决的问题。

四、精准推送内容

如何筛选推送内容？用户需求决定推送内容，保证运营推送的内容与用户需求高度匹配，追求精准内容推送。具体可以通过用户分群、内容筛选、内容匹配三步实现。

第一步，用户分群是精准推送的核心。

用户分群的维度很多，而基于精准推送的目的，则有用户行为、内容偏好、标签选择三个维度。其中，行为维度常用于工具类产品；偏好维度常见于电商类、内容类产品；标签维度则常用于垂直型社区产品。在实战应用中，由于产品所处生命周期以及关键性指标的变动，用户分群的依据也会有所变化，产品应当根据自身属性做出合适的选择。

第二步，内容筛选保证推送的质量。

内容筛选一般有人工、算法两个维度，算法主要由产品和技术把关，此处主要讲运营人工把关。由于产品属性差异，筛选内容的判断依据各不相同，以内容社区为例，筛选推送内容的标准应该包含匹配性、价值性、原创性、专业性、时效性和趣味性6个方面，而其中最重要也常被忽视的一点便是匹配性。

第三步，结合用户分群完成内容匹配。

为什么APP推送会被看做用户骚扰？关键在于推送的内容与用户需求不相关、不匹配，不被用户所需要。前面说过，APP推送的本质是让APP与用户之间的连接更加友好、紧密，提升用户体验并促活。而事实上，APP推送往往被本末倒置，为达到促活目的而罔顾用户需求强行推送，从而变成骚扰。

为了避免APP推送变成用户骚扰，运营需要将筛选出来的内容，进行用户群体匹配，分别推送给不同用户群，尽可能满足用户个性化需求。

五、打磨推送文案

关于如何写推送文案，网上的相关资料数不胜数，套路很多，原理也没问题。因此，我想强调的只有四点：

第1、主题突出，清晰易懂。设置推送文案时需要尽可能在有限显示篇幅里，传达最重要的信息，而不是把过多篇幅留给场景渲染，让用户不明所以。

第2、简洁明了，切忌过长。推送文案有显示字数限制，且不同机型设备可显示字数不一样；同时推送文案有两种显示类型，区别在于标题是否可自主配置，运营人员推送时应充分考虑到这些因素影响。

第3、常见套路的尺度把控。网上关于文案拟定套路的文章很多，其中不少提到了AIDA模型（吸引注意力→引起兴趣→激发欲望→促进行动）。对此，我都表示认可，但是需要强调的是，一定要把握好尺度，切忌用力过猛。举个例子：

看到这些标题熟悉不？朋友圈、亲友群里常见刷屏文章类型。从某种意义上，这种文案套路是很有用的，对于缺乏主观判断能力的一类人。然而，遗憾的是，当代年轻人们早早通过互联网尝遍各式套路，极富主见，审美能力普遍不弱，看见这种标题难免觉得格调太低，反感是常态。

第4、走心才是最强的套路！或许是因为互联网时代，注意力资源稀缺，大家都拼命博套路，而忘了最简单的道理：文案需要走心！也有很多人简单的认为走心就是说两句煽情话……什么才是走心？我想，应该是想用户所想，忧用户所忧，站在用户角度提供需要的服务，就像下雨前的一个用餐提醒一样！

走心的文案背后，一定是一个深刻的洞察！不需要太多华丽辞藻雕饰、太多套路引人注意，就能直戳人心。

六、选择推送时间

无疑，在错误的时间点推送是不会有任何正面效果的。那么，该如何选择推送时间点呢？

在两年的推送实践，以及长期跟踪80+个APP日常推送后，总结出了有关推送时间的一些规律：

如果是类似行业头条、八卦爆料、新闻政策类影响较广、热度较高的内容，那么时效性就是第一要义，必然是即刻推送了。

如果是早/晚播报，类似篝火营地【篝火新闻早茶】、即刻【一觉醒来世界发生了什么】，那么为了培养用户接收习惯，必然是定点通知了，具体时间点的选择，可以从行业属性、用户习惯结合AB测试法来确定。

如果是周期性更新的内容，则选择周期推送的方式。关于周期性推送，基本原理同定点推送，只不过周期较长不以日为单位。具体有两种类型：

• 类似综艺节目、视频剧集、小说章节类长期连载性质的内容，应在内容更新时同步推送持续关注的用户。最近，我在B站追《少年歌行》，这部国漫每周三10点更新，恰好今天周三，于是10点的时候收到了B站发来的更新通知，它提醒了我有最新内容可看了，我很开心。对于这类用户本身关注内容的推送，用户会觉得是骚扰吗？当然不会。

• 类似企微里的【一周小结】、微信游戏里的【王者战报】。基于过去一周的用户行为做一个总结梳理，类似的功能很多产品都有，我在和好友聊天以及朋友圈中多次看到类似的分享，但是迄今未见过有产品将其以外化以APP推送的形式反馈给用户。也许，这是一个值得挖掘的方向。

七、把握推送频次

推送过于频繁、给用户造成骚扰是当前APP推送面临的主要难题之一。无论何时，需要牢记APP推送的本质为了促进产品与用户之间的连接更加友好、紧密。因此，推送的出发点应该是基于用户需求，而推送的频次则取决于用户使用产品的频次。而产品的使用频次则和产品类型、使用场景、用户类型三个因素息息相关。

1．产品类型。对于百度地图等工具类APP，用户使用频次有限，一般每天推送不宜超过1条；对于新闻、视频等内容类产品，除用户订阅更新外，一般每天推送应控制在3条以内；对于双微、QQ、以及各大垂直社区等社交类APP可以更频繁一些，但依然建议控制在每天5条以内。

2．使用场景。还是百度地图为例，用户只在特定场合有需求。结合定位功能，如果用户处于常规路线范围类，推送频次一般不超过每天1次；而当用户出现在常规路线范围外，可能是在出差旅行，总之到了一个陌生的新地方，对于地图的需求变得强烈，不需要产品主动推送就会多次打开地图。此时，无疑可以增加推送频次。

3．生命周期。这个无需多言，用户处于不同生命周期，对于产品的使用频次完全不同。

如今手机内存不断提升，每个人的手机上APP少则数十个，多则百来个，每天收到的推送更是多如牛毛。然而，除了用户有强需求的APP外被日常频繁使用外，很多APP超过30天都未被访问，任凭你每天狂轰滥炸。毕竟，出色的产品本身比任何运营手段都更有效！

八、常见应急措施

一个完整APP推送体系，少不了对于可能发生问题的应急处理措施。本文开头提到的push事故等突发问题常有发生，类似危机，如果没有提前思考过，很难妥当处理。推送事故可能是多方面的责任，但是不用怀疑，站出来的永远是产品和运营。在此，从后台容错机制设置和常见推送问题处理两个方面简单梳理了一下应急思路，希望对同胞们有所启发。

1、设置容错机制

从技术层面设置推送容错机制，可以避免绝大部分推送事故。

批量推送前进行推送测试，检查展示效果和相关跳转是否正常，保证消息推送前无误；推送拦截作用于推送操作完成后发现问题，可以通过人工中止或修改等按钮来调整或中止问题推送流程，也可以是系统自动拦截一定时间段内的二次重复推送；推送上限则是用来避免某一用户处于多个分组和标签下从而多途径接收同一推送的问题。

2、常见事故处理

若事故已然发生，不要慌！危机公共5S原则依然很有用，第一时间做出回应，把事情主动权控制在自己手中，避免事情被恶意揣测无限发酵，从而造成无法挽回的影响。

是将错就错，展开一次bug事件营销？还是诚恳认错，告知缘由？这取决于产品类型、推送内容以及事故类型。

bug营销很早就有，但是一直都没能成为主流营销方式之一，主要在于不可控性，稍有不慎bug营销就变真bug了。

而不同于有预谋有规划的bug营销活动，想将被动产生的bug事故在极短时间内转化为有规划的bug营销事件，其实现更是难上加难！

所以，遇到推送事故可以先迅速思考展开bug营销的可能性和执行方案，如果有较好的想法，需要迅速和相关管理层协商，得到明确回复后立即展开行动；如果半小时内都没有想法，那么老老实实按照当前通用套路走，诚恳道歉，良心补偿！一般来说，从事故发生到用户收到回应，这个过程控制在1个小时以内为宜。