Adobe Analytics 実装プレイブックのダウンロード

「Business Requirements」タブ

対象：ビジネス要件定義書（BRD と呼ばれることが多い）は、主要な関係者、ビジネスユーザー、技術ユーザーが共同作業を行うために必要となる、非常に重要なドキュメントです。このドキュメントに、目標とする KPI、レポート要件、Adobe Analytics（AA）の実装が完了したときに確認できるようにしたいデータポイントのすべてを文書化します。

理由：これは、後続のドキュメント（SDR、技術仕様など）の出発点となり、合意がなされた AA の最終的な状態に関する、信頼できる共通の情報源となります。このドキュメントは、組織内の複数のチーム間の考えを整理し、実装の構築または強化を進めていく上でガイドとなる 1 つの方向を形成します。

方法：ビジネス要件の文書化は AA のエンドビジネスユーザーが行うのが一般的ですが、注意すべき技術的な課題が存在したり、特定のデータポイントは他のデータポイントよりも多くの労力が必要となる場合があり、優先順位付けに反映させる必要があるので、技術ユーザーからフィードバックを得ることが重要です。

「サイトでトラッキングしたいものは何か」「レポート用途において重要なデータポイントはどれか」そして最も重要なのが「これらのデータポイントが、情報に基づいて意思決定を行うのにどのように役立つか」、といった要素を自問自答してください。各ビジネス要件を、情報に基づいてビジネス上の意思決定を行うために使用できるデータポイントと確実に関連付けることが重要です。例えば、サイト上のすべてのクリックをトラッキングしたくなるかもしれませんが、その日の終わりに、そのレポートからどのようなインサイトが得ることができるでしょうか？

まず、以下のスクリーンショットの C 列（ビジネス要件）に記入します。例えば、「サイト上で実行されたサイト内検索の件数」や「インプレッション数の点で最も効果があるサイト内のキャンペーンスポット」のように記入する必要があります。このくらい詳細に記入したら、B 列（カテゴリ）に戻って入力し、要件を「検索」や「サイト内プロモーション」などのカテゴリにグループ化できます。これは、技術仕様のセクションとうまく対応するはずです。

また、eVar、イベント、prop を単体または組み合わせて使用することで、トラッキングしたい項目を達成できると思うかどうかも示します。

最後に、「Implementation Status」列は、サイトに項目の追加を開始する際に、ステータスチェックとして機能します。

ビジネス要件に関するドキュメント

「Variable Map」タブ（タグ付けドキュメント／SDR）

対象： タグ付けドキュメント（SDR と呼ばれることが多い）は、AA の技術ユーザーとビジネスユーザーの両方にとって価値のある、重要なドキュメントです。レポートスイートで使用されているすべての変数と、変数設定に関連するすべての詳細、変数の実装方法、レポートでの目的がリストされています。プロパティドキュメントと同様、常に変動し、適切に管理された Excel ドキュメントで、タグ付けの強化や実装の変更が導入された際に、そのドキュメントを最新の状態に保つ責任者が必要です。

理由：このドキュメントは多くの目的に役立ちますが、最も重要なものは次のとおりです。

実装されている製品に初めて接するユーザー（新入社員、利用可能なレポートの理解を深めたいビジネスオーナーなど）は、このドキュメントで、実装されているすべての変数の概要と各変数の目的を確認できるため、自分たちの AA の設定をセルフサービスで学習できます。
AA 製品の所有者または技術ユーザーにとっては、このドキュメントは、他の変数の設定方法と、新しいディメンションを追加する際にどの変数が使用できるのかを確認するためのリマインダーとして役立ちます。

**方法：**最初に、アドビが用意したすべての変数（ページ、製品、地域など）と、Excel ドキュメント内の eVar、prop、イベント、リスト変数をリストアップします。サイト／レポートスイートごとに 1 つのタブが必要です。
これらの各ディメンションに対して、次の列を追加します。

名前：ほとんどの人が理解できるシンプルで短い名前を指定します。新しいユーザーが選択し、何を取得するための変数なのかを理解できるよう、直感的なものにする必要があります。
説明：変数の使用目的と、変数で追跡するデータに関する詳細です。これはシンプルかつ短くし、インターフェイスで使用されている説明と一致させます。ユーザーがタグ付けドキュメントを参照する必要がなくなるのが理想です。したがって、新しいディメンションが管理バックエンドで設定された場合、同じ説明をそこに追加します。これにより、ユーザーはワークスペースで直接情報アイコンを選択でき、ディメンションが何かを把握でき、Excel ドキュメントを取り出す必要がなくなります。

ページ URL の簡略化

コード：値を設定するバックエンドのコード。ページ上のデータレイヤーのフィールドにすることも、ローンチルールや処理ルールなどを使用して実行するよう呼び出すこともできます。
分類レポート：分類インポーターまたは分類ルールビルダーを使用して実行される分類レポートを呼び出します。
ソリューションの範囲：すべてのプロパティ（少なくとも標準の変数よりも頻繁に使用するプロパティ）を小さな列にリストし、そのプロパティで設定される各ディメンションにチェックマークを追加すると便利です。これにより、特定のプロパティを簡単にフィルタリングでき、特定のディメンションが設定されている場所をすばやく確認できます。
設定：各変数の管理 UI 設定（eVar の場合は、有効期限、配分、マーチャンダイジングなど）。

サンプル SDR のスクリーンショット：

また、このタグ付けドキュメントを使用して、空き変数と「無効な」変数を管理することをお勧めします。ディメンションが役に立たなくなった場合、開発では通常、ディメンションを削除するのに時間がかかります。その後も、キャッシュが発生する場合や、ディメンションが別の場所でも設定されていることに気付く場合があります。ディメンションのクリーンアップは容易ではなく、多くの場合、忍耐が必要です。ここでは、ユーザーが無効な情報を追いかけて混乱しないように、それらを見えない場所に隠しておくためのヒントを紹介します。

使用されていないディメンションやイベントは、すべて「フリー」または「削除中」とします
- 過去 90 日間にディメンションに無効な値が含まれている場合は、「削除中」とします
- 少なくとも過去 90 日間ディメンションが利用されていない場合は、「フリー」とします
- タグ付けドキュメントで「名前」にそのようにマークを付けると、簡単にフィルタリングできるようになります。タグ付けドキュメント（Excel データフィルター）でこれらがチェックされないようにすると、ユーザーに表示されなくなります
- インターフェイスでこれらを eVar 名としてマークして、検索しても見つけられないようにし (例「(v6)」)、インターフェイスの説明を削除します。
これにより、新しいディメンションが必要な場合、「名前」列で「フリー」をフィルタリングすると、使用できるクリーンなディメンションを簡単に見つけることができます
「削除中」のディメンションとイベントについては、ワークスペースを使用して把握しておくことをお勧めします
- eVar、prop、event の 3 つのテーブルを持つ、管理者のみが閲覧可能なプロジェクトを作成します。特定の eVar には「インスタンス」を使用し、prop には、「prop5 が存在する」などを使用して HIT セグメントを作成します。
- 日付を過去 90 日間に設定します
- 上記を 3 つのテーブルの行として、発生件数とともに使用します
- いずれかが「0」になるとすぐに、タグ付けドキュメントで「フリー」とマークし、ワークスペースプロジェクトから削除します

このようにすると、データは常にクリーンな状態に保たれ、無効な値を明確にすることができます。

変数とイベントの概要

プロパティタブ

対象：プロパティドキュメントには、Adobe Analytics でタグ付けされているかどうかを問わず、すべてのデジタルプロパティをリストアップする必要があります。これらのプロパティには Web サイト、モバイルアプリ、その他のツール（チャット、フィードバックなど）などがあります。これは、ビジネスユーザーとテクニカルユーザーをまたいで、常に変動する一元化されたドキュメントとして機能します。

理由：これにより、すべてのデジタルプロパティをまたぐユーザーのジャーニーと、Adobe Analytics でカバーできることとできないことが明確になるので、タグ付けが欠落してプロパティへのタグ付けの追加を優先的に行うことができます。このようにデジタルエコシステムを構築すると、潜在的な機会をタグ付け戦略で特定して、ユーザーのジャーニーの全体像を把握できるようになります。例：複数のドメインやサイトをまたいで追跡できるグローバルレポートスイートが必要ですか。ドメイン間またはアプリからハイブリッドエクスペリエンスへの訪問者 ID の引き渡しは必要ですか。クロスドメイントラッキングの場合、内部 URL フィルターを更新する必要がありますか。

**方法：**ドキュメントをガバナンスし、更新管理を担当する単一の責任元となる、そのドキュメントの所有者を特定します。
「プロパティ」タブで、次のリストアップします。

プロパティ名：ドメイン、サブドメイン、アプリ名など。同じドメイン内でも、その一部が別々に（別のチームや別のテクノロジーによって）管理されている場合は、それらを分ける必要があります。
リンク（URL）：プロパティへのリンクがある場合
所有者と連絡先：プロパティの主たる所有者や連絡先の一覧
タグメソッド：多くのユーザーは、様々なコードメソッドや実装（Launch、JS ファイル、AEP など）を行っています。必要に応じてこれをさらに分類できますが（コードバージョンやタグ管理システムなどを用いて）、それには、様々なコードメソッドやバージョン、コードの更新が必要な場所、コードのメンテナンス方法などのすべてを把握しておく必要があります。Adobe Launch を使用している場合は、Launch のプロパティ名をリストアップします。

Adobe Analytics でタグ付けされていない場合でも、すべてのデジタルプロパティを必ず含めてください。これにより、デジタル環境を把握し、ユーザーがすべてのプロパティとどのようにやり取りしているかを理解することができます。

このドキュメントは、組織の様々な部署で解釈しやすいように、できるだけシンプルに保ち、あまり多くの情報で埋め尽くさないようにすることをお勧めします。分析チームは他のチームよりもデジタル環境を理解していることが多いので、このドキュメントは、他のチームや経営陣が全体的な概要を説明するために使用されることがよくあります。

ヒント

Adobe Analytics でサイト名やプロパティのディメンションを作成します。サイト名やアプリ名を識別する専用のディメンション（通常は eVar）が Adobe Analytics にあると、セグメント化、トラブルシューティング、仮想レポートスイートの作成などを行うことができます。特に、複数のサイトを 1 つの（グローバルな）レポートスイートでまとめる場合、メリットは無限にあります。重要なのは、開発チームが、すべてのページ読み込み（s.t calls/trackState）とすべてのカスタムイベント（s.tl calls/trackAction）を含め、常にこの値をプロパティディメンションに設定するようにすることです。処理ルールは、これらの値を適切に一貫して設定するのに役立つツールとなります。

実装プレイブックの入力の詳細については、Doug Moore によるこちらのビデオをご覧ください。