Google Analytics 4 не может ответить на важные вопросы, когда у вас есть хранилище данных: какой маркетинговый канал привлекает клиентов, которые продолжают платить на 6-й месяц, какие страницы появляются на пути к закрытым сделкам, что конкретный потенциальный клиент просматривал перед бронированием демонстрации. Каждый из этих вопросов требует объединения данных о поведении в интернете с данными CRM на индивидуальном уровне. GA4 хранит веб-аналитику в собственном хранилище и не предоставляет пути для такого объединения на любом уровне.
Этот пробел усугубляет ограничения, о которых большинство команд уже знают. Отчеты GA4 по исследованию данных сэмплируются при объеме более 10 миллионов событий, поэтому наиболее важные объемы трафика дают оценки, а не точные подсчеты. Данные на уровне пользователя хранятся максимум 14 месяцев (2 месяца — единственная альтернативная настройка), что означает, что любой когортный анализ старше года незаметно исчезает. GA4 использует тот же механизм сбора данных на стороне клиента, что и рекламные теги Google, что делает его уязвимым для тех же блокировщиков рекламы; значительная часть трафика сайта никогда не записывается. ИИ-помощники (ChatGPT, Perplexity, Claude и Gemini) удаляют заголовок Referer при ссылке на внешние страницы, поэтому трафик, поступающий из этих источников, попадает в категорию «неназначенный», если вы не классифицируете его по utm_source в SQL. И если ответом на эти ограничения является GA4 360, то входная цена составляет 150 000 долларов США или более в год, только по запросу, и даже на этом уровне нет нативных объединений на уровне строк с данными CRM или данными о доходах.
Альтернатива, описанная здесь: собирать собственные события с помощью RudderStack JavaScript SDK, помещать их в Snowflake, разрешать идентификаторы с использованием RudderStack Profiles, формировать разрешенные данные с помощью dbt и создавать слой анализа в Hex. Это не эталонная архитектура; это реальная производственная сборка, адаптированная для внешнего использования, с каждой цифрой, взятой из того, что было реализовано. Команда с выделенным инженером по аналитике может развернуть ее за несколько дней. Моделирование и планирование данных занимает примерно 5-10 часов; панель мониторинга Hex занимает около 1-2 часов, в основном в автоматическом режиме, пока ИИ-агент Hex строит диаграммы по спецификации. Время на инструментарий варьируется в зависимости от состояния сайта, и это та часть, которую стоит тщательно проработать заранее.
Стек
Три слоя, каждый со своей задачей. RudderStack собирает события и направляет их в Snowflake. dbt моделирует необработанные таблицы в представления уровня витрин данных, которые BI-инструмент может запрашивать без бизнес-логики. Hex запрашивает витрины данных и отображает панель мониторинга.
Усилия по развертыванию, изложено просто:
Фаза
Примерное время
Примечания
Инструментарий
Сильно варьируется
Полностью зависит от текущего состояния сайта. Самая сложная часть для оценки.
Моделирование данных
~5 - 10 часов
Для того, кто знаком с dbt и оконными функциями
Панель мониторинга Hex
~1 - 2 часа
В основном асинхронно; ИИ-агент Hex строит, пока вы занимаетесь чем-то другим.
Шаг 1: Инструментарий
Все в этом стеке работает на пяти типах событий. Сессии, показатель отказов, время на странице, новые пользователи против вернувшихся, атрибуция канала и отслеживание конверсий — все это выводится из этих пяти вызовов. Не требуются пользовательские события глубины прокрутки, пинги вовлеченности, инструментарий кликов.
События
Вызовы RudderStack
Обеспечивает
Загрузка страницы
page()
Трафик, сессии, топовые страницы, каналы
Отправка формы
track('form_submitted')
Конверсии
Идентификация
identify()
Связывание анонимных данных с известными
Встреча начата
track('meeting_started')
Воронка, конверсия
Встреча забронирована
track('meeting_booked')
Первичная конверсия, конвейер
Последние два события специфичны для B2B-продаж с потоком самостоятельного планирования демонстраций. Замените их своими собственными событиями конверсии (order_completed, subscription_started, trial_activated) везде, где применяется логика воронки. Шаблоны моделирования на последующих этапах идентичны независимо от названия события.
Одно правило важнее всего остального на этом уровне:
При первой загрузке страницы захватите параметры UTM и реферер в собственный браузерный файл cookie и прикрепите их к каждому последующему событию в этой сессии.
Без этого посетитель, который пришел с рекламы Google, просмотрел три страницы, а затем отправил форму, будет иметь свою отправку формы, приписанную к последней странице, которую он посетил, а не к рекламе, которая его привела. Атрибуция будет неверной без уведомления, и нет способа исправить это постфактум. Установите файл cookie один раз при входе и считывайте его при каждом последующем событии. Это самая высокоэффективная строка кода инструментария во всей сборке, и она должна происходить в настройке SDK, а не в SQL.
Одна из возможностей разрешения идентификаторов встроена в сам RudderStack SDK: анонимная активность автоматически связывается с известной активностью в момент идентификации пользователя, без дополнительной настройки. Для многих сайтов этого достаточно. Проблема возникает, когда в разных системах используется более одного SDK. Каждый SDK разрешает идентификацию в своей собственной области и не имеет представления о том, что отслеживают другие SDK, что означает, что полный путь пользователя может оставаться изолированным даже после срабатывания отдельных событий идентификации. RudderStack Profiles устраняет этот пробел на уровне хранилища данных, продолжая работу там, где останавливаются отдельные SDK, и завершая граф идентификаторов по всем источникам. Затем dbt получает эти разрешенные данные в качестве входных, что делает представления пути пользователя и влияния конвейера точными.
Одно из недооцененных преимуществ нативной для хранилища коллекции заключается в том, что необработанная история событий остается корректируемой. Когда инструментарий меняется (переименованное свойство, поток регистрации, который разделяется на два, форма, которая перемещается от встроенного провайдера к нативному элементу), модель dbt согласовывает старые и новые данные и сохраняет полную историю нетронутой. Готовый инструмент агрегирует данные при приеме, поэтому прошлое фиксируется в момент его поступления. Хранилище сохраняет каждое необработанное событие, поэтому прошлые ошибки инструментария становятся данными для моделирования, а не данными, которые исчезли.
Шаг 2: Моделирование данных
Работа по моделированию — это то, что GA4 делал невидимо. Границы сессий, группировка каналов, фильтрация ботов, география, показатель отказов, время на странице и новые пользователи против вернувшихся — все это настройки GA4 по умолчанию. В хранилище данных это SQL-модели, которые кто-то должен написать, владеть и защищать. Эта передача владения является основным компромиссом. Приведенные ниже шаблоны охватывают все это, хотя их точность зависит от одного предварительного условия: разрешения идентификаторов. dbt может обрабатывать разрешение идентификаторов, но сложность значительно варьируется в зависимости от ситуации. RudderStack Profiles решает эту часть, а затем dbt выполняет моделирование на основе разрешенных данных.
Слой 1: Объединение и группировка каналов
Реальные сайты обычно имеют более одного потока событий. Полная реализация может объединять просмотры страниц маркетингового сайта, отправки форм на сайте, отправки веб-хуков от встроенного поставщика форм, вызовы идентификации и идентификаторы на стороне приложения, используемые для сквозного связывания доменов. Выходные данные — это одна плоская таблица, одна строка на каждое веб-событие, с согласованной схемой: event_id, anonymous_id, email, event_type, event_at, page_url, page_path, referring_domain, параметры UTM, user agent, IP и заголовок страницы. Все последующее является общим. Это единственный слой, который действительно специфичен для вашего сайта, поэтому репозиторий с открытым исходным кодом поставляет эту модель в качестве рабочего примера с призывом «переписать эту» вместо многократно используемого кода.
Классификация каналов относится к этому уровню, и два проектных решения делают её надежной. Во-первых, каналы оцениваются в строгом порядке приоритетности без перекрывающихся предикатов, поэтому источник, который может квалифицироваться как платный или органический социальный трафик, определяется однозначно. Во-вторых, AI-инструменты сопоставляются по utm_source перед Direct, а не по рефереру. AI-ассистенты удаляют заголовок Referer при переходе на внешние страницы, но добавляют utm_source: chatgpt.com, claude.ai, perplexity.ai и аналогичные. Классификация только по рефереру относит такие сессии к Direct. Сопоставление по utm_source и оценка AI Referral перед Direct позволяет сохранить видимость этого канала, что является актуальной задачей 2025 года и последующего периода, которую большинство унаследованных логик каналов не учитывают.
В промышленной эксплуатации классификация каналов работает как исходный CSV-файл (столбцы: pattern_type, pattern_value, channel, priority), а не как 130-строчный оператор CASE. Маркетолог может добавить строку, когда появляется новый AI-реферер. Именованные партнерские домены представлены явными строками. Приоритетность становится данными, которые можно проверить, а не потоком управления, который нужно изучать.
Уровень 2: Разрешение идентификации
Ретроактивное объединение email по anonymous_id: если любое событие для анонимного ID содержит адрес электронной почты, этот email привязывается ко всем событиям данного анонимного ID, прошлым и будущим. При конфликте приоритет имеет самый последний ненулевой email. Это позволяет в будущем найти конкретного человека и увидеть всю его историю просмотров до идентификации.
Помечайте анонимные ID, которые разрешаются в два или более различных email (is_multi_email_anon). Общие устройства, общие браузеры и киоски создают этот паттерн. Исключайте их из любого анализа, который связывает поведение с конкретным человеком, иначе просмотры одного человека появятся в записи другого.
Для большинства случаев использования вызовы identify() в веб-потоке обеспечивают рабочую отправную точку: любой посетитель, который отправляет форму или регистрируется, объединяется при первом вызове identify. Но отдельные SDK видят только свою область действия и не могут объединить полный граф пользователя между системами. RudderStack Profiles — это комплексное решение: оно собирает граф идентификации целостно по всем источникам, устраняя пробелы между SDK, которые оставляют после себя отдельные вызовы identify(). В планах Enterprise Profiles материализует этот разрешенный граф в Snowflake, а модели dbt строятся поверх него. Представления о пути пользователя (person journey) и влиянии на воронку (pipeline influence) становятся полностью точными только тогда, когда идентификация разрешена на этом уровне.
Уровень 3: Сессионизация
Сессия заканчивается через 30 минут бездействия — это та же граница, которую использует GA4, что делает количество сессий напрямую сопоставимым в период параллельной работы. Сессионизация точна лишь настолько, насколько точны ID, используемые в ней; RudderStack Profiles гарантирует, что эти ID полностью разрешены до запуска этого уровня.
Реализация: используйте lag() для событий каждого анонимного ID, отсортированных по временной метке, помечайте любой разрыв более 1800 секунд как начало новой сессии, выполняйте кумулятивную сумму этих меток для получения порядкового номера сессии и объединяйте его с анонимным ID для создания ключа сессии. Сессионизируйте каждый тип события, а не только просмотры страниц. Отправка формы, следующая за последним просмотром страницы, должна привязываться к правильной сессии, а не начинать новую.
Создавайте модель сессионизации как полную пересборку таблицы, а не инкрементально. Оконные функции требуют полной истории событий каждого анонимного ID, чтобы расставить границы сессий и вычислить время на странице через границы суток. Наивная инкрементальная модель по event_date неправильно разделяет сессии, которые приходятся на полночь; граница сессии вечером становится отдельной сессией на следующее утро, и количество сессий завышается. В масштабах потока событий маркетингового сайта полная пересборка таблицы происходит быстро.
Примечание: этот пример иллюстрирует паттерн. В репозитории сессионизация считывается из int_web_events_identified, поэтому каждое событие уже несет разрешенный person_email из веб-вызовов identify и, опционально, граф идентификации RudderStack Profiles. Границы сессий по-прежнему вычисляются для каждого anonymous_id; разрешение идентификации не меняет количество сессий или канал первого касания. Оно определяет, какому человеку принадлежит сессия, от чего зависят витрины данных о пути пользователя и влиянии на воронку.
Уровень 4: Метрики, которые GA4 давал бесплатно
Каждая из стандартных метрик GA4 — это решение, которое вы принимаете, когда владеете моделью. Вот как промышленная сборка определяет каждую из них.
Показатель отказов (Bounce rate): сессия с одним просмотром страницы, которая не привела к конверсии. Сессия с одной страницей, заканчивающаяся отправкой формы, считается вовлеченной, а не отказом, поэтому лендинги с высокой конверсией считываются правильно. В слое витрин данных есть два различных расчета показателя отказов, и они должны быть помечены отдельно: показатель отказов сессии (bounced sessions / total sessions) и показатель отказов лендинга (entry-page bounces / entrances). Эти два числа сходятся только на уровне общего показателя по сайту, а не по каналам, устройствам или страницам. Их смешивание приводит к несовместимым цифрам в дашбордах.
Время на странице: разрыв до следующего события в той же сессии, ограниченный 30 минутами. Значения выше этого порога устанавливаются в null, чтобы не учитывать простаивающие вкладки как вовлеченность. Последний просмотр страницы в любой сессии не имеет последующего события и также равен null. Назовите метрику "Среднее время на странице (измеренные просмотры)" в дашборде, чтобы читатели понимали, что это нижний предел, а не верхний.
Новые против вернувшихся: производная от порядкового номера сессии для каждого анонимного ID. Учитываются только сессии с просмотром страниц; сессии только внутри приложения, не содержащие маркетинговых просмотров страниц, не должны инициировать флаг вернувшегося пользователя.
Фильтрация ботов: явная модель, сочетающая сопоставление user-agent и поведенческие эвристики. Отфильтрованные боты исключаются из витрины трафика, чтобы каждый последующий показатель конверсии имел чистый знаменатель. Боты помечаются, но не удаляются из сырых данных, поэтому логика фильтрации остается проверяемой.
География: определяется по IP через справочную таблицу с явным значением-заглушкой для ненайденных IP, чтобы они никогда не отображались как реальная страна на географических картах.
Группировка каналов использует первое касание каждой сессии и создает стабильную, переиспользуемую метку. SQL ниже показывает рабочую реализацию, где AI Referral расположен перед Direct — это проектное решение, которое сохраняет видимость трафика из AI-источников:
Уровень 5: Витрины данных (Marts)
Слой витрин данных — это то, что запрашивает Hex. Здесь нет бизнес-логики, только готовые к отчетности таблицы, каждая из которых сформирована для одной части дашборда. Когда появляется новый потребитель (задача Reverse ETL, другой BI-инструмент, экспорт данных), вы добавляете витрину, а не разветвляете запрос.
Витрина
Гранулярность
web_traffic_daily
День x канал x категория устройства x страна (боты исключены)
web_page_performance
URL страницы x день
web_conversions
Одна строка на событие конверсии
web_pipeline_influence
Страница x канал x месяц возможности x тип записи
web_person_journey
Одна строка на событие на каждого разрешенного человека (PII)
Примечание: две из этих витрин, web_pipeline_influence и web_person_journey, полностью точны только при завершенном разрешении идентификации. Именно RudderStack Profiles делает эту точность надежной.
Шаг 3: Архитектура dbt
Полный каталог моделей следует трехслойному шаблону: «сырые» таблицы, выгруженные RudderStack, промежуточные модели для решения сложных задач и витрины данных, которые читает BI-слой. У каждого слоя своя задача: «сырые» таблицы остаются нетронутыми, промежуточные выполняют трансформации, а витрины предоставляют данные в удобном и очищенном виде.
Ключевые проектные решения необходимо задокументировать до написания первой строки SQL, так как каждое из них влияет на множество зависимых моделей ниже по потоку:
Область
Решение
Сессионное окно
30 минут неактивности. Смена UTM-метки или реферера в середине сессии не разделяет сессию. Канал, UTM и устройство назначаются один раз по первому касанию (first touch).
Инкрементальность
Полная пересборка таблицы. Оконные функции требуют полной истории anonymous_id. Инкрементальная модель на основе event_date некорректно разделяет сессии на стыке дней.
Отказ (Bounce)
Сессия с одним просмотром страницы, которая не привела к конверсии.
Время на странице
Дельта до следующего события в рамках сессии. Для последнего просмотра страницы: null. Значения свыше 30 минут: null.
Показатель отказов (Exit rate)
Для каждой страницы: процент просмотров этой страницы, которые оказались последними в своих сессиях.
Новые и вернувшиеся пользователи
Временная метка самого первого события для каждого anonymous_id. Учитываются только сессии с просмотрами страниц.
Устройство
Определяется из context_user_agent. Порядок имеет значение: планшеты перед мобильными; iOS Chrome и Firefox перед Safari; iOS перед macOS.
Боты
Помечаются флагом и исключаются из витрины трафика. Из «сырых» данных они не удаляются.
Тесты схемы, выполняемые в CI: unique для session_id, not_null для всех внешних ключей, ограничение полей с коэффициентами в диапазоне от 0 до 1, сверка количества просмотров страниц между промежуточными и событийными таблицами, а также тест пользовательского пути (person-trail), который выбирает одного идентифицированного человека и проверяет, что количество строк его пути и последовательность совпадают с «сырыми» событиями.
Шаг 4: Создание дашборда в Hex
Создание дашборда следует пятиэтапному агентному рабочему процессу. Этот процесс применим к любому BI-инструменту с возможностями генеративного ИИ, хотя встроенный ИИ-агент Hex делает этап построения графиков необычайно быстрым.
Первый этап: записать разговор с требованиями маркетинговой команды. Спросите их о том, на что они действительно смотрят, а не о том, что, по их мнению, им нужно. Стенограммы надежнее заметок для выявления отчетов, которыми люди пользуются ежедневно и даже не думают упоминать.
Второй этап: изучить стандартные готовые аналоги — в данном случае набор отчетов GA4 по умолчанию, — чтобы учесть отчеты, которые люди воспринимают как должное и о которых никогда бы не догадались попросить. Показатель отказов по целевой странице, разбивка на новых и вернувшихся, время на странице: ничто из этого не упоминается при обсуждении требований, потому что все считают, что это и так будет.
Третий этап: объединить запросы стейкхолдеров и готовые аналоги в приоритетный список отчетов, а затем двигаться в обратном направлении: учитывая уже созданные промежуточные модели, на каких витринах данных эти отчеты должны основываться?
Четвертый этап: планирование с ИИ-агентом: сопоставить промежуточные модели с необходимыми витринами и структурой дашборда. Затем передать этот план ИИ-агенту Hex с конкретными инструкциями по таблицам и столбцам и позволить ему построить интерфейс графика. Агент отлично справляется с построением графиков, когда вы четко указываете, какую витрину и столбцы использовать; ваша задача — обеспечить эту точность, а не определять семантические понятия, которые план уже зафиксировал.
Пятый этап: замкнуть цикл. Экспортировать готовый дашборд обратно агенту планирования и попросить его перепроверить каждую визуализацию на соответствие моделям данных, подтверждая, что каждый график считывает нужную таблицу и столбец и выполняет агрегацию так, как ожидает модель. Это быстрый автоматический этап проверки всего приложения.
Полученный дашборд состоит из семи вкладок: Обзор (Overview), Привлечение (Acquisition), Аудитория (Audience), Поведение (Behavior), Конверсии (Conversions), Влияние на воронку продаж (Pipeline Influence) и История писем (Email Journey Lookup). Первые шесть публикуются как единое приложение. Седьмое, отображающее адреса электронной почты и полную историю просмотров, представляет собой отдельно опубликованное приложение с явными и строго ограниченными правами доступа.
Пять нюансов реализации, которые рабочая версия учитывает правильно:
Сводные показатели с учетом веса сессий: при суммировании дневного показателя bounce_rate за неделю или месяц требуется формула sum(sessions * bounce_rate) / sum(sessions), а не avg(bounce_rate). День с 3000 сессиями должен весить больше, чем день с 3 сессиями. Тот же паттерн применяется к avg_session_duration_sec. Простое среднее арифметическое дневных средних значений дает неверные агрегированные цифры.
Раздельные метрики отказов: показатель отказов на уровне сессии и показатель отказов на целевой странице — это разные расчеты с разными знаменателями. Оба присутствуют в дашборде и называются соответственно «Показатель отказов сессии» (Session bounce rate) и «Показатель отказов целевой страницы» (Landing-page bounce rate). График с надписью «показатель отказов» без уточнений двусмысленен в отношении этих двух значений.
Видимость текущего незавершенного периода: трендовые графики включают текущую неделю. Маркетологам нужно проверять дашборды посреди недели и видеть показатели за прошедшие дни этой недели, даже если она еще не завершена.
Ограничение по пороговым значениям соотношений: на графике отказов по целевым страницам используется условие having entrances >= 25 для подавления шума от единичных визитов. Страница с двумя заходами не должна доминировать в сортировке при показателе отказов 100%.
Вкладка с PII (персональными данными) изолирована отдельно: web_person_journey содержит person_email в сочетании с полными путями страниц, временем сессий и событиями конверсии. Она публикуется как отдельное приложение Hex с более жесткими средствами контроля доступа, а не как вкладка в общекорпоративном дашборде.
Запрос для ключевого показателя (scorecard) на вкладке 1 иллюстрирует паттерн учета веса сессий, который должен применяться везде, где вы агрегируете ежедневные столбцы с соотношениями:
Отчет, который GA4 не может вам предоставить: Влияние на воронку продаж (Pipeline influence)
Влияние на воронку продаж — это не атрибуция.
Сделка, с которой контактировали N страниц, вносит свою полную денежную сумму в N строк таблицы. Эти строки не суммируются в общий объем воронки. Метрика отвечает на вопрос, какие страницы и каналы появляются на пути к сделке; она ранжирует их по объему воронки, с которым они соприкасаются, но не распределяет ценность (attribution credit). Всегда представляйте показатели влияния на воронку в виде рейтинга, но никогда в виде суммы.
Определение: страница повлияла на сделку, если кто-то из аккаунта этой сделки просматривал страницу более 20 секунд до создания сделки. Порог в 20 секунд отсекает случайные заходы и фокусирует метрику на визитах с подлинной вовлеченностью. Все временные метки просмотров страниц и сделок сравниваются в едином часовом поясе (UTC), что гарантирует захват просмотров в часы, непосредственно предшествующие созданию сделки, а не только тех, что были за несколько дней до этого.
Представление влияния на воронку по умолчанию ориентировано на новые продажи (New Business). Контакты существующих клиентов активно просматривают документацию, поэтому воронка продлений ( renewals) существенно искажает отчет при смешивании с новыми продажами. Измерение record_type содержит New Business и Renewal в качестве отдельных значений; всегда уточняйте, что именно вы читаете.
Примерно 40% сделок в этой производственной сборке имеют хотя бы один подходящий просмотр страницы до создания. Оставшиеся 60% просто не посещали маркетинговый сайт в это окно. Сам показатель покрытия является полезным индикатором воронки: он показывает, какая часть воронки новых продаж была видна в веб-пространстве до того, как сделка была создана.
Поиск пути пользователя по email — это вторая часть данного раздела и представление, вызвавшее наиболее бурную реакцию на сессии, где рассматривалась эта сборка. Введите любой адрес электронной почты в параметр Hex, и витрина данных вернет полный хронологический путь этого человека: все посещенные страницы в порядке очереди, канал, который привел пользователя, время, проведенное на каждой странице, все конверсии и кампании, привязанные к каждой сессии. Структурно это невозможно в GA4 на любом уровне; это требует объединения поведенческих данных с данными CRM на индивидуальном уровне в одной системе с помощью «живого» запроса. Запрос, лежащий в основе этого:
Рассматривайте web_person_journey как идентифицируемые персональные данные (PII). Витрина содержит email пользователя в связке с полными путями страниц, временем сессий и событиями конверсии. Опубликуйте поиск по email как отдельное приложение Hex с явными и продуманными правами доступа. Не добавляйте его в качестве вкладки на общекорпоративную панель мониторинга без принятия взвешенного решения о контроле доступа.
Где место RudderStack
RudderStack — это агентный CDP. В этом стеке он отвечает за сбор, идентификацию и маршрутизацию — три уровня, которые находятся выше каждой таблицы витрины данных, описанной в этой статье.
JavaScript SDK инструментирует пять событий и сохраняет каждое необработанное событие page, track, identify и conversion в Snowflake в виде строки, доступной для запросов. Тот же поток событий распределяется в GA4, рекламные платформы и любые другие пункты назначения без повторного инструментирования сайта. Пункты назначения можно добавлять или менять, не затрагивая код приложения.
Profiles отвечает за уровень разрешения идентификации, связывая анонимные сессии на маркетинговом сайте с идентифицированными пользователями продукта из разных источников. Именно это объединение делает представление пути пользователя полным для тех, кто идентифицировался в приложении продукта, но никогда не отправлял формы на маркетинговом сайте. Для всех остальных планов вызовы identify() в веб-потоке покрывают большинство реальных случаев идентификации.
Практическое замечание по миграции: сохранение активного пункта назначения GA4 ничего не стоит. Поток событий отправляется одновременно и в Snowflake, и в GA4. Маркетинг сохраняет привычный интерфейс для быстрой проверки кампаний, отчетов по частоте и всего, что не требует объединения с CRM. Оба пункта назначения могут работать параллельно бесконечно долго.
Компромиссы, о которых стоит знать перед началом
Эти пять пунктов стабильно всплывают на второй месяц проектов, в которых они не обсуждались на первом месяце.
Вы перестраиваете то, что GA4 предоставлял бесплатно. Сессионизация, группировка каналов, фильтрация ботов, география, показатель отказов, новые против вернувшихся пользователей и время на странице — все это стандартные функции GA4, которые становятся SQL-моделями, как только вы покидаете этот инструмент. Шаблоны в этой статье охватывают их все, а репозиторий с открытым исходным кодом содержит рабочие версии. Но ответственность переходит к вашей команде; кто-то должен поддерживать, обновлять и защищать эти определения по мере развития бизнеса.
Кто-то должен отвечать за семантический слой. Первое разногласие в любом проекте по аналитике хранилищ данных — это «что такое сессия» или «что считается активным пользователем». GA4 принимал это решение негласно. Теперь маркетинг, продукт и финансы должны прийти к явному, задокументированному соглашению до того, как панели мониторинга станут доступны, иначе каждая команда будет использовать свой собственный SQL, и цифры никогда не сойдутся. Заложите время на это согласование до начала сборки, а не после.
