Пик после письма: почему трафик приходит волной, а не ровно

MAATRIX

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

Что вы ожидаете увидеть и что видите на самом деле

Интуитивно кажется, что письмо — событие с одной точкой во времени: отправили в 10:00, все получили примерно тогда же и открыли в ближайшие минуты. Такая модель работает для внутренней рассылки на сто адресов внутри одного офиса, где почти все получают письмо и открывают его в течение получаса.

На базе в несколько тысяч и тем более десятков тысяч адресов модель ломается сразу по нескольким независимым причинам, и каждая добавляет свой сдвиг по времени. Реальный график обращений к сайту (переходов по ссылкам из письма) или запросов трекинг-пикселя обычно выглядит так: короткий острый пик в первые 15-30 минут — те, кто держит почтовый клиент открытым и увидел письмо сразу; затем спад, но не до нуля; затем один или несколько вторичных горбов, привязанных не ко времени отправки, а к местному времени получателя или его личному режиму проверки почты; и длинный пологий хвост, растягивающийся на двое-трое суток.

Практическая проблема в том, что если вы настраиваете alert по правилу «нагрузка выросла на N% за M минут», такой волновой профиль либо генерирует серию ложных тревог на каждый горб, либо, если порог задран, чтобы не шуметь на первую волну, пропускает реальный аномальный рост во время второй. Прежде чем чинить правила мониторинга, стоит понять механику, которая эти волны создаёт.

Отдельно стоит развести два похожих, но разных вопроса. Если вас интересует, что происходит с почтовым сервером в первые секунды после команды на отправку — очереди SMTP, лимиты провайдера, скорость постановки писем в отправку, — это отдельная узкая тема, не про поведение получателей, а про механику самой отправки. Здесь же речь о другом: почему уже доставленные и открываемые письма создают на стороне вашего сайта или сервера растянутый во времени, а не мгновенный трафик.

Часовые пояса аудитории: одна рассылка — несколько локальных пиков

Первая и самая очевидная причина волн — география. Если база подписчиков собрана по всей России, она физически растянута на одиннадцать часовых поясов, от Калининграда (UTC+2) до Камчатки (UTC+12). Рассылка, отправленная в 10:00 по Москве, приходит в почтовые ящики Владивостока в четыре часа дня по местному — и открывают её там не потому что «рассылка задержалась», а потому что для владивостокского подписчика это обычное рабочее время, когда он и так проверяет почту.

Тот же эффект работает и без выхода за пределы одного государства, если аудитория международная: подписчики в Европе, США и Азии физически не могут открыть письмо в одну и ту же минуту UTC, если только рассылка не подгоняется под локальное время получателя (send-time optimization, которую умеют некоторые почтовые платформы, но далеко не все и не всегда точно).

Практический вывод для инфраструктуры: если аудитория географически распределена, ожидайте не один пик, а по одному пику на каждый крупный часовой пояс, представленный в базе. Три пояса с заметной долей подписчиков — три волны трафика в течение дня, растянутые примерно на столько часов, сколько разница между крайними поясами. Это стоит учитывать при планировании окна обслуживания сервера — если вы запланировали технические работы через два часа после рассылки, рассчитывая на «уже всё открыли», для восточной части аудитории пик может быть ещё впереди. Заодно стоит убедиться, что часовой пояс на самом сервере настроен корректно и логи не путают локальное время с UTC — иначе разбор волн по графику превращается в отдельную головоломку; как привести это в порядок, разобрано в статье про настройку часового пояса на сервере.

Как почтовые клиенты растягивают момент открытия

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

Мобильные клиенты с push-уведомлениями (стандартная связка на iOS и Android для основных провайдеров) показывают письмо почти сразу после доставки на сервер — здесь задержка на стороне клиента минимальная, счёт на секунды. Но далеко не все ящики настроены на push. Корпоративная почта через Exchange нередко синхронизируется по расписанию — раз в 5, 15 или 30 минут в зависимости от политики IT-отдела, и тогда сотрудник физически не увидит письмо раньше следующего цикла синхронизации, даже если сидит перед экраном.

Десктопные почтовые клиенты, настроенные на периодический опрос сервера (poll), а не на постоянное IMAP-соединение с IDLE, добавляют свою задержку — от минуты до получаса, снова по конфигурации конкретного клиента. Веб-версии почты (открытые в браузере вкладки Gmail, Яндекс.Почты, Mail.ru) обычно подтягивают новые письма динамически, но если вкладка была свёрнута или компьютер спал, обновление произойдёт только когда пользователь вернётся к вкладке — то есть в момент, который никак не связан со временем отправки.

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

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

Поведенческие сегменты: не все открывают почту одинаково

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

• Импульсивные читатели — открывают письмо в течение первых 5-15 минут после получения, часто с телефона по уведомлению. Это они формируют первый острый пик на графике.
• Проверяющие почту пакетно — заходят в ящик два-три раза в день в привычные окна: утром по дороге на работу, в обед, вечером после работы. Их открытия формируют вторичные горбы, привязанные не к моменту отправки, а к их личному расписанию.
• «Разборщики хвостов» — открывают почту раз в один-два дня, обычно ближе к выходным или когда накопилось много непрочитанного. Именно они создают тот самый длинный пологий хвост трафика, растянутый на несколько суток после рассылки.
• B2B-аудитория в рабочие часы — если ваша рассылка адресована сотрудникам компаний, для них будни и выходные дают резко разный профиль: в пятницу вечером и на выходных открытий почти нет, а в понедельник утром накопившиеся письма создают неожиданный скачок, который на первый взгляд не связан с исходной рассылкой вообще.

Сегменты смешаны в одной базе в неизвестной вам пропорции, и именно их суммарная накладка друг на друга даёт тот самый неровный, многогорбый график вместо одного чистого пика. Понять точное соотношение групп без специальной аналитики почтовой платформы (метрики open rate по времени, если провайдер их отдаёт) сложно — но для инфраструктурных целей это и не обязательно: достаточно знать, что растянутый профиль — норма, а не сигнал неполадки.

Повторные открытия и почему хвост не падает до нуля

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

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

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

Всё это означает, что «конец» пика от рассылки — понятие условное. Формально считать кампанию закрытой имеет смысл через тот срок, когда прирост трафика, который можно с разумной уверенностью связать со ссылками из письма (по UTM-меткам), падает до уровня фонового шума — обычно это происходит на вторые-третьи сутки, но конкретный срок у каждой базы свой и заранее не считается, а смотрится по факту на графике.

Что это значит для сервера, мониторинга и планирования мощности

Практические выводы из всей этой механики укладываются в несколько конкретных настроек.

Не проектируйте мощность под один короткий пик. Если вы закладываете запас только на первые 15-30 минут после отправки, вы рискуете упереться в лимиты во время второго или третьего горба, когда просыпается следующий часовой пояс или следующая поведенческая группа. Разумнее смотреть на суммарную площадь под графиком за сутки-двое и держать запас по CPU и соединениям на протяжении всего этого окна, а не только в первый момент.

Настройте мониторинг на скользящее окно, а не на разовый порог. Правило вида «алерт, если запросов в минуту больше X» на волновом графике либо срабатывает ложно на каждый локальный горб, либо, если порог занижен под пиковую волну, не замечает аномалию в спокойные интервалы между волнами. Лучше работает сравнение текущего значения со скользящим средним за предыдущие часы того же дня (или с тем же интервалом дня-два назад) — так система отличает «ожидаемый второй горб от рассылки» от «неожиданного роста, не связанного с кампанией». Пример практики, когда наивные пороговые алерты создают только шум и приучают команду их игнорировать, разобран в статье про антипаттерн алерта на каждый скачок нагрузки — механика там про нагрузку вообще, но логика применима один в один к трафику после рассылки.

Разделяйте трафик от кампании и фоновый трафик по UTM или отдельному поддомену. Если ссылки в письме размечены (utm_source=email&utm_campaign=...) и ведут через отдельный трекинг, вы можете в логах веб-сервера или в системе аналитики выделить именно волну от рассылки на фоне обычного органического трафика — это упрощает и разбор аномалий, и оценку реального охвата кампании. Простой способ прикинуть распределение по часам без сложной аналитики — агрегировать access-лог nginx по часовым бакетам:

awk '{print $4}' access.log \
  | cut -d: -f2-3 \
  | sort | uniq -c \
  | sort -k2

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

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

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

Частые вопросы