Вы отправляете ссылку на коммерческое предложение клиенту. Через две минуты трекинговый инструмент показывает, что клиент открыл его, пролистал шесть страниц и провёл по 30 секунд на каждой.
Вы тут же отправляете follow-up. Клиент понятия не имеет, о чём вы говорите — он ещё даже не открывал ссылку.
Что произошло: почтовый сканер безопасности его компании открыл вашу ссылку раньше него. «Просмотр» был ботом. И если ваша аналитическая платформа не обрабатывает это специально, вы не отличите одно от другого.
Это не редкий крайний случай. Это происходит практически с каждым письмом, отправленным корпоративным получателям, использующим Microsoft 365 или Google Workspace.
Мало времени?
Перейдите к тому, как мы решаем проблему с помощью трёх уровней обнаружения ботов, или узнайте, что это значит для вашей аналитики.
Боты, которые завышают вашу аналитику
Существует три категории автоматизированного трафика, который попадает на ссылки общих презентаций:
Боты предпросмотра ссылок
Когда вы вставляете ссылку в Slack, LinkedIn, Twitter или iMessage, бот немедленно загружает страницу для генерации карточки предпросмотра. Эти запросы приходят с идентифицируемыми user agent — Slackbot-LinkExpanding, LinkedInBot, Twitterbot. Их легко обнаружить и отфильтровать. Большинство трекинговых инструментов справляются с ними корректно.
Поисковые краулеры
Googlebot, Bingbot и их варианты регулярно индексируют общедоступный контент. Они тоже открыто идентифицируют себя и легко фильтруются. Если ваши ссылки защищены аутентификацией или используют уникальные slug, краулеры редко их находят.
Сканеры безопасности электронной почты
Именно эта категория ломает аналитику.
Microsoft Defender SafeLinks, Proofpoint URL Defense, Mimecast и Google Safe Browsing сканируют каждую ссылку во входящих письмах до того, как получатель их увидит. Их задача — обнаруживать фишинговые страницы и вредоносное ПО. Они делают это, фактически открывая ссылку, загружая страницу и во многих случаях переходя по её содержимому.
Что делает их практически неотличимыми от реальных пользователей:
- Подделанные user agent. SafeLinks не объявляет себя ботом. Он использует настоящие браузерные user agent — например, «Chrome 120 on Windows 11» или даже строки мобильных устройств вроде «itel A27 Android». Ваш сервер видит то, что выглядит как легитимное посещение из браузера.
- Навигация по страницам. SafeLinks не просто загружает первую страницу. Он переходит примерно через 6 страниц вашей презентации вне зависимости от общего количества. Proofpoint делает аналогичное многостраничное сканирование.
- Реалистичный тайминг. Такие сессии длятся 22–48 секунд. Они не пролетают мгновенно, как грубый скрапер — тайминг выглядит правдоподобно для быстрого просмотра.
- Синтетические DOM-события. Некоторые сканеры генерируют JavaScript-события — программные прокрутки, имитации касаний, даже события кликов — чтобы активировать вредоносные скрипты, которые могут быть скрыты за пользовательским взаимодействием.
Итог: каждый раз, когда вы отправляете ссылку на презентацию кому-то в компании, использующей Microsoft 365 (а это большинство ваших корпоративных клиентов), вы получаете фейковый «просмотр», который выглядит как настоящий. Иногда два — один от стека безопасности отправителя, другой от получателя.
Вот как сессия бота SafeLinks выглядит рядом с сессией реального человека:
Перезапись URL усугубляет проблему
Некоторые инструменты безопасности не просто предварительно сканируют ссылки — они полностью их перезаписывают. SafeLinks заменяет каждый URL в теле письма на редирект через собственные серверы Microsoft (https://nam02.safelinks.protection.outlook.com/...). Proofpoint делает то же самое через URL Defense (https://urldefense.proofpoint.com/v2/...).
Когда получатель наконец кликает по ссылке в письме, он открывает не ваш оригинальный URL напрямую. Он кликает по перезаписанному URL SafeLinks, который сначала проходит через прокси Microsoft — а прокси Microsoft в этот момент снова открывает вашу страницу для повторного сканирования. Затем перенаправляет браузер пользователя на вашу реальную страницу.
Результат: сканирование ботом и реальное посещение происходят одновременно. Сканер безопасности открывает вашу презентацию с IP дата-центра в ту же самую секунду, когда реальный пользователь открывает её из своего офиса. Вы получаете две параллельные сессии — одна бот, другая человек — с почти идентичными временными метками. Если ваша аналитика не может их различить, вы либо считаете обе (завышение), либо рискуете отфильтровать настоящую (занижение).
Это самый сложный сценарий для корректной обработки. Предварительное сканирование при доставке легко определить изолированно — оно приходит за несколько минут до того, как кто-то кликнет. Но повторное сканирование при клике приходит одновременно с реальным пользователем, с другого IP, с другим user agent, создавая отдельную сессию, которая пересекается с легитимной.
Ловушка follow-up
Если вы используете уведомления о просмотрах для выбора момента follow-up, ботовые просмотры наносят прямой вред. Вы звоните клиенту «пока он смотрит вашу презентацию», а он ещё даже не открыл письмо. Вы выглядите навязчиво, а не внимательно. А при перезаписи URL даже тайминг обманчив — ботовая сессия начинается в тот же момент, что и реальная.
Почему стандартное обнаружение ботов не работает
Стандартный подход — проверка user agent по списку известных ботов — ловит ботов предпросмотра и краулеры, но полностью пропускает сканеры безопасности электронной почты. SafeLinks намеренно использует правдоподобные user agent именно для того, чтобы избежать обнаружения, потому что фишинговые страницы, распознающие ботов, показывают им другой контент, нежели реальным пользователям.
Ограничение по IP тоже не помогает. SafeLinks ротирует пул IP-адресов дата-центров Azure, поэтому каждое сканирование приходит с нового адреса. Вы не можете блокировать по IP, не заблокировав при этом легитимных пользователей на корпоративных VPN.
Фингерпринтинг браузера (canvas, WebGL, перечисление шрифтов) не работает, потому что SafeLinks запускает полноценный браузер на основе Chromium. Его фингерпринт неотличим от реальной установки Chrome.
Как мы решаем проблему: три уровня обнаружения
Мы построили систему обнаружения, которая ловит сканеры безопасности электронной почты, не блокируя легитимных пользователей — включая тех, кто использует корпоративные VPN и прокси.
Вот как трафик проходит через три уровня. Наведите курсор на любой узел, чтобы проследить его путь:
Уровень 1: Сопоставление user agent
Прямолинейная часть. Мы проверяем входящие запросы по 60+ известным паттернам ботов — боты предпросмотра, поисковые краулеры, headless-браузеры, HTTP-клиентские библиотеки. Если запрос идентифицирует себя как Slackbot или python-requests, мы немедленно его отклоняем. Сессия не создаётся.
Это ловит около 40% ботового трафика. Лёгкие 40%.
Уровень 2: Обнаружение IP дата-центров
Сканеры безопасности электронной почты подделывают user agent, но не могут скрыть, где они запущены. SafeLinks работает из дата-центров Azure. Proofpoint работает на AWS. Это известные диапазоны IP хостинг-провайдеров.
Когда зритель открывает общую ссылку, мы проверяем его IP через сервис геолокации, который сообщает, принадлежит ли IP хостинг-провайдеру. Если да, сессия помечается как бот.
Это ловит большую часть трафика сканеров безопасности электронной почты. Зритель, подключающийся из «Quincy, Washington» с IP Microsoft Azure в 2 часа ночи, почти наверняка не ваш клиент, читающий ваше предложение.
Есть нюанс: мы не блокируем такие сессии. Мы создаём запись о просмотре, но помечаем её как бот, исключаем из аналитики и не отправляем вам уведомление. Это позволяет нам проверять ложные срабатывания и даёт пользователям возможность изучить ботовые сессии, если они хотят разобраться.
А что с VPN-пользователями?
Пользователи корпоративных VPN иногда маршрутизируются через IP дата-центров, а значит, Уровень 2 может пометить реального пользователя как бота. Именно для этого существует Уровень 3 — он даёт людям возможность «доказать», что они настоящие, даже если их IP выглядит как адрес дата-центра.
Уровень 3: Подтверждение человека через жесты
Это критически важный уровень. Он основан на простом наблюдении: реальные люди физически взаимодействуют со страницей. Боты — нет, а когда всё же взаимодействуют, их действия имеют характерную сигнатуру.
Когда сессия изначально помечена как бот (Уровнем 2), мы не считаем её реальным просмотром. Вместо этого мы наблюдаем за подлинным пользовательским вводом:
Что мы отслеживаем: Движение мыши, события касания, ввод с клавиатуры и прокрутку.
Что мы игнорируем: Навигацию по страницам, клики по ссылкам и скачивания. Это контринтуитивно — кажется, что это сильные сигналы человеческого поведения. Но SafeLinks переходит по 6+ страницам каждой сканируемой презентации. Headless-браузеры вроде Puppeteer могут программно нажимать кнопки и инициировать скачивания. Эти действия тривиально подделать. Низкоуровневые события устройств ввода гораздо сложнее убедительно синтезировать.
3-секундное окно: Мы игнорируем все жесты в первые 3 секунды после загрузки страницы. SafeLinks и Proofpoint генерируют свои синтетические события почти мгновенно — в пределах 500 миллисекунд после загрузки страницы. Реальным людям нужно как минимум 3 секунды, чтобы сориентироваться и начать взаимодействовать. Один этот временной порог устраняет большую часть шума от синтетических событий.
Анализ движения мыши: Когда мы обнаруживаем движение мыши после 3-секундного окна, мы записываем траекторию — координаты и временные метки до 20 событий движения. Ботовые движения мыши следуют геометрическим путям (идеально прямые линии, точные окружности) или генерируют единственное событие. Человеческие движения мыши имеют органическое ускорение и замедление, лёгкие изгибы и микрокоррекции.
Когда обнаружен подлинный жест, сессия атомарно «повышается» с бота до реальной. В этот момент — и только в этот момент — счётчик просмотров увеличивается, и вы получаете уведомление.
Тайминг имеет значение
Вся система спроектирована с учётом конкретного состояния гонки: что происходит, когда реальный пользователь открывает ссылку, один раз двигает мышью и сразу закрывает вкладку?
Запрос подтверждения может не успеть завершиться до закрытия вкладки. Браузеры отменяют незавершённые запросы fetch() при навигации. Поэтому мы используем sendBeacon() — браузерный API, специально разработанный для запросов типа «отправил и забыл», которые переживают выгрузку страницы — в качестве резервного варианта. Финальный beacon несёт данные подтверждения вместе с метриками вовлечённости сессии.
На стороне сервера повышение атомарно: один SQL-запрос на обновление, который успешен только в том случае, если сессия ещё не была повышена. Это предотвращает двойной подсчёт, когда приходят и обычное подтверждение, и резервный beacon.
Что это значит для вашей аналитики
Практическое влияние значительно. В наших тестах на командах продаж, работающих с корпоративным сектором, 15–40% видимых просмотров презентаций были ботовыми сессиями — в основном от SafeLinks и Proofpoint. Для команд, продающих крупным предприятиям со строгими политиками безопасности электронной почты, этот показатель был ещё выше.
Без фильтрации:
- Счётчики просмотров завышены на 15–40%
- «Наиболее вовлечённые» клиенты могут оказаться теми, у кого самая агрессивная почтовая безопасность
- Время просмотра ненадёжно — вы думаете, что клиент посмотрел вашу презентацию в 14:00, когда сканер безопасности открыл её в 13:58
- Сигналы для follow-up — это шум
С фильтрацией:
- Каждый просмотр представляет реального человека, который действительно посмотрел ваш контент
- Метрики вовлечённости (время просмотра, просмотренные страницы, процент завершения) отражают подлинный интерес
- Уведомления о просмотрах срабатывают, когда человек активно взаимодействует с контентом, а не когда бот предварительно сканирует его
Проверка ботовых сессий в HummingDeck
Лента активности включает фильтр «Показать ботовые сессии», который позволяет изучить отфильтрованные сессии. Используйте его, чтобы убедиться, что система работает правильно для ваших конкретных клиентов — если вы видите, что легитимный зритель помечен как бот, уровень подтверждения жестами должен повысить его статус, как только он начнёт взаимодействовать со страницей. Если этого не происходит, обратитесь в поддержку.
Более широкий урок
Сканирование безопасности электронной почты никуда не исчезнет — оно становится всё более тщательным. Microsoft и Google расширяют автоматическое сканирование ссылок по мере усложнения фишинговых атак. Любая аналитическая платформа, которая использует загрузку страницы как индикатор человеческого просмотра, будет становиться всё менее точной. Те же боты, которые накручивают просмотры презентаций, фальсифицируют и показатели открытия писем.
Нужный вам сигнал — не «была ли моя ссылка открыта». А «взаимодействовал ли человек с моим контентом». Для этого нужно отличать одно от другого — а разница в жестах, а не в загрузке страницы.