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

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

多くの場合、仮想レポートスイートを使用して複数のスイートタグ付けを置き換えることができます。 仮想レポートスイートに切り替えると、セカンダリサーバーコールの必要性を効果的に排除できます。 例えば、組織に 6 つの異なる Web サイトがあり、それぞれが独自のレポートスイートと組み合わされたグローバルレポートスイートにデータを送信しているとします。 各サイトにはセカンダリサーバーコールが必要です。1 つは個々のブランドレポートスイートに、もう 1 つはグローバルレポートスイートに対してです。 代わりに、すべてのサイトのデータをグローバルレポートスイートのみに送信し、複数の仮想レポートスイートを使用して各ブランドを分離できます。

マルチスイートタグをグローバルレポートスイートおよびバーチャルレポートスイートに置き換えると、Adobe Analyticsの実装を簡素化し、サーバーコールの消費量を減らすことができ、ベストプラクティスとして推奨されます。 ただし、仮想レポートスイートには、いくつかの重要な制限があります。 次のガイドラインは、グローバルレポートスイート上に構築された仮想レポートスイートを実装することが適切かどうかを判断するのに役立ちます。

ガイドライン

記載されているユースケースが自社に適しているかどうかわからない場合は、他のAdobe Analytics管理者またはAdobeアカウントチームに相談してください。 ビジネスニーズを評価し、レコメンデーション方法を提示してくれます。

複数のスイートタグ付けまたは仮想レポートスイートを使用するかどうかを決定する際は、次の点に注意してください。

Adobe CX Enterpriseへのセグメントの公開

Adobe CX Enterpriseへのセグメントの共有は、バーチャルレポートスイートではサポートされていません。 セグメントをCX Enterpriseと共有したいユーザーは、ソースレポートスイートにアクセスできる必要があります。

セグメントは、パーソナライゼーションとターゲティング用のバーチャルレポートスイートからAdobe CX Enterpriseにまだ公開できません。 この目的のためには、セグメントをパブリッシュするすべてのユーザーにはソースレポートスイートへのアクセス権が必要です。 例えば、地域のデータのみにアクセス権を付与し、Adobe TargetでターゲティングするセグメントをAdobe AnalyticsからAdobe CX Enterpriseに作成して共有できるようにします。 この場合、複数スイートタグ付けの使用をお勧めします。 ユーザーがグローバルレポートスイートにアクセスできてもよく、他のソリューションで使用するためにセグメントを公開する必要がない場合、仮想レポートスイートを使用できます。

一意の(低トラフィック)制限

大量のサイトを組み合わせたグローバルレポートスイートがある場合は、頻繁に低トラフィックの行項目に遭遇する可能性があります。 複数のスイートにタグ付けする場合、これはグローバルレポートスイートの問題に過ぎません(個々のレポートスイートでの低トラフィックの可能性は低くなります)。 仮想レポートスイートを使用する場合は、個別の制限が共有され、個々のレポートスイートにも低トラフィックが示されます。 複数のスイートタグ付けは、データを低トラフィックにグループ化するのを避ける場合に使用します。

例えば、大規模なメディア組織が 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 Data Collection内のAdobe Analytics拡張機能で、使用しないレポートスイートの横にある「x」をクリックします。
    • 従来の JavaScript 実装では、s.account 変数を見つけて、使用しなくなったレポートスイート ID をすべて削除します。
    • サイトやアプリのデータを収集する場合は、どのような場合でも、グローバル/親レポートスイート ID のみをそのままにします。
    • 管理者/レポートスイートに移動し、使用されなくなったセカンダリレポートスイートを非表示にします。
recommendation-more-help
analytics-help-components