SendGrid Event Webhook は、送ったメールが「その後どうなったか」を SendGrid 側からアプリへ通知してくれる仕組みだ。配信成功・開封・クリック・バウンス・スパム報告・購読解除といったイベントが、発生するたびに指定した URL へ POST される。

なぜポーリングではなくこれなのか

到達状況を知りたいだけなら定期的に API を叩いて調べることもできるが、メールの結果は送信から数時間〜数日かけて散発的に発生する。Webhook なら発生時に即座に受け取れるため、バウンス率の急上昇や大量のスパム報告といった「送信レピュテーションが崩れ始めた」サインをリアルタイムで検知できる。

設計上で必ず押さえる点

  • イベントは順不同・重複ありで届く。タイムスタンプで並べ替え、イベント ID で冪等に処理する設計が前提
  • 受信エンドポイントが遅いと SendGrid 側がリトライし、負荷が増える。受け取ったらすぐ 2xx を返してキューに流す
  • 署名検証（Signed Event Webhook）を有効にしないと、第三者が偽イベントを投げられる

開封・クリック計測の精度の限界

開封トラッキングは透明な 1px 画像の読み込みで判定するため、画像を自動表示しないメールクライアントでは「開いたのに開封イベントが飛ばない」。逆に、メールプロバイダのセキュリティスキャナがリンクや画像を先読みすることで「ユーザーが見ていないのに開封・クリック扱い」になることもある。開封率を KPI に据えるなら、これは絶対値ではなく傾向を見る指標だと割り切る必要がある。バウンスや配信成否のような確定的なイベントと、開封・クリックのような推定値のイベントは、扱いを分けて考えると判断を誤りにくい。

向き・不向き

メール到達率の継続モニタリングを自前で持ちたい場合に強い。一方、当然ながら SendGrid 経由で送ったメールのイベントしか流れてこない。複数の送信基盤を横断して可視化したいなら、各基盤の Webhook を個別に受けて統合する設計が必要になる。費用は SendGrid の利用料に含まれ、Webhook 自体に追加課金はない。