クーポン データ整理の観点
クーポンの仕組みを考えるときは、いきなりテーブル定義に入るより、まず「何を区別して持つ必要があるか」を整理するほうが進めやすいです。
まず分けて考えたい情報
| まとまり | 役割 |
|---|---|
| クーポンそのものの定義 | 何の施策か、どういう特典か |
| 配信や表示の条件 | 誰に、いつ見せるか・渡すか |
| ユーザーごとの保有状況 | 誰が持っているか、使えるか |
| 利用や失効の履歴 | いつ何が起きたか |
flowchart TD
A["クーポン定義\n何の施策か・どういう特典か"] --> B["配信・表示条件\n誰に・いつ見せるか"]
A --> C["ユーザー保有状況\n誰が持っているか・使えるか"]
C --> D["利用・失効履歴\nいつ何が起きたか"]なぜ分けるのか
この4つを分けて考えると、次のような問いに答えやすくなります。
- 施策自体を止めたいのか
- あるユーザーだけ使えなくしたいのか
- 配信条件だけ変えたいのか
- 実績を後から確認したいのか
逆に、これらが混ざると、誤配信や問い合わせ対応のときに切り分けしにくくなります。
ユーザー単位で持ちたい情報
公開向けの観点としては、少なくとも次のような情報を持つかどうかを整理しておくと十分です。
- 誰に紐づくか
- いつ付与・表示されたか
- まだ使えるか
- 何回使ったか
- いつ失効したか
- なぜ無効になったか
履歴をどこまで残すか
施策によって、必要な履歴の粒度は変わります。
- 1回限りのクーポンなら、状態管理だけで足りる場合がある
- 複数回利用や問い合わせ対応が重要なら、利用履歴が必要になる
- 分析を重視するなら、表示・配信・利用を分けて見たくなる
このため、公開向けには「この形が正解」と固定するより、どの粒度で実績を見たいか から考えるほうが現実的です。
実案件で詰めること
最終的には、次のような条件で持ち方が変わります。
- 利用回数制限の有無
- 再配信の有無
- 通知対象として扱うか
- 店舗別集計が必要か
- 外部システムとの連携有無
そのため、このページは実装用のデータモデルではなく、要件定義の前段で認識をそろえるための整理に留めています。