Почему мы отказались от популярной ESP при запуске триггерных рассылок: кейс Vinfixer
При выборе ESP часто смотрят на узнаваемость платформы или ее позицию на рынке. Но на практике популярный сервис не всегда подходит под конкретную маркетинговую стратегию.
Разберем на примере проекта Vinfixer — сервиса проверки автомобиля по VIN-номеру.
Команда пришла с готовой логикой автоматизаций. Но на этапе внедрения выяснилось, что выбранная платформа не позволяет полностью реализовать стратегию.
Контекст проекта
Vinfixer — онлайн-сервис проверки автомобиля по VIN-номеру. К моменту начала работы у команды уже были подготовлены:
- CJM
- логика триггерных сценариев
- условия запуска
- структура писем
Наша задача была технически реализовать стратегию. Изначально для отправки писем планировали использовать SendGrid, и перед началом внедрения мы провели технический аудит платформы.
Что показал технический аудит
1. Порог технического входа
SendGrid предполагает работу через:
- SMTP
- API-настройки
Это нормальный сценарий, если автоматизации поддерживает команда разработчиков. Но в проекте Vinfixer поддержку рассылок планировали вести именно маркетологи.
В таком случае возникали риски:
- зависимость от разработчиков при изменениях,
- усложнение поддержки,
- дополнительная нагрузка на команду.
SendGrid хорошо подходит для:
- транзакционных писем
- масштабных рассылок
Но при реализации триггерной стратегии появились ограничения.
В частности:
- запуск сценариев в основном привязан к попаданию контакта в список;
- ограничена вариативность событийных триггеров;
- нет удобных инструментов проверки условий внутри сценария;
- масштабирование логики усложняет структуру автоматизаций.
Для проекта с поведенческими цепочками это стало критичным.
После аудита мы заново сформировали требования к платформе.
Ключевые критерии:
- глубина триггерной логики
- удобство работы для маркетинговой команды
- масштабируемость
- бюджет
При этом стоимость альтернативных решений была в сопоставимом диапазоне, поэтому цена не стала определяющим фактором.
В итоге мы выбрали ESP с более гибкой системой автоматизаций.
Это позволило:
- настраивать события и ветвления;
- добавлять условия и фильтры внутри сценариев;
- работать с API и динамическими данными;
- передать поддержку автоматизаций маркетологам без зависимости от разработчиков.
В рамках проекта мы:
- адаптировали архитектуру цепочек;
- настроили события и триггеры;
- реализовали передачу динамических данных;
- протестировали интеграцию;
- подготовили документацию для команды клиента.
В результате нам удалось:
- реализовать маркетинговую стратегию без упрощений;
- передать поддержку автоматизаций маркетинговой команде;
- построить архитектуру, готовую к масштабированию;
- выбрать платформу, соответствующую текущей и будущей логике продукта.
Вывод
Этот кейс еще раз показал: при выборе ESP важно смотреть не только на популярность сервиса. Гораздо важнее — насколько платформа соответствует архитектуре автоматизаций и процессам команды.