Show Menu
トピック×

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

仮想レポートスイート(VRS)により、デジタルプロパティからデータを収集するレポートスイートからのデータを、セグメントが永続的に適用された状態で表示できます。
多くの場合、仮想レポートスイートを使用して複数のスイートタグ付けを置き換えることができます。仮想レポートスイートに切り替えると、 セカンダリサーバーコール の必要性を効果的に排除できます。例えば、組織に 6 つの異なる Web サイトがあり、それぞれが独自のレポートスイートと組み合わされたグローバルレポートスイートにデータを送信しているとします。各サイトにはセカンダリサーバーコールが必要です。1 つは個々のブランドレポートスイートに、もう 1 つはグローバルレポートスイートに対してです。代わりに、すべてのサイトのデータをグローバルレポートスイートのみに送信し、複数の仮想レポートスイートを使用して各ブランドを分離できます。
複数のスイートタグ付けの代わりにグローバルレポートスイートおよび VRS を使用すれば、Adobe Analytics の実装を簡素化し、サーバーコールの消費を軽減できるので、ベストプラクティスとして推奨されます。ただし、VRS には、考慮すべき重要な制限事項がいくつかあります。以下のガイドラインは、グローバルレポートスイート上に構築された仮想レポートスイートの実装が、最適なアプローチであるかどうかの判断に役立ちます。

ガイドライン

前述の使用事例が自分および自分の組織に当てはまるかどうかがわからない場合は他の Adobe Analytics 管理者または Adobe アカウント管理者にご相談ください。ビジネスのニーズを評価し、推奨方法を提示してくれます。
複数のスイートタグ付けまたは仮想レポートスイートを使用するかどうかを決定する際は、次の点に注意してください。

Adobe Experience Cloud へのセグメントの公開

仮想レポートスイートの場合は、Adobe Experience Cloud へのセグメントの共有はサポートされていません。Experience Cloud とセグメントを共有するユーザーは、ソースレポートスイートにアクセスできる必要があります。
パーソナライゼーションおよびターゲティングのためにセグメントを仮想レポートスイートから Adobe Experience Cloud にパブリッシュすることはまだできません。この目的のためには、セグメントをパブリッシュするすべてのユーザーにはソースレポートスイートへのアクセス権が必要です。例えば、ユーザーのアクセスを自分の地域の仮想レポートスイートに制限する一方、セグメントを Adobe Analytics から Adobe Experience Cloud に共有することは許可して Adobe Target でのターゲティングに役立てたいとします。この場合、複数スイートタグ付けの使用をお勧めします。ユーザーがグローバルレポートスイートにアクセスできてもよく、他のソリューションで使用するためにセグメントを公開する必要がない場合、仮想レポートスイートを使用できます。

リアルタイムデータと現在のデータ

仮想レポートスイートではデータがセグメント化されるので、リアルタイムレポートはサポートされません。現在のデータではセグメント化がサポートされないので、現在のデータは仮想レポートスイートではサポートされません。これらの機能は Reports & Analytics に固有です。
リアルタイムレポート 現在のデータ は、仮想レポートスイートでは使用できません。これは、Reports & Analytics でのトレンドに数秒または数分以内に反応するユーザーに影響します。これらのユーザーには、リアルタイムコンテンツの消費に基づいてヘッドラインを調整するニュースルームの編集者を含めることができます。個々のレポートスイートに固有の重要なリアルタイムデータが必要な場合は、複数のスイートタグ付けの使用を検討します。リアルタイムデータと現在のデータは、引き続きグローバルレポートスイートで使用できます。

一意の制限

大量のサイトを組み合わせたグローバルレポートスイートがある場合は、頻繁に 低トラフィック の行項目に遭遇する可能性があります。複数のスイートにタグ付けする場合、これはグローバルレポートスイートの問題に過ぎません(個々のレポートスイートでの低トラフィックの可能性は低くなります)。仮想レポートスイートを使用する場合は、個別の制限が共有され、個々のレポートスイートにも低トラフィックが示されます。複数のスイートタグ付けは、データを低トラフィックにグループ化するのを避ける場合に使用します。
例えば、大規模なメディア組織が 100 個の Web プロパティを所有しているとします。各プロパティは、前月のすべての記事のホストに加えて、月に数千のニュース記事を公開します。この組織では、eVar1 が「記事名」であるグローバルレポートスイートを使用しています。このレポートでは、様々なプロパティを組み合わせた結果、毎月約 400 万件の個別記事名が作成されます。仮想レポートスイートを使用する場合、トラフィックの大部分を構成する上位 50 万件の値が仮想レポートスイートに含まれます。残りの 350 万件は「低トラフィック」に含まれています。複数のスイートタグ付けを使用する場合、各レポートスイートには独自の上位 50 万個の値を表示できます。グローバルレポートスイート固有の制限は、複数のスイートタグ付けと仮想レポートスイートの間で同じです。
アドビカスタマーケアでは、少数のディメンションに対して一意の値の制限を増やすことで、この問題を完全に解消できます。詳細については、アカウントチームおよびカスタマーケアにお問い合わせください。

レポートスイート間で共有される変数

仮想レポートスイートは、親のレポートスイートからディメンションと指標のセットを継承しているため、独自のディメンションと指標のセットはありません。グローバルレポートスイートは、すべての Web サイトのすべてのディメンションと指標を取り込む必要があります。現在、レポートスイートには最大 250 個の eVar と 1000 個のカスタムイベントがあります。
実装ニーズはサイトごとに異なります。ディメンションとイベントの中には、2 つのサイト間で共有できるものもあります。例えば、電子メール登録では、複数の Web サイトで同じイベントを使用し、同じカスタムイベントをトリガーできます。その他のディメンションは、サイトに固有の場合があります。例えば、ユーザーがプロフィール画像を変更できるサイトは 1 つだけです。このカスタムイベントは、それをサポートする Web サイトでのみ実装されます。
個別のディメンションと指標の数が単一のグローバルレポートスイートに収まることを確認します。一意のディメンションまたは指標が多すぎる場合は、各実装内の各ディメンションを確認します。ビジネスの成功にとって重要でない重複やディメンションが存在する可能性があります。 分類 の使用も検討します。例えば、eVar5 で「商品名」を取得する代わりに、「商品」のディメンションに基づいた「商品名」の分類を作成します。ソースレポートスイートの分類は、依存する仮想レポートスイートで自動的に使用できます。
キュレーション を導入すると、VRS ごとに特定のディメンションや指標の名前を変更できるようになります。

セグメントのニュアンス

基本レベルの仮想レポートスイートは、単にレポートスイートに適用されるセグメントです。訪問と訪問者ベースのディメンションは、直観的でないレポート結果を提供する可能性があります。
例えば、A と B の 2 つの Web サイトがあり、両方ともグローバルレポートスイートにデータを送信しているとします。必然的に、一部の訪問者はサイト A からサイト B に渡り、この移動がグローバルレポートスイートのパスに表示されます。サイト A とサイト B の仮想レポートスイートを作成すると、サイト A で開始してサイト B で終了した訪問で、VRS B に入口ページが表示されません。この訪問の入口ページは、仮想レポートスイートからセグメント化されたサイト A で開始されました。

通貨換算

仮想レポートスイートでは、現在ベースとするレポートスイート以外の異なる通貨でレポートすることはできません。Adobe Analytics では、レポートの実行中に通貨を換算することができますが、履歴データに対しても現在の日付の換算レートが使用されます。
分析を単一通貨で行う場合、問題は発生しません。ただし、異なる地域のチームが独自の地域通貨で売上高を表示する必要がある場合は、複数のスイートタグ付けの使用を検討してください。

データフィード

データフィードは仮想レポートスイートを使用できません。ただし、グローバルレポートスイートからデータフィードを受け取った後、それを分離することはできます。
データフィードによって、個々のヒットレベルで、すべての Adobe Analytics データの毎日または毎時のエクスポートを受信できます。データフィードは、配信前に事前にセグメント化することはできないので、グローバルレポートスイートのデータフィードのみを受け取ることができます。ブランド、プロパティ、地域、その他の詳細なレベルで個々のデータフィードが強く必要な場合は、複数のスイートタグ付けの使用を検討してください。

パートナーアカウントとの Data Connectors

アドビの Adobe Analytics へのパートナー統合の一部は、レポートスイートごとに 1 つのパートナーアカウントに制限されています。組織によっては、同じ統合に対して複数のパートナーアカウントが必要になる場合があります。
例えば、1 つのレポートスイートにで使用できる Google DCM は 1 つのみです。多くの企業は複数の DCM アカウントを持っており、異なるブランド、事業部門、地域でディスプレイ広告を別々に管理できます。統合を仮想レポートスイートで設定することはできません。複数のアカウントを持つ依存 Data Connectors がある場合は、複数のスイートにタグ付けすることを検討してください。

概要データソース

「概要データソース」により、集計された指標を Adobe Analytics にレポートスイートレベルでインポートできます。概要データソースのアップロードには集計された指標が含まれるので、セグメント化することはできません。VRS はセグメント化を使用して動作するので、概要データソースを使用してインポートしたすべてのデータは、仮想レポートスイートでは使用できません。概要データソースは、ソースレポートスイートでのみ表示されます。
フル処理データソースはセグメント化をサポートし、仮想レポートスイートで使用できます。

VRS の使用を決定した場合の手順

仮想レポートスイートを優先してセカンダリサーバーコールを削除する場合:
  1. セカンダリ/子レポートスイートのデータに合致する仮想レポートスイートを作成します。サイトを相互に区別するカスタムディメンションでセグメント化します。
    • 既存の複数スイートタグ付き実装から移行する場合は、仮想レポートスイートのセグメントを既存の子レポートスイートと比較します。ユーザーを仮想レポートスイートに移動する前に、データが比較可能であることを確認する必要があります。
    • ベストプラクティスとして、 セグメントの積み重ね を使用し、1 か所でセグメントを編集し、依存するすべての仮想レポートスイートに適用できるようにします。
    • 仮想レポートスイートをより排他的に保つ場合は、ヒットコンテナを使用します。
  2. 仮想レポートスイートが正しく設定されていることを確認したら、実装からセカンダリレポートスイート ID を削除します。セカンダリレポートスイートの削除方法:
    • Adobe Experience Platform Launch で、使用しないレポートスイートの横にある「x」をクリックします。
    • DTM で、プロパティと Analytics ツールの場所を特定します。実稼動アカウント ID とステージングアカウント ID フィールドで、今後使用しない任意のレポートスイート ID を削除します。
    • 従来の JavaScript 実装では、 s.account 変数を見つけて、使用しなくなったレポートスイート ID をすべて削除します。
    • サイトやアプリのデータを収集する場合は、どのような場合でも、グローバル/親レポートスイート ID のみをそのままにします。
    • 管理者/レポートスイートに移動し、使用されなくなったセカンダリレポートスイートを非表示にします。