仮想レポートスイートとグローバル/複数のスイートタグ付けに関する考慮事項

仮想レポートスイートを使用すると、デジタルプロパティからデータを収集するレポートスイートのデータを、セグメントが永続的に適用された状態で表示できます。

多くの場合、仮想レポートスイートを使用して複数のスイートタグ付けを置き換えることができます。仮想レポートスイートに切り替えると、セカンダリサーバーコールの必要性を効果的に排除できます。例えば、組織に 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 で「商品名」を取得する代わりに、「商品」のディメンションに基づいた「商品名」の分類を作成します。ソースレポートスイートの分類は、依存する仮想レポートスイートで自動的に使用できます。

TIP
の導入に伴い キュレーションに値を入力すると、仮想レポートスイートごとに特定のディメンションや指標の名前を変更できます。

セグメントのニュアンス

基本レベルの仮想レポートスイートは、単にレポートスイートに適用されるセグメントです。訪問と訪問者ベースのディメンションは、直観的でないレポート結果を提供する可能性があります。

例えば、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 を持たない ​集計指標が含まれるので、訪問コンテナおよび訪問者コンテナではセグメント化できません。仮想レポートスイートはセグメント化を使用して動作するので、訪問コンテナまたは訪問者コンテナを使用して作成されたセグメントの場合、仮想レポートスイートでは概要データソースを使用してインポートされたデータを使用できません。

ヒットコンテナが使用され、そのヒットコンテナにデータソース情報を含めるよう条件付きのルールが含まれている場合、概要データソースは仮想レポートスイートに表示されます。

TIP
フル処理データソースはセグメント化をサポートし、仮想レポートスイートで使用できます。

仮想レポートスイートの使用を決定した場合の手順

仮想レポートスイートを優先してセカンダリサーバーコールを削除する場合:

  1. セカンダリ/子レポートスイートのデータに合致する仮想レポートスイートを作成します。サイトを相互に区別するカスタムディメンションでセグメント化します。

    • 既存の複数スイートタグ付き実装から移行する場合は、仮想レポートスイートのセグメントを既存の子レポートスイートと比較します。ユーザーを仮想レポートスイートに移動する前に、データが比較可能であることを確認する必要があります。
    • ベストプラクティスとして、セグメントの積み重ねを使用し、1 か所でセグメントを編集し、依存するすべての仮想レポートスイートに適用できるようにします。
    • 仮想レポートスイートをより排他的に保つ場合は、ヒットコンテナを使用します。
  2. 仮想レポートスイートが正しく設定されていることを確認したら、実装からセカンダリレポートスイート ID を削除します。セカンダリレポートスイートの削除方法:

    • Adobe Experience Platformデータ収集内のAdobe Analytics拡張機能で、使用しなくなったレポートスイートの横にある「x」をクリックします。
    • 従来の JavaScript 実装では、s.account 変数を見つけて、使用しなくなったレポートスイート ID をすべて削除します。
    • サイトやアプリのデータを収集する場合は、どのような場合でも、グローバル/親レポートスイート ID のみをそのままにします。
    • 管理者/レポートスイートに移動し、使用されなくなったセカンダリレポートスイートを非表示にします。
recommendation-more-help
46b8682c-fda6-4669-9355-1a44923e549e