大規模なパーソナライゼーションは、主に運用の問題です。ルールが5つなら1人の頭に収まりますが、4人が1年かけて書いた50のルールは収まりません。何らかの仕組みがないと、誰も管理していないルール、料金ページの同じ見出しを奪い合う2つのルール、そして誰もそのバリエーションの存在を覚えていなかったために、あるセグメントに古い料金が表示され続ける事態が生まれます。
この記事では、増え続けるルールを管理可能に保つための仕組みを解説します。命名、台帳、競合時の明確な優先順位、専用ページではなく枠ベースのテンプレート、パフォーマンスのチェック、そして誰が何を担当するかです。どれも複雑ではありません。ただ、ルールが増えた後ではなく、増える前に用意しておく必要があります。
現在の環境では足りなくなったサイン
- 特定の訪問者に何が表示されるか誰も答えられない。「エンタープライズの医療系訪問者には、ホームページで何が表示されるのか？」と聞かれて答えるには、複数のルールを、場合によっては複数のツールで開かなければなりません。
- 競合が偶然で決まる。重なり合うセグメントに対して2つのルールが同じ要素を対象にしていて、どちらが優先されるかが誰かの判断ではなく、読み込み順や作成日で決まってしまいます。
- コンテンツの変更が捜索作業になる。価格や製品名を変更するたびに、すべてのバリエーションを調べて古い表現が残っている場所を探さなければなりません。
- ルールを追加するにつれてページが遅くなったり、ちらつき始めたりしたが、それがいつからか誰も気づかなかった。
- 既存ルールの保守に時間をすべて取られ、テストが止まった。
特に一度も測定されていないルールが多い場合は、ルールの数を減らすのが正解のこともあります。ただ多くの場合、ルール自体に問題はなく、欠けているのはそれらを可視化し管理する方法です。
名前を見ればルールがわかるように命名する
1つのパターンを選び、どこでも使いましょう。うまくいくパターンの例：ティア、セグメント、ページ、要素、バージョンをこの順にハイフンでつなぎます。
tier-segment-page-element-version
T1-acme-corp-homepage-hero-v2T2-enterprise-healthcare-pricing-proof-v1T3-returning-visitor-blog-cta-v3
Tierの接頭辞は、後述する競合時の優先順位と連動します。残りの部分は、ルールの一覧を見た人が開かなくても各ルールの役割がわかるようにするためのものです。ページで絞り込めばそのページに影響しうるすべてのルールが、セグメントで絞り込めばそのセグメントに表示されるすべてがわかります。
台帳を管理する
スプレッドシートで十分です。有効なルールごとに1行とし、次の列を設けます。
| 列 | 存在理由 |
|---|---|
| ルール名 | ツール内の名称と完全に一致させる |
| 目的 | 1文で：「医療業界の訪問者に医療業界の導入事例を見せ、デモリクエストを増やす」 |
| 担当者 | 問い合わせ先の担当者と、更新する担当者 |
| セグメントの定義 | 重複が見えるようにした実際の条件 |
| ページと要素 | コンテンツを変更する場所 |
| 含まれる事実 | 価格、プラン名、顧客名、製品名。これらのいずれかが変わったときに検索する列です |
| ホールドアウト／テストのステータス | 計測済み、計測中、または未計測 |
| 最終レビュー日 | 日付 |
これに2つの習慣を加えましょう。新しいルールは、台帳の管理者への簡単な申請(Slackのメッセージで構いません)を経由させ、公開前に重複を見つけます。そして四半期ごとにリストを見直し、本格的なテストで効果が見られなかったルールを廃止し、古くなったコンテンツを更新し、重なり合うセグメントで同じ役割を果たしているルールを統合します。自分で作りたくない場合は、パーソナライゼーションのプレイブックテンプレートを台帳として使えます。重複時の優先順位の列もあります。
競合が起きる前に決めておく
ターゲットアカウントリストに載っている大手ヘルスケア企業からの再訪問者は、アカウントルール、業種×規模ルール、業種ルール、再訪問者ルールに同時に該当することがあります。これらがすべてヒーローを対象にしていれば、どれかを決める仕組みが必要です。明示的な優先順位を決めましょう。
- Tier 1：指名アカウントのルール。特定のアカウントやアカウントリスト向けに作ったものが優先されます。最も具体的で、通常は進行中の営業の会話と結びついています。
- ティア2：複合セグメント。2つ以上の属性を組み合わせたルール（エンタープライズ＋医療）は、単一属性のルールに優先します。誰かがその組み合わせに専用のメッセージが必要だと判断したからです。
- ティア3：単一属性のルール。「すべてのエンタープライズの訪問者」「米国からのすべての訪問者」。フォールバック用。
- デフォルトのページ。それ以外の全員と、クローラーが見るページ。
同じ階層の中では、「最終更新日時」や読み込み順で決まるようにしてはいけません。階層内の各ルールにはルール台帳で明示的な順位番号を付けるか、できれば最初から、重複するセグメントに対して同じ要素で同じ階層のルールを作らないようにしましょう。暗黙のタイブレークこそが、誰も意図しなかったバリアントを訪問者が目にする原因です。
要素ごとに分けることでも競合は避けられます。ヒーローはアカウントのルール、証拠ブロックは業界のルールが担当するようにすれば、両方に当てはまる訪問者には両方が表示され、衝突しません。これが最も簡単な解決策なので、まず試す価値があります。
個別ページではなく、テンプレートとスロットで
大きなルールセットを無理なく運用するためのパターンは、ページのレイアウトを固定し、パーソナライズ可能な枠をいくつか定義することです。ルールは枠を埋めるだけで、ページを作り直すわけではありません。
B2Bホームページのスロット例：
- ヒーロー見出し（モバイルに収まるよう文字数制限付き）
- ヒーローのサブ見出し
- 実績ブロック：ロゴの列と引用1件
- 主要CTAのラベルとリンク先
- 注目の導入事例
そうすれば、バリアントの作成は5つの項目のコピーを書き、導入事例を1つ選ぶだけになり、マーケターがデザインやエンジニアリングの工数なしで対応できます。レジストリも実用的になります。ルールで変更できる項目が正確に分かるからです。
トレードオフは確かにあります。医療業界向けとフィンテック向けのバリアントは、レイアウトが共通なので似た見た目になります。ほとんどのB2Bサイトではそれで問題ありません。セグメントごとに変わるのはメッセージだからです。完全にカスタムな対応は、取引規模が追加作業に見合う少数の指名アカウントに限り、そうしたページには個別の保守が必要になることを受け入れましょう。
ルールの追加に伴うパフォーマンスを監視する
ルールセットが速度にどれだけ影響するかは、判定がどこで行われるかによります。サーバーサイドやエッジでの判定は、ページ送信前に処理を加えます。クライアントサイドのスクリプトは、ページ描画後に処理を加え、ちらつきの原因になることがあります。いずれにしても、推測ではなく測定してください。
- パーソナライズされたページのLargest Contentful Paintとちらつき。PageSpeed Insightsやラボテストで、低速に制限したモバイルのプロファイルを使い、パーソナライズされたバリエーションとデフォルトのページを比較します。パーソナライズされたヒーローがLCP要素で、デフォルトより表示が遅れるなら、判定のタイミングが遅すぎます。
- パーソナライゼーションツールの判定時間。ほとんどのツールは判定にかかる時間を記録しています。その推移を追い、急に長くなったときは何が変わったかを確認しましょう。
- フォールバック率。ルールが機能せず、代わりにデフォルトが表示される頻度です。表示が崩れたページよりは静かにフォールバックするほうがましですが、この率が高いということは、レジストリに書かれている体験が訪問者に届いていないということです。
新しいルールをまとめて公開する前に毎回ベースラインを記録し、性能の低下をその原因となった変更と結び付けられるようにしましょう。RUMツールやSearch ConsoleでのCore Web Vitalsのモニタリングは継続的な問題を検知しますが、それは十分な実トラフィックが影響を受けた後になります。
担当の分担
| 役割 | 役割と責任 | 主な担当者 |
|---|---|---|
| パーソナライゼーション担当者 | 台帳、命名、競合時の優先順位、四半期レビュー、新しいルールの最終決定 | マーケティングオペレーションまたはグロースの責任者 |
| コンテンツ制作者 | セグメントごとのスロットのコピー作成、情報を最新に保つこと | プロダクトマーケティング、コンテンツチーム |
| 技術的な導入担当者 | ルールの設定、競合のデバッグ、パフォーマンスチェック | ツールに応じて、Web開発者または技術に強いマーケター |
| アナリスト | ホールドアウト、ルール単位の結果、廃止すべきルールのフラグ付け | マーケティングアナリスト（仕事内容はマーケティングアナリティクスのキャリアをご覧ください） |
小規模なチームでは1〜2人が4つの役割すべてを担いますが、台帳さえあれば問題ありません。台帳があれば別の人が仕事を引き継げるからです。曖昧に共有できないのは担当者の役割です。全員がルールセットの担当者だと、誰も何も廃止しません。大規模な組織での RACI、展開フェーズ、ガバナンスについては、エンタープライズのパーソナライゼーション導入プレイブックをご覧ください。
プログラムだけでなく、ルールを測定する
プログラム全体のホールドアウトでわかるのは、パーソナライゼーション全体を続ける価値があるかどうかです。50あるルールのうち、どれが成果を生んでいるかまではわかりません。トラフィックが許す範囲で、ティア2とティア3の各ルールに個別のホールドアウトまたはA/Bテストを設定し、読み取れるサンプル数に届かないルールは、効果があると決めつけずにレジストリ上で「未計測」と記録してください。ホールドアウトのサイズ設計と指標の階層については、パーソナライゼーションのROI測定に関する記事で解説しています。
ルール数が増える前のチェックリスト
- 全員が使う命名規則
- すべてのルールについて、担当者、目的、セグメント、事実、テスト状況をまとめた管理台帳
- 文書化した競合時の優先順位と、Tierごとの要素の担当
- 少なくともホームページと料金ページのスロットテンプレート
- パフォーマンスのベースラインと、ルールを追加するたびのチェック
- 担当者1名の明記と、次回の四半期レビューの日付
現実的な最初の一歩：ツール内のすべての有効なルールを、上記の台帳の形式でエクスポートします。記入できないルール（担当者不明、目的不明、効果があるか不明）は、最初のレビューのリストに入れます。Markettailorで設定する場合、セグメンテーションがセグメントの定義を一か所で管理するため、ルール間の重なりを見つけやすくなります。