お支払いと住所のフォームに関するベスト プラクティス

ユーザーが住所や支払いフォームをできるだけ迅速かつ簡単に入力できるようにすることで、コンバージョンを最大化します。

Sam Dutton

適切に設計されたフォームは、ユーザーの利便性を高め、コンバージョン率を向上させます。小さな修正が大きな違いを生むことがあります。

以下は、すべてのベスト プラクティスを実践したシンプルな支払いフォームの例です。

すべてのベスト プラクティスを実践したシンプルな住所フォームの例を次に示します。

チェックリスト

意味のある HTML を使用する

ジョブ用に構築された要素と属性を使用します。

  • <form>、<input>、<label>、<button>
  • type、autocomplete、inputmode

これらを使用すると、組み込みのブラウザ機能を有効にし、ユーザー補助を改善して、マークアップに意味を追加できます。

HTML 要素を本来の目的で使用する

フォームを <form> に配置する

<input> 要素を <form> でラップせず、JavaScript のみでデータ送信を処理したくなるかもしれません。

このようなことは行わないでください。

HTML の <form> を使用すると、最新のすべてのブラウザに組み込まれている強力な機能セットにアクセスできます。また、スクリーン リーダーなどの支援デバイスでサイトにアクセスできるようになります。<form> を使用すると、JavaScript のサポートが制限されている古いブラウザ向けの基本機能を簡単に構築できます。また、コードに不具合がある場合や、実際に JavaScript を無効にしている少数のユーザーでも、フォームを送信できるようになります。

ユーザー入力用のページ コンポーネントが複数ある場合は、それぞれを独自の <form> 要素に配置してください。たとえば、検索と登録が同じページにある場合は、それぞれを独自の <form> に配置します。

<label> を使用して要素にラベルを付ける

<input>、<select>、<textarea> にラベルを付けるには、<label> を使用します。

ラベルの for 属性に、入力の id と同じ値を指定して、ラベルを入力に関連付けます。

<label for="address-line1">Address line 1</label>
<input id="address-line1" …>

1 つの入力に 1 つのラベルを使用します。1 つのラベルで複数の入力をラベル付けしないでください。これは、ブラウザとスクリーン リーダーに最適です。ラベルをタップまたはクリックすると、関連付けられている入力にフォーカスが移動します。スクリーン リーダーは、ラベルまたはラベルの入力にフォーカスが移動すると、ラベルテキストを読み上げます。

ボタンを役立つものにする

ボタンには <button> を使用します。<input type="submit"> を使用することもできますが、div や、ボタンとして機能するその他のランダムな要素は使用しないでください。ボタン要素は、アクセス可能な動作、組み込みのフォーム送信機能を提供し、簡単にスタイルを設定できます。

各フォームの送信ボタンに、そのボタンの動作を示す値を指定します。購入手続きの各ステップで、進捗状況を示し、次のステップを明確にする、わかりやすい行動を促すフレーズを使用します。たとえば、お届け先住所フォームの送信ボタンには、[続行] や [保存] ではなく、[お支払いに進む] というラベルを付けます。

ユーザーが送信ボタンをタップまたはクリックしたら、そのボタンを無効にすることを検討してください。特に、ユーザーが支払いを行ったり、注文したりする場合は、この方法が有効です。多くのユーザーは、ボタンが正常に動作していても、ボタンを繰り返しクリックします。これにより、購入手続きが混乱し、サーバーの負荷が増加する可能性があります。

const form = document.querySelector('form');
const submitButton = form.querySelector('button[type="submit"]');

form.addEventListener('submit', () => {
  submitButton.disabled = true;
  submitButton.textContent = 'Placing order…';
});

一方、完全で有効なユーザー入力を待機している送信ボタンを無効にしないでください。たとえば、何かが不足しているか無効であるという理由だけで、[住所を保存] ボタンを無効のままにしないでください。これではユーザーの役に立ちません。ユーザーはボタンをタップまたはクリックし続け、ボタンが壊れていると思うかもしれません。 代わりに、ユーザーが無効なデータを含むフォームを送信しようとした場合は、何が間違っているのか、それを修正するにはどうすればよいのかを説明します。これは、モバイルでは特に重要です。モバイルではデータ入力が難しく、フォームを送信しようとするまで、フォームデータの欠落や無効なフォームデータがユーザーの画面に表示されないことがあります。

HTML 属性を最大限に活用する

ユーザーがデータを入力しやすくする

適切な入力 type 属性を使用して、モバイルで適切なキーボードを提供し、ブラウザによる基本的な組み込み検証を有効にします。

たとえば、メールアドレスには type="email"、電話番号には type="tel" を使用します。

Android スマートフォンの 2 つのスクリーンショット。メールアドレスの入力に適したキーボード（type=email を使用）と、電話番号の入力に適したキーボード（type=tel を使用）が表示されています。
メールや電話に適したキーボード。

日付には、カスタム select 要素を使用しないでください。適切に実装されていないと、自動入力エクスペリエンスが損なわれ、古いブラウザでは機能しません。生まれ年などの数字については、select ではなく input 要素の使用を検討してください。特にモバイルでは、長いプルダウン リストから選択するよりも、手動で数字を入力する方が簡単で、エラーが発生しにくいためです。inputmode="numeric" を使用して、モバイルで適切なキーボードが表示されるようにします。また、テキストまたはプレースホルダを使用して検証と形式のヒントを追加し、ユーザーが適切な形式でデータを入力できるようにします。

予測入力を使用してユーザー補助を改善し、ユーザーがデータを再入力しなくて済むようにする

適切な autocomplete 値を使用すると、ブラウザはデータを安全に保存し、input、select、textarea の値を自動入力してユーザーを支援できます。これはモバイルでは特に重要であり、フォームの放棄率を抑えるうえで不可欠です。予測入力には、ユーザー補助に関する複数のメリットもあります。

フォーム フィールドに適切な予測入力値がある場合は、それを使用する必要があります。MDN ウェブドキュメントには、値の完全なリストと、それらを正しく使用する方法の説明が記載されています。

安定した値

請求先住所

デフォルトでは、請求先住所はお届け先住所と同じに設定されます。請求先住所をフォームに表示するのではなく、請求先住所を編集するためのリンクを提供（または summary 要素と details 要素を使用）することで、視覚的な煩雑さを軽減します。

請求先住所を変更するリンクが表示されている購入手続きページの例。
請求を確認するためのリンクを追加します。

配送先住所と同様に、請求先住所にも適切な予測入力値を使用することで、ユーザーがデータを複数回入力する必要がなくなります。異なるセクションで同じ名前の入力に異なる値がある場合は、予測入力属性に接頭辞を追加します。

<input autocomplete="shipping address-line1" ...>
<!-- Other fields omitted. -->
<input autocomplete="billing address-line1" ...>

ユーザーが正しいデータを入力できるようにする

「お客様が間違ったことをした」からといって、お客様を「叱る」ことは避けてください。代わりに、問題が発生したときにユーザーが問題を解決できるようにすることで、ユーザーがフォームをより迅速かつ簡単に完了できるようにします。購入手続きを通じて、顧客は商品やサービスに対して会社にお金を支払おうとしています。あなたの仕事は、顧客を支援することであり、罰することではありません。

フォーム要素に制約属性を追加して、許容される値（min、max、pattern など）を指定できます。要素の有効性状態は、要素の値が有効かどうかに応じて自動的に設定されます。:valid および :invalid CSS 疑似クラスも同様で、有効な値または無効な値を持つ要素のスタイルを設定するために使用できます。

たとえば、次の HTML では、1900 ～ 2020 年の出生年の入力を指定しています。type="number" を使用すると、入力値は min と max で指定された範囲内の数値のみに制限されます。範囲外の数値を入力しようとすると、入力は無効な状態に設定されます。

次の例では、pattern="[\d ]{10,30}" を使用して、有効な支払いカード番号を確保し、スペースを許可しています。

最新のブラウザでは、タイプ email または url の入力に対して基本的な検証も行われます。

フォームの送信時に、ブラウザは問題のあるフィールドや必須の値が欠落しているフィールドに自動的にフォーカスを設定します。JavaScript は不要です。

パソコン版 Chrome のログイン フォーム。ブラウザのプロンプトと、無効なメールアドレス値のフォーカスが表示されている。
ブラウザによる基本的な組み込み検証。

ユーザーが送信ボタンをクリックしたときにエラーのリストを表示するのではなく、ユーザーがデータを入力する際にインラインで検証してフィードバックを提供します。フォームの送信後にサーバーでデータを検証する必要がある場合は、見つかったすべての問題を一覧表示し、無効な値を含むすべてのフォーム フィールドを明確にハイライト表示します。また、問題のある各フィールドの横に、修正が必要な内容を説明するメッセージをインラインで表示します。サーバーログと分析データで一般的なエラーを確認します。フォームの再設計が必要になる場合があります。

また、JavaScript を使用して、ユーザーがデータを入力しているときやフォームを送信するときに、より堅牢な検証を行う必要があります。Constraint Validation API（広くサポートされている）を使用して、組み込みのブラウザ UI を使用してカスタム検証を追加し、フォーカスを設定してプロンプトを表示します。

詳しくは、クライアントサイドのフォーム検証をご覧ください。

ユーザーが必要なデータを入力し忘れないようにする

必須値の入力には required 属性を使用します。

フォームが送信されると、最新のブラウザは自動的にプロンプトを表示し、データが欠落している required フィールドにフォーカスを設定します。:required 疑似クラスを使用して、必須フィールドをハイライト表示できます。JavaScript は不要です。

必須フィールドのラベルにアスタリスクを追加し、フォームの先頭にアスタリスクの意味を説明するメモを追加します。

ご購入手続きを簡素化する

モバイル コマースのギャップに注意する

ユーザーには疲労予算があるとします。使い切ると、ユーザーは離れていきます。

特にモバイルでは、ユーザーの負担を軽減し、ユーザーが集中できるようにする必要があります。多くのサイトでは、モバイルでのトラフィックは多いものの、コンバージョンはパソコンの方が多いという現象が見られます。これはモバイル コマース ギャップと呼ばれています。お客様が単にパソコンでの購入を好む場合もありますが、モバイル コンバージョン率が低いのは、ユーザー エクスペリエンスが不十分なためでもあります。あなたの仕事は、モバイルでのコンバージョンの損失を最小限に抑え、パソコンでのコンバージョンを最大化することです。調査によると、モバイル フォームのエクスペリエンスを改善する余地は十分にあります。

特に、フォームが長く、複雑で、方向性が明確でない場合、ユーザーはフォームの入力を途中でやめてしまう可能性が高くなります。これは、ユーザーが小さな画面を使用している場合、気が散っている場合、急いでいる場合に特に当てはまります。要求するデータはできるだけ少なくします。

「ログインせずに決済」をデフォルトにする

オンライン ショップの場合、フォームの煩わしさを軽減する最も簡単な方法は、ログインせずに決済をデフォルトにすることです。購入前にユーザーにアカウントの作成を強制しないでください。ログインせずに決済できないことが、ショッピング カートを放棄する主な理由として挙げられています。

購入手続き中にショッピング カートが放棄される理由。
baymard.com/checkout-usability より

アカウント登録は、購入手続き後に提供できます。この時点で、アカウントの設定に必要なデータのほとんどがすでに揃っているため、ユーザーはアカウントをすばやく簡単に作成できます。

購入手続きの進行状況を表示する

進行状況を表示し、次に何をする必要があるかを明確にすることで、購入手続きをよりシンプルに感じさせることができます。次の動画は、英国の小売業者 johnlewis.com がこれをどのように実現しているかを示しています。

購入手続きの進行状況を表示する。

この勢いを維持する必要があります。支払いまでの各ステップで、ページの見出しとわかりやすいボタンの値を使用して、今何をする必要があるのか、次の決済ステップが何なのかを明確にします。

フォームのボタンには、次のステップを示すわかりやすい名前を付けます。

フォーム入力で enterkeyhint 属性を使用して、モバイル キーボードの Enter キーのラベルを設定します。たとえば、複数ページのフォーム内では enterkeyhint="previous" と enterkeyhint="next" を使用し、フォームの最後の入力には enterkeyhint="done" を、検索入力には enterkeyhint="search" を使用します。

Android の住所フォームの 2 つのスクリーンショット。enterkeyhint 入力属性によって Enter キーボタンのアイコンがどのように変化するかを示しています。
Android の Enter キーボタン: [次へ] と [完了]

enterkeyhint 属性は Android と iOS でサポートされています。詳しくは、enterkeyhint の説明をご覧ください。

ユーザーが購入手続きを簡単に行き来できるようにして、最終的な支払いステップにいる場合でも、注文を簡単に調整できるようにします。限定的な概要だけでなく、注文の全詳細を表示します。ユーザーが支払いページから商品の数量を簡単に調整できるようにします。購入手続きで優先すべきことは、コンバージョンに至るまでのプロセスを中断させないことです。

不要なものを除去

商品のプロモーションなど、視覚的に煩雑で気が散る要素を排除して、離脱ポイントを減らします。成功している小売業者の多くは、購入手続きからナビゲーションと検索を削除しています。

johnlewis.com の購入手続きの進行状況を示す、モバイルの 2 つのスクリーンショット。検索、ナビゲーション、その他の気が散る要素は削除されます。
購入手続きの際に、検索、ナビゲーション、その他の気が散る要素を排除。

ジャーニーを簡潔にまとめます。この段階でユーザーに他の操作を促すのは得策ではありません。

モバイルの購入手続きページに、無料ステッカーのプロモーションが邪魔になる形で表示されている。
購入手続きを完了しようとしているユーザーの注意をそらさない。

リピーターに対しては、不要なデータを非表示にすることで、購入手続きのフローをさらに簡素化できます。たとえば、お届け先住所を（フォームではなく）書式なしテキストで表示し、ユーザーがリンクをたどって変更できるようにします。

購入手続きページの [注文内容の確認] セクション。テキストが書式なしテキストで表示され、お届け先住所、お支払い方法、請求先住所を変更するためのリンクが表示されていません。
顧客に表示する必要のないデータを非表示にする。

名前と住所を簡単に入力できるようにする

必要なデータのみをリクエストする

名前と住所のフォームのコーディングを開始する前に、必要なデータを把握してください。不要なデータはリクエストしないでください。フォームの複雑さを軽減する最も簡単な方法は、不要なフィールドを削除することです。これは、お客様のプライバシーにも配慮したものであり、バックエンドのデータ費用と責任を軽減できます。

1 つの名前入力を使用する

名前、姓、敬称、その他の名前の一部を個別に保存する特別な理由がない限り、ユーザーが 1 つの入力欄に名前を入力できるようにします。名前の入力欄を 1 つにすることで、フォームが簡素化され、切り取りと貼り付けが可能になり、自動入力が簡単になります。

特に、正当な理由がない限り、敬称や肩書き（Mrs、Dr、Lord など）の入力欄を別途追加する必要はありません。ユーザーは必要に応じて、名前とともにこれを入力できます。また、honorific-prefix の予測入力は現在、ほとんどのブラウザで機能しないため、名前の接頭辞や敬称のフィールドを追加すると、ほとんどのユーザーにとって住所フォームの自動入力機能が使えなくなります。

名前の自動入力を有効にする

フルネームには name を使用します。

<input autocomplete="name" ...>

名前の各部分を分割する正当な理由がある場合は、適切な予測入力値を使用してください。

  • honorific-prefix
  • given-name
  • nickname
  • additional-name-initial
  • additional-name
  • family-name
  • honorific-suffix

国際的な名前を許可する

名前の入力を検証したり、名前データに使用できる文字を制限したりする必要があるかもしれません。ただし、アルファベットについては、できる限り制限を緩くする必要があります。名前が「無効」と言われるのは失礼です。

検証では、ラテン文字のみに一致する正規表現を使用しないでください。ラテン文字のみの場合、ラテン文字以外の文字を含む名前または住所のユーザーは除外されます。代わりに Unicode 文字の一致を許可し、バックエンドが入力と出力の両方で Unicode を安全にサポートするようにします。正規表現の Unicode は、最新のブラウザで十分にサポートされています。

すべきでないこと
<!-- Names with non-Latin characters (such as Françoise or Jörg) are 'invalid'. -->
<input pattern="[\w \-]+" ...>
すべきこと
<!-- Accepts Unicode letters. -->
<input pattern="[\p{L} \-]+" ...>
Unicode 文字の一致とラテン文字のみの一致の比較。

さまざまな住所形式に対応する

住所フォームを設計する際は、1 つの国の中でも住所の形式が多種多様であることに注意してください。「通常の」住所について、思い込みをしないように注意してください。（納得できない場合は、UK Address Oddities! をご覧ください）。

住所フォームを柔軟にする

ユーザーがフォーム フィールドに収まらない住所を無理に入力しようとすることがないようにします。

たとえば、番地と通り名を別々に入力するよう求めないでください。多くの住所はその形式を使用しておらず、不完全なデータによってブラウザの自動入力が機能しなくなる可能性があります。

required のアドレス フィールドには特に注意してください。たとえば、英国の大都市の住所には郡がありませんが、多くのサイトでは依然として郡の入力をユーザーに強制しています。

2 つの柔軟な住所行を使用すると、さまざまな住所形式に十分対応できます。

<input autocomplete="address-line1" id="address-line1" ...>
<input autocomplete="address-line2" id="address-line2" ...>

一致するラベルを追加します。

<label for="address-line1">
Address line 1 (or company name)
</label>
<input autocomplete="address-line1" id="address-line1" ...>

<label for="address-line2">
Address line 2 (optional)
</label>
<input autocomplete="address-line2" id="address-line2" ...>

住所には単一のテキストエリアを使用することを検討する

住所の最も柔軟なオプションは、1 つの textarea を指定することです。

textarea のアプローチは、あらゆる住所形式に適合し、切り取りと貼り付けに最適です。ただし、データ要件に適合しない場合があること、また、以前に address-line1 と address-line2 のフォームのみを使用していたユーザーは自動入力を使用できない場合があることに注意してください。

textarea の場合は、予測入力の値として street-address を使用します。

住所に 1 つの textarea を使用するフォームの例を次に示します。

住所フォームを多言語対応、ローカライズする

住所フォームでは、ユーザーの所在地に応じて国際化とローカライズを考慮することが特に重要です。

住所の各部分の名称は、同じ言語であっても、住所の形式と同様に異なる場合があります。

    ZIP code: US
 Postal code: Canada
    Postcode: UK
     Eircode: Ireland
         PIN: India

住所に合わないフォームや、想定していない単語が使用されているフォームが表示されると、イライラしたり、戸惑ったりすることがあります。

サイトによっては、複数の地域に合わせて住所フォームをカスタマイズする必要があるかもしれませんが、前述のようにフォームの柔軟性を最大限に高める手法を使用すれば十分な場合もあります。住所フォームをローカライズしない場合は、さまざまな住所形式に対応するための重要な優先事項を理解してください。

  • 住所の一部（番地や家屋番号など）を過度に特定しないようにします。
  • 可能な限り、フィールドを required にすることは避けてください。たとえば、多くの国の住所には郵便番号がなく、地方の住所には通りや道路の名前がない場合があります。
  • 包括的な名称を使用します。たとえば、「国」ではなく「国/地域」、「郵便番号」ではなく「郵便番号/郵便番号」を使用します。

柔軟性を保ちましょう。上記のシンプルな住所フォームの例は、多くの地域で「十分に」機能するように調整できます。

郵便番号による住所検索を避けることを検討する

一部のウェブサイトでは、郵便番号に基づいて住所を検索するサービスが使用されています。これは一部のユースケースでは妥当な場合がありますが、潜在的なデメリットに注意する必要があります。

郵便番号による住所の候補は、すべての国で機能するわけではありません。また、一部の地域では、郵便番号に多数の住所候補が含まれる場合があります。

郵便番号には多くの住所が含まれる場合があります。

長い住所リストから選択するのは、ユーザーにとって困難です。特に、モバイルで急いでいるときやストレスを感じているときはなおさらです。自動入力機能を利用して、ユーザーが 1 回のタップまたはクリックで住所全体を入力できるようにすると、入力が簡単になり、エラーも少なくなります。

名前を 1 つ入力するだけで、ワンタップ（ワンクリック）で住所を入力できます。

支払いフォームを簡素化する

支払いフォームは、購入手続きの中で最も重要な部分です。支払いフォームのデザインが不適切であることは、ショッピング カートの放棄の一般的な原因です。細部に注意を払う: 小さな不具合でも、ユーザーが購入をあきらめる原因になることがあります。特にモバイルでは注意が必要です。あなたの仕事は、ユーザーがデータをできるだけ簡単に入力できるようにフォームを設計することです。

ユーザーが支払いデータを再入力する手間を省く

支払いカード番号、カードに記載されている名前、有効期限、セキュリティ コードなど、支払いカードのフォームに適切な autocomplete 値を追加してください。

  • cc-number
  • cc-name
  • cc-exp、または cc-exp-month と cc-exp-year（個別のフィールドの場合）
  • cc-csc

これにより、ブラウザは支払いカードの詳細を安全に保存し、フォームデータを正しく入力することで、ユーザーを支援できます。予測入力がないと、ユーザーは支払いカードの詳細を物理的に記録したり、支払いカードのデータをデバイスに安全でない方法で保存したりする可能性が高くなります。

支払いカードの日付にカスタム要素を使用しない

カスタム要素が適切に設計されていないと、自動入力が機能しなくなり、支払いフローが中断される可能性があります。また、古いブラウザでは動作しません。他のすべての支払いカードの詳細が予測入力から利用可能であっても、カスタム要素で自動入力が機能しなかったために、ユーザーが有効期限を調べるために物理的な支払いカードを探す必要がある場合、販売を失う可能性があります。代わりに標準の HTML 要素を使用し、それに応じてスタイルを設定することを検討してください。

自動入力を妨げるカードの有効期限のカスタム要素が表示されている支払いフォーム。
予測入力により、有効期限を除くすべてのフィールドが入力されました。

支払いカードと電話番号に単一の入力を使用する

支払いカードと電話番号には、1 つの入力を使用します。番号を分割しないでください。これにより、ユーザーがデータを入力しやすくなり、検証が簡単になり、ブラウザで自動入力できるようになります。PIN や銀行コードなどの他の数値データについても同様にすることをおすすめします。

4 つの入力要素に分割されたクレジット カード フィールドを示す支払いフォーム。
クレジット カード番号に複数の入力を使用しないでください。

慎重に検証する

データ入力は、リアルタイムとフォーム送信前の両方で検証する必要があります。これを行う方法の 1 つは、支払いカードの入力に pattern 属性を追加することです。ユーザーが無効な値を含む支払いフォームを送信しようとすると、ブラウザに警告メッセージが表示され、入力にフォーカスが設定されます。JavaScript は必要ありません。

ただし、pattern 正規表現は、14 桁（またはそれ以下）から 20 桁（またはそれ以上）の支払いカード番号の長さの範囲を処理できる柔軟性を備えている必要があります。支払いカード番号の構造の詳細については、LDAPwiki をご覧ください。

新しい支払いカード番号を入力する際に、ユーザーがスペースを入力できるようにします。これは、物理的なカードに番号が表示される方法です。この方法であれば、ユーザーに「入力に誤りがある」と伝える必要がなく、コンバージョン フローが中断される可能性も低くなります。また、処理前に番号内のスペースを削除するのも簡単です。

さまざまなデバイス、プラットフォーム、ブラウザ、バージョンでテストする

フォーム要素の機能と外観は異なる場合があり、ビューポートのサイズの違いによって位置が問題になる可能性があるため、ユーザーにとって最も一般的なプラットフォームで住所フォームと支払いフォームをテストすることが特に重要です。BrowserStack を使用すると、さまざまなデバイスやブラウザでオープンソース プロジェクトの無料テストを行うことができます。

iPhone 7 と iPhone 11 の支払いフォーム。[支払いを完了] ボタンが iPhone 11 には表示されるが、iPhone 7 には表示されない
iPhone 7 と iPhone 11 で同じページを表示。
小さいモバイル ビューポートのパディングを減らして、[Complete payment] ボタンが隠れないようにします。

分析と RUM を実装する

ローカルでユーザビリティとパフォーマンスをテストすることは有用ですが、ユーザーが支払いフォームや住所フォームをどのように体験しているかを適切に把握するには、実際のデータが必要です。

そのためには、分析と実際のユーザー モニタリング（購入手続きページの読み込みにかかる時間や、支払いの完了にかかる時間など、実際のユーザー エクスペリエンスに関するデータ）が必要です。

  • ページ分析: フォームを含むすべてのページのページビュー、直帰率、離脱数。
  • インタラクション分析: 目標到達プロセスとイベントは、ユーザーが購入手続きのフローを放棄した場所と、フォームを操作するときに実行したアクションを示します。
  • ウェブサイトのパフォーマンス: ユーザー中心の指標を使用すると、購入手続きページの読み込みが遅いかどうか、遅い場合はその原因を特定できます。

ページ分析、インタラクション分析、実際のユーザー パフォーマンス測定は、サーバーログ、コンバージョン データ、A/B テストと組み合わせることで特に価値が高まり、割引コードによって収益が増加するかどうか、フォーム レイアウトの変更によってコンバージョンが改善するかどうかなどの質問に答えることができます。

これにより、取り組みの優先順位付け、変更、成功への報酬の確固たる基盤が得られます。

学習を継続

写真撮影: @rupixen（出典: Unsplash）