Кто приходит на мои сайты и за что я плачу.

01 / Экономика

Сервер работает. Вопрос — на кого.

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

Рост посещений сам по себе меня уже не убеждает. Я хочу видеть, что за ним стоит: человек читает статью, поисковый робот обходит страницы, кто-то проверяет доступность или перебирает адреса в поисках уязвимости. Ресурсы расходуют все. Польза для проекта у этих обращений разная.

Поэтому собственную аналитику я начинаю с вполне приземлённой задачи: понять, куда уходят ресурсы, какие ошибки встречает посетитель и какую лишнюю работу можно убрать.

02 / Уже работает

Три сайта, один сбор событий

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

Учитываются открытие страницы и переходы внутри сайта. Есть адрес предыдущей страницы, когда он доступен, сведения о браузере и код результата. Можно разбирать отдельные события, смотреть успешные открытия и ошибки по доменам. Это помогает вернуться от общей цифры к конкретному обращению.

Сейчас у этого сбора есть существенная граница: событие отправляет JavaScript в браузере. Если он не выполнился или отправка не дошла, записи не будет. Боты тоже могут выполнять JavaScript. Поэтому число таких событий пока нельзя считать ни полным объёмом запросов к серверу, ни точным числом живых людей.

Нагрузку и доступность я отдельно вижу в серверном мониторинге. Дальше нужно сопоставлять эти данные с журналами запросов, включая обращения без JavaScript. Сама система статистики тоже потребляет ресурсы — её стоимость входит в ту же задачу.

03 / Ошибки

За каждой 404 нужен контекст

При подключении обнаружилась показательная ошибка: страница отвечала 404, а событие посещения сохранялось как успешное. Исправил передачу кода и статуса. На всех трёх сайтах проверил: обычная страница даёт 200 и успешное событие, отсутствующая — 404 и ошибку. Теперь такие обращения можно выделить для разбора.

Но сама 404 ничего не говорит о намерении посетителя. Человек мог открыть старую ссылку. Я мог ошибиться в навигации. Робот мог прийти по давно удалённому адресу. В этих случаях нужно чинить сайт или переход, а не блокировать того, кто обнаружил проблему.

Другая ситуация — последовательный перебор служебных адресов, например попытки найти /.env или панель WordPress на сайте, где её нет. Это повод изучить источник, частоту и последовательность запросов. Пока это пример признаков для анализа, а не подсчитанная доля атак на мои новые сайты.

04 / Мотивация

Хочу понимать, за чью активность плачу

На главной я уже написал, почему не доверяю рекламным отчётам. Для собственного эксперимента мне нужен способ разбирать сомнительную активность: откуда она пришла, что запрашивала, повторяется ли один сценарий и есть ли за ним полезное действие. В этом для меня практический смысл антифрода.

Сканирование уязвимостей и накрутка рекламных кликов — разные проблемы. По набору несуществующих адресов нельзя доказать рекламное мошенничество. Собственная статистика даёт материал для проверки таких предположений, но сама по себе ещё не умеет надёжно отделять человека от бота.

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

05 / Следующий шаг

Сначала накоплю данные. Затем введу фильтры.

Новые фильтры по этой статистике пока не включены. Чуть позже, когда наберётся материал для сравнения, начну разбирать повторяющиеся сценарии и вводить правила на входе на сервер. Задача — отсекать обоснованно нежелательные обращения до того, как они заставят приложение выполнять лишнюю работу.

Перед каждым изменением зафиксирую исходную картину: какие запросы хочу ограничить, сколько их и какую нагрузку вижу. Правила буду вводить постепенно, чтобы понимать эффект каждого изменения и иметь возможность его отменить.

Отдельная проверка — не пострадали ли обычные переходы, полезные роботы и проверки доступности. Красивое падение трафика после блокировки всех подряд мне ничего не даст. Если правило заденет нужные обращения, это тоже результат, который придётся разобрать и исправить.

06 / Продолжение эксперимента

Покажу, что изменилось после фильтрации

В следующем отчёте хочу показать, какие правила включил, за какой период сравнивал данные и что получилось: сколько запросов перестало доходить до приложения, как изменились нагрузка, время ответа и ошибки. Отдельно расскажу о ложных блокировках и правилах, которые пришлось пересмотреть.

Число событий внутри приложения после фильтрации может уменьшиться просто потому, что запросы до него не дошли. Поэтому для оценки эффекта понадобятся и данные на входе на сервер. Буду учитывать изменения общего потока и обновления сайтов: иначе легко приписать фильтру чужой результат.

Снижение нагрузки ещё не означает снижение счёта за сервер. Экономию в деньгах смогу назвать, когда она действительно появится. Сейчас данных для такого вывода нет. Если заметного эффекта не будет, об этом тоже напишу.

Хочу получить проверяемый ответ: какая активность помогает моим проектам, какая расходует ресурсы впустую и что я могу с этим сделать.