ソフトウェア開発キット（SDK）がモバイルアトリビューションと成長を支える仕組み

SDK（ソフトウェア開発キット）とは何で、どのように機能するのでしょうか？ SDKは、開発者がソフトウェアアプリケーションを構築または拡張するために設計された、ライブラリ、API、ツール、ドキュメントの集まりです。モバイル開発において、SDKには一般的に、ディープリンクやアトリビューションなどのプラットフォーム固有の機能を提供するためにネイティブアプリケーションに統合されたコンパイル済みライブラリが含まれます。モバイルエンジニアリングチームが、Webプロモーションからのユーザー獲得データが新規インストールされたアプリケーションにどのように流れるかを評価する際、彼らはOSの根本的な境界線に直面します。リモートのWebインターフェースだけでは、ネイティブアプリのライフサイクルにアクセスしたり、アップストアのサンドボックスを単独で横断したりすることはできないのです。モバイルアトリビューションおよびディープリンクプラットフォームであるOpoInstallは、これら孤立した環境間で連携するネイティブクライアントライブラリとWebスクリプトを提供し、キャンペーンパラメータを復元してユーザーをターゲットとなるアプリ内ビューへルーティングします。

ソフトウェア開発キット（SDK）とは、特定のオペレーティングシステムやフレームワーク向けに設計された、ライブラリ、アプリケーションプログラミングインターフェース（API）、ヘッダーファイル、開発者向けドキュメント、サンプルコードのパッケージ化されたコレクションです。HTTP経由でステートレスな通信インターフェースを定義するスタンドアロンのリモートWeb APIとは異なり、モバイルSDKはクライアントアプリケーションのランタイムプロセス内で直接実行され、ローカル状態、OSのライフサイクルコールバック、非同期のネットワークテレメトリを管理します。

SDKとは何か、そして標準的なWeb APIとの違い

用語の解体：すべてのSDKにAPIが含まれる理由、しかしAPIはSDKではない理由

ソフトウェアエンジニアリングにおいて、モバイル成長インフラストラクチャを初めて扱う開発者は、アプリケーションプログラミングインターフェース（API）とソフトウェア開発キット（SDK）を混同しがちです。これら2つの概念は連携して動作しますが、ソフトウェアアーキテクチャにおいて異なるレイヤーを占めています。

APIは、厳密にはインターフェースの仕様および通信契約です。1つのソフトウェアコンポーネントが別のコンポーネントと対話できるようにするための、メソッドシグネチャ、データ構造、IETF RFC 3986に基づくURI構文、および応答フォーマットを定義します。APIは複数のレベルに存在します。ローカルのOSインターフェース、プロセス内ライブラリインターフェース、あるいはIETF RFC 9110 HTTPセマンティクス（GET、POST）に準拠したリモートのステートレスWebエンドポイントなどがあります。リモートREST APIを直接呼び出す場合、アプリケーション開発者はネットワークリクエストの構築、トランスポートセキュリティの管理、返されたJSONペイロードの解析、およびリトライ条件の処理を手動で行う必要があります。

これに対し、SDKは、ランタイムロジック、ドキュメント、および開発者向けツールとともに1つまたは複数のローカルAPIをカプセル化する完全な実装キットです。開発者がモバイルSDKをAndroid StudioまたはXcodeプロジェクトにインポートすると、ビルド済みのライブラリコードがアプリケーションバイナリに直接リンクされます。SDKは、ホストアプリケーションに対してローカルなプログラム用API（initialize()、getInstallParam()、handleDeepLink()など）を公開する一方で、スレッドのスケジューリング、OSのコールバック、リモートサーバーとの通信を内部で管理します。

実行コンテキスト：ステートレスなサーバー間エンドポイント対ステートフルなクライアントサイドランタイムライブラリ

リモートWeb APIの呼び出しとネイティブモバイルSDKの統合における運用上の違いは、実行コンテキストとデバイス環境へのアクセスに集約されます：

• プロセスの常駐とパッケージング: リモートWeb APIはサーバーサイドインフラストラクチャを介して公開され、ネットワーク経由で呼び出されます。サーバーサイドアプリケーションがエンドポイントを実装し、クライアントアプリケーションがリクエスト処理ロジックを実行します。対照的に、モバイルSDKは、アプリケーションのパブリッシング成果物（Android App Bundle .aabなど）またはインストール可能なアプリケーションパッケージ（Androidの.apkやiOSの.ipa）にコンパイルされ、エンドユーザーのデバイス上のアプリケーションに割り当てられたメモリ空間内で実行されます。
• ネイティブライフサイクルの認識: リモートRESTエンドポイントは、クライアントがHTTPリクエストをディスパッチしたときにのみ応答します。一方、ネイティブモバイルSDKはモバイルOSにオブザーバーを登録するため、アプリケーションの起動、フォアグラウンドとバックグラウンドの状態遷移、またはシステムレベルのルーティングインテントの受信を検知できます。
• オプションのローカル永続化とキューイング: 実装に応じて、モバイルSDKは、構成状態を保存したり、ローカルのサンドボックスストレージ（AndroidのSharedPreferencesやSQLite、iOSのUserDefaultsやアプリケーションファイルストレージなど。なお、小さな機密認証情報にはKeychainを予約します）でコンバージョンイベントをキューイングしたりすることがあります。これにより、ネットワーク接続が利用可能になったときにテレメトリを非同期で送信できるようになります。

アーキテクチャの比較：リモートWeb API対ネイティブモバイルSDK

以下の表は、リモートのステートレスWeb APIとコンパイル済みのネイティブモバイルSDKを、主要なアーキテクチャの観点から対比したものです：

モバイルソフトウェア開発キットの内部にあるコアコンポーネント

コンパイル済みバイナリライブラリ：AndroidアーカイブバンドルとiOSフレームワーク

モバイルSDKの中心にあるのは、ターゲットOSのビルドツールチェーン向けにフォーマットされたコンパイル済みバイナリディストリビューションです：

• Androidアーカイブ（.aar）、JAR、App Bundle（.aab）: Androidでは、SDKは.aarバンドルまたは.jarライブラリとして配布されます。.jarファイルにはコンパイル済みのJVMバイトコードが含まれていますが、.aarバンドルには、Gradleビルド時にホストアプリケーションにマージされるAndroid固有のリソースやマニフェストエントリも含めることができます。ホストアプリケーションがリリース用にビルドされる際、Android App Bundle（.aab）は直接インストール可能なアプリケーションパッケージではなく、パブリッシング成果物として機能します。Google Playはこれを処理し、ユーザーに配信されるデバイス固有のAPKへと変換します。
• iOSスタティックライブラリ（.a）、フレームワーク、XCFramework: iOSでは、SDKはスタティックライブラリ、.frameworkバンドル、または.xcframeworkアーカイブとして配布されます。標準的な.frameworkビルドは通常特定のプラットフォームバリアントをターゲットにし、1つまたは複数のサポート対象CPUアーキテクチャを含む場合があります。一方、Apple XCFramework（.xcframework）バンドルは、物理的なARM64 iOSデバイスのスライスとiOSシミュレータのスライスなど、複数のプラットフォームおよびアーキテクチャのバリアントを単一の配布可能な成果物にパッケージ化するように設計されています。

パブリックヘッダーファイル、インターフェース契約、型定義

コンパイル済みバイナリには、ホストアプリケーションのコンパイラがビルド時にメソッド呼び出しを検証できるようにするためのパブリックな型定義契約が必要です：

• iOSヘッダーファイル（.h）とブリッジングインターフェース: Objective-CベースのiOS SDKは、パブリックヘッダーファイル（OpoInstallSDK.hなど）を提供し、クラスインターフェース、デリゲートプロトコル（OpoInstallDelegate）、データモデル（OpoinstallData）を宣言します。Swiftプロジェクトでは、これらの宣言はObjective-Cブリッジングヘッダーまたはモジュールインポートを介して公開されます。
• Androidクラスシグネチャとコールバックインターフェース: Android SDKは、ドキュメント化されたパッケージネームスペース内で、パブリックなエントリーポイントクラスや汎用的なコールバックインターフェース（ResultCallBack<OpoData>など）を公開します。

構成マニフェスト、AppKey、権限（エンタイトルメント）の宣言

モバイルSDKは、テナントリクエストを認証し、OSのルーティングフックを登録するために、ホストの構成メタデータに依存しています：

• テナントアプリケーション識別子（AppKey）: AndroidのAndroidManifest.xmlの<meta-data>タグ、またはiOSのInfo.plistファイル（com.opoinstall.APP_KEY）内で宣言され、SDK初期化時にアプリケーションテナントを識別します。
• OSルーティング宣言: ワンクリックでのアプリ起動をサポートするため、ホストプロジェクトはカスタムURLスキームと検証済みドメインの関連付け（XcodeのAssociated Domainsエンタイトルメントにおけるapplinks:ドメイン、およびAndroidにおける検証済みインテントフィルター）を宣言します。

ドキュメントとサンプルプロジェクト：コンパイル済みライブラリを使用可能な開発者向けインターフェースへ変換する

コンパイル済みライブラリは、明確な統合仕様がなければ採用が困難です。プロダクション品質のSDKは、明確な開発者向けドキュメントと、可能であれば実行可能なサンプルプロジェクトを提供する必要があります：

• 開発者向けドキュメント: バージョンの互換性、ライフサイクルの初期化順序、必要な権限、コールバックペイロードのフォーマット、エラーコードなどを定義し、エンジニアが予測可能な形でライブラリを統合できるようにします。
• サンプルプロジェクトとクロスプラットフォームブリッジ: 最小限の実行可能なデモプロジェクトは、チームがディープリンクやパラメータの復元を検証するのに役立ちます。モバイルSDKダウンロードセンターでは主にコアとなるネイティブのAndroidおよびiOS SDKパッケージ（現在v2.1.0）を配布していますが、FlutterやUnityなどのクロスプラットフォームフレームワークを使用するチームは、ラッパープラグインやプラットフォームチャネルを介してこれらのネイティブSDK機能をブリッジします。利用可能なプラグインリポジトリを公式ドキュメントと照らし合わせて確認してください。

Web API単体ではモバイルインストールの測定（アトリビューション）を解決できない理由

App Storeというブラックボックス：サンドボックスの隔離が従来のWebクッキー追跡を無効化する仕組み

通常のWeb開発では、リファラルリンクから登録イベントへの追跡はブラウザストレージに依存します。ユーザーがhttps://example.com/index.html?inviter_id=A102にアクセスすると、JavaScriptがクエリ文字列を読み取り、inviter_id=A102をlocalStorageまたはHTTPクッキーに保存します。

しかし、モバイルアプリの獲得においては、App Storeの境界線（App Storeのブラックボックスとして知られる構造的障壁）でこの連続性が途切れます：

1. Webコンテキスト: ユーザーがモバイルブラウザやソーシャルアプリ内のプロモーションリンクをクリックし、カスタムパラメータ（?ref=userA&channelCode=ch_01）を持つH5ランディングページを読み込みます。
2. マーケットプレイスへの引き渡し: ネイティブアプリがまだインストールされていないため、ダウンロードボタンをクリックすると、ユーザーはブラウザからApple App StoreまたはGoogle Playストアへとリダイレクトされます。
3. サンドボックスの隔離: ユーザーがネイティブアプリをインストールして起動すると、モバイルOSは隔離されたファイルシステムとメモリサンドボックス内でプロセスを起動します。ネイティブアプリは、ダウンロードを初期化したブラウザセッションのクッキーやlocalStorageを読み取ることができません。

Webからアプリへのギャップを埋める：Web JS SDKとネイティブクライアントSDKの役割

App Storeの境界を越えてパラメータを解決するには、関連する3つの概念（遅延ディープリンク：インストール後に新規ユーザーをターゲットのアプリ内画面へルーティングすること、インストールパラメータの復元：H5リンクで渡されたカスタムのキーと値のペアを回収すること、アトリビューションマッチング：インストールを特定のプロモーションチャネルに紐付けること）を分離した、協調的なワークフローが使用されます：

• インストール前Web JS SDK（OpoInstall Webスクリプト）: H5ランディングページに統合され、Web JS SDKは共有URLから動的なクエリパラメータ（channelCode、shareCode、ルームIDなど）を解析し、アプリの起動やストアへのリダイレクトをトリガーする前に、インストール前のセッションコンテキストをアトリビューションサーバーにアップロードします。
• インストール後ネイティブクライアントSDK（Android / iOS SDK）: モバイルアプリのバイナリに統合され、ネイティブSDKは初回起動時に初期化され、プラットフォームAPIやアトリビューションサーバーと通信し、非同期コールバックを介して復元されたカスタムパラメータをクライアントアプリに返します。

[モバイルWebブラウザ：H5ランディングページ]
                 |
                 | 1. Web JS SDKがURLパラメータを解析 (?ref=userA&channelCode=ch01)
                 |    & インストール前セッションコンテキストをアップロード
                 v
     [アトリビューションサーバーバックエンド]
                 |
                 | 2. ユーザーがApp Store / Google Playからアプリをダウンロード
                 |    （ブラウザクッキーはOSサンドボックスを跨げない）
                 v
   [ネイティブアプリ初回起動：モバイルSDK]
                 |
                 | 3. クライアントSDKが起動時に初期化され、
                 |    キャッシュされたカスタムパラメータ ＋ チャネルIDを取得
                 v
  [アプリ内ルーティング ＆ チャネルアトリビューション]

プラットフォーム固有のアトリビューションメカニズム：Google Playインストールリファラー対iOSコンテキスト照合

AndroidとiOSでは異なるApp Storeアーキテクチャが採用されているため、モバイルアトリビューションはそれぞれのプラットフォームメカニズムに依存します：

• AndroidエコシステムとGoogle PlayインストールリファラーAPI: Google Playを通じて配信されるアプリの場合、ネイティブ統合によって公式のGoogle PlayインストールリファラーAPIを使用し、インストール中にPlayストアによって渡されたリファラーメタデータ（リファラーURLやクリック／インストール時のタイムスタンプを含む）を取得できます。Google PlayインストールリファラーAPIは、対象となるGoogle Playストアのインストールフローに特化して適用されるため、Google Play外でのAndroid配信では、サーバーサイドでのH5パラメータマッチングや、channelCode識別子が埋め込まれたエクスポート済みAndroidチャネルパッケージ（APKファイル）に依存します。
• iOSエコシステムとコンテキスト照合: AppleのApp Storeには、Google Playのインストールリファラーに相当する、一般的なURLクエリパラメータのパススルー機構はありません。アプリがすでにインストールされている場合、iOSはAppleユニバーサルリンクを介してユーザーをアプリ内に直接ルーティングします。ユニバーサルリンクは、apple-app-site-association（AASA）ファイルを介してドメインの所有権を検証します。アプリがインストールされていない場合、ユニバーサルリンクはWebサイトにフォールバックし、インストール後のパラメータ回復を単独で保証するわけではありません。遅延パラメータの復元には、初回起動時のサーバーサイドでのセッション照合が必要です。

プラットフォームのプライバシー境界の尊重：Appleのユーザープライバシーガイドラインと許可されたマッチングシグナル

モバイルSDKがインストール前のWeb訪問とインストール後の起動をどのように照合するかを評価する際、エンジニアリングチームは、ベンダーがドキュメント化している機能と、OSのポリシーコンプライアンスを区別する必要があります：

• ベンダーが文書化したメカニズム: OpoInstallの公開プロダクトドキュメントには、H5ページ上でWeb SDKがデバイスのフィンガープリンティング特性やチャネルIDを収集し、初回起動時にネイティブのAndroid/iOS SDKがデバイス特性を再収集してインストール元をマッチングする、H5チャネルおよびパラメータインストールワークフローが記載されています。
- Appleのプラットフォームポリシーの境界: Appleのユーザープライバシーおよびデータ使用に関するガイドラインに基づき、Appleはユーザーやデバイスを一意に識別する目的（フィンガープリンティング）で、ブラウザプロパティ、IPアドレス、システム構成などのデータをデバイスから取得して結合することを明示的に禁止しています。禁止されているフィンガープリンティングを行うアプリケーション、またはそれを行うサードパーティSDKを参照するアプリケーションは、App Storeの審査時にリジェクトされるリスクがあります。個別に、異なる企業のアプリ間で広告ターゲティング、広告測定、データブローカーとの共有のためにサードパーティのディープリンクまたは遅延ディープリンクサービスが一意の識別子を渡したり共有ユーザーIDを作成したりする場合、App Tracking Transparency（ATT）の承認が義務付けられています。ただし、ATTの同意によって、禁止されているデバイスフィンガープリンティングが許可されるわけではありません。
コンプライアンスの不備と検証要件: 特定のSDKバージョンや構成が禁止されているデバイスフィンガープリンティングに依存している場合、一般的な内部データ監査の実施やATTプロンプトを通じたユーザー同意の取得のいずれを行っても、そのメカニズムがAppleのガイドラインに準拠することにはなりません。OWASPモバイルアプリケーションセキュリティのガバナンス慣行に従い、ベンダーがiOSのマッチングメカニズムにおいて禁止されているデバイスフィンガープリンティングを回避していることを証明できない場合、開発者は、独立して検証された準拠オルタナティブ（代替手段）が確認されるまで、そのアトリビューションメカニズムをiOSにデプロイすべきではありません。
ネットワークのタイミングと未アトリビューションのフォールバック: iOSは通常のインターネットアクセスに対する一般的なユーザー付与型の許可を公開していませんが（開発者は、一般的なインターネット到達性と、ローカルネットワークデバイスの発見に適用されるAppleのローカルネットワークプライバシーの許可を区別する必要があります）、SDKの初期化とパラメータの取得は、依然としてネットワークの可用性と起動時のタイミングに依存します。遅延マッチングはすべてのネットワーク条件や遅延した初回起動において保証されるものではないため、返されたパラメータが空の場合には、アプリケーションは必ず適切なフォールバックフローを実装する必要があります。

アプリケーションライフサイクル全体で動作するモバイルアトリビューションSDKの仕組み

フェーズ1：GradleおよびCocoaPodsによる依存関係の管理とビルド時リンク

SDKのライフサイクルは、開発者がGradle、CocoaPods、または手動のアーカイブインポートを通じてライブラリの依存関係を宣言するコンパイル時に始まります。ビルドコンパイル中、パッケージマネージャーはライブラリの成果物を解決し、そのバイナリシンボルをアプリケーションパッケージにリンクします。一部のモバイルSDKでは、リリースビルドにおいてコード縮小に関する特定の互換性考慮事項が必要となる場合があり、またiOS SDKの統合ではプラットフォーム固有のプライバシーマニフェストの宣言や互換性のあるビルド構成が必要になる場合もあります。

フェーズ2：アプリ起動時のメインスレッド初期化

ユーザーがアプリを起動すると、モバイルOSはアプリケーションプロセスを作成し、プライマリのエントリポイントライフサイクルホックを呼び出します。これには、アプリケーションライフサイクルに関するGoogle Android開発者ガイドに詳述されているAndroidでのApplication.onCreate()や、UIApplicationDelegateに関するApple開発者ドキュメントに詳述されているiOSでのapplication(_:didFinishLaunchingWithOptions:)が含まれます。優れた設計のモバイルSDKは、アプリケーション起動時の処理を最小限に抑え、ネットワーク操作を非同期実行へと移行させる必要があります。開発者は、ターゲットビルドで実際の初期化動作を検証し、コールドスタートのパフォーマンスを測定する必要があります。

フェーズ3：ユニバーサルリンクおよびインテントフィルターによるネイティブディープリンクのインターセプト

アプリがすでにインストールされており、ユーザーがH5リンクをタップすると、OSはアプリケーションを起動し、プラットフォーム固有のエントリポイントを通じてルーティングコンテキストをSDKに配信します：

• Androidカスタムスキーム対検証済みApp Links: カスタムURLスキーム（scheme://）は、基本的なBROWSABLE <intent-filter>を介してルーティングされます。検証済みAndroid App Linksのサポートには、httpおよびhttpsの両方のスキームをターゲットのandroid:hostとともに宣言する<intent-filter android:autoVerify="true">が必要です。これは、アプリのパッケージ名とSHA-256署名証明書のフィンガープリントを含む/.well-known/assetlinks.jsonデジタルアセットリンクファイルによって裏付けられています。
• iOS AppDelegateおよびSceneDelegateのルーティング: ユニバーサルリンクは、従来のライフサイクルアプリの場合はNSUserActivityをAppDelegateに配信し、UISceneDelegateを介したシーンベースのライフサイクルを採用するiOS 13以降のアプリの場合は、コールドスタート時にはscene(_:willConnectTo:options:)に、ウォームレジューム時にはscene(_:continue:)に配信します。

フェーズ4：非同期パラメータの復元とイベントテレメトリのキューイング

初回起動時、またはビジネスコンバージョンマイルストーンが発生したときに、ホストアプリケーションはSDKの非同期メソッドを呼び出して、キャッシュされたインストールパラメータ（dataおよびchannelCode）を取得し、下流のコンバージョンイベント（アカウント登録やカスタムエフェクトポイントなど）を報告します。

AndroidおよびiOSでのネイティブSDKライフサイクルホックの実装

アプリケーション識別子の構成とSDKリリースの検証

以下の説明用の統合パターンは、OpoInstallの公開統合ドキュメントに準拠しており、ネイティブのAndroidおよびiOSプロジェクトが上記のライフサイクルホックをどのように配線するかを示しています。ダウンロードセンターでは更新されたSDKアーカイブ（現在2026-09-20リリースのv2.1.0）が配布されている一方、ドキュメントのサンプルは以前のマイナー座標を参照している場合があるため、エンジニアリングチームはターゲットのv2.1.0 SDKパッケージをダウンロードし、バンドルされたライブラリヘッダーに対してすべてのインポートパスとメソッドシグネチャを検証し、本番デプロイの前にAndroid StudioおよびXcodeでクリーンビルドの検証を実行する必要があります。リリース固有の統合手順については、OpoInstall技術ドキュメントを参照してください。

Android SDKの初期化とパラメータ取得のパターン

AndroidManifest.xmlにおいて、ネットワーク権限、テナントのAppKey、およびカスタムURLスキームの起動と検証済みAndroid App Links用の個別の<intent-filter>ブロックを宣言します（Android App Linksの検証要件に従ってhttpとhttpsの両方のスキームを宣言し、links.example.comを検証済みドメインに置き換えます）：

<!-- File: app/src/main/AndroidManifest.xml (Illustrative Integration Pattern) -->
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.app">

    <uses-permission android:name="android.permission.INTERNET"/>
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>

    <application
        android:name=".CustomApplication"
        android:allowBackup="true">

        <meta-data
            android:name="com.opoinstall.APP_KEY"
            android:value="OPOINSTALL_APPKEY"/>

        <activity
            android:name=".MainActivity"
            android:exported="true"
            android:launchMode="singleTask">

            <!-- 1. Custom URL Scheme wakeup filter -->
            <intent-filter>
                <action android:name="android.intent.action.VIEW"/>
                <category android:name="android.intent.category.DEFAULT"/>
                <category android:name="android.intent.category.BROWSABLE"/>
                <data android:scheme="OPOINSTALL_SCHEME"/>
            </intent-filter>

            <!-- 2. Verified Android App Links filter (requires /.well-known/assetlinks.json with SHA-256 cert fingerprint) -->
            <intent-filter android:autoVerify="true">
                <action android:name="android.intent.action.VIEW"/>
                <category android:name="android.intent.category.DEFAULT"/>
                <category android:name="android.intent.category.BROWSABLE"/>
                <data android:scheme="http"/>
                <data android:scheme="https"/>
                <data android:host="links.example.com"/>
            </intent-filter>
        </activity>
    </application>
</manifest>

// File: app/src/main/java/com/example/app/CustomApplication.java
package com.example.app;

import android.app.Application;
import com.opoinstall.api.OpoInstall;

public class CustomApplication extends Application {
    @Override
    public void onCreate() {
        super.onCreate();
        OpoInstall.initialize(this);
    }
}

// File: app/src/main/java/com/example/app/MainActivity.java
// Note: Verify exact package imports and callback signatures against your downloaded SDK v2.1.0 archive.
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;

public class MainActivity extends AppCompatActivity {
    private static final String TAG = "OpoInstallSDK";

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        OpoInstall.getInstance().start(this);

        // Process wakeup intent if launched via custom scheme or verified App Link
        getWakeUpData(getIntent());

        // Retrieve deferred installation parameters when needed by onboarding logic
        OpoInstall.getInstance().getInstallParam(new ResultCallBack<OpoData>() {
            @Override
            public void onResult(OpoData opoData) {
                Log.d(TAG, "getInstallParam onResult : " + opoData);
            }

            @Override
            public void onError(OpoError opoError) {
                Log.e(TAG, "getInstallParam onError : " + opoError);
            }
        });
    }

    @Override
    protected void onNewIntent(Intent intent) {
        super.onNewIntent(intent);
        getWakeUpData(intent);
    }

    private void getWakeUpData(Intent intent) {
        OpoInstall.getInstance().handleDeepLink(intent, new ResultCallBack<OpoData>() {
            @Override
            public void onResult(OpoData opoData) {
                Log.d(TAG, "handleDeepLink onResult : " + opoData);
            }

            @Override
            public void onError(OpoError opoError) {
                Log.d(TAG, "handleDeepLink onError : " + opoError);
            }
        });
    }
}

iOS SDKのデリゲート登録とSceneDelegate起動パターン

iOSでは、Objective-Cブリッジングヘッダーで#import "OpoInstallSDK.h"を公開し、Info.plistでcom.opoinstall.APP_KEYを構成し、OpoInstallDelegateを実装します。シーンベースのライフサイクル管理を採用していないアプリケーションの場合はAppDelegateのURL処理メソッドを使用します。シーンベースのアプリケーションの場合は、対応するSceneDelegateメソッドを介してコールドスタートおよびウォームレジュームのユニバーサルリンクとURLスキームを処理します：

// File: AppDelegate.swift & SceneDelegate.swift (Illustrative Integration Pattern)
// Note: Verify exact Objective-C bridging headers and method signatures against your downloaded iOS SDK v2.1.0 archive.
import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

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

    // For apps that do NOT adopt UISceneDelegate lifecycle management:
    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
    }

    func getWakeUpParams(_ appData: OpoinstallData?) {
        print("Wakeup data: \(String(describing: appData?.data)), channelCode: \(String(describing: appData?.channelCode))")
    }

    func fetchInstallParameters() {
        OpoInstallSDK.defaultManager()?.getInstallParmsCompleted({ (appData: OpoinstallData?) in
            print("Install data: \(String(describing: appData?.data)), channelCode: \(String(describing: appData?.channelCode))")
        })
    }
}

// For iOS 13+ apps that adopt UISceneDelegate lifecycle management:
@available(iOS 13.0, *)
class SceneDelegate: UIResponder, UIWindowSceneDelegate {
    var window: UIWindow?

    func scene(
        _ scene: UIScene,
        willConnectTo session: UISceneSession,
        options connectionOptions: UIScene.ConnectionOptions
    ) {
        for userActivity in connectionOptions.userActivities {
            OpoInstallSDK.continue(userActivity)
        }
        for urlContext in connectionOptions.urlContexts {
            OpoInstallSDK.handLinkURL(urlContext.url)
        }
    }

    func scene(_ scene: UIScene, continue userActivity: NSUserActivity) {
        OpoInstallSDK.continue(userActivity)
    }

    func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
        for urlContext in URLContexts {
            OpoInstallSDK.handLinkURL(urlContext.url)
        }
    }
}

エンジニアリングチームがサードパーティ製モバイルSDKを統合すべきタイミング

専用モバイルSDKの統合が適したシナリオ

専用のモバイルアトリビューションおよびディープリンクSDKの統合は、次のような場合に適切です：

• コード不要のリファラルおよびオンボーディングフロー: リファラルプログラムやマルチプレイヤーのルーム招待を実行するアプリケーションにおいて、ストアインストール後に手動コード入力なしでパラメータ（?ref=userAやroom_id=402）を復元する必要がある場合。
• マルチチャネルのH5およびQRコードキャンペーン: ソーシャルネットワーク、オフラインのQRコード、および訪問、クリック、インストール、登録の統合追跡を必要とするAndroidチャネルパッケージにわたってリンクを配信するマーケティングチーム。
- ワンクリックでのWebからアプリへの起動: ユニバーサルリンクやApp Linksを介して既存のアプリユーザーをモバイルブラウザから特定のアプリ内ビューに直接ルーティングしつつ、未インストールのユーザーを適切なApp Storeに誘導するプロダクト。

ダイレクトREST APIで十分なシナリオ

逆に、ワークフローがネイティブモバイルのサンドボックスを跨がない場合、クライアントサイドのアトリビューションSDKは不要です：

• 認証済みバックエンドトランザクション: すでに認証されたユーザーがサブスクリプションを更新したり、バックエンドの課金ウェブフックをトリガーしたりする場合、ダイレクトなServer-to-Server（S2S）REST APIを介してそのコンバージョンを記録することで、クライアントの依存関係の更新を回避できます。
• ブラウザ専用のWebアプリケーション: プログレッシブWebアプリ（PWA）や、App StoreまたはGoogle Playを通じてネイティブバイナリを配信しないモバイルWebサイトは、標準的なファーストパーティのWebクッキーとURLクエリパラメータを使用してリファラルを追跡できます。

モバイルSDKに関する一般的なエンジニアリングの誤解

• 誤解1：モバイルSDKを統合すると、アプリのコールドスタートが自動的にブロックされる: 優れた設計のモバイルSDKは、Application.onCreate()やdidFinishLaunchingWithOptions:の処理を最小限に抑え、ネットワーク操作を非同期実行に移行させます。ただし、開発者はターゲットビルドでコールドスタートのレイテンシを常にプロファイルすべきです。
• 誤解2：AndroidチャネルパッケージがH5リンクのチャネルIDを上書きする: AndroidアプリがエクスポートされたチャネルAPKとH5チャネルリンクの両方を使用する場合、OpoInstall SDKではカスタムパラメータとチャネルIDを一緒に取得できます。OpoInstallのプロダクトドキュメントによれば、インストールが異なるchannelCodeを持つH5チャネルリンクに由来する場合、統計レポートではチャネルパッケージIDよりもH5チャネルリンクIDが優先されます。

まとめとアーキテクチャ上の決定フレームワーク

SDKとは何か、そしてそれがモバイルOSのサンドボックス内でどのように機能するかを理解することは、エンジニアリングチームが信頼性の高いユーザー獲得およびディープリンクアーキテクチャを設計する上で役立ちます。ステートレスなWeb APIはリモートサーバーとの通信を処理しますが、アプリケーションがネイティブのライフサイクルイベントに参加したり、プラットフォーム固有のインストールシグナルを取得したりする必要がある場合には、ネイティブのクライアントサイド統合が必要となり、モバイルSDKはこれらの機能を再利用可能な統合レイヤーにパッケージ化します。

アトリビューションパイプラインの構造を決定する際は、以下のエンジニアリングガイドラインを適用してください：

• ネイティブモバイルSDKをデプロイする: ユーザーの導線がH5ランディングページ、ソーシャルシェア、またはQRコードからApp StoreまたはGoogle Playを経由し、自動パラメータ復元またはワンクリックのユニバーサルリンク / App Linkルーティングを必要とする場合。

• サーバー間HTTP APIを使用する: 集約されたチャネル統計を内部データウェアハウスにエクスポートする場合、またはクライアント側の起動コンテキストに依存しないバックエンドイベントを記録する場合。

• バイナリのコンパイルとプラットフォームのプライバシーコンプライアンスを検証する: 本番リリース前に、ターゲットのSDKアーカイブ（v2.1.0など）をクリーンなプロジェクトで常時コンパイルテストし、iOSのマッチングメカニズムが禁止されているデバイスフィンガープリンティングを回避していることをベンダーに確認してください。

アトリビューションインフラストラクチャを評価するエンジニアリングチームは、OpoInstall開発者コンソールでアプリケーションキーを登録し、ステージング環境でパラメータの復元とディープインクルーティング（ディープリンクルーティング）をテストできます。

関連資料

• 概念: ソフトウェア開発キット、アプリケーションプログラミングインターフェース、遅延ディープリンク、OSサンドボックス隔離

• テクノロジー: Androidアーカイブ（.aar）、iOS XCFramework、Google Playインストールリファラー、Appleユニバーサルリンク

• 標準: IETF RFC 9110 HTTPセマンティクス、IETF RFC 9110 URI汎用構文、OWASPモバイルアプリケーションセキュリティプロジェクト

• プラットフォームおよび統合インターフェース: Android Application.onCreate、iOS UIApplicationDelegate、UISceneDelegate、NSUserActivity

• 公式ドキュメントおよび参考資料:

  • アプリケーションライフサイクルに関するGoogle Android開発者ガイド

  • App Linksに関するGoogle Android開発者ガイド

  • Google PlayインストールリファラーAPI技術ガイド

  • UIApplicationDelegateに関するApple開発者ドキュメント

  • UISceneDelegateに関するApple開発者ドキュメント

  • ユニバーサルリンクのサポートに関するApple開発者ドキュメント

  • マルチプラットフォームバイナリフレームワークバンドル（XCFramework）の作成に関するApple開発者ドキュメント

  • Appleユーザープライバシーおよびデータ使用に関するガイドライン