Каков наилучший способ сделать базовое отслеживание просмотра на веб-странице? - PullRequest
1 голос
/ 04 января 2009

У меня есть веб-сайт, анонимно доступный, каталог блогов и блогов, и я хотел бы отслеживать количество просмотров, которые получает каждое из сообщений блога.

Я хочу сохранить это как можно более простым, точность должна быть только приблизительной. Это не для аналитики (у нас есть Google для этого), и я не хочу делать какой-либо анализ журнала, чтобы получить статистику, поскольку выполнение фоновых задач в этой среде сложно, и я хочу, чтобы числа были как можно более свежими.

Мое текущее решение выглядит следующим образом:

  1. Веб-элемент управления, который просто записывает представление в таблицу для каждого GET.
  2. Исключает список известных сканеров, использующих регулярное выражение и строку UserAgent
  3. Предусматривает исключение определенных IP-адресов (известных спаммеров)
  4. Предусматривает блокировку некоторых сообщений (когда за ним приходят спаммеры)

На самом деле, похоже, это очень хорошая работа, но несколько вещей меня раздражают. Спамеры по-прежнему попадают в некоторые сообщения, тем самым искажая представления. Мне все еще приходится вручную просматривать просмотры и обновлять мой список «плохих» IP-адресов.

У кого-нибудь есть лучшие предложения для меня? Кто-нибудь знает, как отслеживаются представления по вопросам StackOverflow?

Ответы [ 2 ]

1 голос
/ 04 февраля 2009

Похоже, что ваше текущее решение на самом деле неплохо.

Мы внедрили тот, в котором серверный код, который доставлял содержимое представления, также обновил таблицу базы данных, в которой сохранен URL-адрес (фактически специальный идентификационный код для URL-адреса, поскольку URL-адрес может изменяться со временем) и количество просмотров.

На самом деле это была система с постами, написанными пользователями, которые другие могли комментировать, но это в равной степени относится к ситуации, когда вы являетесь единственным пользователем, создающим посты (если я правильно понимаю ваше описание).

Нам пришлось сделать следующее, чтобы минимизировать (не исключить, к сожалению) перекос.

  • Для зарегистрированных пользователей каждый пользователь может добавить только одну точку обзора к сообщению. КОГДА-ЛИБО. Никаких исключений.
  • Для анонимных пользователей каждый IP-адрес может добавлять только одну точку обзора к сообщению каждый месяц. Это было немного менее надежно, поскольку IP-адреса могли быть «общими» (NAT и т. Д.) С нашей точки зрения. Причиной, по которой мы ослабили приведенное выше требование «НИКОГДА», была причина разделения
  • Сами посты ограничивались добавлением одной точки обзора за период времени (период начинался с низкого уровня (скажем, 10 секунд) и постепенно увеличивался (скажем, до 5 минут), так что новым постам было разрешено накапливать просмотры быстрее из-за к их новизне). Это позаботилось о большинстве спам-ботов, так как мы обнаружили, что они имеют тенденцию атаковать еще долго после создания поста.
  • Удаление спам-комментария к сообщению или неудачная попытка обойти CAPTCHA (см. Ниже) автоматически добавило этот IP-адрес в черный список и сократило количество просмотров для этого сообщения.
  • Если IP-адрес из черного списка не пытался оставить комментарий в течение N дней (настраивается), он был удален из черного списка. Это правило и предыдущее правило сводили к минимуму ручное вмешательство в ведение черного списка, нам оставалось только отслеживать ответы на спам.
  • CAPTCHA. Это решило много наших проблем со спамом, тем более что мы не просто полагались на вещи типа OCR (например, «что это за слово ->« необязательно »), мы фактически задавали вопросы (например,« что такое 2 »). умножить на половину от 8? "), что сломает немых ботов распознавания персонажей. Это не победит орды дешёвых рабочих CAPTCHA (если их математика не очень плохая :-), но улучшения от no-CAPTCHA были впечатляющими.
  • Пользователи, вошедшие в систему, не подпадали под действие CAPTCHA, но спам немедленно удалил учетную запись, занес их в черный список IP-адресов и вычел их мнение из сообщения.
  • Мне стыдно признаться, что мы на самом деле не сбрасывали со счетов веб-сканеры (надеюсь, клиент не читает это :-). Честно говоря, они, вероятно, только добавляют минимальное количество точек обзора каждый месяц из-за нашего правила IP-адресов (если только они не набивают нас несколькими IP-адресами).

Так что, в принципе, я предложил следующие возможные улучшения. Конечно, вы всегда должны следить за тем, как они работают, чтобы увидеть, работают они или нет.

  • CAPTCHA.
  • Автоматические обновления черного списка в зависимости от поведения пользователя.
  • Ограничение количества просмотров увеличивается с одинаковых IP-адресов.
  • Ограничение количества просмотров увеличивается до определенной скорости.

Ни одна из выбранных вами схем не будет идеальной (например, наше правило одного месяца), но, пока все посты следуют одному и тому же набору правил, вы все равно получите хорошую сравнительную ценность. Как вы сказали, точность должна быть только приблизительной.

0 голосов
/ 04 февраля 2009

Предложения:

  1. Перемещение логики количества обращений из пользовательского элемента управления в базовый класс Page.
  2. Переработать список исключений для динамического обновления (т.е. сохранить его в базе данных или даже в XML-файле)
  3. Запишите все хиты. Регулярно выполняйте задание cron по новым попаданиям и определяйте, включены они или исключены. Если вы делаете исключение для каждого попадания, каждый пользователь должен ждать, пока не произойдет соответствующая логика.
  4. Придумайте какой-нибудь алгоритм для автоматического обнаружения спамеров / ботов и добавьте их в черный список. И / или подписаться на сторонний черный список.
...