SKAdNetwork 4.0 轉換數值架構：精細數值、粗略數值與轉換視窗

您該如何設定 SKAdNetwork 4.0 轉換數值架構？ SKAdNetwork 4.0 轉換數值架構將安裝後事件或營收訊號對應至 0 到 63 的精細數值以及粗略數值（low、medium、high）。Apple 的回傳資料層級決定了哪些轉換數值表現形式以及其他具隱私敏感性的欄位可能會出現在符合條件的回傳中。

IDFA（廣告識別碼）是 Apple 針對 iOS 廣告衡量所提供的可重設廣告識別碼。Apple 的 App Tracking Transparency (ATT) 框架將 IDFA 的存取權限從預設系統可用改為需經使用者授權，將行動歸因從決定性的跨應用程式比對，轉變為兼顧隱私的衡量框架。

理解 SKAdNetwork 4.0 轉換數值階層

架構演進：從 SKAN 3.0 單一回傳到 SKAN 4.0 多視窗衡量

在 SKAdNetwork 2.0 和 3.0 下，廣告主依賴單一轉換數值與滾動式 24 小時計時器。對於 SKAN 3 及更早版本，較高的轉換數值可以重新啟動滾動式 24 小時計時器，這促使開發者設計單調遞增的轉換數值架構。當使用者完成應用程式內轉換事件時，內嵌的客戶端 SDK 會呼叫系統 API 來更新單一 6 位元整數（0 到 63）。

對於具有較長轉換漏斗的行動應用程式（例如訂閱式電子商務平台與中度行動遊戲），SKAN 的單一回傳模型對於初始轉換期之後發生的安裝後互動僅提供有限的可見度。

SKAdNetwork 4.0 透過導入包含三個獨立時間視窗的 SKAdNetwork 4.0 多視窗結構、取代以往廣告活動識別碼模型的擴充來源識別碼，以及由精細與粗略數值組成的雙層轉換數值系統，重構了此衡量範例。對於贏得的廣告歸因，SKAdNetwork 4 最多可產生三個回傳。第二與第三回傳僅在符合適用隱私條件且對應的轉換視窗產生符合資格的轉換資訊時才可使用；第 0 層僅接收第一個回傳。

精細數值：將應用程式內互動編碼為 6 位元整數

精細轉換數值代表傳統的 SKAN 衡量指標。作為 6 位元無號整數進行編碼，精細數值支援從 0 到 63 的 64 種離散數值狀態。

由於 6 位元提供 64 種潛在數值，開發者會設計對應邏輯來編碼特定的使用者里程碑或營收範圍：

• 順序漏斗對應：根據漏斗深度依序指派數值（例如 1 = 註冊、2 = 新手引導、3 = 5 級、4 = 購買）。

• 營收區間對應：使用 64 種可用的精細狀態來表示基準狀態加上最多 63 種營收區間（例如 1 = $0.01–$0.99、2 = $1.00–4.99、$\dots、63 = $500.00+）。

精細轉換數值僅在第一個回傳中傳回。第二與第三回傳則會傳回粗略轉換數值。

粗略數值：將安裝後價值分類為低、中、高層級

在轉換視窗 1 中，Apple 可能會根據適用的回傳資料層級傳回精細或粗略轉換數值。轉換視窗 2 與 3 則使用粗略轉換數值。當應用程式呼叫 SKAN 4 轉換數值 API 時，會同時提供精細與粗略數值；Apple 隨後會根據回傳資料層級決定在第一個回傳中包含哪種表現形式（若有的話）。回傳可能包含精細或粗略轉換數值，但不會同時包含兩者。低、中、高標籤在 SKAdNetwork 中沒有預先定義的商業含義。應用程式或廣告聯播網會定義每個層級代表的內容。

粗略轉換數值由包含以下三個明確數值之一的字串屬性組成：

• low：表示基本的安裝後互動（例如完成註冊或啟動工作階段）。

• medium：表示中等的安裝後價值（例如達到中級應用程式里程碑或消費 $1.00–$19.99）。

• high：表示高安裝後價值（例如完成高價值訂閱或消費 $20.00+）。

在轉換視窗 2 與 3 中，轉換數值欄位不用於精細數值；當隱私條件允許時，系統可能會傳回開發者提供的粗略轉換數值。

精細與粗略數值如何在各轉換視窗中運作

轉換視窗 1（第 0–2 天）

轉換視窗 1（第 0–2 天，大約是使用者首次啟動應用程式後的最初 48 小時）涵蓋安裝後的初始衡量期間，在此期間開發者可以在系統關閉視窗之前更新精細或粗略轉換數值。在此時間範圍內，行動應用程式可以在使用者完成應用程式內事件時多次更新轉換數值。

根據 Apple 指派的回傳資料層級，轉換視窗 1 會傳遞精細數值（0 到 63）或粗略數值（low、medium、high）。如果回傳資料層級為第 0 層，則第一個回傳僅包含兩位數的階層式來源識別碼；精細或粗略轉換數值會被省略。

轉換視窗 2（第 3 至 7 天）與 3（第 8 至 35 天）

為了提供對中期與長期使用者留存的可見度，SKAdNetwork 4.0 導入了兩個額外的轉換視窗：

• 轉換視窗 2：衡量在安裝後第 3 至 7 天衡量期間（為期 5 天的視窗）內發生的使用者互動。

• 轉換視窗 3：衡量在安裝後第 8 至 35 天衡量期間（為期 28 天的視窗）內發生的使用者互動。

與視窗 1 不同，轉換視窗 2 與 3 僅傳輸粗略數值。視窗 2 與 3 不支援精細數值（0 到 63）。開發者根據該衡量期間內發生的事件來決定為每個視窗回報的粗略數值。

理解回傳資料層級與群體匿名性

Apple 根據與來源應用程式或網域、被宣傳的應用程式、安裝被宣傳應用程式的國家/地區，以及廣告聯播網提供的階層式來源識別碼相關聯的群體規模，來決定應用程式下載的回傳資料層級。根據不同的層級，第一個回傳可能會暴露階層式來源識別碼的兩位、三位或四位數，而轉換數值可能會被省略、以粗略數值傳回或以精細數值傳回。根據 Apple 官方的 SKAdNetwork 框架文件（StoreKit > SKAdNetwork），Apple 並未公布開發者可用來將廣告活動對應至固定資料層級的通用安裝量閾值。

下表根據 Apple 官方的 SKAdNetwork 框架文件，概述回傳資料酬載如何與各轉換視窗中的隱私層級相互關聯：

利用 lockWindow 屬性提早完成轉換視窗

設定 lockWindow: true 會鎖定目前轉換視窗的轉換數值。系統會立即準備對應的回傳，並忽略該視窗中進一步的轉換數值更新。回傳仍受 Apple 的隨機傳遞延遲約束。

例如，如果使用者在轉換視窗 1 開始後 6 小時完成購買，應用程式可以設定 lockWindow: true。這會提早關閉衡量視窗，並允許 Apple 的回傳排程程序開始，這可能會導致系統更早準備回傳，儘管適用的隨機傳遞延遲仍然適用。

SKAdNetwork 轉換視窗 1、2 與 3 的架構比較

SKAN 4.0 回傳時間、數值類型與延遲視窗的比較評估

管理多視窗 SKAdNetwork 架構需要根據視窗持續時間、支援的數值粒度與回傳延遲範圍來對應事件觸發條件。

下表對比了轉換視窗 1、2 與 3 的技術特徵：

評估跨 SKAN 轉換視窗的資料粒度與時間戳記

雖然轉換視窗 1 提供最高的資料解析度（6 位元精細數值），但視窗 2 與 3 提供了至關重要的長期留存訊號。分析師在將 SKAN 回傳與內部交易帳本進行結合時，必須將回傳延遲範圍納入考量。

由於 Apple 對視窗 1 回傳套用 24 到 48 小時的隨機延遲，對視窗 2 與 3 則套用最高 144 小時的隨機延遲，因此到達歸因端點的回傳並不代表即時轉換，而是代表幾天前完成的歷史互動視窗。

尋求設定客戶端 SDK 記錄與自動化 SKAN 回傳解析的工程師可以參考 OpoInstall 歸因 SDK 整合文件以檢視酬載結構設定。

如何設計 SKAdNetwork 轉換數值架構

SKAdNetwork 4.0 轉換架構對應範例

設計 SKAdNetwork 架構需要將應用程式內的里程碑與購買層級對應至離散的精細與粗略數值。

下表說明了行動應用程式的標準轉換數值架構設計：

生產環境架構設計框架：遊戲與訂閱應用程式的比較

根據產品變現動態，工程團隊會量身打造架構設定，以優先考量即時漏斗進展或長期營收層級：

• 遊戲應用程式（以營收優先）：數值 0 到 10 對應早期教學進度，而數值 11 到 63 則代表視窗 1 期間觀察到的累積營收。視窗 2 與 3 中的粗略數值對應重複購買頻率（low = 活躍、medium = 第二次購買、high = VIP 消費者）。

• 訂閱應用程式（以試用優先）：數值 0 到 5 對應註冊與個人檔案完成，數值 10 對應免費試用啟用，數值 20 到 63 則對應訂閱方案選擇。視窗 2 與 3 中的粗略數值對應試用轉付費轉換（low = 活躍工作階段、medium = 試用已轉換、high = 訂閱已續約）。

如何在基於營收與基於事件的轉換數值之間進行選擇

在基於營收與基於事件的架構模型之間進行選擇，需要將轉換數值邏輯與應用程式變現機制相結合：

• 基於營收的模型（電子商務與遊戲）：最適合購買事件發生在最初 48 小時內的應用程式。透過將累積消費編碼到逐漸擴大的營收區間中，需求方平台 (DSP) 可以接收可用於廣告活動分析的營收訊號。如果架構是基於累積營收，則每次轉換更新都應編碼使用者目前的累積安裝後營收，而不僅僅是最近的交易金額。

• 基於事件的漏斗模型（訂閱）：最適合具有延長試用或考慮期的應用程式。透過對應順序里程碑（例如從註冊到試用啟用再到訂閱），廣告活動衡量會在第 0–2 天到期之前評估高意向的試用者。

設計營收區間：將 IAP 範圍對應至 0-63 數值

在分析廣告支出報酬率 (ROAS) 時，將 6 位元精細數值對應至營收區間代表了一種有效的架構設計。應用程式根據自身的商業邏輯計算累積營收，並將結果編碼到轉換數值中。以下的區間邊界僅供說明，而非完整的 64 區間生產環境對應。在實際生產環境中，區間邊界應衍生自應用程式的付費者分佈、預期的 ROAS 敏感度以及廣告活動目標。

電子商務或遊戲應用程式的 6 位元營收架構範例結構如下：

• Value 0：無衡量的安裝後事件 / 基準。

• Value 1：$0.01 至 $0.99（微交易）。

• Value 2：$1.00 至 $4.99。

• Value 3：$5.00 至 $9.99。

• dots\dotsdots

• Value 62：$250.00 至 $499.99。

• Value 63：$500.00+（高價值消費者層級）。

當使用者完成應用程式內購買時，行動 SDK 會計算使用者在視窗 1 期間觀察到的累積消費，識別對應的整數區間，並呼叫 updatePostbackConversionValue。

設計互動漏斗：對應循序里程碑

對於應用程式內購買發生在使用者生命週期後期的訂閱應用程式或公用工具，將精細數值對應至循序互動里程碑可提供早期的廣告活動成效訊號。

互動里程碑架構會對應進展深度：

• Value 1：帳戶註冊完成。

• Value 2：新手引導教學完成。

• Value 3：個人檔案設定與偏好已配置。

• Value 4：免費試用已啟用。

• Value 5：首次應用程式內內容分享。

• Value 10：付費訂閱已開始。

與早期版本相比，SKAN 4.0 提供了更具彈性的轉換數值管理，儘管廣告主通常會繼續使用遞增數值策略來確保最佳化穩定性。應用程式應定義具決定性的優先順序規則，以便在同一視窗內發生的多個事件能夠解析為單一最終的精細/粗略狀態。

[App Launch / Event] ──> [SDK Calls updatePostbackConversionValue]
                                    │
                                    ▼
         ┌──────────────────────────┴──────────────────────────┐
         ▼                                                     ▼
[Conversion Window 1 (0-2 Days)]               [Conversion Window 2 & 3]
 (Fine 0-63 or Coarse)                               (Coarse Only: Low/Med/High)
         │                                                     │
         └──────────────────────────┬──────────────────────────┘
                                    ▼
                [Apple Attribution System Delayed Postback]
                                    │
                                    ▼
               [Attribution / Analytics Backend]

說明性的生產環境風格 SKAdNetwork 4.0 架構範例

1. 行動遊戲架構（營收 + 里程碑混合型）

遊戲應用程式在視窗 1 中採用混合架構，保留較低的數值（0–10）用於教學里程碑，並將較高的數值（11–63）分配給視窗 1 期間觀察到的累積營收。在此說明性架構中，應用程式獨立將這些里程碑對應至粗略類別。

• Value 1：教學完成（low 粗略對應）

• Value 5：達到 10 級（medium 粗略對應）

• Value 15：首次 IAP（$0.99 - $9.99）

• Value 40：中等消費者（$10.00 - $99.99）（high 粗略對應）

• Value 63：VIP 消費者（$100.00+）（high 粗略對應）

2. 訂閱應用程式架構（聚焦試用與續約）

訂閱應用程式將視窗 1 對應至免費試用轉換速度，同時利用視窗 2 與 3 的粗略數值來追蹤長期的試用轉付費轉換與續約事件。

• 視窗 1：Value 1 = 註冊、Value 10 = 試用開始（medium 粗略對應）、Value 63 = 已訂閱年度方案（high 粗略對應）

• 視窗 2（第 3-7 天）：low = 活躍工作階段、medium = 試用已轉換、high = 留存年度方案

• 視窗 3（第 8-35 天）：low = 應用程式重新互動、medium = 付費訂閱者活躍、high = 訂閱已續約

大規模管理 SKAdNetwork 架構

對於管理多個 iOS 廣告活動的成長與資料工程團隊而言，集中式轉換數值管理可以減少實作錯誤、自動化酬載對應，並維持完整的回傳可見度。設定安全的安裝歸因工作流程可確保跨客戶端 SDK 與後端報表資料庫的酬載完整性。

透過 StoreKit 實作 SKAdNetwork 4.0

透過 StoreKit 進行程式化轉換數值更新

當符合相關的 SKAdNetwork 4 資格條件時，即可使用 SKAdNetwork 4 回傳。為了接收多個 SKAdNetwork 4 回傳，被宣傳的應用程式需要在適用的轉換視窗期間更新轉換數值。視窗 1 的更新不會自動建立視窗 2 或視窗 3 的轉換數值。對於使用 SKAdNetwork 4 API 的應用程式，被宣傳的應用程式應使用 iOS 16.1 SDK 或更新版本建構，並在 iOS 16.1 或更新版本上執行，以便在 StoreKit 內呼叫 SKAdNetwork.updatePostbackConversionValue(_:coarseValue:lockWindow:completionHandler:)。AdAttributionKit 是一個獨立的 Apple 歸因框架，不在這個 SKAdNetwork 轉換數值實作範例的範圍之內。

該方法接受三個核心參數：

1. fineValue：從 0 到 63 的整數。

2. coarseValue：一個 SKAdNetwork.CoarseConversionValue 列舉（.low、.medium、.high）。

3. lockWindow：布林值旗標，表示是否要提早完成視窗。

為了進行 SKAdNetwork 4 多回傳衡量，應用程式必須在適用的轉換視窗期間繼續更新轉換數值；設定視窗 1 數值不會自動填入視窗 2 與 3。

開發者可以參考官方開發者文件中關於原始事件記錄酬載架構與 SKAN 酬載結構的技術規格。

以下的程式碼與架構說明了開發者如何在 Swift 中叫用 SKAN 4.0 更新 API，以及後端收集器如何格式化產生的回傳酬載：

注意：以下架構與程式碼片段僅為概念範例，並非 Apple 或 OpoInstall API 規格。

// Swift Example: Updating SKAdNetwork 4.0 Conversion Value on iOS 16.1+
import StoreKit

func updateSKANConversionValue(fineValue: Int, coarseValue: SKAdNetwork.CoarseConversionValue, shouldLock: Bool) {
    guard (0...63).contains(fineValue) else { return }
    if #available(iOS 16.1, *) {
        SKAdNetwork.updatePostbackConversionValue(fineValue, coarseValue: coarseValue, lockWindow: shouldLock) { error in
            if let error = error {
                print("SKAN Update Error: \(error.localizedDescription)")
            } else {
                print("SKAN Value Updated Successfully: Fine = \(fineValue), Coarse = \(coarseValue.rawValue), Locked = \(shouldLock)")
            }
        }
    } else {
        // Deprecated legacy API used for compatibility with older OS versions.
        SKAdNetwork.updateConversionValue(fineValue)
    }
}

{
  "example_only": true,
  "privacy_note": "Illustrative schema only",
  "measurement_model": "cumulative_revenue",
  "precedence": "highest_qualifying_value",
  "lock_policy": "lock_on_terminal_conversion",
  "event_type": "skan_conversion_value_mapping_config",
  "app_id": "com.example.iosapp",
  "skan_schema_version": "4.0",
  "window_1_config": {
    "fine_value_mappings": [
      { "value": 0, "event_name": "app_launch_or_baseline", "min_revenue_cents": 0 },
      { "value": 1, "event_name": "registration", "min_revenue_cents": 0 },
      { "value": 10, "event_name": "free_trial", "min_revenue_cents": 0 },
      { "value": 30, "event_name": "first_purchase", "min_revenue_cents": 100 },
      { "value": 63, "event_name": "whale_purchase", "min_revenue_cents": 50000 }
    ],
    "coarse_value_mappings": {
      "low": "app_launch_or_registration",
      "medium": "first_purchase_under_20",
      "high": "purchase_over_20"
    }
  },
  "window_2_config": {
    "coarse_value_mappings": {
      "low": "d3_d7_active_session",
      "medium": "d3_d7_repeat_purchase",
      "high": "d3_d7_subscription_renewed"
    }
  },
  "window_3_config": {
    "coarse_value_mappings": {
      "low": "d8_d35_active_session",
      "medium": "d8_d35_repeat_purchase",
      "high": "d8_d35_subscription_retained"
    }
  }
}

SKAdNetwork 轉換數值最佳實踐

將轉換架構設計與廣告活動目標相結合

設計 SKAdNetwork 架構需要選擇符合您主要廣告活動目標的對應規則。針對即時試用轉換進行最佳化的媒體採購團隊應優先考慮轉換視窗 1 中的循序漏斗里程碑。相反地，評估高價值購買的成效團隊則應實作細緻的營收區間。

整合廣告活動以清除群體匿名性層級

為了防止回傳傳回 null 數值或降級為粗略備份，行動成長團隊會管理廣告活動密度：

• 減少廣告活動碎片化：為了降低低回傳資料層級的可能性不必要的廣告活動碎片化與過度狹窄的目標鎖定。不過，Apple 並未公布保證特定回傳資料層級的通用支出或安裝閾值。

• 擴大目標鎖定參數：避免打破群體匿名性閾值的過度狹窄地理或人口統計目標鎖定。

• 最佳化 LockWindow 策略：團隊通常應考慮僅在確信該視窗剩餘部分內不再預期有更有價值的轉換訊號時，才使用 lockWindow: true。

SKAdNetwork 4.0 轉換數值架構檢查清單

為確保完整的 SKAdNetwork 4.0 追蹤合規性並最大化 LTV 衡量，請驗證您的架構是否滿足以下工程要求：

• [ ] 主要最佳化目標：定義您的廣告活動是針對早期互動里程碑還是累積 48 小時營收進行最佳化。
• [ ] 視窗 1 精細數值對應：將離散的 6 位元整數數值（0–63）指派給循序漏斗步驟或營收區間。
• [ ] 視窗 1 粗略數值對應：為低群體匿名性分派設定 low、medium 與 high 粗略字串區間。
• [ ] 視窗 2 與 3 粗略數值對應：為 3–7 天與 8–35 天回傳視窗建立粗略追蹤邏輯。
• [ ] 事件優先順序與鎖定規則：定義具決定性的事件優先順序，並僅在終端轉換事件上設定 lockWindow: true。

降低衡量品質的常見 SKAN 4.0 架構設計錯誤

• 將消費層級壓縮至數值 63：將 $10 購買與 $1,000 購買指派到同一個頂端區間，會減少可用於廣告活動分析與最佳化的營收差異。

• 過早執行 LockWindow：在早期註冊事件上呼叫 lockWindow: true 會永久鎖定轉換視窗 1，從而丟棄後續的 48 小時購買事件。

• 使視窗 2 與 3 過於複雜：嘗試為最多 35 天後到達的回傳對應複雜的粗略規則，會在沒有改善早期出價最佳化的情況下使廣告活動評估變得複雜。

如何疑難排解 SKAdNetwork 回傳 Null 值與群體匿名性下降

診斷高 Null 轉換數值率：理解低廣告活動群體匿名性

在歸因儀表板中檢視 SKAN 廣告活動成效時，分析師經常會觀察到回傳傳回 null 或遺失轉換數值。高比例的遺失轉換數值可能表示適用的回傳資料層級不允許 Apple 揭露轉換數值資訊。

為了解決群體匿名性下降並提高轉換數值可見度，成效團隊會整合廣告活動金鑰並評估廣告活動結構密度，以確保安裝速度清除群體匿名性閾值。

解決順序錯位與轉換數值降級陷阱

在 SKAdNetwork 4.0 中，轉換數值可以在視窗 1 期間靈活更新，但開發者必須小心管理 lockWindow 狀態。

如果應用程式在低價值事件（例如 Value 2 = 註冊）上設定 lockWindow: true，視窗將會永久鎖定。如果使用者隨後在 48 小時視窗內的 10 分鐘後完成 $100 購買，系統將無法更新轉換數值，導致回報的廣告活動 LTV 偏低。開發者必須確保 lockWindow: true 是在終端的高價值轉換事件上執行。

處理 Apple 歸因系統強加的隨機延遲範圍

為了防止廣告主試圖透過將轉換時間戳記與網路點擊記錄進行比對來重新識別個別使用者，Apple 對所有回傳分派強制執行強制性的隨機延遲。

對於轉換視窗 1，系統會在轉換視窗關閉或應用程式鎖定視窗時準備回傳。然後，Apple 會套用 24–48 小時的隨機延遲。視窗 2 與 3 在對應視窗關閉或鎖定後使用 24–144 小時的隨機延遲。資料工程管線必須將這些系統性延遲納入考量，避免在 SKAN 資料串流上設定短視窗的自動化出價調整。

重點整理

• 多視窗衡量：SKAN 4.0 跨三個回傳視窗（0-2 天、3-7 天、8-35 天）擴展衡量，使用精細（0-63）與粗略（low、medium、high）數值。

• 群體匿名性閾值：較高的廣告活動安裝量可能會啟用精細數值，而低量廣告活動則會收到粗略數值或 null 修訂以保護隱私。

• 策略性 LockWindow 使用：在終端轉換事件上執行 lockWindow: true 可以縮短視窗鎖定前的等待時間，從而實現更快的廣告活動回饋。

總結與決策框架

在 Apple 的隱私指導方針下最佳化 iOS 廣告活動衡量，需要設定結構良好的 SKAdNetwork 轉換數值架構。從舊版 IDFA 追蹤過渡到 SKAN 4.0 多視窗回傳，可讓成效團隊評估即時啟動與長期使用者留存。

透過為即時 48 小時互動對應 6 位元精細數值，以及為延長的 35 天視窗對應粗略數值，成長團隊可以擷取關鍵的營收與留存訊號。將客戶端 SDK 與自動化 SKAN 架構工具進行整合，可提供解碼聚合回傳所需的基礎設施，並為 iOS 廣告活動效率提供最佳化訊號。

若要探索統一行動衡量如何最佳化您應用程式的成長策略，請參閱 OpoInstall 行動歸因實作參考或在 OpoInstall 開發者控制台註冊帳戶。

相關資源

若要加深您對 SKAdNetwork 衡量、行動歸因基礎設施與隱私保護應用程式成長的理解，請探索我們的技術指南：

• SKAdNetwork 與 MMP 歸因：關鍵差異解析：了解 Apple 原生的 SKAdNetwork 框架與獨立行動衡量夥伴歸因模型之間的對比，以及兩個系統如何協同運作。

• 如何透過延遲深度連結與安裝歸因實作推薦追蹤 SDK：了解行動應用程式如何使用延遲深度連結與歸因 SDK 工作流程，在應用程式商店安裝流程中保留取得情境。

• 行動衡量夥伴如何運作：探索 MMP 平台如何吸收歸因訊號、處理安裝後事件，並產生聚合的廣告活動衡量報告。

相關主題

• 概念：SKAdNetwork、轉換數值、回傳視窗、群體匿名性、LockWindow

• 技術：行動衡量夥伴 (MMP)、StoreKit、AdAttributionKit、伺服器對伺服器回傳

• API：OpoInstall 行動歸因事件記錄功能、Apple SKAdNetwork API、Apple AdAttributionKit API

• 官方文件與參考資料：

  • Apple SKAdNetwork 框架開發者文件

  • Apple AdAttributionKit 開發者文件

  • W3C 網頁效能工作小組標準