この仕組みは、最初の5セッションの集計後に適用されます。 6回目以降は、設定したセッション間の最小時間を経過している場合に、セッションを計上します。 

セッションを計上→カウントダウンタイマーを開始→タイマーの動作中に報告されたセッションは計上しない、という流れです。 

例

前提：セッション間の最小時間は10分に設定され、最初の5セッションはすでに計上されています。

• デフォルト値：10分

• 以下の値を設定できます。 

  • 1～60分

  • 1～24時間

セッション間の最小時間のタイマーを設定するには、以下の手順を実施します。 

1. AppsFlyerのサイドメニューで、設定＞アプリ設定を選択します。
2. セッション間の最小時間を設定します。 
3. ［設定を保存］をクリックします。 
   変更は1時間以内に反映されます。

• リターゲティングのセッションは、2020年7月12日以降のデータで利用できます。
• 以下で確認できます。
  • Overview dashboardのリターゲティング表示と統合表示。 
  • コホートのリターゲティング表示と統合表示。 
    • 統合表示で、セッションがUAとリターゲティングの両方のメディアソースに紐付く場合は、リターゲティングのメディアソースが優先され、UAのメディアソースは表示されません。 
    • データ更新：日次、UTC 13:00。
  • Data Locker：リターゲティングセッションレポートを有効にできます。リエンゲージメントとリアトリビューションの両方のセッションが含まれます。 
    • データ更新：6時間の遅延。
• リエンゲージメント期間中、セッションはUAとリターゲティングの両方のメディアソースに紐付けられます。他のリエンゲージメントのアプリ内イベントも、同様に両方に紐付けられます。 
• Google広告とX広告では、ポストバックの重複を防ぐため、af_app_openedイベントは1回だけ送信されます。

パートナーにセッションポストバックを設定すると、計上されたセッションごとにポストバックが送信されます。 

• 送信するには、af_app_openedをパートナーのイベントに明示的にマッピングします。注意 Data Lockerで取得できるAppsFlyerのローデータレポートでは、このイベントはlaunchとして表示されます。
• このイベントは送信量が多く、多くのパートナーが受信を希望しない点に注意してください。 

アプリ側：SDKは、setMinTimeBetweenSessionsの設定を考慮したうえで、アプリの起動時やフォアグラウンドへの移行時にaf_app_opened を送信します。 

サーバー側：アプリの初回起動後の最初の5セッションに該当せず、かつセッション間の最小時間の判定条件を満たす場合に、セッションを計上します。計上されたセッションには、他のアプリ内イベントと同じアトリビューションルールが適用されます。

開発者による明示的なセッションの報告（Androidアプリのみ）

Androidでは、logSessionを使用して、明示的にセッションを報告します。 iOSには、同等の呼び出しはありません。

• 常にバックグラウンドで動作するアプリでは、開発者がセッション報告用のロジックを実装する必要がある場合があります。たとえば、バッテリー節約、ランチャー、画面ロック、ウイルス対策などのユーティリティアプリが該当します。こうしたアプリでは、毎日午前0時、またはアプリに適した別の間隔で、セッションを報告することを検討してください。
• また、［メモリを解放］ボタンの押下など、特定のアプリ内アクションを実行した時点でセッションを数える方法もあります。

アプリ起動間の最小時間の設定

2つのセッションを別々に報告するために必要な最小の時間間隔を、SDKで設定します。

setMinTimeBetweenSessionsで、af_app_openedイベントをそれぞれ報告するために必要な、セッション間の最小時間を制御します。

• ［デフォルト］5秒。つまり、次のセッションを報告するまでに、少なくとも5秒が経過している必要があります。 
• APIで、セッション間に必要な最小時間を設定できます。

setMinTimeBetweenSessionsのSDKリファレンス：