Полный гайд по интеграции на примере Mindbox
11 февраля 2025
Как внедрить CDP в срок и без лишних расходов — полный гайд на примере Mindbox
Интегрировать CPD легко, если компания использует для продаж только сайт. Задача усложняется, если нужно подключить также кассы, мобильное приложение, мессенджеры, а еще соблюсти требования службы безопасности. Но при тщательной подготовке и такое внедрение проходит гладко.
В гайде рассказываем, что важно предусмотреть на каждом из этапов внедрения: от подготовки до запуска механик и оценки их эффективности. Материал посвящен интеграции с Mindbox, но описанные принципы можно применять для другой платформы.
Главный эксперт материала — менеджер по успеху клиентов Mindbox Георгий Россинский. Он уже 11 лет помогает компаниями внедрять Mindbox. В его портфолио такие крупные проекты, как «Ригла», Burger King, Modis. Со стороны бизнеса об интеграции рассказали эксперты из компаний «Вита», «Тануки», Poison Drop, MoneyMan, XCOM-SHOP, Viva La Vika, NBCom Group.
Дисклеймер: это очень большой материал, практически «Война и мир». Только главные враги тут — ошибки в данных, отсутствие четкой коммуникационной стратегии и приоритизации механик. Для удобства поделили статью на 13 тактических шагов, которые точно помогут одержать победу в борьбе за полезный маркетинг (и при этом не устроить пожары).
Содержание:
Скорость интеграции напрямую зависит от подготовки. Важно заранее определить бизнес-цели и составить список необходимых коммуникаций. Следующий шаг — понять, какие данные потребуются для запуска и откуда их можно передавать в CDP. Также важно выделить время сотрудников: понадобится руководитель интеграции (project manager), разработчики и маркетолог.
Если все ресурсы есть, внедрение CDP пройдет быстро. Чтобы начать отправку массовых рассылок, хватит двух дней. Для переноса всех механик часто уходит до двух месяцев. Если нужно также запустить программу лояльности, стоит заложить в среднем три-четыре месяца.
У крупного бизнеса и компаний с нестандартной бизнес-моделью сроки могут быть больше — из-за сложных процессов и структуры данных. Но этапы подготовки для них те же.
Шаг 1. Определить цели и метрики
До интеграции нужно определить цели и составить список механик, которые помогут этих целей достичь. Список стартовых механик поможет понять, какие данные передавать в CDP в первую очередь.
Сформулировать цели и метрики
Кто. Бизнес-заказчик.
Вначале нужно определить верхнеуровневые метрики прямого маркетинга. Для онлайн-магазина это, скорее всего, монетарные показатели: выручка или товарооборот. А вот медиа может сосредоточиться на росте активной аудитории. Как правило, главную метрику декомпозируют на несколько прокси-метрик. А на них уже напрямую влияют с помощью коммуникаций.
Декомпозиция метрик на примере кейса COZY HOME — упрощенная схема. Чтобы увеличить эти метрики, COZY HOME внедрил узкосегментированные акции
Главная метрика может меняться со временем в зависимости от целей бизнеса. Например, первой целью при запуске программы лояльности может быть рост ее проникновения в чеки. А затем можно переключиться на монетарные показатели, например частоту покупок и средний чек.
Наша цель как бизнеса — увеличивать выручку. Мы делаем это в том числе повышая частоту покупок.
В NBCom Group входит несколько сетей по продаже техники, причем конкуренция между ними минимальная. Поэтому повышаем частоту покупок за счет перетока клиентов между брендами. Для этого внедрили единую программу лояльности. Так, к моменту интеграции с Mindbox мы определили бизнес-цели и механики, которые помогут их добиться. Мы уже отправляли рассылки через платформу — оставалось интегрировать ее с 1С. Причем важно было сделать это малой кровью: ресурс разработчиков 1С дорогой.
В результате интеграция заняла четыре месяца — во многом благодаря нашему менеджеру, которая написала подробное техническое задание для разработки и помогла настроить условия программы лояльности.
Уточнить цели
Кто. Бизнес-заказчик вместе с консультантом по внедрению Mindbox.
На этом этапе важно критически оценить поставленные цели и понять, насколько они реалистичны. Если потребуется — пересмотреть их.
Как оценить реалистичность целей:
- Изучить бенчмарки по индустриям. Например, в исследовании Mindbox «Выручка email и мобильных пушей по индустриям».
- Посоветоваться с консультантом Mindbox. У консультанта есть насмотренность — полезно обсудить с ним бизнес-цели и гипотезы.
Для постановки целей можно использовать методологию OKR (objectives and key results). Она помогает связать цели маркетинга и CRM с целями бизнеса и удерживать фокус на них в течение года.
Шаг 2. Определить ответственного за интеграцию и найти ресурсы
Кто. Бизнес-заказчик.
В первую очередь нужно назначить руководителя интеграции — это связующее звено между бизнесом и разработкой. Он ставит бизнес-задачи и определяет, какие данные нужны для их выполнения. Лучше всего на эту роль подходит project manager — человек, который сможет собрать команду, проконтролировать сроки и декомпозировать цели бизнеса до конкретных технических задач.
Впрочем, отвечать за интеграцию могут и другие сотрудники: директор по маркетингу, CTO, руководитель e-commerce, CRM или разработки, а также опытный маркетолог или аналитик. Главное — чтобы у специалиста была экспертиза и в маркетинге, и в ИТ.
Помимо руководителя проекта понадобятся программисты, которые построят интеграцию. Их количество и специализация зависят от того, какие системы будут интегрироваться с Mindbox. Для интеграции сайта нужны фронтенд- и бэкенд-разработчики, для приложения — мобильный разработчик.
Если сил внутренней разработки недостаточно, можно привлечь подрядчика — системного интегратора. Порекомендовать его сможет консультант по внедрению Mindbox. А определить точный объем задач для подрядчика поможет менеджер Mindbox после подготовки технического задания.
Шаг 3. Выбрать и описать механики
Кто. Ответственный за интеграцию.
Выбор механик. Механики выбирают исходя из приоритетных целей. Например, если задача — удерживать рекламный трафик, то сначала стоит запустить welcome-сценарии. Если важно повысить количество онлайн-заказов, то нужно настроить персонализацию сайта.
Описание механик. Без подробного описания механик можно упустить важные детали. Например, забыть, что в реактивационные рассылки нужно подставлять балльные счета. В таком случае механики не будут работать корректно — бизнес потеряет деньги, а разработчикам придется настраивать передачу данных в авральном режиме.
Описание механик должно быть максимально конкретным, чтобы по нему можно было подготовить техническое задание для разработчиков:
Абстрактно
Конкретно
Запустить цепочку реактивации
Отправить письмо с дополнительными баллами клиентам, которые не покупали у нас три месяца, в письмо подставить балльный счет
Если бизнес не запускает механики с нуля, а переносит с прошлой платформы, их подробное описание особенно важно. Оно позволит сделать переход бесшовным для клиентов, и безболезненным для компании. Так, пауза в отправке массовых писем вряд ли ударит по выручке. Другое дело — сервисные письма: о заказах, доставке или начислении баллов. Даже короткий сбой в их отправке может обернуться финансовыми потерями.
Также будет полезно приложить скриншоты рассылок. Это поможет менеджеру Mindbox составить верное техническое задание для разработчиков и не упустить детали. Например, если в рассылке о заказе выводится время работы магазинов, значит, эти данные тоже нужно передавать в Mindbox.
Описание акций Poison Drop для подготовки технического задания. Полная версия — в документе
Шаг 4. Приоритизировать запуск механик
Кто. Ответственный за интеграцию.
Поскольку интеграция CDP проходит поэтапно, важно приоритизировать механики. Удобнее всего разбить их на три группы:
- Ключевые механики, которые нужно реализовать в первую очередь. Например, сервисные коммуникации, которые сопровождают оплату заказов.
- Механики второго приоритета. Например, триггерные цепочки, которые бизнес раньше не использовал.
- Механики, которые не нужны на старте, но потом будут критично важны. Например, рассылки по узким сегментам клиентов — в зависимости от предпочитаемых товаров.
Шаг 5. Выявить риски: что может помешать запуску механик
Кто. Ответственный за интеграцию вместе с консультантом по внедрению.
После того, как бизнес подготовил детальное описание механик, задача вендора — определить необходимый набор данных для их запуска, а также подсветить возможные риски, связанные с передачей данных.
Допустим, аптека хочет сообщать клиентам о том, что их накопленные баллы скоро спишутся. При этом расчет баллов происходит на внутреннем процессинге аптеки, и данные из него передаются в Mindbox только раз в сутки. Поэтому есть риск прислать клиентам неактуальные данные по баллам. Возможные решения: передавать данные в режиме реального времени, перевести процессинг лояльности на Mindbox или отказаться от механики.
Шаг 6. Подготовиться к передаче данных: определить их состав, формат, источники
Основные задачи на этом этапе:
- определить список нужных данных, например дату рождения клиента или дату последней покупки;
- отсечь лишние. Например, если у компании нет корпоративных рассылок для сотрудников, то не нужно передавать их данные в CDP;
- придумать архитектуру хранения данных в Mindbox.
Как правило, на подготовку уходит около недели.
Определить набор данных и отказаться от лишнего
Кто. Менеджер Mindbох.
Менеджер Mindbox изучает описание механик, соотносит их с логикой платформы и формирует список необходимых данных.
Благодаря менеджеру Mindbox нам удалось запуститься без критических ошибок: он подсветил узкие места. Например, указал на блокирующие моменты, связанные с кассовым ПО. На начальном этапе интеграции мы их проигнорировали — пришлось исправлять позже. Также менеджер подсказал, что выбранный способ регистрации карт на сайте мог стать источником фрода — тогда мы поменяли форму регистрации.
Во время интеграции от меня как руководителя требовалось только обозначить общее видение процесса и определить, какие источники данных подключать в первую очередь. Все технические вопросы были на стороне наших ИТ-специалистов и Mindbox.
Иногда компании хотят передавать в CDP как можно больше данных, потому что так технически проще или потому что рассчитывают использовать их в будущем. Но это ошибочная стратегия. Если передавать ненужные данные в Mindbox, нагрузка на проект увеличится, использование CDP подорожает, а расчет сегментов и фильтров замедлится. Поэтому важно отсечь ненужные потоки данных. Определить этот «балласт» поможет менеджер Mindbox.
Выбрать формат данных
Кто. Ответственный за интеграцию и менеджер Mindbox.
На скорость и логику работы механик влияет также формат данных. Это то, каким способом CDP будет обрабатывать ту или иную информацию. В Mindbox есть несколько форматов для передачи данных. Среди них:
- «строка и идентификаторы» — для передачи любых символов;
- «перечисление» — любые символы, с возможностью выбрать нужный вариант из списка;
- «логический» — для передачи значения «или/или»;
- «целочисленный» — для передачи целых чисел;
- «дата» — для передачи даты.
Строковый формат считается самым универсальным: в нем можно передавать любые значения до тысячи символов. Поэтому есть соблазн использовать его в любом нестандартном случае. Но это не всегда надежное решение:
- строковые данные обрабатываются медленнее других форматов — посимвольно;
- возможность вводить любые данные приводит к ошибкам из-за человеческого фактора, и спустя время механики перестают работать корректно.
Распространенная ошибка — использовать для городов строковый формат вместо перечисления. При ручном вводе в базу попадают самые разные варианты написания: «Москва», «гор. Москва», «г. Москва». В итоге использовать географию клиента в рассылках просто невозможно.
Подобрать оптимальный формат данных помогает менеджер Mindbox. Например, для NPS-опроса — поле со значениями от 1 до 10, а для конечного списка услуг, который будет пополняться редко или никогда, — фиксированный справочник.
Я советую сразу обращаться к менеджеру Mindbox, если у вас есть сомнения в выборе формата. Дело в том, что изменить системное имя и формат поля просто так нельзя: если оно где-то используется в фильтре или подставляется в рассылку, то для переименования или смены формата его придется удалить, завести заново и еще раз указать в нужных фильтрах. Например, мы случайно завели одно поле два раза и назвали его чуть по-разному. Пришлось удалять этот параметр изо всех 20 коммуникаций и прописывать заново. На это ушло около 2-3 часов.
Нарисовать схему интеграции
Кто. Ответственный за интеграцию или разработчик.
Как правило, данные передаются в Mindbox из разных источников. Например, данные о заказах — с бэкенда сайта, а по клиентам и регистрациям в программе лояльности — из внутренней CRM. Важно понять, как будут идти потоки данных. В идеале их нужно визуализировать — это не только упростит интеграцию, но и поможет в случае чего найти место поломки.
На Mindbox мы переезжали с другой платформы. Начали с того, что описали все запущенные сценарии. Затем несколько раз созванивались с менеджером, чтобы понять, как уложить существующие механики в логику Mindbox: какие запросы делать, какие данные передавать.
По итогам этих обсуждений я нарисовала схему, описывающую бизнес-процессы и передачу данных. Эта схема облегчила интеграцию для разработчиков и позволила нам обнаружить узкие места. Например, выяснилось, что в Mindbox корзина считается брошенной, если с момента добавления товара в нее прошло не менее 30 минут. Мы хотели отправлять мобильный пуш клиентам раньше, поэтому нам нужно было передавать в платформу дополнительное действие.
Схема передачи данных «Тануки»
Шаг 7. Определить логику хранения данных в Mindbox
Кто. Аналитик или разработчик вместе с менеджером Mindbox.
Логика хранения данных в Mindbox строится на нескольких основных сущностях: клиенты, заказы, товары и точки продаж.
Клиенты
Для описания клиентов, как правило, используются стандартные поля: телефон, email, имя, пол и дата рождения, действия. Дополнительные поля определяются спецификой бизнеса: у детского магазина — количество детей, у зоомагазина — кличка питомца, у продавца косметики — тип кожи.
Профиль клиента спортивного магазина c заполненными дополнительными полями, включая любимый вид спорта и наличие детей
Заказы
Стандартные поля для этой сущности: купленный товар, его стоимость и количество. В зависимости от специфики бизнеса могут быть и дополнительные поля. Например, при продаже лицензий важно учитывать срок их действия.
Товары
Для описания товаров используется общепринятая модель данных — yandex market language (YML). В ней каждый товар относится к товарной группе и категории. При этом можно передавать любые свойства товара: цвет, размер, номер модели.
Точки продаж
Обязательны название и идентификатор. Дополнительно можно передавать, например, адрес и часы работы.
Хотя этот стандартный набор сущностей больше подходит под e-com-процессы, его можно адаптировать и под другие бизнес-модели, даже самые нестандартные. Например, при интеграции «Т—Ж» статьи положили в раздел «продукты». Когда статья публикуется в журнале, она становится новым «продуктом» в Mindbox, и потом CDP может добавить ее в рассылку.
Шаг 8. Проверить качество данных и настроить их передачу в Mindbox
Качество данных оценивают перед тем, как автоматизировать их передачу в CDP. Каждый поток — клиенты, заказы, магазины — проверяют отдельно. Чтобы отловить все ошибки, нужно в среднем до двух недель.
Полезно также провести гигиену клиентской базы: чтобы не передавать в CDP невалидные контакты. Это нужно сделать заранее и заложить до месяца.
Рассмотрим последовательность действий.
Провести упреждающий аудит клиентской базы
Кто. Ответственный за интеграцию или маркетолог.
Аудит поможет обнаружить невалидные или дублирующиеся контакты, а также неактивных клиентов. Это необязательный, но желательный шаг, который упрощает интеграцию меньше ошибок будет найдено на следующих этапах
На поиск ошибок в передаче данных у меня ушел примерно месяц. Вот что я делала:
Детализировала CJM. Клиентский путь поделили на последовательные шаги. Например, заполнить отдельные поля регистрации или проставить согласия на коммуникации. Всего таких шагов получилось более 60. Особенно детализировали процесс регистрации: она состоит из нескольких этапов, на которых мы собираем много клиентских данных. Важно последовательно передавать их в CDP.
Чтобы проверить корректность интеграции, мы составили список нереалистичных сценариев — того, что никак не может произойти в продукте. Например, пользователь прошел первый и третий этап регистрации, но пропустил второй. Это было нужно, чтобы отследить, не прокрадываются ли такие ошибки в Mindbox.
Изучала исторические данные — обращения клиентов в службу поддержки, описания всех багов в архивах разработки. Это помогло лучше понять, что еще может пойти не так, и перепроверить интеграцию.
Например, на этом этапе мы выявили дубли в базе: один номер телефона мог был привязан к нескольким клиентам. При этом тогда мы совсем не передавали дублирующиеся контакты в Mindbox. Из-за этого подписчики не получали коммуникации, хотя давали согласие на них. Мы доработали логику дедубликации на своей стороне, и теперь рассылки приходят всем заинтересованным клиентам.
Отловить ошибки на тестовой выгрузке
Кто. Ответственный за интеграцию и разработчик совместно с менеджером Mindbox.
Тестовая выгрузка помогает проверить наличие и корректность данных. Допустим, зоомагазин хотел указывать в письмах клички питомцев, но выгрузка показала, что они заполнены только у 5% клиентов. Тогда можно вовремя скорректировать план: либо отказаться от механики, либо собрать данные. Например, прописать в скриптах для кассиров, что они должны уточнять кличку.
В тестовой выгрузке должны быть все данные со всеми допустимыми значениями, которые бизнес планирует передавать в Mindbox. Имеет смысл сначала выгрузить совсем небольшое количество записей: 10 или 100. При таком объеме это займет буквально минуту.
Если с названиями все в порядке, можно выгрузить около тысячи строк. На этом этапе обычно всплывают основные ошибки:
Дубли
В Mindbox у каждого клиента должен быть уникальный email и номер телефона. Если загрузить клиентов с одинаковыми контактами, они объединятся. В большинстве случаев это решает проблему дублей: с одним номером телефона на сайте и в офлайн-магазине обычно зачастую регистрируется один и тот же клиент. Но если дублей много (более 5%), вероятно, с данными что-то не так — и тогда бизнес рискует потерять клиентов при объединении.
Если дублей много, есть два основных решения:
- с помощью разработчиков искать и исправлять ошибки в обработке или импорте данных;
- привязывать email или телефон к наиболее активному клиенту — тому, который последним заходил на сайт.
Перед запуском первых рассылок мы привели базу в порядок. Поскольку контакты хранились в разных сервисах и зачастую повторялись, нужно было провести дедубликацию. Мы перенесли контакты изо всех предыдущих сервисов в Mindbox. Он автоматически нашел дубли и объединил данные таких клиентов — в базе осталось 30 тысяч уникальных подписчиков. Благодаря дедубликации подписчики больше не получают одни и те же письма несколько раз.
Аномалии
Как правило, к аномалиям относят данные со слишком высокими или, наоборот, низкими значениями. Например, клиент с 50 заказами в день — аномалия. Это может объясняться технической ошибкой, а может — тем, что кассир проводит по своей карте все заказы без программы лояльности. Таких клиентов лучше удалить. А чтобы ситуация в будущем не повторялась — исправить ошибку или изменить бизнес-процессы, например запретить кассирам оформлять на свою карту заказы клиентов без лояльности.
Мусорные данные
Частые примеры — непонятный набор символов вместо номера телефона или имени. Мусорные данные обязательно нужно исправить или удалить. Иначе механики будут работать некорректно: вместо обращения по имени в SMS клиент увидит случайные символы.
Бывают и совсем анекдотичные случаи: на одном проекте менеджеры продаж часто указывали email как «номер телефона@mail.ru». Это происходило потому, что email был обязательным полем, а контроля за качеством данных не было. Конечно, такие данные не стоит заливать в Mindbox: при отправке по некорректным адресам письма начнут попадать в спам и ухудшат репутацию домена.
Определить недостающие данные
Кто. Менеджер Mindbox.
Менеджер сверяет тестовую выгрузку со списком кампаний и ищет недостающие данные. Например, продавец ПО хочет отправлять уведомления об окончании лицензии. Тогда важно, чтобы в выгрузку попадали данные о сроке ее действия. Если их не будет, менеджер укажет на это.
Часто недостающие данные можно обнаружить только по косвенным признакам. Так, один из клиентов Mindbox считал, что у него есть всего три типа дисконтных карт. При выгрузке оказалось, что их 10 — часть лежала в старой системе, про которую все забыли. Найти это помог анализ выгрузки.
Определить, нужны ли доработки для передачи данных
Кто. Менеджер Mindbox.
Иногда для передачи данных могут потребоваться доработки на стороне бизнес-заказчика. Например, если компания хочет внедрить омниканальную программу лояльности, ей нужно передавать в Mindbox все товары. А справочники офлайн- и онлайн-товаров разделены — это одна из самых частых проблем. В этом случае их нужно объединить для передачи в Mindbox.
Провести повторный анализ выгрузки
Кто. Менеджер Mindbox.
Часто бывает, что исправление одной ошибки ломает что-то другое, — проверяем данные, пока не убедимся в их корректности.
Шаг 9. Подготовить техническое задание и приоритизировать задачи для разработчиков
Кто. Ответственный за интеграцию и менеджер Mindbox.
Последний шаг перед запуском механик — разделить потоки данных на основные и вспомогательные. Такая приоритизация помогает ответственному спланировать этапы интеграции и понять, где найти нужные данные во внутренних системах. На ее основе менеджер Mindbox готовит для разработки техническое задание на интеграцию.
Данные
Приоритет
Пример данных
Основные: для запуска ключевых механик
Передавать в Mindbox в первую очередь
Перечень магазинов: чтобы сообщать о наличии в них товара
Вспомогательные: для механик, которые можно запустить позже
Передавать на втором этапе интеграции
Наличие у магазина признака «круглосуточный»: чтобы сделать письма еще более информативными
Таблица, которой пользуется ответственный за интеграцию
У нас был ограничен ресурс разработки, поэтому мы разделили интеграцию на два этапа: товарно-акционный и коммуникационный. Нам важно было как можно скорее начать выдавать скидки на товары и заводить промокоды. А коммуникации могли подождать: у нас уже был инструмент для рассылок.
На первом этапе интегрировали Mindbox c сайтом, приложением и 1С, на втором — перенесли в платформу email, SMS и вебпуши.
Модули Mindbox могут существовать отдельно друг от друга, но мы решили подключить весь Mindbox сразу. В результате подрядчики не справлялись с потоком задач, сроки начали смещаться, мы не успевали нормально протестировать интеграцию. Из-за этого мелкие ошибки продолжали всплывать в течение полугода.
Имело смысл интегрировать модули постепенно, начиная с самых важных для бизнеса: сначала рассылки, потом персонализация сайта и так далее. Это позволило бы нам спокойно находить и исправлять ошибки.
Шаг 10. Автоматизировать передачу данных в Mindbox
Кто. Ответственный за интеграцию, разработчики и менеджер Mindbox.
На этом этапе задачи распределяются так:
- разработчики пишут интеграцию;
- ответственный следит за сроками, собирает информацию обо всех возникающих сложностях и советуется с менеджером Mindbox;
- менеджер Mindbox выступает в качестве консультанта, проводит регулярные встречи с клиентом и помогает разбирать сложные вопросы. Они могут быть любыми — от того, как делать запрос по API, до уточнения технической документации платформы.
Мы проводим регулярные синки с командой, ответственной за внедрение Mindbox. Важное правило менеджера — не общаться только с разработкой, а всегда привлекать ответственного за бизнес-задачи. Иначе можно рассинхронизироваться.
При этом разработчики могут задавать вопросы и напрямую. Чтобы получать письменные ответы максимально быстро, важно не только указывать техническую проблему, но и объяснять, какую задачу надо решить.
Неудачный запрос
Понятный запрос
Вызываю операцию на странице категорий, но ничего не работает.
Тестируем интеграцию для механики «Просмотр категории»: вызов уходит, но события не появляются в Mindbox.
В первом случае описывается только техническая проблема, во втором — задача, которую разработчик пытается решить
Mindbox дает два месяца без тарификации, чтобы интегрировать сервис. Чтобы уложиться в этот срок, я советую сначала сделать самое важное. Мы начали с того, что:
— передали в Mindbox всю базу клиентов и данные об их заказах;
— настроили ключевые акции с промокодами, например скидку ко дню рождения.
А вот без скидки дня и реферальной программы можно было жить несколько месяцев — их отложили до окончания основного этапа интеграции.
Шаг 11. Провести первую сверку данных, а потом сделать ее систематической
Доработки на сайте, изменение структуры данных или бизнес-процессов могут сломать интеграцию. Поэтому важно время от времени проверять чистоту передаваемых данных. Во время запуска механик это нужно делать ежедневно.
Во время интеграции — ежедневные сверки
Кто. Менеджер Mindbox, маркетолог и разработчик.
Сначала менеджер Mindbox самостоятельно проверяет качество данных и параллельно обучает маркетолога пользоваться инструментами платформы.
Также для исправления ошибок нужно предусмотреть ресурс разработки. Понадобится по крайней мере один специалист, готовый подключиться к решению проблемы в течение спринта.
Первые недели важно ежедневно сравнивать данные из внутренних систем компании и из Mindbox, чтобы своевременно отлавливать расхождения. Достаточно проверять несколько ключевых показателей. Например, если мы импортировали клиентов, то во внутренней базе и в Mindbox сопоставляем:
— общее количество клиентов;
— количество клиентов с разрешением на коммуникацию;
— объем переданных дополнительных данных (город, дата рождения).
Для отслеживания ошибок в Mindbox есть специальный инструмент — мониторинг интеграций:
Страница показывает количество ошибок в каждой интеграции
Если ошибок — единицы на десятки тысяч вызовов платформы, то все в порядке, это считается нормой. Но если статус горит красным с пометкой «много ошибок», обязательно нужно найти их причины, иначе механики будут работать некорректно.
Еще один способ отслеживать ошибки — фильтры. Их основная задача — сегментировать базу, но они подходят и для поиска аномалий, например фрода. Наконец, можно просто открывать профили случайных клиентов и проверять их.
Иногда я проверяю профили случайных клиентов, и это позволяет отлавливать ошибки. Например, однажды дата-инженеры что-то поменяли в бэкенде и все клиенты стали передаваться с одной датой рождения — 01.01.1970. К счастью, я заметила это и мы быстро исправили ошибку, иначе 1 января клиентам ушла бы рассылка с поздравлением.
После интеграции — сверки хотя бы раз в месяц
Кто. Маркетолог.
Спустя два месяца можно увеличить дистанцию между сверками — до раза в месяц. Через год после завершения интеграции это рекомендуется делать хотя бы раз в квартал.
У нас 8 юрлиц, розничные и интернет-магазины, несколько способов оплаты и доставки, огромное количество акций и бонусов. При этом мы постоянно дорабатываем 1С. Неудивительно, что первое время после интеграции с Mindbox данные между системами терялись или передавались некорректно. Например, мы сталкивались с потерей чеков или некорректной передачей мобильных номеров.
Чтобы избежать таких ошибок, мы еженедельно проводили сверки. Для этого выгружали данные из Mindbox и загружали их в административную панель 1С — она автоматически сравнивает данные и показывает расхождения. На такую проверку уходило около часа.
После полного переезда на Mindbox мы улучшили логику обмена между системами, и теперь расхождения в данных, скорее, редкость. Для профилактики проводим проверки раз в месяц.
Шаг 12. Запустить механики
Кто. Маркетолог и менеджер Mindbox.
Менеджер помогает маркетологу с запуском первых механик. Для базовых, вроде «брошенной корзины», нужно от нескольких минут до нескольких часов. А вот на разработку и реализацию кастомной механики могут уйти недели.
Как правило, первые письма отправляют в тестовом режиме. Так менеджер и маркетолог проверяют, что рассылки формируются корректно.
Есть два способа проверить сценарий. Можно взять случайного клиента и убедиться, что он попал в нужный сценарий. Например, отфильтровать клиентов с брошенной корзиной и посмотреть, приходили ли им соответствующие письма. Если нет, значит, с интеграцией что-то не так. Также можно открыть сценарий и посмотреть, сколько клиентов попало в сценарий и как они его проходили:
Статистика позволяет увидеть движение клиентов по воронке. Причины остановки можно увидеть, кликнув на нужный блок
Когда ошибки найдены, менеджер и маркетолог исправляют их и запускают «боевые» рассылки.
По возможности после запуска сценариев стоит выделить одну-две недели на их мониторинг. Нужно проверить, насколько корректно прописана их логика, правильно ли подставляются параметры в персонализированные рассылки.
Например, мы обнаружили, что часть клиентов не получает нужные письма. Причины было две:
— часть данных терялась при передаче;
— условия срабатывания триггера были скопированы из прошлой платформы и в Mindbox работали некорректно.
Мы также сравнивали количество отправок с прошлой платформой — это помогло заметить отклонения. Но даже без исторических данных полезно сравнить ожидаемое количество отправок с фактическим.
Чтобы проверить, корректно ли срабатывают акции, начисляются скидки и отправляются мобильные пуши, мы выделили несколько телефонных номеров и проверили на них все возможные сценарии. Например, клиент попадал под условие акции — ему должны были начислиться баллы. Если этого не происходило, тестировщик анализировал, что пошло не так.
Причины могли быть разными: маркетинг неверно завел условия акции или нужные данные не передаются из бэкенда во фронтенд. Если не могли найти причину на своей стороне, обращались к менеджеру Mindbox. На проверку и исправление всех запросов ушло около трех недель.
Шаг 13. Регулярно оценивать результаты
Кто. Ответственный за интеграцию, маркетолог или CRM-lead.
Смысл интеграции — не в передаче данных и даже не в механиках, а в том, чтобы достичь бизнес-целей. Чтобы понимать, движется ли бизнес в правильном направлении, и корректировать стратегию, важно оценивать результаты.
По опыту наших клиентов, ключевые результаты имеет смысл отслеживать ежемесячно — по отчетам Mindbox, например отчет по целям, или в дашбордах на стороне компании. Такой подход позволяет увидеть динамику.
Долгосрочная цель единой программы лояльности — увеличивать retention за счет обмена клиентами между сетями. Оценивать влияние на retention еще рано: мы ожидаем, что клиенты будут возвращаться каждые 14 месяцев, и пока не прошел даже один период. Выводы сможем сделать на второй год действия новой программы лояльности.
Мы не сравниваем показатели прежней программы лояльности с новой. Оцениваем эффект от новой программы лояльности относительно ее старта: сравниваем первое и второе полугодие с программой лояльности. Дело в том, что пик продаж приходится на предновогоднее время и гендерные праздники, в остальное время спрос ровный. Так как оба пика приходятся на разные полугодия, мы можем сравнивать их друг с другом.
Мы видим, как растет переток клиентов между сетями: количество участников программы лояльности, которые заработали баллы в одной сети и потратили их в другой, выросло с 2% до 3%. Прирост в один процентный пункт может показаться незначительным, однако стоит учитывать, что участников программы лояльности стало в два раза больше, поэтому в нашем случае это огромное количество клиентов.
Кстати, не только резкое снижение, но и рост — повод бить тревогу. Это может означать, что интеграция сломалась: бизнес получает некорректные данные и принимает на их основе неверные решения. Например, на одном из проектов обнаружили, что выручка от email-канала выросла с нескольких миллионов до нескольких миллиардов. Оказалось, что вместо рублей начали передавать тысячи.
Бонус. Что может помешать достигнуть результатов и как этого избежать
Важно регулярно отслеживать изменение бизнес-метрик в динамике и вовремя замечать расхождения между планом и фактом. Основных причин всего три:
Поломки в интеграции. Так, у интернет-магазина OLDI стала падать доля email-канала в общей выручке. Оказалось, что разработчики обновили сайт и не все файлы cookie передавались в Mindbox. Из-за этого отправлялось меньше писем о брошенном просмотре и брошенной корзине — поэтому бизнес недополучал прибыль.
Чтобы вовремя заметить неполадки в интеграции, нужно регулярно проводить сверку данных.
Неправильная настройка механик. У сервиса бронирования экскурсий Tripster не работала реактивация: лишь малый процент оттока удавалось вернуть. Оказалось, что после прохождения по цепочке клиенты не переводились в другие сегменты на протяжении месяца и не получали коммуникаций в этот период. Исправили ошибку в логике — реактивация стала эффективнее.
Чтобы замечать такие вещи, стоит время от времени проводить технический аудит CRM-маркетинга и проверять механики, если ее эффект ниже ожиданий.
Спорные гипотезы. Частая и пагубная практика: отправлять больше рассылок для увеличения прибыли. Обычно это приводит к прямо противоположному эффекту: растут отписки, а выручка на получателя сокращается.
Сервис поиска подработки MyGig испытал это на себе: желание активнее общаться с пользователями, чтобы конвертировать их в первую смену, привело к тому, что за полгода база сократилась в четыре раза. Когда сервис стал отправлять меньше писем, количество отписок снизилось на 38,5%, а конверсия в завершение смены выросла в три раза.
Чтобы эффективно регулировать коммуникационную нагрузку, важно следить за показателями рассылок: bounce rate и spam rate. Проверять эти показатели можно в постмастерах почтовых сервисов, а также в отчете «Здоровье email» в Mindbox.
Главное из материала
- Перед внедрением CDP важно определиться с целями, которые бизнес планирует достичь с помощью Mindbox. Это поможет составить список механик и, соответственно, данных, которые нужно передавать в платформу.
- Для интеграции потребуются проектный менеджер и разработчики. Важно предусмотреть это заранее. Иначе есть большой риск затянуть интеграцию.
- Не надо передавать в CDP лишние данные. Они делают подписку на Mindbox дороже, создают ненужную нагрузку и замедляют скорость расчета сегментов и работу фильтров.
- Важно определить, какие механики нужны в первую очередь, а какие потом. Это позволит распределить нагрузку на разработчиков и заложить время на исправление ошибок.
- После интеграции нужно постоянно контролировать качество передаваемых данных. Интеграцию могут сломать доработки на сайте, изменение структуры данных или бизнес-процессов, да и просто ошибка разработчика, от которой никто не застрахован. Поэтому нужно проводить регулярные сверки на всем протяжении работы с Mindbox. Первые несколько месяцев — ежедневно, потом ежемесячно, спустя год — хотя бы раз в квартал.
- Ключевые результаты нужно отслеживать ежемесячно — по отчетам Mindbox, например, отчет по целям, и в дашбордах на стороне компании. Отчеты позволяют увидеть динамику, а также сравнить периоды.
