Як перенести аналітику з Google Analytics на privacy‑first аналітику
1. Навіщо мігрувати: цілі, ризики та очікування
Перехід на privacy-first аналітику зазвичай починається не з моди, а з болю. У Google Analytics в останні роки стало більше обмежень: блокувальники, налаштування браузерів, правові вимоги, cookie-банери, а ще зростаюча втома команди від звітів, де частина даних зникає вже на вході.
Бізнесу потрібен не «ще один лічильник», а зрозуміла картина: скільки людей прийшло, звідки, що вони зробили, де зламалася воронка і який канал дав заявку. Якщо після переїзду втрачаються цілі, транзакції або події форми, міграція провалена, навіть якщо новий інтерфейс красивіший. Тому питання, як перенести аналітику з Google Analytics на privacy-first аналітику, зазвичай упирається не в зміну інструмента, а в збереження сенсу вимірювань.
У privacy-first аналітики інша логіка. Вона не намагається зібрати все підряд, а тримає фокус на мінімумі даних, який потрібен продукту, маркетингу та редакції. Це корисно, коли юридична служба вже ставить незручні питання, а маркетологу потрібен відповідь без зайвих cookies.
Є і практичний привід: аналітика без зайвої персоналізації краще переживає обмеження браузерів і дає більш передбачувану картину в довгостроковій перспективі. Один раз вибудувана схема вимірювань часто виявляється стійкішою, ніж набір костилів поверх старого Google Analytics.
До речі, якщо на сайті багато контенту, не завадить подивитися і анекдоти про студентів. Анекдоти безкоштовно. Короткі: короткий формат допомагає зрозуміти, як читається структура сторінки і де користувач втрачає увагу вже після першого екрану.
2. Що вважати privacy-first аналітикою
Аналіз з акцентом на конфіденційність будується навколо трьох правил: збирати менше, зберігати коротше і не прив'язувати дії людини до зайвих ідентифікаторів. В ідеалі аналітика фіксує подію, сторінку, джерело та час, а не тягне за собою довгу історію користувача на місяці вперед.
На практиці це виглядає так: мінімум cookies, акуратна робота з IP, відсутність рекламних ідентифікаторів там, де без них можна обійтися, і прозора політика обробки. Сайт не повинен перетворюватися на «чорний ящик» для відвідувача.
У privacy-first аналітики бувають різні форми. Одні рішення зберігають дані у вас на сервері. Інші працюють в хмарі, але обіцяють короткий retention і агрегування. Треті — це простий лічильник відвідувань без складних воронок. Для маленького медіа іноді вистачає одного виду звітів, для SaaS-продукту вже потрібен інший рівень деталізації.
Саме тому не варто підміняти privacy-first аналітику простим видаленням банера cookies. Якщо механіка збору залишилася старою, а текст в політиці став м'якшим, приватності там мало. Користувач це відчуває швидко.
3. Підготовка до переносу: аудит поточної аналітики
Перед міграцією потрібен не список побажань, а інвентаризація. Відкрийте поточний Google Analytics і випишіть 5 груп: події, цілі, конверсії, джерела трафіку, звіти. Окремо відзначте інтеграції з CRM, рекламними кабінетами, email-сервісами та дашбордами для керівництва.
Корисно пройтись по сайту вручну і зафіксувати 10–20 сценаріїв, які реально важливі: відправка форми, клік по телефону, перегляд прайсу, скачування файлу, оформлення замовлення, вхід у особистий кабінет. На цьому етапі особливо часто з'ясовується, що в GA колись налаштували 40 подій, а команда пам'ятає тільки 7.
Зберіть список сторінок і шаблонів. Для редакційного сайту це можуть бути статті, рубрики, картки автора, пошук і блоки рекомендацій. Для інтернет-магазину — каталог, картка товару, кошик, checkout і сторінка «дякуємо за замовлення».
Якщо потрібна зовнішня перевірка логіки сайту, знадобиться і матеріал як перевірити сайт на шахрайство: при переносі аналітики особливо корисно розуміти, як користувач бачить домен, форму оплати та поведінку підозрілих елементів.
В кінці аудиту повинна вийти таблиця з чотирма полями: що вимірюємо, де це зараз налаштовано, навіщо це потрібно, як перевіримо після переносу. Без цієї таблиці міграція швидко перетворюється на суперечку «здається, все працювало».
4. Вибір альтернативи Google Analytics
Ринок privacy-first аналітики неоднорідний, і вибирати слід за завданням, а не за маркетинговою обіцянкою. Є self-hosted рішення, де ви контролюєте зберігання та оновлення. Є хмарні платформи з простим стартом. Є легкі лічильники для базової відвідуваності. Є більш просунуті системи, де доступні події, сегменти, воронки та звіти по продукту.
Для новинного сайту часто важливі швидкість впровадження та прості звіти по сторінках, джерелах і часу на сайті. Для SaaS важливі події, воронки, утримання та прив'язка до життєвого циклу користувача, але без зайвої персоналізації.
Дивіться на 6 критеріїв. Перший — чи можна розгортати систему на своєму домені або своєму сервері. Другий — як вона працює з cookies та ідентифікаторами. Третій — чи є експорт сирих або агрегованих даних. Четвертий — чи підтримуються події та цілі. П'ятий — наскільки зрозуміла інтеграція з CMS, тег-менеджером та API. Шостий — як виглядає ціна при зростанні трафіку.
Є ще один тихий критерій: хто буде цим користуватися через 3 місяці. Якщо звіти зрозуміє тільки один аналітик, проект зависне. Якщо дашборд читає редактор або продакт без інструкції, у аналітики більше шансів прижитися.
Коли хочеться подивитися на цифрову картину з іншого кута, іноді допомагає і організм людини. Цифри та факти. Цікаві: проста структура чисел нагадує, що хороші звіти не повинні бути перевантаженими.
5. Налаштування нової системи аналітики
Старт зазвичай складається з 4 кроків. Спочатку створіть проект на обраній privacy-first платформі. Потім підключіть домен. Далі додайте код лічильника на сайт. Після цього увімкніть збір базових подій і перевірте, що візити доходять до панелі без затримок.
На WordPress це часто робиться через плагін або вставку коду в шапку сайту. На кастомній платформі підключення може йти через шаблон, tag manager або серверний endpoint. На SPA-додатках особливо важливо перевірити навігацію між сторінками, тому що звичайний pageview там не завжди спрацьовує.
Далі налаштуйте цілі. Для медіа це може бути перегляд 3 сторінок, підписка на розсилку та прокрутка до кінця матеріалу. Для магазину — додавання в кошик, початок оформлення замовлення та покупка. Для B2B — відправка форми, бронювання демо та клік по email.
Не переписуйте стару логіку всліпу. Іноді в Google Analytics були цілі, які створювалися ради звітної звички, а не ради користі. На новому місці такі цілі краще не переносити, інакше в системі знову опиниться сміття.
Якщо команда любить порівнювати підходи в спокійній обстановці, знадобиться і матеріал як економити гроші без страждань: у аналітики теж є бюджет, і не завжди потрібно купувати найскладніший інструмент заради двох корисних графіків.
6. Перенос ключових метрик і подій
Найпоширеніша помилка при міграції — намагатися відтворити назви подій один в один. Краще спочатку описати сенс. Наприклад, стара подія GA «button_click» може в новій системі розділитися на три: клік по CTA в шапці, клік по CTA в статті та клік по CTA в футері. Це точніше, ніж одна загальна корзина.
Складіть таблицю співвідношення: стара подія, нова подія, параметр, місце на сторінці, бізнес-смисл. Для ecommerce окремо пропишіть дохід, кількість замовлень, середній чек і покинуту корзину. Для контенту — перегляди статті, дочитування, внутрішні переходи та підписки.
Є важлива деталь: в privacy-first аналітиці не завжди зручно повторювати user-level логіку з GA. Іноді замість спроби відстежити «одну й ту ж людину» краще вимірювати стійкі агрегати за сесією, сторінкою або джерелом. Це чесніше і часто чистіше.
Якщо у вас вже є події, пов'язані з dataLayer, не змінюйте все одразу. Спочатку перенесіть 5–7 найприбутковіших або найчастіших. Потім додавайте решту. Різка повна переробка майже завжди ламає звіти у маркетингу в найневдаліший день місяця.
І так, числа в звіті повинні мати сенс. Якщо новий лічильник показує більше конверсій, ніж форма реально відправляє, помилка майже напевно в подвійній активації події або в тому, що один клік враховується двічі.
7. Паралельний запуск і перевірка якості даних
Паралельний запуск потрібен мінімум на 2–4 тижні, якщо трафік і сценарії не надто прості. У цей період Google Analytics ще працює, а нова privacy-first аналітика вже збирає статистику. Порівнюйте не тільки цифри, але й структуру: джерела, посадкові сторінки, конверсії, популярні події.
Розбіжності майже неминучі. Один інструмент вважає візит після завантаження скрипта, інший — одразу після відкриття сторінки. Один обрізає частину трафіку через захист приватності, інший бачить більше подій на першому екрані. Панікувати рано. Спочатку перевірте розмітку, потім фільтри, потім налаштування домену.
Хороша практика — вести короткий журнал перевірок. Дата. Сторінка. Що клікнули. Що повинно з'явитися в звіті. Що реально з'явилося. Якщо помилка повторюється на одному шаблоні, виправлення знаходиться за 15 хвилин. Якщо ні, шукайте проблему в маршрутах SPA, в редиректах або в дублях тегів.
Для перевірки зручно використовувати тестовий сценарій з 3–5 діями: відкрити головну, перейти в статтю, клікнути по кнопці, надіслати форму, повернутися назад. Це нудно, зате видно, де втрачаються події. І так, тут допомагає дисципліна, а не інтуїція.
Якщо потрібна додаткова перевірка поведінки сторінок, іноді дивляться і таємниці океану: хороший внутрішній матеріал з довгим читанням показує, як аналітика поводиться на сторінках з високим часом залучення.
8. Вимкнення Google Analytics та фінальна перевірка
Вимикати стару аналітику варто тільки після того, як нова система стабільно тримає 2–3 тижні порівняння без великих провалів. Спочатку приберіть старі теги з GTM або шаблону. Потім перевірте, що жодних прихованих вставок GA не залишилося в плагінах, віджетах і сторонніх інтеграціях.
Після видалення старого коду оновіть політику конфіденційності. У ній повинні бути перераховані нова система, тип зібраних даних і мета обробки. Якщо у вас працює cookie-банер або управління згодою, перевірте сценарії згоди та відмови.
Фінальна перевірка проста: відкрити сайт в звичайному браузері, в режимі без cookies, на мобільному пристрої і через кілька сторінок підряд. Нова privacy-first аналітика повинна рахувати візити однаково передбачувано в цих 4 випадках, інакше десь залишилася дірка в розмітці.
Не забудьте про архів. Експортуйте потрібні звіти з Google Analytics, збережіть карту відповідності подій і відзначте дату відключення. Через півроку це заощадить години, коли хтось запитає, чому в минулому кварталі конверсія рахувалася інакше.
Якщо після відключення GA у вас все ще горить сповіщення про старий тег, значить, хтось сховав його в старій темі, у плагіні або в окремому лендингу. Ось тут і закінчується теоретична частина, а починається акуратна ручна перевірка кожного шаблону.
