⑴ 友盟推送服務如何統計App卸載
首先需要澄清一點的是，友盟統計分析服務不會統計，也不能統計設備上App卸載的信息的，友盟統計分析服務只會針對集成友盟統計分析SDK的App提供類似新增、日活、留存等基本指標，或者是開發者自定義的一些統計信息，如自定義事件等。
統計卸載信息其實是在友盟推送SDK裡面做的，並且當前統計到的卸載信息也已經部分應用在了消息推送服務裡面。接下來就提問者感興趣的如何統計卸載設備，以及我們目前如何使用這部分卸載信息簡單給大家講一講，太細節的東東就不便透露了。當然，我們的卸載只是針對android平台來做的，iOS上由於蘋果的限制，卸載統計從技術上是很難實現的。
先來說說友盟推送是如何統計卸載:
如果一個設備上有多個集成友盟推送SDK的App的話（注意，必須是集成了友盟推送SDK的App），我們把這些個App稱為一個群組或者聯盟，同一個群組內的App在推送的通道上是做了很多互保和優化工作的，比如長連接通道就是在這多個App之間共享的。
同一個群組裡面的App，如果有某個App發生卸載行為的話，那麼這個卸載事件就可以被群組里其它沒有卸載的App所知曉，該卸載事件就可以上報給伺服器端，伺服器端就可以知道哪台設備上哪個App被卸載了。同一個群組內的App之間互相檢測卸載是一種常用的手段，但是這個要依賴於設備上集成友盟推送SDK的App有很多個，形成一個群組，如果只有1個App集成了友盟推送的話，那麼這種手段是無法捕獲到卸載的。 群組內的App越多，卸載統計收集的效果越好。
寫到這里，肯定有一部分開發者要問，如果設備上只有1個集成友盟推送SDK的App的話，那麼如何統計到這個App是否被卸載了呢？ 這種情況下，我們只能判斷到一部分卸載的情況，外加一些其它的輔助判斷信息。
那麼哪部分可以統計到呢？ 其實還是要依賴於App群組了，假設之前這個設備上只有App A集成了友盟推送，並且A被卸載了，假設後續又安裝了集成友盟推送SDK的App B，那麼如果給App A發消息，消息送達設備後(因為App B在，所以消息走的是B建立長連通道), 會嘗試投遞給App A，因為A已經被卸載了，所以投遞是不成功的，App B就能感知到這一事件，因此也可以把該卸載信息上報回友盟伺服器，伺服器也就知道該設備上A App已經被卸載了，其實還是要依賴於設備上的App群組功能。
如果該台設備上後續一直沒能有集成友盟推送SDK的App被安裝，那麼我們只能通過粗糙的看多少天不活躍，比如180天不活躍的App，我們認為這台設備上App已經被卸載了（有一定的偏差，比如某些工具類App，有可能打開頻率就非常低），這個不一定準確，但是根據活躍度做用戶分層多少也能看出來App的健康度。
接下來再談談為什麼推送服務要收集設備上App的卸載信息的:
這個其實是和推送的一個硬指標「送達率」戚戚相關的，對於卸載的App，消息肯定是下發不了的，所以在評估送達率的時候，得把這部分卸載的量踢掉，否則在評估和計算送達率的時候，會導致送達率的下降或者不準確。
舉個簡單地例子，假設某個App有100W的裝機量，過了一段時間有20W的卸載（根據我們的觀察，20%的卸載率就算平均水平了），那麼一次發送任務加入送達了40W的App，那麼最終的送達率應該是 40W/(100W-20W) = 50%, 而不是 40W/100W = 40%。 卸載設備的統計越准確，對於最終送達率的評估效果越好。
最後我們來說說卸載統計在友盟推送服務中的應用:
首先在每次推送任務的時候，對於提交過來的device-token，我們會做一次清理，把卸載設備清理掉，所以有時候App開發者或者App運營人員會發現，他們提交的發送總數和友盟後台顯示的當次發送數對不上，那就是因為友盟後台已經剔除掉了當次發送任務中的卸載設備了。
其次，當前的卸載統計我們還在進一步的分析和評估中，如果我們收集到的卸載設備數量足夠准確，足夠全面的時候，我們會把這個功能開放出來，放到統計分析系統裡面供App開發者和運營人員來做參考。
⑵ 友盟推送android java端的代碼怎麼使用
最好的方法，研讀官方提供的Demo，這里說的Java端應該是前端，即Android App端，在應用程序啟動的時候，開啟推送功能，同時在清單文件移植Demo提供的一些內容，測試幾遍就差不多了。。。
⑶ 友盟-推送-Andorid-消息推送-打開通知消息進入特定Activity操作
要獲取參數的話 只能通過自定義打開行為，重寫dealWithCustomAction
在消息推送SDK里，有一個類UmengNotificationClickHandler，負責處理消息的點擊事件。 該類主要有四個成員方法：
public void launchApp(Context context, UMessage msg);
public void openUrl(Context context, UMessage msg);
public void openActivity(Context context, UMessage msg);
public void dealWithCustomAction(Context context, UMessage msg);
這四個方法，分別對應於四種打開方式。其中，launchApp、openUrl、openActivity這三個方法已經由消息推送SDK完成，而dealWithCustomAction則只是一個空的方法。 若開發者需要處理自定義行為，則可以重寫方法dealWithCustomAction();其中自定義行為的內容，存放在UMessage.custom中。下面是處理自定義行為的代碼：
/**
* 該Handler是在BroadcastReceiver中被調用，故
* 如果需啟動Activity，需添加Intent.FLAG_ACTIVITY_NEW_TASK
* */
UmengNotificationClickHandler notificationClickHandler = new UmengNotificationClickHandler(){
@Override
public void dealWithCustomAction(Context context, UMessage msg) {
Toast.makeText(context, msg.custom, Toast.LENGTH_LONG).show();
}
};
mPushAgent.setNotificationClickHandler(notificationClickHandler);
注意
以上代碼需在 Application 的onCreate() 中調用使用以下介面，而不是在Activity 中調用。如果在Activity中調用此介面，若應用進程關閉， 則設置的介面會無效。 請參考demo 應用代碼。
該Handler是在BroadcastReceiver中被調用。因此若需啟動Activity，需為Intent添加Flag：Intent.FLAG_ACTIVITY_NEW_TASK，否則無法啟動Activity。
若開發者想自己處理打開網頁、打開APP、打開Activity，可重寫相應的函數來實現。
⑷ Android友盟推送集成
友盟官方文檔： https://developer.umeng.com/docs/67966/detail/153908
第一次認真集成推送，碰到了一些問題，記錄一下。
首先講一下實現原理，我們用的是友盟。Android比iOS要麻煩很多。
友盟集成是需要後端配合的，具體就是後端調用友盟的介面，向友盟推送一條消息，然後友盟再向在他們平台注冊過的app發送一條消息，我們要做的就是把接收到的消息展示出來。
需求：用戶要能在各個時候都能收到我們APP的推送，並且能對應打開不同的界面
解決方法：集成友盟，但是Android只簡單集成友盟是不行的，在APP被殺死以後，就接收不到通知了，所以需要額外集成廠商通道。另一個和iOS不一樣的就是，iOS在打開當前APP的時候，可以收到橫幅推送，但是Android需要自己做。
什麼是廠商通道：
由於國內手機廠商過多地使用應用保活方案實現消息推送功能，因此導致手機耗電加快、卡頓。國內部分手機廠商發現了這一問題，自己推出了消息推送服務。這些手機廠商通過進程管理，殺死後台進程，並提供消息推送能力，讓消息通過手機廠商官方推送通道下發到應用程序中。這類典型的手機廠商有小米、華為等。
大致分為兩部分：
正常推送集成。
五大廠商通道集成。
詳見友盟官方文檔： https://developer.umeng.com/docs/67966/detail/153908
點擊推送信息以後的處理，收到推送的時候的回調
UmengNotificationClickHandler notificationClickHandler =new UmengNotificationClickHandler() {
@Override
public void dealWithCustomAction(Context context, UMessage msg) {
//點擊推送通知以後的處理
Log.i(TAG,"notificationClickHandler "+msg);
}
};
UmengMessageHandler messageHandler =new UmengMessageHandler() {
@Override
public void dealWithCustomMessage(final Context context, final UMessage msg) {
Log.i(TAG,"message "+msg);
}
@Override
public NotificationgetNotification(Context context, UMessage uMessage) {
//手機收到推送的時候的回調
Log.i(TAG,"message ");
//返回默認構造
return super.getNotification(context, uMessage);
}
};
mPushAgent.setNotificationClickHandler(notificationClickHandler);
mPushAgent.setMessageHandler(messageHandler);
設置最多能看到的推送條數
mPushAgent.setDisplayNotificationNumber(3);
如果需求中需要打開APP中某個界面，責需要觀察 "after_open"欄位，默認是 "go_app",需要服務端同學配合
{
"msg_id": "uu481201399440513912",
"display_type": "notification",
"alias": "",
"random_min": 0,
"body": {
"title": "測試自定義參數",
"ticker": "測試自定義參數",
"text": "無",
"after_open": "go_app",
"url": "",
"activity": "",
"custom": "",
"play_vibrate": "true",
"play_sound": "true",
"play_lights": "true"
},
"extra": {
"key1": "value1",
"key2": "value2"
}
}
成功以後可以看log
主要看after_open，默認是打開app
友盟官方常見問題： https://developer.umeng.com/docs/67966/cate/66637
1.集成以後收不到推送
(1) mPushAgent.register（）要放在application中調用，放在別的地方不起作用
(2) 檢查so文件有沒有放錯地方
(3) 打開日誌提示，仔細看提示:UMConfigure.setLogEnabled(true)
2.java.lang.ClassNotFoundException: com.ut.mini.UTAnalytics
盡量更新到最新版本的引用，友盟開發說這個只是提示，不用太在意....
3.殺死進程以後收不到推送
解決方法：集成各個廠商通道
iOS的小夥伴集成以後，就算殺死APP也可以收到推送，為啥Android不可以，傷感，看了文檔才知道，我們要集成廠商通道，
4.集成以後收不到推送，顯示送達卻沒有彈出通知
manifest裡面的package最好與build.gradle中的applicationId不一 致， 因為我們項目有兩個applicationId，所以會出現這種情況
需調用setResourcePackageName設置資源文件包名
⑸ 友盟-推送-Andorid-「標簽(tag)」是什麼，如何使用自定義標簽
友盟推送支持的篩選維度有「版本」、「渠道」、「地域」、「用戶活躍度」等，還有一個叫做「標簽」，「標簽」是什麼含義呢？該如何使用呢？ 今天我們和大家聊聊這個話題。
先解釋下什麼是「標簽」:
提問者問到的「標簽」其實指的是App開發者結合自有的業務邏輯對該App的終端用戶打的「標簽」，我們也稱tag，這些「標簽」是App自己的標簽（舉個簡單的例子，App根據終端用戶是否注冊，可以給用戶打上「注冊賬號」和「未注冊賬號」的標簽），第三方開發平台是無法直接提供這樣的標簽的(但是可以開放打標簽介面，讓App開發者把標簽數據回傳到第三方伺服器上)，因為具體的業務邏輯是在App這邊的。 第三方開放平台能提供的維度也僅是在用戶協議范圍內可以收集的欄位，比如「版本」、「渠道」、「機型」、「操作系統」等信息，這些維度可以認為是靜態的維度，其實App開發者自己也可以收集這些欄位，只不過交給第三方平台來做數據收集、存儲和計算更為方便，有興趣的讀者可以了解一下友盟推送收集的用戶協議欄位: 友盟 | 隱私政策。
下面我們給大家提供一些有代表性的垂直領域App結合自有業務邏輯給終端用戶打標簽的思路，希望對大家有幫助:
體育類App可以根據終端用戶看過的節目類型，給終端用戶打上「足球」、「籃球」等類目標簽。
兒童類App可以根據兒童的年齡分布，給終端用戶打上「0~1歲」、「1~3」歲、「3~5」歲之類的年齡結構標簽。
電商類App可以根據用戶的購買習慣推算出用戶性別，給終端用戶打上「男」、「女」標簽。
餐飲類App可以根據用戶的下單記錄以及點評，給終端用戶打上「川菜」、「粵菜」、「韓國料理」等標簽。
……
App自有的標簽體系對精細化運營來說是必需的，App運營人員可以根據這些用戶標簽來做精準推送、廣告定向投放、活動邀請等運營活動。既然標簽這么有用，接下來我們和大家聊聊如何在友盟推送中使用「標簽」維度，順帶也回答了提問者的第二個問題。
再來談談如何在友盟推送中使用「標簽」:
上文提到過雖然第三方開放平台無法直接給App開發者提供「標簽」維度，但是可以開放打標簽的介面，讓開發者把標簽數據回傳到第三方伺服器上。下面給大家講講友盟推送開放介面的形式，以及開發者如何使用開放的介面來把標簽數據回傳到友盟伺服器端:
圖中，黃色部分表示友盟推送提供的模塊兒，綠色部分部分表示App開發者自己的模塊兒。
方式1(推薦方式): App端直接調用友盟推送SDK提供的tag介面，由SDK負責把標簽數據回傳到友盟後端伺服器。 後期tag(標簽)的存儲、計算等邏輯都由友盟後端伺服器來負責。這種方式是推薦的方式，絕大部分開發者都採用這種打tag的方式。SDK端提供的調用介面有如下幾個:
mPushAgent.getTagManager().
添加標簽
public Result add(String... tags)
刪除標簽
public Result delete(String... tags)
清除所有標簽
public void reset()
獲取伺服器端的所有標簽
public List<String> list()
具體用法請參照我們的集成文檔: 友盟消息推送Android文檔
方式2: 開發者在自己的伺服器上通過調用友盟伺服器端提供的開放介面將該標簽數據回傳到友盟後端伺服器，效果和方式1一樣。 有這種需求的開發者不是太多，所以我們的文檔上沒有把這個介面列出來，有需求的開發者可以聯系msg-support at umeng dot com來獲取這個介面的文檔。
通過方式1或者方式2，開發者就把和自己App業務相關的標簽屬性維度放在友盟平台上了，這樣友盟推送間接的提供了「標簽」維度，和其它靜態維度一樣，「標簽」可以和這些維度一塊兒來使用(App自身業務邏輯結合友盟數據屬性)，也可以單獨來使用(純App自身業務邏輯)，開發者可以利用這些綜合維度來做更精準的推送，從而獲得更好的推送效果了。關於「精準推送」，感興趣的讀者可以參考我之前寫過的一篇文章: 友盟陳漠沙：「精準推送」是怎樣煉成的？ - 友盟專欄 - 知乎專欄
開發者在使用標簽的過程中，可能會碰到這樣的問題，就是明明在SDK端已經調用了標簽介面，但是在友盟推送後台網站上並沒有顯示出剛剛打的標簽。這里需要和大家解釋一下為什麼「標簽」不能及時展現在我們的網站上，其實還是要區分一下「正式模式」和「測試模式」兩種case的，在「測試模式」下，測試設備的標簽是及時出現在網站後台的；在「正式模式下」，大概會有5~10分鍾的延遲。這是因為數據量規模決定的，測試設備數量少，所以我們能做到實時處理，線上真實設備數據量龐大，計算節點在計算的時候，會有一定的延遲。 所以開發者在集成測試階段，如果要測試tag功能的話，建議先把測試的設備在「測試模式」下添加為測試設備。關於「測試模式」的更多介紹，請參考友盟推送「測試模式」介紹。
最後，歡迎大家關注友盟消息推送的官方微博賬號"友盟推送"，我們的官微會定期和大家share一些技術干貨。
⑹ 友盟-推送-Andorid-「Alias」是什麼, 該如何使用
不少開發者在使用友盟推送的時候，對Alias的用法和使用場景不是太理解，這篇文章給大家普及一下Alias相關的內容:
我們先從產品層面上對Alias的設計思想說起，這樣能幫助大家更好的理解和使用Alias。在我們官方文檔裡面，Alias的定義是: "設備別名，將別名與設備做綁定，便於部分App開發者使用自有賬號或者第三方賬號體系來做消息推送"。定義裡面涉及到幾個重要的點:
首先，Alias是和設備綁定的，友盟推送對設備的標識是device-token，也就是說，Alias與友盟device-token是綁定對應的。從這個層面來講，Alias可以是開發者的賬號系統(包括第三方賬號體系)，也可以是開發者自己對設備的標識體系(如安卓設備上的imei+mac)，或者是其它的開發者能保證唯一性的ID體系，這些都是由開發者自己決定的。提問中問到是否可以把Alias理解為賬號系統，狹義上講可以這么理解，實際上，友盟推送賦予了Alias更多的靈活性。
其次，結合到越來越多的App提供第三方社交平台賬號登陸的特點，我們在Alias的設計上也充分考慮到了賬號的需求，所以在官方文檔中，我們提到在使用Alias的時候，必須要關聯一個alias_type, 如果是開發者自定義的alias(包括自有賬號系統)，這個alias_type是可以隨便定義的；如果是用了第三方賬號系統，我們預提供了20多種主流的開放平台的賬號類型，如新浪微博(SINA_WEIBO), 微信(WEIXIN)等。填寫alias_type的作用是，友盟推送會和友盟社會化分享服務做數據上的打通，更好的從數據層面發揮價值，為開發者服務。說到這里，我們再次精確一下Alias的概念，即別名(Alias)+別名類型(alias_type)與設備的綁定。
最後，我們來聊聊Alias的用法，這個也是開發者們非常關心的。我們Alias的綁定操作是在SDK端提供的，開發者只需要在SDK端調用mPushAgent.addAlias(alias, alias_type)這個介面，友盟推送SDK就負責把alias+alias_type與友盟的device-token做綁定，將綁定關系回傳到友盟後端伺服器。之後開發者就可以根據自有業務邏輯，調用友盟伺服器端介面，根據Alias來做個性化推送了。由此來看，Alias的作用是能讓開發者結合自有的賬號(此處需要理解成廣義的賬號)體系，來做更個性化、精細化的推送。下圖是一個簡化的Alias架構，幫助大家理解Alias的用法:
關於Alias的相關介面，我們的友盟消息推送Android文檔提供了非常豐富的介面供開發者調用:
[Java] 純文本查看 復制代碼
?
1
2
3
4
5
添加Alias
mPushAgent.addAlias("[email protected]", ALIAS_TYPE.SINA_WEIBO);
移除Alias
mPushAgent.removeAlias("[email protected]", ALIAS_TYPE.SINA_WEIBO);
注意，在App伺服器端調用友盟伺服器端介面做推送的時候，一定不要忘了傳入alias_type的參數。
關於Alias基本的話題差不多解釋清楚了，最後再和大家深入聊聊Alias用作賬號系統涉及到多賬號多設備登陸的問題，這個時候，alias_type就派上用場了，相信看過這個章節後，大家會對我們Alias的設計機制有更深入的理解:
1. 多個賬號登陸同一台設備，具體還要細分為兩種case:
如果是同一個alias_type，那麼以最後綁定的alias為准。舉個例子: (alias_A, alias_type_A)先做了綁定，之後(alias_B, alias_type_A)後做了綁定，那麼，如果這個時候給alias_A發消息，設備是不會收到消息的，因為在友盟推送後台device-token是和最後登陸的alias_B做綁定的。這個在實際業務場景中也成立，最後一個登錄的賬號才是這台設備當前真實的用戶。
如果不是同一個alias_type, 那麼前後兩個綁定的alias均生效。舉個例子: (alias_A, alias_type_A)先做了綁定，之後是(alias_B, alias_type_B)做了綁定，那麼不管是給alias_A發消息，還是給alias_B發消息，設備均能收到消息。因為alias_type變化之後，友盟推送後台確定不了這是同一個用戶(eg: 同一個用戶使用不同平台的賬號登錄)，還是不同的用戶(不同的用戶，使用不同的賬號登錄)，友盟只能簡單的判定這兩個不同alias_type的賬號是兩個不同的賬號。這種場景是需要特別注意的，建議開發者在實際的集成過程中盡量避免這種使用場景。
2. 同一個賬號登錄多台設備:
這種情況處理起來就比較簡單了，即一個alias和多個device-token做綁定。如果給這個alias發消息，我們會給所有和這個alias綁定的設備都去推送消息。
開發者在具體使用過程中，可能會想到Alias做了綁定(addAlias)或者解除(removeAlias)之後,多長時間能在後端生效。 Alias介面，是一個實時的介面，不管是在「測試模式」下，還是在「正式模式」下，都是實時生效的。不過在集成測試階段，還是建議開發者把手頭的設備添加到"測試模式"下的測試設備集合裡面，關於「測試模式」的更多介紹，請參考友盟推送「測試模式」介紹。