現在のソリューションは実際には非常に優れているようです。
ビューコンテンツを配信するサーバーコードが、URL（URLは時間の経過とともに変化する可能性があるため、実際にはURLの特別なIDコード）とビュー数を格納するデータベーステーブルも更新するものを実装しました。
これは実際には、他のユーザーがコメントできるユーザー作成の投稿があるシステムの場合ですが、投稿を作成する唯一のユーザーである状況にも同様に当てはまります（説明を正しく理解している場合）。
スキューを最小限に抑える（残念ながら、排除しない）ために、次のことを行う必要がありました。
- ログインしたユーザーの場合、各ユーザーは投稿に1つの視点しか追加できませんでした。これまで。例外なし。
- 匿名ユーザーの場合、各IPアドレスは毎月1つの視点しか投稿に追加できませんでした。私たちの観点からは、IPアドレスを「共有」（NATなど）できるため、これは少し信頼性が低くなりました。上記の「EVER」要件を緩和した理由は、この共有の理由によるものです。
- 投稿自体は、期間ごとに1つのビューポイントが追加されるように制限されていました（期間は低く始まり（たとえば、10秒）、徐々に増加しました（たとえば、5分））。そのため、新しい投稿は、目新しさのために、より速くビューを獲得することができました。 ）。投稿が作成されてからかなり経ってから攻撃する傾向があることがわかったため、これでほとんどのスパムボットが処理されました。
- 投稿へのスパムコメントの削除、またはCAPTCHAのバイパスの試みの失敗（以下を参照）により、そのIPがブラックリストに自動的に追加され、その投稿の閲覧数が減少しました。
- ブラックリストに登録されたIPがN日以内にコメントを残そうとしなかった場合（構成可能）、ブラックリストから削除されました。このルールと以前のルールは、ブラックリストを維持するための手動による介入を最小限に抑え、スパムコンテンツの応答を監視するだけで済みました。
- CAPTCHA。これにより、スパムの問題の多くが解決されました。特に、OCRタイプのもの（「この単語は何ですか->」など）に依存していなかったため、実際に質問しました（「2に8の半分を掛けたものは何ですか？」など）。 "）それは愚かな文字認識ボットを壊します。それは安い労働力のCAPTCHAブレーカーの大群を打ち負かすことはありません（彼らの数学が本当に悪い場合を除いて:-)が、非CAPTCHAからの改善は印象的でした。
- ログインしたユーザーはCAPTCHAの対象ではありませんでしたが、スパムによってアカウントがすぐに削除され、IPがブラックリストに登録され、投稿からビューが差し引かれました。
- 私たちは実際にWebクローラーを割引しなかったことを認めることを恥ずかしく思います（クライアントがこれを読んでいないことを願っています:-)。正直なところ、私たちのIPアドレスルールのために、彼らはおそらく毎月最小限の数の視点を追加しているだけです（複数のIPアドレスで私たちを群がらせている場合を除く）。
したがって、基本的には、可能な改善として次のことをお勧めします。もちろん、彼らがどのように動いているかを常に監視する必要があります。
- CAPTCHA。
- ユーザーの行動に基づいたブラックリストの自動更新。
- 同一のIPアドレスからビュー数の制限が増加します。
- 視聴回数を制限すると、一定の割合で増加します。
選択したスキームは完璧ではありませんが（たとえば、1か月のルール）、すべての投稿が同じルールセットに従っている限り、優れた比較値が得られます。あなたが言ったように、精度は概算である必要があります。