基本的なSDK連携ガイド

新しいアプリインストールごとに、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では、サードパーティアプリストアでの計測について。以下のようにサポートしています：

• IMEI、またはAndroid ID： AppsFlyer SDK では IMEI または Android ID を自動的には収集しません。ただし、これらの識別子が必要な場合には（例：中国国内市場のアプリなど）、開発者は以下の収集方法を実装できます。
  • 手動での収集： アプリは、IMEI または Android ID を setImeiData または setAndroidIdData API を使用してSDKに渡します（詳細は下のタブの関数リファレンスを参照）。その後、SDK はデータを AppsFlyer サーバーに送信します。
    Android ネイティブUnity

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

    •  
    •   

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

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

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

    •  
    •  

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

    •  
    •  

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

    •  
    •  
• 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 について

waitForATTUserAuthorization を利用することで、AppsFlyerサーバーにデータを送信する前に、SDKがATTへの回答ステータスをどれくらいの時間待機して、計測を保留するかを設定できます。初回起動時にIDFAを正確に取得する上で、非常に重要な設定になるので必ず詳細を確認の上、実装してください

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

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

考慮事項

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

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

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

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

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