2012-02-14 7 views
4

私は会社が新しい訪問者に贈り物に報酬を与えたいウェブサイトビルドに着手しようとしています。贈り物には金銭的価値があり、私はそのサイトが賭けられているか心配です。私は、誰かがギフトの在庫全体を流出させる可能性を減らす方法を模索しています。新しい訪問者のためのウェブサイト報酬のゲームを防ぐ方法

この計画ではFacebookとの統合が求められているため、FB資格情報で認証すると、新しい訪問者が実際に実際の人物であるという確信は少なくなります(FBアカウントの作成をスクリプト化し、それらと一緒には簡単な作業ではありません)。

ただし、FBアカウントを持たない新規の訪問者に報酬を支払う必要があります。これが私がアイデアを探している場所です。無数の電子メールアドレス([email protected][email protected]など)を取得するのが非常に簡単であるため、電子メール検証システムはそれ自体をカットしません。私はクレジットカード番号を尋ねることはあまりにも多くの障壁であると言われてきました。

このような状況に対処するためのかなりの戦略やサービスがありますか?

EDIT:「贈り物」は仮想である - クーポン

+0

電子メールとIPアドレスの組み合わせを使用すると思いますか?再利用されているIPアドレスから誤検知があるかもしれませんが、何よりも優れています。 – dasblinkenlight

+0

IPは唯一OKですが、大学のキャンパスのようなプロキシは、多くの人に同じIPアドレスを与える可能性があります。 –

+0

ギフトは何ですか?それは物理的なものかクーポンのようなものなのでしょうか? – josh3736

答えて

4

などは最終的に、これは戦いを失う、上り坂です。システムを打ち負かすインセンティブがある場合、誰かが試行し、最終的には成功するでしょう。 (たとえば、今まで実装されたすべてのDRMスキームを参照してください)。

しかし、ゲームの容易さを軽減する戦略があります。

  • 私は本当にその安全であるとFBのアカウントを考慮していないでしょう。新しいFBアカウントを作成する上での障壁は、新しいWebメールアカウントを作成するよりも無視される可能性があります。
  • IPアドレスによるフィルタリングは災害になる可能性があります。 1台のIPアドレス(、AOL)にプロキシの背後に何千人ものユーザーがいる可能性があり、詐欺師は各アカウントの要求を一意のIPに配布することができます。先験的にIPをブロックする価値よりも問題が多い可能性がありますが、後で—のようなリクエストを分析してから、実際に報酬を送信する前に—にIPから疑わしい動作が多数あるかどうかを調べることができます。
  • クレジットカード番号を要求するのは良いスタートですが、あなたはすでにそれを排除しています。また、1人の個人が実際のクレジットカード、デビットカード、1回限りのカード番号の間に10以上のカード番号を持つことができると考えてください。
  • SMSを介してPSTN番号に確認コードを送信することを検討してください。これにはお金(メッセージあたり数セント)がかかりますが、メッセージを受け取るために多数の電話番号を取得するためには、詐欺師にはかなりの変更額がかかります。 (インセンティブの価値に応じて、プリペイドSIMを使用すると費用がかさむことがあります)もちろん、既に詐欺師がSMS受信PSTN番号を多く持っている場合、これは機能しません。
2

最初のことは、これらの贈り物を物理的な住所に送る必要があるかどうかです。 100の電子メールアドレスやFBアカウントをスプーフィングするのは簡単ですが、明らかに一意の物理アドレスを100個指定することは明らかです。

もちろん、あなたはそれらに電子クーポンなどを与えている可能性がありますので、アドレスはオプションではない可能性があります。

以前は、コンテスト審査用ユーティリティのために非常に強力な反ゲームスクリプトを書きました。これは数ヶ月の開発期間であり、非常に詳細に説明するにはあまりにも複雑ですが、私はスクリプトの基本的な特徴を概説することができます:

1つは、ユーザーがコンテストに応募したときにできるIP、ブラウザなどの基準からのログイン/提出の平均時間を考慮することで、明らかに類似したアカウントを見つけることはかなり簡単でした。偽装できるすべてのものは信頼できません。さらに、信頼性だけでなく、levenshtein距離の組み合わせを使用して、[email protected][email protected]などの明白なゲームのアカウント資格情報を比較しました。また、さまざまな種類の構文解析スクリプト資格情報の詳細とパターンを探しました。

各テストの得点に応じて、ゲームの可能性と可能性のあるアカウントの一致のリストを割り当てました。それから、結果からそれらを除外するのは管理者の責任でした。

あなたのアルゴリズムを改良するのに数ヶ月間続けても、完璧なことはありません。だからこそ、私のスクリプトは口座にしかフラグを立てておらず、自動的な行動を取らなかったのです。

0

あなたは在庫について話しているので、あなたの贈り物は実際の物であると見なすことができますか?

もしそうなら、贈り物の配信は配信のための物理アドレスが必要になります - 固有のアドレスを必要とする(または、アドレスの重複を許すが、マニュアルレビューのためにそれらのユーザーにフラグを立てるには)良い制限する必要があります。

私の前提はこれです理論的にスクリプトを実行して100種類のFacebookアカウントまたはGoogleアカウントを作成することができますが、何百もの異なる現実世界の配送場所を物理的に制御することは全く異なる問題です。

0

私はすべてのセキュリティの代わりに、より現実的な解決策を提案します。アドレスごとに1つのクーポンであることを明確にしてください。物理的な(配送および/または支払い)住所。それから、あなたが望むように、おそらく電子メールやそれ以外のもので制限しますが、最終的にクーポンを受け取った人ではなく、実際のエンドユーザごとに制限します。

関連する問題