Нові покупці в аналітиці магазину: як звірити перше замовлення з CRM

Нові покупці в аналітиці магазину — не те саме, що нові відвідувачі або нові картки в CRM. Щоб отримати надійну кількість перших клієнтів, спочатку визначте покупця й момент підтвердження покупки в обліковій системі. Потім зіставте замовлення з подіями Google Analytics за стабільним ідентифікатором, а розбіжності розкладіть за причинами.

Це завдання для керівника електронної комерції, аналітика й розробника інтеграцій. Якщо ділити витрати на залучення на випадковий показник «нових», зміна налаштувань може виглядати як поліпшення CAC — вартості залучення клієнта. Нижче йдеться не про вибір рекламних каналів, а про перевірку знаменника: хто справді вперше став покупцем і на підставі яких даних.

Спочатку домовтеся, кого магазин вважає покупцем

Запишіть визначення до побудови звіту. Робочий варіант для перевірки: новий покупець — унікальний клієнт, чия найраніша підтверджена оплачена покупка припадає на звітний період. Це управлінське правило, а не універсальна вимога Google. Для післяплати підтвердженням може бути отримання коштів, а не натискання кнопки оформлення. Для передоплати потрібно окремо визначити, як обробляти частковий платіж.

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

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

Що саме означає перша покупка в Google Analytics

У документації звіту User acquisition Google описує залучення нових користувачів, а не появу перших платників у CRM. Перший візит і перше замовлення можуть відбутися в різні періоди.

Не підміняйте покупців новими користувачами

Показник New users пов’язаний із першими взаємодіями, які фіксують події first_visit або first_open. Він не підтверджує оплату. За описом Monetization overview, First time purchasers рахує унікальних користувачів, від яких purchase було зібрано вперше. Це ближче до потрібного питання, але межі спостереження Analytics не дорівнюють повній історії вашої CRM.

Не закладайте окрему вебподію first_purchase як обов’язковий стандарт: описаний показник використовує purchase. Якщо у вас є власна подія first_purchase, перевірте її специфікацію: назва не робить її еквівалентом стандартного показника.

Ідентичність користувача має межі

Google дозволяє пов’язувати активність через User-ID, який створює бізнес. Це не відновлює автоматично всі гостьові покупки чи історію старого сайту. Результат залежить від реалізації та звітної ідентичності. Реєстр підтверджених покупців будуйте на погоджених облікових даних.

Зберіть мінімальний реєстр для звірки

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

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

Алгоритм такий: визначте придатні покупки за погодженим правилом; знайдіть найранішу для кожного customer_key в усій доступній історії; лише після цього відберіть покупців за звітним періодом. Якщо спочатку обрізати історію поточним місяцем, давній клієнт із повторною покупкою помилково стане новим. Неповну історію позначайте окремо, а не виправляйте здогадками.

Пов’яжіть гостя з клієнтом без небезпечного склеювання

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

Зберігайте підставу об’єднання та можливість його скасувати. Сумнівні пари передавайте на перевірку або залишайте у групі «ідентичність не визначена». Примусове об’єднання може злити різних людей.

Ідентифікація покупців потребує розмежування систем. Email, телефон і ПІБ не передавайте як User-ID, transaction_id чи довільні параметри подій. Перевіряйте URL і назви сторінок на контакти з форми відповідно до рекомендацій Google щодо недопущення PII. Зв’язок технічного ключа з контактами залишайте всередині контрольованого контуру.

Хешування не є універсальним дозволом передавати контакти у звичайних параметрах purchase. Для цієї звірки використовуйте ключі замовлень, а не контакти покупців.

Розкладіть розбіжності за причинами, а не підганяйте підсумок

Спочатку зіставляйте замовлення, а вже потім рахуйте унікальних покупців. У звіті звірки потрібні групи: є в обох джерелах; є лише в обліку; є лише в Analytics; ключ конфліктує; статус або час не збігаються. Для кожної групи призначте наступну дію. Наприклад, відсутній purchase потребує перевірки доставки події, а не автоматичного вилучення оплаченого клієнта з CRM.

За документацією transaction_id, Analytics прибирає дублікати purchase з однаковим ідентифікатором у вебпотоках. Ключ має бути унікальним для замовлення, не порожнім і не спільним для різних покупців. Однак дедуплікація транзакцій не дорівнює дедуплікації клієнтів: різні покупки однієї людини закономірно мають різні ключі.

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

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

Подія refund із відповідним transaction_id передбачена в інструкції Google з електронної комерції. Але не робіть припущення, що її надсилання автоматично перераховує вашу CRM-когорту перших покупців за потрібним правилом. Це окрема логіка. Для післяплати, пізніх підтверджень і повернень погодьте дату повторного зрізу та маркуйте попередні результати.

Умовний приклад: гість повертається з іншого пристрою

Уявімо, що людина купила як гість, а пізніше створила кабінет з іншого пристрою й знову оплатила замовлення. Якщо магазин має підтверджений зв’язок між гостьовою покупкою та профілем, внутрішній customer_key залишається тим самим. Найраніша придатна покупка належить попередньому періоду, тому в поточному клієнт не стає новим.

Без такого зв’язку не «виправляйте» результат через схоже прізвище: позначте невизначеність. Якщо перше замовлення не оплатили, воно не стає першою придатною покупкою. Якщо оплатили й потім повернули, застосуйте політику повернень, а не правило скасування до оплати.

Це умовний сценарій, не кейс GL.ua. Для використання результату в CAC узгодьте витрати, період і охоплення каналів. Загальний реєстр покупців сам по собі не дає коректного CAC окремої кампанії.

Перевірте критерії приймання до запуску звіту

Пілот перевіряє аналітик разом із розробником і відповідальним за продажі. Критерій готовності — пояснення розбіжностей, а не примусова рівність Analytics і CRM.

1. Проведіть тест нового платника й повторного покупця. У реєстрі лише перший отримує ознаку нової покупки за період.
2. Повторіть завантаження підтвердження та доставку тієї самої події. Замовлення зберігає ключ, а внутрішній підсумок не зростає.
3. Перевірте гостя, вхід у кабінет та сумнівний збіг контактів. Для кожного випадку видно підставу зв’язку або явну невизначеність.
4. Пройдіть оплату, неоплачене скасування, часткове й повне повернення. Результати відповідають письмовим правилам, а не поточній назві статусу.
5. Зіставте записи на межі періоду та пізнє підтвердження платежу. Часовий пояс, дата зрізу й повторний перерахунок задокументовані.
6. Перегляньте параметри подій, URL і журнали на витік контактів. Збережіть знеособлений доказ перевірки та призначте власника моніторингу.

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

Строки, вартість і межі корисної точності

Строки залежать від доступності історії, якості статусів і правил ідентичності. Етапи: інвентаризація джерел, словник метрики, пробна звірка, виправлення інтеграцій і повторний зріз. Календарну оцінку давайте після інвентаризації: старий імпорт може вимагати більше роботи, ніж налаштування purchase.

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

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

Якщо проблема в обміні між сайтом, оплатою й CRM, обговоріть із GL.ua (Глянець) розробку інтернет-магазину з CRM та інтеграціями. Підготуйте опис потоку та знеособлені приклади розбіжностей для оцінки доопрацювань і критеріїв приймання.