Show Menu
トピック×

仮想レポートスイートとマルチスイートタギングに関する考慮事項

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

ガイドライン

説明した使用例がユーザーおよび組織に適用されるかどうかがわからない場合は、他のAdobe Analytics管理者またはアドビのアカウントマネージャーに問い合わせてください。 ビジネスのニーズを評価し、推奨方法を提示してくれます。
マルチスイートタギングまたは仮想レポートスイートを使用するかどうかを決定する際は、次の点に注意してください。

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万件の個別記事名が作成されます。 仮想レポートスイートを使用する場合、トラフィックの大部分を構成する上位500,000件の値が仮想レポートスイートに含まれます。残りの350万人は低トラフィックの下に含まれています。 マルチスイートタギングを使用する場合、各レポートスイートには独自の上位500,000個の値を表示できます。 グローバルレポートスイートの固有制限は、マルチスイートタギングと仮想レポートスイートの間で同じです。
アドビカスタマーケアでは、少数のディメンションに対して一意の値の制限を増やすことで、この問題を完全に解消できます。 詳細については、アカウントチームおよびカスタマーケアにお問い合わせください。

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

仮想レポートスイートには、独自のディメンションと指標のセットはありません。これらはソースレポートスイートから継承されます。 グローバルレポートスイートは、すべての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つのレポートスイートにつき1つのGoogle DCMしか使用できません。 多くの企業は複数の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のみをそのままにします。
    • 管理者/レポートスイートに移動し、使用されなくなったセカンダリレポートスイートを非表示にします。