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

コード配置

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

詳細については、ユニバーサルタグ (utag.js) のインストールを参照してください。

命名規則

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

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

長所

• 一貫した命名規則を作成します。
• 新しいユーザーがデータレイヤーに何が含まれているか、および各変数の使用方法を理解しやすくなります。
• Tealiumサポートはこの規則に精通しています。

短所

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

文字列変数

製品以外のすべての変数に文字列値を使用します。ブール値と数値変数は文字列として渡されるべきです。

ブール値の場合、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コンパニオンなどの組み込み機能との互換性が向上します。
• カスタムオブジェクトに関する問題を調査するためのサポートコストが削減されます。

短所

• 実装するための追加労力が必要です。