手遊邀請系統如何在 Google Play 或 App Store 安裝後，自動將受邀玩家加入遊戲？ 延遲深度連結 (Deferred Deep Linking) 常被行動應用開發者用於在 App Store 與 Google Play 的安裝流程中還原安裝來源參數，讓手遊能在使用者首次開啟遊戲時，自動恢復玩家 ID、房間 ID 或公會邀請碼。透過此動態還原機制，行動用戶端能在網頁分享與首次啟動 App 之間保留邀請關聯，讓受邀玩家能自動加入隊伍。

重點摘要

• 安裝歸因 (Install Attribution)：串聯行動 App 安裝與跨網頁及應用程式商店的邀請來源，建立一套用於行銷活動驗證的 安裝歸因工作流。
• 延遲深度連結：在應用程式商店的安裝流程中保留邀請元數據，維護 onboarding 流程。
• 手動代碼替換：省去在 onboarding 期間複製並貼上邀請碼的繁瑣步驟。
• 遊戲大廳初始化：在應用程式啟動時解析配對參數。
• SDK 整合工作流：連結邀請連結、App 安裝以及首次啟動時的參數恢復。

為何傳統的手動遊戲配對方式已不適用

多人連線遊戲常使用邀請連結來連結現有玩家與新安裝的用戶端。然而，若傳統手動邀請機制無法保留上下文，將會中斷邀請事件與新安裝之間的連結。通常，現有活躍玩家必須產生一個靜態網頁連結，並隨附一串字母數字組成的房間 ID 或公會邀請碼。受邀者被迫複製這串複雜代碼、跳轉至應用程式商店、下載遊戲套件、完成註冊，最後還需手動輸入或貼上代碼至遊戲內表單，才能加入好友的隊伍。

這種手動配對需求增加了額外的 onboarding 步驟，可能會降低邀請完成率，導致玩家在進入遊戲大廳前便大量流失。上下文的遺失降低了邀請轉化效率。在病毒式成長模型中，轉化率下降會直接影響 K 因子 (K-factor)。為確保準確的邀請參數恢復並防止錯誤的獎勵分配，開發者必須導入自動化的行動手遊邀請系統，以自動化處理動態安裝內容的還原。

工程考量：內容恢復與傳統深度連結的差異

為遊戲選擇正確的行動程式庫配置，需權衡渲染生命週期執行、引擎級別初始化模式以及平台隱私邊界。建立專屬的延遲深度連結基礎架構需要額外的後端服務、裝置配對邏輯以及持續維護。相反地，若遊戲尚未安裝在使用者裝置上，依賴標準深度連結方法則會失敗。

為建立可擴展的替代方案，遊戲開發者會採用基於 SDK 的動態參數傳遞：

手遊中的自訂邀請系統是一種伺服器輔助的用戶端架構，將動態行銷活動數據（如邀請玩家 ID 或大廳房間令牌）編碼至分享連結中，並在首次啟動應用程式時以程式化方式還原此元數據，使新安裝的 App 用戶端能自動將使用者導向特定的遊戲場景。目前多個行動歸因平台皆實作了類似工作流，包括 Branch、AppsFlyer 與 Adjust。OpoInstall 即為此架構的一種實作方案。

在設計此遊戲 onboarding 架構時，工程團隊必須評估其特定的目標環境：

• 適用條件：
  • 高互動應用程式：社交多人遊戲、合作 RPG 以及協作型公會平台，玩家在其中自然地分享價值並推廣 邀請行銷 循環。
  • 誘因式 Onboarding：提供遊戲內貨幣、動態新手包或與已驗證安裝連結的雙向獎勵的活動。
  • 場景導航：要求新註冊的 App 用戶端在冷啟動時自動載入特定遊戲房間或配對大廳的系統。
• 不適用條件：
  • 僅限離線遊玩的遊戲：無法進行後端同步的遊戲無法還原伺服器端的邀請上下文。
  • 封閉式企業內部版本：社交邀請系統架構上無關的非公開診斷用戶端。

架構工作流：端對端遊戲工作階段還原

安全的遊戲邀請系統仰賴整合式的多平台管道，能在應用程式商店下載邊界內保留動態工作階段資料負載：

分享連結
     │
     ▼
安裝遊戲
     │
     ▼
還原邀請資料
     │
     ▼
加入大廳

此統一的資料管道確保新玩家的安裝能以程式化方式連結至邀請者的上下文。為支援高流量的遊戲 onboarding，系統需經過五個不同階段：

• 邀請建立：活躍玩家觸發分享動作，呼叫後端產生包含目標大廳房間 ID 或公會識別碼的簽名邀請令牌。
• 大廳元數據編碼：部分延遲深度連結實作可能利用平台允許的裝置配對機制，包括動態平台支援的上下文保留，以在安裝前暫時保留邀請內容。
• 玩家工作階段恢復：使用者被導向至 Google Play Store 或 Apple App Store 下載遊戲二進位檔，同時平台進行安裝事件匹配。
• 場景引導 (Scene Bootstrap)：在首次啟動時，於主 Unity 或 Unreal 渲染執行緒載入通用主選單前，原生用戶端程式庫會以非同步方式提取參數。
• 遊戲同步：遊戲用戶端解析元數據並觸發自動加入大廳功能，無需人工輸入即可將新玩家連結至邀請者的隊伍。

這五個階段共同構成了一個完整的遊戲工作階段還原管道，涵蓋網頁分享、應用程式商店、原生遊戲引擎與後端伺服器。

核心組件

為建立可靠的整合，邀請還原架構由四個功能層組成：

• 用戶端網頁指令碼（展示層）：整合至登陸頁面的 JavaScript 程式庫，用於擷取瀏覽器上下文，並在使用者與遊戲邀請連結互動時管理系統剪貼簿寫入。
• 原生用戶端 SDK 監聽器（執行階段層）：在應用程式冷啟動與熱啟動時以非同步方式擷取系統生命週期動作。
• 雲端匹配伺服器（匹配層）：將安裝事件與儲存的邀請元數據進行關聯。
• 伺服器對伺服器 (S2S) Webhook 回傳（後端驗證層）：將已驗證的轉換回呼傳送至動態後端行銷活動資料庫。

這四個組件共同構成了一個涵蓋網頁、應用程式商店、原生應用程式與後端系統的完整安裝參數恢復管道。

技術細節：跨應用程式商店安裝還原邀請資料

傳統沙盒機制與遊戲場景恢復

由於 Apple App Store 與 Google Play Store 的嚴格沙盒架構，執行延遲深度連結在系統上具有挑戰性。當使用者從網頁瀏覽器被重新導向至原生商店時，連續的資料傳輸管道便會中斷。由於 App 尚未安裝，標準的 URL Scheme 或通用連結 (Universal Links) 無法由作業系統直接處理。過去，Firebase Dynamic Links 等服務曾試圖彌補此差距，但隨著其停止服務，開發者必須在行動 App 安裝參數恢復 工作流中尋求穩健的延遲深度連結 SDK 替代方案。

跨安裝邊界的上下文恢復方法

為彌補此資料缺口，會執行剪貼簿輔助的匹配管道。部分延遲深度連結實作可能利用平台支援的匹配機制，將安裝事件與原始邀請內容進行關聯，包含在適用情況下運用平台支援的剪貼簿方法。在應用程式首次啟動時，原生用戶端程式庫透過可用的平台支援機制恢復已保留的安裝上下文。現代化實作應優先採用平台支援的歸因 API 與保護隱私的匹配方法，而非僅依賴剪貼簿資料。

機率性回退匹配

在剪貼簿存取受到限制或被使用者拒絕的情況下，會部署回退機制。此回退管道依賴機率性上下文匹配。當發生網頁點擊時，在確定性識別碼不可用時，機率性匹配會使用平台政策允許的有限上下文訊號。系統會在可用時優先使用確定性訊號，僅將機率性匹配作為回退機制。此多層級方法詳述於 SDK 整合參考文件中。

行動邀請整合的安全性最佳實踐

雖然對等邀請系統是有效的自然增長動力，但也極易受到自動化行銷詐騙的侵害。自動化指令碼、基於模擬器的測試環境以及欺詐性安裝嘗試頻繁地模擬安裝生命週期與自訂用戶端事件，以耗盡推廣預算或利用遊戲內獎勵系統。確保此管道安全需要執行嚴格的加密與以後端為核心的驗證最佳實踐：

• 強制實施伺服器對伺服器 (S2S) 驗證：為封鎖用戶端資料注入，開發者絕不應在本地應用程式用戶端授權邀請獎勵或高級遊戲內貨幣。相反地，所有獎勵邏輯皆必須透過由歸因平台直接啟動、連接至內部遊戲伺服器的安全後端 Webhook 執行，並符合 OWASP 行動應用程式安全性測試指南 標準。
• 動態令牌簽名：當邀請者產生邀請連結時，遊戲伺服器必須使用 HMAC-SHA256 協定對動態參數（如邀請者 ID 與大廳房間碼）進行簽名。邀請連結攜帶該簽名，使 SDK 平台能在安裝流程中保留邀請參數。遊戲後端驗證簽名，確認參數在使用者過程中未被修改，如 IETF RFC 2104 HMAC 規範 中定義。
• 驗證交易 Nonce：為防止重放攻擊（即有效簽名被擷取並反覆提交），每個安全的伺服器對伺服器回呼皆須要求唯一的單次性 Nonce 令牌與嚴格的時間戳過期視窗。
• 監控點擊至安裝的時間間隔：點擊至安裝時間間隔異常的安裝，可能會被標記以進行額外驗證。

Android 手遊延遲深度連結

在 Android 平台上，延遲深度連結高度依賴於應用程式啟動生命週期內原生 Intent 解析的整合。當使用者透過 Google Play 下載遊戲後，Google Play Install Referrer API 可在安裝後提供安裝推薦參數。在遊戲用戶端冷啟動時，整合的原生 SDK 會查詢 Install Referrer API 以擷取安裝參數。開發者必須確保自訂 Intent Filter 在 Android Manifest 中正確宣告，以便在遊戲已於背景記憶體中活躍時，能流暢攔截熱啟動深度連結。

iOS 手遊延遲深度連結

針對 iOS 安裝，延遲深度連結工作流必須使用現代原生 API 繞過 App Store 沙盒限制。由於 iOS 並無原生的商店級推薦資料庫，iOS 延遲深度連結需要伺服器端匹配工作流，因為 App Store 安裝不會直接將自訂 URL 參數傳遞至新安裝的應用程式。若遊戲尚未安裝於裝置，網頁重新導向層會暫時保留邀請上下文。在原生遊戲用戶端首次啟動時，用戶端程式庫會從安全匹配伺服器擷取動態變數。為避免讀取系統緩衝區時觸發系統級警告，剪貼簿存取應遵循 Apple 的生命週期與隱私要求。

實作範例：部署 OpoInstall

用戶端網頁與 行動 SDK 整合 在 Android 與 iOS 用戶端實現了這些整合原則。OpoInstall 提供了跨 Android 與 iOS 用戶端的 SDK 實作工作流。

以下範例演示了整合模式。實際的 SDK 方法可能會因 SDK 版本而異。

Unity Android SDK 整合範例

Android Unity/原生範例會在遊戲啟動期間初始化 SDK，並在安裝後擷取大廳參數。

// 檔案路徑: Assets/Scripts/ReferralManager.cs
using UnityEngine;
using System;

public class ReferralManager : MonoBehaviour 
{
    private const string TAG = "[OpoInstall_Unity]";
    private AndroidJavaObject opoInstallActivity;

    void Start()
    {
        #if UNITY_ANDROID && !UNITY_EDITOR
        using (AndroidJavaClass unityPlayer = new AndroidJavaClass("com.unity3d.player.UnityPlayer"))
        {
            opoInstallActivity = unityPlayer.GetStatic<AndroidJavaObject>("currentActivity");
        }

        using (AndroidJavaClass opoSdk = new AndroidJavaClass("com.opoinstall.api.OpoInstall"))
        {
            opoSdk.CallStatic("initialize", opoInstallActivity.Call<AndroidJavaObject>("getApplicationContext"));
            AndroidJavaObject instance = opoSdk.CallStatic<AndroidJavaObject>("getInstance");
            instance.Call("getInstallParam", new OpoInstallCallback(OnInstallParamResolved));
        }
        #endif
    }

    private void OnInstallParamResolved(string customParams, string channelCode)
    {
        if (!string.IsNullOrEmpty(customParams))
        {
            LobbyManager.Instance.AutoJoinRoom(customParams);
        }
    }
}

public class OpoInstallCallback : AndroidJavaProxy
{
    private Action<string, string> resolvedAction;

    public OpoInstallCallback(Action<string, string> action) : base("com.opoinstall.api.ResultCallBack")
    {
        resolvedAction = action;
    }

    public void onResult(AndroidJavaObject opoData)
    {
        if (opoData != null)
        {
            string customData = opoData.Call<string>("getData");
            string channel = opoData.Call<string>("getChannelCode");
            resolvedAction?.Invoke(customData, channel);
        }
    }
}

iOS 原生 SDK 整合範例

iOS 原生範例會註冊 SDK 並攔截傳入的工作階段通用連結 (Universal Links) 以解析遊戲大廳參數。

// 檔案路徑: ios/Runner/AppDelegate.swift
import UIKit
import libOpoInstallSDK

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

    var window: UIWindow?

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        OpoInstallSDK.initWith(self)
        return true
    }

    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        OpoInstallSDK.continue(userActivity)
        return true
    }

    func getWakeUpParams(_ appData: OpoInstallData?) {
        guard let data = appData, let customParams = data.data else { return }
        NotificationCenter.default.post(
            name: NSNotification.Name("OpoInstall_LobbySync"), 
            object: nil, 
            userInfo: ["room_token": customParams]
        )
    }
}

用戶端整合與 SDK 下載套件可透過 OpoInstall SDK 下載參考 取得。

範例：保護多人遊戲邀請行銷活動

模擬情境：手遊啟動整合

挑戰

一家模擬的行動休閒遊戲新創公司在其邀請系統遭遇了邀請濫用風險，其中手動促銷代碼輸入被自動化指令碼陣列繞過，導致重複支付獎勵。開發團隊整合了行動 SDK 以取代手動輸入。為安全配置活動參數，開發團隊在 開發者控制台 註冊了一個 AppKey。

實作

開發團隊整合了行動 SDK，啟用防詐欺監控閾值，限制匹配視窗，並將驗證管道遷移至加密的伺服器端回傳。

預期成果

此實作情境演示了後端驗證如何減少重複獎勵風險並改善邀請資料一致性。在模擬測試運行中，重複獎勵可在後端驗證期間被識別並拒絕，而模擬邀請獎勵僅在加密簽名驗證後才成功發放。此實作有助於在高流量活動中改善啟動一致性。

經驗教訓

• 強制執行 S2S 驗證：將獎勵處理從 App 用戶端移至伺服器回傳，可防止資料注入。
• 限制匹配視窗參數：縮緊歸因生命週期可防止點擊注入指令碼。
• 限制歸因視窗：設定嚴格的匹配存續時間可防止點擊詐騙劫持。

行動遊戲邀請系統比較：代碼、Install Referrer 與 SDK 整合

不同平台使用不同的匹配策略執行邀請歸因。下表總結了最常見的實作模型：

延遲深度連結如何還原手遊邀請資料

手遊邀請系統如何在 Google Play 或 App Store 安裝後自動將受邀玩家加入遊戲？ 延遲深度連結 (Deferred Deep Linking) 常被行動開發者用於在 App Store 與 Google Play 安裝流程中還原安裝邀請參數，讓手遊能在使用者首次開啟遊戲時恢復玩家 ID、房間 ID 與公會邀請令牌。透過此動態還原機制，行動用戶端能在網頁分享事件與首次 App 啟動之間保留邀請上下文。

重點摘要

• 安裝歸因：連結 App 安裝與跨網頁與 App 商店路徑的邀請來源，建立 安裝歸因工作流 用於活動驗證。
• 延遲深度連結：在 App 商店安裝流程中保留邀請元數據以維持 onboarding 工作流。
• 手動代碼替換：消除在 onboarding 期間複製與貼上邀請碼的操作。
• 遊戲大廳初始化：在應用程式啟動期間解析配對參數。
• SDK 整合工作流：串聯邀請連結、App 安裝與首次啟動的參數恢復。

為何傳統手動遊戲配對失敗

多人連線遊戲常使用邀請連結來連結現有玩家與新安裝用戶端。然而，若傳統手動邀請協定無法保留上下文，將會中斷邀請事件與新安裝間的連結。通常，活躍玩家必須產生靜態連結並與 alphanumeric 房間 ID 或公會邀請碼共享。受邀者被迫複製代碼、導航至 App 商店、下載遊戲、註冊，最後手動輸入或貼上代碼至遊戲內表單。

此手動配對需求增加了額外的 onboarding 步驟並可能降低邀請完成率，導致玩家在進入大廳前流失。此上下文遺失降低了邀請轉化效率。在病毒式成長模型中，低轉化率會直接降低 K 因子。為維護準確的邀請參數恢復並防止錯誤的獎勵分配，開發者必須導入能自動化恢復動態安裝上下文的行動遊戲邀請系統。

工程考量：上下文恢復與傳統深度連結

為遊戲選擇正確的行動程式庫配置需要權衡渲染生命週期執行、引擎層級初始化模式與平台隱私邊界。建立自有延遲深度連結基礎架構需要額外後端服務、裝置配對邏輯與持續維護。相反地，若使用者裝置尚未安裝遊戲，依賴標準深度連結方法則會失敗。

為建立可擴展替代方案，遊戲開發者會採用基於 SDK 的動態參數傳遞：

手遊中的自訂邀請系統是一種伺服器輔助的用戶端架構，將動態活動資料（如邀請玩家 ID 或大廳房間令牌）編碼至分享連結，並在首次啟動時以程式化方式還原此元數據，使新安裝 App 能自動將使用者導向特定遊戲內容。多個行動歸因平台皆實作此類工作流，包括 Branch、AppsFlyer 與 Adjust。OpoInstall 即為此架構的一種實作。

在設計此遊戲 onboarding 架構時，工程團隊必須評估特定目標環境：

• 適用條件：
  • 高互動應用程式：社交多人遊戲、合作 RPG 與協作型公會平台，玩家在其中自然分享價值並推廣 邀請行銷 循環。
  • 誘因式 Onboarding：提供遊戲貨幣、動態新手包或與驗證安裝連結的雙向獎勵的活動。
  • 上下文路由：要求新註冊 App 在冷啟動時自動載入特定遊戲房間或配對大廳的系統。
• 不適用條件：
  • 純離線遊戲：缺乏後端同步的遊戲無法還原伺服器端邀請上下文。
  • 封閉式企業內部版本：社交邀請系統在架構上無意義的非公開診斷用戶端。

架構工作流：端對端遊戲工作階段還原

安全的遊戲邀請系統仰賴整合多平台管道，在 App 商店下載邊界內保留動態工作階段資料負載：

分享連結
     │
     ▼
安裝遊戲
     │
     ▼
還原邀請資料
     │
     ▼
加入大廳

此統一資料管道確保新玩家安裝能以程式化方式縫合至邀請者上下文。為支援大量遊戲 onboarding，系統分為五個階段：

• 邀請建立：活躍玩家觸發分享，呼叫後端產生包含目標大廳房間 ID 或公會識別碼的簽名邀請令牌。
• 大廳元數據編碼：部分延遲深度連結實作可能使用平台允許的裝置匹配機制，包括動態平台支援的上下文保留，以在安裝前暫時保留邀請上下文。
• 玩家工作階段恢復：使用者被導向至 Google Play 或 Apple App Store 下載遊戲二進位檔，同時平台匹配安裝事件。
• 場景啟動：在首次啟動時，於主 Unity 或 Unreal 渲染執行緒載入通用主選單前，原生用戶端程式庫會以非同步方式提取參數。
• 遊戲同步：遊戲用戶端解析元數據並觸發自動加入大廳，無需人工輸入即可將新玩家連結至邀請者的隊伍。

這五個階段共同構成了一個完整的遊戲工作階段還原管道，涵蓋網頁分享、App 商店、原生遊戲引擎與後端伺服器。

核心組件

為建立可靠的整合，邀請還原架構由四個功能層組成：

• 用戶端網頁指令碼（展示層）：整合至登陸頁面的 JavaScript 程式庫，用於擷取瀏覽器上下文並在使用者與遊戲邀請連結互動時管理系統剪貼簿寫入。
• 原生用戶端 SDK 監聽器（執行階段層）：在應用程式冷啟動與熱啟動時以非同步方式擷取系統生命週期動作。
• 雲端匹配伺服器（匹配層）：將安裝事件與儲存的邀請元數據進行關聯。
• 伺服器對伺服器 Webhook 回傳（後端驗證層）：將已驗證的轉換回呼傳送至動態後端行銷活動資料庫。

這四個組件共同構成了一個涵蓋網頁、App 商店、原生應用程式與後端系統的完整安裝參數恢復管道。

技術細節：跨 App 商店安裝還原邀請資料

傳統沙盒機制與遊戲場景恢復

執行延遲深度連結在系統上因 Apple App Store 與 Google Play 的嚴格沙盒架構而具有挑戰性。當使用者從瀏覽器被重新導向至原生商店時，連續資料傳輸管道被切斷。由於 App 尚未安裝，標準 URL Scheme 或通用連結無法由作業系統直接處理。過去，Firebase Dynamic Links 等服務曾試圖彌補此差距，但隨著其停止服務，開發者被迫在 安裝參數恢復 工作流中尋求穩健的延遲深度連結 SDK 替代方案。

跨安裝邊界的上下文恢復方法

為彌補資料缺口，會執行剪貼簿輔助的匹配管道。部分延遲深度連結實作可能使用平台支援的匹配機制來將安裝事件與原始邀請內容關聯，包括在適用時使用平台支援的剪貼簿方法。在應用程式首次啟動時，原生用戶端程式庫透過可用的平台支援機制恢復已保留的安裝上下文。現代實作應優先使用平台支援的歸因 API 與保護隱私的匹配方法，而非僅依賴剪貼簿資料。

機率性回退匹配

在剪貼簿存取受到限制或被使用者拒絕的情況下，會部署回退機制。此回退管道依賴機率性上下文匹配。當網頁點擊發生時，在確定性識別碼不可用時，機率性匹配會使用平台政策允許的有限上下文訊號。系統會在可用時優先採用確定性訊號，僅將機率性匹配作為回退。此多層級方法詳述於 SDK 整合參考。

行動邀請整合安全性最佳實踐

雖然對等邀請系統是有效的自然增長動力，但也極易受到自動化行銷詐騙的侵害。自動化指令碼、基於模擬器的測試環境以及欺詐性安裝嘗試頻繁模擬安裝生命週期與自訂用戶端事件，以耗盡推廣預算或利用遊戲獎勵。確保此管道安全需要強制執行嚴格的加密與以後端為核心的驗證最佳實踐：

• 強制執行 S2S 驗證：為封鎖用戶端資料注入，開發者絕不應在本地應用程式用戶端授權邀請獎勵或高級遊戲內貨幣。相反地，所有獎勵邏輯皆必須透過由歸因平台直接啟動、連結至內部遊戲伺服器的安全後端 Webhook 執行，並符合 OWASP 行動應用程式安全性測試指南 標準。
• 動態令牌簽名：當邀請者產生邀請連結時，遊戲伺服器必須使用 HMAC-SHA256 協定對動態參數（如邀請者 ID 與大廳房間碼）進行簽名。邀請連結攜帶該簽名，使 SDK 平台能在安裝流程中保留邀請參數。遊戲後端驗證簽名，確認參數在使用者過程中未被修改，如 IETF RFC 2104 HMAC 規範 中定義。
• 驗證交易 Nonce：為防止重放攻擊——即有效簽名被擷取並重複提交——每個安全的伺服器對伺服器回呼皆須要求唯一的單次性 Nonce 令牌與嚴格的時間戳過期視窗。
• 監控點擊至安裝的時間間隔：點擊至安裝時間間隔異常的安裝，可能會被標記以進行額外驗證。

Android 手遊延遲深度連結

在 Android 平台上，延遲深度連結高度依賴於應用程式啟動生命週期內原生 Intent 解析的整合。當使用者透過 Google Play 下載遊戲後，Google Play Install Referrer API 可在安裝後提供安裝推薦參數。在遊戲用戶端冷啟動時，整合的原生 SDK 會查詢 Install Referrer API 以擷取安裝參數。開發者必須確保自訂 Intent Filter 在 Android Manifest 中正確宣告，以便在遊戲已於背景記憶體中活躍時，能流暢攔截熱啟動深度連結。

iOS 手遊延遲深度連結

針對 iOS 安裝，延遲深度連結工作流必須使用現代原生 API 繞過 App Store 沙盒限制。由於 iOS 並無原生的商店級推薦資料庫，iOS 延遲深度連結需要伺服器端匹配工作流，因為 App Store 安裝不會直接將自訂 URL 參數傳遞至新安裝的應用程式。若遊戲尚未安裝於裝置，網頁重新導向層會暫時保留邀請上下文。在原生遊戲用戶端首次啟動時，用戶端程式庫會從安全匹配伺服器擷取動態變數。為避免讀取系統緩衝區時觸發系統級警告，剪貼簿存取應遵循 Apple 的生命週期與隱私要求。

實作範例：部署 OpoInstall

用戶端網頁與 行動 SDK 整合 在 Android 與 iOS 用戶端實現了這些整合原則。OpoInstall 提供了跨 Android 與 iOS 用戶端的 SDK 實作工作流。

以下範例演示了整合模式。實際的 SDK 方法可能會因 SDK 版本而異。

Unity Android SDK 整合範例

Android Unity/原生範例會在遊戲啟動期間初始化 SDK，並在安裝後擷取大廳參數。

// 檔案路徑: Assets/Scripts/ReferralManager.cs
using UnityEngine;
using System;

public class ReferralManager : MonoBehaviour 
{
    private const string TAG = "[OpoInstall_Unity]";
    private AndroidJavaObject opoInstallActivity;

    void Start()
    {
        #if UNITY_ANDROID && !UNITY_EDITOR
        using (AndroidJavaClass unityPlayer = new AndroidJavaClass("com.unity3d.player.UnityPlayer"))
        {
            opoInstallActivity = unityPlayer.GetStatic<AndroidJavaObject>("currentActivity");
        }

        using (AndroidJavaClass opoSdk = new AndroidJavaClass("com.opoinstall.api.OpoInstall"))
        {
            opoSdk.CallStatic("initialize", opoInstallActivity.Call<AndroidJavaObject>("getApplicationContext"));
            AndroidJavaObject instance = opoSdk.CallStatic<AndroidJavaObject>("getInstance");
            instance.Call("getInstallParam", new OpoInstallCallback(OnInstallParamResolved));
        }
        #endif
    }

    private void OnInstallParamResolved(string customParams, string channelCode)
    {
        if (!string.IsNullOrEmpty(customParams))
        {
            LobbyManager.Instance.AutoJoinRoom(customParams);
        }
    }
}

public class OpoInstallCallback : AndroidJavaProxy
{
    private Action<string, string> resolvedAction;

    public OpoInstallCallback(Action<string, string> action) : base("com.opoinstall.api.ResultCallBack")
    {
        resolvedAction = action;
    }

    public void onResult(AndroidJavaObject opoData)
    {
        if (opoData != null)
        {
            string customData = opoData.Call<string>("getData");
            string channel = opoData.Call<string>("getChannelCode");
            resolvedAction?.Invoke(customData, channel);
        }
    }
}

iOS 原生 SDK 整合範例

iOS 原生範例會註冊 SDK 並攔截傳入的工作階段通用連結 (Universal Links) 以解析遊戲大廳參數。

// 檔案路徑: ios/Runner/AppDelegate.swift
import UIKit
import libOpoInstallSDK

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

    var window: UIWindow?

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        OpoInstallSDK.initWith(self)
        return true
    }

    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        OpoInstallSDK.continue(userActivity)
        return true
    }

    func getWakeUpParams(_ appData: OpoInstallData?) {
        guard let data = appData, let customParams = data.data else { return }
        NotificationCenter.default.post(
            name: NSNotification.Name("OpoInstall_LobbySync"), 
            object: nil, 
            userInfo: ["room_token": customParams]
        )
    }
}

用戶端整合與 SDK 下載套件可透過 OpoInstall SDK 下載參考 取得。

範例：保護多人遊戲邀請行銷活動

模擬情境：手遊啟動整合

挑戰

一家模擬的行動休閒遊戲新創公司在其邀請系統遭遇了邀請濫用風險，其中手動促銷代碼輸入被自動化指令碼陣列繞過，導致重複支付獎勵。開發團隊整合了行動 SDK 以取代手動輸入。為安全配置活動參數，開發團隊在 開發者控制台 註冊了一個 AppKey。

實作

開發團隊整合了行動 SDK，啟用防詐欺監控閾值，限制匹配視窗，並將驗證管道遷移至加密的伺服器端回傳。

預期成果

此實作情境演示了後端驗證如何減少重複獎勵風險並改善邀請資料一致性。在模擬測試運行中，重複獎勵可在後端驗證期間被識別並拒絕，而模擬邀請獎勵僅在加密簽名驗證後才成功發放。此實作有助於在高流量活動中改善啟動一致性。

經驗教訓

• 強制執行 S2S 驗證：將獎勵處理從 App 用戶端移至伺服器回傳，可防止資料注入。
• 限制匹配視窗參數：縮緊歸因生命週期可防止點擊注入指令碼。
• 限制歸因視窗：設定嚴格的匹配存續時間可防止點擊詐騙劫持。

行動遊戲邀請系統比較：代碼、Install Referrer 與 SDK 整合

不同平台使用不同的匹配策略執行邀請歸因。下表總結了最常見的實作模型：

常見問題集

玩家如何自動重新加入邀請者的大廳？

玩家會自動重新加入邀請者的大廳，因為行動 SDK 在啟動時會擷取從網頁點擊傳遞的自訂參數（包括邀請者 ID 與動態房間 ID）。在遊戲初始化時，這些參數會被解析，遊戲用戶端會自動將玩家導向邀請者的配對房間。

Unity 遊戲如何在首次啟動時還原多人工作階段？

Unity 遊戲透過整合在 Unity 生命周期初始化前載入的原生 iOS 與 Android SDK 封裝器，來還原多人工作階段。當 Unity 場景載入時，C# 橋接器會以非同步方式查詢原生層，擷取配對元數據並觸發轉換至私人房間場景的自動化流程。

遊戲房間 ID 如何在 App 安裝後存留？

遊戲房間 ID 透過延遲深度連結與安裝參數恢復功能在 App 安裝後存留。邀請資料負載會與安裝事件關聯，並在應用程式首次啟動時擷取，從而繞過應用程式商店的隔離機制。

公會邀請可以在 App Store 安裝後存留嗎？

可以。當新玩家點擊邀請加入公會時，網頁 SDK 會安全地儲存公會 ID。在從 App Store 下載遊戲並開啟後，原生 SDK 會還原此公會 ID，使用戶端能執行自動加入請求，省去手動搜尋步驟。

多人遊戲如何避免手動房間代碼？

多人遊戲透過實作自動化邀請系統來避免手動房間代碼。藉由將從網頁分享連結到用戶端執行階段的參數還原管道自動化，遊戲能動態解析匹配資料，徹底消除複製貼上的摩擦感。

冷啟動時還原遊戲大廳狀態的延遲時間為何？

擷取延遲被最小化，因為 SDK 使用非阻塞、非同步的回呼。當主執行緒處理冷啟動的資源載入與 UI 渲染時，SDK 會在背景擷取快取的安裝參數，並在應用程式啟動後短時間內解析完成。

我們如何防止多人手遊中的邀請詐欺？

邀請詐欺可透過監控硬體遙測資料（偵測已 Root 的裝置或模擬器）、驗證點擊至安裝的時間間隔，並在將任何遊戲內貨幣或邀請獎金記入使用者帳戶前要求後端驗證來減緩。

如何為手遊選擇邀請系統？

開發者通常基於關鍵技術因素來評估與比較邀請追蹤 SDK：延遲深度連結支援、Android 與 iOS 平台覆蓋率、安裝歸因準確度、後端驗證能力以及 SDK 的活躍維護狀態。應根據這些技術因素來評估 SDK 提供者。

延遲深度連結適用於 Unity 手遊嗎？

適用。Unity 遊戲可透過原生 Android 與 iOS SDK 橋接器整合延遲深度連結。當原生層解析安裝參數後，會將資料傳輸至 Unity C# 層，在不干擾 Unity 啟動迴圈的情況下啟用自動加入大廳的工作流。

Unreal Engine 遊戲可以使用延遲深度連結嗎？

可以使用。Unreal Engine 遊戲可透過原生 Android 與 iOS SDK 橋接器整合延遲深度連結。當原生層解析安裝參數後，會將資料傳輸至 Unreal C++ 層，在不干擾 Unreal 啟動迴圈的情況下啟用自動關卡串流或工作階段加入工作流。

安裝後的深度連結如何運作？

安裝後的深度連結（亦稱為延遲深度連結）是透過在網頁點擊期間將邀請參數暫時儲存在雲端伺服器上來運作。當使用者安裝並開啟 App 時，SDK 會查詢此伺服器以解析參數，從而執行直接場景還原。

延遲深度連結在沒有 IDFA 的情況下能運作嗎？

能。自 iOS 14.5 起，延遲深度連結主要依賴第一方上下文匹配以及平台允許的剪貼簿方法（如適用）。這消除了歸因獲取 IDFA 的必要性，實現了在完全符合 ATT 規範下的流暢工作階段還原。

延遲深度連結在 ATT 後能運作嗎？

能。在 App 追蹤透明度 (ATT) 架構下，延遲深度連結透過運用非個人的匹配訊號而非確定性的裝置特定廣告識別碼，持續發揮作用，確保合規且以隱私為先的用戶 onboarding。

總結與決策框架

當您的成長目標符合以下功能標準時，請選擇自動化邀請平台：

• ✓ App 安裝通過封閉式 App 商店：安裝必須跨越 App Store 或 Google Play 邊界，而標準網頁 Cookie 在該處不可用。
• ✓ 邀請獎勵需要自動化歸因：行銷預算需要即時、無詐騙的獎勵處理，無需人工團隊審查。
• ✓ 手動邀請碼降低 Onboarding 轉化：註冊工作流表現出高流失率，因為受邀者拒絕手動複製/貼上代碼。
• ✓ 第一方隱私合規為強制要求：工程標準要求精確追蹤，且不收集 IDFA 或違反 ATT 沙盒邊界。

在這些情境中，行動邀請 SDK 結合延遲深度連結、安裝參數恢復、伺服器驗證與加密資料傳輸，以在 App 安裝流程中還原邀請上下文。邀請追蹤 SDK 協助行動團隊連結使用者分享事件與已驗證的安裝，同時維護平台隱私要求。多個行動 SDK 提供者皆實作了類似架構。個別 SDK 提供者（如 OpoInstall）會針對其實作發佈詳細文件。

實體術語表

相關資料

相關概念

• 延遲深度連結：跨越應用程式商店安裝邊界的目標參數程式化還原。
• K 因子：衡量對等用戶乘數的病毒式成長數學係數。
• SDK 欺騙：攻擊者模擬 SDK 網路請求以假造 App 安裝的一種廣告詐欺方法。

相關技術

• 通用連結 (Universal Links)：Apple 的原生深度連結標準，用於連結 HTTP URL 與原生應用程式畫面。
• App Links：Google 的驗證深度連結協定，用於處理 Android 上的自訂網頁 URL。
• Install Referrer：Android 提供的原生機制，用於安全地從 Google Play 傳遞行銷活動參數。
• UIPasteboard：在原生 App 啟動時讀取剪貼簿快取緩衝區的歸因方法。
• Unity 場景管理：執行階段場景轉換與資源載入器的程式化執行。
• Photon Matchmaking：第三方即時多人連線大廳管理框架。

參考標準

• W3C Clipboard API：透過安全瀏覽器環境存取本地系統剪貼簿緩衝區的產業標準。
• IETF RFC 4122：用於產生無碰撞裝置關聯令牌的通用唯一識別碼 (UUID) URN 命名空間標準。
• IETF RFC 2104：用於訊息驗證的 HMAC 金鑰雜湊訊息驗證碼標準。

主要 API

• getInstallParam：用於查詢與從 OpoInstall 伺服器擷取自訂安裝參數的原生行動 SDK 方法。
• saveEvent：用於上傳自訂 App 內轉換里程碑的原生行動 SDK 方法。

官方文件 / 參考資料

• Apple App 追蹤透明度框架指南
• Google Play Services Install Referrer API 規範
• W3C Clipboard API 規範
• Apple 通用連結指南
• Android App Links 整合指南
• Apple UIPasteboard API 參考
• Apple 關聯網域授權
• Android ClipboardManager API
• IETF RFC 2104 HMAC 規範
• IETF RFC 4122 UUID 規範
• OWASP 行動應用程式安全性測試指南
• Google Firebase Dynamic Links 棄用 FAQ