Inbox Placement Testby Live Direct Marketing

Choose your language

Sign in
Сервисы отправки6 мин чтения

Симулятор Amazon SES и реальный тест Inbox Placement

Что проверяет симулятор SES, как учитывать ограничения sandbox и измерить размещение реального письма в тестовых ящиках LDM.

Симулятор почтовых ящиков Amazon SES проверяет, как приложение обрабатывает предусмотренные события отправки. Он не показывает, в какую папку Gmail, Outlook или другого провайдера попадёт письмо. Для этого нужна отдельная разрешённая отправка оригинального сообщения через ваш реальный маршрут SES на тестовые адреса LDM. Используйте оба вида проверки и сохраняйте их результаты раздельно.

Приложение может успешно обработать тестовое событие, а настоящее письмо — оказаться в дополнительной категории или Spam. Отсутствующая копия, напротив, могла вообще не выйти из приложения. Поэтому сначала разделите три вопроса: какой текст сформирован, была ли выполнена отправка и где обнаружено полученное сообщение. Это руководство описывает контролируемую проверку, а не проведённый эксперимент или нативную интеграцию SES с LDM.

Принятое письмо может оказаться в разных папках; успешная передача сама по себе не доказывает попадание в Inbox

Передача письма, папка и действия получателя — разные наблюдения

Что подтверждает симулятор SES

AWS предоставляет специальные адреса для проверки успешной доставки, возврата, жалобы и автоматического ответа. Например, success@simulator.amazonses.com воспроизводит сценарий успешной доставки. Отправлять на эти адреса нужно через SES; порядок работы описан в документации симулятора.

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

Запись «обработчик возвратов работает» должна указывать сценарий симулятора. Запись «копия найдена в Inbox» должна ссылаться на настоящий ящик и время наблюдения. Если объединить их в одну отметку «доставлено», последующее расследование будет опираться на неоднозначный результат.

Сначала проверьте ограничения sandbox

Sandbox аккаунта SES и mailbox simulator — разные понятия. AWS указывает, что статус sandbox определяется отдельно для каждого региона. В sandbox можно отправлять только на верифицированные адреса или домены, кроме адресов симулятора. Production access снимает это ограничение получателей, но требования к идентичностям отправителя сохраняются. Основание — Request production access.

Адрес LDM является внешним получателем, а не адресом симулятора SES. Простое добавление его в запрос не делает отправку допустимой для аккаунта в sandbox. Проверьте регион и разрешения используемого аккаунта. Если ограничения мешают законному тесту, пройдите предусмотренную AWS процедуру получения production access. Не пытайтесь обходить проверку адресатов.

Подготовьте проверку реального письма

1. Выберите сообщение и конкретный вопрос

Начните с одного типа письма: чека покупки, уведомления об аккаунте или подписной рассылки. Вопрос «Куда попадает этот чек при текущем маршруте?» позволяет подготовить проверку. Вопрос «Хорош ли SES?» слишком широк для небольшой панели.

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

2. Зафиксируйте маршрут

Запишите регион AWS, идентичность отправителя, окружение приложения и способ подачи сообщения: SMTP или API. Сохраните сведения о configuration set и маршрутизации, если они используются, а также версию шаблона и настройки отслеживания.

Ручное письмо из консоли может быть полезным отдельным опытом, но не воспроизводит автоматически работу рендера и очереди приложения. Одинаковый видимый From не доказывает, что проверен тот же путь. В записи теста укажите, какая часть рабочего процесса реально участвовала.

3. Отдельно проверьте обработку событий

Выполните необходимые сценарии симулятора и изучите результат в приложении. Пометьте их как simulator tests. Не смешивайте адреса симулятора и LDM в одной итоговой оценке: эти группы отвечают на разные вопросы.

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

4. Получите адреса текущего теста

Откройте Inbox Placement by LDM, укажите настоящий адрес отправителя и используйте выданные для этой проверки адреса. Интерпретируйте результат по методологии LDM.

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

5. Отправьте новый оригинал

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

Используйте обычный код формирования и отправки, осознанно заменив только получателей на тестовый набор. Сохраните необходимые заголовки и отписку. Запишите идентификатор задания, результат подачи, время и доступные идентификаторы письма. Остановите ограниченное задание после предусмотренных отправок.

6. Сопоставьте два вида наблюдений

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

В LDM отсутствующий или неопределённый результат не означает Spam. Promotions и похожие категории — места получения, отличные от основной Inbox и Spam. Суточное наблюдение проверяет ту же полученную копию, а не отправляет новое письмо на каждой отметке. Сохраняйте папку вместе с временем её подтверждения.

Условный пример

Команда проверяет письмо с чеком. Симулятор подтверждает, что приложение обрабатывает событие успешной доставки. Затем отдельная реальная отправка даёт результаты на шести внешних ящиках: три копии в основной Inbox, одна в Promotions, одна в Spam, ещё одна не найдена.

Это условные числа, не измеренный результат SES. Получены пять копий. По формуле LDM доля основной Inbox равна трём, делённым на пять, то есть 60%; покрытие — пять полученных копий из шести выбранных адресов. Одна фраза «доставляемость 60%» скрыла бы и знаменатель, и отсутствие наблюдения.

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

Ограничения вывода

Небольшая панель не воспроизводит историю, правила и будущие действия каждого клиента. Она также не доказывает, что причиной стал конкретный термин, ссылка или сам SES. Аутентификация и наблюдаемая папка отвечают на разные вопросы.

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

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

Успешный симулятор означает попадание в Gmail Inbox?

Нет. Он подтверждает выбранный сценарий симуляции. Для вывода о папке Gmail нужна настоящая отправка на внешний адрес и соответствующее наблюдение в ящике.

Можно ли использовать LDM в sandbox SES?

Только если получатели удовлетворяют ограничениям SES. Обычные адреса LDM не являются адресами симулятора. Проверьте статус аккаунта в используемом регионе и поддерживаемую процедуру доступа.

Отправлять из консоли или приложения?

Используйте путь, который отвечает на ваш вопрос. Для чека приложения проверяйте его собственный рендер и отправку. Опыт только через консоль обозначьте отдельно.

Нужно убрать трекинг или отписку?

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

Как описывать результат, который позже изменился?

Сохраняйте подтверждённую последовательность и время. Не предполагайте неизменность папки между проверками. Более поздняя ошибка наблюдения не подтверждает текущее положение копии.

Проверьте реальный маршрут

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

Первичные источники

Live Direct Marketing