Core/Dash Dimension: カスタムラベルとセグメンテーション

CoreDashにおけるカスタムセグメンテーション

国やデバイスタイプなどの技術的ディメンションは、ブラウザのシグナルから構築されます。CoreDashはこれらを自動的に収集します。ここで取り上げる3つのディメンションはそれらとは異なり、Page Label、A/B Test、Logged In Statusはユーザー定義のものです。CoreDashが実行される前に、独自のコード内でwindow変数に値を代入して設定します。

自動収集から意図的な設定への移行こそが、最も重要なポイントです。アプリケーションは、ブラウザが推測できない情報を把握しています。ユーザーがどのチェックアウトのバリアントを見ているのか、現在のURLが商品詳細ページなのかランディングページなのか、ユーザーが認証されているか、などです。このコンテキストをCoreDashに渡すことで、パフォーマンスデータに実際のビジネスの仕組みを反映できます。

Page Label (lb)

Page Labelディメンションを使用すると、URL構造ではなくビジネス機能ごとにページをグループ化できます。定義方法は以下の通りです。

window.__CWVL = 'mypagelabel';

代表的な値には、checkout、product-detail、landing-page、category、search-results、accountなどがあります。値は自身で制御できる任意の文字列です。

なぜこれが重要なのか

URLベースの分析には、根本的なスケーラビリティの問題があります。大規模なEコマースサイトでは、商品詳細ページが5万ページに及ぶこともあります。それらのURLは/products/blue-widget-32ozや/products/red-gadget-xlのようになりますが、これらは同じテンプレートであり、同じビジネス機能、同じ最適化対象です。これらをURLごとに個別に分析するのは有益ではありません。product-detailとしてグループ化することで、商品カタログ全体の単一のパフォーマンスプロファイルを得ることができます。

Page Labelは、求められるパフォーマンス予算が異なるページを分類する役割も果たします。チェックアウトページは直接の収益に直結するため、許容されるLCPしきい値は厳格です。一方で、ブログ記事の許容度は異なります。有料トラフィックが流入するランディングページでは、1ミリ秒の遅れが広告費の無駄になるため、LCPの低下は一切許容されません。

ビジネス機能ごとにページをラベル付けすれば、CoreDashでラベルごとに異なるアラートしきい値を設定し、適切なアラートを適切なチームにルーティングできます。

A/B Test (ab)

A/B Testディメンションには、ユーザーが現在体験しているバリアントに対して割り当てるラベルを格納します。定義方法は以下の通りです。

window.__CWAB = 'my page version';

値は任意です。variant-aやvariant-bが一般的な選択肢ですが、実験プラットフォームのバリアント識別子に対応する任意の文字列を使用できます。

なぜこれが重要なのか

A/Bテストは、意図しないパフォーマンス低下を引き起こす最も一般的な原因の一つです。バリアントBで新しいヒーロー画像のカルーセルを表示する、サードパーティのレコメンデーションウィジェットを読み込む、Reactのハイドレーション処理を追加する、といった変更にはすべてパフォーマンスコストが伴いますが、実験ツールでそれが測定されることはまずありません。

ほとんどの実験プラットフォームは、コンバージョン率と収益を追跡しますが、p75のLCPやINPは測定しません。もしバリアントBのコンバージョン率が2%向上したとしても、モバイルでの読み込みが400ms遅くなっているなら、トラフィックを100%に適用する前にそれを把握する必要があります。ユーザーがしびれを切らし、次の四半期にはパフォーマンス低下による損失がコンバージョン向上の成果を打ち消してしまう可能性があるからです。

__CWABを設定した状態でCoreDashを開き、ab = variant-bでフィルタリングすれば、コントロールとCore Web Vitalsを並べて比較できます。私が過去に見たA/Bテストでは、勝利したバリアントが重いWebフォントをロードしていたため、コントロールよりもp75 LCPが600ms悪化していました。ビジネスチームはコンバージョン率の上昇だけを見て、パフォーマンスの低下に気づいていませんでした。このディメンションは、そうした事態を防ぐためにあります。

Logged In Status (li)

Logged In Statusディメンションは、現在のユーザーが認証されているかどうかを記録します。定義方法は以下の通りです。

window.__CWVLI = 1; // ログイン済み
window.__CWVLI = 0; // ログアウト済み

なぜこれが重要なのか

ログイン済みのユーザーは、匿名の訪問者とは根本的に異なるページを受け取ります。そのリクエストは多くのCDNキャッシュレイヤーをバイパスします。サーバーは、ユーザーのカート、注文履歴、お気に入りリストなどのパーソナライズされたコンテンツのためにデータベースクエリを実行します。このサーバー側での処理は、TTFBに直接上乗せされます。

フロントエンドでは、認証ページは多くの場合、アカウントウィジェット、通知システム、ショッピングカートのインタラクティブ機能など、より多くのJavaScriptを読み込みます。また、匿名ユーザー向けのページを高速化しているプリレンダリングやエッジキャッシュがスキップされることもあります。結果として、ログインユーザーは匿名ユーザーよりもパフォーマンスが低下しがちです。しかし、ログインユーザーこそが最も価値の高い顧客です。彼らはすでにコンバージョンに達しており、最も離脱を防ぐべき相手なのです。

liディメンションがないと、認証ページの遅いパフォーマンスが集計値の中に隠れてしまいます。例えば、匿名ユーザーのLCPが1.8秒であるのに対し、ログインユーザーのLCPが3.4秒だったとします。全体の集計値は2.3秒となり、一見問題ないように見えてしまいます。しかし、liで分割すれば、状況は完全に変わります。

Implementation

3つのディメンションはすべて同じパターンで動作します。CoreDashのスニペットが実行される前にwindow変数を設定するだけです。これらをドキュメントのhead内のscriptタグ、またはアプリケーションの初期化コードに記述します。

// アプリケーションの状態に基づいて設定
window.__CWVL  = 'checkout';      // ページラベル
window.__CWAB  = 'variant-b';     // A/Bテストのバリアント
window.__CWVLI = 1;               // ログイン済み

ラベルの値は文字列です（1または0を指定する__CWVLIを除く）。これらはコードベース全体で統一してください。あるテンプレートでproduct-detailを使用し、別のテンプレートでproductDetailを使用すると、CoreDashはそれらを異なるセグメントとして処理し、データが断片化してしまいます。命名規則を定め、それを徹底してください。

3つのディメンションの組み合わせ

本当の価値は、これらのディメンションを組み合わせたときに発揮されます。例えば、ログインユーザーを対象にチェックアウトページでA/Bテストを実行しているとします。このとき知りたいのは、バリアントBによってログイン状態のチェックアウト体験が速くなったのか、それとも遅くなったのかです。

CoreDashで、ab = variant-b、lb = checkout、li = 1の条件を組み合わせてフィルタリングします。これにより、認証済みユーザーに限定したチェックアウトバリアントのパフォーマンスが得られます。独自にカスタム開発を行わずにこの組み合わせを可視化できるツールは、他にありません。

標準的な技術ディメンションはブラウザが体験したことを示しますが、カスタムディメンションはビジネスが体験したことを示します。有料トラフィックが流入するlanding-pageでの400msのLCP悪化は、blog記事での悪化とはまったく異なる意味を持ちます。これらの違いは優先順位付けにおいて重要であり、優先順位付けこそが、パフォーマンス改善の取り組みが成功するか、あるいは停滞するかの分かれ道なのです。