Чому варто перейти на first-party аналітику
Команди зазвичай починають думати, як перейти з Google Analytics на first-party аналітику, після однієї з трьох подій: аудиту приватності, оновлення банера згоди або звіту, якому вже ніхто не довіряє. Такий аудит Google Analytics 4 — не про моду. Він про контроль.
Google Analytics може бути цілком придатним для загальних трендів, але багато команд хочуть мати дані, якими вони володіють, зберігають на власних умовах і які відповідають їхнім реальним бізнес-правилам. Перегляд сторінки з згодою — це не те саме, що відстежений перегляд сторінки, і ця різниця має значення, коли юристи, продукт і маркетинг читають одну й ту саму панель. Деяким командам також потрібно зберігати дані в певному регіоні.
Є й інша причина. Контроль вимірювання.
З first-party аналітикою ви самі вирішуєте, що вважати сесією, що вважати конверсією і які події взагалі мають існувати. Звучить дрібно, аж поки хтось не запитає, чому підписка на розсилку рахується двічі на мобільному і один раз на десктопі. Тоді це здається дуже важливим.
Для агенцій і команд із кількома брендами перевага ще очевидніша. Єдиний підхід до звітності для усіх сайтів клієнтів в одній панелі може зменшити звичну тяганину через теги, цілі та “яка версія правди” зараз актуальна. Одна панель. Одна схема. Менше загадок.
Проведіть аудит поточної конфігурації Google Analytics
Перш ніж щось змінювати, зафіксуйте все, що вже відстежується у Google Analytics 4, а також будь-які залишкові експортовані дані Universal Analytics. Почніть з базового: перегляди сторінок, події, конверсії, аудиторії, дослідження та користувацькі параметри. Потім рухайтеся далі. Міграція швидко провалюється, коли стару конфігурацію ніколи не записували.
Перелічіть кожну назву події, яку ви використовуєте, навіть незручні. Якщо ви відстежуєте form_submit, newsletter_signup і cta_click, запишіть їх разом із параметрами. Перевірте, які події позначені як конверсії, бо саме їх люди зазвичай помічають першими, якщо вони зникнуть. Воронка оформлення замовлення переживе відсутній скрол-ивент. Відсутній івент покупки — зазвичай ні.
Аудиторії теж важливі. Якщо ваша маркетингова команда має аудиторію для ремаркетингу за відвідувачами сторінки з цінами, занотуйте правило, вікно членства та джерело даних. Якщо продуктова команда використовує звіт по когортах для активованих користувачів, запишіть умову простою мовою, а не лише назву звіту. Назва — це не план.
Звіти також варто каталогізувати. Експортуйте назви дашбордів, діапазони дат, на які люди спираються, і фільтри, застосовані до кожного з них. В однієї команди, з якою я працював, був “тижневий звіт для керівництва”, який мав сенс лише через прихований фільтр для платного трафіку. Такі деталі губляться під час поспішного переходу, і наступний понеділок стає невдалим.
Визначте вимоги до first-party аналітики
Коли поточну схему буде змальовано, вирішіть, що нова first-party аналітика має зберегти. Список має бути конкретним: перегляди сторінок, початок сесії, кліки на зовнішні посилання, завершення форм, покупки, події входу та стан згоди. Якщо ви не можете назвати подію, ймовірно, не варто її відстежувати.
Думайте не лише про події, а про шлях користувача. Людина може зайти на блогпост, відкрити сторінку з цінами, почати форму демо, покинути її, а потім повернутися через email через два дні. Ваша first-party аналітика має дозволяти пов’язати ці кроки без здогадок. Для цього потрібно визначити ідентифікатори, правила зберігання даних і те, які події прив’язані до відвідувача, а які — до авторизованого користувача.
Обробка згоди має бути в списку вимог від самого початку. Якщо відвідувач відмовляється від файлів cookie для аналітики, ви вимикаєте все відстеження, надсилаєте події без cookie чи чекаєте на згоду? Відповідь впливає на обсяг даних, відповідність вимогам і на те, як продуктова команда інтерпретує падіння трафіку після зміни банера. Без припущень.
Запишіть і обмеження. Можливо, вам потрібна лише історія подій за 12 місяців. Можливо, відділу продажів важливі лише 6 подій конверсії. Можливо, фінанси хочуть бачити дані про покупки, згруповані за тарифом, регіоном і платіжним циклом. Ці цифри згодом вплинуть на вибір платформи і допоможуть рано зупинити розширення обсягу робіт.
Оберіть правильну платформу first-party аналітики
Саме тут команди часто все надто ускладнюють. Почніть із власності: хто хостить дані, хто контролює схему і хто може експортувати їх на вимогу? Потім переходьте до варіантів self-hosting, функцій відповідності вимогам, інтеграцій і підтримки міграції. Якщо платформа не може чітко відповісти на ці питання, шукайте далі.
Власність на дані має бути видима і в договорі, і в панелі адміністратора. Self-hosting може бути важливим, якщо ваша команда безпеки хоче зберігати дані у вашій інфраструктурі. Функції відповідності важливі, якщо вам потрібен хостинг в ЄС, маскування IP, збір з урахуванням згоди або процеси видалення даних. Інтеграції важливі, бо ніхто не хоче щоп’ятниці вручну переносити дані про покупки з Shopify у таблицю.
Підтримка міграції — це не просто модне слово. Запитайте, чи платформа може імпортувати історичні події, відтворити ваші старі назви подій або допомогти перенести логіку конверсій із Google Analytics. Якщо ви порівнюєте варіанти, продукт astrina варто розглянути разом із вашими потребами у відстеженні, особливо якщо ви хочете аналітику та огляд стану сайту в одному місці. І ще одна практична деталь: якщо ваша команда вже перевіряє всі сайти, за які ви відповідаєте, перехід відчувається не як заміна інструмента, а як упорядкування звітності.
Оберіть платформу, яка відповідає тому, як ваша команда реально працює. Невеликій контентній команді не потрібна та сама архітектура, що й ecommerce-команді, яка обробляє сотні транзакцій на день. Стартапу з одним маркетологом і одним інженером потрібне не те саме, що агенції, яка керує 30 проєктами. Звичайна логіка тут усе ще працює.
Відтворіть план відстеження
Тепер перетворіть аудит на нову схему подій. Зіставте кожну подію Google Analytics із назвою події у first-party аналітиці, а потім вирішіть, чи має стара назва залишитися, чи змінитися. Якщо generate_lead стає form_completed, зафіксуйте чому. Якщо змінюється назва, мають змінитися й усі похідні звіти.
Використовуйте правила називання, які люди зможуть зрозуміти навіть через шість місяців. Послідовність важливіша за кмітливість. Проста структура на кшталт action_object_context зазвичай легша в підтримці, ніж кілька разових назв, які може пояснити лише їхній автор. Достатньо однієї дивної назви, щоб зламати дашборд.
Конверсії теж слід переписати уважно. Конверсія в Google Analytics, заснована на цільовій сторінці, може стати подією first-party аналітики, яка спрацьовує після успішного надсилання форми. Конверсія покупки може потребувати параметрів валюти, продукту, тарифу та коду купона. Якщо в початковій схемі були приховані припущення, запишіть їх зараз. Інакше новий звіт не збігатиметься зі старим, і ніхто не зрозуміє чому.
Чітко вкажіть, що не відстежується. Якщо ви вирішили не відстежувати трафік внутрішніх співробітників, вкажіть фільтр. Якщо вам не важлива глибина прокрутки понад 50%, так і напишіть. Такі рішення запобігають фальшивим суперечкам згодом, що дуже доречно, коли троє людей на зустрічі “пам’ятають” стару схему по-різному.
Впровадьте та протестуйте нову аналітику
Встановлення має бути нудним. Додайте скрипт, підтвердьте домен і підключіть стан згоди ще до того, як спрацює щось інше. Якщо платформа пропонує фрагмент для тег-менеджера, спочатку протестуйте його на staging. Зламана first-party аналітика може виглядати живою, хоча передає нісенітницю.
Тестуйте по одній події за раз. Відкрийте перегляд сторінки, надішліть форму, клацніть зовнішнє посилання та завершіть тестову покупку, якщо це дозволяє ваше середовище. Потім перевірте, що кожна подія з’являється з правильними властивостями, мітками часу та ідентифікаторами користувача. Дві хвилини тестування можуть заощадити два тижні дебагу.
Дашборди потребують такої самої перевірки. Перевірте верхньорівневий графік трафіку, кількість конверсій і будь-який воронковий звіт, який, як ви очікуєте, бачитиме керівництво. Порівняйте числа з системою-джерелом, де це можливо. Якщо система оформлення замовлень показує 18 замовлень, а аналітика — 14, не запускайте це в продакшн.
Окремої перевірки заслуговує і тестування згоди. Відхиліть cookie, перезавантажте сторінку й переконайтеся, що скрипт поводиться так, як задумано. Потім прийміть cookie та перевірте, що відстеження відновилося коректно. Цей крок легко пропустити. Не варто.
Запустіть обидві системи паралельно
Паралельний запуск дає вам страховку. Залишайте Google Analytics активним, поки first-party аналітика збирає ті самі основні події протягом визначеного перехідного періоду. Це може бути 2 тижні або 30 днів — залежно від обсягу трафіку та рівня занепокоєння стейкхолдерів. Головне — визначити це ще до першої зустрічі щодо порівняння.
Порівнюйте обидві системи за трендом, а не чекайте абсолютно однакових підсумків. Правила згоди, логіка сесій, фільтрація ботів і моделі атрибуції можуть створювати розбіжності. Якщо Google Analytics показує більше сесій, перевірте, чи причина в поведінці щодо згоди або дублюванні тегів. Якщо first-party аналітика показує менше покупок, перевірте тригер події та процес сторінки підтвердження замовлення, перш ніж звинувачувати платформу.
Ведіть короткий журнал розбіжностей. Записуйте дату, метрику, різницю, можливу причину та виправлення. Одна команда виявила, що сторінка “дякуємо” завантажувалася без події покупки в Safari, бо подія спрацьовувала після редіректу. Такі проблеми трапляються часто, і журнал допомагає не допустити, щоб та сама помилка тягнулася ще через 3 релізи.
Якщо вам потрібна допомога з тим, наскільки активно стежити за змінами, під час перехідного періоду швидко виникає питання чи варто обрати аналітичні сповіщення. Сповіщення можуть ловити просідання, але занадто багато сповіщень перетворюються на шум. Десять шумних сповіщень гірші за одне корисне.
Відключіть Google Analytics і відстежуйте результати
Коли дані вже достатньо добре збігаються для вашої команди, перемикайтеся чисто. Приберіть старі теги з сайту, заархівуйте старі звіти та задокументуйте нове джерело правди. Збережіть копію старих налаштувань властивості Google Analytics, назв подій і визначень аудиторій на випадок, якщо хтось пізніше запитає, чому метрика змінилася в березні. Такі запитання завжди з’являються пізніше.
Після перемикання відстежуйте якість даних щонайменше протягом перших 2 звітних циклів. Слідкуйте за відсутніми подіями, дубльованими покупками та раптовими падіннями трафіку за каналами. Перевірте кілька реальних сесій від початку до кінця, а не лише підсумок на дашборді. Цифри можуть виглядати нормально, хоча одна форма тихо зламана.
Задокументуйте процес, який замінює старий. Хто додає нові події? Хто погоджує зміни в назвах? Хто перевіряє поведінку згоди після оновлення банера cookie? Якщо цей процес живе лише в чиїйсь голові, він зламається в першу ж відпустку цієї людини.
Деякі команди залишають стару властивість лише для читання як історичний архів. Це нормально. Просто переконайтеся, що команда знає, де шукати, і які дашборди вже виведені з використання, бо старі звіти мають звичку з’являтися у слайдах через шість місяців після міграції.
Якщо ваша команда також відстежує стан сайту та технічні зміни разом з аналітикою, корисно тримати обидва напрямки в одному звітному просторі. Налаштування, яке вже контролює всі сайти, за які ви відповідаєте, може спростити постміграційний аналіз, особливо коли одному графіку потрібна перевірка продуктивності, а іншому — перевірка відстеження в той самий день.
Останній крок не надто ефектний: продовжуйте перевіряти якість подій після запуску й виправте перший зламаний тег, перш ніж він стане новою звичкою.
