サーバー側トラッキングの利点と欠点
公開: 2022-04-07Google タグ マネージャーのサーバー サイド コンテナ(SSC) に関する以前の投稿で、その仕組みについて調べ始めました。 この投稿では、サーバー側システムがもたらす主な利点と、潜在的な欠点をいくつか見ていきます。
利点
サーバーサイドトラッキングの利点について言えば、主に収集するデータの制御と柔軟性に関係する主要なものがいくつかあります。 これは、さまざまなデータ法を遵守し、あなたとあなたのユーザーのデータを安全に保ち、可能な限り正確なデータを確保し、データがどこにどのように移動するかを決定し、潜在的にサイトのパフォーマンスを向上させる方法に影響を与えます.
1) コンプライアンス
データをインターセプトすることにより、サーバーサイド コンテナはデータが最終的な送信先に送信される前にデータを変更できます。 これは、最終目的地に到着する前にプロファイリングやフィンガープリンティングに使用される可能性のある情報を削除できるため、 GDPR コンプライアンスや同様のプライバシー保護に大きなメリットがあります。
サーバーサイドコンテナが機能するサーバーは、場所を指定できます。 したがって、この識別可能なデータは、削除される前に収集された地域 (GDPR にとって最も重要な EU) を離れる必要はありません。
ただし、識別可能なデータを操作および削除すると、一部の情報がツールに表示されなくなる可能性があることに注意してください。 たとえば、Google アナリティクスにデータを送信するときにユーザーの IP を削除またはマスキングすると、位置データを取得できなくなる可能性があります。
2) ファーストパーティ Cookie
データは Server-Side Container を介して送信されるため、サイトに返されるデータに変更を加えることができます。 そのため、特定のツールの Cookie が設定されているドメインが変更される可能性があります。 独自のドメインに Cookie を設定できます。 これは、サード パーティの Cookie の設定を制限またはブロックするブラウザーが、早期に期限切れになったり、Cookie の設定をブロックしたりしないことを意味します。
3) 1 つのツールのデータを収集し、他のツールに書き込む
データが Web サイトから送信される場合、そのデータは 1 つのツールを対象としている可能性がありますが、解析されて他のツールに送信される可能性があります。 これは、多くの場合に非常に役立ちます。 この例として、ユニバーサル アナリティクスリクエストから受信ヒットを取得し、データを解析して、Google BigQuery テーブルに送信することができます。 この機能は、プレミアム ユニバーサル アナリティクス 360 プロダクトのユニバーサル アナリティクスでのみ利用できます。
4) クライアント側の負荷軽減
データの処理の大部分をサーバー側コンテナーに移動することで、ユーザーのブラウザーがサイトをロードする際の負荷を軽減できます。
5) API キーとクライアント シークレットを非表示にする
データはサーバー側コンテナーから最終的なツールにのみ送信されるため、すべての API キーとクライアント シークレットをサーバー側コンテナーに格納できます。 これにより、これらがクライアント側で公開される可能性が回避されます。 この例は、Google アナリティクスの UA-ID です。 サード パーティは、Google アナリティクスを実行している任意のサイトにアクセスし、UA-ID をサイトから取り出して別のサイトに置き、Google アナリティクス アカウントにスパムを送ることができます。 私たちは、これが何年にもわたって頻繁に起こるのを見てきました. サーバー側のトラッキングでは、UA-ID はサーバー側でのみ追加でき、Web サイトの読み込み時にまったく公開されないため、これは不可能です。
6) 独自のドメインからトラッキング スクリプトを読み込む
これは、サーバー側トラッキングの長所と短所の両方と見なすことができます。 サーバー側コンテナは問題のツールを直接呼び出すことができるため、サーバー側コンテナを使用して、ほとんどのツール (GA、Facebook、LinkedIn など) がサイトに取り込む JavaScript ファイルを取得できます。 取得すると、ファイルをサイトに送信できます。 これは、ユーザーのブラウザから直接サードパーティのサイトを呼び出すことを回避でき、不要なスクリプトが取り込まれるのを防ぐのに役立つことを意味します。このファイルは独自のドメインから送信されるため (SCC がこのように設定されている場合)、既知のトラッカーを自動的にブロックするサービス (つまり、Firefox、Safari、Brave などのブラウザー) は、ファイルを追跡スクリプトとして認識しません。 サイト独自のドメインが最終的にこれらのサービスによってトラッカーとして識別される可能性があるため、これは常に保証されるわけではありません. 分析プログラムは常にユーザーのプライバシーの選択を尊重する必要があることを覚えておくことが重要です。
短所
サーバー側の追跡には、知っておくべき欠点とシナリオがいくつかあります。 これらのポイントは、サーバー側の追跡を実行するために必要な余分な作業と、自分のデータの正確性とユーザーのプライバシーに対してより責任を負うことの落とし穴のいずれかです.
1) 技術的専門知識
クライアントのコーディングなど、サーバー側トラッキングのより技術的な側面のいくつかは絶対に必要というわけではありませんが、クリアしなければならない技術的な障壁がまだいくつかあります。 これには、最初のサーバー インスタンスのセットアップと、ソリューションを稼働させる際の冗長サーバーのプロビジョニングが含まれます。
2) データの正確さはあなた次第
クライアントまたはタグをコーディングしている場合、データが正しい形式で宛先に到達することを確認する責任は、あなたとあなたのコードにあります。 これは、ミスが発生する余地が追加されていることを意味します。 また、送信されたデータの送信が法的に許可されていることを確認する責任もあります。
3) コスト
Google タグ マネージャーのウェブ コンテナとは異なり、サーバーサイド トラッキングには費用がかかります。 サーバーサイド コンテナを実行するには、App Engine 機能を使用して Google Cloud インフラストラクチャで作成する必要があります。また、冗長性と容量を考慮して、いくつかのサーバー インスタンスで実行する必要があります。 これらのインスタンスの料金を支払う必要があります。 もちろん、実行するサーバーが増え、送信するデータが増えるほど、コストは高くなります。
4) プライバシーに関する懸念
これについてはすでに触れましたが、サーバー側の追跡に関する懸念は、ユーザーが追跡を防止するために実施したいくつかの手段を簡単に回避できることです。 ユーザーのプライバシーに関する決定が尊重され、関連する法律や規制が遵守されていることを確認することが重要です。
サーバーサイド トラッキングについて詳しくお知りになりたい場合は、メッセージを残していただければ、ご質問やご要望について喜んでお応えいたします。