メールのA/Bテストは、2つのバージョンを同じような条件で比べるものです。その価値は、ダッシュボードに表示される勝者のバッジではなく、テストによって下せる判断にあります。

まずは、どちらの結果が出ても次のメールが変わるくらい具体的な問いから始めましょう。「スクリーンショットがあると、新しいユーザーはセットアップを完了しやすくなるか？」は役に立つ問いです。「どちらのメールが良いか？」では、決まっていないことが多すぎます。

まず成果の指標を決める

送信する理由に近い指標を使いましょう。目的がアクティベーションなら、開封よりも、製品での作業の完了のほうが役に立ちます。ニュースレターなら、関連するクリックや返信で十分な場合もあります。迷惑メール報告と配信停止は、主要な指標でなくても、コストとして追跡しましょう。

分母を定義しましょう。到達したメールあたりのクリックと、開封した人あたりのクリックとでは、答えている問いが異なります。開封にもとづく指標は、プライバシー保護機能の影響も受けます。たとえば Apple のメールプライバシー保護は、メールのリモートコンテンツをバックグラウンドで読み込むことがあるため、誰も読んでいないメッセージにも開封が記録される場合があります。テストを始める前に、正確な計算方法を書き留めておきましょう。

トラッキングが判断を誤らせやすい点については、メールの指標のガイドで解説しています。

テストする要素の優先順位

どこから始めればいいかわからない場合は、このリストを上から順に試しましょう。上のほうにある要素は、読み手がそもそもそのメッセージを求めているかどうかを左右します。誰も欲しがらないオファーは、ボタンを改善しても救えません。

配信時刻のテストは、意図的に各バージョンを異なる時刻に送る唯一のテストです。オーディエンスの分け方を含め、それ以外はすべて同じにして、両方のグループを同じ長さの期間で測定しましょう。

テストは仮説として書く

仮説では、変更点、オーディエンス、指標、そして違いが出ると考える理由を明記します。学びが得られるのは、この理由の部分です。結果が予想と逆になれば、どの前提を疑うべきかがわかります。型は「［オーディエンス］に対して［変更］を行うと、［理由］ので、［指標］が［上がる／下がる］」です。

If we [change] for [audience], [metric] will [rise or fall] because [reason].

例をいくつか挙げます。

• 新しいトライアルユーザー向けのオンボーディングメールに、セットアップ完了後の画面のスクリーンショットを加えると、何を目指して作業しているのかが見えるので、7日以内にセットアップを完了する人が増える。
• ニュースレターの差出人を会社名から編集者の名前に変えると、読み手は書いている本人を知っているので、返信が増える。
• リリースのお知らせメールの件名で、「製品アップデート」と書く代わりに新機能の名前を挙げると、自分に関係があるかどうかを読み手が判断できるので、機能ページへのクリックが増える。
• ウェビナーの招待メールのプレビューテキストに登録締め切りを加えると、受信トレイで日付が見えるので、締め切り前の登録が増える。
• メインのリンクを最初の画像より上に移すと、スクロールせずにたどり着けるので、スマートフォンで読んでいる人からのクリックが増える。
• 止まっているトライアルアカウントに、割引ではなくセットアップを手伝うミーティングを提案すると、これらのアカウントはセットアップの途中で止まっているので、有料プランへの転換が増える。

どの仮説も外れる可能性がありますが、外れても読み手について何かがわかります。「新しいテンプレートを試す」のような曖昧なテストからは、どちらのバージョンが勝っても、ほとんど何も学べません。

意味のある差を決めておく

小さな変化は、本物であっても、追加の制作の手間に見合わないほど小さいことがあります。判断を変えるのに必要な最小の効果を決め、ベースラインの割合を見積もり、信頼度と検出力を明示したうえでサンプルサイズを計算しましょう。

「受信者1,000人」のような、どこにでも通用する最低ラインはありません。よくある行動と、めったに起きない購入とでは、必要なサンプルが異なります。ごく小さなリフトを検出したいテストには、大きな変化を探すテストよりも多くのデータが必要です。

リストが小さいなら、1回のキャンペーンを多数のごく小さなグループに分けるよりも、条件の近い複数回の配信で大きな変更をテストしたり、定性的なフィードバックを集めたりするほうがよい場合もあります。キャンペーンを繰り返すとタイミングの違いが入り込むので、結果を解釈するときは、その制約も書き添えましょう。

比較を解釈できる状態に保つ

対象となる受信者を、各バージョンにランダムに割り当てましょう。オーディエンスのルール、配信時間帯、その他の重要な内容は、比較できるようにそろえます。件名、レイアウト、オファー、ランディングページをまとめて変えると、テストしているのは全体のセットになり、どの部分が違いを生んだのかはわかりません。

同じ人への繰り返しの送信を、独立した観測として数えないようにしましょう。アカウント単位の成果を測る場合は、同じアカウントの人どうしが影響し合う可能性も考慮します。

観測期間は、目的の行動が起きるのに十分な長さに設定します。統計手法がそのやり方に明確に対応していない限り、途中で何度も結果をのぞき、最初に有利な変動が出たところでテストを止めるのはやめましょう。

見出しの数字だけでなく、不確かさを読む

たとえば、一方のバージョンで購入が24件、もう一方で27件だったとします。この件数だけでは、勝者は決まりません。グループの規模、割り当ての方法、そして推定された差の信頼区間が必要です。

結論が出なかったなら、そう明記しましょう。シンプルなほうのバージョンを残すか、得られた学びを生かして、次はもっと確かなテストを設計します。大きな改善の可能性を否定できたテストも、時間の節約につながります。

仮説、バージョン、オーディエンス、サンプル、日付、指標、結果、次の判断を記録し、その記録をキャンペーンにひも付けておきましょう。件名を見直すときは、1回のテストの結果を、すべてのオーディエンスに当てはまる不変のルールにしないよう注意してください。