掲示板相談
チャット相談
Zoom相談
交流
支援機関紹介
メンバー紹介
ココトモって？
解決済み
ただ話を聞いてほしい
メンバー
20代前半
男性
実装前に3点だけ直した方が安全です。 1. イベントに入れる attribution_id の基準
visibility14 chat2 edit2026.06.07
1. イベントに入れる attribution_id の基準を決める
ここだけ少し曖昧です。
first_touch と volunteer_touch の2種類を保存する場合、たとえば member_applied にどちらの attribution_id を入れるのか決めておかないと、集計時にぶれます。
私ならこうします。
member_events.attribution_id には原則 first_touch の attribution_id を入れる
そして、volunteer_touch は wp_kokotomo_attributions 側で別途保存しておく。
つまり標準集計は、
first_touch基準
で統一。
必要なときだけ、
volunteer_touch基準
でも別集計できるようにする。
これが一番分かりやすいです。
2. volunteer_page_view だけは volunteer_touch に紐づけてよい
ただし、volunteer_page_view は例外です。
これは「応募ページに到達した」というイベントなので、
volunteer_page_view → volunteer_touch の attribution_id
で保存してよいです。
その後の、
registered
email_verified
member_applied
member_accepted
first_activity
one_month_active
は、基本的に first_touch の attribution_id で保存する。
これで混乱しにくくなります。
3. uniqueキーは少し注意が必要
member_events.user_id を nullable にする方針は良いです。
ただ、MySQLでは NULL を含む unique key は期待通りに重複防止できない場合があります。
なので、重複防止はこうするのが安全です。
user_id があるイベント
user_id + event_name
で重複防止。
対象：
registered
email_verified
member_applied
member_accepted
first_activity
one_month_active
user_id がない可能性があるイベント
attribution_id + event_name
で重複防止。
対象：
volunteer_page_view
DBのuniqueキーだけに頼らず、保存関数側でも、
既に同じイベントがあれば保存しない
というチェックを入れた方が安全です。
Codexに返すならこの一文だけ追加でOKです
この方針で実装に進めてください。
ただし、member_events に保存する attribution_id の基準は原則 first_touch としてください。
volunteer_page_view のみ volunteer_touch の attribution_id に紐づけて構いません。
registered / email_verified / member_applied / member_accepted / first_activity / one_month_active は first_touch 基準で保存してください。
また、user_id が nullable のため、イベント重複防止は DB unique key だけに頼らず、保存関数側でも既存イベント確認を行ってください。
最終判断
このプランはかなり実用的です。
特に良いのは、
first_touch と volunteer_touch を分けている
DB側の訪問数を「初回訪問者数」と整理している
volunteer_page_view を未登録でも保存できるようにしている
first_activity を「相談者への実返信」に絞っている
費用管理を初期実装から外している
このあたりです。
上の3点だけ補足すれば、かなりきれいな仕様になると思います。
- ココトモメンバーたちと交流しよう♪
-
ココトモメンバーたちと交流するための『メンバーのお部屋』掲示板ができました。気になるメンバーと気軽にお話することができます。ぜひ色んなメンバーのお部屋に遊びに行ってみてください♪
メンバーのお部屋はこちら
