Драйвер изменений и эксперт в области данных

Бизнес с каждым днем проявлял потребность в грамотном управлении данными. Регулярно требовалось создать отчет или выгрузить базу SQL. Мы решили починить это несовершенство и создать внятную, доступную и гибкую платформу управления данными.

«Ключевой задачей АЭРО в рамках проекта с Кофеманией было стать драйвером изменений. Помочь компании сделать первый шаг в построении data-культуры. Такие проекты делаются по выработанной методологии, которая включает 3 основных этапа: выявление бизнес-ценности, определение технологий и процесса вокруг данных, который необходимо реализовать в компании», – Вячеслав Жуков, Chief Data Officer АЭРО.

Правильно организованное хранилище данных делится на слои. Слои необходимы для оптимизации работы с данными и подготовки аналитической отчетности.

Слоев может быть много. Представьте себе большой завод. На него приезжает сырье, есть несколько производственных линий и в результате – готовая продукция. Так же происходит и с данными! Есть несколько этапов производственного цикла, который делится на слои.

Из источников информации данные попадают на первый этап – слой сырых данных. Задача этого слоя – в одном месте аккумулировать всю приходящую информацию. При этом на этапе задача очистки данных не решается. Данные поступают в первоначальном виде. Почему же важно хранить данные именно в их исходном виде? Чтобы иметь возможность в любой момент поменять расчеты, откатиться назад и сохранять историчность.

Задача первого слоя – выдерживать высокую нагрузку на чтение и сложные аналитические выборки.

К примеру, формулировка такой задачи может быть следующая: необходимо посчитать количество клиентов из, скажем, Смоленска с чеком более 2,500 рублей на выборке из 30 миллионов строк. Одновременно подобных задач может быть множество.

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

В ядре сырые данные превращаются в заготовки. С точки зрения хранилища, этот слой называется DDS. С технической точки зрения, это отдельная база данных, которая содержит связанные друг с другом таблицы с очищенными, нормализованными и дедуплицированными данными. Эти данные обычно хранятся в определенной модели (снежинка, якорная модель, data vault), которая определяется, исходя из бизнес-задач компании, и необходима для того, чтобы быстро добавлять в систему определенные бизнес-сущности.

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

Финальным этапом производственной цепочки хранилища данных является третий слой. Он содержит витрины данных. Это таблицы, которые содержат важную для бизнеса информацию. Например, это может быть конверсия в разрезе по датам или LTV по клиентам. Дальше эта таблица подключается к BI-системе для визуализации или передается в смежные системы, например, CDP и используется как основа сегментации.

Моделирование данных — это создание визуального представления о всей информационной системе компании.

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

Важно, что модель строится не от задачи, а от бизнеса.

У бизнеса есть ряд задач, связанных с конфиденциальностью данных. Часто их решают с помощью продуктов для маскирования и токенизации.

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

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

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

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

Продукты MDM помогают закрыть эту задачу и осуществлять управление основными и справочными данными для снижения рисков.

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

Для решения этой задачи существует data-каталог — некая "википедия" внутри компании, в которой зафиксированы важнейшие бизнес-термины.

Также каталог содержит корректное и подробное описание всей информации, чтобы работающий с ними человек точно понимал, что это именно то, что ему нужно.

Задача

Hoff обратились к нам в октябре 2021 года за корректировкой разметки web-аналитики. После нескольких консультаций стало ясно, что истинный запрос клиента гораздо шире — в области работы с большими данными.

В компании существует два хранилища, на основе которых работает глобальная аналитическая система Hoff:

• Внутреннее, в котором лежат ключевые данные ритейлера (продажи по товарам, регионам и др).

• Облачное DWH (data warehouse), которое использовалось для работы продуктовых и маркетинговых аналитиков. 

Для повышения эффективности и качества работы Hoff собирает большое количество информации: звонки, визиты, обращения, оплаты, действия клиентов на сайте и многое другое. За 5 лет в хранилище накопился внушительный пул данных об онлайн-заказах и поведении пользователей, а также легаси-код, который замедлял выполнение новых аналитических задач.  

Структура хранилища DWH на базе Google Cloud Platform влекла за собой недочеты, которые ставили под вопрос качество собираемой информации. Сырые данные из более чем 10 источников стекались в BigQuery, использовались для 155 дашбордов и занимали 1938 расчетных полей в 42 отчетах. Иногда данные могли противоречить друг другу, что усложняло принятие решений для бизнеса. 

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

Целью проекта стал рефакторинг облачного хранилища. Главной задачей АЭРО было привести онлайн-данные в порядок: создать единые принципы хранения, разработать масштабируемую архитектуру, выстроить правильную систему алертинга для регулярного контроля качества. В общем, сделать облачное хранилище понятным и структурированным источником информации для Hoff. 

Решение

Дискавери-фаза

Начали с анализа старой структуры: требовалось понять и описать картину as is, поэтому мы провели реверсивный инжиниринг. Начиная с конца, то есть от дашбордов, по цепочке «шли» к сырым данным в источниках, попутно выявляя все последовательности и правила преобразования.  

Это был один из самых сложных этапов, потому что потоки данных в облаке на старте проекта выглядели следующим образом:

Факты, которые мы обнаружили:

• Из 93 ТБ данных в BigQuery почти треть — ненужные или устаревшие. 

• Объем еженедельных запросов к хранилищу из PowerBI составляет 29 ТБ. 

• Обработка запросов данных стоит компании порядка 3000$ в месяц.
  

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

Спасение данных и переезд в Yandex Cloud

Сразу после аудита мы предложили перейти из BigQuery на open-source решения в Yandex Cloud, так как на текущем этапе развития платить за каждое обращение к данным было нерационально. Это казалось рискованным предложением на фоне привычных сервисов Google, но в феврале картина мира резко изменилась — риск отключения стал стимулом к локализации хранилища. Hoff доверился нашей экспертизе, и мы незамедлительно инициировали бэкап данных, параллельно разрабатывая архитектуру совместно с командой Yandex Cloud. 

Как без паники выгрузить 93 ТБ данных ASAP, пока Google рассылает «письма счастья»? В этом помог аудит. С коллегами из Hoff оперативно решили, какие данные можем не забирать, прописали скрипты для разных сценариев выгрузки в Yandex Object Storage и подняли 3 виртуальные машины для синхронизации хранилища. Команда Yandex Cloud экстренно подключилась к процессу, рассказала об архитектурных особенностях облачной платформы и помогла подсчитать бюджет. 

Нам понравились их управляемые сервисы для СУБД ClickHouse и Greenplum: их использование позволяет снять с себя обслуживание инфраструктуры, обеспечение отказоустойчивости и проверку исправности в процессе раскатки обновлений. В общем, Yandex Cloud следит, чтобы железо и базы данных работали бесперебойно, что позволяет сфокусироваться на развитии проекта.

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

Чем хорош open-source

Clickhouse и Greenplum — это бесплатные сервисы с открытым исходным кодом, над которыми работает большое количество разработчиков. Из-за этого они, как правило, содержат меньше дефектов, быстрее обновляются и в целом обеспечивают гибкий рабочий процесс. При желании клиента, текущую архитектуру Hoff можно быстро перенести из облака на локальные сервера без потери данных, в то время как BigQuery заставляет буквально с нуля пересобирать все хранилище. 

В то же время open-source — это про стабильность. Блокировка сервисов поставила под сомнение существование экосистемы данных множества компаний, а открытые решения снимают подобные риски.

Разработка архитектуры

Мы решили послойно развернуть хранилище в разных системах управления.

Clickhouse хорошо работает с сырыми данными: за счет высокого сжатия хранилище занимает меньше места, но при этом даже единичные ad hoc запросы выполняются оперативно. Для ядра DWH выбрали Greenplum. Благодаря распределенной обработке, в нем можно быстро изменять, фильтровать и связывать данные. В BigQuery аналитики Hoff работали только с raw data level, то есть с сырыми данными, которые мы перенесли в Clickhouse вместе с коннекторами. Предобработанные данные упорядочили в Greenplum в виде Data Vault 2.0. 

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

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

Так, благодаря четко выстроенным процессам и описанным регламентам, сотрудники Hoff могут поддерживать эту систему самостоятельно.

Алертинг

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

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

Витрины данных 

Еще один важный этап работы — создание аналитических витрин или data mart. Это части хранилища в виде агрегированных таблиц, которые содержат данные по разным направлениям деятельности компании. Как правило, это ключевые метрики, которые можно комбинировать различными способами для дальнейшего анализа.

На основе витрин данных строится визуализация: один data mart может быть источником для 600 дашбордов. Ранее они делались из сырых данных, которые перед формированием отчета обрабатывал тот или иной отдел на основе своей экспертизы, а теперь будут создаваться из предобработанной по единому стандарту информации.

Наши цели до конца года — создать слой витрин и финально адаптировать бизнес к переезду.

Результаты

За год удалось с нуля пересобрать хранилище на облачной платформе и оптимизировать все данные: из 93 ТБ в ядро уложили 51 ТБ регулярно используемой информации. Сейчас ежедневный прирост сырых данных — около 15 ГБ, а в Data Vault — 3 ГБ единообразно обработанных.

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

Преимущества нового хранилища

• Скорость

Промежуточный слой в виде Data Vault значительно ускорил работу сотрудников. В разных компаниях подготовка аналитического отчета может занимать от нескольких дней до недели, в Hoff этот процесс сократился до 20 минут. 

Мы с клиентом выработали «гигиенический минимум» — данные в облачном хранилище хранятся так, как удобно бизнесу, а не источникам.

• Масштабируемость

Текущая архитектура спроектирована под нужды Hoff: ее можно наслаивать, модифицировать и расширять в зависимости от запроса. При регулярно растущем объеме данных DWH можно трансформировать в Data Lake без потери качества структуры.

• Достоверность

В облаке появилась единая методология очистки и подготовки данных — теперь вероятность разночтений сведена к минимуму. При появлении нового источника достаточно прописать новый алгоритм, после чего сырые данные будут автоматически приводиться в стандартный вид и попадать в Data Valut.

Детализированная система алертинга построена таким образом, что может оповещать аналитиков о сбоях даже в мессенджерах. Это позволяет оперативно устранять неточности в данных — скорость реагирования на ошибки увеличилась в 3 раза.

• Экономическая целесообразность

Сопутствующей выгодой при реализации проекта стала оптимизация бюджета клиента. Хранилище в BigQuery предусматривало оплату за каждое обращение к данным: помимо того, что при увеличении задач это обходилось компании дороже, всегда был риск потерять сотни тысяч рублей из-за одного ошибочного запроса.

Переезд в Yandex Cloud сделал затраты более предсказуемыми и гибкими. Бюджет при переходе в новое облако не изменился, а количество задач и объем разметки для продуктовой аналитики регулярно растет. Все обработки данных внутри хранилища стали фактически бесплатными — теперь нет никаких платежей, зависящих от количества запросов.

• Надежность

Мы в срочном порядке локализовали облачное хранилище и тем самым создали стабильную систему принятия решений в части продуктовой аналитики и digital-маркетинга Hoff. Кроме этого, инфраструктура Yandex Cloud соответствует высшим стандартам безопасности как персональных данных, так и платежных карт.

• Технологии

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

Кирилл Фридлянд, Chief Data Officer в Hoff Tech:
«Компания АЭРО отлично справилась с поставленной задачей и даже больше — проект по оптимизации облачного хранилища превратился в создание гибкой, надежной и масштабируемой системы хранения части данных в компании. Совместными усилиями запрос на локализацию стал для нас историей успеха и рывком вперед. Появились новые возможности: собирать больше данных и наращивать эффективность digital-маркетинга».

Озеро данных — это вид хранения данных и одновременно подход к архитектуре. Большинству бизнесов подходит формат DWH, когда данные хранятся в структурированном виде с помощью таблиц.

Но, например, в недвижимости, когда множество данных имеет формат изображений, или аудио (как записи звонков), необходим другой тип хранения.

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

Для того, чтобы стать data-driven, недостаточно собирать большое количество данных.

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

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

Создавать свою команду с нуля сложно из-за того нехватки дата-специалистов, но АЭРО предлагает мощный HR-бренд - мы берем подбор команды на себя. Кроме того, у нас достаточно обширные компетенции по различным направлениям eCom-бизнеса и опытные тимлиды, которые помогут избежать "призрачной занятости".

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

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

Часто путь клиента начинается с того, что он видит рекламу, ее много и она разная. Как же оценить, какая реклама приводит нам реальных клиентов, а с какой у нас идет пустой трафик. Это и есть зоны отвественности маркетинговой аналитики - оценить источники и посмотреть, как они превращаются в клиентов и насколько хороших клиентов мы получаем.

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

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

Отдельным направлением клиентской аналитики можно выделить direct-маркетинг. Это направление представляет из себя анализ тех коммуникаций и точек контакта, которые мы делаем с клиентом: SMS, e-mail, push-уведомления. Мы смотрим, что именно и когда мы можем сказать клиенту, чтобы он к нам возвращался и покупал еще и еще.

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

Представьте себе бизнес с 5 миллионами активных пользователей в месяц или 2 тысячами заказов в минуту. За каждой покупкой стоит клиент с его желаниями, устремлениями, причинами покупки и вероятностью оттока. 

Сложно представить, что компании, обладающие лишь инструментами массовой e-mail рассылки периодичностью 1-2 раза в неделю, смогут сделать коммуникацию действительно персонализированной. Бизнес, который внедряет CDP, успешно добивается роста среднего чека и частоты покупок, наличия в чеке высокомаржинальных товаров, снижает стоимость удержания клиентов и процент оттока. 

На оборот порядка 10 миллиардов рублей в год можно добиться увеличения до 400 миллионов рублей с сохранением уровня маржинальности. 

Что такое CDP и его модули? Это главный рабочий инструмент маркетолога.

CDP позволяет:

• сегментировать клиентов

• проанализировать частоту покупок и состав чеков, количество товаров в чеке и среднюю стоимость покупки

• составить шаблон сообщений (e-mail, sms, push или даже баннер для отображения на главной странице интернет-магазина)

• разработать механику акций лояльности с вознаграждением клиента за определенные действия

• выстроить логику цепочки коммуникаций

• провести A/B тесты

CDP – инструмент для непрерывного совершенствования через эксперименты. И да, это гораздо веселее, чем об этом рассказывают!

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

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

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

Поэтому стоит быть особенно внимательными при выборе CDP решения, и АЭРО поможет бизнесу сделать правильный выбор.

АЭРО провели анализ порядка 20 российских CDP решений (campaign, сегментация, аналитика, лояльность) и проверили около 150 метрик, включая: 

• функциональные возможности

• информационную безопасность

• технологический стек

• архитектуру

• возможности по кастомизации

• лицензионную модель

Мы выявили три сегмента решений, на которые стоит обратить внимание.  

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

Второй – более специализированные решения с расширенным функционалом. 

Третий – продукты enterprise-уровня, обладающие высокими стандартами в части масштабирования и информационной безопасности. 

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

Одной из нетривиальных задач является выявить все те интеграционные потоки, логические связи и структуру хранения данных и консолидировать их. Важно, чтобы работали как пакетные массовые коммуникации, так и real-time режим, когда клиент уже приложил карту для оплаты товаров в офлайне или оформляет заказ в e-com. 

Ключевые требования к интеграции CDP в IT ландшафт

1. Скорость доставки данных

Для real-time обновления данных мы разработали микросервис, который валидирует события и доставляет их в топики Kafka. Оттуда Kafka Connector вычитывает их, доставляя до CDP системы. В случае необходимости трансформации мы разрабатываем spark джобы, которые также читают данные с топиков Kafka.

Для загрузок по расписанию мы используем AirFlow.

2. Вендор-независимость

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

3. Удобство сопровождения

Мы разрабатываем архитектурную схему с потоками данных, описываем данные и логику их возникновения, разрабатываем дашборды и алерты, описываем типовые проблемы, которые возникают при доставке данных.

Одна из услуг АЭРО – консалтинг по выбору CDP систем.

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

Мы выделяем более 150 критериев, их мы сегментируем на обязательные и желательные к выполнению.

На основе этих критериев мы получаем набор баллов, по которым сравниваем разные CDP решения и выбираем наиболее подходящие для конкретного бизнеса.

Из всех критериев мы выделяем основные, на базе них мы определяем конечный список рассматриваемых CDP решений. Это:

• возможность развертки на серверах клиента или в облаке;

• функционал коробочного решения и его доработок;

• возможности масштабирования и производительности системы;

• похожие кейсы использования в схожем бизнесе;

• и, конечно же, стоимость и сроки внедрения.

При выборе CDP систем мы оцениваем и технические критерии:

• соответствие технологическому радару компании;

• возможности масштабирования и производительность;

• готовность к эксплуатации системы, наличие дашбордов и алертов;

• параметры информационной безопасности;

• возможности интеграции с системой авторизации клиента;

• подходы работы с персональными данными.

Мы также оцениваем готовые коннекторы и простоту интеграции с IT ландшафтом клиента.

При внедрении CDP выделяют 3 основных этапа.

1-й – проектирование.

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

Итог этого этапа – техническое задание на разработку CDP решения и его интеграции.

2-й этап внедрения CDP решения – разработка интеграции и загрузка данных.

В рамках этого этапа мы разрабатываем и внедряем микросервис для приема событий, разворачиваем систему для обмена сообщениями Kafka, Kafka коннекторы, пишем ETL на Airflow для загрузки данных по расписанию.

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

3-й этап внедрения CDP – финальная настройка, тестирование и опытно-промышленная эксплуатация.

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