Oracle Infinity Tagビジネス意思決定ガイド
この記事は、Oracle Infinity UDOタグ・プラグインの実装に関するビジネス意思決定ガイドとして使用することを目的としており、データ・レイヤーおよびデータ・レイヤーの実装に関する論拠と適用可能性について詳しく説明しています。すでにOracle Infinity TagをWebサイトに実装しており、Oracle Infinity UDOタグ・プラグインの使用を決定した場合を想定しています。
概要
デジタル・マーケティングの世界は、複雑な空間です。ビジターの行動データとデモグラフィック・データの収集および分析は、Webアプリケーションとモバイル・アプリケーションの不可欠な部分となりました。マーケティング担当者は、顧客と見込み客および彼らが占有するオンライン空間を一貫して識別することが求められます。そのうえで、マーケティング担当者は、コンテンツを配信しながら、コンバージョン・ファネル全体さらにはその域を越えて、そのエンゲージメントと有効性を測定する必要があります。これを実現するために、これまでマーケティング担当者は、JavaScriptタグを使用してWebサイトに戦略やプログラムを実装する必要がありました。サイトやその他のオンライン・エクスペリエンスへのタグ付けは、その大部分がITの分野でした。このため、マーケティング戦略は、技術的なリリース・スケジュールと使用可能リソースに基づくITプロセスおよび長期にわたる実装の影響を受けてきました。
さらに、マーケティング担当者がデジタル戦略を実装し、コンシューマ・エクスペリエンスを提供するために使用するテクノロジやツールは非常に高度化しているため、こうしたツールのインストールや管理に関連付けられる技術要件は増加し続けています。
こういった要因は、高速かつ動的なデジタル・マーケットプレイスに迅速に適応するマーケティング担当者の妨げとなり、デジタル・マーケット担当者が成功するために設計された高度なツールの有効性が損なわれています。
Infinity UDOタグ・プラグインは、デジタル・マーケティング担当者がデジタル・エクスペリエンスを実装および最適化する際の柔軟性と制御性を大幅に向上させ、IT依存を軽減します。これにより、マーケティング担当者はタグではなくマーケティングに集中できます。Infinity UDOタグ・プラグインを実装すると、市場化までの時間を短縮できるだけでなく、デプロイメントにおける敏捷性と柔軟性およびデータ整合性の向上により、開発コストを削減できます。
データ・レイヤーの概要
データ・レイヤーは、Webサイトまたはモバイル・アプリケーションと別のアプリケーションの間で処理するすべてのデータを保持するデータ構造です。概念上、データ・レイヤーはページ固有の(ただし、ツールに依存しない)メタデータで、ページおよびユーザーがページに対して実行可能なアクションを記述します。データ・レイヤーは、通常、特定のページまたはユーザーについてレポートする必要があるすべての値が含まれたJavaScriptオブジェクトで構成されます。
データ・レイヤーを定義する最も一般的な方法として、JavaScriptプログラミング言語で記述されるユニバーサル・データ・オブジェクト(UDO)と呼ばれるものを使用します。より具体的には、データ・レイヤーは、キー/値ペアでデータを保持するJavaScript配列です。
これがレイヤーと呼ばれるのは、Webサイトまたはモバイル・アプリでの対話型のカスタマ・エクスペリエンスを提供するテクノロジ・スタックの論理要素であるためです。
- エクスペリエンス・レイヤー – エクスペリエンス・レイヤーは、ユーザーがWebサイトやモバイル・アプリと対話する場所です。
- データ・レイヤー – データ・レイヤーは中間に配置され、エクスペリエンス・レイヤーで発生したビジターの対話データをアプリケーション・レイヤーのベンダーに転送します。
- アプリケーション・レイヤー – アプリケーション・レイヤーは、ライブ・チャット、アナリティクス、表示広告、パーソナライズなどのWebサイトの機能をサポートする任意の数のデジタル・ベンダーで構成されます。
データ・レイヤーを実装する理由
データ・レイヤーを実装することは、将来のスケーラブルで保守が簡単な実装を実現するための先行投資です。これは、事前の作業が多くなることを意味します。最初に、レポート要件に確実に対応するようにデータ・レイヤーを設計してから、開発者にこのデータ・レイヤーをサイトに追加してもらう必要があります。ただし、その他に、先行タスクは将来におけるレポート作成の破損を防ぐのに役立ちます。
データ・レイヤーの実装を支持する主な議論の1つとして、値の移入方法があげられます。この方法を使用すると、1)データ収集操作を標準化し、2) DOMスクレイピングの使用を回避できます。
DOMスクレイピングは、JavaScriptセレクタ(タグ名、IDおよびクラス)を使用して、マーケティング・タグによりHTML構造であるDocument Object Model (DOM)から値を収集する方法です。たとえば、マーケティング・タグでは、JavaScriptまたはJQueryを使用してフォーム・フィールドから値をプルし、変数に割り当てることができます。
DOMスクレイピングの排除
DOMスクレイピングは、WebサイトのHTML要素が適切に識別されてさえいれば、いくらかのJavaScriptの基本知識を使用してページから簡単に値を収集できるため、便利です。
しかし、DOMスクレイピングには問題点もあります。再設計または新しいリリースのためにWebサイト構造が変更された場合、DOMスクレイピング用のJavaScriptセレクタに依存するアナリティクス・スクリプトでは、適切な値を変数にプルできなくなることがあります。
データ・レイヤーを入力します。データ・レイヤーの集中管理されたデータは、次の3つの方法を組み合せて使用し、DOMとは個別に構築されます。
- 変数値のハードコーディング。動的である必要がない変数および値は、データ・レイヤーにハードコーディングできます。
- バックエンド変数の移入。テンプレートベースのCMSを使用する場合は、ページの構築時にCMSデータベースからデータ・レイヤーに値をプッシュできます。
- フロントエンド変数の移入。HTMLタグ内のonclickなどのイベント・リスナーを使用すると、イベントの発生時にデータ・レイヤーに値をプッシュできます。
データ・レイヤーは、DOMまたはマーケティング・アプリケーションに依存せずに作成および移入されるため、データ・レイヤーを使用すると、ユーザー・イベントの定義をより細かく制御でき、ページのコンテンツに関する事前定義済データが提供されます。
データ・レイヤーの実装は重大な投資ですが、信頼できるデータおよび効率的な操作を優先する場合は、検討する価値が十分にあります。長期的に見ると、データ・レイヤーを使用することでIT効率が高まり、マーケティング自律性が拡大して、よりクリーンで信頼できるデータがユーザーに提供されます。
データ・レイヤーを実装する場合の考慮事項
自問してください。データ・レイヤーの使用を検討する際、自問するいくつかの質問は、次のとおりです。
以前に別のタグ管理システムを使用したことがありますか。多くの場合、別のツール用に設定されたデータ・レイヤーは、Infinity UDOで使用できます。同様に、クライアントがInfinity UDOの使用から移行する場合、データ・レイヤーも一緒に移行できます。
以前にタグ管理システムを実装したことがありますか。 現在、ほとんどのタグ管理システムには、独自の標準があります。複数のUDO標準を使用しないことをお薦めします。1つを使用しており、現在のTMSソリューションからInfinity UDOタグ・プラグインにコンバージョンする予定がある場合は、TMSのコンバージョンと有効化の専門知識を持つプロフェッショナル・コンサルタントに依頼することをお薦めします。
サイトのコードはどのくらいの頻度で変更されますか。サイトのDOMまたはHTMLが頻繁に変更される場合は、CSSセレクタに依存しないようにする必要があります。ほとんどの場合、レポートはランダムに破損します。多くのデバッグを行った結果、開発者がアナリティクスに影響を及ぼすことを認識していなかったコード変更が問題であるとわかりました。開発者にHTML/CSSを変更しないよう指示するよりも、データ・レイヤー・オブジェクトをページに配置した後は放置するように指示する方が簡単です。
タグ管理システム(TMS)チームは、どの程度CSSに詳しいですか。CSSを使用してDOMを容易に操作できるユーザーがチーム内にいる場合、もう少し簡単にデータ・レイヤーを使用しないで済ますことができる場合もあります。ただし、そのCSSに詳しいリソースがTMSで多くの時間を費やすことを考えてみてください。
サイト上にいくつのページ/ページ・タイプが存在しますか。非常に複雑なサイトは、CSSを介して管理することが困難であり、すべてのページ・タイプのDOMについてよく理解しておく必要があります。
CSSスタイルはどのようにレイアウトされていますか。クリーンかつ体系的で、きわめて永続的ですか。DOMがクリーンであるほど、DOMスクレイピングが容易になることは明らかです。
新しいページまたは新しいサイトの機能はどのくらいの頻度でリリースされますか。新しいマイクロサイトやサイト機能を頻繁に提供するサイトでは、変更のたびに、CSSに詳しいユーザーがTMSを設定する必要があります。あるいは、データ・レイヤーに依存する場合は、すべての新しいページ/サイト/機能について、データ・レイヤーに詳しい開発者が必要となります。通常、新しいサイト/ページ/機能ごとにCSSセレクタを理解するよりも、進化するプロジェクトについて開発者が参照できる堅実なデータ・レイヤー・テクノロジ仕様を記述するほうが簡単です。
サイトには、リンク・トラッキング/ページ・ロード後トラッキングがどのくらい存在しますか。ページ・ロードだけでなく、多くのユーザー・アクションを追跡する必要がある場合は、ITを組み込み、(HTMLから対象をスクレイピングしようとするのではなく)適切な対象を確実に追跡できるようにすることが非常に重要です。
開発者の所要時間はどのくらいですか。多くの会社は、特に、開発チーム内でアナリティクスを設定するために簡単に作業できるわけではないため、TMSソリューションに移行します。開発主導型のデータ・レイヤーでは、設定、ステージング、QAおよび公開までに数か月かかることがあります。その後、変更が必要な場合は、プロセスを再度開始します。時間がかかるプロセスを最初に通して行うことは有用ではありますが、この実装で変更が頻繁に必要になる場合は、DOMの使用をお薦めします。
Infinity UDOおよびデータ・レイヤー
データ・レイヤーは、Infinity UDOプラットフォームの基盤であり、すべてのデジタル・アセットおよび顧客との対話にわたって、データのマスター定義として機能します。データ・レイヤーは、サイト全体で収集される様々なデータ要素すべて、および追跡されるユーザー操作とイベントで構成されます。Infinity UDOは、カスタマ・エクスペリエンス・データを収集するために、ルートJavaScriptオブジェクト(JSO)に依存しています。JSOは、dataLayerと呼ばれるルート・オブジェクト内に含まれるように設計されています。
ここでポイントとなるのは、dataLayerは汎用であり、ツールに依存しないということです。通常のJavaScript配列のように動作するかぎり、1つのツールに限定されることはありません。前述のdataLayerオブジェクトの情報は、このページのグローバル・ネームスペースにアクセスできるすべてのアプリケーションで使用できます。
データ・レイヤーには、静的情報または動的情報を保持できます。Infinity UDOでは、データ・レイヤーにデータをプッシュして、そこから読み取ることができます。たとえば、Webサイトまたはモバイル・アプリでは、ページ・カテゴリやトランザクション値などの静的なページ情報をデータ・レイヤーに配置できます。または、ビジターがカートに製品を追加したときに、dataLayerイベント(製品の情報を含む)が起動される可能性があります。プッシュ・コマンドを使用すると、このデータをデータ・レイヤーに即座に追加できます。
データ・レイヤーを適切に定義および管理する利点
次に、開発者、マーケティング担当者およびその他の関係者間で話し合う必要がある基本的なマイルストンをいくつか示します。
- データ・レイヤー構造およびネーミング規則を決定します(他の何よりも前にデータ・モデルを作成する必要があります)。解決しようとしているユースケースは何ですか。収集するデータは何ですか。ユースケースを収集してモデルを作成してから、決定しますか。
- キー/値ペアを移入するためのコードを開発してデプロイします。
- ハードコード
- バックエンド
- フロントエンド
- ベンダー固有コードをWebサイト・ページ、テンプレートまたはヘッダーから削除します。
- 変数ドキュメントを更新し、データ・レイヤー要素をビジネス/ベンダーの要件にマップします。
- データ・レイヤーの品質保証のために定期的な監査を実行します。
業界のベスト・プラクティスを使用してデータ・レイヤーを実装し、実証済の開発方法論を使用することで、ユーザーとベンダーに信頼性の高い正確なデータを提供します。ビジネスに関する即時的な意思決定と長期的な意思決定の両方を行うために依存するデータが堅実であることが保証されます。