レポート時間処理
レポート時間処理 は、Analysis Workspaceのデータを非破壊的かつ遡及的に処理できる仮想レポートスイート設定です。
レポート時間処理 は、仮想レポートスイートのデータのみに影響し、ベースレポートスイートのデータやデータ収集には影響しません。レポート時間処理 と Analytics の従来の処理の違いは、次の図を見るとよく理解できます。
Analytics によるデータ処理では、データがデータ収集パイプラインを通過して前処理ステップに送られた後に、レポート用のデータが準備されます。この前処理ステップでは、収集されたデータに訪問有効期間のロジックと eVar 持続ロジック(など)が適用されます。この前処理モデルの最大の欠点は、データが収集される前に設定をおこなっておく必要がある点です。つまり、前処理設定の変更は、設定変更後の新しいデータにしか適用されません。これはデータが順番どおりに届かなかった場合や、設定に誤りがあった場合に問題を引き起こします。
レポート時間処理 は、レポート用の Analytics データを処理する根本的に異なる方法です。データが収集される前に処理のロジックをあらかじめ決定するのではなく、前処理ステップの最中に設定されたデータを無視して、レポートが実行されるたびにロジックを適用するという点がこの機能の特徴です。
この処理アーキテクチャにより、従来よりもはるかに柔軟なレポートの作成が可能となります。例えば、訪問のタイムアウト時間を、必要な時間に非破壊的に変更できます。これらの変更は、完全なレポート期間中、eVar永続性コンテナおよびセグメントコンテナに反映されます。 また、ベースレポートスイートのデータを変更することなく、複数の仮想レポートスイートを作成して、同じベースレポートスイートに基づく別々のレポート時間処理オプションを仮想レポートスイートごとに設定することもできます。
また、 レポート時間処理 では、Analytics がバックグラウンドヒットで新しい訪問が開始されないようにしたり、アプリ起動イベントがトリガーされるたびに 🔗2}Adobe Experience Platform Mobile SDK} が新しい訪問を開始したりできます。
設定オプション
現在、レポート時間処理が有効になっている仮想レポートスイートでは、次の設定オプションを使用できます。
- 訪問タイムアウト: 訪問タイムアウト設定では、ユニーク訪問者が非アクティブになってから新しい訪問が自動的に開始されるまでの経過時間を定義します。デフォルト値は 30 分です。例えば、訪問タイムアウトを 15 分に設定した場合、収集された一連のヒットの後に非アクティブな時間が 15 分続くと、新しい訪問が開始されます。この設定は訪問数だけでなく、訪問セグメントコンテナの評価方法や、訪問時に期限切れになる eVar の訪問有効期間ロジックにも影響します。通常は、訪問タイムアウトを短くするとレポートに表示される訪問数が多くなり、訪問タイムアウトを長くするとレポートに表示される訪問数が少なくなります。
- モバイルアプリ訪問設定: Adobe Mobile SDK を使用してモバイルアプリで生成されるデータを含んだレポートスイートの場合は、追加の訪問設定を利用できます。これらの設定は非破壊的であり、Mobile SDK を通じて収集されたヒットのみに影響します。これらの設定は Mobile SDK の外部で収集されたデータには影響しません。
- バックグラウンドヒットによる新しい訪問の開始を防止: アプリがバックグラウンド状態にある場合、バックグラウンドヒットが Mobile SDK によって収集されます。
- アプリが起動するたびに新しい訪問を開始: 訪問タイムアウトに加えて、非アクティブ状態の継続時間に関係なく、Mobile SDK からのアプリ起動イベントが記録されるたびに訪問を強制的に開始できます。この設定は、訪問指標や訪問セグメントコンテナだけでなく、eVar に対する訪問有効期限ロジックにも影響を与えます。
- イベントで新しい訪問を開始: セッションがタイムアウトしているかどうかに関係なく、イベントが発生すると新しいセッションが開始します。新しく作成されたセッションには、そのセッションを開始したイベントが含まれます。さらに、複数のイベントを使用して 1 つのセッションを開始できます。新しいセッションは、これらのイベントのいずれかがデータに検出された場合に開始されます。この設定は、訪問数、訪問セグメントコンテナおよび 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: (低トラフィック)行項目は、レポート時間処理を使用する際の決定が若干異なり、ベースのレポートスイートでレポートする際に表示されるものと一致することは保証されません。 低トラフィックの一部ではないDimensionの行項目は、その行項目のデータの 100% を表すことが保証されるわけではありません。 このような違いは、ディメンション内に存在する一意の値の数が多いほど、より顕著になる場合があります。