Как перенести аналитику с matomo на privacy-first аналитику
Зачем мигрировать с Matomo
Переход на privacy-first аналитику обычно начинается не с интерфейса, а с вопроса: зачем вообще менять Matomo. Ответов три. Первый — требования к приватности, второй — желание упростить сбор данных, третий — уменьшить зависимость от cookie. Если у вас сайт с аудиторией из ЕС, медицинский проект или просто команда, которая не хочет лишний раз трогать пользовательские согласия, повод уже есть.
Matomo часто удобен как привычная система, но его отчёты и настройки постепенно обрастают исключениями, плагинами и ручными правками. В какой-то момент владельцу сайта нужно не «ещё одно поле в форме согласия», а более простая схема, где аналитика собирается аккуратно и без лишних следов. Отсюда и запрос: как перенести аналитику с matomo на privacy-first аналитику.
Есть и практический аргумент. Когда сбор данных меньше зависит от cookies, легче объяснить логику маркетологам, юристам и разработчикам. Не всем. Но чаще всего — да.
Если же Matomo используется только ради базовых событий, глубокой кастомизации нет, а отчёты нужны для 5–7 регулярных решений, migration обычно проходит без драматических потерь. Сложнее, когда в Matomo завязаны сегменты, ecommerce и длинные цепочки целей; там уже нужен план, а не энтузиазм.
Что подготовить перед переносом
Перед переносом соберите 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, если он поддерживается вашей платформой. После этого включите consent-less сбор там, где это допустимо политикой компании и юридической схемой проекта. Не магия, а последовательность из 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 аналитики изменился поток событий, вы будете рады, что не разыскиваете историю по чатикам, тикетам и памяти одного уставшего маркетолога.
