コンテキスト対応セッション

仮想レポートスイートのコンテキストに応じたセッションは、Adobe Analytics が任意のデバイスからの訪問を計算する方法を変更します。また、この記事では、（モバイル SDK によって設定される）バックグラウンドヒットとアプリ起動イベントの処理がモバイル訪問数の定義にどのように影響するかについて説明します。

訪問の定義は、基になるデータを変更することなく、訪問者がデジタルエクスペリエンスをどのように操作するかに応じて自由に変更できます。

デモビデオについては、 Context-aware sessions を参照してください。

顧客視点 URL パラメーター

Adobe Analytics データ収集プロセスでは、お客様の視点を指定するクエリ文字列パラメーター（「cp」クエリ文字列パラメーターと呼ばれます）を設定できます。 このフィールドは、エンドユーザーのデジタルアプリケーションの状態を指定します。 これにより、モバイルアプリがバックグラウンド状態の間にヒットが生成されたかどうかを把握できます。

バックグラウンドヒット処理

バックグラウンドヒットは、バックグラウンド状態でアプリがトラッキングリクエストを行ったときにAdobe Mobile SDK バージョン 4.13.6 以降から Analytics に送信されるヒットの一種です。 その典型的な例を次に示します。

次の例では、仮想レポートスイートに対して「バックグラウンドヒットによる新しい訪問の開始を防止」設定が有効になっている、または有効になっていない場合に、任意の訪問者の訪問がいつ開始し終了するかを決定するために使用されるロジックの概要を説明します。

「バックグラウンドヒットで新しい訪問が開始されないようにする」が有効になっていない場合：

この機能が仮想レポートスイートに対して有効になっていない場合、バックグラウンドヒットは他のヒットと同じように扱われ、新しい訪問が開始され、フォアグラウンドヒットと同じように機能します。 例えば、バックグラウンドヒットが、一連のフォアグラウンドヒットの前に 30 分未満（レポートスイートの標準セッションタイムアウト）発生した場合、バックグラウンドヒットはセッションの一部になります。

バックグラウンドヒットがフォアグラウンドヒットの 30 分以上前に発生した場合、バックグラウンドヒットによって独自の訪問が作成され、合計訪問回数は 2 になります。

「バックグラウンドヒットで新しい訪問が開始されないようにする」が有効になっている場合：

次の例は、この機能が有効になっているときのバックグラウンドヒットの動作を示しています。

例 1：バックグラウンドヒットが発生してから一定時間（t）が経って一連のフォアグラウンドヒットが発生したとします。

この例では、t が仮想レポートスイートで設定された訪問タイムアウトよりも大きい場合、バックグラウンドヒットは、フォアグラウンドヒットによって形成される訪問から除外されます。 例えば、仮想レポートスイート訪問タイムアウトが 15 分に設定されていて、t が 20 分の場合、この一連のヒットによる訪問（緑のアウトラインで示される）は、バックグラウンドヒットを除外します。 つまり、バックグラウンドヒットで「訪問」有効期限が設定された eVar は、次の訪問にも 保持されず、訪問セグメントコンテナには、緑色のアウトライン内のフォアグラウンドヒットのみが含まれます。

逆に、t が仮想レポートスイートで設定された訪問タイムアウトよりも小さい場合、バックグラウンドヒットは、前景ヒットのように（緑のアウトラインで示されます）訪問の一部として含まれます。

つまり、

どちらの場合も、訪問回数の合計は 1 になります。

例 2：一連のフォアグラウンドヒットが発生した後にバックグラウンドヒットが発生した場合の動作は次のようになります。

バックグラウンドヒットが、仮想レポートスイートの設定済みタイムアウトの後に発生した場合、バックグラウンドヒットは、セッションに含まれません（緑色で囲まれています）。

同様に、期間 t が仮想レポートスイートの設定されたタイムアウトよりも短かった場合、バックグラウンドヒットは、以前のフォアグラウンドヒットによって形成される訪問に含まれます。

つまり、

以前と同様に、どちらの場合も訪問総数は 1 になります。

例 3：状況により、バックグラウンドヒットの発生によって 2 つの訪問が 1 つの訪問にまとめられる場合があります。次のシナリオでは、バックグラウンドヒットの前後に、一連のフォアグラウンドヒットが続きます。

この例では、t1 と t2 の両方が、仮想レポートスイートで設定された訪問タイムアウトよりも小さい場合、t1 と t2 が訪問タイムアウトよりも大きい場合でも、これらのヒットはすべて 1 つの訪問に結合されます。

ただし、t1 と t2 が、仮想レポートスイートで設定されたタイムアウトよりも大きい場合、これらのヒットは、次の 2 つの異なる訪問に分割されます。

同様に（前の例と同様に）、t1 がタイムアウトより小さく、t2 がタイムアウトより大きい場合、バックグラウンドヒットが最初の訪問に含まれます。

t1 がタイムアウトより大きく、t2 がタイムアウトより小さい場合、バックグラウンドヒットが 2 回目の訪問に含まれます。

例 4：仮想レポートスイートで設定されている訪問タイムアウト期間内に一連のバックグラウンドヒットが発生した場合、バックグラウンドヒットは目に見えない「バックグラウンド訪問」を形成します。これらの訪問は訪問数にカウントされず、訪問セグメントコンテナを使用してアクセスすることもできません。

バックグラウンド訪問は訪問と見なされませんが、訪問の有効期間が設定された eVar の値は同じ「バックグラウンド訪問」で発生した他のバックグラウンドヒットにも引き継がれます。

例 5：一連のフォアグラウンドヒットが発生した後に複数のバックグラウンドヒットが連続して発生した場合、（タイムアウト設定によって異なりますが）それらのバックグラウンドヒットにより訪問タイムアウト期間を越えて 1 つの訪問が継続されることがあります。例えば、t1 と t2 の合計が仮想レポートスイート訪問タイムアウトよりも大きく、個別にはタイムアウトよりも小さい場合、訪問は引き続き、両方のバックグラウンドヒットを含むように拡張されます。

同様に、一連のフォアグラウンドイベントの前に一連のバックグラウンドヒットが発生した場合は、同様の動作が発生します。

バックグラウンドヒットでは、バックグラウンドヒット時に設定された eVar または他の変数からのアトリビューション効果を保持するために、この方法で動作します。 これにより、ダウンストリームフォアグラウンドコンバージョンイベントを、アプリがバックグラウンド状態にあるときに実行されたアクションに関連付けることができます。 また、訪問セグメントコンテナに、ダウンストリームのフォアグラウンドセッションを引き起こすバックグラウンドヒットを含めることもできます。これは、プッシュメッセージの有効性を測定する場合に役立ちます。

訪問指標の動作

訪問数は、少なくとも 1 つのフォアグラウンドヒットを含む訪問数にのみ基づいています。 つまり、孤立したバックグラウンドヒットまたは「バックグラウンド訪問」は、訪問指標にカウントされません。

訪問別滞在時間指標の動作

滞在時間は、バックグラウンドヒットがない場合と同様に、ヒット間の時間を使用して計算されます。 ただし、訪問にバックグラウンドヒットが含まれる場合（バックグラウンドヒットがフォアグラウンドヒットに対して十分に近く発生した場合）、それらのヒットは、フォアグラウンドヒットであるかのように、訪問ごとの滞在時間の計算に含まれます。

バックグラウンドヒット処理設定

バックグラウンドヒットの処理はレポート時間処理を使用している仮想レポートスイートでしか利用できないので、Adobe Analytics では、レポート時間処理を使用しないベースレポートスイートでも訪問数を維持できるように、2 種類のバックグラウンドヒット処理がサポートされています。この設定にアクセスするには、Adobe Analytics管理ツールに移動し、該当するベースレポートスイートの設定に移動して、「モバイル管理」メニュー、「モバイルアプリケーションレポート」サブメニューの順に移動します。

どちらの場合も、バックグラウンドヒットは、Analytics に送信される他のヒットと同じコストで請求されます。

アプリが起動するたびに新しい訪問を開始

仮想レポートスイートは、バックグラウンドヒットの処理に加えて、モバイル SDKがアプリ起動イベントを送信するたびに、新しい訪問を強制的に開始できます。 この設定を有効にすると、アプリ起動イベントがSDKから送信されるたびに、オープン訪問がタイムアウトに達しているかどうかに関係なく、新しい訪問が強制的に開始されます。 アプリ起動イベントを含むヒットは、次回の訪問の最初のヒットとして含まれ、訪問数を増分し、セグメント化用に個別の訪問コンテナを作成します。