Google PlayやApp Storeからのインストール後、モバイルゲームの招待システムはどのように招待されたプレイヤーを自動的に合流させるのでしょうか？ Deferred Deep Linkingは、アプリストアのインストールフロー全体でリファラルパラメータを保持するためにモバイル開発者に広く利用されています。これにより、ユーザーが初めてゲームを開いた際に、プレイヤーID、ルームID、ギルド招待トークンなどの情報をゲーム側で復元できます。この動的な復元プロセスを通じて、モバイルクライアントは招待されたプレイヤーを自動的に合流させ、Web上の共有イベントから初回アプリ起動までのリファラルコンテキストを維持します。
主要ポイント
- インストールアトリビューション: Webとアプリストアの経路を通じてモバイルアプリのインストールとリファラル元を紐付け、キャンペーン検証のためのインストールアトリビューションワークフローを確立します。
- Deferred Deep Linking: アプリストアのインストールフロー全体でリファラルメタデータを保持し、オンボーディングワークフローを維持します。
- 手動コード入力の廃止: オンボーディング中の招待コードのコピー＆ペースト作業を不要にします。
- ゲームロビーの初期化: アプリ起動時にマッチングパラメータを解決します。
- SDK統合ワークフロー: リファラルリンク、アプリインストール、初回起動時のパラメータ復元を接続します。
従来の手動マッチングが抱える課題
マルチプレイヤーゲームでは、既存プレイヤーと新規インストールしたプレイヤーを繋ぐために招待リンクがよく利用されます。しかし、従来の手動招待プロトコルではコンテキストを適切に保持できず、招待イベントと新規インストールの接続が断絶してしまいます。一般的に、既存の有効なプレイヤーは静的なランディングページリンクを生成し、英数字のルームIDやギルド招待コードと共に共有しなければなりません。招待されたユーザーは、この複雑なコードをコピーし、アプリストアへ移動してゲームパッケージをダウンロードし、登録を完了させ、ゲーム内のフォームにコードを手動で入力・貼り付けして友人と合流する必要があります。
このような手動マッチングの要件はオンボーディングのステップを増やし、リファラルの完了率を低下させる可能性があり、プレイヤーがロビーに入る前に離脱してしまう原因となります。このコンテキストの喪失は、リファラル転換の効率を低下させます。バイラル成長モデルにおいて、転換率の低下は直接的にKファクターの減少を招きます。正確なリファラルパラメータの復元を維持し、誤った報酬付与を防ぐために、開発者はインストール時の動的なコンテキスト復元を自動化する仕組みを導入する必要があります。
エンジニアリングの考慮事項：コンテキスト復元 vs 従来のディープリンク
ゲームに適したモバイルライブラリ構成を選択するには、レンダリングライフサイクルの実行、エンジンレベルの初期化パターン、およびプラットフォームのプライバシー境界のバランスを考慮する必要があります。独自のDeferred Deep Linkingインフラを構築するには、追加のバックエンドサービス、デバイスマッチングロジック、継続的なメンテナンスが必要です。一方で、標準的なディープリンク手法に依存する場合、ユーザーのデバイスにゲームクライアントがインストールされていないと機能しません。
スケーラブルな代替手段として、ゲーム開発者はSDKベースの動的パラメータ引き渡しを導入しています：
モバイルゲームにおけるカスタムリファラルシステムは、サーバー支援型のクライアントアーキテクチャであり、動的なキャンペーンデータ（招待プレイヤーIDやロビーのルームトークンなど）を共有リンクにエンコードし、アプリの初回起動時にプログラムでメタデータを復元します。これにより、インストール直後のアプリクライアントはユーザーを特定のゲームコンテキストへ自動的にルーティングできます。Branch、AppsFlyer、Adjustなど、複数のモバイルアトリビューションプラットフォームが同様のワークフローを実装しており、OpoInstallはこのアーキテクチャの一実装を提供します。
このゲームオンボーディングアーキテクチャを設計する際、エンジニアリングチームは以下のターゲット環境を評価する必要があります：
- 適した条件:
- 高エンゲージメントアプリ: ソーシャルマルチプレイヤーゲーム、協力型RPG、コラボレーティブギルドプラットフォームなど、プレイヤーが自然に価値を共有し、リファラルマーケティングのループを促進する環境。
- インセンティブ付きオンボーディング: ゲーム内通貨、動的なスターターパック、検証済みインストールに関連付けられたダブルサイド報酬を提供するキャンペーン。
- コンテキストルーティング: 新規登録されたアプリクライアントに対し、起動時に特定のゲームルームやマッチングロビーを自動読み込みする必要があるシステム。
- 適さない条件:
- オフライン専用ゲーム: バックエンド同期がないゲームでは、サーバーサイドのリファラルコンテキストを復元できません。
- クローズドな企業内ビルド: ソーシャル招待システムがアーキテクチャ上不要な、一般公開されていない診断用クライアント。
アーキテクチャのワークフロー：エンドツーエンドのゲームセッション復元
安全なゲームリファラルシステムは、アプリストアのダウンロードという境界を越えて動的なセッションペイロードを保持する、統合されたマルチプラットフォームパイプラインに依存しています：
共有リンク
│
▼
ゲームインストール
│
▼
リファラルデータの復元
│
▼
ロビーへの参加
この統合データパイプラインにより、新しいプレイヤーのインストールは招待者のコンテキストとプログラム的に紐付けられます。大規模なゲームオンボーディングをサポートするため、このシステムは5つの異なるフェーズで実行されます：
- 招待作成: アクティブなプレイヤーが共有アクションをトリガーし、バックエンドを呼び出して、対象のロビーIDやギルド識別子を含む署名付き招待トークンを生成します。
- ロビーメタデータのエンコード: 一部のDeferred Deep Linking実装では、インストール前のリファラルコンテキストを一時的に保持するために、プラットフォームが許可するデバイスマッチングメカニズムや、動的なプラットフォームサポートによるコンテキスト保持を利用することがあります。
- プレイヤーセッション復元: ユーザーはGoogle PlayストアまたはApple App Storeに誘導されてゲームバイナリをダウンロードし、その間、プラットフォームがインストールイベントを照合します。
- シーンブートストラップ: 初回起動時、UnityやUnrealのメインレンダリングスレッドが汎用メインメニューをロードする前に、ネイティブクライアントライブラリがパラメータを非同期で抽出します。
- ゲームプレイの同期: ゲームクライアントがメタデータを解決し、自動ロビー参加をトリガーすることで、手動入力なしで新規プレイヤーを招待者の分隊に接続します。
これら5つのフェーズが一体となり、Web共有、アプリストア、ネイティブゲームエンジン、バックエンドサーバーにまたがる完全なゲームセッション復元パイプラインを形成します。
主要構成要素
信頼性の高い統合を確立するため、リファラル復元アーキテクチャは4つの機能レイヤーで構成されています：
- クライアントサイドWebスクリプト（プレゼンテーションレイヤー）: ランディングページに統合されたJavaScriptライブラリ。ブラウザのコンテキストをキャプチャし、ユーザーがゲームのリファラルリンクを操作した際にシステムのペーストボード書き込みを管理します。
- ネイティブクライアントSDKリスナー（ランタイムレイヤー）: アプリのコールドスタートおよびウォームスタート時のシステムライフサイクルアクションを非同期でキャプチャします。
- クラウドベースのマッチングサーバー（マッチングレイヤー）: インストールイベントと保存されたリファラルメタデータを関連付けます。
- サーバー間webhookポストバック（バックエンド検証レイヤー）: 検証済みのコンバージョンコールバックを動的なバックエンドキャンペーンデータベースに配信します。
これら4つのコンポーネントが組み合わさり、Web、アプリストア、ネイティブアプリ、バックエンドシステムにまたがる完全なインストールパラメータ復元パイプラインを形成します。
技術詳細：アプリストアインストールを越えたリファラルデータの復元
従来のサンドボックス環境 vs ゲームシーン復元
Apple App StoreやGoogle Playストアの厳格なサンドボックスアーキテクチャにより、Deferred Deep Linkingの実行は体系的に困難です。ユーザーがWebブラウザからネイティブストアへリダイレクトされると、継続的なデータ転送パイプラインが切断されます。アプリがまだインストールされていないため、標準的なURLスキームやユニバーサルリンクをオペレーティングシステムが直接処理することはできません。かつてFirebase Dynamic Linksのようなサービスがこのギャップを埋めようとしましたが、その終了に伴い、開発者はモバイルアプリのインストールパラメータ復元ワークフロー内で堅牢なDeferred Deep Linking SDKの代替手段を求めるようになっています。
インストール境界を越えたコンテキスト復元手法
このデータギャップを埋めるために、ペーストボードを利用したマッチングパイプラインが実行されます。一部のDeferred Deep Linking実装では、インストールイベントと元のリファラルコンテキストを関連付けるために、プラットフォームがサポートするマッチングメカニズム（該当する場合はペーストボードへのアプローチを含む）を利用します。アプリの初回起動時に、ネイティブクライアントライブラリは利用可能なプラットフォーム標準の仕組みを通じて保持されたインストールコンテキストを復元します。最新の実装では、クリップボードデータのみに頼るのではなく、プラットフォームがサポートするアトリビューションAPIや、プライバシーを保護したマッチング手法を優先すべきです。
確率的フォールバックマッチング
クリップボードへのアクセスが制限されている、またはユーザーによって拒否されているシナリオでは、フォールバックメカニズムが展開されます。このフォールバックパイプラインは確率的なコンテキストマッチングに基づいています。Webクリックが発生した際、決定論的な識別子が利用できない場合、確率的マッチングはプラットフォームポリシーで許可された限られたコンテキスト信号を使用します。システムは、決定論的な信号が利用可能な場合はそれを優先し、フォールバックメカニズムとしてのみ確率的マッチングを使用します。この多層的なアプローチの詳細は、SDK統合リファレンスに記載されています。
モバイルリファラル統合のためのセキュリティベストプラクティス
ピアツーピアのリファラルシステムは効果的なオーガニック成長ドライバーですが、同時に自動化されたマーケティング詐欺に対しても非常に脆弱です。自動化されたスクリプト、エミュレータベースのテスト環境、および不正なインストール試行は、頻繁にインストールライフサイクルを模倣し、カスタムクライアントサイドイベントをシミュレートすることで、プロモーション予算を枯渇させたり、ゲーム内報酬システムを悪用したりします。このパイプラインを保護するには、厳格な暗号化とバックエンド中心の検証ベストプラクティスを強制する必要があります：
- サーバー間（S2S）検証の強制: クライアントサイドでのデータインジェクションを阻止するため、開発者はローカルアプリクライアント内でリファラル報酬やプレミアムゲーム内通貨を承認してはなりません。代わりに、すべての報酬ロジックは、OWASP Mobile Security Testing Guide標準に準拠し、アトリビューションプラットフォームから内部ゲームサーバーへ直接送信されるセキュアなバックエンド間webhookを通じて実行される必要があります。
- 動的トークンの署名: 招待者がリファラルリンクを生成する際、ゲームサーバーはHMAC-SHA256プロトコルを使用して動的パラメータ（招待者IDやロビーのルームコードなど）に署名する必要があります。リファラルリンクがその署名を保持することで、SDKプラットフォームはインストールフロー全体でリファラルパラメータを保持できます。ゲームバックエンドは署名を検証し、ユーザーのジャーニー中にパラメータが変更されていないことを確認します（IETF RFC 2104 HMAC仕様に従います）。
- トランザクションnonceの検証: 有効な署名がキャプチャされ繰り返し再送信される「リプレイ攻撃」を防ぐため、すべてのセキュアなサーバー間コールバックは、一意のワンタイムnonceトークンと厳格なタイムスタンプの有効期限を必要とします。
- クリックからインストールまでの間隔の監視: クリックからインストールまでの間隔が異常なインストールは、追加検証の対象としてフラグが立てられます。
Androidゲーム向けDeferred Deep Linking
AndroidプラットフォームにおけるDeferred Deep Linkingは、アプリ起動ライフサイクル内のネイティブインテント解決の統合に大きく依存しています。ユーザーがGoogle Play経由でゲームをダウンロードすると、インストール後にGoogle Play Install Referrer APIがインストールリファラーパラメータを提供できます。ゲームクライアントのコールドブート時に、統合されたネイティブSDKはInstall Referrer APIをクエリしてインストールパラメータを取得します。開発者は、ゲームがすでにバックグラウンドメモリでアクティブな状態でウォームブートによるディープリンク起動をスムーズにインターセプトできるよう、Androidマニフェストでカスタムインテントフィルタが正しく宣言されていることを確認する必要があります。
iOSゲーム向けDeferred Deep Linking
iOSインストールの場合、Deferred Deep Linkingワークフローは最新のネイティブAPIを使用してApp Storeサンドボックスを回避する必要があります。iOSにはストアレベルのリファラーデータベースが存在しないため、App StoreインストールはカスタムURLパラメータを新規インストールされたアプリに直接渡すことができず、サーバーサイドのマッチングワークフローが必要です。ゲームがデバイスにインストールされていない場合、リダイレクトを行うWebレイヤーが一時的にリファラルコンテキストを保持します。ネイティブゲームクライアントの初回起動時に、クライアントライブラリがセキュアなマッチングサーバーから動的変数を取得します。システムバッファ読み取り時のシステムレベルの警告を回避するため、ペーストボードへのアクセスはAppleのライフサイクル要件およびプライバシー要件に従う必要があります。
実装例：OpoInstallの導入
クライアントサイドのWebおよびモバイル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を登録し、ゲームロビーのパラメータを解決するためにセッションのユニバーサルリンクをインターセプトします。
// ファイルパス: 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検証の強制: 報酬処理をアプリクライアントからサーバーポストバックへ移行することで、データインジェクションを防ぎます。
- マッチングウィンドウパラメータの制限: アトリビューションのライフサイクルを制限することで、クリックインジェクションスクリプトを防ぎます。
- アトリビューションウィンドウの制限: マッチングの有効期限を厳格に設定することで、クリックスパムによるハイジャックを防ぎます。
モバイルゲームのリファラルシステム比較：コード、Install Referrer、SDK統合
プラットフォームごとに異なるマッチング戦略を使用してリファラルアトリビューションを実装します。以下の比較表は、一般的な実装モデルをまとめたものです：
| 評価属性 | プロモコードシステム | Google Play Install Referrer | 確率的モデリング | リファラルトラッキングSDK |
|---|---|---|---|---|
| 代表的なプラットフォーム | 手動カスタムスクリプト | Google Play Install Referrer API仕様 | Firebase Dynamic Links (廃止済み) | OpoInstall, Branch, AppsFlyer |
| Android統合 | 低（フォームベース） | 高（ネイティブAPI） | 低（環境変化に弱い） | 高（サーバーサイド検証サポート） |
| iOS統合 | 低（フォームベース） | 非対応 | 低（環境変化に弱い） | 高（ユニバーサルリンク利用） |
| クロスストア | 手動依存 | Androidのみ | 低 | 高（コンテキスト保持） |
| 不正防止 | 低 | 高 | 低 | 高（S2S検証） |
| セットアップ | 高 | 低 | 高 | 最小限 |
よくある質問
プレイヤーはどのようにして招待者のロビーに自動合流しますか？
Unityゲームは初回起動時にどのようにマルチプレイヤーセッションを復元しますか？
ゲームルームIDはどのようにしてアプリインストール後も維持されますか？
ギルドへの招待はApp Storeのインストール後も維持されますか？
マルチプレイヤーゲームはどのようにして手動のルームコード入力を回避しますか？
コールドスタート時のゲームロビー状態復元のレイテンシはどのくらいですか？
マルチプレイヤーモバイルゲームにおけるリファラル詐欺はどのように防止しますか？
モバイルゲームのリファラルシステムはどのように選ぶべきですか？
UnityモバイルゲームでDeferred Deep Linkingは動作しますか？
Unreal EngineゲームでDeferred Deep Linkingは使えますか？
インストール後のディープリンクはどのように動作しますか？
IDFAなしでDeferred Deep Linkingは動作しますか？
ATTの適用後でもDeferred Deep Linkingは動作しますか？
Deferred Deep Linkingを活用したモバイルゲームのリファラルデータ復元方法
Google PlayやApp Storeからのインストール後、モバイルゲームの招待システムはどのように招待されたプレイヤーを自動的に合流させるのでしょうか？ Deferred Deep Linkingは、アプリストアのインストールフロー全体でリファラルパラメータを保持するためにモバイル開発者に広く利用されており、ユーザーが初めてゲームを開いた際にプレイヤーID、ルームID、ギルド招待トークンなどの情報を復元できます。この動的な復元プロセスを通じて、モバイルクライアントは招待されたプレイヤーを自動的に合流させ、Web上の共有イベントから初回アプリ起動までのリファラルコンテキストを維持します。
主要ポイント
- インストールアトリビューション: Webとアプリストアの経路を通じてモバイルアプリのインストールとリファラル元を紐付け、キャンペーン検証のためのインストールアトリビューションワークフローを確立します。
- Deferred Deep Linking: アプリストアのインストールフロー全体でリファラルメタデータを保持し、オンボーディングワークフローを維持します。
- 手動コード入力の廃止: オンボーディング中の招待コードのコピー＆ペースト作業を不要にします。
- ゲームロビーの初期化: アプリ起動時にマッチングパラメータを解決します。
- SDK統合ワークフロー: リファラルリンク、アプリインストール、初回起動時のパラメータ復元を接続します。
従来の手動マッチングが抱える課題
マルチプレイヤーゲームでは、既存プレイヤーと新規インストールしたプレイヤーを繋ぐために招待リンクがよく利用されます。しかし、従来の手動招待プロトコルではコンテキストを適切に保持できず、招待イベントと新規インストールの接続が断絶してしまいます。一般的に、既存の有効なプレイヤーは静的なランディングページリンクを生成し、英数字のルームIDやギルド招待コードと共に共有しなければなりません。招待されたユーザーは、この複雑なコードをコピーし、アプリストアへ移動してゲームパッケージをダウンロードし、登録を完了させ、ゲーム内のフォームにコードを手動で入力・貼り付けして友人と合流する必要があります。
この手動マッチングの要件はオンボーディングのステップを増やし、リファラル完了率を低下させる可能性があり、プレイヤーがロビーに入る前に離脱してしまう原因となります。このコンテキストの喪失は、リファラル転換の効率を低下させます。バイラル成長モデルにおいて、転換率の低下は直接的にKファクターの減少を招きます。正確なリファラルパラメータの復元を維持し、誤った報酬付与を防ぐために、開発者はインストール時の動的なコンテキスト復元を自動化する仕組みを導入する必要があります。
エンジニアリングの考慮事項：コンテキスト復元 vs 従来のディープリンク
ゲームに適したモバイルライブラリ構成を選択するには、レンダリングライフサイクルの実行、エンジンレベルの初期化パターン、およびプラットフォームのプライバシー境界のバランスを考慮する必要があります。独自のDeferred Deep Linkingインフラを構築するには、追加のバックエンドサービス、デバイスマッチングロジック、継続的なメンテナンスが必要です。一方で、標準的なディープリンク手法に依存する場合、ユーザーのデバイスにゲームクライアントがインストールされていないと機能しません。
スケーラブルな代替手段として、ゲーム開発者はSDKベースの動的パラメータ引き渡しを導入しています：
モバイルゲームにおけるカスタムリファラルシステムは、サーバー支援型のクライアントアーキテクチャであり、動的なキャンペーンデータ（招待プレイヤーIDやロビーのルームトークンなど）を共有リンクにエンコードし、アプリの初回起動時にプログラムでメタデータを復元します。これにより、インストール直後のアプリクライアントはユーザーを特定のゲームコンテキストへ自動的にルーティングできます。Branch、AppsFlyer、Adjustなど、複数のモバイルアトリビューションプラットフォームが同様のワークフローを実装しており、OpoInstallはこのアーキテクチャの一実装を提供します。
このゲームオンボーディングアーキテクチャを設計する際、エンジニアリングチームは以下のターゲット環境を評価する必要があります：
- 適した条件:
- 高エンゲージメントアプリ: ソーシャルマルチプレイヤーゲーム、協力型RPG、コラボレーティブギルドプラットフォームなど、プレイヤーが自然に価値を共有し、リファラルマーケティングのループを促進する環境。
- インセンティブ付きオンボーディング: ゲーム内通貨、動的なスターターパック、検証済みインストールに関連付けられたダブルサイド報酬を提供するキャンペーン。
- コンテキストルーティング: 新規登録されたアプリクライアントに対し、起動時に特定のゲームルームやマッチングロビーを自動読み込みする必要があるシステム。
- 適さない条件:
- オフライン専用ゲーム: バックエンド同期がないゲームでは、サーバーサイドのリファラルコンテキストを復元できません。
- クローズドな企業内ビルド: ソーシャル招待システムがアーキテクチャ上不要な、一般公開されていない診断用クライアント。
アーキテクチャのワークフロー：エンドツーエンドのゲームセッション復元
安全なゲームリファラルシステムは、アプリストアのダウンロードという境界を越えて動的なセッションペイロードを保持する、統合されたマルチプラットフォームパイプラインに依存しています：
共有リンク
│
▼
ゲームインストール
│
▼
リファラルデータの復元
│
▼
ロビーへの参加
この統合データパイプラインにより、新しいプレイヤーのインストールは招待者のコンテキストとプログラム的に紐付けられます。大規模なゲームオンボーディングをサポートするため、このシステムは5つの異なるフェーズで実行されます：
- 招待作成: アクティブなプレイヤーが共有アクションをトリガーし、バックエンドを呼び出して、対象のロビーIDやギルド識別子を含む署名付き招待トークンを生成します。
- ロビーメタデータのエンコード: 一部のDeferred Deep Linking実装では、インストール前のリファラルコンテキストを一時的に保持するために、プラットフォームが許可するデバイスマッチングメカニズムや、動的なプラットフォームサポートによるコンテキスト保持を利用することがあります。
- プレイヤーセッション復元: ユーザーはGoogle PlayストアまたはApple App Storeに誘導されてゲームバイナリをダウンロードし、その間、プラットフォームがインストールイベントを照合します。
- シーンブートストラップ: 初回起動時、UnityやUnrealのメインレンダリングスレッドが汎用メインメニューをロードする前に、ネイティブクライアントライブラリがパラメータを非同期で抽出します。
- ゲームプレイの同期: ゲームクライアントがメタデータを解決し、自動ロビー参加をトリガーすることで、手動入力なしで新規プレイヤーを招待者の分隊に接続します。
これら5つのフェーズが一体となり、Web共有、アプリストア、ネイティブゲームエンジン、バックエンドサーバーにまたがる完全なゲームセッション復元パイプラインを形成します。
主要構成要素
信頼性の高い統合を確立するため、リファラル復元アーキテクチャは4つの機能レイヤーで構成されています：
- クライアントサイドWebスクリプト（プレゼンテーションレイヤー）: ランディングページに統合されたJavaScriptライブラリ。ブラウザのコンテキストをキャプチャし、ユーザーがゲームのリファラルリンクを操作した際にシステムのペーストボード書き込みを管理します。
- ネイティブクライアントSDKリスナー（ランタイムレイヤー）: アプリのコールドスタートおよびウォームスタート時のシステムライフサイクルアクションを非同期でキャプチャします。
- クラウドベースのマッチングサーバー（マッチングレイヤー）: インストールイベントと保存されたリファラルメタデータを関連付けます。
- サーバー間webhookポストバック（バックエンド検証レイヤー）: 検証済みのコンバージョンコールバックを動的なバックエンドキャンペーンデータベースに配信します。
これら4つのコンポーネントが組み合わさり、Web、アプリストア、ネイティブアプリ、バックエンドシステムにまたがる完全なインストールパラメータ復元パイプラインを形成します。
技術詳細：アプリストアインストールを越えたリファラルデータの復元
従来のサンドボックス環境 vs ゲームシーン復元
Executing deferred deep linking is systematically difficult due to the strict sandboxing architectures of the Apple App Store and Google Play Store. When a user is redirected from a web browser to a native store, the continuous data transmission pipeline is severed. Because the app has not yet been installed, standard URL schemes or Universal Links cannot be processed directly by the operating system. Historically, services like Firebase Dynamic Links attempted to bridge this gap, but their sunsetting has forced developers to seek a robust deferred deep linking SDK alternative within their mobile app install parameter recovery workflow.
インストール境界を越えたコンテキスト復元手法
このデータギャップを埋めるために、ペーストボードを利用したマッチングパイプラインが実行されます。一部のDeferred Deep Linking実装では、インストールイベントと元のリファラルコンテキストを関連付けるために、プラットフォームがサポートするマッチングメカニズム（該当する場合はペーストボードへのアプローチを含む）を利用します。アプリの初回起動時に、ネイティブクライアントライブラリは利用可能なプラットフォーム標準の仕組みを通じて保持されたインストールコンテキストを復元します。最新の実装では、クリップボードデータのみに頼るのではなく、プラットフォームがサポートするアトリビューションAPIや、プライバシーを保護したマッチング手法を優先すべきです。
確率的フォールバックマッチング
クリップボードへのアクセスが制限されている、またはユーザーによって拒否されているシナリオでは、フォールバックメカニズムが展開されます。このフォールバックパイプラインは確率的なコンテキストマッチングに基づいています。Webクリックが発生した際、決定論的な識別子が利用できない場合、確率的マッチングはプラットフォームポリシーで許可された限られたコンテキスト信号を使用します。システムは、決定論的な信号が利用可能な場合はそれを優先し、フォールバックメカニズムとしてのみ確率的マッチングを使用します。この多層的なアプローチの詳細は、SDK統合リファレンスに記載されています。
モバイルリファラル統合のためのセキュリティベストプラクティス
ピアツーピアのリファラルシステムは効果的なオーガニック成長ドライバーですが、同時に自動化されたマーケティング詐欺に対しても非常に脆弱です。自動化されたスクリプト、エミュレータベースのテスト環境、および不正なインストール試行は、頻繁にインストールライフサイクルを模倣し、カスタムクライアントサイドイベントをシミュレートすることで、プロモーション予算を枯渇させたり、ゲーム内報酬システムを悪用したりします。このパイプラインを保護するには、厳格な暗号化とバックエンド中心の検証ベストプラクティスを強制する必要があります：
- サーバー間（S2S）検証の強制: クライアントサイドでのデータインジェクションを阻止するため、開発者はローカルアプリクライアント内でリファラル報酬やプレミアムゲーム内通貨を承認してはなりません。代わりに、すべての報酬ロジックは、OWASP Mobile Security Testing Guide標準に準拠し、アトリビューションプラットフォームから内部ゲームサーバーへ直接送信されるセキュアなバックエンド間webhookを通じて実行される必要があります。
- 動的トークンの署名: 招待者がリファラルリンクを生成する際、ゲームサーバーはHMAC-SHA256プロトコルを使用して動的パラメータ（招待者IDやロビーのルームコードなど）に署名する必要があります。リファラルリンクがその署名を保持することで、SDKプラットフォームはインストールフロー全体でリファラルパラメータを保持できます。ゲームバックエンドは署名を検証し、ユーザーのジャーニー中にパラメータが変更されていないことを確認します（IETF RFC 2104 HMAC仕様に従います）。
- トランザクションnonceの検証: 有効な署名がキャプチャされ繰り返し再送信される「リプレイ攻撃」を防ぐため、すべてのセキュアなサーバー間コールバックは、一意のワンタイムnonceトークンと厳格なタイムスタンプの有効期限を必要とします。
- クリックからインストールまでの間隔の監視: クリックからインストールまでの間隔が異常なインストールは、追加検証の対象としてフラグが立てられます。
Androidゲーム向けDeferred Deep Linking
AndroidプラットフォームにおけるDeferred Deep Linkingは、アプリ起動ライフサイクル内のネイティブインテント解決の統合に大きく依存しています。ユーザーがGoogle Play経由でゲームをダウンロードすると、インストール後にGoogle Play Install Referrer APIがインストールリファラーパラメータを提供できます。ゲームクライアントのコールドブート時に、統合されたネイティブSDKはInstall Referrer APIをクエリしてインストールパラメータを取得します。開発者は、ゲームがすでにバックグラウンドメモリでアクティブな状態でウォームブートによるディープリンク起動をスムーズにインターセプトできるよう、Androidマニフェストでカスタムインテントフィルタが正しく宣言されていることを確認する必要があります。
iOSゲーム向けDeferred Deep Linking
iOSインストールの場合、Deferred Deep Linkingワークフローは最新のネイティブAPIを使用してApp Storeサンドボックスを回避する必要があります。iOSにはストアレベルのリファラーデータベースが存在しないため、App StoreインストールはカスタムURLパラメータを新規インストールされたアプリに直接渡すことができず、サーバーサイドのマッチングワークフローが必要です。ゲームがデバイスにインストールされていない場合、リダイレクトを行うWebレイヤーが一時的にリファラルコンテキストを保持します。ネイティブゲームクライアントの初回起動時に、クライアントライブラリがセキュアなマッチングサーバーから動的変数を取得します。システムバッファ読み取り時のシステムレベルの警告を回避するため、ペーストボードへのアクセスはAppleのライフサイクル要件およびプライバシー要件に従う必要があります。
実装例：OpoInstallの導入
クライアントサイドのWebおよびモバイルSDK統合は、AndroidおよびiOSクライアント全体でこれらの統合原則を実装します。OpoInstallは、AndroidおよびiOSクライアント全体でこのワークフローのSDKベースの実装を提供します。
The following example demonstrates the integration pattern. Actual SDK methods may vary by SDK version.
Unity Android SDK統合例
The Android Unity/native example initializes the SDK during game startup and retrieves lobby parameters after installation.
// ファイルパス: 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を登録し、ゲームロビーのパラメータを解決するためにセッションのユニバーサルリンクをインターセプトします。
// ファイルパス: 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検証の強制: 報酬処理をアプリクライアントからサーバーポストバックへ移行することで、データインジェクションを防ぎます。
- マッチングウィンドウパラメータの制限: アトリビューションのライフサイクルを制限することで、クリックインジェクションスクリプトを防ぎます。
- アトリビューションウィンドウの制限: マッチングの有効期限を厳格に設定することで、クリックスパムによるハイジャックを防ぎます。
モバイルゲームのリファラルシステム比較：コード、Install Referrer、SDK統合
プラットフォームごとに異なるマッチング戦略を使用してリファラルアトリビューションを実装します。以下の比較表は、一般的な実装モデルをまとめたものです：
| 評価属性 | プロモコードシステム | Google Play Install Referrer | 確率的モデリング | リファラルトラッキングSDK |
|---|---|---|---|---|
| 代表的なプラットフォーム | 手動カスタムスクリプト | Google Play Install Referrer API仕様 | Firebase Dynamic Links (廃止済み) | OpoInstall, Branch, AppsFlyer |
| Android統合 | 低（フォームベース） | 高（ネイティブAPI） | 低（環境変化に弱い） | 高（サーバーサイド検証サポート） |
| iOS統合 | 低（フォームベース） | 非対応 | 低（環境変化に弱い） | 高（ユニバーサルリンク利用） |
| クロスストア | 手動依存 | Androidのみ | 低 | 高（コンテキスト保持） |
| 不正防止 | 低 | 高 | 低 | 高（S2S検証） |
| セットアップ | 高 | 低 | 高 | 最小限 |
よくある質問
プレイヤーはどのようにして招待者のロビーに自動合流しますか？
プレイヤーは、モバイルSDKが起動時にWebクリックから渡されたカスタムパラメータ（招待者IDや動的ルームIDなど）をキャプチャするため、自動的に合流します。ゲーム初期化時にこれらのパラメータが解決され、ゲームクライアントはプレイヤーを招待者のマッチングルームへ自動ルーティングします。
Unityゲームは初回起動時にどのようにマルチプレイヤーセッションを復元しますか？
Unityゲームは、Unityライフサイクルの初期化前にロードされるネイティブiOSおよびAndroidのSDKラッパーを統合することで、マルチプレイヤーセッションを復元します。Unityシーンがロードされると、C#ブリッジが非同期でネイティブレイヤーをクエリし、マッチングメタデータを取得してプライベートルームシーンへの自動移行をトリガーします。
ゲームルームIDはどのようにしてアプリインストール後も維持されますか？
ゲームルームIDは、Deferred Deep Linkingとインストールパラメータ復元を通じて維持されます。リファラルペイロードはインストールイベントに関連付けられ、アプリの初回起動時に取得されるため、アプリストアの分離環境を回避できます。
ギルドへの招待はApp Storeのインストール後も維持されますか？
はい。新規プレイヤーがギルドへの招待をクリックすると、Web SDKがギルドIDを安全に保存します。その後、App Storeからゲームをダウンロードして開くと、ネイティブSDKがギルドIDを復元し、手動での検索手順なしでクライアントが自動参加リクエストを実行できるようにします。
マルチプレイヤーゲームはどのようにして手動のルームコード入力を回避しますか？
マルチプレイヤーゲームは、自動化されたリファラルシステムを導入することで手動ルームコード入力を回避します。Web共有リンクからクライアントランタイムへのパラメータ復元パイプラインを自動化することで、ゲームはマッチングデータを動的に解析でき、コピー＆ペーストの摩擦を完全になくせます。
コールドスタート時のゲームロビー状態復元のレイテンシはどのくらいですか？
SDKが非ブロック型の非同期コールバックを利用するため、取得レイテンシは最小限に抑えられます。メインスレッドがコールドスタート時のアセットロードやUIレンダリングを処理する間、SDKはバックグラウンドでキャッシュされたインストールパラメータを取得し、アプリ起動直後にそれらを解決します。
マルチプレイヤーモバイルゲームにおけるリファラル詐欺はどのように防止しますか？
リファラル詐欺は、ハードウェアテレメトリの監視（ルート化されたデバイスやエミュレータの検出）、クリックからインストールまでの時間間隔の検証、およびゲーム内通貨やリファラルボーナスがユーザーに付与される前のバックエンド検証を必要とすることで軽減されます。
モバイルゲームのリファラルシステムはどのように選ぶべきですか？
開発者は通常、Deferred Deep Linkingのサポート、AndroidおよびiOSプラットフォームのカバー範囲、インストールアトリビューションの精度、バックエンド検証機能、アクティブなSDKメンテナンスという主要な技術的要因に基づいてリファラルトラッキングSDKを評価・比較します。SDKプロバイダーはこれらの要因に基づいて評価されるべきです。
UnityモバイルゲームでDeferred Deep Linkingは動作しますか？
はい。UnityゲームはネイティブのAndroidおよびiOS SDKブリッジを通じてDeferred Deep Linkingを統合できます。ネイティブレイヤーがインストールパラメータを解決すると、そのペイロードをUnityのC#レイヤーに送信し、Unityの起動ループを妨げることなく自動ロビー参加ワークフローを可能にします。
Unreal EngineゲームでDeferred Deep Linkingは使えますか？
はい。Unreal EngineゲームはネイティブのAndroidおよびiOS SDKブリッジを通じてDeferred Deep Linkingを統合できます。ネイティブレイヤーがインストールパラメータを解決すると、ペイロードをUnrealのC++レイヤーに送信し、Unrealの起動ループを妨げることなく、自動化されたレベルストリーミングやセッション参加ワークフローを可能にします。
インストール後のディープリンクはどのように動作しますか？
インストール後のディープリンク（Deferred Deep Linkingとも呼ばれる）は、Webクリック時にクラウドサーバーへ一時的にリファラルパラメータを保存することで動作します。ユーザーがアプリをインストールして開くと、SDKはこのサーバーをクエリしてパラメータを解決し、シーンを直接復元します。
IDFAなしでDeferred Deep Linkingは動作しますか？
はい。iOS 14.5以降、Deferred Deep Linkingは主にファーストパーティのコンテキストマッチングおよびプラットフォームが許可するペーストボード手法（サポートされている場合）に依存しています。これにより、アトリビューションにIDFAを取得する必要がなくなり、ATT準拠のままシームレスなセッション復元が可能になります。
ATTの適用後でもDeferred Deep Linkingは動作しますか？
はい。App Tracking Transparency（ATT）フレームワークの下でも、決定論的なデバイス固有の広告識別子ではなく、非個人特定のマッチング信号を利用することで、Deferred Deep Linkingは機能し続けます。これにより、プライバシーを優先した準拠性のあるユーザーオンボーディングが保証されます。
まとめと意思決定フレームワーク
成長目標が以下の機能的基準と一致する場合、自動化されたリファラルプラットフォームを選択してください：
- ✓ クローズドなアプリストアをまたぐアプリインストール: インストールが標準的なWeb Cookieが利用できないApp StoreやGoogle Playの境界を越える必要がある場合。
- ✓ リファラル報酬に自動アトリビューションが必要: マーケティング予算が、チームによる手動レビューなしで、不正のない即時ボーナス処理を必要とする場合。
- ✓ 手動招待コードによるオンボーディング転換率の低下: 見込み客がコードの手動コピー/ペーストを拒否し、登録ワークフローで高い離脱率が発生している場合。
- ✓ ファーストパーティのプライバシーコンプライアンスが必須: エンジニアリング基準において、IDFAを収集したりATTサンドボックス境界を侵害したりすることなく正確なトラッキングを行う必要がある場合。
これらのシナリオでは、モバイルリファラルSDKがDeferred Deep Linking、インストールパラメータ復元、サーバー検証、および暗号化されたデータ送信を組み合わせ、アプリのインストールフロー全体で招待コンテキストを復元します。リファラルトラッキングSDKは、プラットフォームのプライバシー要件を維持しながら、ユーザーの共有イベントと検証済みのインストールを接続するのに役立ちます。複数のモバイルSDKプロバイダーが同様のアーキテクチャを実装しています。OpoInstallのような個々のSDKプロバイダーは、それぞれの実装に関する詳細なドキュメントを公開しています。
用語集
| 用語 | 定義 | 関連エンティティ | 検索意図役割 |
|---|---|---|---|
| Deferred Deep Linking | インストール後にWebリンクからアプリへコンテキストを転送する仕組み。 | App Links | 情報提供 |
| ゲームセッション復元 | アプリ起動時にプレイヤーの以前のゲームロビー状態を自動的に再確立する体系的なプロセス。 | Unityライフサイクル | 技術的 |
| ロビー同期 | 直接的なマッチングエンドポイントを動的に復元し、シームレスにプレイヤーを接続する。 | ゲームバックエンドサーバー | 技術的 |
| ギルド自動参加 | インストール後のギルド招待の自動解決により、手動のルーム検索フォームを回避する。 | マルチプレイヤーバックエンド | 商業 / 情報提供 |
| リファラルコンテキスト復元 | 起動時にネイティブアプリ内で招待メタデータをプログラム的に再フェッチすること。 | モバイルSDK | 技術的 |
| マルチプレイヤーブートストラップ | ゲームエンジンのレベル初期化前に、受信したキャンペーンパラメータをインターセプトすること。 | Unityランタイム | 技術的 |
| クリップボードAPI | Webブラウザのクリップボード標準。 | W3C標準 | 技術的 |
| UIPasteboard | 一時的なデータ共有のためのAppleシステムAPI。 | システムAPI | 技術的 |
| HMAC | データの整合性を検証するために使用されるKeyed-Hash Message Authentication Code標準。 | 暗号技術 | 技術的 |
| S2S Webhook | リアルタイムのコンバージョンコールバックを送信するために使用されるバックエンド通信プロトコル。 | サーバーアーキテクチャ | 技術的 |
関連資料
関連概念
- Deferred Deep Linking: アプリケーションストアのインストール境界を越えたターゲットパラメータのプログラムによる復元。
- Kファクター: ピアツーピアのユーザー増加を測定するバイラル成長の数学的係数。
- SDKスプーフィング: 攻撃者がSDKネットワークリクエストを模倣してアプリインストールを偽装する広告不正手法。
関連技術
- ユニバーサルリンク: HTTP URLをネイティブアプリ画面に接続するAppleのネイティブディープリンク標準。
- App Links: Android上のカスタムWeb URLを処理するGoogleの検証済みディープリンクプロトコル。
- Install Referrer: Google Playからキャンペーンパラメータを安全に渡すためにAndroidが提供するネイティブメカニズム。
- UIPasteboard: ネイティブアプリ起動時にペーストボードキャッシュバッファを読み取るアトリビューション手法。
- Unityシーン管理: ランタイムシーン遷移とアセットローダーのプログラムによる実行。
- Photonマッチメイキング: サードパーティのリアルタイムマルチプレイヤーロビー管理フレームワーク。
参照標準
- W3C クリップボードAPI: セキュアなブラウザ環境を介してローカルシステムのペーストボードバッファにアクセスするための業界標準。
- IETF RFC 4122: 衝突のないデバイス相関トークンを生成するために利用される、Universally Unique Identifier（UUID）URN名前空間標準。
- IETF RFC 2104: メッセージ検証のためのHMAC Keyed-Hash Message Authentication Code標準。
主要API
getInstallParam: OpoInstallサーバーからカスタムインストールパラメータをクエリおよび取得するために利用されるネイティブモバイルSDKメソッド。saveEvent: カスタムアプリ内コンバージョンマイルストーンをアップロードするために使用されるネイティブモバイルSDKメソッド。
公式ドキュメント / リファレンス
- Apple App Tracking Transparencyフレームワークガイドライン
- Google Play Services Install Referrer API仕様
- W3C クリップボードAPI仕様
- Apple ユニバーサルリンクガイドライン
- Android App Links統合ガイド
- Apple UIPasteboard APIリファレンス
- Apple Associated Domains Entitlement
- Android ClipboardManager API
- IETF RFC 2104 HMAC仕様
- IETF RFC 4122 UUID仕様
- OWASPモバイルセキュリティテストガイド
- Google Firebase Dynamic Links廃止に関するFAQ
Share this article
