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

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

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

以下は、コンテキスト対応セッションに関するビデオです。

顧客視点の 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 がタイムアウトより短い場合、バックグラウンドヒットはその次の訪問の一部として扱われます。

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

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

例 5：一連のフォアグラウンドヒットが発生した後に複数のバックグラウンドヒットが連続して発生した場合、（タイムアウト設定によって異なりますが）それらのバックグラウンドヒットにより訪問タイムアウト期間を越えて 1 つの訪問が継続されることがあります。例えば、t1 と t2 を合わせた時間が仮想レポートスイートのタイムアウトより長くても、それぞれの時間がタイムアウトより短い場合は、両方のバックグラウンドヒットが同じ訪問の一部として扱われます。

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

バックグラウンドヒットのこのような動作は、バックグラウンドヒットが続いている間に設定された eVar やその他の変数による属性の効果を維持することを目的としています。これにより、アプリがバックグラウンド状態のときに実行されたアクションにもダウンストリームのコンバージョンイベントを関連付けることが可能になります。また、ダウンストリームのフォアグラウンドセッションにつながったバックグラウンドヒットを訪問セグメントコンテナに含めることもできるようになるので、プッシュメッセージの効果を容易に測定できます。

訪問指標の動作

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

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

滞在時間は引き続き、バックグラウンドヒットを除く、ヒットからヒットまでの時間に基づきアナログ方式で計算されます。ただし、（バックグラウンドヒットとフォアグラウンドヒットの間隔が短いことにより）バックグラウンドヒットが訪問の一部として扱われている場合、それらのバックグラウンドヒットはフォアグラウンドヒットと同様に訪問別滞在時間の計算に含まれます。

バックグラウンドヒットの処理に関連する設定

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

いずれの場合も、バックグラウンドヒットは請求の対象になり、その料金は Analytics に送信される他のヒットと同じ料金になります。

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

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