一度 web サービスを退会したユーザーが再度入会してきたか調べる
web 開発していると、時々「新規入会会員が、実は以前退会済みで戻ってきたか知りたい」という要望が出る。
理由はいろいろあるが
- 復帰率を取りたい
- 出戻りユーザーに対しての何らかのアクションを行いたい
- 退会済ユーザーに「再度入会したら美味しいことあるよ」みたいなキャンペーンやりたい
など。
では、どう実装すればいいだろうか?
前提条件
- メールアドレスをユーザー ID と紐づけているサービスであること
- RDB は論理削除であること
先に言っておくこと
- このやり方が許されるかの倫理的な話はしない
- 「論理削除絶対ダメ」な人は回れ右した方が良い
まずはユーザー(User)のテーブル構成
| カラム名 | 内容 | 型 | 備考 |
|---|---|---|---|
| userId | ユーザー ID | number | PK (auto increment) |
| mailAddress | メールアドレス | string | Unique |
| passwordHash | パスワードハッシュ | string | not null |
| isActive | 有効なユーザーかどうか | boolean | |
| deletedAt | 削除(退会)日時 | Date | allow null |
要はこんなデータが入っている。
| userId | mailAddress | passwordHash | isActive | deletedAt |
|---|---|---|---|---|
| 1 | userA@example.com | … | true | null |
| 2 | userB@example.com | … | true | null |
| 3 | userC@example.com | … | true | null |
退会時に仕掛けること
例として userId = 1 が退会したとする。
昨今、個人情報保護は当たり前だし、パスワードハッシュを残したままにするのはどうかと、という観点から
- mailAddress
- passwordHash
を論理的に消す、という必要がある。
あと、もちろん
- isActive = false
- deletedAt = now()
もお忘れなく。
パスワードハッシュ
まずはパスワードハッシュについての処理だが、こちらは簡単で「退会したのでパスワードハッシュ自体消す」で問題ない。
シンプルに
UPDATE User SET password_hash = "" WHERE userId = [対象の UserId];
でいい。ユニーク制約もかかってないので。
メールアドレス
メールアドレスをどうするかが今回のキモ。
単純に残す、はダメ
パスワードハッシュを空文字列にしてしまえばログインは出来なくなる。
ただ、
- 個人情報保護的にどうなの
- DB データ流失時のこと、ちゃんと考えてる?
- ユニーク制約があるので、一度退会したユーザーが同じメールアドレスで登録できなくなる
などの問題があるので、ダメとしか言いようがない。
ランダムな文字列で書き換える?
シンプルにいうなら、論理削除するだけならこれで問題ない。
ただし、今回の話である「一度 web サービスを退会したユーザーが再度入会してきたか調べる」ことは出来なくなる。
なぜなら、すでにメールアドレスが失われているから。
ではどうするのか?
結論から言うと
- 冒頭を固定化。
__CANCEL__とか。 - メールアドレス を HMAC-SHA256 通す
- 削除(退会)日時
- ランダムな文字列 を組み合わせて mailAddress を書き換える。
__CANCEL__ + HMAC-SHA256(secret, mailAddress)_[退会日時の unix time(秒)]_[ランダムな16文字]
のように。
もちろん secret は秘匿情報なのをお忘れなく。
新規入会ユーザーが過去に退会していたユーザーなのか調べる方法
まあ、うすうす理解している人もいると思うけど、メールアドレスのハッシュ値を前方一致で検索すればいい。
SELECT COUNT(userId) FROM User WHERE mailAddress like '__CANCEL__[HMAC-SHA256(secret, 新規入会ユーザーのメールアドレス)]%' and isActive = false;
これで 1 以上が返ってきたら、過去入会していたユーザーである。
注意点
以上書いてきた内容は同一トランザクション内で整合性が崩れないように必要なら行ロック取ろう。
また
自サービスの利用規約/プライバシーポリシー/法令に適合するかは確認が必要
なのは当然だ。
上司/顧客から言われたからってホイホイ実装するのはダメ、ぜったい。