レポート時間処理
レポート時間処理 は、Analysis Workspaceのデータを非破壊的かつ遡及的に処理できる仮想レポートスイート設定です。
レポート時間処理 は、仮想レポートスイートのデータのみに影響し、ベースレポートスイートのデータやデータ収集には影響しません。レポート時間処理 と Analytics の従来の処理の違いは、次の図を見るとよく理解できます。
Analytics のデータ処理中、データはデータ収集パイプラインを通じて前処理ステップに送られ、前処理ステップではレポート用のデータが準備されます。 この前処理手順では、データが収集されるたびに、訪問の有効期限ロジックとeVarの永続性ロジックが(特に)適用されます。 この前処理モデルの主な欠点は、データを収集する前に事前に設定を行う必要があることです。 つまり、前処理設定に対する変更は、その時間以降の新しいデータにのみ適用されます。 データが順不同で送信されたり、設定が誤って設定されていた場合は、これが問題になります。
レポート時間処理 は、レポート用の Analytics データを処理する根本的に異なる方法です。データが収集される前に処理のロジックをあらかじめ決定するのではなく、前処理ステップの最中に設定されたデータを無視して、レポートが実行されるたびにロジックを適用するという点がこの機能の特徴です。
この処理アーキテクチャにより、より柔軟なレポートオプションが可能になります。 例えば、訪問のタイムアウト時間を、必要な長さに非破壊的に変更できます。これらの変更は、完全なレポート期間中、eVarの永続性コンテナおよびセグメントコンテナに反映されます。 さらに、ベースレポートスイート内のデータを変更することなく、同じベースレポートスイートに基づいて、それぞれ異なるレポート時間処理オプションを持つ、任意の数の仮想レポートスイートを作成できます。
また、 レポート時間処理 では、Analytics がバックグラウンドヒットで新しい訪問が開始されないようにしたり、アプリ起動イベントがトリガーされるたびに 2}Adobe Experience Platform モバイルSDK} が新しい訪問を開始したりできます。
設定オプション
現在、レポート時間処理が有効になっている仮想レポートスイートでは、次の設定オプションを使用できます。
- 訪問タイムアウト: 訪問タイムアウト設定では、ユニーク訪問者が非アクティブになってから新しい訪問が自動的に開始されるまでの経過時間を定義します。デフォルト値は 30 分です。例えば、訪問のタイムアウトを 15 分に設定した場合、収集されたヒットのシーケンスごとに、新しい訪問のグループ化が 15 分間隔で作成されます。 この設定は、訪問の回数だけでなく、訪問セグメントコンテナの評価方法や、訪問時に期限が切れる eVar の訪問有効期限ロジックにも影響します。 訪問タイムアウトを減らすと、レポートの合計訪問回数が増える可能性が高くなり、訪問タイムアウトを増やすと、レポートの合計訪問回数が減る可能性が高くなります。
- モバイルアプリ訪問設定: Adobe Mobile SDK を使用してモバイルアプリで生成されるデータを含んだレポートスイートの場合は、追加の訪問設定を利用できます。これらの設定は非破壊的で、Mobile SDK を介して収集されたヒットにのみ影響します。 これらの設定は、Mobile SDK以外で収集されるデータには影響しません。
- バックグラウンドヒットによる新しい訪問の開始を防止: アプリがバックグラウンド状態にある場合、バックグラウンドヒットが Mobile SDK によって収集されます。
- アプリが起動するたびに新しい訪問を開始: 訪問タイムアウトに加えて、非アクティブ状態の継続時間に関係なく、Mobile SDK からのアプリ起動イベントが記録されるたびに訪問を強制的に開始できます。この設定は、訪問指標や訪問セグメントコンテナだけでなく、eVar に対する訪問有効期限ロジックにも影響を与えます。
- イベントで新しい訪問を開始: セッションがタイムアウトしているかどうかに関係なく、イベントが発生すると新しいセッションが開始します。新しく作成されたセッションには、そのセッションを開始したイベントが含まれます。 さらに、複数のイベントを使用してセッションを開始できます。データにこれらのイベントのいずれかが表示された場合は、新しいセッションが起動します。 この設定は、訪問回数、訪問セグメント化コンテナ、eVar の訪問有効期限ロジックに影響を与えます。
デモビデオについては、
レポート時間処理の制限事項
レポート時間処理は、従来の Analytics レポートで使用できるすべての指標とディメンションをサポートしているわけではありません。レポート時間処理を使用する仮想レポートスイートにはAnalysis Workspaceからのみアクセスでき、Data Warehouse、Report Builder、データフィードおよびレポート API からはアクセスできません。
また、レポート時間処理では、レポートの日付範囲内のデータ(以下「日付ウィンドウイング」と呼びます)のみを処理します。 つまり、レポートの日付範囲より前の訪問者に対して「期限切れなし」に設定されたeVar値は、レポートウィンドウには保持されず、レポートには表示されません。 つまり、顧客ロイヤルティの測定は、レポートの日付範囲に存在するデータにのみ基づいており、レポートの日付範囲より前の履歴全体には基づいていません。
次のディメンションと指標は、レポート時間処理ではサポートされていません。
- Analytics for Target
- Analytics for Advertising Cloud のディメンション/指標
- カウンター eVar
- 初回購入までの日数
- 前回購入からの日数
- 最終訪問からの日数
- オリジナルの入口ページ
- 線形配分 eVar
- リスト変数
- マーケティングチャネルディメンション
- オリジナルの参照ドメイン
- 再来訪頻度
- 単一アクセス
- トランザクション ID データソース
- 訪問回数
影響を受けるディメンションと指標
以下は、選択したレポート時間処理設定によっては影響を受けるディメンションと指標のリストです。
-
「バックグラウンドヒットで新しい訪問が開始されないようにする」が有効な場合、次の変更がおこなわれます。詳しくは、「コンテキスト対応セッション」を参照してください。
- バウンス / バウンス率: フォアグラウンドヒットの後にフォアグラウンドヒットが続かないバックグラウンドヒットは、バウンスとは見なされず、バウンス率には寄与しません。
- 訪問別滞在時間(秒):この指標には、フォアグラウンドヒットを含む訪問のみが寄与します。
- 訪問別滞在時間:この指標には、フォアグラウンドヒットを含む訪問のみが寄与します。
- エントリ指標 / 終了指標: フォアグラウンドヒットのある訪問からのエントリと離脱のみが、このディメンションに表示されます。
- 入口ディメンション / 出口ディメンション: フォアグラウンドヒットのある訪問からの入口と出口のみが、このディメンションに表示されます。
- ユニーク訪問者指標:ユニーク訪問者には、レポートの日付範囲でバックグラウンドヒットのみを行った訪問者は含まれません。
-
訪問回数:訪問回数には仮想レポートスイートで定義されているすべての設定が反映されます。これらの設定はベースレポートスイートと異なる場合があります。
-
イベント ID が付くシリアル化されたイベント:イベント ID が付くイベントのシリアル化を使用するイベントは、訪問者のレポート日付範囲内で発生したイベントに対してのみ重複除外されます。レポート時間処理の日付ウィンドウイングより、これらのイベントは、すべての日付または訪問者に対してグローバルに重複除外されません。
-
購入/売上高/注文/数量: 購入 ID が使用されている場合、これらの指標は、すべての日付または訪問者にわたって重複が除外されるのではなく、レポート時間処理の日付ウィンドウイングに基づくレポートの日付範囲内で発生し、重複している購入 ID についてのみ重複が除外されます。
-
非マーチャンダイジング eVars / 予約 eVars: eVarで設定された値は、レポート時間処理の日付ウィンドウイングに基づくレポートの日付範囲内で値が設定された場合にのみ維持されます。 なお、値が維持されている間に夏時間への変更や夏時間からの変更があった場合は、時間に基づく有効期限が通常よりも 1 時間早く終了したり、1 時間遅く終了したりすることがあります。
-
マーチャンダイジング eVar / 予約 eVar: 上記を参照してください。 なお、バインディングが「すべてのイベント」に設定されるコンバージョン構文については、「すべてのヒット」が代わりに使用されます。
-
ヒットタイプ:このディメンションは、ヒットがフォアグラウンドで発生したかバックグラウンドで発生したかを示します。
-
(低トラフィック)または「ユニーク数超過」を含むディメンション: (低トラフィック)行項目は、レポート時間処理を使用する場合とはわずかに異なって決定され、ベースのレポートスイートでレポートする場合に表示されるものと一致することは保証されません。 低トラフィックの一部ではないDimensionの行項目は、その行項目のデータの 100% を表すことが保証されるわけではありません。 このような違いは、ディメンション内に存在する一意の値の数が多いほど、より顕著になる場合があります。