一、關于用戶觸達
用戶觸達：可以簡單理解為通過某種方式將訊息傳遞給用戶的行為；觸達的特定訊息從功能上可分展示、引導落地兩層，用戶觸達作為一種產品運營方式，已經融入我們日常生產活動的方方面面，在移動互聯網的世界里，我們的產品離不開觸達，用戶活動也離不開觸達，
二、為什么做用戶觸達
以用戶使用角度來看，用戶在使用App的程序中會有一些與用戶相關的系統類的通知，比如交易物流、客服訊息、賬單資訊，借還款提醒，實時資訊等訊息需要及時的給用戶提醒；
以APP運營活動看，App在日常運營程序中，根據當前的目標，結合活動向用戶定向發送相關營銷類資訊，比如單品的活動資訊或一些品類促銷優惠等，引導用戶快速進入活動頁面；
因此觸達在拉新、促活、留存、變現、自傳播等運營活動中扮演者重要角色，這篇文章從app 研發視角介紹下用戶觸達方面的一些實踐，
三、觸達用戶的方式實踐
從APP的存活狀態區分，實作觸達有兩種方式，一種是：APP非活躍狀態時的站外觸達，主要包含:短信、Push、桌面小組件等
另一種是：APP活躍狀態時的站內觸達，主要包含站內彈窗、頁面固定運營位，feed流推薦位等，
下面介紹下一下我們實作的幾種觸達方式及遇到的一些問題，
觸達方式一：短信
短信起初應用最廣泛的場景是作為我們交流溝通的一種方式，隨著時代的發展微信、QQ等即時通訊類的app逐漸代替了短信作為人與人溝通工具，但是由于短信能夠及時穩定的將訊息同步給用戶的特點，它仍是我們現在使用比較廣泛的訊息觸達方式，常見的應用場景如：驗證碼通知、還款提醒、賬戶變動、營銷活動通知等，我們知道作為一種觸達方式，它的使命不僅是將訊息通知到用戶，對于特定的訊息還要能便捷的引導用戶跳轉到APP內的相應的落地頁，
短信的訊息觸達能力是毋庸置疑的，雖然短信文本中直接放入的鏈接我們也可以打開，但是確存在一些局限性，這種方式僅支持打開web頁面，無法跳轉到APP原生頁面，另外點擊鏈接會先彈窗，由用戶選擇打開鏈接的app，這種體驗相比直接打開APP指定頁面來說大打折扣，因此，如何通過短信直接到達APP內
相應的落地頁就是我們需要解決的問題，google提供了一種能使Android系統直接通過網站地址打開應用程式對應內容頁面，而不需要用戶選擇使用哪個應用來處理網站地址的方式，即Android App Links；其作業流程如下：
要添加Android App Links到應用中，需要在應用里定義通過Http(s)地址打開應用的intent filter，并驗證你確實擁有該應用和該網站，
如果系統成功驗證到你擁有該網站，那么系統會直接把URL對應的intent路由到你的應用，
1.在AndroidManifest里配置用于系統進行驗證的IntentFilter：
當android:autoVerify="true"出現在你任意一個intent filter里，在Android 6.0及以上的系統上安裝應用的時候，會觸發系統對APP里和URL有關的每一個域名的驗證，驗證程序設計以下步驟：
系統會檢查所有包含以下特征的intent filter：Action為
android.intent.action.VIEW、Category為
android.intent.category.BROWSABLE和
android.intent.category.DEFAULT、Data scheme為http或https
2.配置一個數字資產鏈接的Json檔案，宣告你的網址和應用之間的關系；
對于在上述intent filter里找到的每一個唯一的域名，Android系統會到對應的域名下查找數字資產檔案，地址是：https://域名
/.well-known/assetlinks.json
只有當系統為AndroidManifest里找到的每一個域名找到對應的數字資產檔案，系統才會把你的應用設定為特定鏈接的默認處理器，
數字資產示例：
package_name：在build.gradle里定義的application ID
sha256_cert_fingerprints：應用簽名的SHA256指紋資訊,這個欄位支持多個指紋資訊，可以用來支持不同的應用版本，如開發版本和發布版本然后將assetlinks發布到https://域名
/.well-known/assetlinks.json
[ { "relation": [ "delegate_permission/common.handle_all_urls" ], "target": { "namespace": "android_app", "package_name": "xxx.xxx.xx", "sha256_cert_fingerprints": [ "xx:xx...." ] } } ]
3.跳轉落地頁
在配置了上述intent filter的Activity中決議url，并執行跳轉落地頁等操作
4.問題及排查方法
如果配置后點擊短信的鏈接無法正常跳轉，可以逐個排查相關配置是否正確
4.1 確認數字資產檔案是否被正確地定義和發布：
https://digitalassetlinks.googleapis.com/v1/statements:list?
source.web.site=https://你的域名:可選的埠
&relation=delegate_permission/common.handle_all_urls
4.2 確認應用是否設定了正確鏈接處理方式：
adb shell am start -a android.intent.action.VIEW \
-c android.intent.category.BROWSABLE \
-d "http://你的域名:可選的埠"
4.3 檢查鏈接策略
這一步需要在應用安裝后，等待一段時間10s后再執行，因為應用安裝后系統會請求決議配置表
執行：adb shell dumpsys package domain-preferred-apps 或 adb shell dumpsys package d
該命令回傳了設備上每一個應用配置的串列，這個串列標明應用和網站之間的關聯
App linkages for user 0:
Package: com.android.demo 代表應用包名
Domains: play.google.com market.android.com 網站域名，多個網站之間用空格分隔
Status: always : xxxx 表示應用在Manifest檔案里的配置了 android:autoVerify="true" 狀態為 always；后面的xxxx和驗證是否成功無關，和系統中應用的配置記錄有關；
4.4 解決機型兼容性適配問題
在實踐程序中還發現各廠商的不同型號的設備上存在無法跳轉到落地頁的情況，經分析該機型上應用安裝后系統請求決議配置表assetlinks程序失敗，此時會使用系統默認瀏覽器打開落地頁，落地頁是app原生頁面的無法跳轉到落地頁，對于需要登錄的web頁面，如果未在登錄中心注冊的也會跳轉失敗，并會重定向到m.jd.com ，
解決方案：有問題的機型，使用統一下載頁中轉，下載頁執行喚起APP，APP內處理跳轉落地頁邏輯，
觸達方式二：Push推送
1.客戶端推送方案
Google 為 Android 提供了 FCM 推送，但是因為網路服務等一些原因其可用性不佳；目前國內各廠商rom也都提供了免費的push推送接入能力，同短信比push由于其免費性極大地節約了觸達成本，
同時國內也有一些三方推送服務供應商，我們結合京東金融自身業務特點，為了保障資料的安全性以及推送訊息的服務質量，最終采取整合華為，小米，OPPO、ViVO、魅族各廠商推送能力與自建通道相結合的方案，
其中廠商推送特點：token有效期內，用戶殺死app 可以接收到push訊息；自建通道特點：app啟動后建立連接，接收push訊息，殺死APP后收不到push訊息，主要用于使用未適配的廠商設備如三星、努比亞等用戶接收push訊息，
各廠商在push方案的實作上大體相同（廠商push接入流程，下圖以MiPush為例），在使用廠商推送的程序中我們也遇到了很多問題，因此了解了各廠商的特性是制定出良好的觸達策略前提，
2.廠商推送遇到的問題
2.1 push通知訊息是否可以個性化展示
通常情況下通知欄訊息展示效果主要內容包括訊息標題、摘要、應用圖示和時間，客戶端可以自行定義具體展示內容，
不同廠商如華為、OPPO、vivo、小米、魅族等通知欄樣式存在一些不同綜合對比如下表：
在通知展示的樣式上，綜合對比來看華為支持inBox的樣式，OPPO小米支持大圖樣式，可以通過這些特點定制出更有特色的通知展示形式來突出通知主題，
華為inBox樣式：Inbox樣式將每行內容都當作獨立的單行文本去展示，文本內容最多可展示5行，每行內容展示不了時后邊自動添加“...”
OPPO小米支持大圖樣式:這種通知可以將更有吸引力的圖片展示給用戶
2.2 App有很多業務推送通知，用戶是否可以指定接收分類訊息
隨著APP的業務越來越復雜，應用的通知越來越多，給用戶造成明顯打擾；
用戶只能全域屏蔽這個應用的全部通知，不能屏蔽部分，然后留下對自己有用的，
為了解決這個問題，Android 8.0開始支持開發者給自己的通知分成若干類，然后允許用戶單獨屏蔽這個類別的通知，
需要進行Channel 分類，添加新Channel（以MiPush為例）：
ChannelHelper channelHelper = new ChannelHelper(APP_SECRET); ChannelInfo channelInfo = new ChannelInfo.Builder() .channelId("id") //必填，通知類別的ID，長度不超過 200 字符 .channelName("name") //必填，通知類別的名稱，長度不超過40字符 .channelDesc("desc") //可選，通知類別的描述，長度不超過300字符 .notifyType(0) //必填，通知的效果型別，僅支持0，即振動、提示音、led燈三種效果都無 .soundUrl("sound_url") //可選，通知的自定義鈴聲uri，格式介紹請參見 “4.1 自定義鈴聲” .build(); Result result = channelHelper.addNewChannel(channelInfo, 1)
不同的channel在系統設定頁通知設定中展示如下：
通過細分push通知的類別，增加通道數量可提高push訊息在通知欄里的留存率；
同時用戶可有更多選擇，設定自己比較關注的型別訊息，避免過多打擾，以提升用戶體驗，
2.3 如何指定推送方式或人群
各廠商推送方式支持方式如下：
2.3.1 基于ReglD的推送
RegID為是推送SDK為每個設備上的每個app注冊推送服務時生成的唯一標示，
當開發者需要給一個或多個具體的設備推送訊息時，可以使用基于 RegID的推送，將個性化的資訊推送給指定的設備，這種方式適用于需要為每個用戶訂制個性化推送的場景，
2.3.2 基于Alias的推送
alias是推送提供的一種個性化設定, 開發者可以將用戶在應用內的賬號或其它用戶唯一標識設定為用戶設備 RegID 的別名，在推送中可以直接基于別名進行推送，
別名不僅方便開發者將推送與自有的賬號系統進行關聯，同時也避免了因需要保存設備 RegID 與自有帳號的對應關系而額外帶來的開發和存盤成本，
2.3.3基于標簽的推送
對應用下已訂閱push的設定了標簽的用戶進行推送，在推送訊息時，開發者可以結合每條訊息的內容和目標用戶人群，選擇所對應的標簽，完成請求后，push推送服務會向所有
打上這一標簽的用戶發送該訊息，從而滿足定向推送的需求，并且提供標簽管理功能，
2.3.4 小米通道userAccount ：最多可對應20臺設備，單賬號可登陸多臺設備，給一個 userAccount 推送可同時有20臺設備收到訊息，
總結：將特定的推送訊息通過特定的方式發送給比如不同的客戶端版本、 不同地域、男女等的用戶群體，或者通過給不同的用戶群體打不同的標簽的方式實作特性訊息的推送，以達到更精細推送的目的，
2.4 OPPO、ViVO觸達成功率低，如何提升
觸達資料接入資料看板后，經對比各廠商觸達成功率發現OPPO、ViVO的觸達率基本在83%~86%而小米華為通道觸達成功率基本在94%~98%因此提升OPPO、VIVO通達的觸達成功率是我們面臨的又一問題
OPPO:經排查發現影響OPPO觸達率的主要因素為通知開關的狀態：APP 僅在通知開關開啟的情況下才能收到廠商的Push訊息而OPPO、一加通知開關在用戶安裝后默認關閉，因此收不到Push訊息，
解決辦法：前期主要是制定引導策略，在合適的時機檢測通知開關狀態，引導用戶主動去設定頁開啟，后來經調研發現OPPO的 ColorOS 系統提供了一鍵開啟通知開關的能力，后期使用引導一鍵開啟方案，將OPPO通道的觸達率提升到了94%左右；
VIVO:與OPPO不同，VIVO設備安裝應用后通知開關是開啟的，我們根據數倉提供的資料與廠商反饋的錯誤碼分析，導致VIVO觸達偏低主要因素為訊息未進行分類而被限額，
vivo通道訊息型別分為兩類——按訊息型別是否與用戶強相關將訊息分為“運營訊息”和“系統訊息”，未接訊息分類功能將導致所有訊息默認為運營訊息而受到頻控限制，從而導致重要訊息可能無法觸達，
vivo用戶單應用每日運營訊息接收條數上限5條，系統訊息無限制，vivo用戶單應用接收條數限制以“到達量”是否超過5條為準，在發送時校驗單用戶是否到達5條，超限則計入管控量，
除VIVO外，華為、OPPO、小米對通知訊息的數量 都有一定的限制，對于存在限額的廠商通道，將點擊率高的個性化推送策略盡量安排在上午推送，可以保證優質推送內容的到達率；通過提高訊息推送的額度，提高push訊息的觸達率，
2.5 如何增強未讀訊息提醒
可以在App桌面角標顯示未讀訊息數，廠商lunch app 和 push sdk對此提供了相應的能力支持，用于增強提醒，各廠商的實作細節上有差異：
華為：角標未讀數由服務端下發的push訊息控制，開放了api供第三方應用設定角標未讀數，移除通知欄訊息角標數量不會變化，
小米：角標未讀數等于廠商push通道（系統通知欄）收到的該app的未讀通知數，開放api供第三方應用設定角標未讀數，移除系統通知欄訊息，角標數量相應減少，
oppo：支持紅點，數字角標，角標未讀數等于廠商push通道（系統通知欄）收到的該app的未讀通知數，
vivo：桌面角標未讀數開關默認關閉，需要用戶手動開啟才能使用，提供設定角標未讀數的能力，
角標適配的問題及解決辦法：
2.5.1 在小米系統上能展示通知數，但無法更新站內信數量，
解決方案：站內信和push打通，進入app時同步更新未讀數，
2.5.2 在華為系統上無法顯示Push數量，站內信數顯示正常，
解決方案：華為推送服務提供了在服務端設定桌面角標API介面，第三方app可以在訊息中封裝角標引數，
2.5.3 vivo手機上不支持顯示角標未讀數，
解決方案：更新SDK版本，接入角標能力
2.5.4 在oppo角標展示僅站內信數量，
push功能在開通時可以申請圓點角標或數字角標、無角標三種形式，用戶可以在通知設定中自主選擇，
oppo push支持的系統版本，目前支持 ColorOS3.1及以上的系統的OPPO的機型，一加5/5t及以上機型，realme所有機型（Android 8.0 以后的設備），
2.5.5 其他：魅族手機未開放桌面角標設定，
觸達方式三：站內橫幅
1.站內橫幅方案介紹
已有的觸達方式對用戶實時行為產生的場景覆寫不夠，而且這類場景較離線場景相比實時性更高，對用戶來說相對更重要，針對這個情況，我們增加了對實時場景覆寫，
目的是將用戶行為抽象成關系模型，當關系一側的用戶行為發生變更后觸發對另一側的觸達，這種情況實時性更強而且和用戶強相關，觸達的訊息點擊和轉化都比較高，也有利于增強用戶粘性，
站內橫幅整體設計概覽
資料服務層：各業務模塊負責采集用戶行為資料，由molo側將用戶行為抽象關系模型，用戶進入指定場景，觸發對應場景觸達策略，再經統一頻控量控進行核驗
傳輸層：基于MQTT協議的長鏈接實作的鷹眼自建通道，將通過核驗的觸達信號傳遞給下一流程
APP基礎能力層：為觸達訊息傳輸，流程監控提供基礎能力
資料決議層：將傳遞過來的觸達訊息體決議，合法性校驗，監控例外資料
視圖控制層：進行觸達訊息模板視圖創建，彈出方式識別，通過ViewCore給觸達訊息視圖注入生命周期，出入場影片，聲音震動提醒、展示動效等各種定制化屬性
2.京東金融App站內橫欄應用場景
站內橫欄功能上線后，為一批業務提供了有效的觸達策略
3.遇到的問題及解決思路
3.1 如何讓橫欄實作在App站內全域
全域彈窗這個實作起來相對容易，主要依賴注冊的頁面生命周期監聽，利用WindowManager在離開頁面時移除view ，在進入新頁面重新添加；
3.2 指定頁面顯示或指定頁面不顯示問題
指定頁面的前提是能區分是哪個頁面，分兩種情況：
Web頁面,首先獲取運營在鷹眼平臺配置的指定的Web鏈接,再通過APP的web容器獲取當前正在加的web頁面的鏈接地址，兩個地址進行匹配，需要注意本地取到的url里引數存在比運營配置多的情況，因此匹配時我們認為只要本地取到的引數包含配置的地址中的各引數即是匹配成功；
原生頁面，方式一，路由地址匹配：我們首先取原生頁面的路由資訊，本地有路由資訊根據路由地址去匹配，若原生頁面無路由地址，需要進行適配
方式二，popClass匹配：需要將原生頁面的類路徑錄入到后臺頁面配置表進行維護，匹配時根據頁面的類路徑進行匹配
3.3 如何避免多個橫欄訊息時丟失問題
同時支持多個橫欄，這里需要注意的是橫欄資訊同步問題，我們在創建橫欄的時候給橫欄創建了一個屬性資訊物件，每個橫欄屬性資訊都有唯一的key,將橫欄屬性快取起來，并給快取設定最大閾值，達到閾值時最后一個橫欄消失清除快取資訊
總結：站內橫欄觸達方案是我們在智能化觸達方式中的一項探索，功能上線后，為白條，保險，財富，基金，分期等業務提供了一種更智能化的運營方式，觸達訊息觸達成功率98%，點擊率達到12%~16%，助力相關業務提升40%以上
觸達方式四：桌面小組件
AppWidget 又稱小部件、小插件或微件，它是顯示在Launcher上，能在Logo以外提供更多資訊的一種特別的設計；它方便用戶免于打開App即可直接查看資訊和進行簡單的互動，
- Android 初期已經提供這種能力，但應用比較少，常見的應用如：時鐘、天氣、日歷等；
- iOS 10引入小組件，直到iOS 14的全面支持，可能是受此影響，Android 12 改進了widgetAPI，提升了用戶及開發者體驗
1.創建AppWidget
總的來說分以下幾個部分：
1.1 定義AppWidgetProvider
創建一個AppWidgetProvider子類，并創建對應的AppWidgetProviderInfo 組態檔
example_appwidget_info.xml，并在manifest宣告
1.2 設定appWidget 的基本屬性
AppWidgetProviderInfo定義了widget的基本特性，如應用微件的最小布局尺寸、應用微件的初始布局資源、應用微件的更新頻率，以及（可選）在應用微件創建時啟動的配置 Activity，您可以使用單個 <appwidget-provider> 元素在 XML 資源中定義 AppWidgetProviderInfo 物件，并將其保存在專案的 res/xml/ 檔案夾中
1.3 繪制widget的布局
AppWidget可以支持的布局如下（由于其底層是基于RemoteViews實作，支持的視圖較少）：
- FrameLayout、LinearLayout、RelativeLayout、GridLayout
支持使用的View如下（不支持自定義View）：
- AnalogClock、Button、Chronometer、ImageButton、ImageView、ProgressBar、TextView、ViewFlipper、ListView、GridView、StackView、AdapterViewFlipper
1.4 配置Configuration Activity
當應用widget使用配置 Activity 時，由該 Activity 負責在配置完成后對 app 的widget進行初始化
1.4.1 獲取widget id
1.4.2 執行應用微件配置
1.4.3 配置完成后，通過呼叫 getInstance(Context) 來獲取 AppWidgetManager 的實體
1.4.4 通過呼叫 updateAppWidget(int, RemoteViews) 來使用 RemoteViews 布局更新應用微件
1.4.5.最后，創建回傳 Intent，為其設定 Activity 結果，然后結束該 Activity
1.4.6 設定預覽圖片
在選擇創建appWidget時，展示給用戶的描繪應用微件是什么樣子的一張圖片，未配置時默認展示APP logo
1.4.7 配置Service
請求集合中的特定專案時，RemoteViewsFactory 會為集合創建相應專案并將其作為 RemoteViews 物件回傳，要在appWidget中添加集合視圖，您必須實作 RemoteViewsService 和 RemoteViewsFactory，
詳細參見官方demo：
https://android.googlesource.com/platform/development/+/master/samples/StackWidget/src/com/example/android/stackwidget/StackWidgetService.java
1.4.8 設定點擊事件
通常使用 setOnClickPendingIntent() 來設定物件的點擊行為 - 例如，讓按鈕啟動 Activity，但是，不允許對各個集合專案中的子視圖使用此方法，如果要向集合中的各個專案添加點擊行為，應改用 setOnClickFillInIntent()，這需要為集合視圖設定待定 Intent 模板，然后通過 RemoteViewsFactory 在集合中的每個專案上設定填充 Intent，
2.常見App的實作
金融APP的實作：
3.小組件實踐中的問題
3.1 如何裁剪圖片圓角
一般在開發程序中使用Glide對圖片進行裁剪，這里需要注意小組件里使用Glide與平常略有不同,因為拿不到對應的View視圖，AppWidgetTarget更適用于小組件加載圖片場景，配合MultiTransformation 可簡便的實作圖片圓角的剪裁
AppWidgetTarget appWidgetTarget = new AppWidgetTarget(context, ivViewId, views, mAppWidgetIds);
RequestOptions option = new RequestOptions()
.transform(new MultiTransformation<>(
new CenterCrop(),
new RoundedCorners(ToolUnit.dipToPx(mContext, connerDp))));
GlideApp.with(context)
.asBitmap()
.load(bgUrl)
.apply(option)
.diskCacheStrategy(DiskCacheStrategy.NONE)
.into(appWidgetTarget);
3.2 如何實作自定義字體
小組件本身是不支持自定義view的，若要實作支持自定義字體，可以通過Canvas draw text 方式 給 text 設定字體樣式，粗細、顏色 、背景等屬性
3.3 處理點擊回應延遲問題
通過廣播形式PendingIntent.getBroadcast 處理點擊事件，在部分機型上存在延時，最長約7s；可以使用setOnClickPendingIntent方式代替，需要在app的跳轉中心處理對應的事件，如跳轉落地頁、埋點等
3.4 如何制定更新策略
系統為了避免小組件過多的占用資源，默認拒絕頻繁更新，設定了最短更新時間為30分鐘；這種默認的重繪方式不太適合互動型別的小組件，存在用戶操作完以后頁面狀態不同步的問題，那這個問題如何解決呢？首先根據業務場景需要我們也可以把重繪分為兩類：
實時性有一定要求的業務場景：比如新聞資訊類的
通過創建Service開啟定時任務的方式，制定更新的時間間隔，比如5分鐘執行一次更新任務；
用戶互動型別的業務場景：比如簽到，識訓分、能量等；此類場景不要求頻繁重繪資料，但需要配置合理的自動重繪時間，同時在用戶操作后需要重繪頁面；可以在App啟動時注冊APP內頁面生命周期監聽
ActivityLifecycleCallbacks，實作判斷APP前后臺監聽能力，監聽應用進入后臺時發送重繪小組件的廣播，觸發小組件的重繪；或者封裝統一方法，提供給業務主動觸發重繪對應的小組件的介面
小結
本文主要分享了京東金融客戶端技術團隊對短信、push、站內橫幅、小組件幾種觸達方式的探索實踐程序以及遇到的問題和解決方案，希望能給在探索用戶觸達實作方案的同學提供一些思路；為了讓用戶在使用我們的產品的時候能有更好的體驗，產品在運營程序中能高效的觸達用戶，京東科技技術團隊在持續打磨已有方案的同時將繼續探索和實踐更加智能高效的觸達方案，
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/508877.html
標籤：其他
上一篇：下載和安裝appuploader
下一篇：IOS證書制作教程