トラッキングタグを実装してわかったこと

PLAN-Bではデジタルマーケティング領域のSaaSを複数提供しています。
提供している機能の中には、お客様のWebサイトにタグ(≒トラッキングタグ)を入れてもらうことで動くようになるものがあります。自社のサービス上ではなくお客様のWebサイト上で動くものなので、一般的なWebサービスの開発とは違った観点が必要になってきます。本記事ではどのような気にするべきことがあるかや、開発してわかったことをまとめました。

トラッキングタグってなんだっけ？

代表的な物でいうと、GoogleAnalytics（以下「GA」という）です。トラッキングタグにもいろんな種類がありますが、GAをイメージするのが、一番分かりやすいかと思います。

何かしらのHTMLタグを任意のウェブサイトに設置する事で、 設置したウェブサイトの分析データを管理画面などで確認できるようになるイメージです。
GAの場合だと、設置したウェブサイトの「セッション数」や「PV数」といった指標の集計結果が管理画面で見る事ができますよね？

※ 何を分析してくれるのか？管理画面で何が見れるか？などは各トラッキングタグの用途や目的によって違います。

トラッキングタグの仕組み

トラッキングタグの仕組みはタグにより様々ですが、 基本は以下の様な仕組みの物が多いです。

タグ形式で任意のサーバーに通信させる

例えば、以下のようなタグコードをウェブサイトに設置してもらうとします。

<script src="//tag.example.com/"></script> 

このタグを設置してもらう事によって、タグ設置サイトから「//tag.example.com」というサイトにHTTP (HTTPS) 通信が発生します。
一番単純な例としては、この通信ログを集計する事でページ別のページビューが分かりますよね？といったニュアンスです。

通信先のサーバーからトラッキング用スクリプトを返す

スクリプト形式で埋め込んでいるトラッキングタグの場合は、何らかのトラッキング用スクリプトを設置したサイトに出力する事がほとんどです。

例えば…
旧GA（ユニバーサルアナリティクス）では、設置コードは以下のような内容でした。

上記の設置コードで、赤文字になっているURL部分をブラウザで開くと、JavaScriptが表示されます。
このJavaScriptの挙動を一つ一つ追っていくと、旧GAのトラッキングコードが設置サイトでどういう処理を行い、どういうデータを送信しているのか？少し理解する事ができるかもしれません。

イベントログを送信する

トラッキング用スクリプトで詳細なトラッキングログを送信したり、ボタンクリックなどのイベントログを送信します。

トラッキング用スクリプトを返す事で、設置したサイトに対して、独自のトラッキング処理を行います。

例えば…　　

• GAのようにサイト分析に必要なセッション数や訪問ユーザー数などを計測するためのログを送信する。
• ヒートマップを作成するためにマウス操作位置のログを送信したり、ブラウザのスクロール位置のログを送信する。

などなど、トラッキングタグの種類によって、千差万別です。

トラッキングタグを自前で開発する時に考えたい3つのポイント

PLAN-Bの開発業務でも、過去に何度かトラッキングタグを自前で開発しようという企画がありました。

それらを通じて、私が感じた「トラッキングタグを開発する前に必ず確認しておきたい・しっかり考えておきたい」と思うは以下の3つです。

それ、本当にトラッキングタグを作る必要があるかなぁ？

例えばGAと同じ様なサイト分析をしたいのであれば、必要な各指標はGAのレポートAPI経由で取得する事ができます。

このAPIを上手く使えば、自社サービスと組み合わせて、クライアントに分析ダッシュボードを提供する事もできます。

他にも私が知らないだけでいろんな埋め込み型タグとそれを操作するためのAPIがあると思います。案件の要件にもよりますが、場合によっては組み合わせて使う事で、実現したい要件を達成する事ができる事もあると思います。

アクセス負荷に耐えられるか

不特定多数のサイトにトラッキングタグを埋め込んでもらう場合、スクリプト配信サーバーとログ受信サーバーの負荷耐性は必ず考えておかなければいけません。埋め込んだサイトのアクセス数がスパイクした時、アクセスログを欠損する事なく受信できるサーバー設計が必要です。

同時に、負荷レベルに合わせて、配信・受信サーバーが自動でスケールイン・アウトするインフラ設計が必要です。

こちらについては、AWSやGCP、Azureといった大手クラウドサービスのサービスを組みわせれば、比較的難易度は高くないかもしれません。
想定外のトラフィック増減は、経験上ですが起きる可能性が高いので、「本当に設計通り動くか？」「本当に設計通り負荷があがっても動作するか？」の検証はしておきたいですね。

集めたログを集計するための集計基盤のアーキテクチャ設計

ログを集めるという事は、そのログに対して、何らかの集計処理が必要になります。ただの単純な集計であっても、月間100万ページビューと月間○億ページビューであれば、開発に使う技術やインフラが大きく変わる事が多いです。

たとえば、月間100万PVのログに対して、集計を行うだけであれば、集計内容にもよりますが、シンプルにMySQLやPostgreSQLといった馴染み深いデータベースのSELECT文だけでも実行可能かもしれません。

しかし、それが月間○億で○年間のログをさかのぼって集計処理を行うとなると、データベースではかなり厳しくなるかもしれません。

• タグを設置してくれるサイト数は、無制限なのか？最大数が決まっているのか？
• タグを設置するサイトのページビュー数は、どの程度あるのか？

こちらの要件は、しっかりキメを決めた上で、サービス要件に合わせた集計基盤の設計を行う事が必要です。

トラッキングタグを自前で開発し提供する時のリスク

私個人としては、トラッキングタグについては、作らずに既存サービスを組み合わせて実用化できるなら、それがベストだと思います。
開発のメンテナンスの工数を考えた時、選択肢としてもアリかなと感じています。

どんなサイトにどれだけ設置されるかわからないトラッキングタグは、それだけ障害の発生リスクが高いです。

• 自分が提供しているタグに不具合があったため、設置サイト自体に悪い影響を与えてしまう
• ある特定のサイトのみ、何故かログが送信されない
• 導入者数は伸びたが、タグサーバーのインフラコストが想定以上になり、ビジネスとして成立しない

などなど、弊社でもトラッキングタグの開発知見が少ない段階の時は、様々な問題がおきました。

またタグ設置が始まると、通常のウェブアプリケーションと比べ、リプレイスの難易度も跳ね上がるという印象です。
そういった点でもトラッキングタグのインフラ設計については、通常より慎重に行うために時間を多め割きたいと社内では、ビジネスに携わる関係各所の方々には、常々お願させて頂いております。

まとめ

トラッキングタグの自社開発について、少し後ろ向きな意見をいくつか書きましたが、個人的には以下のような、自社開発を検討したくなる点もあります。

めっちゃロマンのある開発ができる

通常ではお目にかかれない大量ページビューのコントロール経験
難易度が高い開発って、幾つになっても楽しい

サイト分析に使う各指標に対する理解が深くなった

トラッキングタグを開発するまでは、セッション数やクリック数などについて、分かった気になっていただけで、本質的にはあまり理解してなかったと思います。今思えばGAについても只眺めていただけだったような気がします。
トラッキングタグを実装する事によって、各指標の重要性や使い所のような物が、凄く腹落ちした感があります。

データのIN/OUTについての価値観・意識が変わった

タグを初めて実装する前の自分は、正直な所、目の前のアプリケーションに対するデータのイン・アウトしか見えていませんでした。
ですが、トラッキングタグ開発を経験した後は、上手くいえないですが、各システムレベルの単位で俯瞰的にデータのイン・アウトを意識できるようになった気がします。(気がしてるだけ感も強いですが。。。

さいごに

エンジニアとして、トラッキングタグの開発を経験出来た事は、凄く大きかったなと本当に思います。

もし、トラッキングタグをこれから開発しなければならない、悩んでおられるエンジニアの方がいらっしゃれば、本記事での検討項目や注意事項を参考にしてもらえると嬉しいです。