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

CoreDashでのカスタムセグメンテーション

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

この「自動」から「意図的」への移行が非常に重要です。ユーザーが表示しているチェックアウトのバリアントはどれか、現在のURLは商品詳細ページかランディングページか、ユーザーは認証されているかなど、ブラウザが推測できない情報をアプリケーションは把握しています。そのコンテキストをCoreDashに渡すことで、ビジネスが実際にどのように機能しているかをパフォーマンスデータに反映させることができます。

ページラベル (lb)

ページラベルディメンションを使用すると、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のようになります。これらは同じテンプレート、同じビジネス機能、同じ最適化ターゲットです。これらを1つのURLごとに分析しても役に立ちません。これらをproduct-detailの下にグループ化することで、商品カタログ全体に対する単一のパフォーマンスプロファイルを取得できます。

ページラベルは、異なるパフォーマンス予算を持つページを分離することもできます。チェックアウトページは直接的な収益をもたらすため、許容されるLCPのしきい値が厳しくなります。ブログ記事の許容範囲は異なります。有料トラフィックを流しているランディングページでは、1ミリ秒ごとに広告費がかかっているため、遅いLCPに対する許容度はゼロです。

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

A/Bテスト (ab)

A/Bテストディメンションは、ユーザーが現在体験しているバリアントに割り当てたラベルを保持します。次のように定義します：

window.__CWAB = 'my page version';

値は任意です。variant-aやvariant-bはわかりやすい選択肢ですが、実験プラットフォームのバリアント識別子にマッピングされる任意の文字列を使用できます。

これが重要な理由

A/Bテストは、意図しないパフォーマンス低下の最も一般的な原因の1つです。バリアントBでは新しいヒーロー画像のカルーセルが導入されます。バリアントBではサードパーティのレコメンドウィジェットが読み込まれます。バリアントBにはReactのハイドレーションが追加で1回含まれます。これらはすべてパフォーマンスコストを伴いますが、実験ツールではほとんどの場合測定されません。

ほとんどの実験プラットフォームは、コンバージョン率と収益を追跡します。p75のLCPやINPは追跡しません。バリアントBのコンバージョンが2%向上したとしても、モバイルでの読み込みが400ミリ秒遅くなる場合は、トラフィックの100%に展開する前にそれを知る必要があります。ユーザーが焦燥感を感じて離脱するため、次の四半期にはそのパフォーマンスコストがコンバージョン向上分を帳消しにしてしまう可能性があります。

__CWABを設定したら、CoreDashを開き、ab = variant-bでフィルタリングして、Core Web Vitalsをコントロール（対照群）と並べて比較します。コントロールよりもp75 LCPが600ミリ秒悪化しているにもかかわらず、重いフォントを読み込んだために勝者となったバリアントのA/Bテストを見たことがあります。ビジネスチームはコンバージョンの向上は見ていましたが、パフォーマンスの低下には気づいていませんでした。このディメンションはそれを防ぐためのものです。

ログインステータス (li)

ログインステータスディメンションは、現在のユーザーが認証されているかどうかを記録します。次のように定義します：

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

これが重要な理由

ログインしているユーザーには、匿名訪問者とは根本的に異なるページが提供されます。彼らのリクエストは多くのCDNキャッシュ層をバイパスします。サーバーはパーソナライズされたコンテンツ（ユーザーのカート、注文履歴、保存したアイテムなど）を取得するためにデータベースクエリを実行します。そのサーバー側の処理は、TTFBに直接加算されます。

フロントエンドでは、認証されたページはアカウントウィジェット、通知システム、ショッピングカートのリアクティビティなど、より多くのJavaScriptを読み込むことがよくあります。また、匿名ページを高速化しているプリレンダリングやエッジキャッシュをスキップすることもあります。その結果、ログインしているユーザーのパフォーマンスは匿名ユーザーよりも遅くなることがよくありますが、ログインしているユーザーは通常、最も価値の高い顧客です。彼らはすでにコンバージョンに至っています。最も維持する必要があるユーザーなのです。

liディメンションがない場合、認証時の遅いパフォーマンスは集計値の中に隠れてしまいます。匿名のLCPが1.8秒であるのに対し、ログイン時のLCPは3.4秒になるかもしれません。集計値は2.3秒となり、許容範囲内にあるように見えます。しかし、liで分割すると、状況は完全に変わります。

実装

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

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

ラベルの値は文字列です（1または0を取る__CWVLIを除く）。コードベース全体で一貫性を保ってください。あるテンプレートでproduct-detailを使用し、別のテンプレートでproductDetailを使用した場合、CoreDashはそれらを2つの別々のセグメントとして扱い、データが断片化します。規則を決めて、それを徹底してください。

3つすべての組み合わせ

これらのディメンションを重ね合わせたときに、真の価値が現れます。ログインしているユーザー向けに、チェックアウトページでA/Bテストを実行しているとします。バリアントBによって、認証済みのチェックアウト体験が速くなるのか遅くなるのかを知りたいはずです。

CoreDashで、ab = variant-b、lb = checkout、およびli = 1でフィルタリングします。これにより、認証済みユーザーに特化したチェックアウトバリアントのパフォーマンスが得られます。あなた自身でカスタムエンジニアリング作業を行わずに、この組み合わせを表面化できる監視ツールは他にありません。

標準的な技術的ディメンションは、ブラウザが何を体験したかを教えてくれます。カスタムディメンションは、ビジネスが何を体験したかを教えてくれます。400ミリ秒のLCP低下は、有料トラフィックを流しているlanding-pageとblog記事とでは、意味するものがまったく異なります。このような区別は優先順位付けにおいて重要であり、優先順位付けこそが、パフォーマンス改善の取り組みが成功するか行き詰まるかの分かれ目なのです。