新しいアプリインストールごとに、AppsFlyer IDが自動的に作成されます。マーケティング担当者による追加の作業などは必要ありません。

このAppsFlyer IDを利用することで、以下のようなことが実現可能です：

• Server-to-Serverでのアプリ内イベントの送信
• AppsFlyer IDと自社システムのユーザーデータの照合
• ローデータのアプリ内イベントレポートによる、appsflyer_id単位でのユーザージャーニーのやアプリ内行動の分析

AppsFlyer SDKで顧客ユーザーID（CUID）を設定し、自社BIシステム側で発行しているユーザーIDをAppsFlyer IDやその他の広告IDなどと紐づけて計測することが可能です。 CUIDはAppsFlyerのローデータレポート上で確認が可能になります。ポストバックAPIで内部IDと相互参照するために利用することもできます。

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

［重要］Google Playインストールリファラー

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 supports attribution in the context of third-party app stores as follows:

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

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

    Android native

    Android SDKリファレンスをご覧ください：

    • setImeiData
    • Androidネイティブ iOSネイティブ Unity React Native 

    Unity

    Unity SDKリファレンスをご覧ください：

    • setImeiData
    • setAndroidIdData

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

    Android native

    Android SDK リファレンスをご覧ください。

    • setCollectIMEI
    • setCollectAndroidID

    Unity

    Unity SDK リファレンスをご覧ください。

    • setCollectIMEI
    • setCollectAndroidID

    Android ネイティブUnityReact Native

    React Native リファレンスをご覧ください。

    • setCollectIMEI
    • setCollectAndroidID
• OAI： サードパーティ Android アプリストアからのインストールをアトリビューションします。詳細は OAID の実装ガイドを参照してください。
• インストールリファラー： SDKはSamsung GalleryとHuawei AppGalleryからのリファラーデータの取得をサポートしています。

背景

iOS 14.5 以降では、IDFA の収集にはユーザーの同意が必要です。具体的には、IDFA のアクセスは App Tracking Transparency (ATT)のフレームワークによって管理されます。 iOS 14以降の端末では、AppsFlyer SDKはATTフレームワークを使用してIDFAにアクセスします。 ATT の概要は、ATT の原則を参照してください。

SRN媒体をはじめ、IDFA を用いて計測を行うには、初回起動時に IDFA を送信することが非常に重要です。 それを実現するために、AppsFlyerでは waitForATTUserAuthorization というメソッドを提供しています。

［重要］waitForATTUserAuthorization について

ディープリンクデータ

ユーザーがアプリを初回起動したタイミングでは、ATTステータスは未決定となります。 そして、waitForATTUserAuthorization で設定した待機時間の間、SDKはオフラインイベントが記録される方法と同じ様に、起動イベントとその後のアプリ内イベントをメモリ内のキューに入れて待機させます：

• 設定した待機時間内に、ユーザーがATTプロンプト（IDFA取得）に同意した場合：
  • SDK側でそれまでキャッシュされていたイベントにもIDFAを追加します。
  • SDKが起動し、IDFAを付与した状態でキャッシュされたイベントを送信します。
• 設定した待機時間内に、ユーザーがATTプロンプト（IDFA取得）を拒否した場合：SDKが起動し、IDFAなしの状態でキャッシュされたイベントを送信します。
• 設定した待機時間が終了し、ATTステータスが 未決定 のままである場合： SDKがIDFAなしの状態でキャッシュされたイベントを送信します。

考慮事項

• requestTrackingAuthorizationを設定せずに waitForATTUserAuthorization を呼び出してしまうと、iOS 14以降の端末では起動とアプリ内イベントがIDFAが欠損した状態で送信されてしまうのでご注意ください。
• 設定した待機時間中に、ユーザーがアプリをバックグラウンドに移動させた場合：
  • アプリがフォアグラウンドに戻るまでタイマーは一時停止します。
  • イベントはメモリ内にキャッシュされます。
• 設定した待機時間中に、ユーザーがアプリをシャットダウンすると強制終了されます。
  • 次回のアプリ起動時に、タイマーが再開されます。
  • キャッシュされたイベントは失われます。

ATTの同意プロンプトは一部カスタマイズが可能です。同意取得の目的を的確に表現したメッセージは、ユーザーのオプトイン率を向上させるのに役立ちます。

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

• アプリがユーザーに同意を求める理由を、明確に説明する言葉を使いましょう。
• 取得したデータがどのように利用されるかをユーザーに知らせましょう。 ユーザーのプライバシーとデータ使用についての詳細はこちら。

メッセージが完成したら、開発者にテキストと実装手順を提供してください。

SKANは、iOSで広告主主導のアプリインストールを検証するために利用されるクラスです。アプリインストール検証プロセスには、ソースアプリと広告されるアプリが関与します。

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

広告されるアプリ（AppsFlyer SDKを搭載したアプリ）については、AppsFlyerのSKANソリューションがSKANを使用してアトリビューションポストバックを提供し、ユーザーのプライバシーを保護しながらデータを収集、変換、および集約します。アプリが初めて起動されると、AppsFlyerプラットフォームはマーケターが設定した内容に基づいて、SDKにSKANコンバージョン値を設定する方法を指示します。

SKANソリューションを使用するには：

• マーケターは、AppsFlyerでSKAN計測を設定する必要があります。 開発者は特に作業を行う必要はありません。
• AppsFlyer SDKは必要なSKAN APIを自動的に呼び出します。
• SKAN計測をAppsFlyerの機能に依存して行う場合は、他のSDKでのSKAN呼び出しを無効にしてください。
• App Storeでは、開発者やマーケターが取るべき追加の手続きや登録プロセスは必要ありません。

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

あらゆるアプリ内イベントで収益を計測・送信できます。収益をアプリ内イベントの情報に含めるには、必ず af_revenue のパラメーターを使用してください。これは、AppsFlyerが管理画面とローデータレポート上で実際の収益としてカウントする唯一のイベントパラメーターです。 詳細はこちら。

AppsFlyer SDK は、アプリ内購入についてサーバーによる検証を提供します。アプリ内購入が検証されると、購入イベントがAppsFlyerに自動的に送信されます。このイベントを自分で送信すると、重複レポートが発生します。

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

アプリをインストールしていないユーザーの場合、OneLinkはデバイスの種類を検出し、適切な宛先（例えば、Google Play、Appleアプリストア、サードパーティのアプリストア、またはウェブページ）にリダイレクトします。これは、OneLinkテンプレートの設定に基づいています。 詳細はこちら

アプリをインストールしているユーザーの場合、OneLinkによってアプリが起動されます。アプリを起動するだけでなく、アプリ内の特定画面やページにユーザーをディープリンクすることも可能です。これには、開発者がUnified Deep Linking (UDL)を実装する必要があります。

• SDKのインストールウィザードには、ディープリンク実装のための専用のプロセスがあります。
• https://dev.appsflyer.com/hc/docs/dl_work_flow#implement-unified-deep-linking-udl

注：

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

ディープリンクとディファードディープリンクの設定に関するガイドをご覧ください。

アプリをインストールしていないユーザーの場合、OneLinkはデバイスの種類を検出し、適切な宛先にリダイレクトします：Google Play、Appleアプリストア、サードパーティのアプリストア、またはウェブページ。ユーザーがアプリを起動すると、ディファードディープリンクを利用して、特定のアクティビティまたはページにリダイレクトできます。

This requires your developer to implement deferred deep linking using:

• SDKのインストールウィザードには、ディープリンク実装のための専用のプロセスがあります。
• https://dev.appsflyer.com/hc/docs/dl_work_flow#recommended-implement-extended-deferred-deep-linking

注：

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

ディープリンクとディファードディープリンクの設定に関するガイドをご覧ください。