Webhook
メールマーケティングと配信率をマスターするために必要なすべての用語を、分かりやすく解説します。
メール技術
定義
Webhookは、別のシステムで特定のイベントが発生したときにアプリケーションにリアルタイムでデータを配信するHTTPコールバックです。更新をポーリングする従来のAPIとは異なり、Webhookはトリガーされると即座にエンドポイントにデータをプッシュし、配信、バウンス、開封、クリックなどのメールイベントの即時通知を可能にします。
一般的な使用例
バウンス通知:送信者レピュテーションを保護するためにハードバウンスを即座にリストから削除
開封とクリックの追跡:リアルタイムのエンゲージメントスコアリングと営業アラートをトリガー
配信停止処理:すべてのシステムで購読者ステータスを自動更新
スパム苦情処理:到達率の損害を避けるために苦情者を即座に抑制
配信確認:トランザクションメールの成功した受信トレイ配置を確認
メール検証結果:大規模バッチジョブの非同期検証結果を受信
リストハイジーン自動化:繰り返しソフトバウンスするアドレスをレビュー用にフラグ立て
マーケティングオートメーショントリガー:特定のメールインタラクションに基づいてナーチャリングシーケンスを開始
Webhookが重要な理由
Webhookは、継続的なポーリングの必要性を排除することで、メールデータとのやり取り方法を変革します。新しいイベントを確認するためにAPIを繰り返しクエリする代わりに(リソースを浪費し遅延を生じさせる)、Webhookは情報が利用可能になった瞬間に配信します。このリアルタイム機能は、次のキャンペーンの前にバウンスしたアドレスを削除したり、受信者のエンゲージメントに基づいてフォローアップシーケンスをトリガーしたりするなど、タイムセンシティブな操作に不可欠です。 メールマーケターや開発者にとって、Webhookは以前は不可能だった高度な自動化を可能にします。誰かがメール内のリンクをクリックすると、Webhookは即座にCRMを更新したり、営業通知をトリガーしたり、ターゲットを絞ったナーチャリングシーケンスに連絡先を登録したりできます。ユーザー行動へのこの即時応答は、エンゲージメントとコンバージョン率を劇的に向上させます。 Webhookはインフラストラクチャコストと複雑さも軽減します。ポーリングベースのアプローチは、何も変更がない場合でも、継続的に更新を確認するための専用リソースを必要とします。Webhookでは、イベントが実際に発生した場合にのみデータを処理するため、システムがより効率的でスケーラブルになります。このイベント駆動型アーキテクチャは、現代のメールインフラストラクチャの標準的なプラクティスです。
Webhookの仕組み
Webhookは、シンプルで強力なメカニズムで動作します。事前定義されたイベントが発生すると、ソースシステムが指定したURLにHTTP POSTリクエストを送信します。Webhookエンドポイントと呼ばれるこのURLは、イベントに関する詳細情報を含むJSONペイロードを受信します。メールシステムの場合、メールがバウンスしたり、開封されたり、その他の追跡されたイベントがトリガーされた瞬間にアプリケーションに通知されます。 プロセスは、メールサービスプロバイダーにエンドポイントURLを登録し、受信したいイベントを選択することから始まります。購読者がメールを開封すると、ESPはこのアクションを検出し、イベントタイプ、タイムスタンプ、受信者メール、その他の関連メタデータを含むペイロードを即座に構築します。このペイロードは、HTTPS POSTリクエストを介してエンドポイントに送信されます。 サーバーはHTTP 200ステータスコードを返すことで受信を確認する必要があります。Webhookの配信に失敗した場合(サーバーダウンタイムやネットワーク問題)、ほとんどのプロバイダーは指数バックオフによるリトライロジックを実装しています。これにより、一時的な障害が発生しても、最終的にすべてのイベントデータを受信できます。プロセス全体は通常ミリ秒で完了し、メールパフォーマンスのほぼ瞬時の可視性を提供します。
ベストプラクティス
Webhook署名を検証し、リクエストが攻撃者ではなくESPからのものであることを確認する
HTTP 200で即座に応答し、ペイロードを非同期で処理する
データの破損なく重複配信を適切に処理するために冪等性を実装する
トラフィックスパイク時に受信Webhookをバッファリングするためにメッセージキューを使用する
処理前にデバッグと監査目的ですべての受信ペイロードをログに記録する
Webhookエンドポイントの可用性とエラー率の監視とアラートを設定する
重複イベントIDを確認して無視することでリトライを適切に処理する
HTTPSエンドポイントのみを使用し、Webhookシークレットを定期的にローテーションする
よくある質問
WebhookとAPIの違いは何ですか?
APIは能動的にデータをリクエストする必要があります(プルモデル)が、Webhookはイベントが発生したときに自動的にデータを送信します(プッシュモデル)。APIでは、サーバーに定期的に「新しいイベントはありますか?」とポーリングします。Webhookでは、何かが起こったときにサーバーが即座に通知します。Webhookはリアルタイム通知に効率的で、APIはオンデマンドのデータ取得に適しています。
Webhookエンドポイントをどのようにセキュアにしますか?
複数のセキュリティレイヤーを実装してください。HTTPSのみを使用し、ESPが提供するシークレットキーを使用してWebhook署名を検証し、プロバイダーが公開している場合はソースIPアドレスを確認し、悪用を防ぐためにレート制限を実装します。ほとんどのメールサービスは、ペイロードを処理する前にシークレットに対して検証すべき署名ヘッダー(X-Webhook-Signatureなど)を含んでいます。
Webhookエンドポイントがダウンした場合はどうなりますか?
ほとんどのメールサービスプロバイダーは、指数バックオフによる自動リトライロジックを実装しています。エンドポイントがエラーを返すかタイムアウトした場合、プロバイダーは数時間または数日にわたって複数回配信を再試行します。ただし、リトライを使い果たした後、イベントが失われる可能性があります。データ損失を防ぐために、エンドポイントの高可用性を確保し、バッファとしてマネージドWebhookサービスまたはメッセージキューの使用を検討してください。
エンドポイントはWebhookにどれくらい早く応答すべきですか?
エンドポイントは、タイムアウトエラーを防ぐために5〜10秒以内にHTTP 200レスポンスを返す必要があります。ベストプラクティスは、受信を即座に確認し、バックグラウンドジョブキューを使用してペイロードを非同期で処理することです。これにより、処理の遅延がWebhook失敗を引き起こすのを防ぎ、システムがボトルネックなく大量の同時イベントを処理できるようになります。
関連用語
関連記事
メール検証の準備はできましたか?
BillionVerify を今すぐ使用して、99.9% の精度でメールを検証しましょう。
クレジットカード不要 · 毎日 100 回以上の無料検証 · 5 分で設定完了