1. 程式人生 > >訊息推送平臺亂象和趨勢

訊息推送平臺亂象和趨勢

最近筆者關注了一下推送這個領域,來給大家說說目前的推送的現狀,我的一些想法以及這個行業的一些趨勢判斷.文章分兩大部分,分別是訊息的使用者打擾以及訊息通道和各推送平臺的趨勢.

訊息的使用者打擾

目前每日全網下發的推送訊息大概是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的推送訊息改變是正向的,只不過產品策略還不夠好.可以更好.

關於各推送平臺的趨勢分析

從手機廠商角度來看,AndroidPush訊息目前是各家建立後臺Service長連線方式來實施的,帶來的問題是手機使用者都在抱怨手機耗電快,偷跑流量等;所以部分手機為了提升自己的產品競爭力,不讓應用自己開長連線做推送(如小米 華為),自己來做系統級的推送,還有一些意識到了這個問題,但是對於這部分廠商來說,沒有自建系統級訊息推送的能力,但是他又想讓自己的手機續航能力強,所以他只能強制殺應用.

目前這部分還沒有想好自建訊息推送對自己的收益的廠商和開發者實際上在玩一個貓和老鼠的遊戲,廠商為了讓自己的手機具備續航能力強,所以他就想殺應用,但是廠商也不能全殺,因為全殺了手機使用者完全收不到通知,體驗也有問題所以這部分廠商做了一些策略(如只能後臺有幾個程序)得到了一個稍微能提升一些續航能力,同時又會影響使用者訊息下達的方式而開發者為了自己的利益(訊息推送是日活和使用者消費時長的關鍵)就在拼命想辦法繞開廠商被殺的策略,同時儘量在存活時展示更多的訊息給使用者,歷史訊息也發出來類似憋久了之後的洪荒之力;

對於廠商來說,自建系統推送訊息通道一定是後面發展的趨勢,只有這樣才能將續航能力提升到最大,同時解決偷跑流量的問題;這條路廠家勢在必行.

當各廠家都決定要有自己的系統推送訊息通道,那麼試問現在的極光,個推,還有BAT等推送平臺以後怎麼辦?是不是可以完全不需要他們了.

有人說一定還需要人做整合,因為廠商那麼多,但是個人以多年網際網路的研發經驗來看,整合各廠家只需要一個開源專案,並不需要一個公司以商務的形式來提供服務,當然若現在做推送業務的公司能夠與廠商合作拿到一些普通開發者拿不到的東西(如詳細的回執報告),可能會有他存在的必要性,但是看起來這個商業模式有點弱不禁風!

對於目前的推送平臺來說有一條路是可以走的,那就是擁抱變化;沒有人能改變趨勢,但是他們可以利用趨勢;現在自己能做好系統級推送訊息的除了華為,小米,沒有二家了,那麼推送平臺可以與其他廠商快速取得合作,成為他們的官方系統渠道;這在目前是行的通的,因為現在OPPO,VIVO,魅族等其他廠商並沒有覺得系統級推送訊息是手機廠商需要乾的事情,但是為了提升續航能力又不得不幹,此時有人能解決他們的困難,讓他們拿到產品續航能力提升的收益,何樂而不為.推送平臺成為官方渠道後繼續做目前的事情,順便解釋一下他們目前所做的事情,目標不僅僅是推送服務,而是資料的應用以及精準廣告的售賣,這才是推送SAAS的正確姿勢.

還有一種方式就是,目前各推送平臺的資料應用和精準廣告已經開始開展,有先天優勢,可以與各廠商談合作留下他們的長連線,一個手機一條長連線鏈路的權利(反正也不會影響他們的業務,因為可以接收訊息和喚起其他app,這樣他們該有的業務還是按原來繼續發展;至於廠商為什麼要給某個平臺留,當然是需要各推送平臺拿一些收益出來分給廠商的,能留哪幾家這些都完全取決於商務合作結果.這個模式個推送平臺的生殺大權全在各大廠商手裡.

推送訊息這個高價值的小業務,即將迎來新一輪的變化,擁抱變化吧。

相關推薦

訊息平臺趨勢

最近筆者關注了一下推送這個領域,來給大家說說目前的推送的現狀,我的一些想法以及這個行業的一些趨勢判斷.文章分兩大部分,分別是訊息的使用者打擾以及訊息通道和各推送平臺的趨勢. 訊息的使用者打擾 目前每日全網下發的推送訊息大概是120億條,這些訊息主要在Android裝置上,平均每個Android使用者每

結合實際需求,在webapi內利用WebSocket建立單向的訊息平臺,讓A頁面服務端建立WebSocket連線,讓其他頁面可以及時給A頁面訊息

1.需求示意圖     2.需求描述 原本是為了給做unity3d客戶端開發的同事提供不定時的訊息推送,比如商城購買道具後服務端將道具資訊推送給客戶端。 本篇文章簡化理解,用“相關部門開展活動,向全市人民徵集社會服務改善意見”為例子。但核心想法一致:單向推送(指這個需求上只需要單向)。所

Android 基於Netty的訊息方案之概念工作原理(二)

上一篇文章中我講述了關於訊息推送的方案以及一個基於Netty實現的一個簡單的Hello World,為了更好的理解Hello World中的程式碼,今天我來講解一下關於Netty中一些概念和工作原理的內容,如果你覺得本篇文章有些枯燥,請先去閱讀《Android 基於Netty的訊息推送方案之Hell

如何構建一套高可用的 APP 訊息平臺

轉載自  如何構建一套高可用的 APP 訊息推送平臺 訊息推送作為移動 APP 運營中的一項關鍵技術,已經被越來越廣泛的運用。本文追溯了推送技術的發展歷史,剖析了其核心原理,並對推送服務的關鍵技術進行深入剖析,圍繞訊息推送時產生的服務不穩定性,訊息丟失、延遲,接入複雜性,統計

如何構建一套高可用的移動訊息平臺

作者:李曉清、董澤光 編輯:小智 訊息推送作為移動 APP 運營中的一項關鍵技術,已經被越來越廣泛的運用。本文追溯了推送技術的發展歷史,剖析了其核心原理,並對推送服務的關鍵技術進行深入剖析,圍繞訊息推送時產生的服務不穩定性,訊息丟失、延遲,接入複雜性,統計缺失等問題,提供了一整套平臺級的高可用訊

常見的訊息平臺

比較常用的訊息推送平臺的調研 個推平臺 個推不僅能提供雲端到客戶端的推送服務,也可以提供從客戶端上傳至雲端的服務,即推送訊息鏈路支援上下行雙向通道,開發者與客戶端之間互動更方便. 多個APP合

Android 基於Netty的訊息方案之字串的接收傳送(三)

在上一篇文章中《Android 基於Netty的訊息推送方案之概念和工作原理(二)》 ,我們介紹過一些關於Netty的概念和工作原理的內容,今天我們先來介紹一個叫做ChannelBuffer的東東。 ChannelBuffer  Netty中的訊息傳遞,都必須以位元

netty 三之訊息心跳檢測

主要參考 https://blog.csdn.net/coder_py/article/details/73441043 有小改動(因使用的是netty4的包 netty-all-4.1.25.Final.jar) 通訊資訊的基類,需要實現序列化,定義了資訊的型別和客戶端ID,方便進行管

談談接入各種第三方平臺的技術方案一點經驗

在移動網際網路時代,為了運營好一個APP,訊息推送是一個優質廉價的渠道。訊息推送的使用場景簡單來說,可以包括運營類的訊息推送,如活動推廣期間的推送等,還包括通知類的訊息推送,如社交場景中的新訊息提醒等。 對於APP來說,訊息推送能夠起到內容告知、提高日活,甚至召回使用者的作用。那麼如何接入第三方推送平臺呢

支付寶支付微信訊息

支付寶支付   如果想在網站上,通過掃碼支付寶收錢,你必須到支付寶網站https://openhome.alipay.com/platform/home.htm申請賬號,但是正式的,需要你提供營業執照,現在沒有,也不要緊,支付寶還提供一個沙箱的測試環境   服務商註冊:業務只是網站上收個錢,註冊一個支付系

如何建立雲平臺聊天系統,如何解決訊息困難問題

聊天業務描述: 使用者1發起聊天,將聊天資訊傳送到伺服器,伺服器將資訊轉發到使用者2 需要解決的問題: 1.如何判斷使用者是否線上(通過使用者滑鼠點選範圍進行判斷,若點選離開頁面則認為使用者的關注點不

php 接極光 普通訊息標題內容訊息實現方法

一、如下兩種訊息樣式推送方法,這裡介紹第一種標題+內容樣式的訊息推送。 1.首先,下載極光PHP的SDK,引入到專案,基礎參考 https://docs.jiguang.cn/jpush/server/sdk/php_sdk/   這裡不詳細介紹了 2.在

SpringCloud工作筆記062---APP訊息_個平臺API使用經驗

前言       移動Push推送是移動網際網路最基礎的需求之一,用於滿足移動互聯環境下訊息到達App客戶端。以轉轉(58趕集旗下真實個人的閒置交易平臺)為例,當買家下單後,我們通過移動Push推送訊息告訴賣家,當賣家已經發貨時,我們通過移動Push訊息告訴買家,讓買賣雙

藉助微信第三方實現訊息提醒

一.前言 近來在負責微信端的專案開發,遇到了一個比較奇特的需求,使用者不想關注本公眾號(可能是怕隱私或者其他等等)但是還想收到推送給的訊息提醒。搜尋良久,最後在同事口中得知微信有專門實現這種功能的公眾號。 二.PushBear 基於微信模板的一對多訊息送達服務 API 就兩個引數  https:/

NSNotificationCenter訊息的學習

NSNotificationCenter基本介紹: 要在程式碼中的兩個不相關的模組中傳遞訊息時,通知機制是非常好的工具。通知機制廣播訊息,當訊息內容豐富而且無需指望接收者一定要關注的話這一招特別有用

APP訊息(APP Push)解決方案-服務端工作邏輯實現

一、APP 推送概述: App推送訊息是我們常見的一種app訊息提醒方式。 我們的實現需要第三方的支援,實現方式是後臺通過介面將Push請求傳送至第三方,第三方實現在App所在裝置上的推送。 二、APP推送後臺處理邏輯: 在與推送平臺互動時,後臺需要向第三方傳送兩部分資訊

Nodejs一個簡單的web頁面訊息服務

前言: 英語能力有限,所以不能叫做純翻譯,大概比例是70%翻譯,20%理解,10%自由發揮 原文: http://www.gianlucaguarini.com/blog/nodejs-and-a-simple-push-notification-server/ 簡述: 用

利用第三方平臺做notify實現訊息

最近可能要做一個訊息推送平臺的建設,app那邊是外包出去的,可能會用到極光推送或者其他的第三方平臺,但是使用者的資料需要持久化儲存,並且也應該對第三方保密。 如果做伺服器端的話要儘可能的考慮高併發和執行效率的問題。 初步規劃如下: 大概流程如下: APP端向訊息平臺

乾貨|現代IM系統中訊息儲存架構的實現

摘要:前言 IM全稱是『Instant Messaging』,中文名是即時通訊。在這個高度資訊化的移動網際網路時代,生活中IM類產品已經成為必備品,比較有名的如釘釘、微信、QQ等以IM為核心功能的產品。當然目前微信已經成長為一個生態型產品,但其核心功能還是IM。 前言 IM全稱是『Instant Mess

springboot整合websocket實現一對一訊息廣播訊息

springboot基礎環境 請參考springboot文件 maven依賴