GTM on Marketechlabo

URLの指定の仕方

Mon, 17 Jun 2019 00:00:00 +0900

JavaScriptでURLを表すlocationオブジェクト

URLとそのパーツはJavaScriptの変数として取得できる。

タグマネージャなどでJavaScriptの変数を使ってURL（の一部）を指定する場合や、直接Javascriptを書いてURLを指定する場合にこれらを使うことがある。

変数名	意味	例
`window.location.href`	URL全体	https://example.com/audio/detail.php?id=123#rev
`window.location.protocol`	プロトコル	https:
`window.location.hostname`	ホスト名	example.com
`window.location.port`	ポート番号（デフォルトポートの場合は空文字）
`window.location.pathname`	パス名	/audio/detail.php
`window.location.search`	クエリ文字列	?id=123
`window.location.hash`	ハッシュ	#rev

（「window.」は省略可）

たとえば

if (location.hostname.indexOf('example.com') > -1 && /\/detail\.html$/.test(location.pathname)) {
 // マッチしたときの処理。以下は外部スクリプトファイルを読み込む例
 var t = document.createElement('script'); t.async = true; t.src = '//js/lib.js';
 var s = document.getElementsByTagName('script')[0];
 s.parentNode.insertBefore(t, s);
}

location.hostname.indexOf('example.com') > -1でホスト名に「example.com」を含み、
/\/detail\.html$/.test(location.pathname)でパス名が「/detail.html」で終わる

URLを指定している。

（参考）正規表現

いろいろなパターンの文字列をまとめて指定するものである。

正規表現の使い道

正規表現を使う処理には

マッチするかどうか判定（match）
マッチした部分の抽出（extract）: URLからディレクトリ名の抽出などに使う
置換（replace）

がある。

どんなプログラミング言語でもSQLでもBIツールでもこの3種類の処理は備わっている。

レベル別正規表現

正規表現の学習の詳細は他の教材に任せるが、学ぶ際のコツとして難易度別に段階的に学ぶことが挙げられる。

レベル1: 特殊文字：1文字を表すもの

. 何でも1文字（改行以外）
^ 行頭
$ 行末
\n ラインフィード（LF）
\r キャリッジリターン（CR）

レベル1: 特定の種類の文字を表すもの

\d: 任意の数字
\w: 任意の英数字かアンダースコア_
\s: 空白文字（ホワイトスペース、タブ、改行文字）

\Dなどの大文字は否定（数字以外の文字）を表す。

Googleタグマネージャーの使い方＆設定をExcelで出力するツール

Tue, 17 Sep 2019 00:00:00 +0900

Googleタグマネージャー（GTM）を使ったタグマネジメントについて解説する。前半ではタグマネジメントの概念と仕組みの一般論、後半ではGTMの具体的な設定方法を説明する。

タグマネジメントとタグマネージャ

タグマネジメントとはwebサイトに設置するタグの一元管理である。管理すべきタグには以下のようなものがある。

アクセス解析ツールのタグ
広告のコンバージョンタグ
リマーケティングタグ
接客ツール（チャットなど）のタグ
ABテストツールのタグ

web施策が進んでいくと、これらのタグを複数、それぞれ異なるページに設置する必要が出てくる。どのタグをどんな条件で設置したか管理し、不要になったタグは削除するなどの運用を徹底しておかないと、同じ目的のタグを重複設置したり、古いタグがページ表示の不具合を引き起こしたりする。担当者が変わった際にも「どこにどのタグをどんな目的で設置したか」を把握できるようにしておく必要がある。

タグマネージャはこの管理を支援するツールで、サイトのHTMLにはタグマネージャのタグのみを設置し、個別のタグは管理画面上で設定する。ただしツール導入だけで管理が完結するわけではなく、人の手による運用ルールもセットで成立する。タグと発火条件（※タグが実行されることを「発火する」（fire）という）、名前と目的を一覧管理する管理表を作るといい。

タグマネージャを導入するメリット

タグの追加・削除時にHTMLの改修が不要→設置工数が大幅低減
検証モードで本番公開前に動作確認できる
タグの実行順序を指定できる
不具合発生時に過去の状態にロールバックできる

どのタグマネージャも共通して設定するのがタグ、発火条件（トリガー）、データレイヤー（タグマネージャにデータを渡す仕組み）の3点である。

GTMとは

Googleタグマネージャー（GTM）はGoogleが提供している無料のタグマネージャ。Googleアナリティクス（GA4）やGoogle広告との親和性が高く、無料でもあるので独立したタグマネージャとしても十分使える。

設置

タグは2個あり、両方設置する。それぞれ設置個所が決まっている。

<head>～</head>内
<body>開始タグの直後

ここにないとSearch Consoleなどの認証で失敗する。

タグの設定

タグ＋トリガー＋変数のセット→これら設定の一式をコンテナという。

タグ→実行するタグ
トリガー→タグの実行（発火）条件
変数
- トリガーの中での条件判定に使う
- タグに動的に値を渡す（データレイヤー）

条件判定で使う変数は、たとえばクリックしたリンクのURLやログイン済みかどうかのフラグなど、その値によってタグを実行するかどうかの扱いが変わるもの。タグに動的に値を渡すというのはサーバから出力される問合せ番号や注文番号など。サーバで処理をした結果をGoogleアナリティクスや広告のコンバージョンタグなどに送りたい場合に使う。

コンテナ

現在のタグ一式（タグ＋トリガー＋変数）をまとめたもの
タグを登録しただけでは有効にならず、公開（パブリッシュ）するとはじめて本番環境に反映される
バージョン管理の仕組みがあり、過去のバージョンへのロールバックも容易
複数人で更新可能（ワークスペース）

ワークスペース

複数人で同時に一つのコンテナを管理、更新できる
その際の各人の作業用のコンテナをワークスペースという
自分のワークスペースで行った設定をコンテナに反映し、公開する

ワークスペースと現在のコンテナとの差分を管理する。コンテナは複数人で更新するため、現在のコンテナは必ずしも自分がワークスペースを作成した時点のバージョンと一致するわけではない（自分がコンテナを取得した以降に他人がコンテナを更新している可能性がある）。他人がコンテナへのマージをした後、自分の変更点のみマージすることが可能。

公開

設定の流れ

現在公開されている（最新の）コンテナからコピーしてワークスペースを作る
自分のワークスペースで設定
動作確認（プレビュー）
「送信」して変更を最新のバージョンのコンテナと比較、確認
「公開」

送信→公開するのを忘れずに。初心者あるある。

高度な計測に使えるGTMの黒魔術とタグアシスタントの裏技

Thu, 13 Aug 2020 00:00:00 +0900

GTMとGA4の高度な使い方。設定しておくと便利な変数やトリガーの使い方に加え、データレイヤーを徹底的に使いこなす。さらには計測だけでなく検証の手間を大幅に省くタグアシスタントの裏技を紹介する。

GTM設定の黒魔術

便利な変数

ページビューID

ページビュー固有のID。一度ページを読み込んでから、次に読み込むまでの間で保持されるIDで、そのIDをさまざまなツールに送ればそれをキーにデータ連携できる。ツールA,B,Cの間でIDを連携する場合、

ツールAのIDを取得→Bに送る
ツールAのIDを取得→Cに送る
ツールBのIDを取得→Cに送る
（CのIDを取得→Aに送る？）
（CのIDを取得→Bに送る？）

など、ツール数が増えると複雑になる。ツールAのIDはツールAのタグが処理完了しないと取得できず、それを受けてIDを送るタグはその後に発火させる必要があるなど、タイミングのコントロールも難しくなる。ページビューIDを使うと

PVID→ツールAに送る
PVID→ツールBに送る
PVID→ツールCに送る

となるのでシンプル。ページビューIDは最初に生成しておけばいい。ログ分析を進めていくと、どのイベントがどのページビューにおいて発生したものなのか知りたくなることがある。たとえばスクロールや動画再生などは典型的。イベントのレコードでページパスは記録されている（どこのページかはわかる）が、いつのページビューかは実はわからない。またページの表示内容を変えるABテストもどのページビューにおいて発生したのかがわからないと分析が不正確になる（同じトップページでも1PV目なのか2PV目なのか）。これらは単純にログを上から見ていけばわかるというものではない。たとえば最初にタブをまとめて開いておいて、後でページ閲覧するケース。この場合ページビューヒットとイベントヒットの順番がわからなくなる。これを解決するためにページビューに対してIDを割り振るといい。同一ページビューに対するすべてのヒット（ページビュー、イベント、トランザクション）はすべて同じIDが割り振られる。つまりページビューに紐づけることができるようになる。

GA4ではユーザ（user_pseudo_id）とセッション（ga_session_id）に対してIDが割り振られていることは知られているが、実はbatch_page_idがハードナビゲーションのページではページビューIDに該当する。しかしこの値はGA4以外のツールに連携することができないため、他のツールを含めて同じページビューIDの値を格納するためには、GTMで変数として設定する必要がある。

以下を変数／カスタムJavaScriptに設定する

function(){
 if (!window._pv_id) {
 window._pv_id = crypto.randomUUID()
 }
 return window._pv_id
}

最初に一度限りページビューIDを生成してwindowオブジェクトに保存する。 2回目以降はwindowオブジェクトの中のページビューIDを参照する。 crypto.randomUUID()はUUID v4形式の一意なIDを生成する標準APIで、すべてのモダンブラウザで利用できる。この変数を各ツールでカスタム変数（GA4ではイベントパラメータ）としてセットする。

データレイヤーイベントのおすすめ設定

データレイヤーにイベントを送るときは常に時刻も入れておくと検証しやすい。ページ読み込みからの経過ミリ秒にしておくとわかりやすくていい。

dataLayer.push({
 'event': 'イベント名',
 'time': Math.round(performance.now()),
});

performance.now()はナビゲーション開始からの経過ミリ秒を返す標準APIで、高精度かつDeprecatedでない。

便利なトリガー

「もしもイベントが発生していなかったら」という条件（トリガー）

トリガーで「イベントが発生したら・・・」という条件は設定できる。そして「あるイベントAが発生した時、イベントBが発生していたら・・・」はトリガーグループの機能を使えばいい。では「イベントAが発生したとき、イベントBが発生していなかったら・・・」という条件はどうやって実現するのか？そこでデータレイヤーイベントを使う。

dataLayer.filter(function (x) { return x.event === 'イベント名' }).length === 0

これがtrueであればそのイベントは発生していない。イベントBが発生していなければイベントCを発生させるコードが以下になる。これをトリガーAによって呼び出されるカスタムHTMLタグとして設定し、トリガーにデータレイヤーイベント「イベントC」を設定すればいい。

dataLayer.filter(function (x) { return x.event === 'イベントB' }).length === 0 && dataLayer.push({'event': 'イベントC'})

便利なイベントとデータレイヤー

ABテスト／ウェブ接客ツール

KARTEなどのABテストツール／ウェブ接客ツール（ウェブの出し分けツール）を計測ツールと連携する場合、ABテストで表示するHTML内に以下のスクリプトを入れておく

JavaScriptの計測タグと最近のウェブページレンダリング（SPA、SSRなど）

Thu, 07 Nov 2024 00:00:00 +0900

最近増えているSPA、SSR、SSGとは何か

最近ではSPA（シングルページアプリケーション）、SSR（サーバサイドレンダリング）などといったウェブページの表示の仕組みを採用するサイトが増えている。これらのページではウェブ解析ツールの計測タグや広告のリマーケティングタグなどが正しく動作しないことがある。SPAの仲間にはSSR、SSGがあるが、これらの共通点はSPA内でのページの遷移時にページの読み込み処理（ロード）が行われない点である。これらのページではページを最初に表示するときにだけ読み込み処理が行われる。そこでページのアセット（画像やJavaScriptのファイル）がまとめて読み込まれる。その後のページの切り替わり時にはページのボディ部分を部分的に書き換える処理が行われていく。ヘッダの画像などは最初に読み込まれたものがそのまま表示される。jQueryなどの大きなスクリプトファイルをもう一度読み込まれることもなく、最初に読み込んだものが使われ続ける。一方で各ページ固有の写真のファイルなどの新たなアセットだけが追加的に読み込まれることになる。一方で従来のページはMPA（マルチページアプリケーション）といってこれらと区別することがある。MPAではページが切り替わるたびにページの読み込み処理が行われる。ページが切り替わるたびにページのアセットの取得を行い（画像やスクリプトファイルはキャッシュがあれば毎回ダウンロードしないが）、HTMLのレンダリングもゼロから行う。 SPAでは表示内容を書き換えたいその都度、更新する部分のコンテンツだけをサーバから取得し、レンダリングそのものはブラウザ側で行うものを指すことが多い。 SSRではレンダリングの大部分をサーバで行う、ページの表示内容をサーバ側で組み上げてからブラウザに渡す。ブラウザ側では最小限のレンダリング処理で済ませるものである。それに対してレンダリング処理のすべてをブラウザ側で行うものをクライアントサイドレンダリング（CSR）という。 SSGはクライアント（ブラウザ）側にとってはSSRとあまり変わらないが、サーバ側での処理に違いがある。SSRはブラウザからのリクエストのたびにHTMLを生成するのに対して、SSGはあらかじめHTMLを生成しておく。同じページでもタイミングや人によって表示内容が細かく変わる場合にはSSRでなければならないが、同じページでは表示する内容が同じ、つまり静的サイトの場合にはSSGでいい。ページの表示速度はサーバ側でのHTML生成の時間がない分、SSGのほうが高速になる。厳密にはSPAでもSSRタイプのものとCSRタイプのものがある、SPAの対になるのがMPAで、SSRの仲間ががSSGで対になるのがCSR、でもSSGはSPAではないのだが、あまり気にする必要はない。計測上はただ一点、ページの読み込み処理をページ遷移のたびに行うか、行わないかを意識すればいい。ページ遷移のたびにページ読み込み処理が行われるのであれば従来通りのトリガー設定でいいが、そうでない場合はトリガーなどの計測設定を変更する必要がある。

一つのサイトにはMPAや複数の環境のSPAが混在する

一つのサイトがすべて一つのSPAやSSRだけでできているケースは多いわけではない。**一部の階層のみSSRになっていたり、またSSRであっても異なるシステム（一方がNext.jsで、別の階層がReactなど）**であるケースも多い。タグマネジメントにおいてはそういった複数のレンダリングシステムが混在した環境に対して、サイト全体で計測タグが正しく動作するように設定する必要がある。これは大変難易度が高い。

MPAページの基本

MPAページでは、GTMタグ読み込み時に発火するページビュートリガーが基本になる。データレイヤーからデータを取得したり、DOMの内容を取得したりする場合にDOM Readyを使うことがある。これについてはこれまでと変わりない。

SPA / SSR / SSGページの基本

サイト外や当該SPAページ以外から遷移してくるパターンと、SPAの同一ページ内で遷移をするパターンを両方サポートする必要がある。

初回読み込み時

SPAページそのものを読み込むタイミングである。純粋な閲覧開始や、MPAページから遷移してくる、他のシステムのSSRページから遷移してくるケースである。 SPA / SSR / SSGページの初回読み込み時にはGTMのタグも読み込まれるので、ページビュートリガーが適用される。MPAと同様にDOM Readyを使ってもいい。

次回以降のページ遷移

一度SPAページを読み込んだ後の、ページ内での遷移である。ここではページの読み込み処理は行われない。 簡単なのは「履歴の変更」トリガーを使うことである。「履歴の変更」（gtm.historyChange）とは、ブラウザでページの読み込みを伴わないURL変更が行われた時に発火するトリガーである。、厳密にはwindow.history.pushState()またはwindow.history.replaceState()メソッドが呼び出された時、イベントpopstateが検知された時、URLのハッシュ（フラグメント）部分が書き換えられた時のいずれかに該当した場合になる。 GA4の拡張計測機能では履歴の変更には対応しているが、あくまでGA4のみが対象であって、他のツールのタグや広告タグは対象外なので別途対応が必要となる。そうなると、GA4の拡張計測機能に依存せずにすべてタグマネージャ側で発火制御するほうが管理がしやすくなる。 SPAやSSRでも、最初のページ表示時（読み込み時）は該当しない。そこではページビュートリガーやDOM Readyが該当する。SPAやSSR内での次回以降のページ遷移時に「履歴の変更」トリガーが該当する。つまり従来の「ページビュー」トリガーや「DOM Ready」トリガーなどと、「履歴の変更」トリガーを組み合わせることですべてのページ遷移に対応できるようになる。しかし「履歴の変更」トリガーの限界がある。履歴の変更トリガーではデータレイヤーやDOMの内容など、ページとのデータ連携は基本的に不可能になる。というのも多くのシステムでは履歴の変更処理後にページ内容の書き換えが非同期で進められるためである。つまり履歴の変更トリガー発生時には古いコンテンツされており、その後でページの表示処理が行われて新しいコンテンツになる。GTMの「履歴の変更」トリガーを使ってページビュー計測をすると、ページタイトルがそのURLと合わないものになるケースがあるのはこれが理由である。

「履歴の変更」トリガーの罠

「履歴の変更」トリガーではSPAやSSR内でのブラウザバックなどの際に想定通りにハンドリングされず、重複してトリガーが適用される（タグが重複発火する）ケースがある。その場合履歴の変更前後のURLが異なる時にのみ履歴の変更トリガーを発火させることで重複発火を回避できる。「履歴の変更」発生時に変更前のURLはデータレイヤー変数gtm.oldUrlに、新URLはデータレイヤー変数gtm.newUrlに格納される。これらをそれぞれGTM変数として設定する。

ここで設定した2個のGTM変数の値が同じかどうかを判定するJavaScript変数を作成する。

この値がtrueであれば履歴の変更前後のURLが異なる（発火対象）、falseであれば前後のURLが同じということになる（非発火対象）。したがって「履歴の変更トリガー」で、この変数がtrueになるケースに絞り込んでトリガーを作成する。以下は第1階層がaaaとbbb以外の全階層でこの絞り込んだ履歴の変更トリガーを実装する例である。

カスタムイベント

履歴の変更トリガーを使う場合はデータ連携はあきらめた方がいい。データ連携が必要な場合はページの切り替え時にアプリケーション（フレームワーク）側の設定でカスタムイベントを発火させ、それをトリガーとして個別のタグを発火させるようにする。タグマネージャではなくウェブサイト側（フレームワークなど）でページ切り替え時の処理に以下の記述を入れる。

dataLayer.push({
 'event': 'custom_page_load', // （カスタムイベント名は何でもいい）
 'category': 'cosmetics' // （連携するデータ）
 :
});

ここではcustom_page_loadという名前のカスタムイベントとしてページ切り替わりを意味するイベントを作った。GTM側でもこのカスタムイベントに対応したトリガーを作成する。

SPA / SSR / SSG内でのページ表示（遷移）時に発生させるイベント名はアプリケーションごとに別々にするのではなく、サイト全体で統一しておくといい。そうすると一つのトリガー設定ですべてのSPAやSSRなどのページに対して共通してページビュー計測できるようになる。しかしSPAのシステム（フレームワーク）側からカスタムイベントを発生させる場合、技術的な実装上の観点から、前節の「次回以降のページ遷移」だけでなく初回読み込み時にも発生させざるを得ないのが普通である。そこでカスタムイベントを使う場合は、SPAやSSRの階層ではページビューやDOM Readyのトリガー自体を発火させないようにしておく必要がある。つまりページビュートリガー側で除外条件としてSPAのパスを含めておく。以下の例では第1階層がaaaとbbbを除外対象としている。

JavaScriptでフラグをビットで管理する～複数の状態フラグを少ない容量で管理

Tue, 21 Feb 2017 00:00:00 +0900

状態を管理する、その状態に応じて条件分岐するやり方。

フラグをビットで管理するメリットとケース

例: ランディングページで「30秒以上滞在」「スクロール深度50%到達」「フォーム入力開始」を検知し、3つとも満たしたユーザーにのみリターゲティング用のカスタムオーディエンスを送る。あるいは、ECサイトで「トップ閲覧」「カテゴリ閲覧」「詳細閲覧」を1つの数値で持ち、商品詳細まで到達したユーザーにのみ関連商品リコメンドのタグを発火させる。個別の条件を満たしたときにフラグを立て、その組み合わせを参照して処理を分岐させる。単純に1フラグを1変数にすると変数の数が増える。そこで1個の変数で複数の状態をまとめて管理する方法がビットによる管理である。なおこの考え方はJavaScriptに限らずあらゆるプログラム言語で実装が可能。管理するフラグが多く、メモリ消費や発生するパケットを小さくする必要があるときに重要となる。

ビット

ビットは0または1の2値を表す情報の単位それを8個つなげたもの、

11001101

は8個の0/1を表す情報を保持している。 11001101の各桁は0か1しかないので2進数として見ることができる。これを10進数に置き換えると205ということになる。 8ビットの変数1個（0~~255の整数）であれば8個のビット（0/1）が収まる。つまり0~~255の整数で8種類の0/1の状態を表せる。この最小の情報の単位であるビットに対する処理がビット処理である。

フラグの定義

var STATE = {
 DISABLED: 1 << 0,
 HOVER: 1 << 1,
 ACTIVE: 1 << 2
};

1<<桁で、桁は0からスタート

フラグを設定（代入）する

まず状態を表す変数を宣言

var state;

フラグ`DISABLED`を立てる

state |= STATE.DISABLED;

フラグDISABLEDとHOVERを同時に立てる（一度に代入する）

state |= STATE.DISABLED | STATE.HOVER;

フラグのセットを作る

state = STATE.DISABLED | STATE.HOVER | STATE.ACTIVE;

フラグ`DISABLED`を下げる

state &= ~STATE.DISABLED;

フラグを下げる場合は「&」にするのと否定の「~」を付けるフラグDISABLEDとHOVERを同時に下げる（一度に代入する）

state &= ~(STATE.DISABLED | STATE.HOVER);

特定のフラグを反転させる

state ^= STATE.DISABLED;

特定のフラグを取り出す

stateの中でDISABLEDに対応するビットの値を抜き出す（これが0でなければDISABLEDのフラグが立っていることになる）

state & STATE.DISABLED

stateの中でDISABLED、HOVERに対応する部分を抜き出す

state & (STATE.DISABLED | STATE.HOVER)

これが0でなければDISABLEDまたはHOVERのフラグが立っていることになる
これが(STATE.DISABLED | STATE.HOVER)と等しい場合、DISABLEDとHOVERの両フラグが立っていることになる

フラグの取り出しは条件判定で使うことになる。

逆引き

やりたいこと	演算方法	演算子	変更したいビット	そのままにしたいビット
ビットをすべて反転させたい	NOT	`~`	すべて変更される	指定不可
一部のビットを反転させたい	XOR	`^`	反転させたいビット: 1	0
一部のビットをONにしたい	OR	`	`	ONにしたいビット: 1
一部のビットをOFFにしたい	AND	`&`	OFFにしたいビット: 0	1

条件判定

if (state & STATE.DISABLED) { 処理 }
if (state & (STATE.DISABLED | STATE.HOVER)) { 処理 }
!!(state & STATE.DISABLED) && 処理

ビットを使った条件

UIの状態管理の例。ボタンが無効でなく、かつホバー中の場合にのみクリック処理を実行する。