消息推送平台乱象和趋势

最近笔者关注了一下推送这个领域,来给大家说说目前的推送的现状,我的一些想法以及这个行业的一些趋势判断.文章分两大部分,分别是消息的用户打扰以及消息通道和各推送平台的趋势.

消息的用户打扰

目前每日全网下发的推送消息大概是120亿条,这些消息主要在Android设备上,平均每个Android用户每天会收到30条以上的消息, 为什么呢,主要是因为Android手机生态的原因,关闭消息太难. 所以Android设备的用户每天生活在消息的轰炸之中,从业内的一些数据来看,现在Android的一条推送,从展示到点击的转化,已经不足5%了,绝大部分的消息都是无用的,打扰用户的。

为什么要推那么多消息,甚至一个APP每天需要推好几条消息呢,从业内的一些运营人员了解到,因为现在各家推的消息都多,所以我们也必须跟上,不跟上用户的屏幕就被霸屏了,显示不到我们app的推送内容,所以每隔几个小时我们得发一个,冒个泡抢个楼露个脸,是这么个味道.

还有一个奇特的情况是,美国总统当选,一天一个用户就收到了好几十条总统选举消息,第二天还有好几十条是那些运营团队跟进不及时的Apps发的,绝大部分用户的已然被强打扰.但是还是有那么多用户不知道怎么关. 或者痛苦着并不思如何解决(用户很懒)

这就是当前的现状:消息很多,转换很低,有用的消息很少且被埋没

下面来谈下我的观点:

针对问题消息多,大家都知道一个道理,就无利不起早,所以大家会发一定是有利可图,即便现在一条消息被用户打开的转换率已经足够低了,但是有总比没有好,另外还惦记着冒个泡抢个楼露个脸;所以你看,消息就这么多起来的。核心是有利可图. 类似投入产出比,得到的收益与失去的东西做权衡是正向的。

那推送难道真的就没有成本吗?不然,推送了消息后打扰了用户,用户的关闭和卸载行为其实就是一条推送的成本,或者叫负影响, 市面上有两类公司,一类是算过投入产出比的,成本和产出是正向有收益的,也就是推送消息获得的收益 大于 推送消息带来的关闭和卸载负影响,所以在坚持干坚持发,绝大部分95%以上的公司是没有算过的,在陷入上面的跟风抢位且不停循环中。

所以对于手机厂商来说,要优化消息的体验,势必要提升成本,也就是让更多的打扰用户的场景变成不是正向的,不能得利,那么用户被打扰的频度就降下去了.

具体怎么操作呢?假设我是手机产品的设计者,我会从以下三个维度考虑:

  1. 让用户更加容易关闭和拒绝消息
  2. 消息根据具体某个用户转换率的排序,以及自动策略关闭
  3. 收费

三个纬度都在提升APP的发一条消息的成本

  1. 现在消息那么多,把决定权交给用户,让用户可以快速便捷的关闭某个APP的消息,例如在消息展示时下方有小按钮关闭此APP推送,或者类似苹果左滑的体验,后面出关闭此APP推送按钮。这样推一些不是那么有用的消息的时候,用户反感能快速关闭,app推送的损失是很难再触达这个用户了.
  2. 手机展示消息根据具体某个用户转换率的排序,以及自动策略折叠或关闭;例如对A用户来说,新浪微博推的消息点击转换效果好,头条推的消息对此用户转换效果差,那么新浪微博的消息排在前面;若头条的效果在此用户所有的Apps中比较差而且还经常推消息,那么策略性的折叠消息甚至是自动帮用户关闭此app的推送;这样能够激励apps去发那些对用户真正有帮助的消息,而不是以量取胜. 同时对于Apps来说,一条消息该不该发,需要更加谨慎的考虑了,还拿总统选举的例子,获得消息晚,该不该发可能就得掂量掂量了.
  3. 按发送数量收费,类似运营商短信的玩法,此处不展开讨论,得罪万千开发者,我想说的是这个模式也不是不可能,因为国内一台手机利润才100左右,他也没法cover自建消息通道的成本;且此路是我开,要从此路过,留下买路钱,很合理,没毛病.

从产品角度考虑,哪一个手机做到前两者,那么相对他的消息体验就能好起来了. 从手机厂商的角度他愿意在自己的推送产品上这样做吗?当然愿意,因为这关乎他手机体验的核心竞争力. 类似目前OPPO R9S手机的做法,极度反对消息推送,几乎不主动打开就没有消息推送,这类太极端,甚至作为用户,损失了消息获取权,但是从使用者的感触上来说,的确比不停的接受垃圾消息要好,所以Oppo的推送消息改变是正向的,只不过产品策略还不够好.可以更好.

关于各推送平台的趋势分析

从手机厂商角度来看,Android的Push消息目前是各家建立后台Service长连接方式来实施的,带来的问题是手机用户都在抱怨手机耗电快,偷跑流量等;所以部分手机为了提升自己的产品竞争力,不让应用自己开长连接做推送(如小米 华为),自己来做系统级的推送,还有一些意识到了这个问题,但是对于这部分厂商来说,没有自建系统级消息推送的能力,但是他又想让自己的手机续航能力强,所以他只能强制杀应用.

目前这部分还没有想好自建消息推送对自己的收益的厂商和开发者实际上在玩一个猫和老鼠的游戏,厂商为了让自己的手机具备续航能力强,所以他就想杀应用,但是厂商也不能全杀,因为全杀了手机用户完全收不到通知,体验也有问题; 所以这部分厂商做了一些策略(如只能后台有几个进程)得到了一个稍微能提升一些续航能力,同时又会影响用户消息下达的方式; 而开发者为了自己的利益(消息推送是日活和用户消费时长的关键)就在拼命想办法绕开厂商被杀的策略,同时尽量在存活时展示更多的消息给用户,历史消息也发出来, 类似憋久了之后的洪荒之力;

对于厂商来说,自建系统推送消息通道一定是后面发展的趋势,只有这样才能将续航能力提升到最大,同时解决偷跑流量的问题;这条路厂家势在必行

当各厂家都决定要有自己的系统推送消息通道,那么试问现在的极光,个推,还有BAT等推送平台以后怎么办?是不是可以完全不需要他们了.

有人说一定还需要人做集成,因为厂商那么多,但是个人以多年互联网的研发经验来看,集成各厂家只需要一个开源项目,并不需要一个公司以商务的形式来提供服务,当然若现在做推送业务的公司能够与厂商合作拿到一些普通开发者拿不到的东西(如详细的回执报告),可能会有他存在的必要性,但是看起来这个商业模式有点弱不禁风!

对于目前的推送平台来说有一条路是可以走的,那就是拥抱变化;没有人能改变趋势,但是他们可以利用趋势;现在自己能做好系统级推送消息的除了华为,小米,没有二家了,那么推送平台可以与其他厂商快速取得合作,成为他们的官方系统渠道;这在目前是行的通的,因为现在OPPO,VIVO,魅族等其他厂商并没有觉得系统级推送消息是手机厂商需要干的事情,但是为了提升续航能力又不得不干,此时有人能解决他们的困难,让他们拿到产品续航能力提升的收益,何乐而不为.推送平台成为官方渠道后继续做目前的事情,顺便解释一下他们目前所做的事情,目标不仅仅是推送服务,而是数据的应用以及精准广告的售卖,这才是推送SAAS的正确姿势.

还有一种方式就是,目前各推送平台的数据应用和精准广告已经开始开展,有先天优势,可以与各厂商谈合作留下他们的长连接,一个手机一条长连接链路的权利(反正也不会影响他们的业务,因为可以接收消息和唤起其他app),这样他们该有的业务还是按原来继续发展;至于厂商为什么要给某个平台留,当然是需要各推送平台拿一些收益出来分给厂商的,能留哪几家这些都完全取决于商务合作结果.这个模式个推送平台的生杀大权全在各大厂商手里.

推送消息这个高价值的小业务,即将迎来新一轮的变化,拥抱变化吧。

时间: 2024-10-13 07:03:10

消息推送平台乱象和趋势的相关文章

消息推送平台高可用实践(上)

本文来自网易云社区 作者:李弈远 消息推送平台为公司内部和第三方应用提供统一消息推送服务,支持广播.私信.组播.附件等多种消息推送方式,覆盖IOS.Android.PC.Web等多种终端,并根据应用特定需求制定各种解决方案. 平台支持水平扩展,支持C5000K高并发下的实时消息推送,通过动态负载均衡.隔离部署.LXC虚拟化和监控报警等多种机制确保系统 的高可用,通过高可用消息队列.自动重连和ACK等机制实现消息可靠性(QoS1),并提供SDK方便产品和应用接入. 本文将在介绍消息推送服务相关功能

Android消息推送:手把手教你集成小米推送

前言 在Android开发中,消息推送功能的使用非常常见. 为了降低开发成本,使用第三方推送是现今较为流行的解决方案. 今天,我将手把手教大家如何在你的应用里集成小米推送 该文档基于小米推送官方Demo,并给出简易推送Demo 看该文档前,请先阅读我写的另外两篇文章: 史上最全解析Android消息推送解决方案 Android推送:第三方消息推送平台详细解析 目录 1. 官方Demo解析 首先,我们先对小米官方的推送Demo进行解析. 请先到官网下载官方Demo和SDK说明文档 1.1 Demo

iOS 细说消息推送

经常有同学问我们,iOS上推送究竟怎么做啊,为什么我的设备总收不到推送呢,这里跟大家集中讨论一下iOS上推送的实现细节. APNS的推送机制 与Android上我们自己实现的推送服务不一样,Apple对设备的控制非常严格,消息推送的流程必须要经过APNs: 这里 Provider 是指某个应用的Developer,当然如果开发者使用AVOS Cloud的服务,把发送消息的请求委托给我们,那么这里的Provider就是AVOS Cloud的推送服务程序了.上图可以分为三步: 第一步:AVOS Cl

魔推MPUSH开发者程凯征:好的消息推送技术是磨出来的

开发一款程序员喜欢用的SDK不容易.也许有些开发者还不知道能够使用方便易用的消息推送平台接口服务.但是像百度.网龙.去哪儿等APP应用都是在使用消息平台接口的服务.魔推MPUSH开发者程凯征以一位标准研发人员的视角,将研发和产品设计之间的关系用"与.或.非"来阐述他对消息推送技术是如何诞生的. 目前,魔推MPUSH已经向应用开发者开放,支持包括安卓.IOS.JAVA.PHP的主流系统.从原理上来说,为应用开发者提供的SDK包嵌入到应用程序当中,就可以实现信息的推送功能.目前,广泛的做法

细说 iOS 消息推送

APNS的推送机制 与Android上我们自己实现的推送服务不一样,Apple对设备的控制很严格.消息推送的流程必需要经过APNs: 这里 Provider 是指某个应用的Developer,当然假设开发人员使用AVOS Cloud的服务,把发送消息的请求托付给我们,那么这里的Provider就是AVOS Cloud的推送服务程序了. 上图能够分为三步: 第一步:AVOS Cloud推送服务程序把要发送的消息.目的设备的唯一标识打包,发给APNs. 第二步:APNs在自身的已注冊Push服务的应

技术大佬告诉你:创业型APP如何选择推送平台

对于中小型APP开发团队,特别是创业型的APP开发者来说,选择一款小巧.适时而又能够精准消息推送SDK是一件很麻烦的事儿,相同的内容推送给所有终端用户,担心打扰用户.引起用户方案:而个性化的分类精准推送,又因为自身团队人少,运营负担很大不足以实现.那开发者怎么办? 目前,消息推送服务平台中普遍增加了用户筛选的功能,如个推.极光和刚刚面向开发者放了用户筛选功能的魔推等push服务都加入了精准用户筛选的功能和分类.应该说这几款消息推送服务都能显著的提高APP的用户活跃度,对次日的日活跃度也有积极的影

设计一个百万级的消息推送系统

原文链接:https://crossoverjie.top/2018/09/25/netty/million-sms-push/ 前言 首先迟到的祝大家中秋快乐. 最近一周多没有更新了.其实我一直想憋一个大招,分享一些大家感兴趣的干货. 鉴于最近我个人的工作内容,于是利用这三天小长假憋了一个出来(其实是玩了两天??). 先简单说下本次的主题,由于我最近做的是物联网相关的开发工作,其中就不免会遇到和设备的交互. 最主要的工作就是要有一个系统来支持设备的接入.向设备推送消息:同时还得满足大量设备接入

如何使用Netty技术设计一个百万级的消息推送系统 原 荐

先简单说下本次的主题,由于我最近做的是物联网相关的开发工作,其中就不免会遇到和设备的交互. 最主要的工作就是要有一个系统来支持设备的接入.向设备推送消息:同时还得满足大量设备接入的需求. 所以本次分享的内容不但可以满足物联网领域同时还支持以下场景: 基于 WEB 的聊天系统(点对点.群聊). WEB 应用中需求服务端推送的场景. 基于 SDK 的消息推送平台. 技术选型要满足大量的连接数.同时支持双全工通信,并且性能也得有保障. 在 Java 技术栈中进行选型首先自然是排除掉了传统 IO. 那就

一篇文章教你如何设计一个百万级的消息推送系统

前言 先简单说下本次的主题,由于我最近做的是物联网相关的开发工作,其中就不免会遇到和设备的交互. 最主要的工作就是要有一个系统来支持设备的接入.向设备推送消息:同时还得满足大量设备接入的需求. 所以本次分享的内容不但可以满足物联网领域同时还支持以下场景: 基于 WEB 的聊天系统(点对点.群聊). WEB 应用中需求服务端推送的场景. 基于 SDK 的消息推送平台. 技术选型 要满足大量的连接数.同时支持双全工通信,并且性能也得有保障. 在 Java 技术栈中进行选型首先自然是排除掉了传统 IO