Задача	Объединить разрозненные данные клиентов (из офлайн-магазинов, веб-сайта и мобильного приложения) в единую систему. Настроить автоматизированные омниканальные коммуникации и триггеры программы лояльности.
Решение	Объединение данных в единый профиль клиента на базе External Customer ID. Запуск поведенческих триггеров и омниканальных цепочек с логикой переключения между доступными каналами.
Ресурсы	Разработчики и маркетинговая команда “Золотой Век”. Customer success менеджер и техническая поддержка eSputnik.
Результаты	85% базы клиентов имеют объединенные профили. Высокий уровень омниканального вовлечения — охват до 5 каналов на одного пользователя. Высокий уровень конверсии (CR) в триггерных сценариях.

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

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

О проекте

“Золотой Век” — украинская ювелирная компания и один из крупнейших ювелирных ритейлеров страны. Бренд специализируется на производстве и продаже ювелирных изделий и имеет разветвленную сеть офлайн-магазинов, а также интернет-магазин с доставкой по Украине. Параллельно с розничными продажами компания развивает собственные инструменты взаимодействия с клиентами, в том числе программу лояльности и мобильное приложение.

Задача

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

Из-за этого один и тот же покупатель мог выглядеть в базе как несколько разных записей: отдельно “клиент из офлайн-магазина”, отдельно “пользователь сайта”, отдельно “пользователь приложения”. Поскольку эти данные не сводились в один профиль, возникали типичные сложности:

• невозможно быстро увидеть полную историю взаимодействия клиента с брендом;
• онлайн- и офлайн-покупки существуют отдельно и не формируют единую картину;
• данные из разных источников нельзя использовать вместе (например, события с сайта/приложения и покупки в магазинах);
• любые сценарии, сегментация и аналитика требуют дополнительных ручных сверок между системами.

Чтобы сделать коммуникации точнее и логичнее, перед командой “Золотого Века” встала ключевая задача: преодолеть эту фрагментацию и собрать офлайн- и онлайн-данные в единый профиль клиента.

Решение

Основой нового подхода к работе с данными стал External Customer ID — единый идентификатор клиента. Именно он позволил “сшить” разрозненные данные в целостные профили.

Идентификатор передается в систему eSputnik вместе с данными из всех точек касания. Благодаря этому система автоматически формирует единую карточку контакта, собирая полный контекст по клиенту:

• события с сайта
• события из приложения
• история онлайн-заказов
• история офлайн-заказов
• дополнительные атрибуты профиля

Система самостоятельно формирует единую карточку контакта, заменяя модель “несколько независимых баз” на модель “один клиент — один профиль”.

Что содержит единый профиль клиента

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

• базовые атрибуты контакта и идентификаторы;
• подключенные каналы и их статус/наличие (в том числе привязка приложения и web push);
• параметры профиля, если они передаются (например, язык, часовой пояс, локация);
• историю транзакций с разделением на онлайн- и офлайн-покупки;
• события и активность с веба и приложения, которые фиксируются трекингом.

Это означает, что при работе с контактом команда видит не “часть” информации, а полный контекст: из какой среды пришел клиент, какие покупки он совершал в разных каналах продаж и какие данные о нем уже есть в системе.

Офлайн-данные (программа лояльности и продажи)

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

Из офлайн-источников передаются два ключевых типа данных:

1. Данные программы лояльности — информация об участии клиента в программе и связанные атрибуты.
2. Данные об офлайн-продажах — история покупок в магазинах (транзакции), чтобы ее можно было видеть вместе с онлайн-заказами.

Передача офлайн-данных позволяет:

• видеть полную историю покупок клиента (онлайн + офлайн) в одном профиле;
• сегментировать аудиторию по реальным покупкам в магазинах, а не только по онлайн-активности;
• избегать дублирования контактов и работать с клиентом как с единым профилем независимо от канала покупки;
• корректно анализировать влияние маркетинговых коммуникаций на продажи, включая офлайн.

После передачи офлайн-данных в профиле контакта появляются:

• блок/атрибуты, связанные с лояльностью (если передаются);
• офлайн-заказы в истории покупок рядом с онлайн-заказами.

Источники данных и подключение

Для формирования и поддержания единого профиля данные передаются из нескольких источников:

• мобильное приложение — через SDK (передача событий и идентификатора);
• сайт — через web tracking (передача событий и поведения на сайте);
• web push — через скрипт (передача подписок/идентификаторов для канала);
• CRM/внутренние системы — загрузка/синхронизация данных по клиентам и профильным атрибутам;
• передача офлайн-заказов для отображения покупок из магазинов в том же профиле, что и онлайн.

Критически важно, что во всех этих интеграциях используется один и тот же External Customer ID. Именно это позволяет корректно сшивать данные и избегать дублирований.

Каналы коммуникации

События с сайта и приложения — основа для автоматизации

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

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

• что клиент просматривал товары;
• что добавлял товар в корзину;
• что начинал оформление заказа;
• что возвращался на сайт или в приложение;
• что завершил покупку (онлайн) или выполнил другие зафиксированные системой действия.

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

Коммуникации программы лояльности

Отдельное направление автоматизации в этом проекте — коммуникации, связанные с программой лояльности. Такие сообщения не зависят от поведения на сайте или в приложении: они запускаются на основе событий и изменений в лояльности, которые передаются в систему.

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

Какие события этой программы можно автоматизировать:

1. Начисление бонусов.

Уведомление клиенту о том, что бонусы начислены, с указанием суммы/баланса (если эти данные передаются), а также с объяснением, как ими можно воспользоваться.

2. Сгорание бонусов

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

3. Переход на новый уровень

Уведомление об изменении уровня/статуса в программе лояльности с фиксацией того, что именно изменилось (новый уровень, условия, преимущества).

Триггерные сценарии и омниканальные цепочки

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

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

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

Сегментация

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

Сегментация может учитывать сразу несколько уровней данных:

1. История покупок

• покупки онлайн и офлайн;
• дата/период покупок (например, за последние 6 месяцев/1 год/3 года);
• количество и частота покупок (например, “более 2 заказов”).

2. География

• город покупки (особенно важно для офлайна);
• сегменты по отдельным городам или группам городов.

3. Параметры товаров в заказах

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

• категория товара;
• материал (белое золото/желтое золото);
• наличие и тип вставок или камней;
• другие параметры товара, если они есть в данных заказа.

4. Данные программы лояльности

• участие в программе;
• уровень/статус (если передается);
• дополнительные атрибуты программы.

5. Доступность и активность в каналах

Сегмент можно дополнительно уточнять по тому, есть ли у клиента:

• конкретный подключенный канал;
• взаимодействие с сообщениями в этом канале (например, “читает Viber”, если этот сигнал передается/фиксируется).

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

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

“Золотой Век” активно использует полный объем данных о клиенте — некоторые сегменты, применяемые для массовых рассылок, насчитывают более 10 условий.

Рекомендации и искусственный интеллект

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

В результате:

• модели лучше понимают поведение клиента (не только онлайн, но и в целом);
• расчеты вероятности покупки становятся точнее, потому что строятся на более полной истории;
• рекомендательные алгоритмы имеют больше данных для подбора товаров, категорий или предложений.

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

Атрибуция

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

Для сайта применяется атрибуция last paid click. Это стандартная логика, близкая к Google Analytics:

• источник/канал определяется через UTM-метки;
• система “видит” сессию, которая пришла из трафика;
• покупка привязывается к последнему переходу.

Мобильное приложение: post-click/post-read

В мобильном приложении нет UTM-меток в привычном для веба виде, поэтому классическая веб-атрибуция не подходит. Вместо этого используется post-логика: post-click или post-read.

Как работает post-атрибуция:

1. В систему поступает информация о заказе.
2. Далее система проверяет, было ли взаимодействие клиента с коммуникациями за определенный период (окно атрибуции).
3. Если взаимодействие было, покупка атрибутируется к соответствующей кампании.

В зависимости от канала это может быть:

• post-read — прочтение сообщения;
• post-click — клик/переход из сообщения;
• delivered — когда “read” недоступен, но есть факт доставки.

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

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

Офлайн

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

Принцип работы тот же:

1. Происходит покупка (офлайн-транзакция), которая передается в систему.
2. Система проверяет взаимодействия клиента с коммуникациями за окно атрибуции.
3. Если взаимодействие было, покупка может быть атрибутирована к кампании по правилу “последнее взаимодействие”.

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

Mobile push

В некоторых каналах (например, mobile push) нет статуса read, но есть:

• delivered (доставлено);
• click (клик).

В этом проекте для mobile push выбрана логика post delivered:

• если push был доставлен;
• и в течение N дней после доставки была покупка;
• покупка может быть атрибутирована к соответствующей кампании (с учетом правила “последнее взаимодействие”).

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

Результаты

Рост качества базы

Благодаря объединению данных под единым идентификатором клиента сформирована качественная “сшитая” база, где контакт имеет один профиль независимо от того, где происходило взаимодействие (офлайн или онлайн). Такие профили содержат в карточке контакта большой объем информации, включая данные о:

• покупках (офлайн и онлайн);
• активности на сайте;
• активности в приложении;
• взаимодействии в каналах коммуникации.

Общие результаты объединения профилей:

• Единый профиль клиента: 1 672 543 контакта из 1 971 754.
• Покрытие сшитыми профилями: 84,82% от общей базы.

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

Новые омниканальные возможности

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

• Максимум каналов на одного пользователя: до 5 (email, web push, SMS, Viber, mobile push)

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

Увеличение эффективности массовых рассылок

Улучшенный сбор и объединение данных позволили проводить более точную сегментацию, что напрямую отразилось на эффективности кампаний. Так, за три месяца 2026 года массовые рассылки “Золотого Века” показали CTR на 35,4% выше по сравнению с другими компаниями в нише ювелирных изделий.

Увеличение эффективности триггерных сценариев

После настройки автоматизированных триггерных цепочек ключевые сценарии обеспечили высокие показатели конверсии на этапах цепочки.

Брошенная корзина

• 1-е письмо: 30,16%;
• 2-е письмо: 27,40%.

Просмотры

• 1-е письмо: 22,83%;
• 2-е письмо: 25,77%.

Что показывают эти результаты:

• показатели CR свидетельствуют о том, что триггерные сценарии хорошо “подхватывают” пользователя на этапе намерения (просмотр или корзина) и доводят до целевого действия;
• стабильные значения CR в рамках цепочек означают, что автоматизации работают не как разовые сообщения, а как эффективная последовательность касаний;
• эти сценарии могут масштабироваться и дополняться сегментацией (по истории покупок, офлайн/онлайн-активности, участию в программе лояльности), чтобы повышать релевантность коммуникаций для разных групп клиентов.

Выводы

“Золотой Век” объединил офлайн- и онлайн-данные в единую систему, собрав информацию из разных источников (CRM, сайт, мобильное приложение, программа лояльности, офлайн-продажи) и связав ее под одним контактом через общий идентификатор. В результате данные о клиенте не разбросаны по разным базам, а сосредоточены в одном профиле.

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

Объединенная история покупок также обогащает данными AI-модели: рекомендации и прогнозирование (в том числе вероятность покупки) могут работать точнее, потому что учитывают как онлайн-, так и офлайн-поведение клиентов.

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

И наконец, благодаря единой логике атрибуции для разных сред появляется возможность измерять вклад direct marketing не только в онлайн, но и в офлайн-продажи.

Получить персонализированную консультацию