推送系统从0到1
（一）是系统不是工具
- 如果你是运营人员，你可以在文中了解推送所蕴含大量运营策略；
- 如果你是产品经理，只是用推送完成消息的传递，你可以在文中了解到推送可以实现更大的价值；
- 如果你正准备着手构建你的推送系统，但不知道如何下手，你可以在文中了解整个推送从0到1；
- 如果你已经使用推送作为日常运营方式，你可以在文中了解系统性的设计能让推送威力翻倍。
网上很多资料有关于推送的文章大多是介绍推送需要注意的几个点，注意的相关数据以及推送的运营策略。包括推送的作用以及能产生的效果，想必大家都已经有所了解，这里不再单独介绍。但是对于整个推送系统全面剖析，以系统性的思维对推送这件小事有结构性的了解的介绍文章少之又少。
本篇文章作为系列的开端，只是阐述一个思想，也是着手做之前最重要的思想，以系统来看待推送。
何为系统？
中国著名学者钱学森认为：“系统是由相互作用相互依赖的若干组成部分结合而成的，具有特定功能的有机整体，而且这个有机整体又是它从属的更大系统的组成部分。”系统是指将零散的东西进行有序的整理、编排形成的具有整体性的整体。
从上述定义中可以看出，系统所需要具备的几个条件：
- 包含若干组成部分（零散）
- 各部分相互作用、依赖
- 最终结合并形成整体
若干知识相互作用组成系统
以手机淘宝为例，如果你使用手机淘宝浏览一件商品A，在第二天中午12收到淘宝的推送，推送的内容与你所浏览过的商品相关，你会非常有点开看一看的想法。
此时选择在中午12点，给你推送商品A相关内容，并且写出吸引你去看的推送文案，以及制作精美的着陆页则为运营面知识。
通过大量数据分析，知道你喜欢商品A，同时知道你会喜欢与商品A相关的商品B或同类信息，并且能准确无误的把消息推送到你的设备上，则使用到技术面知识。
设计以上系统结构，完成整个流程以及促成后续行为转化的过程，也非常考验产品设计的功力。
看似简单的推送，其实蕴含着产品、运营、技术要点等众多的知识要求。推送可以简单到只是一个工具，但是想要做好这件小事，对产品经理的运营、结构设计、技术知识、设备熟悉度都有一定的要求。从其所涵盖的知识面可以看得出，推送就是一个系统。
三个层级相互依赖组成系统
有些人觉得推送就是个工具，建立个推送任务，点击发送就完事了。但是在推送时，实际上还要考虑：
- 何时何地给谁发什么消息，为什么？
- 发了多少条消息中多少个用户收到了，多少用户点了看，看了之后做什么？
- 有多少目标用户，目标用户喜欢看什么，有什么内容可以满足这些用户？
以上这些所考虑的内容都会体现在推送中。推送系统从其目的上来说，是通过设备的通知消息传递的方式满足用户的需求，从而实现某些运营策略。因此系统结构上来说，我会把它定位为“运营层”、“通信层”、“底层数据库”。
以微信公众号为例，发送什么内容、什么时候发、发给谁、等等 都是运营层；公众号后台编辑发布后，展示在粉丝的消息上则为通信层、而公众号底层数据完成了用户数据、消息内容存储等工作。其实微信消息推送通知也是通过其推送系统完成了消息传递的工作。
若干因素影响推送的效果
推送效果受到多个因素的影响，多个因素之间还存在相互矛盾的地方。因此如果此时你设计的推送效果不好，上网查询提高推送效果的方法，网上的资料也行会列出1、2、3、4..几点解决方案，但是如果不理解这若干因素影响的原因，就无法对症下药。以上面介绍的三个层级为例，每个层级有都若干因素会影响到推送效果。如：
- 运营层的影响因素：推送时间是否合理、推送文案是否吸引、目标用户的需求等
- 通信层的影响因素：发送数量、发送成功率、到达率，发送设备有效性等
- 数据层的影响因素：全过程数据是否清晰，用户对推送内容是否感兴趣等
这些关键因素相互依赖，组成三个层级。这些层级构成了推送系统。而这些关键因素相互影响，如推送数量影响推送质量；推送效率影响推送时间；推送到达影响运营效果。这些零散的因素相互作用下影响着整个推送系统。
为何要以系统性的思维看待推送
也许你此时在某第三方推送后台建立推送任务，勾选发送全体用户并点击发送。部分用户收到了消息，部分用户点击查看了。流量、运营目的达到了，美滋滋的说‘推送就是这么简单而已。
如果你把推送当成一个工具看待，你无法获得最大量的用户去完成你的运营计划；
如果你把推送当成一个工具看待，你无法了解推送过程中丢失了多少宝贵的用户数据；
如果你把推送当成一个工具看待，你无法达到激活沉默用户的有效策略。
如果你想让推送效果最大化，此时就不能简单的把推送当成一个工具。
系统性的设计思维能让你在设计之初就很清晰整个推送系统的结构，脑袋中自然会有一个推送系统的结构图。考虑到每个关键因素、每个过程之间的衔接，每个层级如果更完善，能让推送给你带来意想不到的收获。
- 完善底层数据：能帮助你剖析用户的需求、了解推送全过程的数据流动情况，即时掌握转化致命点。
- 完善通信传递：能让消息尽可能多的准确抵达用户设备，也不枉辛苦想出的运营策略在半路夭折。
- 完善运营策略：能让产品数据有明显的变化，对活跃用户、用户留存、流量等有明显提升，对业务转化、运营目标有更大的效果帮助。
综上所述，在系列第一篇是非常有必要介绍系统化设计的观念；以便在你动手之前，能够决定接下来怎么做这件事以及最终能产生的效果。
如何从0到1构建推送系统
如果此时你已经明白要如何看待推送，想以系统性的方式去构建这套系统，但是不知道如何下手。那么干货来了，本系列接下来的文章将会带着大家一步步的搭建这个系统，涵盖运营的方式、推送全过程的剖析、设计过程中需要注意的关键点等。尽情期待！
（二）了解你的用户
上篇介绍了要以系统的思维来看待推送，没看过的小伙伴可以回顾一下。而本篇就是真正着手开始构建推送系统了。阅读本篇，你能收获：
- 浏览器推送还是APP推送？
- 如何选择推送平台？
- 用户、设备、Token之间的关系？
- 如何标识你的用户？
以上问题都是在开始搭建推送系统时困扰大家的问题，但其实最终的答案只有一个，就是了解你的用户。你的用户决定了你如何构建推送系统。
下面我们开始第一步，选择推送平台：
一、用户决定了推送平台的选择
为了实现消息的传递，搭建推送系统的第一步，就是选择靠谱的推送平台实现消息精准无误的传递到用户的设备上。
作为产品经理的我们，对推送的实现技术也许没有那么深入的了解，此时在做选择的时候，也许就会在网上查找各种资料，尝试各种推送平台。
但其实，你的用户已经决定了你该如何选择。
1.浏览器推送还是APP推送？
相信问题的答案非常显而易见，大家应该都会选择APP推送，因为在国内大多数站台其APP用户已经占站台80%以上的用户。
但这里还是要说一下，如果你的用户在浏览器（PC、触屏）有一定比例，也可以尝试进行浏览器推送，让整体推送效果最大化。
以我自己为例，我们站台主要面对台湾市场，而用户在PC和触屏端占比有近60%，因此浏览器推送也在我搭建推送系统的范畴内，并且也取得不错的成效。相信此时大家心中也有答案了，看那个设备端用户占比最多。
2.如何选择推送服务？
网上查资料，各种推送某光、某云、某鸽、某盟、某米等，还有推送自己建立推送平台。到底该如何选择推送服务呢？其实还是很简单，由你的用户决定了选择哪个推送平台。
(1).系统级服务与应用级服务
1).系统级服务
- IOS：APNs，IOS系统服务简单而有效，必定走向系统级服务APNs。所以IOS系统不需要选择。
- Android：FCM/GCM，此为google官方的系统级推送服务，Chrome浏览器同样适用。不过必须依托于google服务。
- 其他：如小米手机的小米推送服务、华为手机的华为推送服务。
2).应用级服务
简单来说就是第三方服务商提供应用来解决推送问题。需要注意的是，若选择小米推送在非小米的手机上也会属于应用级服务。
应用级和系统级服务有什么差别呢？一句话概括就是：应用级的服务会被杀死，而系统不会杀死自己品牌的推送服务。
所以尽量选择系统级服务，但是大多数情况下，用户的设备不会这么高度一致，而国内google服务行不通。在这种情况下就不得不使用应用级服务，也就是选择第三方平台进行推送。
(2).第三方平台的选择
当用户群体广泛，设备类型较多且无法使用系统级推送服务时，只能考虑选择第三方平台，此时选择第三方平台则有一个简单的原理：第三方推送系统会共享一条推送链路。
也就是说选择一个服务于多款APP的第三方平台，越多越好。因为你会和软件A、B、C、D、E、…共享一条推送链路，若推送服务被杀掉后，可以通过其中一款软件来重新唤起链接。这样能减少你的推送服务被杀死的可能性，最大程度保证消息到达。
简单总结一下：
- 若用户主要在海外、港澳台地区，确认大部分用户都使用google服务，则建议使用FCM系统级推送。
- 若用户绝大多数是小米、华为手机，则可以考虑小米、华为内置的系统级推送服务。
- 若用户设备分布较为平均，没有特别集中的设备品牌，则可以选择服务规模较高的国内第三方服务。
- 若用户信息敏感，不希望信息经过第三方平台，则可以选择自建推送系统。但需要与手机厂商进行定制化合作，成本较高。
在完成推送平台的选择之后，我们要做的下一步就是要选择给谁进行推送。一些产品经理会认为，我只要在推送后台录入一串要发送的token就行了，真的是这样吗？
二、用户、设备、Token分不清
我常常会把用户、设备和Token之间的关系比喻成：人、电话、电话号码的关系。
认清楚他们三者的关系非常关键，很多产品经理经常会把Token数量当成了用户数量，这会导致推送的成效越来越差。
1.什么是用户、设备、Token
用户：就是你的目标用户，也就是你的站台使用者的人数，他们就是活生生的人。
设备：一个人有多个设备，就像一个人可能有多个电话。
因此用户与设备的关系是一对多的关系。
Token：用户的客户端在推送服务上注册的令牌，简单理解就是用来标识这个客户端的。对推送平台来说，就是根据Token来知道你要把消息发给哪个用户的客户端。类似于我知道你的电话号码，我就可以打电话给你。
但是需要注意，电话号码可能会被遗弃、更换，而且不同电信服务提供商的电话号码都是不同的，Token同样存在这种特性。
2.使用设备号作为用户的唯一标识
(1).为什么要选择唯一标识？
你知道每次推送到底发送给多少用户吗？多少用户收到了，多少用户点击了？其中多少的真实有效的用户呢？想要掌握这一系列数据，必须建立一个用户的唯一标识。使用这个唯一标识，你可以了解：
- 用户有效性，唯一标识能帮你辨别出有效的用户。
- 具体到个人，便于跟踪用户后续一系列数据表现。
- 整个网站对同一个用户有同样的标识，实现数据共享。
(2).唯一标识的特性
既然上述唯一标识的主要功能是帮助筛出有效的用户，具体个人，并且能作为全网站对用户的认知。那么唯一标识需要具备以下2个特点：
- 唯一：每个设备的设备号必须是不同的，才能作为唯一标识，就像身份证号。
- 不变：标识不能发生改变，不然就无法标识某个用户了。
那么根据这“唯一”、“不变”这两个特点，选择什么来作为唯一标识呢？
(3).使用什么作为唯一标识？
1).选择用户作为唯一标识：
若你的网站必须登录才可以使用且用户ID不会发生改变，那么可以把用户ID作为唯一标识，因为用户ID是最贴近真实用户的数量。但是前提要保证每个设备必须登录用户ID。例如聊天软件，即时推送消息是跟随账号进行区分的。
但是很多情况非常多的APP是不需要登陆即可使用的，此时无法使用会员账号来标识每个用户。
2).选择Token作为唯一标识：
该方法是行不通的，同时非常多的产品经理会踩这个坑（包括我以前）。如果把Token作为唯一标识，你就会发现越推送，效果越差。因为你已经无法把无效用户和有效用户区分开来了，当Token失效的时候，你会以为该用户也失效了。
3).使用设备号作为唯一标识：
强烈推荐，因为设备号存在两种特性：只要硬件不变，设备号一般是不会变化；设备号一般不会出现重复的情况，适合作为唯一标识。
同时大多数时候，特别对于APP来说，我们会使用设备数/活跃用户数来作为APP用户数的衡量标准。
但是该方法也有3个缺点：
- 即时通讯类的推送不适合，多数即时通讯使用会员账号来区分消息。
- 与网站真实用户数有一定差距，一个真实用户可能会有多个设备，因此会存在一定差别。
- 浏览器端的设备号由于技术原因会与真实用户数存在一定误差。
但纵观以上三种方式，设备号是最适合一般类型的应用作为唯一标识。
三、本篇总结
本篇文章主要从推送平台的选择和标识用户的角度进行了理论性的阐述，归纳下来为以下两点：
- 如何选择推送平台：根据用户的设备情况进行选择
- 如何标识用户：使用用户的设备号作为唯一标识
下一篇会是实战篇，会从如何建立用户-设备-Token关联、Token的获取、如何筛选出有效用户等角度进行逐步讲解。
（三）推送任务的建立
上一篇文章已经讲述了如何选择推送服务，并梳理了用户与设备、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点：
- 建立有效的用户池：获得用户最新的‘联系方式’
- 建立有效性筛查机制：无效设备统统剔除
- 建立推送任务的要素：推送时间、推送设备、推送用户、推送内容（标题、文案、图片、其他富文本、着陆页）
（四）消息如何到达用户设备
在上一篇文章中，我们可以知道在建立推送任务的过程中，需要考虑带有自滤功能的用户池构建、筛选有效用户、设置推送内容、推送时间、着陆页的设置及相关用途等信息。如果还不清楚的童鞋可以回顾上一篇文章：推送系统从0到1（三）：推送任务的建立 。
本篇主要为大家揭秘推送消息是如何传输的，如何到达用户设备上的，在不同的设备上会如何展示。所以首先会为大家讲解在建立推送任务之后，消息是如何传输的。
从服务端到推送服务平台
推送任务建立之后，服务端按照约定推送时间，把所设置的推送内容按照设备号查询对应的token，并发送给对应的推送平台。
值得注意的是：如果同时接入多个推送平台则需要针对设备号标记，这个设备需要采用哪个平台的token进行推送。Token是对于推送服务平台来说是用户的唯一标识，不同推送服务之间的token均不相同。也是因为如此，才建议大家使用设备号作为我们对用户的标识。
推送服务通过长连接下发
如同想要给别人打电话，首先要做的事情就是拨通号码，而推送同样的首先需要推送服务与客户端建立长连接。只有接通之后，才能把通知消息传送给客户端。
在第二篇文章中，已经有讲到我们需要选择推送服务，推送服务将会尝试与客户端建立长连接，只有成功建立长连接的设备可以进行下一步。此时无法建立长连接的设备可能由于Token变更、推送服务无法唤起等其他异常情况导致无法与客户端建立长连接。
无法建立长连接的设备将无法进行推送，此时可以把该部分用户从推送队列中筛出来，并进行标记。防止推送队列在执行过程中，因为部分设备无法建立连接的原因，导致推送任务的中止。
同时被标记出来的用户，可以引入“重发机制”，关于“重发机制”的内容将会在下一篇“推送过程中丢失的消息”详细讲述。当设备多次无法建立长连接时，该设备处于暂时失效状态，即可进入黑名单。
在完成长连接的建立后，可执行消息的下发，第三方的推送服务使用自身的服务通道进行传输，而谷歌推送服务则会使用fcm/gcm通道进行传输。对于苹果手机来说，第三方服务均承担转发的任务，最后把消息传输给APNS，由APNS完成消息传输的任务。当然也可以直接由自己的服务端把消息传给APNS，不通过第三方平台，只不过使用第三方平台转发可以减少服务器开销。
消息送达和路由
对于苹果推送来说，APNS执行消息推送后，此时消息到达苹果手机上，由苹果系统执行消息的送到和路由展示。
对于Android系统来说，消息的到达和路由展示更为开放，可以使用自定义的消息处理方式，自主的选择消息收到之后是否路由展示，并可以展示成自定义的通知样式。
所以凭借Android系统开放性的消息处理方式，可以在消息发送的预测试、消息重发机制等方式，灵活巧妙的弥补消息的无效发送和消息丢失问题。关于这些弥补方案将会在下一篇详细讲述。
推送消息的展示
为什么要关注消息的展示方式？
因为消息的展示是吸引用户点击最重要的因素，用户通过浏览通知消息决定是否点开浏览，所以消息的展示至为重要。除了消息的内容以外，消息能否正常展示，展示成何种样式，能否在众多通知消息中脱颖而出，成为了争夺点击的重要关键点，以下会从针对不同系统的消息的展示方式进行讲解。
Android系统
Android系统从1.X到8.X通知栏进行了非常大的变化和改版，由于Android系统对个性化开放的追求，不仅部分Android手机拥有个性化的通知栏（如：国产机）以外，谷歌也在持续对通知栏进行调整和优化，提供更多的个性化支持，并提供自定义通知消息。
下面简单介绍几种标准Android系统的通知展示：
- Android 5.x系统：引入Material Design的设计风格，通知栏主要为白色背景、暗色字体，并可通过状态栏的悬浮窗口展示通知消息。
- Android 6.X系统：允许用户控制应用通知的优先级并且加入免打扰模式。
- Android 7.X系统：通知栏全面改版，左上角小图标、app名称、副标题、数量和时间在第一列、第二列为主标题、第三列为内容，并且支持直接回复。更为重要的是支持通知消息组，通知消息达到一定数量（好像是4条以上）会合并成消息组展示。
- Android 8.X系统：引入通知渠道的概念，即可以把推送类型分成多个渠道进行推送，用户可自主选择开启或关闭其中的一个或全部渠道。增加通知标志，用户可以通过长按应用图标来浏览通知消息，还提供自定义通知的背景颜色等个性化功能。
图片来自Xing’s Blog，如有侵权请联系本人立即删除
IOS 系统
- IOS 10系统：支持富文本通知展示，如：图片、GIF、视频等；通知调整为圆角卡片式展示，3D touch可以展示通知详情等。
- IOS 11系统：合并锁屏和通知中心。默认显示新通知，上滑显示所有未处理的通知，锁定屏幕时，将所有未处理的通知移入「历史通知」列表。
- IOS 12系统：新增通知分组功能，增加安静通知功能，强化勿扰模式。
谷歌浏览器
- PC端：windows机器和mac机器的chrome浏览器均可以支持单条消息推送，windows机器的chrome浏览器还可以支持多条消息合并推送。
- 手机端：Android手机chrome浏览器支持类似于APP的通知推送，谷歌推出pwa技术可以让手机端浏览器推送效果更像原生APP。
通过对比可以发现：不同系统设备关于推送通知的展示会有所不同，即使用个系统不同版本之间也纯在差异。切勿以偏概全，不考虑设备端的差异就只管发送。也许部分用户都无法看全推送通知内容，点击率自然上不去。
所以在进行客户端差异化展示的设计中，可以遵循以下方式：
- 根据应用/网站主流用户的设备情况，选择主要处理的几个系统；
- 根据系统的不同版本之间的特性进行单独处理；
- 若是批量发送，需要考虑标题、内容长度能否在不同系统之间兼容；
- 测试各系统设备的展示效果，力求效果最优。
同时需要注意到部分系统的特性，例如：Android7.x以上系统，当收到超过一定数量推送消息后，消息将会合并成消息组。这样既不利于通知消息的曝光，也不利于用户的点击。所以在短时间内的推送数量所需要考虑的。
又如：IOS系统的推送通知本身没有明显的标题和内容区分，但是按照用户的浏览习惯，若有明显标题展示点击意愿更为强烈（可自行测试），此时可把内容的第一行作为IOS通知的标题并加粗。
同时IOS10以上系统支持3Dtouch查看，通知详情则可以附加一些富文本内容增加吸引力。
本篇总结
本篇文章主要介绍了从推送任务建立之后，推送消息是如何到达用户的设备上，并且会展示成什么样式，那么归纳起来有以下四点：
- 推送消息首先会由服务端根据token发送给推送服务；
- 推送服务通过长连接把通知消息下发给设备；
- 设备把推送消息路由且显示出来；
- 推送消息的展示会根据设备和系统有所差异，需要有针对性的设计。
通过本篇介绍已经了解到消息是如何传达用户设备的，但是你知道消息在传递过程中会遇到什么艰难险阻，消息在推送过程中是如何丢失的，为什么推送到达率和点击率不高？
（五）推送消息如何丢失的
上一篇文章已经详细讲述了推送任务建立后，消息是如何到达用户的设备上的，在推送消息的传输过程中经历了什么步骤。大家可以再回顾一下 推送系统从0到1（四）：消息如何到达设备。
相信使用过推送的童鞋一定会遇到过这样的场景：明明给1万个用户发了推送，结果只有不到100个用户点开并浏览了，难道推送的内容这么没有吸引力吗？还是什么原因呢？如果你也遇到过这种情况，别着急，不一定是推送的内容没有吸引力，很可能是推送消息在推送的过程中“偷偷溜走了”。
从系列文章第二篇，我就一直给大家强调在推送系统的构建中，要尽量排除掉无效的设备，尽量让消息能正常的到达用户的设备上，这样的推送点击率才是最真实最能反映推送文案对用户的吸引力。
所以在建立推送任务之前，有向大家介绍如何标识你的用户，如何选择推送服务，如何建立带有自滤功能的用户池。这一切的一切都是希望在消息推送过程中，减少消息的丢失。那么消息在推送过程中，到底为什么会丢失呢？下面为大家详细讲解。
你的用户已离开
在推送任务建立之后，即便你按照我所说的构建带有过滤功能的用户池，同时也进行了有效用户的甄别。但是在推送的目标用户中，仍然存在无效用户，这些用户也许已经卸载了你的APP，或者已经关闭了通知权限，但你并不知道。此时，这些用户注定是无法收到推送消息了。所以这是消息丢失的第一个环节，而这个问题几乎无法避免。我们只能通过一些方式尽量减少这些无效用户。
当用户卸载APP后，我们是否能知道该用户已经是无效的呢？若用户卸载APP，那么无法再通过APP告知我们的后台，这个用户已经不存在了。所以即便我们的用户池会判断用户的token是否发生变更，在此时也无法发挥作用。同时在甄别有效用户的时候，当APP卸载的一段时间内，推送服务仍然会认为该用户的token是有效的。所以在此环节也是难以判断。我个人的建议是，如果确实想要排除掉这些无效用户，可以考虑从以下两个角度入手：
（1）APP被用户卸载后，通过其他途径告知后台
如以前Android设备出现过APP卸载后，利用系统进程的某些服务来告知服务器。或 者使用其他APP的协助传输被卸载的消息（具体没尝试过，可以询问开发人员…
（2）甄别有效用户时，实际给该用户预先推送
此方法我在上一篇有提到过，实际推送是排查的有效方式，但是！预先推送空白通知， 如在苹果设备上，可能会被展示给用户看，对用户造成困扰。同时即便是预先推送测试， 用户收不到也可能是偶发的情况，只能在多次推送收不到的情况下，标记为疑似无效用户。
若用户关闭通知权限，此时也有一个办法能解决。用户关闭通知权限后，若开启APP，则可通过APP检测到权限是被关闭的，并告诉服务端这个用户已经失效且不可再推送了。当然这个方法仍然不是万全之策，若用户关闭通知权限之后，没有再启动过APP，那么此时如何告诉服务端，又是个难题。
所以在推送过程中，像上述情况因为用户已经无效，就已经丢失了一部分推送消息了。即便我们通过一些策略减少该问题的发生，仍然会不可避免的掺杂一些无效用户。那么除此之外还有什么情况会导致消息的丢失呢？
你的用户失联了
即使用户没有卸载APP，也没有关闭通知权限，此时你仍然有可能无法把消息推送给你的用户。在上一篇我有提到过，在推送任务开始的时候，需要与客户端所在的设备建立长连接，通过设备中的推送服务进程完成消息的传递。但是有可能无法建立连接导致用户‘失联’，这个原因其实我在第二篇有提到过。原因可能如下：
- 推送服务进程被系统杀死
- 推送服务进程被第三方软件杀死
- 设备无法建立长连接
先从第3个原因来看，这是最容易理解的，用户设备处于某种异常状态情况下，推送服务无法与用户建立长连接，或者长连接失效等情况存在，此时需要推送服务多次尝试与设备建立连接，若仍无法建立，则无法进行下一步的推送。那么我们回过来看前2个原因，都是因为Android推送服务进程被杀死，导致无法正常推送消息。这种情况多发生在Android推送时，使用第三方推送服务，系统的安全管家/省电模式将会把这些进程杀死（如OPPO）或第三方软件如某某管家、某某卫士等把进程杀死。如何避免这个问题的发生呢？可以考虑以下方案：
（1）考虑使用系统级推送
即接入你的用户主流设备系统的推送服务，假设你的用户主要使用华为、小米、OPPO、等设备，则可以考虑把这些推送服务都接入。但是随之而来的是研发成本、技术难题、维护成本等。
（2）使用大部分APP接入的推送服务
在第二篇也曾介绍过，若你的APP与其他主流APP均使用相同的推送服务，即便用户的设备把推送服务杀死后，若用户使用与你的APP同一家推送服务的其他APP，则可以实现相互唤醒。这样做的优点是接入研发成本较低，维护较为容易。但是缺点是过度依赖于用户的行为，用户若未开启这些APP，则被系统杀死的问题仍然难以解决。
总结来说，你要想尽一切办法让推送服务能在用户的设备中存活下来，当然此问题在苹果系统是不存在的，APNs是苹果唯一的系统级通道。而也是由于Android品牌的定制化及开放性问题，让市场上的Android品牌有各自改造过的系统、自己的推送服务通道、自己的系统管理机制。对于推送设计者和应用开发来说确实会造成一定的困扰。其实如果你请研发工程师反编译一些大厂出品的APP，你就会发现他们也会面对这些问题。有些APP选择和Android品牌手机厂商合作，让它的APP成为系统级服务。有些APP也会接入多种Android设备品牌提供的系统级推送服务，即便接入成本比较高，也会力求消息能正常到达。
推送服务的问题
即便排除了用户的有效性问题及负责长连接的进程能正常运用，天仍有不测风云。即便是苹果的APNs推送都不敢保证推送通知消息能百分百到达。推送服务作为一种服务也会存在故障、拥堵、丢失等情况，对于这种情况的存在几乎是不可避免的。当进行大批量发送时，这些情况都是偶有发生的。
对于推送服务拥堵、故障的问题，需要考虑推送服务提供商的规模及资质，部分推送服务拥有多个推送通道，可以同时容纳大批量的推送任务同时执行。这样出现拥堵的风险就能得到降低。但是对于我们作为推送系统的设计者来说，是需要正视这些偶发性的问题及服务故障问题的存在。及时这些问题存在，其实它在推送过程中所占消息丢失的比例很低。由于推送进程被杀死或者用户Token失效造成消息丢失的情况才是大头。
用户设备环境复杂
上面曾经讲述用户设备若无法与推送服务保持长连接，或者推送服务进程被杀死，此时会造成消息的丢失。其实除此以外，用户设备所处在环境对消息能否正常到达，是否可以正常路由显示也起着非常重要的因素。
你可能遇到过这么一种情况：在火车收到一条推送消息，讲的是几个小时前的即时新闻，你会吐槽到这个新闻推送一点也不及时。其实是因为你的设备处于弱网或无网状态，例如在电梯里、地铁上等弱网环境中，推送消息即使已经发出，但是由于网络情况差，而无法及时的显示在设备上。在这个过程中，网络状态较差的时候，推送服务将会替你把消息暂时存储下来，待接入良好的网络环境再重新展示出来。这样虽然消息无法及时到达，但已经能减少消息丢失的几率。可是在这个过程中消息丢失仍是不可避免的，仍然存在由于设备网络环境差造成的消息丢失。例如当设备较长一段时间处于关机或无网状态，当突然正常接入网络后，大量的推送消息被路由展示，在这个过程中就很有可能出现消息丢失。
点击率低，不一定是真的低
也许你会觉得推送点击率一般都比较低，Android在10%左右，IOS在5%左右已经不错了。那也许是你认识的点击率不是真的点击率。下面先给大家介绍概念：
- 发送成功率：建立推送任务成功数/计划发送用户总数
- 下发成功率：推送服务实际下发数/推送服务计划发送量
- 推送到达率：推送实际达到设备数/推送服务下发量
- 推送点击率：用户点击推送数/推送实际到达设备数
看着是不是有点抽象，待我详细介绍一遍。发送成功率指的是从你的推送系统服务端发传输到推送服务平台的成功率，这个时候做了有效用户的甄别等丢出，部分无效用户将会失败。所以这个成功率反应的是从你的服务端到推送服务的丢失和损耗，这个丢失一般比较小，如果此时丢失量很大的话，问题就出在服务端了。
推送平台通过长连接把推送消息进行下发，可能会遇到什么问题，在上面已经讲过了，这个过程中由于推送进程被杀死导致长连接失效，会造成大量推送消息丢失，因此在这个过程中丢失的消息相对较多，同时由于部分无效设备并未在第一阶段剔除，此时也将无法实现消息的下发。故会把问题堆积在这个过程中，往往消息下发过程可能成功率仅为80%左右。
当消息成功下发到设备上后，设备讲会对消息进行路由和展示，根据上面的讲述，这个过程会由于设备端的异常状态导致消息的丢失，但这个数量相对较少。所以消息的到达率=消息到达展示数/消息实际下发数。
纵观以上过程，消息在推送过程中已经损耗了70%，如果让点击率来“背锅”那点击率自然会更低。可以给大家算个账。假设点击量约为700个。使用错误的点击率=点击量/总发送量=700/10,000=7%；而正确的点击率=点击量/消息到达展示量=700/7,000=10%。是的，对比可以发现实际点击率并没有预想的这么低，而上述案例建立在消息丢失比较小的情况下，非常多情况消息丢失可能达到50%。
相比通过本篇文章的讲解，大家应该了解到推送消息在传输的过程中，在每个环节均会有丢失的情况，针对丢失的情况我们可以对其做一些对应的策略，关于如何提高推送消息的到达将会在后面的章节中讲到，敬请期待。
本篇总结
本篇主要为大家介绍了推送消息在传输过程中，会出现怎么样丢失的情况，而消息的丢失不应该归入点击率的计算。具体可以总结成以下几点：
- 推送发送时，可能由于用户卸载、关闭通知等情况导致消息丢失
- 推送下发时，可能由于长连接失效，推送服务进程被杀死导致丢失
- 推送到达时，可能由于设备网络情况差，处于异常状态导致丢失
- 推送点击率应该为点击数/实际到达展示数，消息丢失不应归入点击率
按照计划，下一篇将会为大家介绍，用户在收到推送消息后的一些点击和后续行为，希望大家能喜欢。
（六）推送的着陆页设计
上一篇为大家介绍了推送消息在传输过程中出现丢失的情况，并讲述了消息丢失的几个原因及建议，没看过的小伙伴可以看下 推送系统从0到1（五）：推送消息如何丢失的。从第二章开始围绕着推送的整个流程进行介绍，从推送服务的接入、推送消息的建立、消息传输、消息到达等阶段都进行了讲述。
本篇来到了推送流程的最后一个阶段，用户点击推送消息后进入到着路页。这个是用户使用推送系统的最后一个环节，也是整个推送的最终目的：把用户带入到着陆页。所以本篇将围绕推送着陆页的设计、着陆页的用户行为、消息中心等几个方面为大家介绍。本章将会是最后一篇讲述推送流程的文章，从下一章开始会深入从运营层面（如个性化推送）、数据层面（如用户画像、提高推送点击率、数据监控等）为大家介绍。
1. 着陆页的设计
用户收到推送消息后，若对推送的文案及内容产生兴趣，便会点开推送内容浏览详情。这与列表页似乎有些相似，通过标题、摘要或图片吸引用户进行浏览，只不过推送具有及时性、定向性。用户不需要处于应用内的列表页中，便也可以看到摘要的内容。能否吸引用户点开是推送消息内容的责任；而用户点开之后能否达成运营目的，则是着陆页的责任。
1.1 着陆页的类型
根据推送目的的需要，着陆页可以是APP中的原生页面、活动网页等。像是以促成APP内部流程转化的，如电商类网站的下单、发货、签收等；又如社交类软件的聊天消息；亦或者资讯类平台的文章内容等。这些类型的推送大多是跳转至APP内的原生页面，对于这类页面有2个好处：
- 原生页面加载快，减少点击消息到着陆过程中的用户流失
- 原生页面用户熟悉，了解该页面的出入口位置
但是该类型的页面也有局限性，用户对于这些页面过于熟悉，以至于后续再次点开的几率会减少。例如电商网站的发货提醒，你前几次点进去之后会发现就是一个订单发货状态。后续再次收到发货提醒的推送之后，根据通知消息知晓发货状态就完成了解进度的需求，不再需要点进去浏览了。
而活动类页面多使用H5等网页形式，由于其形式灵活多变所以使用网页的概率极高。相较于原生页面，其加载速度略微不暂优势（当然一些大厂的APP中这个差距可以忽视）。这个将有可能导致用户在等待过程中离开。但是活动类推送由于其蕴含的运营策略在其中，同时样式并非用户常见页面，对用户比较有吸引力。
综上所述，着陆页的设计最终还是根据推送需求所决定，只不过由于选择的页面类型不同，会有一定程度的数据表现差异，在进行设计的时候有这个预期便可。而着陆页的类型对于用户转化的影响并没有特别大，更大的在于用户对通知消息的预期与着陆页实际结果的差异。下面为大家介绍着陆页的用户预期。
1.2 着陆页的用户预期
与大多数公众号及列表页的用户预期相似，用户在浏览推送消息时也会产生一定的预期效应。用户可能会被所谓的“标题党”所吸引，也可能会对消息中的“诱惑”充满兴趣。但是在用户点击的那一刻，他的心里已对着陆页内容有所预期。也许你曾遇到过这样的场面，收到一条电商网站的关于优惠活动的推送：参与活动，立减XXX；你在被价格所吸引点后点开推送并在活动页中翻来覆去都无法找到优惠的地方，此时你一定会直接关掉APP。从推送的传播的角度来说这是成功的，用户成功被标题吸引并抵达着陆页。从本次推送的商业化转化效果则有待考量，但是毋庸置疑用户的预期是着陆页确实有优惠信息并且应当一进入便可找到。由于预期与着陆页不符，很可能用户下次根本不再会点开通知消息，或者用户会直接关闭通知权限。
所以在推送消息与着陆页的设计上需要考虑用户预期，相比于公众号或者列表页，标题党真的需要慎用再慎用，不然少则无法达到后续的转化目的，多则直接损失一个用户。毕竟像列表页点开发现不符合预期返回之后仍是列表，并且那是用户主动点开的行为。而对于推送消息是首先从外部进入到APP的，再者并非用户主动找到的，若着陆页不符合用户的预期，用户极大概率直接关掉。
所以在推送消息和着陆页的设计上，尽量考虑用户的预期效应，不要消息和着陆页文不对题，即便一些商业化运营手法，请不要放在着陆页上，可以考虑放在后续的行为页面上。
1.3 着陆页的设计目的
上面有讲述到，由于着陆页的设计目的不同，设计类型及推送消息均会有不同的展示方式。那么在着陆页的设计上，需要根据目的进行设计。需要记住的是，与用户正常浏览行为不同的是，推送是从应用外部直接进入着陆页的，并且是平台方/第三方发起的行为。不同的用户行径自然与正常浏览的用户产生差异，从推送进来的用户相较于普通浏览的用户来说，耐心（浏览时间）、浏览量以及转化效果都可能与正常浏览的用户不同，所以在着陆页的设计上需要更考虑目的。
（1）若设计目的是实现转化/过程衔接
那么在着陆页的设计上，更突出吸引用户转化的点。最好直接放在第一屏，转化的核心入口请显著突出，减少用户翻找的成本。同时在内容的设计上尽量符合用户需求或者完成过程的衔接。如电商类平台希望实现用户的购买，若该页面为用户需求的商品优惠页，则转化的可行性非常高。若此页面为用户转化过程中的衔接页面，请告诉用户在处于的过程或状态，因为用户不是正常流程走下来的，而是从外部进来的。
（2）若设计目的是增加浏览
从推送进来的用户浏览量从理论上讲是不如正常浏览用户的浏览量。这是因为用户主动和被动产生的差异化效果。当然也不排除推送的内容非常贴合用户需求，并且在着陆页的设计上能引导用户一步步深入浏览。所以目的是增加浏览量的着陆页设计需要考虑的是，用户不是从首页/列表页进来的，根据正常的返回习惯，从哪来就回到哪去，那么用户很可能在浏览完当前页后离开APP。所以在着陆页出口的设计上就需要更加注意，想要增加浏览量就需要更多的页面出口，更需要强化引导浏览的通道。如果你观察天猫的推送你就会发现，它的猜你喜欢推送大多数着陆页中都是放置大量商品入口，给予用户深入继续浏览的入口。减少用户浏览完当前页由于习惯性返回而离开APP。
（2）若设计目的是满足用户需求
若是为了满足用户需求，像是满足用户获取消息的提醒类推送，满足用户获取最新资讯的新闻类推送，满足用户兴趣的文章类推送。这些推送的目的更多在于满足用户需求，那么着陆页的设计应当直接展示需求内容，这类推送会更简单纯粹，因为竞争力在于内容本身，推送只是作为触达用户的途径。
2. 着陆页的用户行为
上面已经介绍过了从推送进来的用户行为可能会与从正常路径进来的用户行为有所差异，所以需要监控该部分的用户行为，若是带有商业化转化目的的，就更需要针对用户着陆后的行为进行监控和分析，从而挖掘和调整转化的关键诱因。此处推荐2种用户行为的数据采集方式：
- 沙漏模型：从用户点击推送进入着陆页到实际转化与正常用户的转化沙漏进行对比
- 喜好度模型：从用户停留、浏览深度、关键交互（收藏、分享、转化）等进行分析对比
第一种方式多运用在活动类的着陆页，根据用户转化效果不断调整页面的设计，力求实现最高的商业化价值。第二种多运用在个性化精准推送，而使用户在点击推送并着陆后的数据表现反过来修正用户画像，这个将在后面的章节进行详细介绍。对比用户行为与设计目的，我们可以与原设计时预定的用户行为路径进行比对分析，不断调整着陆页让其更好的与设计目的一致。
3. 推送消息的存储— 消息中心的设计
在用户浏览完着陆页后，也有可能点击左上角的返回，此时应当返回哪里呢？按理说从哪来就返回哪里，但是推送是从系统通知栏点击进来的，难道返回手机主屏幕？有些APP的做法会返回APP的首页，或者着陆页的入口页面。但是当着陆页是特殊的活动页面，没有常规入口怎么办？或者说用户不小心离开了，再想看刚刚推送着陆页怎么找？这个时候很多APP就会通过消息中心解决消息的存储问题。
3.1 消息中心的作用
消息中心作为推送消息的存储中心，提供了再次造访推送着陆页的机会。不仅如此消息中心还承担了离线消息的作用。若用户并未点开推送消息或清除了推送消息，在其启动APP时，消息中心仍然提供用户访问消息着陆页的机会。许多APP会单独把消息中心放置在重要的tab标签页上，并加上小红点提醒；若用户已经点开推送消息并浏览，不小心离开着陆页或者下次还想浏览，则消息中心提供长期访问着陆页的入口。
对于社交类APP来说，消息中心才是最为主要的聊天列表，推送反倒是次要的，仅仅作为提醒的功能。该类型的APP会把消息中心作为最主要的页面进行放置，既然消息中心这么重要，那么又该如何设计呢？
3.2 消息中心的设计
按照消息中心的作用中描述，消息中心是把推送消息保存下来并提供再次造访的入口，那么消息中心的实现就是把通知直接保存在APP里面吗？其实不是的，下面将为大家介绍消息中心的设计原理。
（1）消息的传送
消息中心的消息传送其实与推送消息为两套消息传送机制。消息中心的消息更类似于离线推送。由于不需要实现用户在关闭APP时的及时提醒（交给推送完成），所以消息中心的消息多为启动APP后进行数据拉取的。虽然是两套数据传输的方式，但是两者又是相互关联的。消息中心需要了解推送消息的内容，读取状态等相关信息，所以推送消息的状态及内容需要反馈给服务器，并展示在消息中心。
（2）消息的存储
消息的存储主要分为两种方式：一种是需要登陆的方式，跟随用户账号迁移，该方式涉及数据同步问题，由于成本过高，使用场景较少。另一种是保存在客户端本地，卸载或迁移后数据均会丢失，大多数APP运用该方式。消息的存储难点在于，每个人的消息是不同的，需要单独存储，这个存储量相对较大，相当于每个人有自己的一套消息中心，因此大多数消息建议存储在客户端，而服务端多负责新消息的传递和消息的读取状态（此处需要与研发多进行探讨，寻求较好的存储和实现方式）。
（3）消息中心的展示
由于消息的类型不同，消息中心呈现方式有很大的差异化。例如电商类网站，由于消息种类不同光消息中心内容页就有很多种的展示方式。如消息列表形式的、如微信公众号形式的、如即时通讯对话框等等。不管消息中心长什么样，其最终解决的问题就是消息的展示和存储。为用户提供消息着陆页的入口。
由于本章主要讲述推送着陆页的设计及进入方式，而消息中心作为着陆页的存储和入口在此进行简单的介绍，关于消息中心如何具体设计与实现，后续有机会再进行详细的介绍，在此就简单介绍其用途即可。
本篇总结
本篇主要为大家介绍了推送着陆页的设计及消息中心的作用和原理，总结下来会是以下几点：
- 根据着陆页设计需求决定着陆页的类型
- 推送消息和着陆页需要给予用户预期一致性
- 推送进入着陆页的用户行为与正常用户浏览有所差异
- 观察用户在着陆页的行为与设计目的的差异，能更好的优化着陆页
- 消息中心承担消息存储和着陆页入口的重要任务
至此基本完成对推送流程的介绍，在流程介绍中有许多不足或者不准确的地方，也期待各位看官能提出修改建议，非常感谢您的支持。下一篇将会是个性化精准推送的开端，介绍如何获取用户行为，分析用户的喜好度，建立用户画像。尽请期待。
（七）推送用户画像建立
通过前六篇文章的介绍，大家应该对推送系统的整体运作流程有清晰的了解。本篇开始将会从数据和运营层面对推送进行更深入的介绍，力求把推送的效果最大化，也和大家一起把推送系统研究到极致。
想要通过推送达成运营目的，首要的是要用户点开推送消息，进到目标页面才有机会实现运营目的。所以推送点击率，成为许多运营者观察的数据指标之一。
用户对推送内容是否感兴趣，很大程度影响着点击率的高低。近年来，各种信息平台/电商网站通过精准推荐、消息聚合和消息分发，声称基于大数据算法实现个性化的推荐，从而达到内容点开率大幅提升。
精准 大数据算法似乎成为当下的潮流，但是对于很多产品经理来说，机器学习、大数据算法听起来就难以实现。
其实个性化推荐并没有想象的那么困难，本篇将会给大家介绍个性化精准推送的第一步：建立用户画像，当然我们主要从推送出发，在推荐算法上不会有太深入的挖掘。
为什么建立用户画像
其实要做精准推送同样可以使用多种推荐算法，例如：基于用户协同推荐、基于内容协同的推荐等其他的推荐方式，但是以上方式多是基于相似进行推荐，运用范围多为单一的功能，难以实现全网功能之间的联动。而构建用户画像，不仅可以满足根据分析用户进行推荐，更可以运用在全网所有功能上。
建立用户画像确实是一个一劳多得的事情，不仅可以运用于精准推送、精准推荐、精准营销，更可以作为网站的用户属性分析，用户行为分析，商业化转化分析等。同时网站共用一套用户画像，可以对用户有统一的认知，更可以在各个运用渠道对数据进行补充和矫正。
大致的理念如下图：
从图上可以看出，用户画像的运用途径非常广，但那些都是应用层面的事情，我们在此主要分析从用户画像构建到实现精准推送的过程。下面开始为大家介绍如何构建网站的用户画像库。
用户画像构建思路
在部分构建用户画像介绍文章中分为四个层级，第四层为预测模型，但在精准推送中较少运用到预测的需求，而且预测算法会是更高阶的算法，需要大量的数据演算，本次不做讨论，所以暂且分为三层进行构建。
从图中可以看到，用户画像的第一层主要是原始数据库，此数据库主要囊括后续分析所需要的所有原始数据。也是通过大量数据的分析和处理，后面能提炼成用户的画像得以运用。
故在这一层的关键词是：大量、数据。而第二层级是根据第一层的原始数据通过算法计算、提炼、规划成可以组成用户画像的一系列通用标签，而这类标签的存在形式类似于矩阵或者多个类别的集合。
在业务需要时，该类标签从数量和维度都可以增加以满足业务需求。所以第二层的关键词是：通用、标签。
而对于第三层，我们可以通过对标签的聚合、提炼、建模等方式构成用户的多个“面”，并运用于多个场景。例如：说小明在听音乐时的画像是摇滚、年轻、流行、活泼；而在学习时的画像是认真、专心、投入、经济学等。
通过用户不同的角度实际运用于各类业务需求，实现精准化。所以在第三层的关键词是：聚合、运用。
建立原始数据库
从第一层的原始数据库搭建开始介绍，这一层我们需要获得尽量多的原始数据，因后面的所有的应用场景都依托于原始数据的计算、分析、建模，所以在原始数据库搭建时需要考虑更全面，当然原始数据与数据存储、采集难度和成本都密切相关。
以下图为主要数据维度，大家根据实际情况进行抉择。
一般来说，例如：电商类网站。对用户的分析更为深入仔细，会需要分析出用户的购买力，所以可能会在用户信息部分下功夫。虽然在用户信息泛滥的今天，依然不提倡大家通过非正常渠道获取用户信息，即便这些数据的商业价值很高。
而第二类数据即用户行为数据是必选项，用户行为数据可以更好的分析用户需求，更容易获取用户的兴趣内容。所以大部分的推荐算法，都会基于用户行为作为原始数据源。而用户环境信息及其他的数据，可以作为数据分析的重要参考资料，这个可视实际情况进行采集和存储。
下面仔细介绍如何采集用户行为数据，采集的目的多用于推算出用户的喜好度以及分析用户的转化行为。通过用户行为推算出用户的标签，实质是利用用户感兴趣的内容赋予标签化的过程。
主要思路如下图：
这个方法的核心思路就是把用户在网站内的每一个操作和操作的对象、操作时间，均记录下来，形成一个用户行为表，这样用户行为的原始数据就构建完成了。
具体操作如下：
把用户浏览/收听/观看的每一个内容、浏览时间、与该内容的交互（点击、滑动）、在该内容的关键指标（收藏、分享、商业化行为等）均记录下来，那么每个用户都会有一个用户行为记录表，而记录的维度可以是数值，可以是“是or否”，也可以是时间，要视具体的需求而定。
如下图：是我在实际设计过程中定义的用户行为数据存储格式，主要反映用户在什么时间看了什么，并做了什么事情。
根据这个表格形成原始数据，当然我前面也说到了，这只是原始数据中行为数据的部分，在设计时可以根据实际情况拓展数据表。
通过记录用户行为的这个原始数据，我们可以获得这些信息：用户的访问习惯（频率、时间、时长）、用户感兴趣的内容、用户对内容的感兴趣程度。
其实光是这些，我们已经大致能推算出用户基本喜好度了。但是这个方法有个缺陷，既用户未产生足够多的行为时，我们无法获取其行为信息，自然也无法进行后续分析。此时就可以运用前面介绍到的通过用户的信息、用户环境等其他数据作为基础，通过用户协同算法，找到与该用户相似的同类用户喜好的内容。
建立用户标签库
根据上面获得的用户行为原始数据，我们得到了一张庞大的行为记录表。但是想要把这个表格的内容运用起来，我们需要把用户行为更为具象化，也就是需要把用户画像构建起来。
构成用户画像可以是一段话描述，可以是各种属性的合集，也是直观解释的标签。根据上面的介绍，用户画像可以运用在用户的分析、商业化模式的分析、精准和个性化推荐系统中。而本篇主要介绍精准推送，故只选取可以具象化展示画像的用户标签。
其实用户标签并不等同于用户画像，只是用户标签是用户画像直观的呈现，并且是比较好且常用的运用方式。
构建用户标签库其实比较简单，因为我们在上述采集用户行为过程中，已经把用户喜好的内容采集下来了，所以基础标签并可以直接运用内容的标签。也就是通过用户喜欢的内容给用户贴标签。
（1）内容标签化
首先要做的事情就是把内容标签化，根据内容定性的制定一系列标签，这些标签可以是描述性标签，也可以是具象的标签，更可以是数字或者数值范围。这些内容的标签需要具有通用性，即适用于你所采集的用户浏览的所有内容。
例如：是电商类网站，则这一些列标签可以是商品类型、商品价格范围、商品产地、商品品牌、商品特点等等。如果是房产类网站，则可以是房子的区域、价格、面积、格局、形态等等。
在完成这一步操作之后，此时用户行为表中的内容均可以标签化了，相当于用户行为表记录的是用户对一组标签的感兴趣程度。
在对内容标签化的时候，需要注意，标签的值需要有统一的范围，不然在后期将无法进行使用和比较。例如说：上图表格中，“区域”这个标签的值范围只能是某个行政区，而每个房源信息都有这个区域值的标签，切勿出现“区域”这个标签值是范围外的内容，如：小区名等情况。
以上图为例，房源ID-1001的标签为：福田区、6万单价、2房、40-50坪、……
（2）用户标签化
第二步要做的就是把内容的标签赋予用户，这个过程就是需要研究用户对内容的喜好程度，用户喜欢的内容即当作用户喜好的标签。
在用户行为记录表中，我们所记下用户的行为在此时就发挥出重要的作用了。用户的浏览（时长/频率）、点击、分享/收藏/关注、其他商业化或关键信息均不同程度的代表的用户对这个内容的喜好程度。
此时我们可以用过给这些行为赋予权重分值，通过分值的计算得出用户喜好的一组标签。按照行为的重要程度赋予分值没有规定的值推荐给大家，大家可以通过不断的尝试和调整，找到最适合自己算法的权重值。同时内容是具有时效性或者与时间的关系比较重要，也是可以把时间作为权重参数之一。以下图是举例说明为行为赋值的过程。
完成对关键行为赋予权重分值后，即可开始计算，首先我们把用户浏览（收听、观看）的内容全部按照上面内容标签化的方式打散成标签，并且把用户行为表中的关键行为转化成对应分值。
这样可以得到下表：
把标签与分值关联进行求和计算，即每个标签的值都可以得到一个分值之和，例如说：商品A的标签“商品产地”的值有“福建、广东、、云南、浙江、河北”等，通过分值计算，找到分值最高的值作为该用户此标签的值。
如：计算出来“福建”的分值最高，即该用户喜欢“商品产地是福建”的商品。
通过以上计算可以实现每个系列标签获得分值最高的值，此时根据自身的需求，可以取最高的值作为标签值，当然也可以从分值从高到低排序，取前几个成为标签数组。通过上面计算，那么一个用户将获得一组/多组标签及对应的值。
如下图：
建立用户画像库
我们通过上述方式获得了用户的一组组标签，但是对用户的剖析并不够立体。用户画像的是个立体标签库的集合，此时就需要我们把标签组构成像矩阵、集合一样立体。再把用户通过各类维度进行组合和排布，形成用户画像。
这是一个用户的画像在数据表中的形态，然而网站千万用户均有自己的画像库，所以在构建用户画像的时候，需要考虑数据存储的问题。这个大量的数据计算将会持续对数据的存和使用造成压力，所以在构建时一定要与研发工程师讨论。
用户画像的横向和纵向都具有拓展性，随着基础数据的获取越来越多，可以拓展的维度也越来越多。同时通过标签的组合、聚合和拓展，可以形成二级标签、三级标签等高阶标签，并运用于不同场景。
下面将为大家举例介绍标签多变的玩法。
应用层的用户标签
来到应用层，我们就可以充分的利用标签发挥各种用途。首先我们可以通过标签筛选出用户，特定的几个标签即可圈定特定范围的用户。
例如说：我可以在用户池中筛选出“年轻、单身、用苹果手机、喜欢xxx”的用户，可以对这类用户进行有针对性的推荐和营销。同时除了圈定用户，我们还可以对标签进行组合。如：标签A=标签a 标签b-标签c。
以上面基础用户画像图中信息举例：首购用户=年龄22~35岁 购房格局为2房 购房单价低于X万-有小孩 ….等等，当然只是举例说明，通过标签之间的组合叠加或排除，可以形成更高阶的标签并运用于各种应用层。
例如：电商网站经常会通过各种信息来判断用户的购买力、喜欢的商品，购物习惯和购物频次。这些都是可以根据基础标签的聚合计算出来的，不同的组合方式让标签更丰富，更贴近实际运用场景，但是也不会干扰原始标签库和用户原始数据的存储和使用。
总结
本篇主要为大家介绍了精准推送的第一步，构建用户画像：
- 构建用户画像可以用于精准推荐、精准推送、精准营销、数据分析等；
- 把用户画像构建分成三层，分别是原始数据库、画像标签库、画像应用层；
- 原始数据的获取可以是用户信息、用户行为、用户环境等相关信息；
- 通过分析用户行为，可以针对用户对内容的喜好度，使用内容给用户标签化；
- 用户画像是可以在横向和纵向进行拓展的庞大标签组；
- 在应用层可以通过标签的组合、聚合、拓展形成各类高级标签并灵活使用。
（八）个性化精准推送的实现
在上一篇，给大家介绍了实现精准推送的第一步：建立用户画像，大家可以回顾看看。完成用户画像的建立后，想要实现精准推送的简单很多。本篇将会给大家介绍一些基础的推荐算法，并以其中基于物品的协同过滤算法为例，详细讲解如何找到用户最感兴趣的内容，从而实现个性化精准推送。文中介绍的推荐算法大部分源自于《推荐系统实践》一书，书中还详细讲述的通过分析用户行为，形成用户标签并构建用户画像的详细过程，大家可以结合书中的要点和本篇实践一起了解。
一. 几种推荐算法
1. 基于内容推荐算法
基于用户感兴趣的物品A，找到和A内容信息相近的物品B
（1）找到物品A的内容信息
（2）找到与内容信息相近的物品B
运用：这种推荐算法多数运用在简单的推荐列表上，当用户看了物品A立刻展示推荐关联的物品B，不需要通过大量计算反馈。但由于其局限性并不能精准推荐出用户所喜欢的内容。
2. 基于用户的协同过滤算法（UserCF）
这种算法给用户推荐和他兴趣相似的其他用户喜欢的物品。
基于用户的协同过滤算法主要包括两个步骤：
（1）找到和目标用户兴趣相似的用户集合。
（2）找到这个集合中的用户喜欢的，且目标用户没有听说过的物品推荐给目标用户。
运用：UserCF的推荐结果着重于反映和用户兴趣相似的小群体的热点，即更社会化，反映了用户所在的小型兴趣群体中物品的热门程度
3. 基于物品的协同过滤算法（ItemCF）
这种算法给用户推荐和他之前喜欢的物品相似的物品。
基于物品的协同过滤算法主要分为两步：
（1）计算物品之间的相似度。
（2）运用：ItemCF的推荐结果着重于维系用户的历史兴趣，即更个性化，反映了用户自己的兴趣传承
4. 隐语义模型算法（LFM）
通过隐含特征联系用户兴趣和物品
LFM是一种基于机器学习的方法，具有比较好的理论基础。这个方法和基于邻域的方法相比有更强的理论基础、离线计算空间、时间的复杂度，并且可以实现在线实时推荐。
5. 其他推荐算法
（1）基于图的推荐算法
其基本思想是将用户行为数据表示为一系列的二元组。基于用户行为二分图，给用户u推荐物品，可以转化为计算用户顶点u和与所有物品顶点i之间的相关性，然后取与用户没有直接边相连的物品，按照相关性的高低生成推荐列表。
（2）基于关联规则的推荐
反映一个事物与其他事物之间的相互依存性和关联性，常用于实体商店或在线电商的推荐系统：通过对顾客的购买记录数据库进行关联规则挖掘，最终目的是发现顾客群体的购买习惯的内在共性。
（3）基于知识推荐
使用用户知识和产品知识, 通过推理什么产品能满足用户需求来产生推荐。这种推荐系统不依赖于用户评分等关于用户偏好的历史数据, 故其不存在冷启动方面的问题。基于知识的推荐系统响应用户的即时需求, 当用户偏好发生变化时不需要任何训练。
二. 选择适合的算法
根据使用场景选择不同的算法，如果是为简单的物品或者商品详情页底部设计推荐功能，即可使用“基于内容推荐算法”，根据当前物品的内容信息推荐相关的物品，当然这个并非是个性化推荐，但确实使用最广的一种推荐方式。若你的网站是做知识培训的，那可以尝试构建基于知识的推荐，这种推荐方式根据用户需求及用户所处知识阶段进行推荐，更贴合所在场景。
而本篇我主要介绍“基于物品的协同过滤算法”，这个算法与“基于用户的协同过滤算法”共同被称为“基于邻域的协同过滤算法”。下面，我们对这类算法进行简单的介绍。
1. 基于邻域的协同过滤算法
从字面上理解“邻域”在数学上指的是“邻域是一个特殊的区间，以点a为中心点任何开区间称为点a的邻域，记作U(a)”，我们可以简单的理解为某个集合点中的左右相邻区间。而“协同过滤”在百度百科上解释为“利用某兴趣相投、拥有共同经验之群体的喜好来推荐用户感兴趣的信息”。那么“基于邻域的协同过滤算法”总结一下就是基于某个维度的相邻区间中利用兴趣相投或共同经验的群体的喜好，找到用户感兴趣的信息。
从某个维度，我们常用用户或者物品所组成的集合区间，所以基于邻域的算法分为两大类，一类是基于用户的协同过滤算法，另一类是基于物品的协同过滤算法。而基于邻域的算法是推荐系统中最基本的算法，该算法不仅在学术界得到了深入研究，而且在业界得到了广泛应用。非常多的个性化推荐算法多使用或混合使用了基于领域的协同过滤算法。可能一些大厂会在这个算法的基础上加入机器学习的理念，克服这个算法本身的缺点。
2. 用户画像与基于邻域的推荐算法
大家一定记得上一篇向大家介绍了用户画像，我们通过用户行为分析，拆解成用户标签，并组合成了用户画像。而利用该用户画像，我们就可以使用基于邻域的推荐算法，因为这个算法最核心的一步就是找到用户的兴趣点。
而我们的用户画像就可以满足这个要求，我们可以通过用户画像计算用户之前的相似度，再推荐另外一个用户感兴趣的内容，这就是“基于用户的协同过滤算法”；我们也可以通过用户画像计算出用户感兴趣的物品相似的物品，这就是“基于物品的协同过滤算法”。
再者我们可以混合一起使用。不管怎么说，我在上一篇就提到了构建用户画像的好处，此时无论选择哪种邻域推荐算法均可使用。而对于我自己，这次选择了选择给大家介绍的是“基于物品的协同过滤算法”。如果对其他算法也有兴趣，强烈推荐大家可以看看《推荐系统实践》一书。
图片引用自《推荐系统实践》 项亮 编著
3. 基于物品的协同过滤算法
基于物品的协同过滤算法是目前业界应用最多的算法。无论是亚马逊网，还是Netflix、Hulu、YouTube，其推荐算法的基础都是该算法。我在前面提到，这个算法主要思路是用户推荐和他之前喜欢的物品相似的物品。在上一篇文章，我们已经把用户之前的浏览行为都记录下来，通过分析和标签化，形成了用户画像。那么其实我们已经完成了第一步，掌握用户之前喜欢的内容。那么第二步即使计算物品相似程度，找到最为相似的物品形成个性化的推荐，再通过推送系统触达用户。下面为大家详细讲解计算的过程：
- 找到用户感兴趣的物品
- 与推荐的物品列表逐个物品进行相似度计算
- 选择相似度最高的物品，并推送给用户
首先如何找到用户感兴趣的物品，在上一篇我们是通过把内容标签化，并把标签赋予用户。那么我们从用户画像中取出一组与推荐物品相关的用户标签。即想给用户推荐商品，那么取出与商品相关的一组用户标签，例如是用户A（茶叶，铁观音，清香，100-200元/斤，产地福建，2018新茶，….）。然后我们在取出待推荐的物品列表，以同样标签化的方式整理，如下图：
然后，我们再计算用户标签与物品标签之间的相似度，找到与用户标签最为相似的物品。此时我们会使用余弦公式进行计算。余弦公式计算的结果会是余弦夹角，夹角越小则相似度越高，通过计算我们就能用余弦夹角来反应相似度关系。
4. 余弦相似公式的运用
向量的余弦相似度公式和我们在三角函数中学的余弦定理有所不同，但我们在数学中计算向量夹角的时候就学习过。当有两个向量a和b时，此时我们计算这两个向量的夹角会使用到“向量的余弦值等于向量的乘积/向量绝对值的乘积”
若把向量拓展到多维度A=（A1，A2，A3，…An），B=（B1，B2，B3，…Bn），此时获得如下余弦相似度公式
把公式运用到我们上述情况中，则用户的标签则是向量A，物品的标签则是向量B。我们可以通过计算余弦值，确定相似度。余弦相似度公式还常常运用于计算文本相似度。将两个文本根据他们词，建立两个向量，计算这两个向量的余弦值，就可以知道两个文本在统计学方法中他们的相似度情况。实践证明，这是一个非常有效的方法。那么下面我们举个例子具体尝试下。假设用户要买房，那么我们可以推荐什么房子给他。
为大家详细讲述下计算方法：
- 列出用户的标签和用于比较物品的标签。
- 列出所有词，即用户标签和物品标签中所有的词，重复/同范围的词只需列一遍，不同的词需要逐个列出。
- 计算词频，即用户标签和物品标签在所有词中出现的次数，若出现则为1次，未出现则为0次。如所有词中“成屋”，在用户标签中出现，则用户的词频为1;在物品中未出现，则物品的词频为0。
- 把用户和物品的词频组成向量A和向量B
- 代入余弦相似公式计算向量A与向量B的夹角，结果即为相似度。
下面我用excel为大家模拟计算上图的结果：
此致我们完成了对一组用户与物品的相似度计算，后续只需要把物品1轮流替换成需要比对的物品即可，完成后得到用户与一组物品的相似度。大家其实算下来有感觉到，余弦相似公式在计算标签的运用上视乎有些“浪费”，因为不管怎么算，用户的词频只会是1和0。所以可以看出余弦相似公式在计算文章内容的相似度或者某些元素非可控集合的相似度中更能突显出其价值。文章中某个关键词出现5次，那么该关键词的词频将会是5，计算结果将会大大的不同。
那么对于我们上面介绍的方法，我们也是可以把词频拿来灵活运用的，因为词频就类似于权重，我们可以通过调整词频来达到提高某个标签的权重。
如上述情况，用户对城市极为敏感，那么我们可以把城市的词频从1提升到2或3。如果是某些必须相同的标签，我们可以在提供匹配的物品列表中先进行筛选。其中可以灵活运用的方式还有很多很多，等待大家的挖掘和探索。
三. 实践中对算法的改造
细心的朋友可能会发现，我这里使用的方法和传统意义上的基于物品的协同过滤算法有所不同，传统基于物品的协同过滤算法不会直接使用用户标签，而是提前维系好物品与相似物品之前的相似度关联。而再用用户行为判断用户对当前物品的喜好度。
也就是说，传统的基于物品协同过滤算法，即便没有用户，物品与推荐的物品就已经有了相似度推荐的关系存在。
这也是ItemCF非常大的缺点之一：如果网站的物品很多，那么计算物品相似度矩阵代价很大。
而我使用的是改造版本，即是把物品赋予用户标签的与物品计算相似度。这样的好处是我不用维系庞大的物品相似度关系表，同时具有更大的灵活性。当用户产生浏览行为后，根据分析用户的标签，再进行相似度计算。
这个时候大家也就会有疑问，如果没有提前准备好物品相似度矩阵。那么用户在第一次进来的时候，或者用户行为不足以分析的时候。我们就无法给用户进行推荐了。确实是的，这也是这个方法存在的缺陷，在推荐系统中称为“冷启动”。
四. 推荐系统冷启动问题
正如我上面描述的情况，用户第一次使用或者用户行为不足的时候，我们无法通过用户行为计算出用户的标签，也讲无法通过基于邻域的协同过滤算法进行推荐/个性化推送。那么此时我们该怎么解决这个问题呢？其实冷启动分为三种，即为用户冷启动，物品冷启动，系统冷启动。我们刚才所描述的问题是用户冷启动，也是最常见的一种。
1. 用户冷启动
若要解决用户冷启动问题，我们只能利用其他方式获得用户的兴趣，暂时替代用户的行为。大家一定记得上一篇我在讲述获取用户画像的原始数据中提到过，我们可以获取用户的信息。那么对于这个问题我们就可以用以下的方法：
- 使用用户信息：例如用户注册信息等
- 使用合适的物品启动用户兴趣：用合适的物品去试探用户兴趣
当以上方式获得的信息再进过算法推荐给用户后，用户只要产生了交互，那么暨产生了用户行为。
2. 物品冷启动
物品冷启动常见的场景是将新的物品推荐给可能对它感兴趣的用户这一问题，新上架的物品或信息如何能快速投递给感兴趣的用户，我们可以通过以下两个方法解决：
- 新上架的物品运用于基于物品过滤协同算法，并提高权重
- 利用物品内容信息，提取内容的关键词（TF-IDF算法），再通过物品推算算法呈现。
3. 系统冷启动
系统冷启动多见于新开发的网站上设计个性化推荐系统，此时物品/内容少，用户少。很多算法无法奏效。那么在这个时候，只能通过专家作用，即通过人工标记的方式制定类别和标签，人工分类，人工制定权重等方式进行。后续用户行为及物品产出后，即可更换替代。
4. 实现个性化精准推算
上述讲了这么多都是如何通过用户画像找到用户感兴趣的内容/物品，那么终于来到精准推送这一步了。用户已经选定好了，用户喜欢的物品/内容也选好了。那么这个时候就可以使用推送系统把内容触达用户了。在这个过程中所需要注意的是以下几个问题：
- 推送系统的用户和用户画像的用户是一致的，即不能算出推送内容却找不到推给谁。这个时候回顾第二篇，使用设备号作为网站对用户的唯一标示就显得更为重要的。
- 选择活跃用户推送，冷启动实现难度较高。所以尽量在用户产生浏览行为后的计算结果推送给用户，这样能避免推送内容不是用户习惯的情况。
- 推送文案可以参考用户标签，既然用户标签是通过用户浏览行为计算出来的。那么用户对标签内容会更为敏感。也许推送文案对勾起用户兴趣帮助更大。
- 推送着陆后的用户行为，也是用户画像用户行为来源之一。用户点击推送消息进到内容页所产生的用户行为也将会作为构建用户画像的行为来源之一。同时用户对推送内容的反馈是可以作为用户喜好度的调节系数之一，这个暂不展开详细说了，大家有兴趣可以去研究看看。
- 推荐的物品/内容尽量是用户没看过的。因为不管使用什么算法计算相似度，很可能出现的结果是用户看过/用户喜欢的内容与用户标签相似度最高。所以进行计算之前，可以考虑把用户过往浏览过的内容/推送过的内容筛掉。
完成以上这些步骤，也就可以基本上实现了个性化的精准推送了，但其实还有很多需要我们去尝试和研究的，例如用户活跃度对协同过滤算法计算的影响，以及用户活跃度对推送的影响。用户的兴趣随着时间的逐步衰减，推送的点击意愿随着用户沉默的时间越来越低；等等….这里就不展开详细说明了，如果大家有兴趣，我们可以再进行详细交流。
本篇总结
本篇主要为大家介绍了如何通过推荐算法，实现个性化的精准推送。总结成以下几点：
- 介绍几种基本的推荐算法：基于内容推荐算法、基于邻域协同过滤算法、隐语义模型算法等等。
- 介绍了用户画像与基于邻域的推荐算法的关系，把上一篇与本篇链接起来。
- 重点介绍了基于的物品协同过滤算法
- 通过余弦相似度公式计算用户标签与物品相似度
- 推荐算法冷启动问题
- 实现个性化精准推送需要注意的问题
作者：番茄那只羊
既然来了，说些什么？