データレイヤーのベストプラクティス

コードの配置

ページコード内では、データレイヤーオブジェクト（utag_data）は、ユニバーサルタグ（utag.js）への参照の_前に_宣言する必要があります。これにより、ユニバーサルタグがロードルール、拡張機能、タグを評価するために必要なデータレイヤー変数をすべて持つことが保証されます。推奨されるコード配置の例は、コードセンターからアクセスできます。

詳細はこちら: Code Center

命名規則

データレイヤーの目的は、ベンダーニュートラルで理解しやすい一連の変数を提供することです。以下のベストプラクティスが適用されます：

• 小文字とアンダースコアで区切られた変数名を使用します。
  例：site_section、product_unit_price、login_status。
• ベンダー固有の命名を避けます。
  eVar1、pv_a3、またはoidなどは避けてください。
• 意味のある変数の説明を使用します。
  適切に命名された変数でも、追加の説明が必要な場合があります。良い変数の説明には、変数が構成されるタイミングと場所、変数を使用するベンダー、変数で期待する可能性のある値の詳細が含まれます。例：
  • ログインステータスはanonymousまたはauthenticatedで、Adobe AnalyticsのeVar1に使用されます。
  • 注文小計は税金や送料を含まず、カンマと通貨記号を除外します。
• 複数形の変数名を避けます。
  複数の値を含む変数、例えば商品配列変数は、名前の単数形を使用するべきです。例：
  • product_categoriesの代わりにproduct_category
  • product_idsの代わりにproduct_id
• ブーリアン変数名にはis_.またはhas_.のプレフィックスを付けます。
  これにより、1または0の値を含む変数をすばやく識別できます。例：is_registered、is_first_time_visitor、is_logged_in

メリット

• 一貫した命名規則を作成します。
• 新しいユーザーがデータレイヤーに何が含まれていて、各変数がどのように使用されているかを理解するのが容易になります。
• Tealium Supportはこの規則に精通しています。

デメリット

• ベンダー固有の変数をベンダーニュートラルな命名規則に移行するための追加の努力が必要です。

文字列変数

すべての非製品変数には文字列値を使用します。ブーリアン変数と数値変数は文字列として渡すべきです。

ブーリアン値には、trueとfalseの代わりに1と0を使用します。このアプローチはより安定しており、これらの変数で期待される値についての混乱を減らします。

例：

メリット

• タグテンプレートは文字列と配列を期待しています。
• 実装中および実装後のテスト努力を最小限に抑えます。

デメリット

• なし。

配列変数

製品変数（価格、数量、IDなど）を配列として構成します。ユニバーサルタグ（utag.js）は、すべての製品変数に対して配列を使用するように設計されています。製品値をカンマ区切りの文字列で構成することも可能ですが、このアプローチはエラーが発生しやすいです。

配列（推奨）：

product_id : ["prodID1","prodID2","prodID3"]

文字列：

product_id : "prodID1,prodID2,prodID3"

メリット

• ベンダータグテンプレートが期待する同じ形式です。
• データレイヤーの可読性を向上させます。

デメリット

• なし。

ページタイプ

サイトのすべてのページには、page_typeという変数を含めるべきです。これは、ユーザーが表示しているページのタイプを判断するために使用されます。提案される値には、以下のようなものがありますが、これに限定されません：

メリット

• ユーザーがどのようなページを表示しているかを明確に理解します。
• 多くのベンダータグは、適切に機能するためにページタイプを利用します。

デメリット

• ユニバーサルデータオブジェクトにpage_type変数を追加するための初期開発努力が必要です。

サードパーティのデータレイヤーオブジェクト

すでにW3Cデータオブジェクトや独自のカスタムオブジェクトなど、サイトにデータレイヤーオブジェクトが実装されているかもしれません。これらのオブジェクトは、利用可能なデータレイヤーコンバーターのいずれかを使用してUDO utag_data形式に変換することをお勧めします。

メリット

• ロードルール、データマッピング、Web Companionなどの組み込み機能との互換性が向上します。
• カスタムオブジェクトに関する問題の調査にかかるサポートコストを削減します。

デメリット

• 実装に追加の努力が必要です。