Як перенести аналітику з matomo на privacy‑first аналітику
Навіщо мігрувати з Matomo
Перехід на privacy-first аналітику зазвичай починається не з інтерфейсу, а з питання: навіщо взагалі змінювати Matomo. Відповідей три. Перша — вимоги до приватності, друга — бажання спростити збір даних, третя — зменшити залежність від cookie. Якщо у вас сайт з аудиторією з ЄС, медичний проект або просто команда, яка не хоче зайвий раз торкатися користувацьких згод, привід вже є.
Matomo часто зручний як звична система, але його звіти і налаштування поступово обростають виключеннями, плагінами і ручними правками. В якийсь момент власнику сайту потрібно не «ще одне поле в формі згоди», а більш проста схема, де аналітика збирається акуратно і без зайвих слідів. Відтак і запит: як перенести аналітику з matomo на privacy-first аналітику.
Є і практичний аргумент. Коли збір даних менше залежить від cookies, легше пояснити логіку маркетологам, юристам і розробникам. Не всім. Але частіше за все — так.
Якщо ж Matomo використовується тільки для базових подій, глибокої кастомізації немає, а звіти потрібні для 5–7 регулярних рішень, міграція зазвичай проходить без драматичних втрат. Складніше, коли в Matomo зав'язані сегменти, електронна комерція та довгі ланцюги цілей; там вже потрібен план, а не ентузіазм.
Що підготувати перед перенесенням
Перед перенесенням зберіть 5 груп даних: цілі, події, джерела трафіку, звіти Matomo, інтеграції та доступи до сайту. Без цього міграція перетворюється на вгадування. І так, вгадування майже завжди дорожче.
Почніть зі списку цілей. Запишіть, які дії вважаються конверсією: відправка форми, клік по телефону, реєстрація, завантаження файлу, покупка. Для кожної цілі корисно вказати не тільки назву, але й сторінку, де вона спрацьовує, і умови спрацьовування. Один приклад краще десяти загальних фраз.
Потім пройдіться по подіях. У Matomo вони могли бути розмічені по-різному: частина через JavaScript, частина через GTM, частина через серверні виклики. Тут знадобиться таблиця або хоча б документ з колонками «подія», «категорія», «дія», «ярлик», «сторінка», «замітка». Такий список економить години на розборі старих налаштувань.
Окремий блок — джерела трафіку. Збережіть, які UTM-мітки у вас реально використовуються, які канали пов'язані з рекламними кабінетами, які кампанії приходять з короткими посиланнями або редиректами. Без цього нова система може зібрати візити, але ви не зрозумієте, звідки прийшов користувач. А це вже проблема не аналітики, а рішень.
Не забудьте про інтеграції. CRM, коллтрекинг, форми, чат, серверна відправка подій, BI-панель — все це потрібно перерахувати до старту. Якщо доступів до сайту, GTM, CMS або CDN не вистачає, їх краще запросити заздалегідь. Інакше перенесення зупиниться на другому кроці.
Сопоставлення метрик Matomo та нової системи
Порівняння метрик починайте з простого: сторінки, події, конверсії, UTM-мітки та користувацькі сегменти. Не намагайтеся одразу зіставити все. Спочатку базові речі, потім вже нюанси. Так менше шансів заплутатися в різниці методологій.
Сторінки в Matomo і в новій системі зазвичай збігаються за URL, але не завжди за правилами нормалізації. Перевірте, як враховуються слеші, параметри, якорі та редиректи. Один і той же шлях може виглядати як три різні рядки, якщо правила відрізняються. Для інтернет-магазину це особливо помітно на картках товарів і фільтрах.
Події краще перевіряти парами. Наприклад, якщо в Matomo є клік по кнопці «Залишити заявку», у новій системі потрібно створити той же тригер і порівняти не тільки число спрацьовувань, але й умови. Іноді в Matomo подія ловилася на батьківському блоці, а нова система чекає точний селектор. Сюрприз простий, наслідки неприємні.
Конверсії та цілі вимагають окремого списку. Для кожної старої цілі запишіть: ім'я, джерело події, сторінку, умову, цінність. Потім порівняйте з новою моделлю. Якщо в Matomo ціль вважалася за переглядом сторінки «Дякуємо», а нова система вважає форму за submit, цифри будуть розходитися вже на старті. Це нормально, але тільки якщо ви заздалегідь це зафіксували.
UTM-метки перевіряйте на 2 рівнях: як вони приходять у систему і як потім відображаються в звітах. Іноді різниця з'являється через регістр букв, іноді через автопідстановку кампаній, іноді через редиректи з обрізанням параметрів. Внутрішні сегменти також варто описати: нові користувачі, повернуті, трафік з email, користувачі з конкретної країни. Сегмент без опису — майже завжди майбутня помилка.
Налаштування privacy-first аналітики
Базова настройка починається з установки лічильника. Далі задайте режим без cookies, якщо він підтримується вашою платформою. Після цього увімкніть збір без згоди там, де це дозволяє політика компанії та юридична схема проєкту. Не магія, а послідовність з 3–4 кроків.
Фільтрація внутрішніх візитів потрібна одразу. Якщо команда з 12 осіб відкриває сайт по 20 разів на день, аналітика швидко втрачає сенс. Виключайте IP офісу, тестові пристрої, staging-домени і, якщо потрібно, окремі облікові записи співробітників. Інакше ви побачите «зростання» від людей, які просто перевіряли кнопку.
Далі налаштуйте базові події: перегляд сторінки, відправка форми, клік по телефону, клік по email, завантаження файлу. Не намагайтеся перенести все з Matomo за один вечір. Спочатку ядро, потім рідкісні події. На цьому етапі особливо корисно звірятися з документацією і тестовим середовищем.
Якщо обрана privacy-first аналітика підтримує серверні події, використовуйте їх там, де браузерні події ламаються через блокувальники або складні сценарії. Це важливо для оплат, закритих кабінетів і довгих форм. Але не тягніть сервером все підряд, інакше позбудетеся прозорості в налагодженні.
Іноді допомагає окремий тестовий домен або staging-звіт. На ньому можна безпечно натиснути 7–10 ключових кнопок, перевірити фільтри та впевнитися, що приватна аналітика не збирає сміття. Так, це нудно. Зате потім менше нічних правок.
Перенесення подій, цілей та воронок
Перенос подій робіть за пріоритетом: спочатку 5–10 найцінніших дій, потім решта. Якщо у вас є ecommerce, почніть з add to cart, begin checkout, purchase, а вже потім підключайте перегляди фільтрів і кліки по рекомендованим блокам. Логіка проста: що впливає на гроші, те переноситься першим.
Цілі в Matomo нерідко будувалися навколо сторінок подяки або конкретних URL. У новій системі такий підхід також можливий, але краще переглянути його разом з технічною реалізацією. Іноді форма надсилається через AJAX і користувач не потрапляє на окрему сторінку — тоді потрібна фіксація події, а не сторінки. Так точніше і спокійніше.
Воронки перевіряйте по кроках. Для реєстрації це може бути 4 екрани: вхід на лендинг, натискання на кнопку, заповнення форми, підтвердження по email. Для замовлення — кошик, доставка, оплата, підтвердження. У кожного кроку має бути свій тригер і свій тест. Один пропущений крок ламає всю картину.
Якщо в Matomo були складові цілі або сегментні воронки, не намагайтеся скопіювати їх буквально. Краще розкласти логіку на окремі події та зібрати воронку заново вже в privacy-first аналітиці. Іноді така пересборка навіть корисніша старої схеми: спливають зайві кроки та мертві кліки.
Для ecommerce-сценаріїв провірте суми, валюту, ID замовлення та скасування. На практиці часто плутають передачу ціни та знижки, а потім звіт виглядає красиво, але не збігається з CRM. В цей момент знадобиться внутрішній документ по правилам розрахунку.
Перевірка якості даних після міграції
Перші 3–7 днів після запуску — це не «спостерігаємо», а звіряємо. Відкрийте старі та нові звіти поруч і порівняйте сторінки, події, конверсії, джерела. Розбіжності майже неминучі. Питання лише в тому, чи можете ви їх пояснити.
Починайте перевірку з ручних тестів. Зайдіть на сайт, відкрийте 2–3 сторінки, натисніть кілька кнопок, надішліть форму, переходьте за UTM-посиланням. Потім подивіться, чи з'явилися події в новій системі і чи не зламався шлях користувача. Такий тест звучить примітивно, але саме він ловить 80% помилок.
Окремо перевірте реферальний трафік. Часто він зникає через редиректи, неправильний список виключень або налаштування cookie-less режиму. З рекламними переходами також бувають помилки: UTM читаються, але канал йде в «direct» через проміжну сторінку. Якщо це сталося, не поспішайте звинувачувати платформу; спочатку подивіться на ланцюг переходів.
Сегменти звіряйте після базових звітів. Якщо в Matomo у вас було 2 сегменти за країнами і 3 за джерелами, перевірте, чи збігаються логіка і обсяг. Невеликі відхилення допустимі, але різкий провал в одному сегменті зазвичай говорить про помилку фільтра або правила.
Хороша практика — вести журнал розбіжностей. У ньому фіксують дату, сторінку, подію, старе значення, нове значення та пояснення. Це рятує, коли через тиждень хтось запитує, чому покупки стали меншими на 12. Відповідь вже не потрібно шукати знову.
Що робити зі старим Matomo після переходу
Після переходу Matomo не обов'язково видаляти одразу. Частіше залишають 3 варіанти: архів, замороження збору або повне відключення. Вибір залежить від юридичних вимог, термінів зберігання і того, як часто команда повертається до старих звітів.
Якщо потрібен архів, залиште доступ тільки на читання і зафіксуйте дату зупинки збору. Це зручно для історичних порівнянь і внутрішніх перевірок. Якщо звіти більше не використовуються в роботі, можна перенести основні висновки в документацію: список цілей, джерела, правила сегментів, важливі виключення. Документ короткий, але рятує при суперечці через 6 місяців.
Повне відключення старої установки підходить не всім. Іноді Matomo залишається як резерв на 30–60 днів, щоб зловити пропущені події або спірні розбіжності. Потім його можна прибрати, коли нова аналітика стабільно збирає всі потрібні дії.
Чек-лист запуску та контроль після переносу
Перед фінальним запуском перевірте 8 речей: лічильник встановлений, режим без cookies увімкнений, внутрішні візити виключені, цілі пересобрані, UTM читаються, форми ловляться, ecommerce передається, звіти відкриваються. Якщо хоча б один пункт порожній, запуск краще не поспішати.
В перші дні після переносу призначте одного відповідального за аналітику. Не команду, а одну людину. Він дивиться логи, порівнює звіти, збирає помилки і відповідає на питання, чому у сторінки «Контакти» раптово 0 подій. Такий режим особливо корисний, коли в проекті одночасно йдуть реліз і рекламна кампанія.
Потім заведите регулярну ревізію — раз на 2 тижні або раз на місяць, в залежності від трафіку. Перевіряйте нові форми, нові кнопки, нові лендинги, нові рекламні UTM та зміни в consent-банері. Будь-яка правка на сайті може вплинути на аналітику, навіть якщо розробник клянеться, що «ми тільки змінили текст».
І ще один дрібний, але частий пункт: зберігайте список усіх змін в одному місці. Коли через 3 місяці доведеться пояснювати, чому у privacy-first аналітики змінився потік подій, ви будете раді, що не розшукуєте історію по чатикам, тикетам і пам'яті одного втомленого маркетолога.
