iOS SDKの実装ガイド：マーケター向け

背景

iOS 14以降、IDFAの収集にはアプリユーザーの同意が必要になります。実際には、IDFAへのアクセスはApp Tracking Transparency (ATT) によって管理されることを意味します。そのため、iOS14以降の端末においては、AppsFlyerのiOS SDKもATTのフレームワークを利用して端末のIDFAへのアクセスを得ることになります。 

ATTの概要については、ATTの基本仕様を参照してください。

IDFAを利用した計測が発生する場合には、IDFAが初回起動(first launch)のイベントとともに送信されることが重要になります。このため、AppsFlyer SDKではwaitForATTUserAuthorizationという機能を提供しています。

waitForATTUserAuthorization について

waitForATTUserAuthorizationを使用することで、ATTへの同意が完了するのを待って、AppsFlyerサーバーへデータ送信するのを延期する期間を設定することが可能です。

ユーザーがアプリを起動した時、ATTステータスはnotDetermined(未確定)の状態です。waitForATTUserAuthorizationのタイムアウト中：

• SDKは、オフライン時のイベント計測方法と同様の方式で、起動イベントとその後のアプリ内イベントをメモリ内に待機させます。
• ユーザーがATTプロンプト(IDFAの収集)に同意 した場合：
  • SDKはメモリ内に待機させたイベントにもIDFAを追加します。
  • SDKは計測を開始し、メモリ内に待機させたイベントにIDFAを添えて、タイムアウトが終了するのを待たずに送信します。
• ユーザーがATTプロンプトを拒否した場合：
  • SDKは計測を開始し、メモリ内に待機させたイベントにIDFAを添えず、またタイムアウトが終了するのを待たずに送信します。
• タイムアウトが終了し、ATTの 同意ステータスが未決定(=notDetermined)のままだった場合 ：
  • SDKは計測を開始し、メモリ内に待機させたイベントをIDFAを添えずに送信します。

注意事項

• waitForATTUserAuthorizationを設定せずにrequestTrackingAuthorizationを呼び出してしまうと、iOS14以降の端末ではIDFAを取得せずに起動とその後のアプリ内イベントを送信してしまうので注意してください。
• タイムアウト中にユーザーがアプリをバックグラウンドに移動した場合：
  • ユーザーが再度アプリを表示させる(フォアグラウンドに戻す)まで、タイマーが一時停止されます。
  • イベントはメモリ内にキャッシュされます。
• タイムアウト中にユーザーがアプリをシャットダウンまたは強制終了(=キル)した場合：
  • タイマーは、次回のアプリの起動時に再開されます。
  • キャッシュされたイベントは削除されます。

ATTの同意ダイアログをカスタマイズすることも可能です。ATTのダイアログでその目的を明確に示したメッセージを届けることは、ユーザーのオプトイン率を高めるのに役立ちます。

メッセージを作成するときには、以下のポイントに注意してください：

• アプリがユーザーの同意を求めている理由を、ユーザーにもっとも分かりやすく説明しているテキスト/単語を使用しましょう。
• データがどのように利用されるのかについてユーザーに知らせましょう。ユーザープライバシーとデータ利用の詳細については、こちらを参照してください。

メッセージが完成したら、開発担当者にそのテキストとこちらのガイドを共有してください。

ATTダイアログの実装例を見たい場合には、こちらを参照してください。

SKANは iOS で使用されるクラスで、広告主アプリのインストールを検証します。アプリのインストール検証プロセスには、ソースアプリ(≒広告配信面のアプリ)と広告主アプリが関係します。 

ソースアプリとは、アドネットワークによって署名された広告を表示している、広告掲載面としてのアプリです。広告を表示するようにアプリに設定することは、AppsFlyer SDKのサポート範囲ではありません。設定する場合には、Appleのガイドに従ってください。

広告主アプリ (AppsFlyer SDKを実装しているアプリ) の場合、AppsFlyerの  SKANソリューションはSKANを使用してアトリビューションのポストバックを提供し、AppsFlyerはユーザーのプライバシーを維持しながらデータを収集、翻訳、集計します。アプリを初回起動すると、AppsFlyerはマーケティング担当者が事前に設定した内容を使用して、SKANのコンバージョン値の設定方法をSDKに指示します。

SKANソリューションの使用方法：

• マーケティング担当者は、AppsFlyerの管理画面上でSKANの計測に関する設定を行う必要がありますが、開発担当者は何も追加作業を行う必要はありません。
• AppsFlyer SDK は自動で 必要なSKAN APIを呼び出します。
• SKANの計測においてAppsFlyerを利用する場合には、他のSDKではSKANに関する呼び出しを全て無効にしてください。
• AppStoreにおいて、開発者、マーケティング担当者のどちらも、この他に何も特別なアクションや登録プロセスは必要ありません。 

SKANの計測を無効にするには、SDK内で無効にするように開発担当者へ依頼してください。

収益の情報は、どのアプリ内イベントでも送信できます。収益を計測する際には、必ずaf_revenueのパラメータを使用していることを確認してください。af_revenueは、AppsFlyerのローデータと管理画面で収益としてカウントされる、唯一のイベントパラメータです。詳細については、こちらを参照してください。 

開発担当者向けの手順については、収益の計測を参照してください。

AppsFlyerのSDKでは、アプリ内購入をサーバーにて検証できます。 アプリ内購入を検証するとアプリ内イベントが自動的にAppsFlyerに送信されます。このイベントを別途送信すると、重複してイベントをレポートすることになるので注意してください。

旅行、ゲーム、Eコマースといった特定のカテゴリーのアプリの場合には、 業種別のアプリ内イベントの推奨リストも参照してください。

まだアプリをインストールしていないユーザーの場合、OneLinkはそのユーザーの端末の種類を判別して正しい遷移先 (GooglePlay、AppleのAppStore、サードパーティのアプリストア、もしくはウェブページ) へリダイレクトさせます。この挙動は予め設定されたOneLinkテンプレートの内容に基づきます。詳細はこちら

注：端末の判定とリダイレクトには、AppsFlyer SDKは必要ありません。ただし、ディープリンクにはSDKが必要です。

アプリを既にインストールしているユーザーの場合、OneLinkはアプリを起動します。また、アプリを開くだけでなく、アプリ内の特定のアクティビティやページへユーザーをディープリンクさせることも可能です。そのためには、開発者側でユニファイドディープリンク(UDL)を実装する必要があります。

注意：

• UDLの利用には、SDK V6.1以上の実装が必要です。
• なお、ディープリンクのためにOneLinkを既に使用しているお客様は、UDLではなく従来の方法を使用している可能性があります。

OneLinkでのディープリンク設定 のガイドを参照してください。

まだアプリをインストールしていないユーザーの場合、OneLinkはそのユーザーの端末の種類を判別して正しい遷移先 (GooglePlay、AppleのAppStore、サードパーティのアプリストア、もしくはウェブページ) へリダイレクトさせます。そのユーザーがアプリを初回起動した際に、ディファードディープリンクを使用して、アプリ内の特定のアクティビティやページにユーザーをリダイレクトさせることが可能です。

そのためには、開発者側でユニファイドディープリンク(UDL)を実装する必要があります。

注意：

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

詳細については、ディファードディープリンクのガイドを参照してください。

AppsFlyerは、Google Cloud Messaging または Apple push notification を含む全てのベンダーのプッシュ通知キャンペーンの測定をサポートしています。プッシュ通知メッセージから発生したアプリ起動として定義されたコンバージョンは、AppsFlyerのリターゲティングダッシュボードに表示されます。

OneLinkを使用することで、プッシュ通知で復帰したユーザーをリエンゲージメントとして計測することも可能です。詳細はプッシュ通知によるリエンゲージメントの測定のページをご確認ください。

アンインストール計測の実装方法については、 こちらを参照してください。

SDKが正常に起動し、AppsFlyerサーバーに通知されたことを確認したい場合には、 startWithCompletionHandler というhandlerを実装してください。その後、SDK起動の成功または失敗を処理するロジックを適用できます。

実装例

[[AppsFlyerLib shared] startWithCompletionHandler:^(NSDictionary<NSString *,id> *dictionary, NSError *error) {
        if (error) {
            NSLog(@"%@", error);
            return;
        }
        if (dictionary) {
            NSLog(@"%@", dictionary);
            return;
        }
    }];

 AppsFlyerLib.shared()?.start(completionHandler: { (dictionnary, error) in
            if (error != nil){
                print(error ?? "")
                return
            } else {
                print(dictionnary ?? "")
                return
            }
        })

リクエストリスナー中にエラーが発生した場合には、次の表に示すように、エラーコードと文字列での説明が提供されます。

setAdditionalData API を使用すると、SDK から送信されたイベントにカスタムデータを更に追加できます。特に、Segment、Adobe、Airshipなどの外部のパートナープラットフォームとSDKレベルで連携する際には、このAPIが必要になります。

setAdditionalData コード例：

NSDictionary* customDataMap = [[NSDictionary alloc] initWithObjectsAndKeys:@"value_of_param_1", @"custom_param_1", nil];
[[AppsFlyerLib shared] setAdditionalData:customDataMap];

let customDataMap: [AnyHashable: Any] = [
  "custom_param_1" : "value_of_param_1"
]
AppsFlyerLib.shared().customData= customDataMap

(OneLink以外で)ディープリンクのためにユニバーサルリンクを使用し、アプリに関連付けられたドメインを持っている広告主は、appendParametersToDeepLinkingURLのメソッドを使用することで、それらのドメインを介して開始された起動を計測できます。

たとえば、ユーザーがGoogleで検索し御社のドメイン：www.example.comをクリックしたとします。

• ユーザーがアプリをインストールしていない場合には、そのままWebサイト(www.example.com)に遷移します。
• ユーザーが既にアプリを端末にインストールしている場合には、www.example.comに関連付けられたアプリがディープリンク起動されます。この起動イベントをappendParametersToDeepLinkingURL内で指定されたメディアソース (pidパラメータ)に紐づけて計測することができます。

詳細は、iOS SDKのAPIリファレンスを参照してください。

Point： スマートバナーは、Webサイトに訪問したユーザーをアプリユーザーに変換するのにとても役立ちます。

デフォルトでは、それぞれ別のセッションとしてカウントされるには、２つのアプリ起動の間隔が少なくとも5秒以上あいている必要があります（詳細は 「セッション数のカウント」を参照してください）。

セッション間の最小時間を設定したい場合には、次のAPIを使用してください：

[AppsFlyerLib shared].minTimeBetweenSessions = <your_custom_time_in_seconds>;

AppsFlyerLib.shared().minTimeBetweenSessions = <your_custom_time_in_seconds>

セッション間のカスタム時間に大きい値を設定すると、ディープリンクなどのセッションデータに依存するAPI へ悪影響を与える可能性があるので注意してください。

iOSでは利用できません。 

メールサービスプロバイダー(ESP)などの一部のサードパーティサービスは、独自のクリック計測用ドメインでメール内の計測リンクを変換してしまいます。一方で元々のクリック計測URLを設定できるものもあります。もしもOneLinkがクリック計測用に変換された場合、OneLinkの機能が制限される可能性があります。

この問題を解決するには、 setResolveDeepLinkURLs のAPIを使用してください。このAPIを使用することで、アプリを起動するクリックドメインからOneLinkを取得することが可能です。このAPIはSDK初期化よりも前に必ず呼び出してください。

たとえば、あなたのOneLink（https://mysubdomain.onelink.me/abCD）にリダイレクトする3つのクリックドメインがあったときにも、このAPIを使用することで、そのクリックドメインたちがリダイレクトするOneLinkを取得可能です。このAPIメソッドはSDKが分析するクリックドメインのリストを受け取ります。

[AppsFlyerLib shared].resolveDeepLinkURLs = @[@"example.com",@"click.example.com"];

AppsFlyerLib.shared().resolveDeepLinkURLs = ["example.com", "click.example.com"]

上記のコードを使用すると、OneLinkの機能を維持しながらクリックドメインを使用できます。そのクリックドメインは、アプリの起動を担います。このAPIは、順番に、これらのクリックドメインからOneLinkを取得し、そのデータを使ってカスタマイズされたユーザーコンテンツへのディープリンクを可能にします。

AppsFlyerでは、リターゲティングキャンペーンの一部として、プッシュ通知を計測できます。 プッシュ通知の計測に関する詳細は、こちらを参照してください。

アプリの既存ユーザーがアプリに友人を招待できるようにすることが、アプリインストール増加のきっかけとなる場合があります。AppsFlyerを使用することで、アプリ内のユーザー招待から発生したインストールの計測を行うことが可能です。

詳細は、ユーザー招待の計測のガイドを参照してください。

注意！ IDFVによるクロスプロモーションの実施には、SDK V6.0.2以上の実装が必要になります。なお、IDFVは自動的に収集されるので、アプリ開発者側での追加作業は不要です。

AppsFlyer IDは、ユーザーがアプリをインストールする度に作成されるユニークなIDで、さまざまな目的に利用可能です。

• サーバー間(S2S)イベントを送信するとき
• 広告主側で持っているシステム上のユーザー情報と一致させるとき
• Pull APIとPush APIのデータをマージするときに、各データを突合させるとき

AppsFlyer IDを取得するには、次のAPIを使用してください。

NSString *appsflyerId = [AppsFlyerLib shared].getAppsFlyerUID;

let appsflyerId = AppsFlyerLib.shared().getAppsFlyerUID()

カスタマーユーザーIDを設定するには：

[AppsFlyerLib shared].customerUserID = @"my user id";

AppsFlyerLib.shared().customerUserID = "my user id"

iOSでは、アプリを起動するたびにカスタマーユーザーIDを設定する必要があります。設定された後に計測されたイベントにしかカスタマーユーザーIDを紐付けられないので、AppsFlyerでは、 アプリ利用の一連の流れの中で、できる限り早いタイミングでカスタマーユーザーIDを設定することをお勧めしています。

• startを呼び出す前に setCustomerUserId が呼び出された場合には、インストールおよびイベントのローデータレポートにカスタマーユーザーIDが表示されます。
• trackAppLaunchよりも後に設定された場合には、カスタマーユーザーIDはその設定後に計測されたイベントへのみ紐付けられます。

最初の起動後にカスタマーユーザーIDの値を再度設定したり、IDを取得する通信をあなたのサーバーに必要以上にしないように、以下のコードを使用してIDの値が空かどうかを確認できます。 

NSString *customerUserID = [AppsFlyerLib shared].customerUserID;

let customerUserID = AppsFlyerLib.shared().customerUserID

カスタマーユーザーIDの詳細については、こちらをクリックしてくだい。

Customer User IDが設定されるまで、SDKの初期化を遅らせることも可能です。これは、インストールデータとアプリ内イベントデータの両方にCustomer User IDを含めたい場合に有効です。

次のコードを実装してください。

- (void)applicationDidBecomeActive:(UIApplication *)application {
    NSString *customUserId = [[NSUserDefaults standardUserDefaults] stringForKey:@"customerUserId"]; // Your custom logic of retrieving CUID
    if (customUserId != nil && ![customUserId  isEqual: @""]) {
        [AppsFlyerLib shared].customerUserID = customUserId; // Set CUID in AppsFlyer SDK for this session
        [[AppsFlyerLib shared] start]; // Start
    }
}

func applicationDidBecomeActive(_ application: UIApplication) {
        let customUserId = UserDefaults.standard.string(forKey: "customUserId")  //  your logic to retrieve CUID
        if(customUserId != nil && customUserId != ""){
            AppsFlyerLib.shared().customerUserID = customUserId // Set CUID in AppsFlyer SDK for this session
            AppsFlyerLib.shared().start() // Start
        }
    }

カスタマーユーザーIDが利用可能になるまでSDKの初期化を遅らせる方法の詳細については、こちらを参照してください。

GDPRやCOPPAへの同意など、ユーザーの同意が得られるまでSDKの初期化とデータの送信を遅延させたい場合があるでしょう。

注：これはiOS 14で導入されるATTとは無関係です。 

SDKの初期化を遅延させるには：

1. バックグラウンドからフォアグラウンドへの遷移時にセッションが送信されないようしてください。すべてのapplicationDidBecomeActive（セクション3.3に基づく）で呼び出されるsendLaunch()のメソッド内で、条件チェックの上startのコールをラップしてください。
   たとえば、以下のようになります：
   
   

   -(void)sendLaunch:(UIApplication *)application {
       if (consent_given) { // check the condition
           [[AppsFlyerLib shared] start]; // Start
       }
   }

2. 遅延する理由がなくなったら、条件が変更された直後にすぐセッションを送信してください。 最初のセッションデータを送信する準備ができたら、 start を呼び出してください。
   たとえば、以下のようになります：
   
   

   ...
   consent_given = YES; // change the condition
   [[AppsFlyerLib shared] start]; // Start
   ...

稀ではあっても場合によっては、法律やプライバシー遵守のために、すべてのSDKにおける計測を停止しなければならないケースがあります。その場合、isStoppedのプロパティを利用可能です。一度このプロパティがtrueに設定されと、AppsFlyer SDKは動作を停止し、すべての情報はAppsFlyerサーバーに送信されなくなります。 

ユーザーのオプトアウトには、さまざまなケースがあります。AppsFlyerでは、アプリに適したシナリオにあわせて正しい手順を守って実装するよう推奨しています。

[AppsFlyerLib shared].isStopped = true;

AppsFlyerLib.shared().isStopped = true

なお、同じAPIにてfalseを渡して呼び出すことにより、SDKを再アクティブ化することができます。

ユーザーのインストール、イベント、セッションの計測を明示的に匿名化するには、SDKの初期化中にこのAPIを使用してください。

[AppsFlyer shared].anonymizeUser = YES;

AppsFlyerLib.shared().anonymizeUser = true

anonymizeUser を false に設定することで、データの計測を再開できます。

StrictモードSDKを使用して、IDFAの収集機能とAdsupport frameworkの依存関係を除外してください。(たとえば、Kids向けアプリを開発する場合などに有効です。)

注意：IDFVは引き続き使用できます。

Podfile内で、AppsFlyerLibの依存関係を次のように置き換えてください：

pod 'AppsFlyerFramework/Strict','6.2.3'

AdSupportとiAd frameworkを無効化するために、SDKでは以下の機能を用意しています：

• disableCollectASA = true.詳細はこちら。
• disableAdvertisingIdentifier = true.詳細はこちら

ad frameworkを無効化するには：

[AppsFlyerLib shared].disableCollectASA = YES
[AppsFlyerLib shared].disableAdvertisingIdentifier = YES;

AppsFlyerLib.shared().disableCollectASA = true
AppsFlyerLib.shared().disableAdvertisingIdentifier = true

場合によっては、アドネットワークやパートナーに対する特定ユーザーのユーザーレベルのデータ共有を停止したい場合があるかと思います。その理由には次が挙げられます。

• CCPAやGDPRのようなプライバシーポリシー
• ユーザーによるオプトアウト
• 一部パートナー（広告ネットワーク/第三者ツール）との競合

パートナーとのデータ共有は、setSharingFilterForPartners メソッド で制御されます。