アプリが新規インストールされるたびに、AppsFlyer IDが自動的に作成されます。マーケティング担当者による作業は不要です。

この識別子を使用して、以下の操作を行えます。

• サーバー間（S2S）でアプリ内イベントを送信します。
• AppsFlyer IDを、バックエンドシステムのユーザーレコードと照合します。
• アプリ内イベントのローデータレポートをダウンロードし、appsflyer_idを使用してユーザーの行動やジャーニーを分析します。

AppsFlyer SDKに独自の顧客ユーザーID（CUID）を設定すると、BIシステムの一意のIDを、AppsFlyer IDやその他の識別子と照合できます。 CUIDは、AppsFlyerのローデータレポートで確認できます。ポストバックAPIでもCUIDを使用し、自社の内部IDと照合できます。

CUIDの詳細は、こちらの記事をご覧ください。

Google Play Install Referrer

Google Play Install Referrer APIは、アトリビューションの精度を高め、インストール不正を防ぎます。また、Google Playからリファラデータ（初回インストール時のアプリバージョンなど）を安全に取得できます。

Google Play Install Referrer APIを追加する手順を開発者に共有することをおすすめします。

GAID

SDK V4.8.0以降では、AppsFlyerがこのデバイス識別子を自動的に収集します。

AppsFlyerでは、Amazon、Opera、GetJar、Baidu、Huaweiなど、サードパーティのアプリストア経由のインストールをアトリビューションできます。 これにより、Google Playストアを利用できない市場でもアプリを宣伝し、より多くのユーザーにリーチできます。

AppsFlyerは、サードパーティのアプリストアにおけるアトリビューションを、以下の方法でサポートしています。

• IMEIまたはAndroid ID：SDKは、IMEIやAndroid IDを自動的には収集しません。ただし、これらの識別子を収集する必要がある場合（中国国内市場向けのアプリなど）は、開発者が以下のいずれかの収集方法を実装できます。

  • 手動収集：アプリがsetImeiDataまたはsetAndroidIdData APIを使用して、IMEIまたはAndroid IDをSDKに渡します（以下のタブにある関数リファレンスを参照）。 SDKは、このデータをAppsFlyerサーバーに送信します。

    Androidネイティブ

    以下の関数については、Android SDKリファレンスをご覧ください。

    • setImeiData
    • <0><1>setAndroidIdData1>0> 

    Unity

    以下の関数については、Unity SDKリファレンスをご覧ください。

    • setImeiData
    • setAndroidIdData

  • デバイスID収集のオプトイン：setCollectIMEIとsetCollectAndroidIDを使用して、SDKによるIMEIまたはAndroid IDの収集を有効にします（以下のタブにある関数リファレンスを参照）。

    Androidネイティブ

    以下の関数については、Android SDKリファレンスをご覧ください。

    • setCollectIMEI
    • setCollectAndroidID

    Unity

    以下の関数については、Unity SDKリファレンスをご覧ください。

    • setCollectIMEI
    • setCollectAndroidID

    React Native

    以下の関数については、React Nativeのリファレンスをご覧ください。

    • setCollectIMEI
    • setCollectAndroidID
• OAID：サードパーティのAndroidアプリストア経由のインストールをアトリビューションします。詳細は、OAIDの実装ガイドをご覧ください。
• インストールリファラ：SDKは、Samsung Galaxy StoreとHuawei AppGalleryからのリファラデータの取得に対応しています。

背景

iOS 14.5以降では、IDFAの収集にユーザーの同意が必要です。つまり、IDFAへのアクセスは、App Tracking Transparency（ATT）フレームワークによって管理されます。 iOS 14以降のデバイスでは、SDKがATTフレームワークを使用してデバイスのIDFAにアクセスします。 ATTの基本的な仕組みについては、ATTの基本原則をご覧ください。

IDFAを使用してアトリビューションを行う場合は、IDFAを初回起動時に送信することが重要です。 このため、SDKにはwaitForATTUserAuthorizationメソッドが用意されています。

waitForATTUserAuthorizationの概要

waitForATTUserAuthorizationを使用すると、AppsFlyerサーバーへのデータ送信を保留し、SDKがATTのステータスの確定を待つ時間を設定できます。

ユーザーがアプリを起動すると、ATTのステータスはnotDeterminedです。 waitForATTUserAuthorizationのタイムアウト時間中、SDKは起動イベントと、その後に発生するアプリ内イベントをメモリ上のキューに保存します。これは、オフラインイベントを記録する仕組みと同様です。

• ユーザーがATTの同意ダイアログで同意した場合（IDFAの収集）：
  • SDKは、キャッシュされたイベントにIDFAを追加します。
  • SDKは起動し、タイムアウト時間の終了を待たずに、IDFAを含むキャッシュ済みイベントを送信します。
• ユーザーがATTの同意ダイアログで拒否した場合：SDKは起動し、タイムアウト時間の終了を待たずに、IDFAを含まないキャッシュ済みイベントを送信します。
• タイムアウト時間が終了してもATTのステータスがnotDeterminedのままの場合：SDKは起動し、IDFAを含まないキャッシュ済みイベントを送信します。

考慮事項

• requestTrackingAuthorizationを、waitForATTUserAuthorizationを設定せずに呼び出すと、iOS 14以降のデバイスでは、起動イベントやその他のイベントがIDFAを含まずに送信されます。
• タイムアウト時間中にユーザーがアプリをバックグラウンドに移した場合：
  • アプリがフォアグラウンドに戻るまで、タイマーが一時停止します。
  • イベントはメモリ上にキャッシュされます。
• タイムアウト時間中にユーザーがアプリを終了し、アプリのプロセスが停止した場合：
  • 次回のアプリ起動時に、タイマーが再開始されます。
  • キャッシュされたイベントは失われます。

ATTの同意ダイアログはカスタマイズできます。同意を求める目的を明確に伝えるメッセージを表示すると、ユーザーの同意率向上につながる可能性があります。

メッセージを作成する際は、以下の点を考慮してください。

• アプリが同意を求める理由を、ユーザーに最も分かりやすく伝えられる表現を使用します。
• ユーザーのデータをどのように使用するかを伝えます。 ユーザーのプライバシーとデータの使用に関する詳細をご覧ください。

メッセージが完成したら、文面と実装手順を開発者に共有してください。

SKANは、広告経由のアプリインストールを検証するためにiOSが使用するクラスです。アプリインストールの検証には、広告を表示するアプリと、広告対象のアプリが関わります。

広告を表示するアプリとは、アドネットワークの広告を表示することで広告キャンペーンに参加するアプリです。アプリに広告を表示するための設定は、AppsFlyer SDKの対応範囲外です。設定するには、Appleの手順に従ってください。

広告対象のアプリ（AppsFlyer SDKを実装したアプリ）では、AppsFlyerのSKANソリューションがSKANを使用してアトリビューションのポストバックを提供します。AppsFlyerは、ユーザーのプライバシーを保護しながら、データの収集・変換・集計を行います。アプリの初回起動時には、マーケティング担当者が指定した設定に基づき、AppsFlyerプラットフォームがSDKにSKANコンバージョン値の設定方法を指示します。

SKANソリューションを利用するには、以下の点を確認してください。

• マーケティング担当者は、AppsFlyerでSKAN計測を設定する必要があります。 開発者による作業は不要です。
• AppsFlyer SDKが、必要なSKAN APIを自動的に呼び出します。
• AppsFlyerでSKANアトリビューションを行う場合は、他のSDKによるSKANの呼び出しを必ず無効にしてください。
• 開発者・マーケティング担当者ともに、App Storeで追加の操作や登録を行う必要はありません。

SKANアトリビューションを無効にするには、SDK側で無効にするよう開発者に依頼してください。

収益は、どのアプリ内イベントでも送信できます。収益を含める場合は、必ずaf_revenueパラメータを使用してください。 AppsFlyerがダッシュボードとローデータレポートで実際の収益として集計するイベントパラメータは、このパラメータのみです。 詳細はこちら。

AppsFlyer SDKは、アプリ内購入のサーバー側での検証に対応しています。アプリ内購入を検証すると、アプリ内購入イベントがAppsFlyerに自動送信されます。このイベントを別途送信すると、イベントが重複して記録されます。

旅行、ゲーム、Eコマースなどの業種別の推奨アプリ内イベント一覧をご覧ください。

アプリをインストールしていないユーザーに対しては、OneLinkがデバイスの種類を検出し、適切な遷移先（Google Play、Apple App Store、サードパーティのアプリストア、Webページなど）にリダイレクトします。リダイレクト先は、OneLinkテンプレートの設定に基づいて決まります。 詳細はこちら

アプリをインストール済みのユーザーに対しては、OneLinkがアプリを起動します。アプリを起動するだけでなく、ディープリンクによってアプリ内の特定のアクティビティやページにユーザーを誘導することも可能です。この機能を利用するには、開発者が以下のいずれかを使用して、統合ディープリンク（UDL）を実装する必要があります。

• ディープリンクの実装専用の手順が用意されているSDK実装ウィザード、または
• 統合ディープリンクのSDK実装手順。

注意：

• UDLには、SDK V6.1以降が必要です。
• すでにOneLinkでディープリンクを利用している場合は、UDLではなく従来の方法を使用している可能性があります。

設定方法は、ディープリンクとディファードディープリンクのガイドをご覧ください。

アプリをインストールしていないユーザーに対しては、OneLinkがデバイスの種類を検出し、Google Play、Apple App Store、サードパーティのアプリストア、Webページなど、適切な遷移先にリダイレクトします。ユーザーがアプリを起動した後は、ディファードディープリンクを使用して、アプリ内の特定のアクティビティやページに誘導できます。

この機能を利用するには、開発者が以下のいずれかを使用して、ディファードディープリンクを実装する必要があります。

• ディープリンクの実装専用の手順が用意されているSDK実装ウィザード、または
• ディファードディープリンクのSDK実装手順。

注意：

• UDLには、SDK V6.1以降が必要です。
• すでにOneLinkでディファードディープリンクを利用している場合は、UDLではなく従来の方法を使用している可能性があります。

設定方法は、ディープリンクとディファードディープリンクのガイドをご覧ください。