Расследование недоставок

Оглавление

1. Как расследовать недостачу ›
2. Что приложить в обращение ›
3. Как читать результат и когда писать в поддержку ›

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

В большинстве случаев письмо «не пропало в вакууме». Оно либо не попало в аудиторию отправки, либо не ушло из кабинета, либо ушло и получило недоставку, либо ящик принял письмо, а человек смотрит не ту папку. Разбор кодов soft и hard bounce — в статье Какие бывают ошибки недоставки ›.

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

Как расследовать недостачу

Идите по гипотезам по порядку. Как только нашли слой, на котором письмо «остановилось», дальше по списку можно не бежать — сначала закрыть эту причину.

1. Один email — несколько профилей

В Mailganer один и тот же адрес может жить в нескольких местах. Жалоба часто звучит про «email Ивана», а в кабинете смотрят не ту карточку.

Типичные варианты:

• один адрес состоит в нескольких списках — статус подписки в каждом списке свой;
• после импорта или синхронизации с CRM появились дубли (две карточки на один email);
• у двух профилей разные внешние идентификаторы (external_id / id из CRM), а email совпал;
• в поиске открыли первого попавшегося подписчика, а письмо уходило на другой профиль с тем же адресом.

Что сделать: найдите все карточки по этому email. Сверьте список, статус подписки и историю отправок у каждой.

Если у «того же» адреса в одном списке статус «подписан», а в другом — «отписан» или «недоставка», картина для расследования уже другая. Подробнее о логике подписок и отписок — Логика подписок и отписок в имейлах ›.

2. Не попал в аудиторию отправки

Письмо не могло уйти человеку, которого не было в аудитории этой отправки.

Коротко про списки и сегменты (полный разбор не дублируем):

• список — где хранится подписчик и его статус;
• сегмент — набор условий поверх списка; рассылка и многие сценарии уходят на сегмент.

Если отправляли на сегмент «активные из списка А», а проверяете человека из списка Б или с другим статусом — в отчёте его не будет как «должен был получить». Чем списки отличаются от сегментов — в отдельной статье ›.

Проверьте также: отписан, не подтвердил подписку, неактивен по вашим правилам, не проходит условия сегмента на момент отправки.

3. Массовая рассылка: на этого человека письмо не ушло

Кампания в целом могла уйти, а конкретному адресу — нет.

Смотрите отчёт по рассылке и карточку подписчика: был ли адрес в отправке, есть ли отметка об исключении, стоп-листе, ошибке. Как читать отчёт — Как работать с отчётом по рассылке ›. Про стоп-листы платформы — Стоп-листы в Mailganer ›.

Имеет смысл сразу уточнить: жалоба на одного человека или «никто не получил»? При массовом сбое картина в отчёте другая, чем при одном статусе в карточке.

4. Триггер не сработал или шаг не ушёл

Отдельная ветка: «триггер не отправился» часто значит не «SMTP лёг», а «событие не дошло / условия не сошлись / человек уже был в цепочке».

Проверьте по порядку:

• пришло ли событие, на которое завязан сценарий;
• выполнены ли условия и сегмент на шаге в момент срабатывания;
• не был ли подписчик уже в этой цепочке / на этом шаге;
• не уходит ли письмо на служебный или тестовый адрес вместо боевого.

Обзор событий — Обзор событий в триггерах ›. Настройки и отправка — Как отправить триггер › и Способы отправки триггера ›. Служебный адрес в B2B — Служебный имейл ›.

5. SMTP и транзакционные письма

Та же логика слоёв, другой контур отправки: API или SMTP, часто без «рассылки» в привычном смысле отчёта кампании.

Что сверить:

• ушёл ли запрос / сессия на стороне отправителя (код ответа, лог интеграции);
• не стоит ли адрес в стоп-листе SMTP › (как снять — инструкция ›);
• какой From / return-path и не упираетесь ли в особенности служебного имейла ›;
• есть ли недоставка уже после приёма транспортом — тогда снова ошибки недоставки ›.

Для клиента важно в обращении сразу написать: это была массовая кампания, триггер или SMTP/API. Иначе поддержку гоняют по неверному контуру.

6. Ушло из Mailganer — пришла недоставка

Если в кабинете видно, что письмо отправляли, а статус — soft или hard bounce, дальше разбирают код и политику повторов, а не «почему триггер молчит».

Виды ошибок, ретраи и где смотреть недоставки — Какие бывают ошибки недоставки ›. Раздел «Недоставки» в кабинете — отправная точка после того, как подтвердили факт отправки.

7. Ящик принял письмо, человек его не видит

На этом слое Mailganer уже отдал письмо почтовику. Дальше — спам, «Промоакции», корпоративные фильтры, задержка, другая папка, другой ящик (алиас / пересылка).

С чего начать: Почему письма попадают в спам ›, для Gmail — Почему письмо попало в спам на Gmail ›. Как понять, что письма садятся в спам массово — отдельный разбор ›. Служебные заголовки с стороны получателя — Как просмотреть служебные заголовки писем ›.

Уточнения

Открытие письма ≠ доставка. Нет открытия — ещё не значит, что письмо не приняли.

«Нет во Входящих» ≠ «не отправляли». Сначала слой аудитории и отправки, потом папки у получателя.

Один тикет «мне не пришло» при тысяче успешных доставок чаще про этого подписчика или его ящик, чем про «у всех сломалось». Если падают метрики по домену целиком — это уже другая проверка (репутация, спам, Postmaster).

Список и сегмент путают чаще всего при расследовании «почему его не было в рассылке». Имеет смысл держать под рукой статью про разницу › и не спорить словами — сверить условия и статус.

Чеклист самопроверки

1. Нашли все карточки по email и сверили статусы в списках.
2. Поняли канал: массовая рассылка / триггер / SMTP или API.
3. Проверили, входил ли человек в аудиторию (список, сегмент, статус).
4. В отчёте или истории шага видно: ушло / не ушло / почему.
5. Проверили стоп-листы (платформа и SMTP — по контуру).
6. Если ушло — посмотрели недоставки и код ошибки.
7. Если принято ящиком — проверили спам, папки, заголовки у получателя.
8. Собрали пакет для обращения (следующий блок), если сами не закрыли вопрос.

Что приложить в обращение

Одна и та же памятка для клиента в тикете и для поддержки: чем полнее пакет, тем меньше кругов «пришлите ещё скрин».

Укажите:

• email подписчика (как в жалобе);
• сколько карточек нашлось на этот адрес и какие статусы / списки;
• что отправляли: название или id рассылки, id / название триггера и шага, либо признак SMTP/API;
• дата и время (и часовой пояс), когда письмо «должно было» прийти;
• один человек или пачка адресов с той же жалобой;
• что уже видно у вас: ушло / не ушло / недоставка / «в отчёте нет»;
• кратко: что уже проверили по чеклисту выше.

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

Как читать результат и когда писать в поддержку

Как понять, что нашли причину:

• остановились на аудитории или статусе — чините сегмент, список, подписку, дубль профиля;
• остановились на «не ушло из кабинета» — стоп-лист, условия триггера, исключение в отчёте;
• остановились на недоставке — работаете с кодом и базой, см. ошибки недоставки ›;
• остановились на «принято, не видит» — сторона ящика и репутация/спам, не повторная «отправка наугад» тем же письмом без гипотезы.

В поддержку имеет смысл писать, когда:

• самопроверка по чеклисту пройдена, а слой всё ещё неясен;
• видите системный сбой (много адресов, один код, один домен получателя) и нужен разбор с нашей стороны;
• нужен доступ к логам, которых нет в кабинете.

Обращение удобнее оставлять через раздел «Мои обращения» в личном кабинете или канал, который использует ваша команда с Mailganer. В текст тикета можно просто вставить список из блока «Что приложить» — и клиенту, и поддержке будет один и тот же каркас.

Если после правок (сегмент, статус, стоп-лист) шлёте контрольное письмо — меняйте по одной гипотезе и снова смотрите тот же слой в отчёте или истории. Так быстрее понять, что сработало, чем менять всё сразу.