FullStoryBot: почему для верификации здесь не работает обычное правило про IP

Если фильтровать access.log по fullstory, часто всплывает целый пласт машинных хитов — это и есть FullStoryBot, часть постоянной работы платформы аналитики цифрового опыта FullStory. В отличие от разовой проверки интеграции, FullStoryBot работает непрерывно: после того как FullStory записывает пользовательскую сессию на сайте клиента, бот подгружает внешние CSS, изображения и другие ассеты напрямую с сервера сайта — чтобы позже можно было точно, пиксель в пиксель, восстановить эту сессию при просмотре записи (session replay). Оператор: FullStory — платформа аналитики цифрового опыта (session replay, heatmaps, воронки, кастомные события). Классификация: легитимный сервис; решение allow/deny стоит принимать по бизнес-пользе — используется ли FullStory на сайте.

Что такое FullStoryBot

Зачем FullStoryBot приходит на сайт

Если вы видите FullStoryBot в логах, это почти наверняка означает, что сайт (или конкретная команда — продукт, маркетинг, UX-аналитика) использует FullStory для записи и анализа пользовательских сессий.

• Какие зоны чаще трогает: внешние ресурсы страницы — CSS-файлы, изображения, шрифты, которые нужны для визуального воспроизведения записанной сессии
• Что ищет: статические ассеты, необходимые для точного рендеринга страницы в момент, когда её видел реальный пользователь
• Чем отличается от браузерного пользователя: нет обычной сессии в привычном виде — запрос идёт от лица сервиса, обслуживающего уже записанную сессию реального посетителя

Официальная позиция FullStory по нагрузке

FullStory прямо заявляет, что бот не замедляет серверы клиентов, и описывает двухуровневое кеширование, встроенное именно для этого:

• Первый уровень — стандартный HTTP-кеш клиента, который уважает заголовки кеширования сайта и включает встроенный rate-limiting на случай некорректных заголовков
• Второй уровень — общий кеш подгруженных ресурсов, который используется для всех сессий одного клиента FullStory, чтобы не запрашивать одни и те же ассеты повторно

Практический вывод: если сайт использует FullStory и при этом видит заметный устойчивый фоновый шум именно от FullStoryBot — это отклонение от заявленного поведения, и стоит проверить, не связано ли это со спуфингом UA или некорректной конфигурацией кеш-заголовков на самом сайте, а не считать это нормой «раз уж бот, значит нагрузка неизбежна».

Как проверить подлинность — здесь всё наоборот

Для большинства ботов в этой категории совет один: не доверять только строке UA, сверять IP/ASN. Для FullStoryBot FullStory официально советует прямо противоположное для сценария allowlisting: **не** привязываться к IP, поскольку бот работает через облачную инфраструктуру с широким и переменным диапазоном адресов. Вместо этого компания рекомендует разрешать доступ именно по наличию FullStoryBot в строке UA. Это не отменяет базовую осторожность — UA всё ещё можно подделать — но означает, что IP-based allowlist для этого конкретного бота работает хуже, чем UA-based, вопреки общей рекомендации для большинства других ботов.

IP="1.2.3.4"
whois -h whois.cymru.com " -v $IP"
dig +short -x "$IP"

Отдельный рычаг контроля: настройки самого FullStory

Если задача не в том, чтобы остановить сам сбор ассетов ботом, а в том, чтобы боты и краулеры (включая сторонние) не засоряли аналитику FullStory фейковыми «сессиями» — это решается не на уровне сервера, а прямо в панели FullStory: Settings → Data Capture & Privacy → Data Capture, раздел Blocked User-Agents. Там можно добавить строку UA любого нежелательного робота, и FullStory перестанет фиксировать его визиты как пользовательские сессии.

Как найти FullStoryBot в логах

# Базовый поиск
grep -i "fullstory" /var/log/nginx/access.log

# Топ URL, которые вычитывает бот
grep -i "fullstory" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head

# Топ IP за этим UA
grep -i "fullstory" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

# Суточная активность
grep -i "fullstory" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1 | sort | uniq -c

robots.txt для FullStoryBot

# Жёсткий запрет
User-agent: FullStoryBot
Disallow: /

# Разрешить всё
User-agent: FullStoryBot
Allow: /

# Компромисс: закрыть служебные разделы, оставить публичку
User-agent: FullStoryBot
Disallow: /admin/
Disallow: /cart/
Disallow: /checkout/
Disallow: /account/
Disallow: /api/
Allow: /

Важно: если сайт использует FullStory, полная блокировка бота сломает корректное восстановление записанных сессий — стилей и изображений не будет хватать в replay.

Блокировка вручную и через TrafficVeil

Nginx

if ($http_user_agent ~* "fullstory") {
    return 403;
}

limit_req_zone $binary_remote_addr zone=fullstory:10m rate=10r/m;
location / {
    if ($http_user_agent ~* "fullstory") {
        limit_req zone=fullstory burst=20 nodelay;
    }
}

Apache (.htaccess)

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} fullstory [NC]
RewriteRule ^ - [F,L]

TrafficVeil

• Найдите fullstory / FullStoryBot в ботах домена или в /system/bots
• Сайт использует FullStory для аналитики — оставляйте allow, иначе сломается качество session replay
• FullStory не используется — можно ставить запрет без риска для функциональности
• После изменения сверьте логи: хиты fullstory должны уйти в блок/лимит, а поисковики Google/Yandex остаться без изменений

Рекомендации: что делать с FullStoryBot

• Команда использует FullStory для UX-аналитики — Allow, для allowlist ориентируйтесь на UA FullStoryBot, а не на IP
• FullStory на сайте не используется — Disallow/403, пользы от визитов нет
• Нужно очистить саму аналитику FullStory от бот-трафика (не связано с сервером) — используйте Blocked User-Agents в настройках FullStory
• Наблюдаете устойчиво высокую нагрузку от FullStoryBot вопреки заявленному кешированию — проверьте на спуфинг и на корректность cache-заголовков сайта, а не считайте это нормой

С кем не путать FullStoryBot

Прямых документированных «соседей» с такой же функцией восстановления сессий под похожим UA-паттерном в открытых источниках не нашлось — если в логах встречается похожий, но не идентичный токен, не считайте его автоматически тем же оператором.