（二）：了解你的用户
搭建推送系统时，会遇到如何选择推送平台，浏览器推送还是APP推送，用户、设备、Token之间的关系，如何标识你的用户等问题，而最终答案只有一个：了解你的用户。

上篇介绍了要以系统的思维来看待推送，没看过的小伙伴可以回顾一下。而本篇就是真正着手开始构建推送系统了。阅读本篇，你能收获：

• 浏览器推送还是APP推送？
• 如何选择推送平台？
• 用户、设备、Token之间的关系？
• 如何标识你的用户？

以上问题都是在开始搭建推送系统时困扰大家的问题，但其实最终的答案只有一个，就是了解你的用户。你的用户决定了你如何构建推送系统。

下面我们开始第一步，选择推送平台：

为了实现消息的传递，搭建推送系统的第一步，就是选择靠谱的推送平台实现消息精准无误的传递到用户的设备上。

作为产品经理的我们，对推送的实现技术也许没有那么深入的了解，此时在做选择的时候，也许就会在网上查找各种资料，尝试各种推送平台。

但其实，你的用户已经决定了你该如何选择。

相信问题的答案非常显而易见，大家应该都会选择APP推送，因为在国内大多数站台其APP用户已经占站台80%以上的用户。

但这里还是要说一下，如果你的用户在浏览器（PC、触屏）有一定比例，也可以尝试进行浏览器推送，让整体推送效果最大化。

以我自己为例，我们站台主要面对台湾市场，而用户在PC和触屏端占比有近60%，因此浏览器推送也在我搭建推送系统的范畴内，并且也取得不错的成效。相信此时大家心中也有答案了，看那个设备端用户占比最多。

网上查资料，各种推送某光、某云、某鸽、某盟、某米等，还有推送自己建立推送平台。到底该如何选择推送服务呢？其实还是很简单，由你的用户决定了选择哪个推送平台。

(1).系统级服务与应用级服务

1).系统级服务

• IOS：APNs，IOS系统服务简单而有效，必定走向系统级服务APNs。所以IOS系统不需要选择。
• Android：FCM/GCM，此为google官方的系统级推送服务，Chrome浏览器同样适用。不过必须依托于google服务。
• 其他：如小米手机的小米推送服务、华为手机的华为推送服务。

2).应用级服务

简单来说就是第三方服务商提供应用来解决推送问题。需要注意的是，若选择小米推送在非小米的手机上也会属于应用级服务。

应用级和系统级服务有什么差别呢？一句话概括就是：应用级的服务会被*死，而系统不会*死自己品牌的推送服务。

所以尽量选择系统级服务，但是大多数情况下，用户的设备不会这么高度一致，而国内google服务行不通。在这种情况下就不得不使用应用级服务，也就是选择第三方平台进行推送。

(2).第三方平台的选择

当用户群体广泛，设备类型较多且无法使用系统级推送服务时，只能考虑选择第三方平台，此时选择第三方平台则有一个简单的原理：第三方推送系统会共享一条推送链路。

也就是说选择一个服务于多款APP的第三方平台，越多越好。因为你会和软件A、B、C、D、E、…共享一条推送链路，若推送服务被*掉后，可以通过其中一款软件来重新唤起链接。这样能减少你的推送服务被*死的可能性，最大程度保证消息到达。

简单总结一下：

1. 若用户主要在海外、港澳台地区，确认大部分用户都使用google服务，则建议使用FCM系统级推送。
2. 若用户绝大多数是小米、华为手机，则可以考虑小米、华为内置的系统级推送服务。
3. 若用户设备分布较为平均，没有特别集中的设备品牌，则可以选择服务规模较高的国内第三方服务。
4. 若用户信息敏感，不希望信息经过第三方平台，则可以选择自建推送系统。但需要与手机厂商进行定制化合作，成本较高。

在完成推送平台的选择之后，我们要做的下一步就是要选择给谁进行推送。一些产品经理会认为，我只要在推送后台录入一串要发送的token就行了，真的是这样吗？

我常常会把用户、设备和Token之间的关系比喻成：人、电话、电话号码的关系。

认清楚他们三者的关系非常关键，很多产品经理经常会把Token数量当成了用户数量，这会导致推送的成效越来越差。

用户：就是你的目标用户，也就是你的站台使用者的人数，他们就是活生生的人。

设备：一个人有多个设备，就像一个人可能有多个电话。

因此用户与设备的关系是一对多的关系。

Token：用户的客户端在推送服务上注册的令牌，简单理解就是用来标识这个客户端的。对推送平台来说，就是根据Token来知道你要把消息发给哪个用户的客户端。类似于我知道你的电话号码，我就可以打电话给你。

但是需要注意，电话号码可能会被遗弃、更换，而且不同电信服务提供商的电话号码都是不同的，Token同样存在这种特性。

(1).为什么要选择唯一标识？

你知道每次推送到底发送给多少用户吗？多少用户收到了，多少用户点击了？其中多少的真实有效的用户呢？想要掌握这一系列数据，必须建立一个用户的唯一标识。使用这个唯一标识，你可以了解：

• 用户有效性，唯一标识能帮你辨别出有效的用户。
• 具体到个人，便于跟踪用户后续一系列数据表现。
• 整个网站对同一个用户有同样的标识，实现数据共享。

(2).唯一标识的特性

既然上述唯一标识的主要功能是帮助筛出有效的用户，具体个人，并且能作为全网站对用户的认知。那么唯一标识需要具备以下2个特点：

1. 唯一：每个设备的设备号必须是不同的，才能作为唯一标识，就像身份证号。
2. 不变：标识不能发生改变，不然就无法标识某个用户了。

那么根据这“唯一”、“不变”这两个特点，选择什么来作为唯一标识呢？

(3).使用什么作为唯一标识？

1).选择用户作为唯一标识：

若你的网站必须登录才可以使用且用户ID不会发生改变，那么可以把用户ID作为唯一标识，因为用户ID是最贴近真实用户的数量。但是前提要保证每个设备必须登录用户ID。例如聊天软件，即时推送消息是跟随账号进行区分的。

但是很多情况非常多的APP是不需要登陆即可使用的，此时无法使用会员账号来标识每个用户。

2).选择Token作为唯一标识：

该方法是行不通的，同时非常多的产品经理会踩这个坑（包括我以前）。如果把Token作为唯一标识，你就会发现越推送，效果越差。因为你已经无法把无效用户和有效用户区分开来了，当Token失效的时候，你会以为该用户也失效了。

3).使用设备号作为唯一标识：

强烈推荐，因为设备号存在两种特性：只要硬件不变，设备号一般是不会变化；设备号一般不会出现重复的情况，适合作为唯一标识。

同时大多数时候，特别对于APP来说，我们会使用设备数/活跃用户数来作为APP用户数的衡量标准。

但是该方法也有3个缺点：

• 即时通讯类的推送不适合，多数即时通讯使用会员账号来区分消息。
• 与网站真实用户数有一定差距，一个真实用户可能会有多个设备，因此会存在一定差别。
• 浏览器端的设备号由于技术原因会与真实用户数存在一定误差。

但纵观以上三种方式，设备号是最适合一般类型的应用作为唯一标识。