1、標簽推送 標簽是App運營人員對自己用戶的劃分。比如：有些用戶喜歡看時事政治報道，有些用戶喜歡看娛樂頭條，還有一些用戶只是通過你的視頻客戶端來追某電視劇。對這些人群按照標簽分類后進行推送，很輕松就能達到非常好的效果?！ ”热绺嬖V喜歡看《虎媽貓爸》電視劇的用戶，今天晚上大結局，那么此次推送到用戶手機上的消息是有效的，用戶會因為消息是他們想要的內容而高興地點擊通知并打開App?！ ?、帳號體系推送(alias推送) 每個App都會或多或少的引導用戶去創建賬戶。賬戶體系越完善，App對自己當前用戶就越了解。這樣推送起來也會更加精準，不至于產生騷擾?！ ”热?，《侏羅紀世界》電影的熱播，會引起不少男生對侏羅紀三部曲的懷念，這種情況下可以通過帳號體系選擇20–28年齡段的用戶進行推送消息，告知侏羅紀三部曲合集可觀看，相信這部分篩選出來的用戶的活躍度一定會有大大的提升?！ ?多維度推送 第三方推送平臺往往都會有一些自帶維度，來協助App運營人員進行推送。像友盟推送，基于多年來友盟統計對App數據的積累，提供了如下維度： ?、賾冒姹劲诜职l渠道③地理位置(目前通過IP定位,支持精確到省和直轄市)④用戶活躍度(X天不活躍、X天活躍)⑤機型(包含熱門機型與全部機型)⑥性別(男女)⑦消費力、購買力⑧群組(高富帥、女漢子、窮屌絲等等) 不同的維度可進行組合，取交集或者并集來推送，效果會更佳?！ ?、對沉默用戶的推送 沉默用戶是每個App都很頭疼的一部分用戶，這些用戶下載后玩了一段時間后可能再也沒有開啟過App，如果沒有一個有效的提醒，會有潛在的流失風險。根據這一剛需，友盟推送可以對任意沉默天數的用戶進行推送，從而喚醒他們，且這樣的推送還不會對活躍用戶造成騷擾?！ ?、升級版本的推送 視頻類App整個用戶群體中，零碎版本很多。通過版本的推送，告知用戶有新版本更新，便可以讓更多的用戶主動去升級到最新版本，從而讓用戶享受更好的體驗?！ ∫曨l類 App推送技巧? ? 1、消息標題：簡單而又直觀的標題是吸引用戶的硬性條件 推送通知最好保持在110個字符之內，大概4行文本，并要保證將最重要的細節內容寫在前面。保證消息足夠簡單，讓用戶能夠輕松理解內容。較長的通知內容有可能不能有效傳達信息并且會導致用戶難以集中精神。適當的時候可以發揮一下娛樂精神，來引導用戶。如下圖： 澎湃新聞這條推送簡潔，信息傳遞準確，并能引起用戶的好奇。這樣的推送保證推送不會騷擾到用戶，還會引起一定比例的用戶點擊消息、進而打開App?！ 《缦碌哪承侣効蛻舳送扑偷南⒈泔@得臃腫，用戶需要花時間去理解這條消息。運營人員想法挺好，想短時間內把娛樂消息發給用戶，可過多的點反而會讓用戶閱讀起來不夠順暢?！ ?、消息打開的后續動作 消息推送不僅可以引導用戶打開應用，我們還可以查看用戶打開消息后的行為軌跡，便于了解用戶習慣性使用的功能版塊。友盟推送跟統計自定義事件打通后便可以較好地解決此問題，通過消息推送的后臺可查看比較清晰的軌跡?！ pp運營人員還可以通過消息推送來引導用戶關注新功能模塊，從而有效提高App內各模塊的使用率?！ ?、消息推送維度的使用 分地域推送。某些地域性新聞，如果不足以讓全國各地的人觀看的時候，還是選擇地域性推送比較好，這樣可像“墨跡天氣”一樣，用戶收到的信息一直是與當地的天氣有關，而視頻類應用分地域推送的話，用戶收到的也是當地發生的事情?！ 》智劳扑?。分渠道推送可檢測渠道用戶質量以及該渠道用戶的活躍度。假如某渠道下的沉默用戶過多，那可增加推送次數?！ 尾?。這個主要是針對反饋過BUG的用戶或者某活動中獎用戶，一對一的推送溝通。友盟的消息推送也與自有產品用戶反饋打通，這樣的話會讓App推送能力更加強大，基于強大的友盟推送底層還可以通過單播將推送變成IM?！ 〗M播。這個就是主要把用戶分類推送。選擇不同的用戶標簽，精準到具體人群進行推送。往往App都會有自己的賬號系統，可以把自己的賬號體系導入友盟推送系統，進一步細分用戶畫像。通過賬號體系推送亦可達相對應的效果?！ ?、定時發送 根據友盟統計來看用戶活躍時間段，在用戶比較活躍的時候定時推送,這樣用戶接受度更高?！ ”热?，從友盟統計后臺來觀察，每天用戶的活躍高點集中在下午1點–2點和晚上的19–20點，那么可以選擇這兩個時間段來發送消息?！ 《渌臅r間，便可以選擇拉起沉默用戶?！ ?、過期時間設置 視頻類應用，在推送具有時效性的熱點新聞時，消息過期時間可以設置的短一些，以避免過了新聞時效性后打開App的用戶再收到過時消息。假如對時效性要求不是很高的娛樂新聞，可設置長一點的過期時間。正常我們建議設置消息推送為1天內有效，這樣可以避免用戶在第二天登陸的時候還收到前一天的消息?！ ?、限制發送速度 不少視頻類App在用戶點擊消息的時候，會打開視頻進行播放，這些視頻資源都是存放在App開發者自己的服務器上的。在用戶量比較大或者自身服務器資源比較緊張的時候，建議在一次性推送龐大用戶群體時，選擇限制發送速度，這樣開發者自己服務器受到的壓力會分攤開，避免單點壓力太大造成服務不可用。
