一、關於用户觸達
用户觸達：可以簡單理解為通過某種方式將消息傳遞給用户的行為；觸達的特定消息從功能上可分展示、引導落地兩層。用户觸達作為一種產品運營方式，已經融入我們日常生產活動的方方面面。在移動互聯網的世界裏，我們的產品離不開觸達，用户活動也離不開觸達。
二、為什麼做用户觸達
以用户使用角度來看，用户在使用 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.goo...
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....
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、站內橫幅、小組件幾種觸達方式的探索實踐過程以及遇到的問題和解決方案。希望能給在探索用户觸達實現方案的同學提供一些思路；為了讓用户在使用我們的產品的時候能有更好的體驗，產品在運營過程中能高效的觸達用户，京東科技技術團隊在持續打磨已有方案的同時將繼續探索和實踐更加智能高效的觸達方案。
