目次
はじめに
こんにちは！ 食べログ開発本部ウェブ開発 1 部に所属している城戸です。
2021 年に新卒入社してから、現在はメディアマネジメントチームに所属しており、
食べログの一般ユーザー向けページの機能開発、他社との外部提携機能の開発、
制度改正に伴う改修、社内システムの改善など様々な開発に日々携わっています。
今回は食べログメールへのワンクリックでの登録解除導入についてご紹介します。
送信者ガイドライン
ワンクリックでの登録解除の対応方針に関しては Google のメール送信者のガイドラインに記載があり、 1 日に 5,000 通以上のメール配信を実施している送信者については、以下の対応を実施する必要があります。
- 送信ドメインの認証
- 迷惑メール率の監視
- ワンクリックでの登録解除
送信ドメインの認証
送信元ドメインに SPF、DKIM、DMARC というメール認証をそれぞれ設定する必要があります。
SPF（Sender Policy Framework）
メール送信元が該当ドメインに許可されているサーバーなのかを確認する仕組みです。
DNS に SPF レコードを追加し、送信元として許可された IP アドレスをリストアップすることで、 なりすましメールを防止できます。DKIM（DomainKeys Identified Mail）
メールがドメイン所有者によって送信されたことを確認する仕組みです。
メールにデジタル署名を追加し、DNS に公開鍵を配置することで、中身の改ざんを防ぎます。DMARC（Domain-based Message Authentication, Reporting & Conformance）
上記 SPF と DKIM の認証に失敗したメールの処理方法を指示する仕組みです。
DNS に DMARC レコードを追加し、ポリシーを定義することで、 認証に失敗したメールの適切な処理及びドメイン所有者へのレポート提供が可能になるため、 送信者のドメインを利用してなりすましを試みているメールを監視できます。
迷惑メール率の監視
Postmaster Toolsにて迷惑メール率を定期的に監視する必要があります。
迷惑メール率が 0.1% 未満に維持するのが理想的ですが、0.3%以上を超えた状態が続くと、迷惑メールとしてフィルタリングされる確率が上がるようです。
ワンクリックでの登録解除
ワンクリックでの登録解除は文字通りワンクリックでメールの配信停止が可能な機能です。
ワンクリックでの登録解除に対応することで、ユーザー側は送信元のサービスにログインせず、
各メールアプリから簡単に不要なメールを配信停止にできます。
配信停止操作が簡潔になることで、受信者に迷惑メールとして報告される確率も下がるので、
受信者、送信者の双方にメリットがあります。
また、対応が必要なのはプロモーションメールのみであり、トランザクションメールは対象外となります。
すべてのメールに対してワンクリックでの登録解除が求められるのですか？
いいえ。ワンクリックでの登録解除が必要なのは、マーケティングやプロモーションのメールのみです。
トランザクション メールはこの要件から除外されます。トランザクション メールの例としては、パスワードの再設定、予約の確認、フォーム送信の確認などがあります。
私たちのチームでは、こちらのワンクリックでの登録解除の対応を担当することになりました。
設計について
対応方針
ワンクリックでの登録解除はRFC 8058によって標準化されており、 送信ヘッダーに以下の拡張ヘッダーを設定することで実現できます。
List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: <https://example.com/unsubscribe>
List-Unsubscribe 内に配信停止リクエスト用の URL を埋め込むことで、 受信者のメールアプリ上で対象メールに配信停止ボタンが表示され、 受信者が配信停止操作をすることで、配信停止の POST リクエストが実行されます。
配信停止リクエストについて
List-Unsubscribe に設定する配信停止リクエストについては、以下の 2 パターンの案を検討しました。
案 1:自前実装
処理の流れ
- 食べログのメールは、外部のメール配信システム経由で送信されています。
メール配信システムにメール送信をリクエストする際、配信停止リクエストの URL を埋め込んだ List-Unsubscribe ヘッダーを含めたリクエストを送信します。
クエリパラメータには、対象ユーザーを特定できる固有値が含まれます。 - 食べログからのリクエスト通りに外部のメール配信システム経由でユーザーにメールが届きます。
- ユーザーがメールを開くとメールアプリ独自の配信停止 UI が表示されるので、ユーザーが UI に従って配信停止操作をします。
- メールアプリから食べログへ配信停止リクエストが送信されます。
- 配信停止リクエストを受けて、食べログ DB の対象ユーザーのメール配信設定を配信停止に更新します。
- 次回のメール配信から該当ユーザーが除外されます。
メリット
- 外部システムに依存せず、要件に合わせた独自のカスタマイズをしやすい
- 即時で DB のデータ及び画面に反映される
デメリット
- List-Unsubscribe の設定及び配信停止リクエストの実装を独自で行う必要がある
- 短期間で大量リクエストがあった場合に、負荷がかかる場合がある
案 2:外部のメール配信システムの機能を利用
処理の流れ
- 事前に外部のメール配信システム上で対象メールにワンクリックでの登録解除の設定をします。
- 食べログからメール配信システムにメール送信をリクエストします。
- メール配信システム経由でメール配信を実施することで、 対象メールの List-Unsubscribe ヘッダーに配信停止リクエストの URL が自動設定されます。
- ユーザーがメールを開くとメールアプリ独自の配信停止 UI が表示されるので、ユーザーが UI に従って配信停止操作をします。
- メールアプリから配信停止リクエストが送信されます。
- メール配信システムが配信停止リクエストを受けて、リクエストがあったユーザーを次回以降の配信対象から除外します。
- 食べログ側の DB に保存しているメール配信状況のデータと差分が生じるため、定期バッチでメール配信システムに配信停止ユーザーを取得するリクエストを送ります。
- メール配信システムから配信停止ユーザーのリストが返却されます。
- 食べログ DB の対象ユーザーのメール配信設定を配信停止に更新します。
- 次回のメール配信から該当ユーザーが除外されます。
メリット
- List-Unsubscribe の設定及び配信停止リクエストの実装が不要なので、導入しやすい
- 配信停止リクエスト先は外部システムのため、大量リクエストによる負荷の影響が少ない
デメリット
- 機能やデザインなどのカスタマイズに制約がある
- 同期バッチを実装する必要がある
- 同期バッチの実行頻度次第で DB 及び画面との同期に遅延が生じる
比較と結論
それぞれのメリットデメリットを踏まえて、全体工数自体はあまり変わらない点、 機能の性質上システムに負荷がかかるような大量リクエストを短期間で送信される可能性は低い点、 独自のカスタマイズを柔軟に行いたい点から今回は案 1 の自前実装を選択しました。
グルーピングによる一括配信停止
メール送信者のガイドラインの内容や各メールの重要度なども踏まえた上で、 今回ワンクリックでの登録解除を導入することになったのは以下 8 つのメールです。
- いいね通知
- お店からの返信通知
- コメント登録通知
- フォロー通知
- メッセージ受信通知
- レビュアーページ訪問者通知
- お知らせメール
- 口コミお知らせメール
それぞれのメールで個別に配信停止処理することも可能でしたが、その場合、似たようなメールを一括で配信停止したいユーザーからすると、停止操作を何度も実施する必要が出てきてしまいます。
かといって全てのメールを一括で配信停止してしまうと、ユーザーが意図しないメールを停止させてしまう恐れがあります。
そこでその折衷案として、メールの属性からグルーピングして、グループ単位で一括配信停止する形をエンジニアから提案しました。 企画チームや CS チームとも会話し、以下の形でグルーピングを実施することになりました。
| メールタイトル | 配信停止グループ | 新しい送信元メールアドレス |
|---|---|---|
| いいね通知 | レビュアー系の通知 | info-noreply@tabelog.com |
| お店からの返信通知 | ||
| コメント登録通知 | ||
| フォロー通知 | ||
| メッセージ受信通知 | ||
| レビュアーページ訪問者通知 | ||
| お知らせメール | ||
| 新着口コミメール | 口コミ通知 | review-noreply@tabelog.com |
また、配信停止グループの各送信元メールアドレスについては、新しいメールアドレスに差し替えました。
ユーザーが配信停止を実施すると、対象の送信元メールアドレスを迷惑メールとして設定する UI が表示されます。
仮に送信元メールアドレスを区別しないままワンクリックでの登録解除を導入すると、
送信元メールアドレス単位で迷惑メール設定された場合、他の配信停止グループのメールや重要なトランザクションメールなどの
他のメールまで正常に受信できなくなってしまう恐れがあります。
送信者ガイドラインにもメール種別に応じて、送信元メールアドレスを分けるよう記載があり、 そちらにも沿った形になります。
同じカテゴリのメールでは、From: に同じメールアドレスを指定してください。 たとえば、solarmora.com というドメインからのメールの From: アドレスは以下のように指定します。
- 顧客に送る領収書のメール: sales@solarmora.com
- プロモーション メール: deals@solarmora.com
- アカウントに関する通知メール: alert@solarmora.com
動作検証及びリリース
開発環境での検証
開発環境のメールを受信可能なメールアプリがワンクリックでの登録解除に未対応だったため、 開発環境上で配信停止 UI の表示及び動作確認を実施できませんでした。
そのため、開発環境上のテストは以下 2 点にとどめました。
- 送信メールのメールヘッダーに、List-Unsubscribe が適切に設定されていること
- 配信停止 URL に POST リクエストをした際、正常に配信停止が実行されること
本番検証及びリリース
開発環境では一部の動作検証ができなかったため、本番検証も交えて段階的にリリースをすることにしました。
フェーズ 1 のリリース
配信停止リクエスト及び一部メールの List-Unsubscribe 設定までをフェーズ 1 のスコープとし、 特定のメールにのみワンクリックでの登録解除を適用しました。
本番検証
適用したメールを社内ユーザー向けに実際に配信し、 ワンクリックでの登録解除に対応済みの Gmail 上で配信停止 UI の表示及び動作確認を実施しました。
フェーズ 2 のリリース
本番検証にて配信停止 UI の確認も取れたので、残りのメールの List-Unsubscribe 設定をリリースし、 全ての対象メールにワンクリックでの登録解除を適用しました。
リリース後、ユーザーからのリクエストが問題なく処理されているかをしばらく監視し、特に異常は見られなかったため、対応完了としました。
さいごに
食べログメールにワンクリックでの登録解除を導入した事例紹介でした。
ワンクリックでの登録解除を導入することは、メールの送信者・受信者双方にメリットをもたらします。 今後プロモーションメールを導入する際は、対応が必要になるのでご注意下さい。
私たちの取り組みが、他の組織の皆さんにも何かの参考になれば幸いです。
最後までお読みいただきありがとうございました。
食べログでは一緒に働いてくれる仲間を募集しております。
興味を持っていただけたら是非採用ページをご覧ください。
本記事の画像には、Apache License Version 2.0で配布されているアイコンが含まれています。
