パーソナライズされたリード獲得:より多く、より質の高いリードを集める方法

リード獲得の本質は、フォームの送信数を増やすことではありません。適切な人に適切なタイミングで手を挙げてもらい——すぐに対応することです。それなのに多くのサイトは、すべての訪問者に同じ場所で同じ汎用メッセージの静的なフォームを見せ、コンバージョンが伸びない理由に首をかしげています。 パーソナライゼーションは、この方程式そのものを変えます。誰がオファーを見るのか、何を伝えるのか、いつ表示するのか、そして送信された瞬間に何が起きるのかを決めるのです。パーソナライゼーション——特に Personyze——が、既存のトラフィックからより多くの質の高いリードを生み出す方法を紹介します。 適切な訪問者に適切なメッセージを表示する 汎用的な「ニュースレターに登録」は、特定の誰にも語りかけていないためコンバージョンしにくいのです。パーソナライゼーションは、実際にそこにいる人に合わせてお願いの内容を変えます——業種、企業( アカウントベースのターゲティングと逆引きIPによる)、流入元、行動、新規かリピーターかといった要素です。ターゲットアカウントの訪問者にはその人の業界向けのオファーを、ブログ記事から初めて来た人には読んでいた内容に関連するリードマグネットを表示します。自分に向けたメッセージだからこそ響くのです。 その裏返しも同じくらい重要です:条件に合わない人にはフォームを表示しないこと。明らかにターゲット市場外の訪問者には、オファーそのものを表示しないようにできます——パイプラインをきれいに保ち、チームがノイズではなく本当に重要なリードに集中できます。 実際の操作を見る · 1:17 — リード獲得フォームを作り、リードを送り先につなぐ. ほかのチュートリアルと一緒に見る → 鉄は熱いうちに打て 同じフォームでも、いつ表示するかによってコンバージョンは大きく変わります。初回訪問の最初の1秒でお願いすれば見知らぬ人の邪魔になり、関心が最も高まった瞬間にお願いすれば前向きな人をつかめます。Personyzeは行動とエンゲージメントをきっかけに発動します——料金ページを最後まで読んだとき、3回目の訪問をしたとき、商品ページに長く留まったとき、あるいは 離脱の意図を示したときなどです——そのため、オファーは邪魔ではなく、絶妙なタイミングの招待として届きます。 テストを重ねてコンバージョンの高いフォームへ ここまでの内容は、すべてテストできます。 A/Bテストで、メッセージ、フォームの長さ、CTAの文言、トリガーのタイミング、配置を検証し——データに勝者を選ばせましょう。項目を1つ減らす、見出しを鋭くする、トリガーを賢くするといった小さな変更が積み重なって獲得率を大きく押し上げ、どのバージョンが成果を上げたのかも正確にわかります。 自社のフォームでも、Personyzeのフォームでも すでにあるものを捨てる必要はありません。Personyzeの組み込み フォームを使うか——既成の フォームテンプレートから始めるか——、あるいはHubSpotなど、すでに使っているフォームにターゲティング、タイミング、テストを重ねることもできます。いずれの場合もパーソナライゼーションは上に重なるだけで、リードはこれまでどおりの場所に届きます。実際の動作は リード獲得フォームの事例でご覧ください. 訪問者自身のデータをフォームに表示する パーソナライゼーションは、誰にいつフォームを見せるかを決めるだけではありません——フォーム自体が訪問者の言葉で語りかけることもできます。Personyzeの訪問者変数を使えば、統合された訪問者プロファイルからリアルタイムに値が入るトークンをフォームに挿入できます。企業名(ABMと逆引きIPによる)、都市、最新の関心(PersonyzeのAIが検知した、訪問者が関心を示しているトピック)、最近読んだ記事や閲覧した商品などです。 これにより、汎用的なフォームがオーダーメイドのように感じられるものに変わります。 著者をフォロー。「{author}さんの記事をお楽しみいただけましたか?新しいコンテンツが公開されたらメールでお知らせします」——訪問者が何度も読みに来ている書き手の名前をそのまま表示します。 前回の続きから。訪問者が最近接した記事や商品をフォームの中に直接表示し——「こうした記事をもっと読みたいですか?」——受け身の読者を購読者に変えます。 カートを送信。「カートの中身をメールで送る」フォームでメールアドレスを取得し、訪問者に現在の商品を送れば、後から売上を取り戻せます。 企業、都市、関心。ターゲットアカウントを企業名で迎え、訪問者の都市に触れて地域限定のオファーを出したり、最新の関心に合わせて訴求を変えたりできます。 これらは、Personyzeのキャンペーンのどこででも使える訪問者変数と同じものです——それをフォームの中でも使えるので、お願いの内容も周囲のすべてと同じくらいパーソナライズできます。 送信の瞬間:データ連携、通知、エンリッチメント パーソナライゼーションが本当に効果を発揮するのは、送信時に何が起きるかです。1回の送信が、スタック全体に一瞬で広がります。 データを好きな場所に送る。JavaScriptで外部サーバーやWebhookに渡したり、フォームの値をパラメーターとしてURLにリダイレクトしたりできます——リードはそのまま自社システムに流れ込みます。 リアルタイム通知を送る。フォームが送信された瞬間に、入力値に合わせたメールを送れます——たとえばエンタープライズ規模の企業が手を挙げたら、すぐに営業に知らせることができます。 訪問者プロファイルを充実させる。回答を訪問者の統合プロファイルに戻し、次回以降の訪問を、今わかったことにもとづいてパーソナライズします。 保存とエクスポート。リードをPersonyzeに保存し、必要なときにリストをダウンロードできます。 すでにリードになった人を覚えておく 既知のリードに同じフォームをもう一度入力してもらうことほど、コンバージョン率を下げるものはありません。Personyzeは送信済みの人を覚えているため、すでに情報を提供してくれた人にはフォームを表示しないようにし——代わりに次のステップを提示できます。デモのご案内、会員限定コンテンツ、営業への相談のおすすめなどです。同じことの繰り返しではなく、段階的に進めましょう。 優良リードをスコアリングし、優先順位をつける すべてのリードが同じ価値を持つわけではありません。Personyzeはすでにエンゲージメント——閲覧ページ、閲覧コンテンツ、クリックしたキャンペーン、重要なページでの滞在時間——を追跡しているため、こうしたシグナルにもとづいてリードをスコアリングできます。営業は、リストに追加されたばかりの名前ではなく、本当に準備ができている見込み客に時間を使えます。 何が効果的だったのかを正確に把握する Personyzeがフロー全体を担うため、キャンペーンの成果を完全に把握できます。誰が各オファーを見て、誰がクリックし、誰が送信したのか、そして各バリエーションの成果はどうだったのか。獲得したリードを、それを生んだメッセージ、タイミング、オーディエンスまでさかのぼって確認し——効果のある施策に注力できます。 得られるのは、訪問者一人ひとりが何を見て、何をクリックし、何を送信したのかがわかる、ユーザー別のキャンペーンレポートです: 関連性を軸にしたリード獲得 まとめると、パーソナライゼーションはリード獲得を、ポップアップの数ではなく関連性とタイミングの問題に変えます。ターゲットを絞ったメッセージとフォーム、最適なタイミング、テスト、スマートなデータ連携、エンリッチメント、記憶、スコアリング、充実したレポート——すべてを1つの統合プロファイルから実現します。デモを予約して自社サイトで実際にお試しいただくか、 プランと料金をご覧ください. パーソナライズされたリード獲得:よくある質問 パーソナライズされたリード獲得とは何ですか? すべての訪問者に同じ静的なフォームを見せるのではなく、誰がオファーを見るのか、何を伝えるのか、いつ表示するのかを調整してリードを獲得することです。パーソナライゼーションは、業種、企業、流入元、行動などのシグナルを使ってお願いの内容とタイミングを最適化し、リードの数と質の両方を高めます。 パーソナライゼーションはリードのコンバージョンをどう高めますか? 訪問者に合ったメッセージを関心が最も高まった瞬間に表示し、すでにコンバージョンした人や条件に合わない人にはフォームを表示しないことで高めます。関連性が高くタイミングの良いお願いは、全員に見せる汎用的なフォームよりはるかにコンバージョンします。 HubSpotなど、既存のフォームをPersonyzeで使えますか? […]
パーソナライゼーションやA/Bテストでサイトは遅くなる? ページ速度への実際の影響

パーソナライゼーションやA/Bテストの導入に対して最もよく聞く反対意見は速度です。「スクリプトがまた増えたら読み込みが遅くなり、Core Web Vitalsが台無しになるのでは?」というものです。もっともな懸念です——作りの悪いテスト用スクリプトは実際にページを遅くします。しかし最新の非同期スクリプトなら、実際のコストはわずかです。およそ~250ミリ秒の追加読み込みが、ページをブロックせずに発生するだけです——Google PageSpeed Insightsを導入前後で実行しても、通常スコアに意味のある変化は見られません。 その理由と——実際にページを遅くする要因を解説するので、それを避けましょう。 実際のコスト:非同期読み込みで約250ミリ秒 鍵となる言葉は非同期です。Personyzeのスクリプト(ダッシュボードでのデフォルトかつ推奨の設定)は、レンダリングを止めるのではなく、ページのほかの部分と並行して読み込まれます。ブラウザは通常どおりのタイミングでコンテンツを描画し、パーソナライゼーションのレイヤーはそれと並行して処理され、平均でおよそ4分の1秒を追加します——その大半は、ページがすでに使える状態のため訪問者には感じられません。 対照的に、同期型でレンダリングをブロックするスクリプトでは、ブラウザは何かを表示する前に処理を止めて待たなければなりません。「テストツールでサイトが遅くなる」という評判はここから生まれています——そして、まさにそれを回避するのが非同期のアプローチです。 PageSpeed Insightsのスコアがほとんど動かない理由 PageSpeed Insightsとその基盤であるLighthouseは、いくつかのレンダリング指標を評価します。Largest Contentful Paint(LCP)、Interaction to Next Paint(INP)、Cumulative Layout Shift(CLS)、Total Blocking Time(TBT)です。重要なタイミングでメインスレッドをブロックせず、レイアウトもずらさない非同期スクリプトは、これらの数値をほとんど動かしません——そのため導入前後のテストでも、差は通常ごくわずかです。 影響が出るとすれば、それはすべて実装の問題です。重いスクリプトや同期スクリプト、バリエーションが読み込まれるまでページを隠す不適切なちらつき防止スニペット、コンテンツが突然表示されることによるレイアウトのずれ、メインスレッドの長いタスクなどです。いずれも修正可能なミスであり——パーソナライゼーションに本来伴うコストではありません。 でも、追加のコンテンツを読み込んでいるのでは?それは問題にならないのですか? はい——パーソナライゼーションや レコメンドはコンテンツを追加します。カスタマイズされたブロック、レコメンドウィジェット、画像などです。バイト数もリクエスト数も増えます。それでも悪影響を防げる理由は3つあります。 コンテンツは非同期で、クリティカルレンダリングパスの後に読み込まれるため、最初の描画を遅らせません。 その多くはスクロールしないと見えない位置に配置されるか段階的に表示されるため、ユーザーが実際に体感する指標に影響しません。 画像やウィジェットは遅延読み込みと最適化ができるため、追加コンテンツは最初にまとめてではなく、必要なタイミングで届きます。 追加のコンテンツがあることと、ページが遅いことは同じではありません。適切に配信すれば、高まる関連性の価値はわずかな重さをはるかに上回り——その重さはツール上でもほとんど目立ちません。 実際にページを遅くするもの(と回避方法) 同期的でレンダリングをブロックするスクリプト。非同期を使いましょう——Personyzeのデフォルトです。 ページ全体を長時間隠すちらつき防止。全体を真っ暗にするのではなく、短く範囲を絞りましょう。 レイアウトのずれ。パーソナライズされたブロックの表示領域を確保し、コンテンツが跳ねないようにします(CLS)。 重く最適化されていない画像をパーソナライズされたブロックに使っている。圧縮し、適切なサイズにし、遅延読み込みしましょう。 多すぎるサードパーティスクリプトが積み重なっている。本当に必要なものを見直し、削りましょう。 すべてをクライアント側で処理する。重い処理は、可能な限りサーバー側やエッジに移しましょう。 正しく測定する方法 代表的なページでPageSpeed InsightsまたはLighthouseを導入前後に実行し、見出しの総合スコアだけでなく、LCP、INP、CLS、TBTを確認しましょう。さらに良いのは、フィールドデータ(Chrome UX Reportやアナリティクスなどの実ユーザーデータ)を確認することです。ラボのスコアは計測のたびに変動するからです。最も重要なページ——トラフィックの多いテンプレート——をテストし、パーソナライゼーションにもほかのスクリプトと同じ基準を求めましょう。 Personyzeが速さを保つ仕組み Personyzeは、クリティカルパスに入り込まないように設計されています。スクリプトはデフォルトで非同期(ダッシュボードの推奨設定)で、パーソナライゼーションはリダイレクトではなく同じURL上でその場で適用され、レコメンドウィジェットは遅延読み込みでき、ちらつき防止は範囲を絞っているためページ全体を隠すことはありません。その結果が上記のプロファイルです。追加の読み込みは約250ミリ秒で、PageSpeedへの意味のある影響はありません——速度を犠牲にせず関連性を高められます。 ここでは速度と検索順位は表裏一体です。テストとパーソナライゼーションがクロール、インデックス、ランキングシグナルとしてのCore Web Vitalsにどう影響するかについては、 A/BテストやパーソナライゼーションはSEOに悪影響を与えるのか?をご覧ください 速いページとパーソナライズされた体験は両立できる 読み込みの速いサイトか、パーソナライズされたサイトか、どちらかを選ぶ必要はありません。非同期スクリプトといくつかの賢明な習慣があれば、パーソナライゼーションとA/Bテストは、訪問者が実感できる関連性をもたらし、体感できる遅さはもたらしません。デモを予約して実際の動作をご確認いただくか、 プランと料金をご覧ください. パーソナライゼーション、A/Bテスト、ページ速度:よくある質問 パーソナライゼーションでWebサイトは遅くなりますか? 非同期スクリプトで実装すれば、ごくわずかです。Personyzeの非同期スクリプトは平均で約250ミリ秒を追加しますが、ページをブロックせずに読み込まれ、PageSpeed Insightsのスコアにも通常は意味のある変化は見られません。 […]
A/Bテストやパーソナライゼーションは SEO に悪影響? 検索順位への影響を解説

多くのマーケティングチームが、Googleを混乱させて検索順位を落とすのではないかと恐れ、A/Bテストやサイトのパーソナライズに踏み切れずにいます。安心してください。正しく行えば、どちらもSEOに悪影響を与えません——GoogleはA/Bテストを明確に支援しています——し、より良い体験は間接的にプラスに働くことさえあります。ただし、クローキング、誤ったリダイレクト、表示の遅いちらつくスクリプトなど、雑に行えば、どちらも実際に損害をもたらし得ます。 ここでは、検索順位に何が影響するのか、そして安全にテストとパーソナライズを行う方法を具体的に解説します。 あらゆるSEOの懸念に共通する唯一の原則 このテーマの懸念は、ほぼすべてひとつのルールに集約されます。ユーザーが見ているものと大きく異なるものを検索エンジンに見せないこと、主要なコンテンツを隠さないこと、そしてページの表示速度を損なわないことです。Googleはテストやパーソナライズを歓迎しています——ただGooglebotをほかの訪問者と同じように扱ってほしいだけです。そこさえ押さえれば、あとは細部の話です。 実際の操作を見る · 1:28 — A/Bテストの設定:トラフィックを分けて対照群を残す. ほかのチュートリアルと一緒に見る → A/BテストはSEOに悪影響を与えますか? 結論から言えば、いいえ——Googleのガイドラインに従っていれば問題ありません。GoogleはA/Bテストの公式ベストプラクティスを公開しており、実験を積極的に支援しています。リスクはすべて実装の仕方にあります。主なルールは次のとおりです。 クローキングしない。ボットとユーザーには同じコンテンツのバリエーションを表示します。Googlebotを検出して別のページ(あるいは「オリジナル」のページ)を見せてはいけません——サーバー側であれ何であれ、方法を問わずクローキングとみなされます。 バリエーションURLにrel=“canonical”を設定する——オリジナルを指すように設定します。Googleはnoindexタグよりこちらを推奨しており、オリジナルがインデックスに残り、ランキングシグナルも統合されたままになります。 301ではなく302(一時的)リダイレクトを使う——オリジナルからバリエーションURLへユーザーをリダイレクトする場合です。302は変更が一時的であり、オリジナルをインデックスに残すようGoogleに伝えます。301ではランキングシグナルがバリエーションに引き継がれ、オリジナルが置き換えられてしまいます。JavaScriptによるリダイレクトも問題ありません。 テストは必要な期間だけ実施する——終了後は、テスト用のURL、スクリプト、マークアップを速やかに削除します。 安心材料として、ボタンの色、「今すぐ購入」と「カートに追加」のラベルの違い、レイアウトの微調整といった小さな変更は、通常ほとんど、あるいはまったく順位に影響しません。WordPressでの実務上の落とし穴がひとつあります。強力なページキャッシュ(WP Rocket、W3 Total Cache)やCDN/エッジのキャッシュが、バリエーションをキャッシュしたり302のロジックを壊したりすることがあるため、URLで振り分ける場合は必ず確認してください。 パーソナライゼーションはSEOに悪影響を与えますか? パーソナライゼーションは、訪問者の行動、所在地、流入元、プロファイルに応じて表示内容を変えます。SEO上の問いはシンプルです:Googlebotには何が見えているのか?その答えこそが、このテーマ全体の鍵です。 GooglebotはCookieも履歴もない一般的な訪問者として(通常は米国から)クロールするため、見えているのはパーソナライズされていないデフォルトの体験です。インデックスされるのはこのデフォルト版です。つまりルールはシンプルで、デフォルト版を完全かつクロール可能な状態に保つことです。 主要なコンテンツや重要なリンクを、パーソナライゼーションの裏に——あるいはGooglebotが実行しない操作の裏に——隠さないでください。 順位を狙いたいコンテンツは、パーソナライゼーションのイベント後に初めて表示されるのではなく、デフォルトでクロール可能なHTMLに含まれるようにしてください。 オーディエンスセグメントに向けたパーソナライズはクローキングではありません。クローキングになるのは、実際のユーザーとは異なるコンテンツを意図的にGooglebotに向けて表示した場合だけです。クローラーをほかの訪問者と同じように扱えば問題ありません。 パーソナライゼーションをクライアント側で実行している場合、GoogleはJavaScriptをレンダリングできるものの、スクリプトが想定どおりに動くことに依存せず、重要なコンテンツにアクセスできる状態にしておくのが最も安全です。 レコメンド、ABM、オーディエンス別ターゲティング:ボットに実際に見えているもの 多くのSEOの懸念が見落としている安心材料があります。ターゲティングが具体的であるほど、クローラーの目に触れることは少なくなるのです。パーソナライゼーションは条件によって発動します——行動、所在地、流入元、ログイン状態、カートの中身、購入履歴、訪問者の勤務先企業などです。Googlebotはそのほとんどを満たしません。Cookieなし、ログアウト状態、履歴なし、購入なしで、どのターゲットアカウントからでもなく訪れるため——毎回そのままデフォルトの体験に行き着きます。 例:アカウントベースドマーケティング(ABM) たとえば ABM施策を実行しているとします。ターゲットアカウント(逆引きIPで、たとえばAcme Corpと特定された企業)の訪問者がホームページに来ると、Personyzeはヒーローを「Acme Corpのために」に差し替え、Acmeの業界の導入事例を表示します。GooglebotはAcmeのIPアドレス範囲からクロールしていないため、このルールが発動することはなく——標準のヒーローが見えます。クローラーから何かを隠すわけでも、インデックス対象を追加で作るわけでもありません。条件を満たさないボットには、パーソナライズ版が表示されないだけです。 例:購入履歴とオーディエンスセグメント 行動ベースやCRMベースのターゲティングも同様です。500ドル以上購入した顧客に「おかえりなさい——次回のご注文が15%オフ」のバナーとVIP向けのおすすめ商品を表示しても、アカウントも購入履歴もないクローラーは条件を満たさないため、デフォルトのページを見ます。カートにもとづくクロスセル、ログインユーザー限定のコンテンツ、リピーター向けのメッセージ、キャンペーンや都市別のオファー——ボットはどの条件にも一致しないため、クロールされる内容には一切現れません。 だからこそ、オーディエンス別のパーソナライゼーションは本質的にSEOに安全なのです。クローキングにはなり得ません——クローラーを特別扱いしているのではなく、クローラーがオーディエンスルールを満たしていないだけで、まさにGoogleが意図するとおりです。しかも、これらのバリエーションは別URLではなく同じページ内で表示されるため、追加でインデックスや正規化をする必要もありません。インデックスされるページは常にデフォルト版——もともと検索向けに最適化したバージョンです。 レコメンドは付加的なもの——そして多くの場合SEOにプラス コンテンツ(「次に読むべき記事」)や 商品レコメンドも同じ仕組みで、さらに利点があります。ページに関連性の高い内部リンクと新しい関連コンテンツを加えるため、クロールパスを支え、訪問者の関心を保てます。クローラーに見えるのは個人向けのセットではなく、人気商品のデフォルトのセットですが——それで問題ありません。ただし、主要なナビゲーションと重要な内部リンクもクロール可能なベース部分に置き、重要なリンク評価がウィジェットの表示に左右されないようにしましょう。 ひとつだけ変わらないルールがあります。本当に順位を狙いたいコンテンツを、こうした条件の裏に置かないことです。SEOにとって重要なテキストやリンクは、ボットが見るデフォルト版に含めるべきです。パーソナライゼーションは、条件を満たす人のためにデフォルト版を補強するものであるべきで——順位を支えている部分を置き換えるものであってはなりません。 隠れたリスク:ちらつき、速度、Core Web Vitals テストもパーソナライゼーションも、通常はJavaScriptを追加します——そして実際の損害が最も起きやすいのがここです。スクリプトが同期的に実行されたり、ファーストビューのコンテンツを再描画したりすると、ちらつき(バリエーションが読み込まれる前に一瞬オリジナルが表示される現象)やレイアウトのずれが生じます。これはランキングシグナルであるCore Web Vitalsを悪化させ、ユーザーを苛立たせます。スクリプトは非同期で軽量に保ち、ちらつき対策を適切に行い、可能ならサーバー側やエッジでのパーソナライゼーションを選び、テスト実施中はCore Web Vitalsを監視しましょう。たとえばPersonyzeはスクリプトをデフォルトで非同期で読み込みます——ダッシュボードでも推奨されている設定です——。そのため、テストやパーソナライゼーションがページの表示をブロックしたり、先にオリジナルを表示したりすることはありません。 A/BテストやパーソナライゼーションはSEOにプラスになりますか? 間接的にはなります——ペナルティの心配ばかりしているチームが忘れがちな点です。Googleは「エンゲージメント」を直接のランキング要因として扱っていませんが、二次的な効果は確かにあります。 テストによるタイトルタグとメタディスクリプションの改善は、検索結果からのクリック率を高めます——オーガニック成果に直結するレバーです。 より関連性の高いページは直帰率とポゴスティッキングを下げ、サイト滞在時間を伸ばします——訪問者が求めていたものを見つけたサインです。 パーソナライズされた […]
商品レコメンドの事例:売上を伸ばす14のパーソナライズ手法

商品が見つけられる場所は、もはやメニューや検索バーではありません。「こちらもおすすめ」「よく一緒に購入されている商品」「あなたへのおすすめ」と表示される提案の帯です。こうしたブロックは、目立たないながら売上の大きな部分を担っています——ただし、適切な人に適切な商品を見せていればの話です。 関連記事: ECパーソナライゼーション・プレイブック これが、ただのレコメンドとパーソナライズされたレコメンドの違いです。汎用的な「ベストセラー」の行でも悪くはありません。しかし、この訪問者が直前に見た商品、いる場所、過去の購入に合わせた行こそが、コンバージョン率と平均注文額を本当に動かします。そして買い物客もそれを期待するようになっています。Statistaのある調査では、Z世代の47%、ミレニアル世代の46%が、オンラインショッピングでパーソナライズされた商品レコメンドを求めていると回答しました。 ここでは、購買プロセス全体にわたる商品レコメンドの事例を14件紹介します——それぞれのパーソナライズのポイントと、 Personyzeのレコメンドエンジンでの構築方法も合わせて解説します。さらに、成果を安定して高める3つの施策、ソーシャルプルーフバッジ、ワンクリックでのバンドル一括カート追加、プッシュ通知も取り上げます。 すべての事例を支えるエンジン 事例の前に、共通点を押さえておきましょう。Personyzeのレコメンドはすべて、3つの選択で構成されています:コンテキスト(表示する場所——ホーム、商品ページ、カート、カテゴリ、検索、さらにはメールまで)、アルゴリズム(商品を選ぶロジック)、そしてテンプレート(見た目)です。アルゴリズムは自分で選ぶことも、AIに任せることもでき、まだ情報のない訪問者向けのフォールバックを設定し、必要に応じてカテゴリ、ブランド、価格、さらには訪問者の性別や年齢でカタログを絞り込めます。 こちらがPersonyzeのアクションエディターにある実際のアルゴリズム選択画面です。以下の事例はすべて、これらの選択の組み合わせを変えただけのものです: Personyze — レコメンドアルゴリズムの選択画面 エディター全体を新しいタブで開く ↗ アルゴリズムの一覧は、普段の買い物でおなじみのパターンを網羅しています。ベストセラー、この商品を見た人はこちらも閲覧、閲覧後に購入された商品、クロスセル、アップセル、よく一緒に購入される組み合わせ、カテゴリから着想、最近チェックした商品、もう一度購入、値下げ、再入荷、ほしい物リストのリマインダーなどです。どれかにフォールバックとテンプレートを組み合わせれば、実際に動く事例になります。 実際の操作を見る · 2:02 — 訪問者ごとの商品レコメンドを設定する. ほかのチュートリアルと一緒に見る → 商品レコメンドの事例14選(とそれぞれのパーソナライズ方法) 1. 初回訪問者向けのベストセラー まったく新しい訪問者が来て行動データがまだない場合は、実績のある人気商品から見せましょう。Personyzeでは、ベストセラーがフォールバックアルゴリズムとして非常に効果的です——枠をすぐに埋め、訪問者が何らかの意図を示した瞬間に、パーソナライズされた提案へ自然に切り替わります。 2. 「前回の続きから」(最近チェックした商品) 多くの人は初回訪問では購入しません——閲覧し、気が散り、離脱します。戻ってきたら、見ていた商品を表示しましょう。Personyzeはセッションやデバイスをまたいで統合された訪問者プロファイルを保持しているため、どのように戻ってきても、その行はすでに用意されています。 3. 「近くで人気」(地域ベース) IPから訪問者の都市や地域を割り出せば、「あなたの地域で人気」「[都市]でトレンド」といったローカルな味付けができます。ストアが自分をわかってくれていると感じてもらえ、Personyzeは国、地域、都市単位でレコメンドをターゲティングできます。 4. 「この商品を見た人はこちらも見ています」 商品ページに置く、みんなの知恵の行です。買い物客は他の人が見たり買ったりしているものに強く影響されるため、一緒に閲覧された商品のブロックはクリック率を確実に高めます。Personyzeは静的なリストではなく、実際のリアルタイムの閲覧データからこれを作ります。 5. ワンクリック一括追加付きの「よく一緒に購入されている商品」 補完商品を1つずつ追加してもらうのではなく、自然なセットを見せて——まとめて一度に追加できるようにします。平均注文額を高める最も強力なレバーのひとつで、Personyzeには専用テンプレートがあります(詳しくは後述)。 6. クロスセル:「相性の良い商品」 / コーディネートを完成 購入を仕上げる補完商品です——ソファにはクッション、エスプレッソマシンにはグラインダー、スマートフォンにはケース。Personyzeのクロスセルとペアリングアルゴリズムは、現在の商品、カート、または訪問者がすでに購入した商品に対して、これらを生成します。 7. 上位版へのアップセル 訪問者が中価格帯の商品を見ているときは、プレミアム版をさりげなく勧めることで、押し付けがましくなく注文額を引き上げられます。アップセルアルゴリズムが、同じシリーズの上位モデルを提示します。 8. 送料無料への後押し付きカートでのクロスセル カートは関連商品をもう1点加えてもらう絶好のタイミングです——特にしきい値と組み合わせると効果的で、「あと$20で送料無料」という表示と、それを達成できるおすすめ商品を並べます。カートに入っている商品を除外することを忘れずに。Personyzeはこれを自動で行います。 9. チェックアウト時の低価格な追加商品 チェックアウトの段階では購入の決断は済んでいます——高額商品を勧める場面ではありません。ついで買いしやすい小物(「こちらも必要かもしれません…」)がよくコンバージョンします。Personyzeは注文内容に合わせてこれらをターゲティングできるため、本当に関連性の高い提案になります。 10. 今のトレンド ベストセラーとは違い——今まさに勢いを増している商品です。「今週のトレンド」ブロックはほどよい緊急性を生み、毎日手作業で選ばなくてもストアを新鮮に保てます。 […]
Personyzeの訪問者ターゲティング:セグメンテーションと行動ターゲティングを支える属性

Personyzeが追跡する訪問者の属性(デバイス、地域、企業、行動、CRM)と、それらをセグメンテーションや行動ターゲティングに活用する方法を解説します。
PersonyzeのA/Bテスト新UI:設定がより簡単に、勝者を自動選択、結果がより明確に

PersonyzeのリニューアルされたA/BテストUIをご紹介します。トラフィック配分、割り当て方法、勝者の自動選択、KPIごとのタブを備えた結果ダッシュボード。実際に操作して試せます。
成果の高いランディングページ:関連性、パーソナライゼーション、テストが勝敗を分ける

成果の高いランディングページの条件とは。メッセージの関連性、ペルソナ別のパーソナライゼーション、A/Bテストを、ホスティング型のランディングページツールなしに自社サイトで実現する方法を解説します。
バンドル販売のメリット:まとめ売りで平均注文額を引き上げる方法

バンドル販売は、関連商品をワンクリックでまとめてカートに追加できるようにすることで、平均注文額を引き上げます。そのメリットと、バンドル販売プロモーションの進め方を解説します。
パーソナライゼーションSaaS:パーソナライゼーションがサービスとして最もうまく機能する理由

パーソナライゼーションSaaSなら、セグメンテーション、レコメンド、ターゲティング、A/Bテストをマネージドサービスとして利用できます。インフラもデータチームもコードも不要です。
サービスとして提供されるレコメンドエンジン

レコメンドエンジンをサービスとして使えば、Webとメールで商品とコンテンツのレコメンドを実現できます。データチームもインフラもコードも不要です。