本物のユーザーをブロックせずに無料トライアルの悪用を防ぐ方法
新しいアカウントで無料トライアルをやり直す人がいる理由、それらのアカウントを結びつけるシグナル、そして正直なユーザーにはカード不要のトライアルを残しつつ繰り返しを止める判定フロー。
無料トライアル悪用の実際の姿
無料トライアルの悪用とは、同じ人が新しいアカウントで何度もトライアルを始め、いつまでも支払わずに済ませることです。攻撃のようにはほとんど見えません。トラフィックの急増も盗まれたカードもありません。目に入るのは、一つずつ見ればごく普通のアカウントが途切れなく続く様子です。
- 新しい使い捨てメール。何万もある使い捨てドメインの一つから取った一時アドレスで、アカウント確認に一度使ったきりです。
- 同じGmailの別表記。
jane.doe@gmail.com、janedoe+2@gmail.com、j.a.n.e.doe@gmail.comはすべて同じ受信箱に届きます。 - 同じノートPCと同じ自宅回線。ブラウザ、画面、フォント、IPアドレスが、1か月前に作られたアカウントとまったく同じです。
これらのアカウントはすべてメール確認を通過するので、「メールアドレスを確認してください」だけでは何の効果もありません。登録時に答えるべき問いは「このメールは本物か?」ではなく「この人を前に見たことがあるか?」です。
よくある対策が逆効果になる理由
すべてのトライアルでカード登録を必須にする
カード登録の壁は繰り返しトライアルの大半を止めますが、まず製品を試したいだけの正直な訪問者の多くも止めてしまいます。悪用の問題をコンバージョンの問題に置き換えているだけです。しかもカードは複数のアカウントで使い回せるので、カードだけでは新しい人である証明にもなりません。
メールのドメインだけでブロックする
使い捨てドメインのブロックリストが止められるのは、最も手を抜いた悪用者だけです。Gmailのエイリアスはまったく見抜けず、コードにコピーしたリストは新しい使い捨てドメインが次々に現れるためすぐに古くなります。詳しくは登録時に使い捨てメールをブロックする方法で解説しています。
IPアドレスでブロックする
IPブロックは最も大雑把な手段です。オフィス、大学、携帯キャリアはまるごとアドレスを共有しており、本気の悪用者は数秒でネットワークを切り替えます。IPはスコアの中では有用なシグナルですが、それだけで拒否する理由にはなりません。
新しいアカウントを古いアカウントと結びつけるシグナル
一つの厳格なルールではなく、複数の弱いシグナルを見て足し合わせましょう。どれも単独で判定すべきではありませんが、組み合わせれば繰り返しトライアルは一目瞭然になります。
| シグナル | 検出できるもの | 誤検知のリスク |
|---|---|---|
| 正規化した受信箱がすでに存在する | 既存アカウントのGmailのドット・プラス違い | 低:文字どおり同じ受信箱 |
| 使い捨てドメイン | 1回の登録のために作られた使い捨て受信箱 | 低(リストが最新なら) |
| ドメインがメールを受信できない | タイプミスや架空のドメイン | 低 |
| 既存アカウントと同じデバイス | 同じブラウザが2つ目のアカウントを作成 | 中:家族や共用パソコン |
| 今日同じIPから多数の登録 | 一つのネットワークからの集中 | 中:オフィス、キャンパス、キャリアNAT |
| データセンターまたはTorのアドレス | サーバー上のスクリプト、匿名化された通信 | 中:一部のVPN利用者 |
傾向ははっきりしています。誤検知リスクの低いシグナルには大きな重みを与えてよく、正直なユーザーにも当たるシグナルはスコアを少し上げる程度にとどめるべきです。
正直なユーザーを困らせない判定フロー
私たちが見てきた中で最も効果的な設定は、ほとんどブロックしません。ほぼ全員にカード不要のトライアルを提供し、スコアが高いときだけ手間を増やします。
- サーバーで登録をスコアリングする(フォーム送信後、トライアル開始前)。
- 許可(低スコア):通常のトライアルを開始します。大多数はここに入るはずです。
- 確認(中程度のスコア):トライアルは開始しつつ、本物のユーザーより悪用者にとってコストの高いもの——カード、電話番号、または確認までの小さな枠——を求めます。
- ブロック(高スコア):トライアルを開始しません。行き止まりではなく有料プランや問い合わせ先を案内しましょう。スコアは確率であって証拠ではないからです。
目安:姉妹とノートPCを共有しているだけの人を、それだけを理由にブロックしてはいけません。共用デバイスのシグナルは、受信箱の一致のようなより強いシグナルと組み合わせたときだけ積み上げましょう。
登録フローへの組み込み方
必要なのは2つ、登録ページでブラウザを認識する仕組みと、トライアル付与前のサーバー側チェックです。Attrelixなら、scriptタグ1つとAPI呼び出し1回で済みます。
<!-- 登録ページ --> <script src="https://attrelix.com/v1.js" data-key="pk_live_…" async></script>
# サーバー、トライアル開始前(Python) r = requests.post("https://attrelix.com/v1/check", timeout=3, headers={"Authorization": f"Bearer {SECRET}"}, json={"email": email, "ip": ip, "visitor": form["attrelix_visitor"]}) decision = r.json().get("decision", "allow") if r.ok else "allow" if decision == "allow": start_trial(user) elif decision == "review": start_trial(user, require_card=True) else: offer_paid_plan(user)
フォールバックに注目してください。チェックがタイムアウトしたらユーザーを通します。不正対策のチェックが登録停止の原因になってはいけません。
厳しくする前に計測する
まずは観察のみのモードで始めましょう。1〜2週間、何もせずに判定だけを記録し、確認に回っていたはずのアカウントを見てみます。ほとんどが繰り返しトライアルなら対応を有効にします。正直なユーザーが含まれていたら、しきい値を上げるか、その原因になったシグナルの重みを下げます。他人のデフォルト値ではなく、自社のデータで調整しましょう。
まとめ
- 繰り返しトライアルはアカウント単位では問題なく見えます。過去のアカウントとのつながりを探しましょう。
- メールを正規化し、使い捨てドメインを確認し、デバイスを認識します。
- シグナルをスコアに足し合わせ、単独で判定するのは強いシグナルだけにします。
- 確認ではブロックではなく手間を増やし、障害時は必ず通します。