この記事は『LITALICO Engineers Advent Calendar 2019』の 16 日目の記事です。
はじめに
弊社では、LITALICO 発達ナビ・LITALICO 仕事ナビ・LITALICO キャリアという複数の Web サービスを運用しています。
各サービスにはエンジニアだけではなく、営業・カスタマーサクセス・コンテンツエディターなどのビジネス職の方もたくさんいます。
そのため、ビジネス職の方も数値分析を行えるように Google Analytics（以下、GA）を運用しています。
私の所属している「LITALICO仕事ナビ」でも GA を一応使ってきました。
しかし今まではエンジニアが主に数値分析まで担当することが多く、GA の使い方にも不慣れだったため、「欲しいデータはログから SQL 書いて取ってくれば良いよね」という感じで、あまりがっつりと運用はしてきませんでした。
ところが最近、経験豊富なマーケターの方にジョインしていただいたのと、ビジネス職の方からも「毎回データを見る度にエンジニアに依頼するのは申し訳ない」という温かい声をいただいたので、本格的に GA を運用することになりました。
その経験を元に、この記事では GA を使う意味をちゃんと理解した上で、最終的に「この記事を読めばチームで GA を最低限導入できる」というところを目指したいと思います。
この記事を読んで分かること
この記事のタイトル「Google Analytics を導入しようとなった時にエンジニアがやるべきこと」、それは上記の３つを理解し、本当に GA は導入するべきなのか、導入するなら gtag.js と Google Tag Manager（以下、GTM）のどちらを使うのかを意思決定し実際に導入することです。
GA を導入する前に確認しておきたいこと
そもそもどうして GA を使うのか
「はじめに」で書いたような「サイトのパフォーマンスをビジネス職でも自分で見られるようにしたい」という要望は、様々なところであるのではないかと思います。
その要望を叶える手段として GA は２つの理由で強力です。
１つ目は無料だということ。無料ですが、ユーザーが１セッションでページ遷移を伴う行動であれば、どんな行動を取ったのか、必要なデータは十分に確認することができます。
無料にも関わらず十分な機能が付いているのは、今のところ GA は「Google 広告のフロントエンド商品」と位置付けられているためではないかと個人的には考えています。
２つ目は、SQL が分からなくてもユーザーの行動分析ができるという点です。
GUI の操作で簡単にデータを確認することができるため、ビジネス職の方が SQL を書けるようになる必要がありません。
上記２つの理由から、エンジニア以外には SQL の書ける人がいない環境ではかなり有用なツールだと言えます。
GA の限界
一方で、GA にも限界はあります。
上述したように、「ユーザーが１セッションでページ遷移を伴う行動であれば」どんな行動を取ったのかは追えますが、「電話ボタンのクリック」などページ遷移を伴わない行動や、「会員登録したユーザーの長期的な行動」などの１セッションではない行動は GA ではデフォルトでは追えません。
これらの行動を取得したい場合は、イベントトラッキングやカスタムディメンションと呼ばれるものを追加で設定する必要があります。
どのような作業を伴うかは、下で解説します。
また、数値の正確性という面でも若干の難点が残ります。
これは GA が悪いという話ではなく当然の話ですが、ログを自前で集計するよりも若干数値の正確性は落ちるため、事業 KGI・KPI としているような指標で使うと誤った意思決定をしてしまいかねません。
しかし、数値の桁が違うなどはさすがに起こらないため数値の傾向を知るには十分です。
GA を導入する前に確認しておきたいことのまとめ
GA の導入法
では、ここから導入法です。
上述の通り、ユーザーが１セッションでページ遷移を伴う行動であれば GA はデフォルトで計測することができます。
これだけの用途で良いのであれば、導入は一瞬で、GA のアカウントを発行して、サイトにグローバルサイトタグをコピペで貼り付ければ終了です。
こちらのサイトの説明が分かりやすいかと思います。
そして少し厄介なのが、イベントトラッキングやカスタムディメンションの設定でした。
ここで登場するのが、gtag.js と GTM です。
gtag.js とは
gtag.js は、公式ドキュメントでは以下のように説明されています。
Google アナリティクス、Google 広告、Google マーケティング プラットフォームにイベントデータを送信できる、JavaScript のタグ設定フレームワークおよび API です。
つまり、GA ではデフォルトで計測できない「電話ボタンのクリック」もクリックイベントを gtag.js で GA に送れば計測できる上に、「会員登録したユーザーの長期的な行動」も会員 ID をカスタムディメンションとしてログと一緒に GA に送れば計測できるようになります。
gtag.js を用いたクリックイベントの送信
では実際にクリックイベントを送信するコードを見ていきます。
サンプルコードとして、Rails と React を用いた例を載せていきます。
もっと一般的な書き方が知りたい方は公式ドキュメントをご覧ください。
ここでは１つのページに、複数の電話ボタンが置かれているものを想定しています。
__tel_button.html.erb
<div>
<%= link_to 'tel:' + tel_number, class: 'TelButton' do %>
<div><%= tel_number %></div>
<% end %>
</div>
google_analytics.ts import isEmpty from 'lodash-es/isEmpty'; declare function gtag(...args: any[]): any; const telButtons = document.getElementsByClassName('TelButton'); if (!isEmpty(telButtons)) { const gtagReportConversion = (url?: Location) => { const callback = () => { if (typeof url !== 'undefined') { window.location = url; } }; gtag('event', 'conversion', { event_callback: callback, event_category: 'click', event_label: 'tel_button', send_to: 'UA-◯◯◯◯◯◯' //トラッキングID }); return false; }; for (const button of telButtons) { button.addEventListener('click', () => gtagReportConversion()); } }
TelButton というクラス名で React コンポーネントをマウントして、クリックイベントで gtag の関数が発火するようにしています。
event_category や event_label は設定しなくても動きはしますが、GA 側で設定しておいてイベントと一緒に送るようにしておくと、計測イベントがどんどん増えていっても管理がしやすいです。
GA 側の設定は他にたくさん記事があるので、ここでは割愛します。
こちらの記事を参考にすると良いかと思います。
ただしこちらの記事では gtag.js ではなく、analytics.js が使われているので要注意です。
これでクリックイベントが計測できるようになりました。
gtag.js を用いたカスタムディメンションの送信
では次にカスタムディメンションの送信です。
こちらもサンプルコードとして、Rails と React を用いた例を載せていきます。
公式ドキュメントはこちら
application.html.erb ... <body> ... <div id="UserDimension" data-user-id="<%= current_user&.id %>"></div> ... </body> ...
google_analytics.ts gtag('config', 'UA-◯◯◯◯◯◯', { custom_map: { dimension1: 'user_id' } }); const userDimension = document.getElementById('UserDimension'); if (userDimension) { const { userId } = userDimension.dataset; gtag('event', 'page_view', { send_to: 'UA-◯◯◯◯◯◯', //トラッキングID user_id: userId }); }
GA にログを送るために config を設定しなければいけません。
その config を設定する箇所で送りたいカスタムディメンションを宣言します。
ここでは、user_id というカスタムディメンションを一緒に送るよと宣言しています。
あとは UserDimension という id でマウントして page_view イベントと一緒に user_id を送ってしまえば完了です。
ただこれも GA 側で受け取りの設定をしなくてはいけません。
こちらもGA 側の設定は他にたくさん記事があるので割愛します。
こちらの記事を参考にすると良いかと思います。
これで、GA にカスタムディメンションを送れるようになりました。
GTM とは
次は GTM についてです。
GTM は、公式ドキュメントでは以下のように説明されています。
ウェブサイトやモバイルアプリに含まれる「タグ」（トラッキングコードや関連するコードの総称）を素早く簡単に更新できるタグ管理システムです。
・・・（中略）・・・
特定のイベントが発生したときにタグを起動させるトリガーを確立し、タグ設定を簡単かつ自動で行うために使用できる変数を作成します。
つまり、ページビューや電話クリックという「トリガー」を元に起動される「タグ」と呼ばれるものを作ることができます。
このタグによって GA にログやイベントを送ることができます。
例えば、先程の電話クリックの例では以下のような図になります。
この GTM の導入ですが、導入自体は簡単で、GA と同じようにアカウントを発行して、サイトにタグを貼り付ければ終了です。
以下の記事を見ると、すぐにできると思います。
そして GTM を用いたイベントの送信は、gtag.js のようにコードの変更は必要ありません。
GTM のコンソール上で、タグとトリガーを作るだけで計測が可能になります。
GTM の使い方は、こちらで学べます。
GTM 導入の落とし穴
ここまでの話だと、「gtag.js はコードの変更伴うけど、GTM は伴わないからビジネス職に数値分析してもらうなら GTM 一択じゃね？」という感じだと思います。
しかし、環境によっては GTM 導入後にちゃんと正しく動いてくれないことがあります。
現に私のチームでは、GTM を導入したは良いものの、Rails に導入されていた turbolinks との噛み合いのせいで上手く動かず、デバッグに結構な時間を費やしました。
また、この記事を書いている現在でも一定の条件で上手く行かない現象を確認しており、こちらは原因もよく分かっていない状態です。
GTM の中がかなりブラックボックス化されているのでデバッグが難しく、何らかの原因で動かなくなったときは手がかりがないので、そういう意味では gtag.js の方が扱いやすいとも言えます。
gtag.js と GTM のそれぞれの使いどころ
各々のメリットは、今までの話をまとめると以下のようになります。
GTM はコードの変更を伴わず、ビジネス職の方から導入を熱望されやすいです。
ただ、そこでよく検討せずに導入してしまうと膨大なメンテコストを払わなくてはならなくなる危険性があります。
本格導入をするのであれば、コードの変更を伴わないというメリットはかなり強力なのでメンテコストを払ってでも GTM に踏み切るべきですが、ちょっと GA を使ってみたいというレベルであれば、最初は gtag.js を使っておいて、後に GTM に切り替えるというやり方がベストだろうなと考えています。
GA を導入するとなったら、ここをエンジニアがしっかり判断しなければならないだろうなと感じました。
終わりに
以上、「Google Analytics を導入しようとなった時にエンジニアがやるべきこと」に付いて書きました。
「本当に導入するのか」はしっかりと考えた方が良いという考えを述べましたが、GA や GTM 自体はとても素晴らしいツールなので、使いこなせるようになって損はないと思います。
明日の記事は @ti_aiuto さんの「歴史あるRailsアプリケーションのリファクタについて考えていることなど」です。お楽しみに！