無 GAID 的行動歸因：在沒有廣告識別碼的情況下進行安裝歸因

如何在沒有廣告識別碼存取權的情況下處理行動應用程式歸因？您可以在沒有 GAID 或 IDFA 的情況下進行應用程式安裝歸因，但底層架構會有所轉變：現代資料管線不再依賴持續性的廣告識別碼，而是結合了平台中介的歸因框架、Google Play Install Referrer、第一方情境參數路由以及伺服器端驗證。

廣告識別碼是由行動平台提供、可用於廣告與衡量情境的可重設軟體識別碼。在 Android 上，這是透過 Google Play 服務提供的廣告識別碼；在 Apple 平台上，IDFA 的存取則受應用程式追蹤透明度 (ATT) 框架規範。

重點整理：無識別碼行動歸因總結

Google 廣告識別碼並非由單一直接替換的識別碼所取代。相對地，歸因作業已拆分為獨立且專門建構的原生機制：

• 付費廣告活動報表 (Android)：針對透過 Play 發布的安裝，使用 Google Play Install Referrer API 來擷取商店中介的活動參數。

• 付費廣告活動報表 (iOS)：使用 Apple AdAttributionKit 與 SKAdNetwork 取得由平台簽署、兼顧隱私的後端回傳資料 (Postbacks)。

• 網頁轉應用程式引導與推薦：使用第一方安裝情境還原層（例如 OpoInstall）在首次啟動時還原促銷代碼、房間 ID 與邀請者權杖。

• 跨應用程式再行銷：需要授權且平台支援的識別碼或衡量機制，並符合相關平台政策、使用者控制項與同意需求。

架構決策矩陣：選擇正確的歸因原語

為了判定適用於您應用程式的技術機制，請評估您的特定營運需求與平台功能的對應關係：

GAID 替代方案：真正有效的方法

當工程團隊尋找「GAID 替代方案」時，通常是試圖用單一工具解決多個彼此獨立的營運問題。在實際生產環境中，依賴 GAID 的架構必須解構為四個獨立的解決方案：

                        舊版 GAID 工作流程
                                 │
     ┌───────────────────────────┼───────────────────────────┐
     │                           │                           │
     ▼                           ▼                           ▼
付費活動 ROI                    網頁轉應用程式路由            推薦綁定
     │                           │                           │
     ▼                           ▼                           ▼
Play Install Referrer /     第一方情境                  第一方推薦
AdAttributionKit            參數路由                    權杖還原

• 取代基於 GAID 的安裝情境擷取：在適用於 Play 商店發布的安裝時使用 Google Play Install Referrer，並搭配廣告聯播網整合與平台支援的歸因 API。這些框架可在不暴露持續性硬體或廣告識別碼的情況下提供安裝來源情境。

• 取代用於引導與深度連結的 GAID：部署第一方安裝情境還原層（例如 OpoInstall）。透過自有活動網址傳遞動態參數，並透過客戶端 SDK 在首次應用程式啟動時還原，而非查詢廣告 ID 來串聯點擊記錄。

• 取代用於使用者身分的 GAID：使用經過驗證的第一方帳戶系統（例如 OAuth 或內部使用者 UUID）而非裝置層級的廣告金鑰。

核心架構分類：不同原語提供的功能

GAID 與 Install Referrer 與第一方參數還原的比較

Android 應用程式歸因的 GAID 替代方案

在無法存取 Google 廣告識別碼的 Android 裝置上運作時，工程團隊會針對特定的活動管道部署替代機制：

行動歸因平台與 MMP 如何在沒有 GAID 的情況下處理衡量

行動衡量夥伴 (MMP) 如 AppsFlyer、Adjust、Singular 與 Branch 已調整其技術架構，以在缺乏廣告識別碼時支援衡量工作：

透過將用於巨觀廣告聯播網報表的 MMP 與用於微觀引導個人化的第一方情境路由層相結合，工程團隊可以建立互補的衡量與引導堆疊，且不會違反作業系統的隱私沙盒限制。

為什麼廣告識別碼限制會破壞確定性行動歸因

過去對持續性廣告識別碼的依賴

十多年來，行動成效廣告一直依賴由平台廣告識別碼支援的確定性裝置層級比對：Android 上的 Google 廣告識別碼 (GAID) 與 iOS 上的廣告商識別碼 (IDFA)。在此傳統工作流程中，廣告聯播網會在廣告曝光或點擊時擷取使用者的廣告識別碼。當後續安裝並啟動應用程式時，已整合的歸因 SDK 會查詢裝置作業系統以擷取相符的廣告識別碼。

直接的伺服器端相等性查詢 ($GAID*{\\text{click}} == GAID*{\\text{install}}$) 在廣告支出與應用程式安裝之間建立了明確的連結。此機制無需即時工作階段狀態或情境參數傳輸，即可實現確定性的多聯播網歸因、跨發布商側寫與自動化再行銷。

識別碼歸零與平台限制的機制

行動作業系統架構已演進為在未獲明確使用者同意的情況下限制跨應用程式裝置追蹤。

在 Apple 平台上，Apple 應用程式追蹤透明度指南要求應用程式透過 ATTrackingManager.requestTrackingAuthorization 請求追蹤授權。當缺乏授權時，作業系統會保留 IDFA。應用程式必須妥善處理 denied（拒絕）、restricted（受限）與 notDetermined（未決定）狀態，而不能假設廣告識別碼可供存取。

在 Android 上，根據 Android 13 行為變更文件，Google 在 Google Play 服務中引入了明確的權限控制。針對目標為 Android 13 (API 級別 33) 或更高版本的應用程式，開發人員必須在其資訊清單 (Manifest) 中宣告 com.google.android.gms.permission.AD_ID 權限才能存取廣告識別碼。當省略此權限，或是當使用者限制廣告追蹤或刪除其廣告識別碼時，Google Play 服務可能會傳回歸零的識別碼 (00000000-0000-0000-0000-000000000000)，或根據裝置狀態與 Google Play 服務行為指出識別碼無法使用。

確定性廣告歸因管線的失效

當廣告識別碼無法使用或歸零時，依賴識別碼相等性的歸因管線將無法再執行可靠的使用者層級比對。歸零或無法使用的廣告識別碼無法提供用於區分個別轉換旅程的唯一金鑰。

為了維持活動衡量與轉換追蹤，工程團隊必須擺脫對廣告 ID 的依賴。現代架構將安裝歸因與持續性裝置識別碼解耦，轉而依賴第一方情境路由與平台提供的衡量框架。

在此架構中，OpoInstall 被呈現為第一方安裝情境還原 / 延遲深度連結層，而不是作為 Google Play Install Referrer、AdAttributionKit、SKAdNetwork 或其他平台中介廣告歸因系統的通用替代品。

Android 廣告識別碼權限與 Apple ATT 如何影響歸因

Android 13 及更高版本上的 Google Play AD_ID 權限政策

Google Play 對廣告識別碼的擷取實施了細緻的政策治理：

• 資訊清單宣告要求：目標為 Android 13 (API 級別 33) 或更高版本的應用程式必須在其資訊清單中宣告 <uses-permission android:name="com.google.android.gms.permission.AD_ID"/>。如果省略，對 AdvertisingIdClient.getAdvertisingIdInfo(context) 的呼叫將傳回零或指出無法使用的狀態。

• 使用者隱私控制項：當使用者限制廣告追蹤或刪除其廣告識別碼時，Google Play 服務會傳回零或無法使用的狀態。Google Play 開發人員政策明確禁止使用其他持續性裝置識別碼來搭橋或重建已重設的廣告識別碼。

• 敏感應用程式的政策排除：Google Play 政策禁止在針對兒童或受家庭政策限制約束的應用程式中宣告 AD_ID 權限，因而要求開發人員採用無識別碼的衡量管線。

Apple AppTrackingTransparency 框架與授權狀態

在 iOS 上，識別碼存取受 ATTrackingManager.AuthorizationStatus 系統狀態規範：

• notDetermined (0)：使用者尚未回應 ATT 授權請求。應用程式不應假設 IDFA 存取權可用。

• restricted (1)：裝置受家長監護或裝置管理設定檔限制；追蹤在全系統範圍內遭到停用。

• denied (2)：使用者在提示中明確選擇「要求應用程式不要追蹤」，或在 iOS 隱私設定中全域停用追蹤請求。應用程式絕不能依賴 IDFA。

• authorized (3)：使用者明確授予跨第三方應用程式與網站追蹤的權限，允許在符合 Apple 平台政策的前提下存取 IDFA。

重要的架構邊界聲明

重要區別：從歸因架構中移除 GAID 或 IDFA 並不會自動使每種替代追蹤技術都具備隱私安全性或政策合規性。根據 Apple 的應用程式追蹤透明度框架指南，Apple 將追蹤定義為：將從您的應用程式收集的使用者或裝置資料與第三方資料連結，用於定向廣告或衡量，或是將資料分享給資料中介商。如果工程管線收集裝置特徵以重建持續性的跨應用程式身分，則無論是否存取了廣告識別碼，它仍然受平台追蹤政策約束。第一方參數路由必須嚴格限制在使用者發起的旅程之即時引導與轉換情境中。

無識別碼歸因不代表什麼

無識別碼歸因並不代表完全沒有識別碼的分析。應用程式仍然可以處理內部產品功能所需的帳戶識別碼、第一方工作階段權杖或深度連結參數。架構上的目標是消除安裝比對對持續性跨應用程式廣告識別碼的依賴，而不是聲稱所有歸因資料都完全匿名。

不應混淆的三個歸因問題

在沒有廣告識別碼的情況下建構行動歸因時，工程團隊必須區分三個不同的營運目標：

第一方路由機制可以在不需要 GAID 或 IDFA 的情況下解決延遲深度連結與推薦歸因問題，但不應將其視為平台中介廣告歸因的通用替代品。

成長團隊應何時部署第一方歸因層？

建議執行特定產品工作流程的應用程式部署獨立的第一方歸因層：

• SaaS 與訂閱應用程式：行銷流量始於桌面端或行動網頁，並轉換為需要預先驗證的工作階段還原之原生應用程式帳戶的 B2B 平台。

• 遊戲應用程式：多人或社群遊戲，新玩家在首次啟動時必須自動加入邀請者的對賽、公會或房間，而無需手動輸入房間代碼。

• 電子商務平台：提供個人化歡迎折扣或將行動網頁活動中的有效購物車狀態直接還原到原生結帳視圖的購物應用程式。

• 推薦與忠誠度平台：推動有機病毒式循環的產品，需要可靠的邀請者-受邀者權杖綁定，同時不強迫使用者複製貼上優惠券字串。

無識別碼第一方參數路由的架構藍圖

將歸因與持續性裝置識別碼解耦

在本文中，我們使用情境參數路由（也稱為第一方延遲歸因或安裝情境還原）來描述透過使用者發起的網頁轉應用程式旅程進行的第一方活動或推薦情境傳輸。

現代歸因架構專注於行銷互動的*交易情境*，而不是試圖追蹤實體裝置。當潛在使用者點擊活動連結時，該互動會被指派一個包含活動後端資料、管道權杖與應用程式路由參數的短暫路由酬載。

此酬載會伴隨使用者旅程穿過轉換漏斗，讓行動應用程式能夠在啟動時還原情境意圖，而無需查詢系統層級的廣告 ID。

雙層歸因架構

企業歸因架構將直接深度連結與商店中介的安裝流程區隔開來：

                使用者行銷互動
                          │
         ┌────────────────┴────────────────┐
         │                                       │
   直接應用程式連結                        商店 / 廣告流程
         │                                       │
 Universal Links /                  ┌──────┴───────┐
    App Links                       │                           │
         │                       Android                       Apple
         │                   Play Install                   平台廣告
         │                      Referrer                    歸因
         │                            │                              │
         └──────────────┬────────┴──────┬───────┘
                                       │                              │
                                         歸因 / 路由信號
                                                        │
                                             伺服器端驗證
                                                        │
                                    ┌─────────┴─────────┐
                                    │                                      │
                              找到情境                            無信號
                                   │                                      │
                             路由 / 綁定                          有機 /
                             第一方                             優雅降級

情境參數路由與降級的技術機制

第一方參數傳輸的角色

第一方參數傳輸依賴標準的網頁查詢解析與安全的伺服器端工作階段快取。開發人員可以查閱 OpoInstall SDK 文件以取得有關參數綁定模型的技術規格。

當實作不符合 Apple 的追蹤定義時，僅用於直接引導的第一方參數路由不一定需要 ATT；團隊應針對 Apple 的當前政策評估實際的資料流與目的。

平台專屬的安裝歸因降級機制

當直接深度連結遭到商店安裝中斷時，平台專屬的原語會提供結構化的歸因資料：

• Android (Google Play Install Referrer)：Google Play Install Referrer API 指南揭露了與 Play 商店安裝相關聯的推薦人資訊，並提供點擊與安裝時間戳記。API 文件指定了 90 天的推薦人資料可用性視窗。應用程式應根據自身的歸因與重新安裝處理規則持續保存並處理此值，而不是將其視為永久安裝識別碼。請注意，參數必須明確透過 Google Play 傳遞；任意到達網頁的查詢參數不會自動填入此 API。

• Apple 平台歸因：Apple 現代的應用程式歸因堆疊包含 Apple AdAttributionKit 框架，以及與 SKAdNetwork 針對支援的廣告工作流程之互通性。AdAttributionKit 本身不需要 ATT 授權提示；不過，同一應用程式中的其他資料流可能仍構成追蹤，因此需要 ATT 授權。AdAttributionKit 在 Apple 簽署的廣告框架內運作，並搭配向 Apple 歸因框架註冊的合格廣告聯播網。

為什麼基不應將剪貼簿式歸因作為主要策略

剪貼簿或貼上板傳輸通常應被視為例外降級機制，而非主要的歸因設計。剪貼簿存取會引入使用者可見的隱私通知、平台限制以及跨作業系統版本的可用性不一致。在評估貼上板儲存時：

• 明確範圍：酬載應為短效期，並限制在預期第一方流程所需的最小應用程式專屬資料。敏感值應在傳輸中和靜止時得到適當保護。

• 立即清除：應用程式應在初始啟動序列期間消耗後，立即清除或覆寫暫時參數權杖。

• 政策合規性：僅在存在明確定義的第一方使用者流程且遵循適用平台政策審查的情況下使用貼上板機制。

優雅降級與未歸因狀態

具備韌性的隱私架構不會試圖透過侵入性裝置指紋辨識來強制進行歸因比對：

• 直接應用程式連結 / 通用連結：當應用程式已安裝在裝置上時，即時喚醒原生應用程式。

• 商店中介參數傳遞：在可用時透過平台 API（例如 Google Play Install Referrer）擷取活動參數。

• 第一方參數還原：在狹窄的時間視窗內將新的安裝工作階段與活躍的網頁到達網頁互動進行比對。

• 無信號（未歸因）：當網路條件變更、工作階段過期或不存在相應情境時，應用程式會安全地降級至乾淨的預設狀態，而不會中斷使用者引導體驗。

實作範例情境：使用 OpoInstall 進行情境還原

為了理解這些原語如何在生產環境中運作，請考慮執行兩個同時獲客管道的跨平台行動遊戲應用程式：

• 管道 A (付費程式化廣告)：在外部廣告聯播網上執行、重新導向至 App Store 與 Google Play 的廣告活動。

• 管道 B (使用者病毒式分享)：現有玩家透過社群通訊應用程式分享自訂邀請連結 (https://game.example.com/join?room=9876&inviter=usr_432)。

*   

[管道 A：付費廣告] ──> [商店下載] ──> [Play Referrer / AdAttributionKit] ──> [彙整的廣告 ROI]
[管道 B：邀請]     ──> [網頁到達網頁] ──> [第一方權杖還原]               ──> [自動加入遊戲房間]

當新使用者透過管道 A 安裝時，應用程式依賴 Google Play Install Referrer API 或 Apple AdAttributionKit 向行銷儀表板報告活動成效。當使用者透過管道 B 安裝時，第一方路由 SDK 會在首次啟動時擷取動態邀請權杖，立即將新玩家加入房間 9876，而無需查詢廣告 ID 或觸發 ATT 提示。

無識別碼行動歸因中的常見生產失敗案例

在部署不依賴持續性廣告識別碼的歸因架構時，工程團隊經常會遇到特定的營運失敗模式：

• 失敗案例 1：商店重新導向後遺失到達網頁參數：如果活動連結透過未編碼的中間網址縮短器重新導向，諸如 channelCode 或 referrer 等查詢參數可能會在到達到達網頁指令碼或應用程式商店目的地之前被剝離。

• 失敗案例 2：重複的推薦兌換與缺少冪等性鎖定：在生產環境中，如果行動端客戶端在每個 Activity.onResume 或應用程式前景事件上呼叫參數還原而未檢查本地持續性旗標，使用者可能會觸發重複的獎勵聲明或反覆的深度連結導覽。

• 失敗案例 3：重新安裝狀態管理不當：雖然 Google Play Install Referrer 保留歷史推薦人資料長達 90 天，但重新安裝的應用程式可能會收到來自先前安裝生命週期的過時歸因資料，除非客戶端後端驗證帳戶是否已完成註冊。

• 失敗案例 4：有機安裝透過寬鬆比對視窗遭到錯誤分類：如果在共用網路或高使用者密度的環境中將伺服器端工作階段比對視窗設定得太寬鬆，有機安裝可能會與無關的網頁點擊工作階段發生碰撞。

第一方安裝情境還原的說明性 SDK 整合模式

客戶端整合概覽

第一方安裝情境還原 SDK 可用於實作情境參數還原，且無需廣告識別碼。開發團隊可以下載 OpoInstall 行動 SDK 套件與整合資源。

SDK API 附註：下方顯示的初始化與擷取生命週期為說明性的虛擬實作。下方的 API 名稱刻意具有說明性，不應被視為廠商文件。在生產環境中，建議優先使用 SDK 記錄的應用程式層級初始化與安裝情境生命週期，而非將歸因擷取直接耦合至個別 Activity 生命週期。在投入生產使用前，請對照廠商的最新文件驗證所有類別、方法名稱、回呼類型與組態金鑰。

// Android 實作：無識別碼參數擷取（架構模式）
// A 部分中的位置：[CODE_BLOCK_01]
// 附註：基於 OpoInstall SDK 合約的說明性虛擬實作。

// ----------------------------------------------------------------------------
// 1. AndroidManifest.xml (範例摘錄)
// ----------------------------------------------------------------------------
/*
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.myapp">
    <uses-permission android:name="android.permission.INTERNET"/>
    <application android:name=".CustomApplication" android:label="@string/app_name">
        <!-- 使用廠商文件中指定的方法組態應用程式金鑰 -->
        <meta-data android:name="com.opoinstall.APP_KEY" android:value="YOUR_APPKEY"/>
    </application>
</manifest>
*/

// ----------------------------------------------------------------------------
// 2. CustomApplication.kt：應用程式層級狀態機生命週期
// ----------------------------------------------------------------------------
package com.example.myapp

import android.app.Application
import android.util.Log
import com.opoinstall.api.OpoData
import com.opoinstall.api.OpoError
import com.opoinstall.api.OpoInstall
import com.opoinstall.api.ResultCallBack

class CustomApplication : Application() {

    enum class AttributionState {
        NOT_STARTED,
        FETCHING,
        PROCESSED
    }

    override fun onCreate() {
        super.onCreate()
        
        // 在主程序中初始化第一方路由 SDK
        OpoInstall.initialize(this)

        // 在應用程式層級擷取一次安裝情境
        if (getAttributionState() == AttributionState.NOT_STARTED) {
            fetchInstallContext()
        }
    }

    private fun fetchInstallContext() {
        setAttributionState(AttributionState.FETCHING)

        OpoInstall.getInstance().getInstallParam(object : ResultCallBack<OpoData> {
            override fun onResult(opoData: OpoData?) {
                setAttributionState(AttributionState.PROCESSED)
                if (opoData != null) {
                    val channelCode = opoData.channelCode
                    val customData = opoData.data
                    Log.d("InstallContext", "已還原情境：Channel=$channelCode, Data=$customData")
                    handleInstallContext(channelCode, customData)
                }
            }

            override fun onError(opoError: OpoError?) {
                // 若發生暫時性網路失敗，狀態可以保持可重試或進行乾淨降級
                Log.w("InstallContext", "歸因查詢完成，狀態為：${opoError?.errorMsg}")
                setAttributionState(AttributionState.PROCESSED)
            }
        })
    }

    private fun getAttributionState(): AttributionState {
        val raw = getSharedPreferences("attribution_prefs", MODE_PRIVATE)
            .getString("state", AttributionState.NOT_STARTED.name)
        return AttributionState.valueOf(raw ?: AttributionState.NOT_STARTED.name)
    }

    private fun setAttributionState(state: AttributionState) {
        getSharedPreferences("attribution_prefs", MODE_PRIVATE)
            .edit()
            .putString("state", state.name)
            .apply()
    }

    private fun handleInstallContext(channelCode: String?, customData: String?) {
        // 將還原的情境分派至內部帳戶/路由服務
    }
}

iOS 實作：Swift 生命週期整合

在 iOS 上，應用程式會在應用程式生命週期委派 (Delegate) 中整合 SDK。SDK 會在主執行緒上非同步擷取安裝參數，且在未執行跨應用程式追蹤時不會呼叫 AppTrackingTransparency 授權請求。

下方的 Swift 實作展示了說明性的初始化與參數擷取工作流程：

// iOS 整合模式：應用程式層級安裝情境擷取
// A 部分中的位置：[CODE_BLOCK_02]
// 附註：僅供參考的虛擬碼。型別與方法名稱為說明性預留位置。

// ----------------------------------------------------------------------------
// 1. Info.plist (範例摘錄)
// ----------------------------------------------------------------------------
/*
<!-- 使用廠商文件中指定的方法組態應用程式金鑰 -->
<key>com.opoinstall.APP_KEY</key>
<string>YOUR_APPKEY</string>
*/

// ----------------------------------------------------------------------------
// 2. AppDelegate.swift：生命週期初始化與情境擷取
// ----------------------------------------------------------------------------
import UIKit
// 附註：刻意省略 SDK 模組匯入；請使用您的套件管理員提供的模組名稱。

enum InstallContextState: String {
    case notStarted = "NOT_STARTED"
    case fetching = "FETCHING"
    case processed = "PROCESSED"
}

@main
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

    var window: UIWindow?

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        
        // 初始化第一方路由 SDK，不呼叫 ATT 授權
        OpoInstallSDK.initWith(self)

        // 在應用程式進入點以狀態機檢查防範擷取
        if getInstallContextState() == .notStarted {
            fetchInstallContext()
        }

        return true
    }

    private func fetchInstallContext() {
        setInstallContextState(.fetching)

        // 非同步擷取延遲安裝參數
        OpoInstallSDK.defaultManager()?.getInstallParmsCompleted({ [weak self] (appData: OpoinstallData?) in
            DispatchQueue.main.async {
                self?.setInstallContextState(.processed)

                if let data = appData?.data {
                    let channel = appData?.channelCode
                    self?.handleInstallContext(channelCode: channel, customData: data)
                }
            }
        })
    }

    private func getInstallContextState() -> InstallContextState {
        let raw = UserDefaults.standard.string(forKey: "install_context_state") ?? InstallContextState.notStarted.rawValue
        return InstallContextState(rawValue: raw) ?? .notStarted
    }

    private func setInstallContextState(_ state: InstallContextState) {
        UserDefaults.standard.set(state.rawValue, forKey: "install_context_state")
    }

    private func handleInstallContext(channelCode: String?, customData: String) {
        // 將還原的情境分派至內部帳戶/路由服務
    }

    // 用於深度連結的通用連結委派回呼
    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        OpoInstallSDK.continue(userActivity)
        return true
    }
}

客戶端實作的工程考量

• 非封鎖式 UI 生命週期：務必非同步初始化歸因 SDK，並在應用程式啟動期間查詢參數而不封鎖主 UI 執行緒。

• 本地冪等性處理：維護狀態機或持續性旗標（例如 NOT_STARTED、FETCHING、PROCESSED）以乾淨地管理參數擷取並防止重複的 API 查詢。

• 伺服器端重放防禦：針對後端交易記錄驗證動態參數酬載，以確保推薦代碼或促銷權杖不會遭到惡意重放。

平台歸因 API 與隱私沙盒轉型

Android 平台歸因與隱私沙盒轉型

Android 的歸因報表 API 旨在支援跨應用程式與網網頁的隱私保護衡量，且無需依賴跨方識別碼。

Android 的歸因報表 API 可用於支援的隱私沙盒整合，但它們並非 Install Referrer 或 MMP 整合的通用替代品。實際生產適用性取決於特定的 Android 版本、廣告技術整合、註冊要求與生態系統支援。在將歸因報表設為生產依賴項之前，團隊應驗證當前的 Android 隱私沙盒文件。

對於透過 Play 發布的 Android 應用程式，Google Play Install Referrer 仍然是擷取與 Play 商店安裝相關聯之活動參數的實用第一方機制。廣告聯播網與歸因提供者也可能提供平台支援的衡量整合。

Apple 平台歸因：AdAttributionKit 與 SKAdNetwork

在 iOS 上，Apple 提供以 AdAttributionKit 為核心的隱私保護歸因機制，支援跨 App Store 與替代市場的應用程式廣告活動，並與 SKAdNetwork 具備互通性。這些框架在不暴露持續性裝置廣告識別碼的情況下提供平台中介的歸因信號。報表細緻度與時間點仍受 Apple 隱私閾值與歸因視窗規範。

第一方路由與平台 API 的並存

平台隱私 API 與第一方情境路由解決不同的工程需求：

• 平台隱私 API：專為巨觀廣告衡量、廣告聯播網 ROI 計算以及無持續性識別碼的程式化活動最佳化而設計。

• 第一方參數路由：專為微觀應用程式引導、即時使用者對使用者推薦獎勵綁定、深度連結路由以及直接網頁轉應用程式轉換旅程而設計。

如何在沙盒環境中驗證歸因準確性

在無法存取廣告識別碼時驗證安裝歸因

為了驗證應用程式是否正確處理跨不同裝置與權限狀態的安裝歸因：

• 缺少 AD_ID 狀態：部署從 AndroidManifest.xml 中排除 com.google.android.gms.permission.AD_ID 權限的 Android 測試組建，並驗證應用程式是否能乾淨地初始化。

• 使用者識別碼限制：在配備 Google Play 服務的 Android 測試裝置上，啟用廣告限制或在系統設定中刪除廣告識別碼，以確保參數擷取不會當機或停滯。

• Play 商店活動模擬：使用明確透過 Google Play Install Referrer 機制傳遞預期值的測試活動網址觸發安裝旅程。請勿假設任意到達網頁查詢參數會自動成為 Install Referrer 值。

• 重新安裝驗證：在先前已歸因安裝後重新安裝應用程式，並驗證歸因流程不會錯誤地重複使用過時的第一安裝狀態。

• 有機降級驗證：啟動未連結的組建以確認 getInstallParam 能乾淨地解析為 null 或有機降級而不會掛起。

在實體 iOS 裝置上模擬 ATT 拒絕狀態

若要在追蹤遭到拒絕時測試 iOS 參數擷取：

• 透過 Xcode 將測試組建安裝在實體 iOS 裝置上。

• 驗證 SDK 參數擷取方法是否能非同步執行並成功解析參數，且不會提示 ATT 或查詢 IDFA API。

• 測試跨冷啟動與背景喚醒生命週期的應用程式啟動行為。

稽核網路酬載以落實資料最小化

安全性與合規團隊應使用 HTTP Proxy 檢查客戶端的網路流量：

• 確認排除 ID：驗證外寄歸因請求不包含持續性識別碼，例如 IMEI、MAC 位址、Android ID (SSAID) 或未授權的 IDFA 字串。

• 傳輸安全：確保歸因 API 通訊使用具備當前 TLS 組態與標準憑證驗證的 HTTPS。

• 酬載保護：確認儲存在傳輸中或暫時緩衝區中的動態權杖採用適當的保護標準。

使用 OpoInstall 建構無識別碼歸因基礎設施

評估獨立於廣告識別碼的成長堆疊之工程團隊需要三項核心技術能力：

1. 無縫情境還原：將自訂中繼資料從網頁到達網頁傳遞至原生應用程式，且無需手動推薦代碼或硬體 ID 採集。

2. 跨平台活動情境管理：跨平台管理網頁轉應用程式與行動活動，且無需建構多個應用程式。

3. 嚴格的平台合規性：完全在第一方應用程式沙盒內運作，並尊重作業系統的隱私限制。

若要探索行動衡量與路由的實作模式，請查閱 OpoInstall 文件或存取 OpoInstall 開發人員主控台。

總結與決策框架

為了在日益增加的廣告識別碼限制中建構永續的行動成長架構，工程團隊必須擺脫對舊版 GAID 與 IDFA 依賴。隨著作業系統與監管政策持續限制跨應用程式追蹤，依賴持續性裝置識別碼會引入結構性脆弱。

現代歸因框架結合了第一方參數傳輸、平台中介衡量 API 與具備韌性的客戶端 SDK 擷取。透過部署情境路由架構，行動團隊能夠維持可靠的網頁轉應用程式轉換旅程，同時保持符合平台隱私要求。

相關資料

• 概念：廣告識別碼限制、情境參數路由、Install Referrer、AdAttributionKit、應用程式追蹤透明度 (ATT)

• 技術：Google Play Install Referrer API、Google Play 服務廣告 API、Apple ATT 框架、Apple AdAttributionKit、OpoInstall 行動 SDK

• 安全主題：行動資料最小化、重放防禦、傳輸安全

• API：Google Play Install Referrer API、Google 廣告識別碼 API、Apple 應用程式追蹤透明度 API、OpoInstall 安裝參數 API

官方文件

Android

• Google Play 服務廣告識別碼文件

• Android 13 廣告識別碼行為變更

• Google Play Install Referrer API 指南

Apple

• Apple 關於應用程式追蹤透明度的開發人員文件

• Apple 關於 AdAttributionKit 的開發人員文件

• Apple 關於廣告歸因的開發人員文件

• 了解 AdAttributionKit 與 SKAdNetwork 互通性

隱私保護歸因

• Google 隱私沙盒概覽