ウェブサイトによるトラッキング設定の適応例

Web トラッキング設定を使用すると、管理するさまざまな Web サイト全体で訪問者データがどのように収集され、解釈されるかを柔軟に定義できます。ビジネスニーズに応じて、各 Web サイトで独自の追跡動作が必要になる場合があります。ウェブトラッキング設定の詳細については、以下を参照してください。ウェブトラッキングを設定する。

この記事では、Web トラッキング構成を効果的に調整および整理する方法を示す 4 つの実用的なシナリオを紹介します。

1. シナリオ1:ウェブトラッキング要件が異なる複数のウェブサイト
2. シナリオ2:構成を分離することで所有権の曖昧さと構成の乱雑さを解消する
3. シナリオ3:デフォルトのウェブトラッキング設定を許可する
4. シナリオ4:ウェブトラッキング設定をテストする

これらのシナリオを例として使用すると、すべての Web サイトにわたってデータがクリーンで、構成が保守可能で、顧客行動が正確であるような方法で Web トラッキング設定を整理するのに役立ちます。

シナリオ1:ウェブトラッキング要件が異なる複数のウェブサイト

あるソフトウェア会社が 2 つの異なる会社の Web サイトを管理しています。

• ウェブサイト A は複数の製品を販売する電子商取引サイトです。
• ウェブサイト B は、シングル ページのアプリケーションをホストする保険会社です。このアプリケーションを使用すると、ユーザーは登録し、自分のアカウントで Web サイトにログインし、ポリシーを管理できます。

両方の Web サイトは同様の URL プロパティを共有しています。

同じ URL プロパティを共有しているにもかかわらず、2 つの Web サイトでは完全に異なる Web トラッキング ニーズが必要です。

組織は、ウェブサイトAとウェブサイトBの両方の固有のウェブトラッキング要件を、従来のウェブトラッキング設定に変換しようとします。メニュー>オーケストレーション>予測エンゲージメント設定その結果、次のような追跡動作が発生します。

Predictive Engagement による集中化された Web トラッキング設定の制限を克服するために、組織は、Web サイト A と Web サイト B にそれぞれ展開された 2 つの Messenger 構成を編集し、両方に対して Messenger から直接個別の Web トラッキング設定を定義することにしました。それぞれの Web トラッキング設定は次のように構成されています。

• マーケティング チームは、Web サイト B では通常の訪問者として表示されますが、Web サイト A では追跡対象から除外されます。
• ウェブサイト A の URL でビジネス ニーズに関連する情報を取得しますが、ウェブサイト B では、関連するナビゲーション データをキャプチャしながら、URL に保存されている機密データを正常に除外しています。

シナリオ2:構成を分離することで所有権の曖昧さと構成の乱雑さを解消する

組織には複数のビジネス管理者がおり、それぞれが異なる Web サイトでの Web トラッキングの管理を担当しています。予測エンゲージメントでは、Web トラッキング設定に複数のユーザーエントリが存在すると、所有権の境界が曖昧になり、各フィールドの明確さが低下します。その結果、ビジネス管理者は、各設定がどの Web サイトに適用されるのか、あるいはまだ適用されるのかどうか判断するのに苦労します。誤って複数のデプロイメントに影響を与えるリスクを回避するために、古い値が構成内に残されることがよくあります。

予測エンゲージメントの組織の Web トラッキング設定には、次のように構成された複数のユーザー貢献が含まれています。

代わりに、それぞれの Messenger 設定で個別の Web トラッキング設定を構成することで、ビジネス管理者は所有権と責任を明確に分離できます。各管理者は、次に示すように、他の管理者が構成した追跡動作に影響を与えることなく、自分が管理する特定の Web サイトに展開された独自の追跡構成を維持できます。

シナリオ3:デフォルトのウェブトラッキング設定を許可する

ある企業は、公開されているメインの Web サイトを管理し、社内開発とテスト専用のさまざまな Web ドメインを所有しています。エンジニアリング チームは開発環境を使用して、会社の Web サイトを保守および改善します。コードが完成すると、変更を安全に公開する前にテスト環境に追加されます。メインの Web サイトは顧客専用であり、機密性の高いユーザー データを処理しますが、テストのニーズに十分なイベント データが収集されるように、内部の Web ドメインでは追跡の制限が発生してはなりません。

同社では、公開 Web サイト、開発環境、テスト環境の 3 つの異なる Messenger 構成を使用して、開発の 3 つの段階を管理しています。3 つの Web トラッキング設定すべてが Predictive Engagement の集中管理された従来の設定で構成されていた場合、企業は次のような妥協を迫られる可能性があります。 

• 内部環境で追跡されるデータの量により、開発タスクとテストを完了するためのエンジニアリング チームの可視性が低下し、公開されている Web サイトから機密性の高いユーザー データが取得されることが回避されます。
• ウェブトラッキング設定をデフォルトのままにして、開発とテストのニーズに対応するためにフィルタリングされていないデータを取得すると、一般向けウェブサイトで機密性の高いユーザーデータが収集され、プライバシーコンプライアンスに違反することになります。

同社はリスクを認識した上で、次に示すように、公開 Web サイトの Messenger 構成で特定の値を指定して Web トラッキング構成を分離し、トラッキング動作をビジネス ニーズとデータ コンプライアンスに適合させることを選択しました。開発とテスト専用の両方の Messenger 構成も、デフォルトのトラッキング値を使用して Messenger 固有の Web トラッキング設定に設定されます。つまり、ユーザーは無視されず、すべての URL クエリ パラメータが追跡されます。これにより、すべてのナビゲーション データが収集されます。

シナリオ4:ウェブトラッキング設定をテストする

管理者ユーザーは、自社の Web トラッキング実装を担当します。同社は、Web 訪問者が検索したキーワードを記録しながら、社内従業員の IP アドレスと機密性の高いユーザー データが公開 Web サイトで追跡されないようにしたいと考えています。実稼働中の公開 Web サイトにこれらを適用する前に、Messenger 固有の Web トラッキング設定が適切に定義されていることを確認する必要があります。Messenger の設定を編集して、社内従業員の IP アドレス、不要なデータを保存するクエリ パラメータ、ユーザーが検索した用語を保存するために使用されるクエリ パラメータを指定します。新しい Messenger 構成バージョンは次のように作成されます。

テスト目的で作成された Test Env という名前の Messenger 展開で、管理者は新しい Web トラッキング設定を含む、作成した最新の Messenger 構成バージョンを選択します。一方、Messenger 固有のデフォルトの Web トラッキング設定が含まれる以前の Messenger 構成バージョンは、現在も実稼働バージョンとして使用されています。

管理者は、新しい設定が適用されるテスト環境内を移動して、Web 訪問者の行動をシミュレートします。管理者は、URL フラグメント トラッキングをデフォルトで無効のままにしておくと、かなりの量のデータが失われていることに気付きました。ナビゲーションは部分的にしか追跡されません。テスト中に訪問したいくつかのページがカスタマージャーニービュー。管理者は、URL フラグメント トラッキングを有効にした新しい Messenger 構成バージョンを作成します。

繰り返しになりますが、最新の Web トラッキング構成は、本番環境に展開する前にテストする必要があります。管理者は、Test Env Messenger の展開を編集して、URL フラグメント トラッキングを含む最新の Messenger 構成バージョンを割り当てます。

新しい構成では、ビジネス要件に合わせて、すべての Web ページが期待どおりに追跡されます。管理者は、最新の Messenger 構成バージョンを安全に本番環境に展開し、これらの Web トラッキング設定を公開 Web サイトに適用できるようになりました。