Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ポイント管理システムの改善について

pistaman
November 02, 2022

 ポイント管理システムの改善について

2022/10/13に行われたSTORESとMGReの共同勉強会で登壇した際の資料
https://hey.connpass.com/event/261576/

pistaman

November 02, 2022
Tweet

Other Decks in Programming

Transcript

  1. 自己紹介 2 • 西川輝 • バックエンドエンジニア • STORES 株式会社 ◦

    EC(2019/04 ~ 2019/11) ◦ レジ(2019/11 ~ 2022/05) ◦ ブランドアプリ(2022/05 ~) • STORES チョットワカル
  2. STORES ブランドアプリ の概要 6 STORES ブランドアプリ でできること - 顧客管理・利用分析 -

    会員属性 - 性別、年齢、誕生日など - ポイント数 - 来店状況 - POSレジ、ECサイト連携 - マーケティングオートメーション - Push通知配信 - クーポン機能
  3. STORES ブランドアプリ の機能 12 STORES ブランドアプリ でできること - 顧客管理・利用分析 -

    会員属性 - 性別、年齢、誕生日など - ポイント数 - 来店状況 - POSレジ、ECサイト連携 - マーケティングオートメーション - Push通知配信 - クーポン機能
  4. STORES ブランドアプリ の機能 13 STORES ブランドアプリ でできること - 顧客管理・利用分析 -

    会員属性 - 性別、年齢、誕生日など - ポイント数-> チェックイン - 来店状況-> チェックイン - POSレジ、ECサイト連携-> チェックイン - マーケティングオートメーション - Push通知配信 - クーポン機能-> チェックイン
  5. チェックインとは 機能追加後... - 来店情報 - 来店日 - 利用店舗 - 獲得スタンプ数

    - ポイントシステムの導入 new - ポイントの取得、利用、失効などの管理が必要に - イベントログの保存 new - アプリダウンロード - SNS共有 - POSレジ、ECサイト連携 new - 購入金額 - 購入商品ID 16
  6. チェックインとは チェックインの課題点 - イベントログや外部連携情報などが追加されたことにより、分析クエリが複雑化 - パフォーマンス悪化 - データ量も増大 - 各カラムの状態によってデータの意味が変わる

    - キャッチアップコストが高い - 知らずに改修すると分析結果が変わってしまう - ポイントの履歴が追えない - チェックインテーブルにはポイント取得履歴しか残っていない 17
  7. チェックインとは チェックインの課題点 - イベントログや外部連携情報などが追加されたことにより、検索条件が複雑化 - パフォーマンス悪化 - データ量も増大 - 各カラムの状態によってデータの意味が変わる

    - キャッチアップコストが高い - 知らずに改修すると分析結果が変わってしまう - ポイントの履歴が追えない - チェックインテーブルにはポイント取得履歴しか残っていない 18
  8. ポイントの履歴が追えない 20 - ポイントの履歴とは - 取得 -> 購入、来店時のポイント付与 - 利用

    -> クーポン利用時に1ポイント1円等で会計から割引 - 失効 -> 退会、期限切れ - チェックインテーブルにはポイント取得情報しか残っていない - アプリケーション上で複数テーブルの情報を組み合わせて履歴を算出 - 退会の場合は物理削除しているため履歴が残らない
  9. ポイントの履歴が追えない 21 日付 ポイント 2022-10-01 14:00 5pt 2022-10-02 16:00 10pt

    checkins(取得) 日付 ポイント 2022-10-09 18:00 10pt .. .. coupons(利用) 有効期間 7 .. shop_settings(失効)
  10. ポイントの履歴が追えない 22 日付 ポイント 失効期限 2022-10-01 14:00 +5pt(取得) 2022-10-09 00:00

    2022-10-02 16:00 +10pt(取得) 2022-10-10 00:00 2022-10-09 00:00 -5pt(失効) - 2022-10-09 18:00 -10pt(利用) - 日付 ポイント 2022-10-01 14:00 5pt 2022-10-02 16:00 10pt checkins(取得) 日付 ポイント 2022-10-09 18:00 10pt .. .. coupons(利用) 有効期間 7 .. shop_settings(失効) アプリケーション側で全データをソートして計算
  11. ポイント管理の仕組みを改善 24 - ポイント履歴用のテーブルを作成 - アプリケーションで作っていたデータをそのままDBへ - 取得、利用、失効イベントごとにレコードを追加 日付 ポイント

    失効期限 2022-10-01 14:00 +5pt(取得) 2022-10-09 00:00 2022-10-02 16:00 +10pt(取得) 2022-10-10 00:00 2022-10-09 00:00 -5pt(失効) - 2022-10-09 18:00 -10pt(利用) - point_transactions
  12. ポイント管理の仕組みを改善 25 改善の結果 - ポイントの履歴が残るように - パフォーマンスが向上 - DB側で有効ポイントの計算が可能に -

    チェックインからポイントに関するユースケースを剥がせた - 責務が明確に - 可読性が向上
  13. まとめ 26 - 目的の違うものを一つにまとめない - 機能追加をする際は立ち止まって考えてみる - アプリケーションの設計でもDB設計でも同じ - データ量を意識する

    - 今後どのようなペースで増加するのか - マスターデータなのかトランザクションデータなのか - update より insert - 履歴が残らなくて問題ないか - 競合が発生しないか
  14. 27