Google Analytics 4 не может ответить на самые важные вопросы, когда у вас появляется хранилище данных: какой маркетинговый канал приводит аккаунты, которые все еще платят на 6-й месяц, какие страницы появляются на пути к закрытым сделкам, что конкретный потенциальный клиент просматривал перед бронированием демо. Каждая из этих задач требует объединения данных о поведении на сайте с данными CRM на индивидуальном уровне. GA4 хранит веб-аналитику в собственном изолированном хранилище и не предоставляет никаких возможностей для такого объединения ни на одном из тарифных планов.
Этот пробел усугубляет ограничения, о которых большинство команд уже знает. Отчеты по исследованиям в GA4 подвергаются семплированию при превышении примерно 10 миллионов событий, поэтому наиболее важные объемы трафика дают оценки, а не точные показатели. Данные на уровне пользователей хранятся максимум 14 месяцев (единственная альтернативная настройка — 2 месяца), а это значит, что любой когортный анализ старше года тихо исчезает. GA4 использует те же механизмы сбора данных на стороне клиента, что и рекламные теги Google, что делает его уязвимым для тех же блокировщиков рекламы; значительная часть трафика сайта никогда не фиксируется. ИИ-ассистенты (ChatGPT, Perplexity, Claude и Gemini) удаляют заголовок Referer при ссылках на внешние страницы, поэтому трафик из этих источников попадает в «не назначенные» (unassigned), если вы не выполняете классификацию по utm_source в SQL. А если ответом на эти ограничения становится GA4 360, цена за вход составляет от 150 000 долларов в год по запросу, и даже на этом уровне нет нативных объединений на уровне строк с данными CRM или выручки.
Альтернатива, описанная здесь: сбор событий первой стороны с помощью JavaScript SDK от RudderStack, их загрузка в Snowflake, разрешение идентификации с помощью RudderStack Profiles, формирование полученных данных с помощью dbt и построение уровня анализа в Hex. Это не эталонная архитектура; это реальная продакшен-сборка, очищенная для внешнего использования, где каждый показатель взят из реально запущенного проекта. Команда с выделенным инженером по аналитике может развернуть ее за несколько дней. Моделирование и планирование данных занимают примерно 5–10 часов; дашборд в Hex создается примерно за 1–2 часа, в основном без участия человека, пока ИИ-агент Hex строит графики по спецификации. Время инструментирования зависит от состояния сайта и является той частью, которую стоит тщательно оценить заранее.
Стек
Три слоя, у каждого из которых одна задача. RudderStack собирает события и направляет их в Snowflake. dbt моделирует сырые таблицы в представления витрин данных (mart-layer), которые BI-инструмент может запрашивать без необходимости содержать бизнес-логику. Hex запрашивает витрины и отрисовывает дашборд.
Затраты труда на развертывание, если говорить прямо:
Этап
Ориентировочное время
Примечания
Инструментирование
Сильно варьируется
Полностью зависит от текущего состояния сайта. Сложнее всего поддается оценке.
Моделирование данных
~5–10 часов
Для специалиста, уверенно владеющего dbt и оконными функциями
Дашборд Hex
~1–2 часа
В основном асинхронно; ИИ-агент Hex строит графики, пока вы занимаетесь чем-то другим.
Шаг 1: Инструментирование
Все в этом стеке работает на пяти типах событий. Сессии, показатель отказов, время на странице, соотношение новых и вернувшихся пользователей, атрибуция каналов и отслеживание конверсий — все это выводится из этих пяти вызовов. Никаких пользовательских событий глубины прокрутки, никаких пингов вовлеченности, никакого инструментирования кликов не требуется.
События
Вызовы RudderStack
Обеспечивает
Загрузка страницы
page()
Трафик, сессии, топ страниц, каналы
Отправка формы
track('form_submitted')
Конверсии
Identify
identify()
Связывание анонимных пользователей с известными
Встреча начата
track('meeting_started')
Воронка, конверсия
Встреча забронирована
rack('meeting_booked')
Основная конверсия, пайплайн
Последние два события специфичны для процесса продаж в B2B с потоком самостоятельного планирования демо. Замените их своими собственными событиями конверсии (order_completed, subscription_started, trial_activated) везде, где применяется логика воронки. Шаблоны моделирования на последующих шагах идентичны независимо от имени события.
Одно правило важнее всего остального на этом уровне:
При первой загрузке страницы захватите UTM-параметры и реферер в файл cookie первой стороны браузера и прикрепите их к каждому последующему событию в этой сессии.
Без этого отправка формы посетителей, которые пришли из рекламы Google, просмотрели три страницы, а затем отправили форму, будет приписана последней просмотренной ими странице, а не рекламе, которая их привела. Атрибуция будет молчаливо искажена, и исправить ее постфактум невозможно. Установите cookie один раз при входе и считывайте его при каждом последующем событии. Это единственная строка кода инструментирования с наибольшим рычагом влияния во всей сборке, и она должна выполняться в настройке SDK, а не в SQL.
Одна функция разрешения идентификации встроена в сам SDK RudderStack: анонимная активность автоматически связывается с известной активностью в момент идентификации пользователя, без дополнительной настройки. Для многих сайтов этого достаточно. Пробел возникает, когда в разных системах задействовано более одного SDK. Каждый SDK разрешает идентификацию в рамках собственной области видимости и не имеет представления о том, что отслеживают другие SDK, что означает, что полный путь пользователя может оставаться изолированным даже после срабатывания индивидуальных событий идентификации. RudderStack Profiles закрывает этот пробел на уровне хранилища данных, подхватывая эстафету там, где отдельные SDK останавливаются, и завершая граф идентификации по всем источникам. Затем dbt получает эти разрешенные данные в качестве входных данных, что и обеспечивает точность представлений о пути человека и влиянии на пайплайн.
Одно недооцененное преимущество сбора данных на уровне хранилища заключается в том, что история сырых событий остается исправимой. Когда настройки инструментирования меняются (переименованное свойство, процесс регистрации, который разделяется на две части, форма, которая переезжает от стороннего провайдера к нативному элементу), модель dbt согласовывает старое и новое и сохраняет всю историю в целости. Готовый инструмент агрегирует данные при их приеме, поэтому прошлое оказывается заблокированным в тот момент, когда данные поступают. Хранилище сохраняет каждое сырое событие, благодаря чему прошлые ошибки инструментирования становятся данными для моделирования, а не исчезают навсегда.
Шаг 2: Моделирование данных
Работа по моделированию — это то, что GA4 делал невидимо для вас. Границы сессий, группировка каналов, фильтрация ботов, география, показатель отказов, время на странице и соотношение новых и вернувшихся пользователей — все это настройки по умолчанию в GA4. В хранилище данных это SQL-модели, которые кто-то должен написать, поддерживать и защищать. Эта передача ответственности является основным компромиссом. Приведенные ниже шаблоны охватывают все эти аспекты, хотя их точность зависит от одного предварительного условия: разрешения идентификации. dbt может справиться с разрешением идентификации, но сложность значительно варьируется в зависимости от ситуации. RudderStack Profiles решает эту задачу, а dbt затем выполняет моделирование поверх разрешенных данных.
Уровень 1: Объединение (Union) и группировка каналов
Реальные сайты обычно имеют более одного потока событий. Полная реализация может объединять просмотры страниц маркетингового сайта, отправки форм на сайте, отправки вебхуков от стороннего сервиса форм, вызовы identify и идентификаторы на стороне приложения, используемые для кросс-доменного объединения. На выходе получается одна плоская таблица, по одной строке на каждое веб-событие, с согласованной схемой: 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 года и последующего периода, которую большинство унаследованных логик каналов не учитывают.
В продакшене классификация каналов работает как seed-файл CSV (столбцы: pattern_type, pattern_value, channel, priority), а не как 130-строчная конструкция CASE. Маркетолог может добавить строку, когда появляется новый AI-реферер. Именованные партнерские домены представлены явными строками. Приоритезация становится данными, которые можно проверить, а не потоком управления, который нужно изучать.
Уровень 2: Разрешение идентификации
Ретроспективное объединение email по anonymous_id: если любое событие для anonymous ID когда-либо содержит адрес электронной почты, этот email привязывается ко всем событиям данного anonymous ID, прошлым и будущим. При конфликте побеждает самый последний ненулевой email. Это позволяет в будущем найти конкретного человека и увидеть всю его историю просмотров до момента идентификации.
Помечайте anonymous ID, которые разрешаются в два или более разных email (is_multi_email_anon). Общие устройства, общие браузеры и киоски создают этот паттерн. Исключайте их из любого анализа, который связывает поведение с конкретным человеком, иначе история просмотров одного человека попадет в запись другого.
Для большинства случаев использования вызовы identify() в веб-потоке обеспечивают рабочую отправную точку: любой посетитель, который отправляет форму или регистрируется, объединяется при первом вызове identify. Но отдельные SDK видят только свою область действия и не могут объединить полный граф пользователя между системами. RudderStack Profiles — это комплексное решение: оно собирает граф идентификации целостно по всем источникам, устраняя пробелы между SDK, которые оставляют отдельные вызовы identify(). В планах Enterprise Profiles материализует этот разрешенный граф в Snowflake, а модели dbt строятся поверх него. Путь клиента и влияние на воронку продаж становятся полностью точными только тогда, когда идентификация разрешена на этом уровне.
Уровень 3: Сессионизация
Сессия заканчивается после 30 минут бездействия — это та же граница, которую использует GA4, что делает количество сессий напрямую сопоставимым в период параллельной работы. Сессионизация настолько точна, насколько точны ID, поступающие в неё; RudderStack Profiles гарантирует, что эти ID полностью разрешены до запуска этого уровня.
Реализация: используйте lag() для событий каждого anonymous ID, отсортированных по временной метке, помечайте любой разрыв более чем в 1800 секунд как начало новой сессии, выполняйте кумулятивную сумму этих меток для получения порядкового номера сессии и объединяйте его с anonymous ID для создания ключа сессии. Сессионизируйте каждый тип события, а не только просмотры страниц. Отправка формы, следующая за последним просмотром страницы, должна привязываться к правильной сессии, а не начинать новую.
Создавайте модель сессионизации как полную пересборку таблицы, а не инкрементально. Оконные функции требуют полной истории событий каждого anonymous 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. Назовите метрику «Среднее время на странице (измеренные просмотры)» в дашборде, чтобы читатели понимали, что это нижний предел, а не верхний.
Новые против вернувшихся: производная от порядкового номера сессии для каждого anonymous ID. Учитываются только сессии с просмотром страниц; сессии только внутри приложения, не содержащие маркетинговых просмотров страниц, не должны инициировать флаг вернувшегося пользователя.
Фильтрация ботов: явная модель, сочетающая сопоставление user-agent и поведенческие эвристики. Отфильтрованные боты исключаются из витрины трафика, чтобы каждый последующий показатель конверсии имел чистый знаменатель. Боты помечаются, но не удаляются из сырых данных, поэтому логика фильтрации остается проверяемой.
География: определяется по IP через справочную таблицу с явным значением-заглушкой для ненайденных IP, чтобы они никогда не отображались как реальная страна на географических картах.
Группировка каналов использует первое касание каждой сессии и создает стабильную, пригодную для повторного использования метку. SQL ниже показывает рабочую реализацию, где AI Referral расположен перед Direct — это проектное решение, которое сохраняет видимость трафика из AI-источников:
Уровень 5: Витрины данных
Слой витрин — это то, к чему обращаются запросы Hex. Здесь нет никакой бизнес-логики, только готовые для отчетов таблицы, каждая из которых сформирована под определенную часть дашборда. Когда появляется новый потребитель (задание Reverse ETL, другой BI-инструмент, экспорт данных), вы добавляете витрину, а не разветвляете запрос.
Витрина
Детализация (Grain)
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 и устройство назначаются один раз по первому касанию.
Инкрементальность
Полная пересборка таблицы. Оконным функциям требуется полная история 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, подсчет просмотров страниц сверяется между промежуточными таблицами и таблицами событий, а также тест цепочки пользователя, который выбирает одного идентифицированного пользователя и проверяет, что количество строк его пути и последовательность совпадают с «сырыми» событиями.
Шаг 4: Создание дашборда Hex
Создание дашборда следует агентскому рабочему процессу из пяти шагов. Этот процесс применим к любому BI-инструменту с возможностями генеративного ИИ, хотя встроенный ИИ-агент Hex делает этап создания графиков необычайно быстрым.
Первое: зафиксируйте беседу с требованиями с маркетинговой командой. Спросите, на что они действительно смотрят, а не на то, что, по их мнению, им нужно. Стенограммы надежнее заметок для выявления отчетов, которые люди используют ежедневно и никогда не додумываются упомянуть.
Второе: пройдитесь по готовым аналогам — в данном случае по набору отчетов по умолчанию в GA4 — специально чтобы обнаружить отчеты, которые люди воспринимают как должное и о которых никогда бы не догадались попросить. Показатель отказов по целевой странице, разбивки на новых и вернувшихся, время на странице: ничего из этого не упоминается в беседе о требованиях, потому что все предполагают, что это будет существовать.
Третье: объедините запросы стейкхолдеров и готовые аналоги в приоритетный список отчетов, а затем двигайтесь в обратном направлении: учитывая уже созданные промежуточные модели, какая детализация витрины нужна для этих отчетов?
Четвертое: спланируйте работу с ИИ-агентом: сопоставьте промежуточные модели с необходимыми витринами и структурой дашборда. Затем передайте этот план ИИ-агенту Hex с конкретными инструкциями по таблицам и столбцам и позвольте ему построить интерфейс графиков. Агент отлично справляется с созданием графиков, когда вы точно указываете, какую таблицу витрины и какие столбцы использовать; ваша задача — обеспечить эту точность, а не определять семантические определения, которые уже зафиксированы в плане.
Пятое: замкните цикл. Экспортируйте готовый дашборд обратно в агент планирования и попросите его перепроверить каждую визуализацию на соответствие моделям данных, подтверждая, что каждый график считывает нужную таблицу и столбец и агрегирует данные так, как ожидает модель. Это быстрая автоматическая проверка всего приложения.
Полученный дашборд состоит из семи вкладок: Overview (Обзор), Acquisition (Привлечение), Audience (Аудитория), Behavior (Поведение), Conversions (Конверсии), Pipeline Influence (Влияние на воронку) и Email Journey Lookup (Поиск пути по email). Первые шесть опубликованы как единое приложение. Седьмое, отображающее адреса электронной почты и полную историю просмотров, представляет собой отдельно опубликованное приложение с явными и осознанными настройками разрешений.
Пять деталей реализации, которые рабочая версия делает правильно:
Взвешенные по сессиям свертки: свертка ежедневного bounce_rate до недели или месяца требует вычисления sum(sessions * bounce_rate) / sum(sessions), а не avg(bounce_rate). День с 3000 сессиями должен учитываться весомее, чем день с 3 сессиями. Тот же паттерн применяется к avg_session_duration_sec. Простое усреднение ежедневных средних дает неверные агрегированные значения.
Раздельные названия показателей отказов: показатель отказов на уровне сессии и показатель отказов на целевой странице — это разные расчеты с разными знаменателями. Оба присутствуют на дашборде под названиями «Session bounce rate» и «Landing-page bounce rate» соответственно. График, на котором написано просто «bounce rate» без уточнений, является неоднозначным между этими двумя числами.
Видимость текущего незавершенного периода: трендовые графики включают текущую неделю. Маркетологам нужны дашборды посреди недели, и им необходимо видеть неделю на текущий момент, даже если она еще не завершена.
Ограничение по порогу соотношений: график отказов по целевой странице использует условие having entrances >= 25 для подавления шума от единичных заходов. Страница с двумя заходами не должна доминировать в сортировке по показателю отказов в 100%.
Вкладка с PII изолирована отдельно: web_person_journey содержит person_email в паре с полными путями страниц, временем сессий и событиями конверсий. Она публикуется как отдельное приложение Hex с более строгим контролем доступа, а не как вкладка на общекорпоративном дашборде.
Запрос для скоринговой карточки на вкладке 1 иллюстрирует паттерн взвешивания по сессиям, который должен применяться последовательно везде, где вы сворачиваете столбцы ежедневных пропорций:
Отчет, который не может дать GA4: влияние на воронку (Pipeline influence)
Влияние на воронку — это не атрибуция.
Возможность, с которой взаимодействовали N страниц, вносит свой полный денежный эквивалент в N строк таблицы. Эти строки не суммируются в общую воронку. Эта метрика отвечает на вопрос, какие страницы и каналы появляются на пути к воронке; она ранжирует их по воронке, с которой они соприкасаются, но не распределяет заслуги. Всегда представляйте показатели влияния на воронку в виде ранжирования, но никогда — в виде суммы.
Определение: страница повлияла на возможность, когда кто-то из аккаунта этой возможности просмотрел страницу более 20 секунд до создания возможности. Порог в 20 секунд отфильтровывает случайные загрузки страниц и фокусирует метрику на посещениях с подлинной вовлеченностью. Все временные метки просмотров страниц и возможностей сравниваются в едином часовом поясе (UTC), что гарантирует захват просмотров страниц в часы, непосредственно предшествующие созданию возможности, а не только тех, что были за несколько дней до этого.
Представление влияния воронки по умолчанию настроено на «Новый бизнес». Контакты существующих клиентов активно просматривают документацию, поэтому воронка продлений существенно искажает отчёт при смешивании с новым бизнесом. Измерение record_type содержит «Новый бизнес» и «Продление» в качестве отдельных значений; всегда указывайте, какое из них вы читаете.
Примерно 40% возможностей в этой продакшн-сборке имеют хотя бы один подходящий просмотр страницы до ее создания. Оставшиеся 60% просто не просматривали маркетинговый сайт в течение этого окна. Сам показатель покрытия является полезным индикатором воронки: он показывает, какая часть воронки нового бизнеса была видна на веб-сайте до ее создания.
Поиск по цепочке писем — это вторая половина данного раздела и представление, вызвавшее самую сильную реакцию на сессии, где рассматривалась эта сборка. Введите любой адрес электронной почты в параметр Hex, и март возвращает полную хронологическую историю этого человека: каждую посещенную страницу по порядку, канал, который его привлек, время, проведенное на каждой странице, любые конверсии и кампании, привязанные к каждой сессии. Это структурно невозможно в GA4 на любом уровне; это требует соединения поведенческих данных с данными CRM на индивидуальном уровне, в той же системе, по живому запросу. Запрос, стоящий за этим:
Рассматривайте web_person_journey как идентифицируемые персональные данные (PII). Март содержит person_email в паре с полными путями страниц, временем сессий и событиями конверсии. Опубликуйте поиск по электронной почте как отдельное приложение Hex с явными, продуманными разрешениями. Не добавляйте его в качестве вкладки на общекомпанийский дашборд без осознанного решения по контролю доступа.
Где применим RudderStack
RudderStack — это агентский CDP. В этом стеке он обрабатывает сбор, идентификацию и маршрутизацию — три слоя, которые находятся выше каждой таблицы марта, описанной в этой статье.
JavaScript SDK инструментирует пять событий и сохраняет каждое сырое событие page, track, identify и conversion в Snowflake в виде строки, доступной для запросов. Тот же поток событий расходится по GA4, рекламным платформам и любым другим назначениям без повторного инструментирования сайта. Назначения добавляются или заменяются без изменения кода приложения.
Profiles управляет слоем разрешения идентификации, объединяя анонимные сессии маркетингового сайта с идентифицированными пользователями продукта из разных источников. Это соединение делает представление пути пользователя полным для пользователей, которые идентифицировали себя в приложении продукта, но никогда не отправляли форму на маркетинговом сайте. Для всех остальных планов вызовы identify() в веб-потоке покрывают большинство реальных случаев идентификации.
Одно практическое примечание о миграции: сохранение назначения GA4 активным ничего не стоит. Поток событий отправляется в Snowflake и GA4 одновременно. Отдел маркетинга сохраняет привычный интерфейс для быстрых проверок кампаний, отчетов по частоте и всего, что не требует соединения с CRM. Оба назначения работают параллельно неопределенно долго.
Компромиссы, о которых следует знать до начала
Эти пять пунктов надежно всплывают на второй месяц проектов, которые не обсудили их в первый месяц.
Вы перестраиваете то, что GA4 давал вам бесплатно. Сессионизация, группировка каналов, фильтрация ботов, география, показатель отказов, новые и возвращающиеся пользователи, а также время на странице — все это настройки по умолчанию в GA4, которые становятся SQL-моделями в момент ухода из инструмента. Шаблоны в этой статье охватывают все из них, а репозиторий с открытым исходным кодом поставляет работающие версии. Но ответственность переходит к вашей команде; кто-то должен поддерживать, обновлять и отстаивать эти определения по мере развития бизнеса.
Кто-то должен отвечать за семантический слой. Первое разногласие в любом проекте аналитики на базе хранилища — «что такое сессия» или «что считать активным». GA4 принимал это решение невидимо. Теперь маркетинг, продукт и финансы должны прийти к явному, задокументированному соглашению до запуска дашбордов, иначе каждая команда будет запускать свой собственный SQL, и цифры никогда не сойдутся. Заложите время на это согласование до начала разработки, а не после.
