Сценарії використання Data Store: як він допомагає вашому трекінгу

Data Store — це вбудована база даних NoSQL для користувачів серверного Google Tag Manager. Вона швидка, надійна та проста у використанні: ви можете зберігати та отримувати будь-які JSON-дані без налаштування зовнішньої бази даних.

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

Багато користувачів обирають Data Store як альтернативу Firestore. Вони використовують його для зберігання будь-якої інформації: від даних клієнтів до історії покупок (наприклад, збереження всіх куплених товарів). Причини для цього можуть бути різними — зокрема те, що Data Store вбудовано безпосередньо в платформу Stape, тому немає потреби в додаткових зовнішніх налаштуваннях. Ви можете почати зберігати та зчитувати дані одразу всередині вашого контейнера sGTM, не виходячи з облікового запису Stape.

Деякі користувачі навіть оформлюють підписку Stape і не використовують покращення, sGTM hosting або будь-які інші сервіси, окрім Store. Для них сама лише функція Store є достатньо цінною, щоб виправдати витрати!

Головна перевага — простіша архітектура: замість розгортання окремої бази даних, керування обліковими даними та підтримки додаткової інтеграції команди можуть використовувати шар сховища, який вже є частиною їхнього налаштування sGTM на базі Stape.

Ще один популярний сценарій використання — виявлення дублікатів транзакцій. Продубльовані конверсії можуть завищувати показники у вашій аналітиці та спричиняти неправильну атрибуцію в таких платформах, як Google Ads або Google Analytics. Зберігаючи ідентифікатори транзакцій у Data Store, ви можете легко перевірити, чи конверсія вже була оброблена. Таке налаштування дуже зручне для серверного трекінгу, де конверсії завантажуються через API.

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

Чому це корисно:

• Точні метрики: кожна транзакція враховується лише один раз.
• Краща атрибуція: запобігає помилковому зарахуванню конверсії кільком каналам.
• Розумніший розподіл бюджету: допомагає розподіляти рекламні бюджети на основі чистих і достовірних даних.

Вебхуки автоматизують передачу даних між вебдодатками в реальному часі. Деякі з наших клієнтів використовують Data Store, щоб додавати додаткові дані до вебхуків. Такий підхід гарантує, що ваші події трекінгу завжди міститимуть повний контекст. Це працює так:

1. 1.
   Коли користувач виконує дію онлайн (наприклад, надсилає форму), ви зберігаєте його cookies або ідентифікатори в Store під певним ключем, як-от email.
2. 2.
   Згодом, коли надходить подія вебхука, ви шукаєте цей самий ключ у Store, отримуєте дані користувача та надсилаєте повний набір даних, включно з cookies та ідентифікаторами, до таких платформ, як Google Ads або Meta Conversions API.

Покращення Enricher від Stape вже дозволяє збагачувати дані подій інформацією про користувачів, зібраною раніше. Проте в поєднанні з Data Store ви також можете збагачувати події бекенд-даними.

Ще одне застосування Data Store для збагачення даних — додавання інформації, яка не повинна або не може бути доступною в браузері: статус у CRM, рівень клієнта, внутрішня класифікація товарів, стан запасів, відповідальний менеджер, маржинальність або статус виконання замовлення. Збагачена подія, надіслана до платформ аналітики чи реклами, містить важливий бізнес-контекст, який сам по собі клієнтський трекінг надати не може.

Крос-доменний трекінг часто дає збої, оскільки cookies не можна передавати між різними доменами.

За допомогою Data Store ви можете зберігати cookies або ідентифікатори під спільним ключем (наприклад, User ID) і відновлювати їх, коли той самий користувач переходить на інший домен. Таким чином ваші дані користувачів залишаються узгодженими, а аналітика може точно атрибутувати конверсії навіть між різними вебсайтами.

Як це працює на практиці:

1. 1.
   Коли користувач відвідує ваш перший домен, ви зберігаєте ключові дані трекінгу (cookies, ідентифікатори сесій, ідентифікатори користувачів) у Data Store.
2. 2.
   Коли той самий користувач продовжує взаємодію на іншому домені, система витягує збережені дані з Data Store за спільним ідентифікатором.
3. 3.
   Ці відновлені дані допомагають зберегти зв'язок між візитами та конверсіями, гарантуючи, що ваші платформи аналітики та реклами розпізнають того самого користувача.

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

Більшість рекламодавців вимірюють ефективність за допомогою ROAS (окупність витрат на рекламу), але ROAS не враховує собівартість товарів. Profit Over Ad Spend (POAS) — це точніша метрика. Вона фокусується на реальному прибутку, а не просто на доході.

У Stape вже є спеціальне покращення POAS Data Feed, яке дозволяє безпечно зберігати й отримувати дані про прибуток та використовувати їх замість доходу під час передачі конверсій у Google Ads або Analytics. Проте Data Store розширює цю функціональність, дозволяючи виконувати складніші розрахунки POAS.

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

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

Click ID зазвичай зберігаються в cookies браузера, але cookies можуть закінчуватися, блокуватися, бути недоступними для бекенд-систем або з інших причин не передавати дані атрибуції до майбутньої конверсії. Data Store надає ще одне місце для надійного збереження цих ідентифікаторів.

Наприклад, ви можете зберегти click ID за стабільним ключем, як-от User ID, Session ID, Lead ID або Order ID. Коли пізніше відбувається конверсія, click ID можна отримати за цим ключем і додати до події конверсії. Цей підхід все ще потребує стабільного ідентифікатора, що зв'язує початковий клік із наступною подією. Проте він дозволяє зберегти дані атрибуції навіть тоді, коли сховище браузера більше недоступне.

Зрештою, Data Store корисний майже в будь-якому випадку, коли вам потрібно зберегти дані тимчасово або на тривалий термін, щоб використати їх пізніше. Це надійніше та масштабованіше, ніж cookies чи локальне сховище. Усе, що вам потрібно, — це ключ для запису та отримання даних, наприклад, email користувача, ID або токен сесії.

• Створюйте документи та колекції для збереження кількох файлів.
• Шукайте та фільтруйте дані за допомогою умов. 
• Встановлюйте TTL (time-to-live) для документів, щоб вони автоматично видалялися, коли більше не потрібні. 
• Отримуйте та використовуйте збережені в сховищі дані для збагачення потоків подій серверного GTM (наприклад, для атрибутів користувачів, кастомних параметрів, токенів). 
• Використовуйте API для програмного доступу до сховища через ендпоінти.

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

Наприклад, ви можете зберігати правила для товарів, класифікації кампаній, регіональні налаштування, зіставлення клієнтів або інші параметри конфігурації. Потім ви можете оновлювати їх через панель Stape, імпорт CSV або API без повторної публікації контейнера sGTM щоразу, коли змінюється значення.

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

Data Store може допомогти зв'язати анонімну активність користувача з його особистістю та попередніми діями після того, як він ідентифікує себе. Це також робить відстеження нових і повторних клієнтів надійнішим.

Наприклад, відвідувач може переглядати ваш вебсайт до входу в акаунт або заповнення форми. Ви можете зберегти зв'язок між його анонімним ідентифікатором браузера чи сесії та його ідентифікатором клієнта. Щойно користувач ідентифікує себе, майбутні події зможуть використовувати цей зв'язок для отримання підтверджених атрибутів особистості та забезпечення безперервності раніше анонімних сесій.

Інформація про згоду часто доступна в браузері, але відсутня, коли подія надходить із CRM, вебхука, офлайн-системи чи іншого бекенд-джерела. Data Store може зберігати статус згоди користувача разом із метаданими, як-от джерело, мітка часу або версія політики.

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

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

Цей підхід слід використовувати обережно: застосовуйте вузькі тригери, короткі TTL, мінімізацію даних та фільтрацію PII. Збереження кожного запиту може створити непотрібні ризики для конфіденційності та швидко вичерпати ліміти запису в базу даних.

Data Store виріс із простої функції у потужний інструмент, який підтримує широкий спектр сценаріїв трекінгу та роботи з даними. З ним ви можете налаштувати крос-доменний трекінг, усунути дублікати транзакцій, побудувати легку CDP або просто зберігати дані для подальшого використання.

Оскільки він вбудований безпосередньо в платформу Stape, немає потреби налаштовувати чи підтримувати зовнішню базу даних. Ви можете почати зберігати та отримувати дані безпосередньо всередині вашого серверного GTM. Data Store може замінити такі інструменти, як Firestore, зберігаючи все в одному місці.