Кейс “Золотий Вік”: як об’єднати дані з офлайну, вебсайту і мобільного застосунку в єдиний профіль клієнта

Клієнти взаємодіють із брендом у різних каналах — онлайн і офлайн — але їхні дані часто залишаються роз’єднаними в різних системах. Коли бренд не бачить зв'язку між покупкою у фізичному магазині, активністю у мобільному застосунку та візитом на сайт, втрачається цілісність картинки. І замість одного користувацького шляху може здатися, що це три окремі людини. 

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

Про проєкт 

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

Завдання

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

Через це один і той самий покупець міг виглядати в базі як кілька різних записів: окремо “клієнт з офлайн-магазину”, окремо “користувач сайту”, окремо “користувач застосунку”. Оскільки ці дані не були зведені до одного профілю, виникали типові складнощі:

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

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

Рішення

Основою нового підходу до роботи з даними став External Customer ID — єдиний ідентифікатор клієнта. Саме він дозволив "зшити" розрізнені дані в цілісні профілі.

Ідентифікатор передається в систему eSputnik разом із даними з усіх точок дотику. Завдяки цьому система автоматично формує єдину картку контакту, збираючи повний контекст по клієнту:

• події з сайту
• події із застосунку
• історія замовлень онлайн
• історія замовлень офлайн
• додаткові атрибути профілю

Думка експерта: Що дає обʼєднаний клієнтський профіль 360°?

 

Об’єднаний профіль клієнта дозволяє бачити повну історію взаємодії користувача з брендом у всіх каналах. Наприклад, коли клієнт переглянув товар на сайті, отримав email, зробив покупку в офлайн-магазині, а потім встановив застосунок — і компанія розуміє, що це одна людина, і в eSputnik це не кілька окремих контактів.

 

Це забезпечує коректну аналітику онлайн- та офлайн-шляху клієнта, персоналізовані комунікації на основі повної історії взаємодії, точну сегментацію (VIP, нові, сплячі, повторні покупці) та узгоджену омніканальну комунікацію без дублювання повідомлень.

 

Анна Забудська, Marketer в eSputnik Agency

Система самостійно формує єдину картку контакту, що замінює модель “кілька незалежних баз” на модель “один клієнт — один профіль”.

Що містить єдиний профіль клієнта

У профілі контакту може зберігатися повний набір даних, який надходить із підключених джерел. Як правило, це включає:

• базові атрибути контакту та ідентифікатори;
• підключені канали та їхній статус/наявність (зокрема, прив’язка застосунку та 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-атрибуція важлива: вона дозволяє розрахувати вплив комунікацій на офлайн-покупки через факт взаємодії з повідомленням.

Принцип роботи той самий:

• відбувається покупка (офлайн-транзакція), яка передається в систему;
• система перевіряє взаємодії клієнта з комунікаціями за вікно атрибуції;
• якщо взаємодія була, покупка може бути атрибутована до кампанії за правилом “остання взаємодія”.

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

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 не тільки в онлайн, а й в офлайн-продажі.

Special Request Inline