再入荷通知（Back in Stock）機能の設計と管理UI

このテーマで解決したいこと

再入荷通知機能は「入荷したらメールを送る」だけでは不十分です。
実運用では、通知対象の重複、通知タイミングの偏り、配信失敗時の再送、管理画面の使いにくさがボトルネックになります。

このあたり、運用を始めるとすぐに悩みやすいポイントですよね。

この記事では、在庫復活の検知・通知キュー・配信制御・管理UI・効果測定までを、実装可能な粒度で整理します。
「まず何から決めるべきか」が見えるように構成しています。

先に結論

Back in Stock を安定運用するには、次の4層で設計するのが有効です。

1. 在庫状態の真実（source of truth）を定義する
2. 通知対象をキュー化して重複を防ぐ
3. 配信をレート制御し、失敗時は段階的にリトライする
4. 管理UIで「誰に・いつ・何を」通知したかを追跡できるようにする

推奨アーキテクチャ

シリーズ記事（詳細解説）

設計全体を3つのレイヤーに分けて詳しく解説しています。
実装時は上から順に読むのがおすすめです。

データ設計の要点

最低限、次のエンティティを分離して持つと運用しやすくなります。
最初に分けておくと、あとから要件が増えても破綻しにくいです。

• subscriptions: 通知希望登録（メール/同意状態/希望チャネル）
• stock_snapshots: 在庫の観測値（バリアント単位）
• notification_jobs: 実行キュー（pending/processing/sent/failed）
• notification_logs: 実行結果ログ（プロバイダ応答、エラー分類）

重要なのは、登録情報（subscriptions）と実行キュー（jobs）を分けることです。
これにより、在庫復活時点の配信対象をスナップショット化でき、後から購読解除された場合の扱いも明確になります。

在庫復活判定（0→1以上）の実装ポイント

単純な「在庫 > 0」判定だけだと多重通知が発生しがちです。
以下を組み合わせると安定します。

• 前回在庫と今回在庫の差分を比較し、0→1以上のみ対象化
• 通知後のクールダウン期間を持たせる（例: 同一バリアント24時間）
• 在庫が短時間で揺れる商品はデバウンス（数分遅延）で誤検知を抑制

配信制御と失敗時リカバリー

レート制御

一度に大量通知を送ると、メールプロバイダ制限やスパム評価に引っかかるリスクがあります。
ワーカー側で「秒間上限」「ドメイン別上限」「優先度（wishlist登録日時）」を持つ設計が有効です。

リトライ戦略

• 一時障害（429/timeout）は指数バックオフで再送
• 恒久エラー（アドレス不正等）は即座に failed-permanent
• リトライ上限超過は dead-letter に隔離し、UIから手動再実行可能にする

管理UIで見るべき機能

現場で使われるUIは、次の観点を最初から入れておくと強いです。

1. キュー一覧: pending/processing/failed を即時把握
2. 通知詳細: 対象商品、対象ユーザー、失敗理由、再送履歴
3. 配信ルール設定: クールダウン、送信時間帯、上限値
4. テンプレート管理: チャネル別文面、差し込み変数、プレビュー
5. KPIダッシュボード: 通知数、開封、クリック、購入貢献

現時点の実装範囲について

本リポジトリでは、Back in Stockの通知基盤・管理UI・KPI可視化はまだ実装されていません。
本記事群は、実装前に設計意図を共有するためのドキュメントです。

KPIの具体値や成果表現は、実装後に計測基盤を整えた段階で追記する前提としています。
この線引きを明確にしておくと、読み手にも誤解が生まれにくいですよね。

セキュリティ・コンプライアンス

• 二重オプトイン（地域要件に応じて）
• 購読解除リンクの常時提供
• 個人情報の保存期間ポリシー
• 監査ログの保持（誰がいつ再送したか）

特に管理UIでは、顧客連絡先のマスキングと権限制御（閲覧/再送/設定変更）を分離してください。

まとめ

再入荷通知は、ECサイトのCV改善に直結する一方で、設計が甘いと「誤通知」「再送不能」「成果不明」になりやすい機能です。
在庫検知・キュー処理・管理UI・KPIの4点をセットで設計すると、運用チームが安心して改善を回せる仕組みになります。

派手さはありませんが、こうした土台づくりが長く効いてきます。