計測 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などの大文字は否定（数字以外の文字）を表す。

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