Команды обычно начинают думать о том, как перейти с Google Analytics на first-party аналитику, после одного из трёх событий: проверки приватности, обновления баннера согласия или отчёта, которому больше никто не доверяет. Этот переход — не про моду. Он про контроль, и именно поэтому переход на first-party аналитику часто становится не просто техническим шагом, а решением уровня стратегии.
Google Analytics может неплохо подходить для общих трендов, но многим командам нужны данные, которыми они владеют, которые могут хранить на своих условиях и которые соответствуют их реальным бизнес-правилам. Просмотр страницы с согласием — это не то же самое, что отслеженный просмотр страницы, и эта разница важна, когда юридический отдел, продукт и маркетинг смотрят в одну и ту же панель. Некоторым командам также нужна first-party аналитика для сайта с хранением данных в определённом регионе.
Есть и другая причина. Контроль измерений.
С first-party аналитикой вы сами решаете, что считать сессией, что считать конверсией и какие события вообще должны существовать. Это звучит незначительно, пока кто-то не спросит, почему регистрация на рассылку считается дважды на мобильных устройствах и один раз на десктопе. Тогда это уже кажется очень важным.
Для агентств и мультибрендовых команд преимущество ещё заметнее. Единый подход к отчётности для всех клиентских сайтов в одной панели может снизить обычную путаницу вокруг тегов, целей и того, «какая версия правды» сейчас актуальна. Одна панель. Одна схема. Меньше загадок.
Проведите аудит текущей настройки Google Analytics
Прежде чем что-либо менять, составьте список всего, что вы уже отслеживаете в Google Analytics 4, а также остатков выгрузок из Universal Analytics. Начните с базового: просмотры страниц, события, конверсии, аудитории, исследования и пользовательские параметры. Затем идите дальше. Миграция быстро проваливается, если старую настройку никогда не документировали.
Перечислите все названия событий, даже неловкие. Если вы отслеживаете form_submit, newsletter_signup и cta_click, запишите их вместе с параметрами. Проверьте, какие события отмечены как конверсии, потому что именно их люди обычно замечают в первую очередь, если они исчезают. Воронка оформления заказа переживёт потерю события прокрутки. А вот потерю события покупки — обычно нет.
Аудитории тоже важны. Если у маркетинга есть аудитория ремаркетинга для посетителей страницы с ценами, зафиксируйте правило, окно членства и источник данных. Если продукт использует когортный отчёт по активированным пользователям, опишите условие простыми словами, а не только названием отчёта. Метка — это не план.
Отчёты тоже стоит каталогизировать. Экспортируйте названия дашбордов, диапазоны дат, на которые люди опираются, и фильтры, применённые к каждому из них. У одной команды, с которой я работал, был «еженедельный отчёт для руководства», который имел смысл только из-за скрытого фильтра по платному трафику. Такие детали теряются при спешке, и следующий понедельник становится тяжёлым.
Определите требования к first-party аналитике
Когда текущая схема описана, решите, что новая first-party аналитика должна сохранить. Список должен быть конкретным: просмотры страниц, начало сессии, исходящие клики, заполнение форм, покупки, события входа в систему и состояние согласия. Если вы не можете назвать событие, скорее всего, его и не стоит отслеживать.
Думайте не только о событиях, но и о пользовательских сценариях. Пользователь может зайти на статью в блоге, открыть страницу с ценами, начать форму демо, бросить её, а потом вернуться через два дня по email. Ваша first-party аналитика должна позволять связать эти шаги без догадок. Значит, нужно определить идентификаторы, правила хранения данных и то, какие события относятся к посетителю, а какие — к авторизованному пользователю.
Обработка согласия должна быть в списке требований с самого начала. Если посетитель отклоняет cookies аналитики, вы отключаете всё отслеживание, отправляете события без cookies или ждёте, пока согласие будет дано? Ответ влияет на объём данных, соответствие требованиям и на то, как продуктовая команда интерпретирует спад трафика после изменения баннера. Никаких догадок.
Ограничения тоже нужно записать. Возможно, вам достаточно 12 месяцев истории событий. Возможно, отдел продаж интересуют только 6 событий конверсии. Возможно, финансам нужны данные о покупках, сгруппированные по тарифу, региону и биллинговому циклу. Эти цифры позже повлияют на выбор платформы и помогут раньше ограничить разрастание объёма работ.
Выберите подходящую платформу first-party аналитики
Здесь команды часто всё усложняют. Начните с владения: кто размещает данные, кто управляет схемой и кто может выгружать их по запросу? Затем переходите к вариантам self-hosting, функциям соответствия требованиям, интеграциям и поддержке миграции. Если платформа не может чётко ответить на эти вопросы, лучше искать дальше.
Право собственности на данные должно быть видно и в договоре, и в админ-панели. Self-hosting может быть важен, если служба безопасности хочет, чтобы данные оставались внутри вашей инфраструктуры. Функции соответствия требованиям важны, если вам нужен хостинг в ЕС, маскирование IP, сбор данных с учётом согласия или рабочие процессы удаления данных. Интеграции важны, потому что никто не хочет вручную переписывать данные о покупках из Shopify в таблицу каждую пятницу.
Поддержка миграции — это не просто модное слово. Спросите, может ли платформа импортировать исторические события, повторять ваши старые названия событий или помочь перенести логику конверсий из Google Analytics. Если вы сравниваете варианты, продукт astrina стоит рассмотреть вместе с вашими задачами по трекингу, особенно если вам нужны аналитика и видимость сайта в одном месте. Ещё один практический момент: если ваша команда уже проверяет все сайты, за которыми вы следите, переход ощущается не как смена инструмента, а как наведение порядка в отчётности.
Выбирайте платформу, которая соответствует тому, как ваша команда действительно работает. Небольшой контент-команде не нужна та же архитектура, что и e-commerce-команде, обрабатывающей сотни транзакций в день. У стартапа с одним маркетологом и одним инженером потребности другие, чем у агентства, управляющего 30 проектами. Простая логика всё ещё помогает.
Воссоздайте план трекинга
Теперь превратите аудит в новую схему событий. Сопоставьте каждое событие Google Analytics с названием события в first-party аналитике, а затем решите, оставить старое имя или изменить его. Если generate_lead становится form_completed, зафиксируйте причину. Если имя меняется, все связанные отчёты тоже нужно менять.
Используйте понятные правила именования, которые будут читаться и через шесть месяцев. Последовательность важнее хитрости. Простая структура вроде action_object_context часто удобнее в поддержке, чем набор разовых названий, которые может объяснить только их автор. Одного странного названия достаточно, чтобы сломать дашборд.
Конверсии тоже нужно аккуратно переписать. Конверсия в Google Analytics, основанная на целевой странице, может стать событием first-party аналитики, срабатывающим при успешной отправке формы. Для покупки могут понадобиться параметры валюты, продукта, тарифа и промокода. Если в исходной настройке были скрытые допущения, опишите их сейчас. Иначе новый отчёт будет расходиться со старым, и никто не поймёт почему.
Отдельно зафиксируйте, что не отслеживается. Если вы решили не учитывать внутренний трафик сотрудников, укажите фильтр. Если вам не важна глубина скролла больше 50%, так и напишите. Такие решения помогают избежать ложных споров позже, что особенно полезно, когда на встрече трое человек «помнят» старую настройку по-разному.
Внедрите и протестируйте новую настройку аналитики
Установка должна быть скучной. Добавьте скрипт, подтвердите домен и подключите состояние согласия до того, как что-либо ещё начнёт срабатывать. Если платформа предлагает сниппет для tag manager, сначала проверьте его на staging. Сломанная first-party аналитика может выглядеть рабочей, при этом отправляя ерунду.
Тестируйте по одному событию за раз. Откройте просмотр страницы, отправьте форму, кликните по внешней ссылке и выполните тестовую покупку, если среда это позволяет. Затем проверьте, что каждое событие приходит с правильными свойствами, временными метками и идентификаторами пользователя. Две минуты тестирования могут сэкономить две недели отладки.
Панели отчётов заслуживают такой же проверки. Посмотрите на верхнеуровневый график трафика, количество конверсий и любую воронку, которую, как вы ожидаете, увидит руководство. Сравните цифры с исходной системой, где это возможно. Если платёжная система показывает 18 заказов, а аналитика — 14, запускать ещё рано.
Отдельно проверьте обработку согласия. Отклоните cookies, обновите страницу и убедитесь, что скрипт ведёт себя так, как задумано. Затем примите cookies и проверьте, что отслеживание возобновляется корректно. Этот шаг легко пропустить. Но не стоит.
Запустите обе системы параллельно
Параллельный запуск даёт запасной вариант. Оставьте Google Analytics активной, пока first-party аналитика собирает те же основные события в течение определённого переходного периода. Этот период может составлять 2 недели или 30 дней — в зависимости от трафика и уровня тревожности заинтересованных сторон. Главное — определить его до первой встречи по сравнению данных.
Сравнивайте две системы по тренду, а не ожидайте идентичных итогов. Правила согласия, логика сессий, фильтрация ботов и модели атрибуции могут создавать расхождения. Если Google Analytics показывает больше сессий, спросите, не связано ли это с поведением согласия или дублирующими тегами. Если first-party аналитика показывает меньше покупок, проверьте триггер события и страницу подтверждения заказа, прежде чем винить платформу.
Используйте краткий журнал расхождений. Записывайте дату, метрику, разницу, возможную причину и исправление. У одной команды оказалось, что страница «спасибо» загружалась без события покупки в Safari, потому что событие срабатывало после редиректа. Такие проблемы встречаются часто, а журнал помогает не повторять ту же ошибку ещё в трёх релизах.
Если вам нужно понять, насколько агрессивно отслеживать изменения, вопрос стоит ли выбирать уведомления аналитики довольно быстро всплывает в переходные периоды. Уведомления могут поймать падения, но слишком большое их количество превращается в шум. Десять шумных уведомлений хуже одного полезного.
Отключите Google Analytics и отслеживайте результаты
Когда данные достаточно хорошо совпадают для вашей команды, переключайтесь без лишней суеты. Уберите старые теги с сайта, заархивируйте старые отчёты и задокументируйте новый источник истины. Сохраните копию старых настроек property в Google Analytics, названий событий и определений аудиторий на случай, если позже кто-то спросит, почему метрика изменилась в марте. Этот вопрос всегда задают позже.
После переключения отслеживайте качество данных как минимум в течение первых 2 циклов отчётности. Следите за отсутствующими событиями, дублирующимися покупками и резкими падениями трафика по каналам. Проверяйте несколько реальных сессий полностью, а не только сводку на панели. Цифры могут выглядеть нормально, пока одна форма тихо сломана.
Опишите рабочий процесс, который заменяет старый. Кто добавляет новые события? Кто утверждает изменения в названиях? Кто проверяет поведение согласия после обновления баннера cookie? Если этот процесс живёт только в чьей-то голове, он сломается в первый же отпуск этого человека.
Некоторые команды оставляют старую property только для чтения в качестве исторического справочника. Это разумно. Просто убедитесь, что команда знает, где смотреть и какие дашборды уже устарели, потому что старые отчёты имеют привычку снова появляться в презентациях спустя шесть месяцев после миграции с Google Analytics на first-party аналитику.
Если ваша команда также отслеживает состояние сайта и технические изменения вместе с аналитикой, полезно держать для этого одно и то же место отчётности. Настройка, которая уже следит за всеми сайтами, за которыми вы следите, может упростить постмиграционный аудит, особенно когда один график требует проверки производительности, а другой — проверки трекинга в тот же день.
Финальный шаг не самый эффектный: продолжайте проверять качество событий после запуска и исправьте первый сломанный тег до того, как он станет новой нормой.
