シングルオプトインとダブルオプトインの到達率の違い

購読者を1人追加するたびに、到達率にとっては小さな賭けをしていることになります。シングルオプトインは集められる人数を最大にし、ダブルオプトインは、各アドレスが実在し、メールを受け取る意思があるという確実性を最大にします。この選択は長年、成長か品質かのトレードオフとして語られてきました。しかし、第3の選択肢が登場し、このトレードオフはずっと負担の少ないものになっています。ここでは、2つの方式の比較、それぞれの弱点、そして登録時点でアドレスを検証することで状況がどう変わるかを解説します。

結論#

シングルオプトインは、フォームを送信した時点で購読者を追加します。ダブルオプトインは、確認メールのリンクをクリックした後に初めて追加します。ダブルオプトインはリストがクリーンになり、同意の記録も残りますが、手間がかかり離脱も発生します。シングルオプトインは増え方が速い反面、入力ミス、無効なアドレス、悪意のある登録がそのままリストに入り、バウンスやスパムトラップへの到達につながります。登録フォームでのリアルタイム検証、つまり入力時点での検証は、ダブルオプトインの確認ステップを加えずに、シングルオプトインの最大の弱点を解消します。そのため、どちらの方式とも並べて検討する価値があります。

シングルオプトインとは#

シングルオプトインは1ステップです。アドレスを入力してフォームを送信すれば、リストに加わります。ほかに必要な操作はありません。これが最大の魅力で、購読したい人が全員購読者になり、2つ目の操作で失敗する余地がありません。収集方法としては最も成長しやすい方式です。

問題は、入力からリスト登録までの間に関門がないことです。入力されたものは、そのまま入ります。

• 入力ミス。 jane@gmial.comやbob@yaho.comは、登録フォームから見れば問題ありませんが、完全に無効です。購読者はメールを受け取りたいのに、届くことはありません。送信者側も、その理由に気づけません。
• 無効なアドレスや存在しないアドレス。 最初から存在しなかったメールボックスや、閉鎖されたメールボックスがリストに入り、将来のハードバウンスとして残り続けます。
• 使い捨てアドレス。 リードマグネットを受け取るために使われ、その後は二度と開かれない一時的な受信トレイです。
• 悪意のある登録。 ボットや悪意のある人物が、自分のものではないアドレスを送信します。ときには、スパムトラップだったというケースもあります。同意を得て集めたのではなく、フォームが何でも受け付けたために集まったアドレスです。

こうした問題は、最初の配信で必ず表面化します。無効なアドレスはバウンスし、バウンス率の上昇は、メールプロバイダーが読み取る最も明確なマイナスのシグナルの1つです。

ダブルオプトインとは#

ダブルオプトインは確認ステップを加えた方式です。フォームの送信後に、確認リンク付きの短いメールを送り、クリックして初めてリストに加わります。これでそのアドレスは、メールを受信できることと、相手側の人間が操作したことの2つを証明したことになります。

メリットは確かにあります。

• よりクリーンなリスト。 確認済みで到達可能な、少なくとも最低限のエンゲージメントがあるアドレスだけが通過します。ボットや入力ミスのアドレスが確認リンクをクリックすることはまずないため、購読者になりません。
• 同意の証拠。 確認のクリックは、受信者が連絡に同意したことを示す、タイムスタンプ付きの記録になります。GDPRのような同意を基本とする規制の下で役立ち、苦情に異議が出た場合にも有力な根拠になります。

一方、デメリットも同じくらい確かにあります。

• 手間と離脱。 ステップが増えるたびに人が離れます。正当な購読者のかなりの割合が確認を完了しません。メールがプロモーションタブに入る、気が散る、迷惑メールに振り分けられるなどが理由です。メールを受け取りたかったのにリストに加われなかった、実在の人たちです。
• 確認メール自体がバウンスし得る。 これが見落としやすい欠点です。アドレスが入力ミスや存在しないメールボックスだと、確認メールがバウンスします。つまり、ダブルオプトインでもバウンスは発生し、購読希望者は訂正する機会もなく静かに消えてしまいます。確認メールのバウンスで気づいた入力ミスは失われた購読者ですが、フォームで気づいた入力ミスなら救えた購読者です。

到達率の違い#

2つの方式では、できあがるリストに測定可能な差が出ます。その差は、プロバイダーが最も重視する3つの指標に表れます。

バウンス率。 シングルオプトインのリストには、無効なアドレスや入力ミスのアドレスが多く含まれるため、バウンスが増えます。ハードバウンスが起きるたびに、送るべきでないアドレスに送っていることがプロバイダーに伝わり、高いバウンス率は受信トレイへの到達を失う最も速い原因の1つです。ダブルオプトインは、確認メールすら受信できないアドレスを除外するため、構造的にバウンスが少なくなります。

スパムトラップへの到達リスク。 シングルオプトインでは、再利用型や未使用型のスパムトラップがリストに入り込むことがあります。たとえば、たまたまトラップ用の基盤だった入力ミスのドメインや、悪意のある登録です。ダブルオプトインでは、未使用のトラップ宛ての確認リンクを人間がクリックすることはないため、入り込むことはまれです。トラップへの到達は、リストが抱える最も深刻なシグナルの1つで、2つの方式では扱いが大きく異なります。

送信者レピュテーション。 バウンス、トラップへの到達、質の低い登録に続く迷惑メール報告は、いずれも送信者レピュテーションを損ないます。そして、メールが受信トレイに届くかどうかを決めるのは、レピュテーションです。汚れたリストは、1回バウンスが増えるだけでなく、その後のすべての配信を悪化させます。

第3の選択肢：入力時点での検証#

シングルオプトインの手間の少なさを保ちながら、ダブルオプトインのクリーンなリストも同時に得る方法があります。アドレスが入力された瞬間に検証することです。

リアルタイムのメールアドレス検証は、最終的にバウンスで判明するのと同じチェックを、リストに入る前に、その場で実行します。構文、ドメインとメールサーバーの解決を一瞬でチェックし、使い捨てアドレスや役割アドレスを検出します。さらに重要なのは、明らかな入力ミスに対して「もしかして」の修正候補を提示する点です。各アドレスにはステータスが返されるため、フォームはそれに応じて動作できます。

• undeliverableのアドレスは、保存する前にその場で拒否します。
• gmial.comと入力された場合は修正候補を提示します。失われるはずだった購読者を救い、バウンスも登録の取りこぼしも起きません。
• 使い捨てアドレスは、入り口でフラグを付けるかブロックします。
• それ以外はすべて、シングルオプトインのフォームと同じように受け付けます。

これにより、シングルオプトインの最大の弱点である「ゴミが入る」問題を、ダブルオプトインの最大のデメリットである、2通目のメールによる手間と静かな離脱なしに解消できます。アドレスは入力の時点で検証されるため、途中で放棄される確認ステップがありません。実装は、フォームの背後に置く小さなサーバー側の関数です。APIが遅いときに本物の登録をブロックしないためのフェイルオープンのルールを含む実装パターンは、サーバーレス関数による登録時のメール検証で解説しています。無料メールチェッカーで手動で試すこともでき、検証APIでフォームに組み込むこともできます。

入力時点での検証が確認するのは到達可能性であり、同意ではありません。連絡に同意したことの記録が必要な場合は、引き続きダブルオプトインの役割です。この2つが競合ではなく補完関係にあるのは、そのためです。

どちらを選ぶべきか#

最適な方式は、何を重視するかによって決まります。

• 成長を重視する一般消費者向けの登録（ECサイト、ニュースレター、アプリ）。 シングルオプトインに入力時点での検証を組み合わせます。手間を抑えて登録率を高く保ちつつ、検証によって入力ミス、無効なアドレス、使い捨てアドレスを取り除けます。これらはシングルオプトインを弱点に変える要因です。ほとんどの送信者にとって、総合的に最も優れた構成です。
• 同意の確認が特に重要なリストや規制対象のリスト（EU向けマーケティング、リスクの高い配信）。 同意の記録のためにダブルオプトインを使い、その前段に入力時点での検証を置きます。こうすれば、確認メールが入力ミスでバウンスせず、実際に相手に届きます。アドレスは確認メールの送信前に検証され、確認メールが同意を証明する、最も強力な構成です。
• 判断に迷う場合。 どちらの方式でも、まずフォームに入力時点での検証を導入してください。そのうえで、追加の確認ステップが、自社の対象者にとって離脱に見合うかを判断します。検証は、どちらの方式でも効果を発揮する層です。

シングルオプトインとダブルオプトインを単純なトレードオフとして捉える見方は、もう古くなっています。ダブルオプトインにコストをもたらした手間と、シングルオプトインにリスクをもたらした汚れたリストの問題は、別々の失敗です。入力時点での検証は後者を直接解決し、ダブルオプトインには、その方式にしかできない役割である同意の証明だけを任せられます。

クリーンなリストは、最初の配信の前から始まります。入力された瞬間に、各アドレスを検証してください。無料プランには100クレジットが含まれており、自社の登録フォームで入力時点での検証を試せます。また、APIリファレンスには、フォームの背後に組み込める/verifyエンドポイントが用意されています。