Переезд с другой платформы

Иногда текущий сервис для отправки рассылок не устраивает клиента. И это нормально. Смена платформы бывает нужна по разным причинам. Основные три — это:

Техническая

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


Плохая репутация текущих серверов

Бывает и так, что у серверов платформы плохая репутация, если их клиенты злоупотребляют спамом. В этом случае компании точно нужно переходить на сервис с хорошей репутацией серверов, так как это напрямую влияет на доставляемость писем.


Рост бизнеса

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

Самый простой пример — небольшие компании, которые синхронизируются с сервисами рассылок по имейлу. Когда они растут, то появляются внутренние CRM-системы с id и ключами клиента. В этом случае нужна более серьёзная интеграция и не каждая платформа может работать с внешними идентификаторами.

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


Шаг 1. Перенести базу имейлов

Транспортировка информации о подписчиках делится на 2 типа: перенос уже накопленной базы и перенос всех новых с момента запуска.

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

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


Шаг 2. Отправить массовую рассылку с новой платформы

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


Шаг 3. Перенести все цепочки и триггеры

Но не все сразу, особенно, если у вас их много. Начните с 10-15 в неделю и протестируйте, как они работают на новой платформе. Если все прошло хорошо — переносите оставшиеся триггерные коммуникации.

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

Для такого кейса у нас есть пользовательская дата, которая решает эту проблему.


Шаг 4. Выключить API-интеграцию со старой платформой

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

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