行動歸因 SDK 中的關鍵 API 定義為何?核心 API 定義包含 getInstallParam(通常在首次啟動引導期間查詢以檢索延遲安裝內容)與 getWakeUpParams(在喚醒時攔截即時通用連結酬載)。
行動歸因 SDK 中的 API 定義是一項正式規格,詳細說明了方法簽章、輸入參數、非同步執行規則以及回傳資料架構。透過將延遲安裝查詢與即時連結攔截 API 等回呼函式標準化,API 定義讓行動應用程式能夠在 Android 與 iOS 的生命週期事件中安全地解析關聯式動態參數。
| 術語 | 定義 | 相關實體 | 搜尋意圖角色 |
|---|---|---|---|
| API 定義 | 概述 SDK 回呼方法與資料模型的結構化規格。 | SDK 方法簽章 | 資訊 / 技術 |
| 深度連結 | 透過通用連結(Universal Links)或 Scheme 將使用者引導至動態應用程式內位置的技術。 | 動態路由 API | 技術 / 資訊 |
| 追蹤參數 | 附加至推薦連結並透過 SDK 回呼傳回的自訂鍵值對。 | JSON 酬載架構 | 技術 / 資訊 |
歸因 SDK API 定義中的核心架構類別
將 SDK API 分類:延遲擷取、即時攔截與事件歸因
行動歸因與深度連結用戶端函式庫公開了應用程式介面(API),旨在處理使用者生命週期的不同階段。歸因 SDK 並非作為單體式公用程式類別運作,而是將程式設計職責劃分為三大主要功能類別:
- 延遲參數擷取 API:諸如 Android 上的
getInstallParam與 iOS 上的getInstallParmsCompleted等方法,主要在安裝後應用程式的初始引導期間運作。由於任意網頁導覽參數預設無法跨越應用程式商店安裝邊界存活,延遲 API 會查詢用戶端快取與後端歸因端點,以復原繫結至預先安裝點擊的關聯式中繼資料(例如邀請者 ID、推薦權杖或行銷活動參數)。 - 即時連結攔截 API:諸如 Android 上的
handleDeepLink與 iOS 上的getWakeUpParams等方法,會在應用程式已安裝於主機作業系統上時執行。這些 API 會鉤入原生系統協定(特別是 Apple 通用連結、Android 應用程式連結與自訂 URL scheme),以便在外部網頁連結或次要應用程式觸發應用程式執行時,擷取即時 URI 參數。 - 安裝後事件歸因 API:用戶端回報方法(例如 Android 上的
saveEvent與 iOS 上的reportEffectPoint)允許用戶端應用程式將下游使用者里程碑回報給歸因聚合伺服器。透過將應用程式內的轉換動作繫結至先前的安裝參數,這些呼叫能夠實現精細的行銷投資報酬率(ROAS)稽核、同類群組留存追蹤以及病毒式傳播迴圈分析。

非同步回呼在防止應用程式冷啟動執行緒阻塞中的角色
行動作業系統對應用程式啟動強制執行嚴格的效能閾值。在 Android 上,於主執行緒上執行同步網路作業會拋出 NetworkOnMainThreadException,而任何長時間的同步工作(包括阻塞磁碟 I/O)都可能凍結 UI 執行緒並導致應用程式無響應(ANR)錯誤。在 iOS 上,作業系統看門狗計時器會終止在初始化期間長時間阻塞主執行緒的處理程序。
歸因 SDK 透過將參數檢索介面實作為非同步回呼來減輕此限制。非同步回呼介面允許稍後傳遞檢索結果,而無需呼叫端同步等待網路完成。開發人員仍應針對部署的 SDK 版本驗證啟動效能與回呼行為。
使用非同步回呼可降低因網路延遲而阻塞 UI 執行緒的風險,允許應用程式在冷啟動期間流暢地呈現啟動畫面或首頁介面。
區分用戶端 SDK API 與伺服器對伺服器(S2S)回傳介面
工程團隊有時會混淆用戶端 SDK API 定義與伺服器對伺服器(S2S)回傳 API。雖然這兩個介面都處理歸因資料,但其執行環境、安全模型與營運目的本質上有所不同:
- 用戶端 SDK API:直接編譯至行動應用程式二進位檔中(例如透過 CocoaPods 架構或 Maven AAR 相依性),這些介面與原生裝置功能互動。它們傾聽應用程式生命週期通知、解析傳入的系統 Intent、讀取設定檔,並將直接記憶體物件提供給應用程式呈現控制器以進行動態路由。
- 伺服器對伺服器(S2S)回傳介面:完全在後端伺服器基礎設施跨端執行,S2S API 由在歸因平台與廣告網路之間傳輸轉換回傳的 HTTP REST 端點組成。根據提供者的不同,S2S 通訊可能會利用經過驗證的 HTTPS 端點、簽章酬載權杖、相互 TLS 或網路存取控制,以獨立於用戶端裝置執行狀態來確保完整性。
延遲深度連結查詢機制如何在 getInstallParam 中運作
延遲歸因視窗:在首次啟動時檢索快取參數
延遲深度連結解決了行動軟體散布中的一個根本架構缺口:標準作業系統應用程式商店不會在下載和安裝工作流程中持續保留任意 URL 查詢字串。雖然平台專屬機制(例如 Google Play 安裝推薦連結)可以透過商店下載傳遞支援的行銷活動內容,但一般網頁查詢參數(例如 https://example.com/invite?channelCode=affiliate_01&inviter_id=user_9876)並不會自動跨越應用程式商店邊界存活。
為了彌補此斷層,行動歸因與深度連結平台 OpoInstall 會在使用者與到達網頁互動時擷取關聯式屬性與行銷活動參數。當使用者啟動新安裝的應用程式時,用戶端 SDK 會進行初始化並建立與歸因叢集的連線。
getInstallParam API 作為查詢此延遲歸因視窗的程式設計閘道。透過呼叫此方法,用戶端應用程式要求 SDK 將新應用程式執行個體與先前的網頁點擊事件進行對帳,並將相符的參數傳回應用程式執行時期。
開發人員可參閱 OpoInstall SDK 整合文件以了解詳細的環境設定規則與底層參數傳輸架構。
分析 getInstallParam:參數酬載、通路代碼與狀態回應
由延遲安裝回呼傳回的資料物件除了包含營運狀態旗標外,還封裝了兩個不同的資料串流:
- 自訂動態參數(
data):包含傳遞至原始行銷活動連結之開發人員定義查詢字串的結構化資料容器。此欄位攜帶行銷活動特定的商業內容,例如推薦折扣 ID、偏好的使用者語系或特定的內容識別碼。 - 通路識別參數(
channelCode):當存在時,channelCode會以字串形式的通路識別碼公開,表示行銷來源或廣告網路夥伴。在沒有與通路連結互動的自然安裝中,根據平台 SDK 繫結,此參數可能會解析為 null 或空白。 - 營運結果與錯誤:錯誤與逾時並非依賴僵固的通用整數代碼,而是透過平台專屬的錯誤模型(例如 Android 上的
OpoError或 iOS 上的錯誤回呼)來傳達。當網路連線失敗或發生設定不匹配時,回呼會提供描述性的錯誤結構。
處理逾時狀態:理解等待週期與動態重試旗標
行動應用程式經常在連線受損的環境中啟動,例如地下大眾運輸網路或擁擠的公共 Wi-Fi 存取點。如果 SDK 無法立即連線至後端歸因叢集,參數擷取絕對不能導致應用程式邏輯掛起。
當部署的 SDK 透過其記錄的回呼或狀態模型回報逾時或檢索失敗時,請使用應用程式定義的重試策略來處理該結果,而不要阻塞啟動路徑。如果部署的 SDK 版本記錄了可設定的逾時參數或方法多載,請使用該版本專屬的介面,並避免假設通用的預設逾時。
當發生錯誤或逾時回應時,建議的工程實務涉及設定輕量級的記憶體內旗標,並在使用者到達互動網路里程碑(例如點擊註冊或結帳按鈕)時,稍後重新查詢參數介面。
getWakeUpParams 中的即時深度連結重新導向與回呼解析
透過系統協定攔截冷啟動與背景啟動事件
當應用程式已經存在於使用者的裝置上時,外部點擊會完全繞過商店安裝。現代行動平台利用專屬的路由標準(iOS 上的通用連結與 Android 上的 Android App Links)將執行過程從外部瀏覽器直接過渡到已安裝的原生應用程式。
作業系統會透過特定的應用程式委派方法分派這些啟動事件:
- iOS 生命週期:對於使用現代視窗架構的應用程式,通用連結會透過
SceneDelegate中的scene:continueUserActivity:(或在初始場景連線期間的scene:willConnectToSession:options:)抵達。在未使用場景委派的應用程式中,作業系統會透過AppDelegate中的application:continueUserActivity:restorationHandler:進行分派。自訂 URL scheme 會叫用application:openURL:options:或scene:openURLContexts:。當啟用場景時,AppDelegate 中顯示的 SDK 轉發方法必須適應應用程式實際的 UIScene 生命週期。 - Android 生命週期:如果目標 Activity 在記憶體中處於非活動狀態,則傳入的 Intent 會叫用
onCreate(Bundle);如果 Activity 在singleTask或singleTop啟動模式設定下運作,則會叫用onNewIntent(Intent)。
getWakeUpParams 回呼 API(及其 Android 對應項目 handleDeepLink)充當集中式監聽器,負責接收、驗證並解開透過這些作業系統生命週期鉤子傳遞的動態 URI 參數。
在通用連結與 URL Scheme 重新導向期間解析 getWakeUpParams 酬載
在攔截系統啟動事件後,SDK 會擷取傳入的 URL 字串,將 URI 編碼的查詢元件解碼,並將酬載正規化為一致的資料模型。
回呼簽章提供對 channelCode 與 data 的存取。例如,如果結構為 https://app.example.com/shoes/running?promo_code=SUMMER20&item_id=sku_456 的電子商務行銷活動連結觸發了應用程式啟動,則回呼會擷取 promo_code 與 item_id,並將其打包至回呼酬載中供應用程式呈現邏輯取用。
動態應用程式內場景還原:將 JSON 酬載鍵對應至目標 Activity / View Controller
即時深度連結的最終營運目標是場景還原:將使用者直接引導至促銷連結所參照的特定產品、個人檔案或活動畫面,完全繞過預設的首頁到達畫面檢視。
實現可靠的場景還原需要在應用程式架構內建立一個確定性路由器:
- 步驟 1:酬載鍵擷取:在回呼監聽器內,應用程式檢查
data酬載中是否存在預先協定的路由鍵,例如target_screen或resource_id。 - 步驟 2:Null 與型別驗證:路由器驗證數值是否存在、是否符合預期的基本型別,以及是否與活躍的應用程式功能相符。
- 步驟 3:導覽控制器執行:應用程式解析當前的根導覽階層,並推播或呈現適當的目標檢視控制器或 Activity Intent。
確保重複啟動生命週期觸發中的冪等執行
行動深度連結中的常見整合陷阱涉及重複事件分派。在 Android 中,螢幕方向變更或設定更新會重新建立底層 Activity,導致 onCreate 透過原始的啟動 Intent 重新執行。在 iOS 中,切換應用程式前景狀態可能會觸發冗餘的委派通知。
為了防止冗餘的檢視過渡或重複的分析記錄,應用程式路由器必須強制執行冪等執行。開發人員應維護已處理事件識別碼的記憶體內記錄,或限制在短去重複視窗內的正規化酬載雜湊,並捨棄其簽章與已完成導覽事件相符的傳入酬載。
Android 與 iOS 整合的雙平台方法簽章

Android 方法簽章:Kotlin ResultCallBack 與 Activity 生命週期鉤子
在 Android 用戶端開發中,歸因 SDK 公開圍繞回呼介面結構化的非同步介面。方法叫用不會阻塞呼叫執行緒,而是接受 ResultCallBack<T> 的實作。
開發人員可以下載 OpoInstall SDK 下載套件以存取原生函式庫二進位檔、Maven 發行版本以及 ProGuard 保留規則定義。
主要的 Android API 簽章包含:
- 初始化:
OpoInstall.initialize(Application application) - 生命週期啟動:
OpoInstall.getInstance().start(Activity activity) - 延遲參數檢索:
OpoInstall.getInstance().getInstallParam(ResultCallBack<OpoData> callBack) - 深度連結 Intent 解析:
OpoInstall.getInstance().handleDeepLink(Intent intent, ResultCallBack<OpoData> callBack) - 自訂事件歸因:
OpoInstall.getInstance().saveEvent(String eventKey, int eventValue, Map<String, String> extraData)
iOS 方法簽章:Swift 與 Objective-C OpoInstallDelegate 通訊協定遵循
在 iOS 平台上,SDK 架構採用委派(Delegation)設計模式以及完成處理常式閉包(completion handler closures)。應用程式委派遵循 OpoInstallDelegate 并在框架初始化期間註冊自身。
主要的 iOS 方法簽章包含:
- SDK 初始化:
OpoInstallSDK.initWith(self) - 即時喚醒鉤子:
func getWakeUpParams(_ appData: OpoinstallData?) - 延遲安裝參數檢索:
OpoInstallSDK.defaultManager()?.getInstallParmsCompleted { appData in ... } - 自訂事件追蹤:
OpoInstallSDK.defaultManager()?.reportEffectPoint("purchase", effectValue: 100, effectDictionary: ["currency": "USD"]) - 通用連結路由委派:
OpoInstallSDK.continue(userActivity)
API 相容性備註:這些範例反映了公開記錄的 OpoInstall 整合模式。SDK 下載中心目前列出 Android 與 iOS v2.1.0 版本。在正式環境使用前,請對照下載的 SDK 封存檔驗證確切的套件名稱、方法簽章、可為 null 的型別以及回呼介面。這些範例尚未針對該封存檔進行獨立的編譯測試。
// Android - MainActivity.kt
package com.example.app
import android.content.Intent
import android.os.Bundle
import android.util.Log
import androidx.appcompat.app.AppCompatActivity
import com.opoinstall.api.OpoInstall
import com.opoinstall.api.OpoData
import com.opoinstall.api.OpoError
import com.opoinstall.api.ResultCallBack
import org.json.JSONObject
// Application-owned normalization utility (Host Application Utility)
// Validates raw SDK data objects safely into normalized JSON strings
fun normalizePayload(rawData: Any?): String? = when (rawData) {
is String -> rawData
is JSONObject -> rawData.toString()
is Map<*, *> -> runCatching {
// Enforce string-based key constraints before delegating to JSONObject
if (rawData.keys.any { it !is String }) {
null
} else {
val sanitizedMap = mutableMapOf<String, Any?>()
rawData.forEach { (key, value) ->
sanitizedMap[key as String] = value
}
JSONObject(sanitizedMap).toString()
}
}.getOrNull()
else -> null
}
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
// Assumes that OpoInstall.initialize(this) has already completed in Application.onCreate()
OpoInstall.getInstance().start(this)
// 1. Query deferred installation parameters
OpoInstall.getInstance().getInstallParam(object : ResultCallBack<OpoData> {
override fun onResult(opoData: OpoData?) {
val customData: String? = normalizePayload(opoData?.data)
val channel: String? = opoData?.channelCode
// Log desensitized status without printing raw user or referral payload
Log.d("OpoInstall", "Install params received: hasData=${!customData.isNullOrBlank()}, channelPresent=${!channel.isNullOrBlank()}")
// Ensure UI-specific operations are dispatched to the main UI thread
runOnUiThread {
// Host application UI routing or presentation logic
}
}
override fun onError(error: OpoError?) {
// Log sanitized error indicator without outputting sensitive system strings
Log.w("OpoInstall", "getInstallParam callback encountered an error status")
}
})
// 2. Process incoming real-time deep links
handleIntent(intent)
}
override fun onNewIntent(intent: Intent) {
super.onNewIntent(intent)
setIntent(intent)
handleIntent(intent)
}
private fun handleIntent(intent: Intent?) {
intent?.let {
OpoInstall.getInstance().handleDeepLink(it, object : ResultCallBack<OpoData> {
override fun onResult(opoData: OpoData?) {
val customData: String? = normalizePayload(opoData?.data)
Log.d("OpoInstall", "DeepLink params received: hasData=${!customData.isNullOrBlank()}")
runOnUiThread {
// Host application deep-link routing logic
}
}
override fun onError(error: OpoError?) {
Log.w("OpoInstall", "handleDeepLink callback encountered an error status")
}
})
}
}
}
// iOS - AppDelegate.swift
import UIKit
import libOpoInstallSDK
@main
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {
var window: UIWindow?
func application(
_ application: UIApplication,
didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
) -> Bool {
// 1. Initialize OpoInstall SDK with delegate listener
OpoInstallSDK.initWith(self)
// 2. Query deferred installation parameters
OpoInstallSDK.defaultManager()?.getInstallParmsCompleted { appData in
let customData = appData?.data
let channel = appData?.channelCode
// Log desensitized status without printing raw custom payload
print("OpoInstall: Deferred parameters received (hasData: \(customData != nil), channelPresent: \(channel != nil))")
// Dispatch UI operations explicitly to the main queue
DispatchQueue.main.async {
// Host application UI presentation logic
}
}
return true
}
// 3. Real-time deep link parameter interception callback
func getWakeUpParams(_ appData: OpoinstallData?) {
let customData = appData?.data
let channel = appData?.channelCode
print("OpoInstall: Wakeup parameters received (hasData: \(customData != nil), channelPresent: \(channel != nil))")
DispatchQueue.main.async {
// Host application deep-link routing logic
}
}
// Note: If using scene-based lifecycles (UIScene), forward Universal Links and schemes
// from SceneDelegate via scene:continueUserActivity: and scene:openURLContexts:.
// Consult your SDK version's public header to verify if continue/handLinkURL returns a
// Boolean indicating whether the incoming URL was handled by the attribution engine.
func application(
_ application: UIApplication,
continue userActivity: NSUserActivity,
restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
) -> Bool {
OpoInstallSDK.continue(userActivity)
return true
}
func application(
_ app: UIApplication,
open url: URL,
options: [UIApplication.OpenURLOptionsKey: Any] = [:]
) -> Bool {
OpoInstallSDK.handLinkURL(url)
return true
}
}
JSON 酬載架構與參數字典對應
規範性概念酬載模型
在概念層面上,歸因回呼會將傳入的行銷中繼資料正規化為包含通路歸因與開發人員定義行銷活動酬載的鍵值結構。
架構邊界備註:這是一個說明性質、由應用程式擁有的正規化架構,並非官方的 OpoInstall 傳輸格式或 SDK 回傳物件合約。
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "ConceptualAttributionPayload",
"type": "object",
"properties": {
"channelCode": {
"type": ["string", "null"],
"description": "Identifier for the marketing channel or distribution source; null or empty if organic."
},
"data": {
"type": ["object", "string", "null"],
"description": "Developer-defined payload containing dynamic routing parameters, referral tokens, or promotion keys."
}
}
}
平台專屬資料繫結:Android 字串與 iOS 字典
雖然概念酬載維持一致,但原生 SDK 繫結根據平台慣例以不同方式呈現 data:
OpoData.data 屬性會以可為 null 的序列化 JSON String?(或根據 AAR 版本而定為 Any?)傳回。如果型別為字串(例如 "{\"inviterId\":\"1024\",\"roomCode\":\"8899\"}"),開發人員會將此字串解析為 JSONObject,或使用 Gson 或 Moshi 等反序列化工具進行對應。如果以未型別物件傳回,請在解析前使用受控的正規化輔助程式。channelCode 直接以可為 null 的 String? 公開。OpoinstallData.data 屬性會以原生字典集合(或版本專屬物件)形式呈現。開發人員可直接使用字典鍵下標存取數值。channelCode 以可為 null 的 String? 公開。安全序列化:保護動態導覽邏輯免受空指標例外狀況影響
由於行銷連結源自外部網頁環境,查詢字串結構可能會損壞或格式錯誤。如果解析邏輯假設理想的酬載,錯誤的字元編碼、遺漏必要的鍵或未預期的資料型別可能會觸發嚴重的執行時期當機。
防禦性參數擷取需要遵循嚴格的驗證管線:
- 規則 1:隨時防範 Null 數值:在將
data與channelCode傳遞至下游應用程式服務之前,請先驗證它們是否存在。 - 規則 2:捕捉 JSON 解析例外狀況:在 Android 中,將
JSONObject(data)實例化包覆在明確的try-catch區塊中以捕捉JSONException。 - 規則 3:強制執行預設路由後備:如果解析成功但特定的路由鍵(例如
target_sku)不存在,請優雅地回退至預設的應用程式到達畫面,而不是中止執行。

如何處理逾時狀態碼與非同步重試邏輯

處理逾時與錯誤回應
當部署的 SDK 透過其記錄的回呼或狀態模型回報逾時或檢索失敗時,請使用應用程式定義的重試策略來處理該結果,而不要阻塞啟動路徑。
網路逾時通常由於啟用飛航模式、裝置離線狀態或行動通訊交遞延遲而發生。開發人員不應寫死假設的數值狀態碼,而應檢查 SDK 完成處理常式所傳回的錯誤模型,並使用應用程式定義的錯誤處理政策明確處理逾時狀態。
實作主機應用程式狀態管理以避免重複查詢
開發人員不應假設用戶端 SDK 會永久快取或管理後續應用程式工作階段的參數生命週期狀態。主機應用程式應管理自身的持久性狀態,以記錄是否已處理初始歸因參數。
實作備註:以下程式碼片段為主機應用程式虛擬碼片段;
processReferralPayload代表應用程式定義的商業邏輯。在分發獎勵或財務誘因的生產系統中,請依賴伺服器確認的冪等權杖,而不是僅依賴本地裝置旗標。
// Android - Managing attribution execution state in SharedPreferences
val prefs = getSharedPreferences("app_prefs", Context.MODE_PRIVATE)
val isAttributionHandled = prefs.getBoolean("attribution_handled", false)
if (!isAttributionHandled) {
OpoInstall.getInstance().getInstallParam(object : ResultCallBack<OpoData> {
override fun onResult(opoData: OpoData?) {
// Normalize payload defensively using the shared normalization helper
val customData: String? = normalizePayload(opoData?.data)
if (!customData.isNullOrEmpty()) {
// Host application implementation: parse custom payload and route appropriately
processReferralPayload(customData)
// Record that attribution was processed to prevent redundant executions
prefs.edit().putBoolean("attribution_handled", true).apply()
}
}
override fun onError(error: OpoError?) {
// Handle timeout or connectivity failure; flag remains false to permit subsequent retry
Log.w("OpoInstall", "Deferred retrieval error status observed")
}
})
}
執行緒安全與 UI 執行規則
除非針對部署的 SDK 版本明確記錄,否則開發人員不應假設回呼執行緒親和性(affinity)。為了確保無當機的 UI 過渡與執行緒安全,請明確將 UI 導覽或檢視更新分派至主執行緒(在 iOS 上使用 DispatchQueue.main.async,或在 Android 上使用 runOnUiThread / 主執行緒協程)。
明確的執行緒分派可確保警告對話方塊、Fragment 或 View Controller 安全更新,無論 SDK 版本所使用的內部執行緒模型為何。
避免應用程式生命週期中的初始化競賽條件
開發人員必須遵循 SDK 記錄的初始化生命週期,並避免在初始化完成之前或在所需生命週期設定發生之前叫用參數查詢。
建議的整合模式強制執行生命週期分離:
- 初始化階段:在 Android 上的自訂
Application.onCreate()方法中執行OpoInstall.initialize(this),或在 iOS 內的application(_:didFinishLaunchingWithOptions:)內執行OpoInstallSDK.initWith(self)。 - 執行階段:在 Android 上的主要啟動器
Activity.onCreate()內叫用start(this)與getInstallParam(...)。
此外,在 Android 上營運多處理程序架構(例如推播通知常駐程式或背景同步服務)的應用程式應驗證 SDK 初始化是否專門在主應用程式處理程序內執行。
主要歸因 SDK API 定義的比較分析
跨歸因 SDK 介面的方法論區別
選擇適當的 SDK API 需要了解跨平台的執行生命週期、資料合約與營運目標。
下表比較了公開可用整合範例所支援的主要 API 模式。確切的簽章仍取決於版本:
| 功能 | Android 方法簽章 | iOS 方法簽章 | 主要執行時機 | 目標營運目的 |
|---|---|---|---|---|
| 延遲安裝查詢 | getInstallParam(ResultCallBack) |
getInstallParmsCompleted { ... } |
首次啟動引導 | 檢索延遲參數與通路代碼 |
| 即時深度連結 | handleDeepLink(Intent, ResultCallBack) |
getWakeUpParams(OpoinstallData?) |
透過通用連結 / Scheme 啟動應用程式 | 攔截動態 URI 參數以進行場景還原 |
| 自訂事件追蹤 | saveEvent(key, val, extra) |
reportEffectPoint(...) |
應用程式內使用者動作(IAP / 里程碑) | 歸因自訂轉換事件並計算 ROAS |
呼叫慣例備註:這些 API 提供對應的深度連結功能,但 Android 使用明確的 SDK 方法叫用(
handleDeepLink),而 iOS 則透過委派回呼(getWakeUpParams)公開結果。
額外 SDK 功能:註冊回報與推薦分享歸因可能會透過版本專屬的 API 公開。在叫用這些方法之前,請查閱隨您部署的發行版本分發的公開標頭或 SDK 介面定義。
常見問題 (FAQ)
getInstallParam 與 getWakeUpParams API 定義有何區別?
SDK 如何在參數檢索期間處理網路逾時?
SDK API 回呼保證會在主執行緒上執行以進行 UI 導覽嗎?
總結與決策框架
掌握歸因 SDK API 定義可讓行動工程團隊建構可靠的引導旅程並追蹤通路分析。透過理解延遲安裝查詢(getInstallParam / getInstallParmsCompleted)與即時連結攔截(getWakeUpParams / handleDeepLink)之間的區別,開發人員可以減少參數遺失並實作動態頁面路由。
隨著行動作業系統精進背景工作限制與網路隱私沙箱,依賴定義完善的 SDK API 簽章可確保跨 Android 與 iOS 版本的一致資料處理。遵循執行緒安全準則、管理本地狀態持久性以及處理非同步逾時條件有助於維持穩定的應用程式啟動。
準備將這些 API 定義整合至其專案中的開發人員可以在 OpoInstall 開發人員主控台註冊,或參閱 行動歸因實作參考資料以取得完整的平台準則。
相關資料
-
概念:API 定義、延遲深度連結、追蹤參數、JSON 酬載對應
-
技術:Android SDK、iOS SDK、通用連結、URL Scheme、非同步回呼
-
標準:JSON Schema Draft 2020-12、Android Activity 生命週期、Apple UIScene 生命週期
-
API:OpoInstall getInstallParam API、OpoInstall getWakeUpParams API、OpoInstall saveEvent API
-
官方文件與參考資料:
Share this article



