仮想レポートスイートとグローバル/複数のスイートタグ付けに関する考慮事項
仮想レポートスイートを使用すると、デジタルプロパティからデータを収集しているものの、セグメントが永続的に適用されているレポートスイートのデータを表示できます。
多くの場合、仮想レポートスイートを使用して複数のスイートタグ付けを置き換えることができます。仮想レポートスイートに切り替えると、セカンダリサーバーコールの必要性を効果的に排除できます。例えば、組織に 6 つの異なる Web サイトがあり、それぞれが独自のレポートスイートと組み合わされたグローバルレポートスイートにデータを送信しているとします。各サイトにはセカンダリサーバーコールが必要です。1 つは個々のブランドレポートスイートに、もう 1 つはグローバルレポートスイートに対してです。代わりに、すべてのサイトのデータをグローバルレポートスイートのみに送信し、複数の仮想レポートスイートを使用して各ブランドを分離できます。
複数のスイートタグ付けをグローバルレポートスイートと仮想レポートスイートに置き換えると、Adobe Analyticsの実装が簡素化され、サーバーコールの消費が減少します。ベストプラクティスとして推奨されます。 ただし、仮想レポートスイートで考慮すべき重要な制限がいくつかあります。 以下のガイドラインは、グローバルレポートスイート上に構築された仮想レポートスイートの実装が、最適なアプローチであるかどうかの判断に役立ちます。
ガイドライン
説明されている使用事例が自社に当てはまるかどうかわからない場合は、他のAdobe Analytics管理者やAdobeアカウントチームにお問い合わせください。 ビジネスのニーズを評価し、レコメンデーション方法を提示してくれます。
複数のスイートタグ付けまたは仮想レポートスイートを使用するかどうかを決定する際は、次の点に注意してください。
Adobe Experience Cloud へのセグメントの公開
仮想レポートスイートの場合は、Adobe Experience Cloud へのセグメントの共有はサポートされていません。Experience Cloud とセグメントを共有するユーザーは、ソースレポートスイートにアクセスできる必要があります。
パーソナライゼーションおよびターゲティングのためにセグメントを仮想レポートスイートから Adobe Experience Cloud にパブリッシュすることはまだできません。この目的のためには、セグメントをパブリッシュするすべてのユーザーにはソースレポートスイートへのアクセス権が必要です。例えば、ユーザーのアクセスを自分の地域の仮想レポートスイートに制限する一方、セグメントを Adobe Analytics から Adobe Experience Cloud に共有することは許可して Adobe Target でのターゲティングに役立てたいとします。この場合、複数スイートタグ付けの使用をお勧めします。ユーザーがグローバルレポートスイートにアクセスできてもよく、他のソリューションで使用するためにセグメントを公開する必要がない場合、仮想レポートスイートを使用できます。
ユニーク(低トラフィック)の制限
大量のサイトを組み合わせたグローバルレポートスイートがある場合は、頻繁に低トラフィックの行項目に遭遇する可能性があります。複数のスイートにタグ付けする場合、これはグローバルレポートスイートの問題に過ぎません(個々のレポートスイートでの低トラフィックの可能性は低くなります)。仮想レポートスイートを使用する場合は、個別の制限が共有され、個々のレポートスイートにも低トラフィックが示されます。複数のスイートタグ付けは、データを低トラフィックにグループ化するのを避ける場合に使用します。
例えば、大規模なメディア組織が 100 個の Web プロパティを所有しているとします。各プロパティは、前月のすべての記事のホストに加えて、月に数千のニュース記事を公開します。この組織では、eVar1 が「記事名」であるグローバルレポートスイートを使用しています。このレポートで、さまざまなプロパティを組み合わせたユニークな記事名が毎月 500 万件程度あると仮定します。 仮想レポートスイートを使用している場合、500 万件の値のうち、一部のみが仮想レポートスイートに含まれます。 残りは低トラフィックの下に含まれます。 複数のスイートタグ付けを使用した場合、個々のレポートスイートは一意の値のセットを表示できます。
Adobeカスタマーケアでは、少数のディメンションについて一意の値の制限を増やす可能性があり、その結果、この問題が完全になくなる場合があります。 詳細については、アカウントチームおよびカスタマーケアにお問い合わせください。
レポートスイート間で共有される変数
仮想レポートスイートは、親のレポートスイートからディメンションと指標のセットを継承しているため、独自のディメンションと指標のセットはありません。グローバルレポートスイートは、すべての Web サイトのすべてのディメンションと指標を取り込む必要があります。現在、レポートスイートには最大 250 個の eVar と 1000 個のカスタムイベントがあります。
実装ニーズはサイトごとに異なります。ディメンションとイベントの中には、2 つのサイト間で共有できるものもあります。例えば、電子メール登録では、複数の Web サイトで同じイベントを使用し、同じカスタムイベントをトリガーできます。その他のディメンションは、サイトに固有の場合があります。例えば、ユーザーがプロフィール画像を変更できるサイトは 1 つだけです。このカスタムイベントは、それをサポートする Web サイトでのみ実装されます。
個別のディメンションと指標の数が単一のグローバルレポートスイートに収まることを確認します。一意のディメンションまたは指標が多すぎる場合は、各実装内の各ディメンションを確認します。ビジネスの成功にとって重要でない重複やディメンションが存在する可能性があります。分類の使用も検討します。例えば、eVar5 で「商品名」を取得する代わりに、「商品」のディメンションに基づいた「商品名」の分類を作成します。ソースレポートスイートの分類は、依存する仮想レポートスイートで自動的に使用できます。
セグメントのニュアンス
基本レベルの仮想レポートスイートは、単にレポートスイートに適用されるセグメントです。訪問と訪問者ベースのディメンションは、直観的でないレポート結果を提供する可能性があります。
例えば、A と B の 2 つの Web サイトがあり、両方ともグローバルレポートスイートにデータを送信しているとします。必然的に、一部の訪問者はサイト A からサイト B に渡り、この移動がグローバルレポートスイートのパスに表示されます。サイト A と B に対して仮想レポートスイートを作成した場合、サイト A で開始し、サイト B で終了した訪問には、仮想レポートスイート B のエントリページは表示されません。この訪問のエントリページは、仮想レポートスイートからセグメント化されたサイト A で開始されました。
通貨換算
仮想レポートスイートでは、現在ベースとするレポートスイート以外の異なる通貨でレポートすることはできません。Adobe Analytics では、レポートの実行中に通貨を換算することができますが、履歴データに対しても現在の日付の換算レートが使用されます。
分析を単一通貨で行う場合、問題は発生しません。ただし、異なる地域のチームが独自の地域通貨で売上高を表示する必要がある場合は、複数のスイートタグ付けの使用を検討してください。
データフィード
データフィードは仮想レポートスイートを使用できません。ただし、グローバルレポートスイートからデータフィードを受け取った後、それを分離することはできます。
データフィードによって、個々のヒットレベルで、すべての Adobe Analytics データの毎日または毎時のエクスポートを受信できます。データフィードは、配信前に事前にセグメント化することはできないので、グローバルレポートスイートのデータフィードのみを受け取ることができます。ブランド、プロパティ、地域、その他の詳細なレベルで個々のデータフィードが強く必要な場合は、複数のスイートタグ付けの使用を検討してください。
パートナーアカウントとの Data Connectors
アドビの Adobe Analytics へのパートナー統合の一部は、レポートスイートごとに 1 つのパートナーアカウントに制限されています。組織によっては、同じ統合に対して複数のパートナーアカウントが必要になる場合があります。
例えば、1 つのレポートスイートにで使用できる Google DCM は 1 つのみです。多くの企業は複数の DCM アカウントを持っており、異なるブランド、事業部門、地域でディスプレイ広告を別々に管理できます。統合を仮想レポートスイートで設定することはできません。複数のアカウントを持つ依存 Data Connectors がある場合は、複数のスイートにタグ付けすることを検討してください。
概要データソース
「概要データソース」により、集計された指標を Adobe Analytics にレポートスイートレベルでインポートできます。概要データソースのアップロードには、訪問者 ID を持たない 集計指標が含まれるので、訪問コンテナおよび訪問者コンテナではセグメント化できません。仮想レポートスイートはセグメント化を使用して動作するので、セグメントが訪問コンテナまたは訪問者コンテナを使用して作成された場合、概要データソースを使用してインポートしたデータは、仮想レポートスイートでは使用できません。
ヒットコンテナが使用され、そのヒットコンテナにデータソース情報を含めるよう条件付きのルールが含まれている場合、概要データソースは仮想レポートスイートに表示されます。
仮想レポートスイートを使用することにした場合の手順
仮想レポートスイートを優先してセカンダリサーバーコールを削除する場合:
-
セカンダリ/子レポートスイートのデータに合致する仮想レポートスイートを作成します。サイトを相互に区別するカスタムディメンションでセグメント化します。
- 既存の複数スイートタグ付き実装から移行する場合は、仮想レポートスイートのセグメントを既存の子レポートスイートと比較します。ユーザーを仮想レポートスイートに移動する前に、データが比較可能であることを確認する必要があります。
- ベストプラクティスとして、セグメントの積み重ねを使用し、1 か所でセグメントを編集し、依存するすべての仮想レポートスイートに適用できるようにします。
- 仮想レポートスイートをより排他的に保つ場合は、ヒットコンテナを使用します。
-
仮想レポートスイートが正しく設定されていることを確認したら、実装からセカンダリレポートスイート ID を削除します。セカンダリレポートスイートの削除方法:
- Adobe Experience Platform データ収集内のAdobe Analytics拡張機能で、使用しないレポートスイートの横にある「x」をクリックします。
- 従来の JavaScript 実装では、
s.account
変数を見つけて、使用しなくなったレポートスイート ID をすべて削除します。 - サイトやアプリのデータを収集する場合は、どのような場合でも、グローバル/親レポートスイート ID のみをそのままにします。
- 管理者/レポートスイートに移動し、使用されなくなったセカンダリレポートスイートを非表示にします。