Как заменить Google Analytics с помощью RudderStack, Snowflake, dbt и Hex

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')

Воронка, конверсия

Встреча забронирована

rack('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: Объединение и группировка каналов

Реальные сайты обычно имеют более одного потока событий. Полноценная реализация может объединять просмотры страниц маркетингового сайта, отправки форм на сайте, вебхук-отправки от встроенного провайдера форм, вызовы 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), а не как CASE-выражение на 130 строк. Маркетолог может добавить строку, когда появляется новый 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-модели строятся поверх него. Представления пути пользователя и влияния на воронку полностью точны только тогда, когда идентичность разрешена на этом уровне.

Слой 3: Сессионизация

Сессия заканчивается после 30 минут бездействия — та же граница, которую использует GA4, что делает количество сессий напрямую сопоставимым в период параллельной работы. Сессионизация настолько точна, насколько точны ID, поступающие в неё; RudderStack Profiles гарантирует, что эти ID полностью разрешены до запуска этого слоя.

Реализация: lag() по событиям каждого анонимного ID, упорядоченным по времени, пометить любой разрыв более 1 800 секунд как начало новой сессии, выполнить кумулятивную сумму этих флагов для получения порядкового номера сессии и объединить с анонимным ID для создания ключа сессии. Сессионизируйте каждый тип событий, а не только просмотры страниц. Отправка формы, следующая за последним просмотром страницы, должна прикрепляться к правильной сессии, а не начинать новую.

Стройте модель сессионизации как полную пересборку таблицы, а не инкрементальную. Оконные функции требуют полной истории событий каждого анонимного ID, чтобы расставить границы сессий и вычислить время на странице через границы дней. Наивная инкрементальная модель по event_date неправильно разделяет сессии, пересекающие полночь: граница сессии вечером становится отдельной сессией следующим утром, и количество сессий завышается. При масштабе потока событий маркетингового сайта полная пересборка таблицы выполняется быстро.

Примечание: этот пример иллюстрирует паттерн. В репозитории сессионизация читает из int_web_events_identified, поэтому каждое событие уже содержит разрешённый person_email из веб-вызовов identify и, опционально, граф идентичности RudderStack Profiles. Границы сессий по-прежнему вычисляются для каждого anonymous_id; разрешение идентичности не меняет количество сессий или канал первого касания. Оно определяет, какому человеку принадлежит сессия, — от этого зависят витрины пути пользователя и влияния на воронку.

Слой 4: Метрики, которые GA4 давал вам бесплатно

Каждая из стандартных метрик GA4 — это решение, когда вы владеете моделью. Вот как продакшен-сборка определяет каждую из них.

Показатель отказов: сессия с одним просмотром страницы, которая не совершила конверсию. Одностраничная сессия, завершающаяся отправкой формы, считается вовлечённой, а не отказом, поэтому высококонверсионные посадочные страницы отображаются корректно. В слое витрин есть два различных расчёта показателя отказов, и их нужно помечать отдельно: показатель отказов сессий, определяемый как число отказовых сессий, делённое на общее число сессий, и показатель отказов посадочных страниц, определяемый как число отказов на входных страницах, делённое на число входов. Эти два числа сходятся только на общесайтовом итоге, а не по каналам, устройствам или срезам страниц. Их смешение даёт непримиримые цифры в дашбордах.

Время на странице: интервал до следующего события в той же сессии, ограниченный 30 минутами. Значения выше этого порога устанавливаются в null, а не считаются вовлечённостью из-за бездействующих вкладок. Последний просмотр страницы в любой сессии не имеет следующего события и также равен null. Назовите метрику «Avg time on page (measured views)» в дашборде, чтобы читатели понимали, что это нижняя граница, а не верхняя.

Новые и вернувшиеся: вычисляется из порядкового номера сессии для каждого анонимного ID. Учитываются только сессии с просмотрами страниц; сессии только в приложении, не содержащие маркетинговых просмотров страниц, не должны задавать флаг возврата.

Фильтрация ботов: явная модель, сочетающая сопоставление user-agent и поведенческие эвристики. Отфильтрованные боты исключаются из витрины трафика, поэтому у каждого последующего показателя конверсии чистый знаменатель. Боты помечаются, но не удаляются из сырых данных, поэтому логика фильтра остаётся проверяемой.

География: определяется по IP через справочную таблицу, с явным sentinel-значением для несопоставленных IP, чтобы они никогда не отображались как реальная страна в географических графиках.

Группировка каналов использует первое касание каждой сессии и создаёт стабильную, переиспользуемую метку. SQL ниже показывает рабочую реализацию, где AI Referral расположен перед Direct, — проектное решение, которое сохраняет видимость трафика из AI:

Слой 5: Витрины данных

Слой витрин — это то, что запрашивает 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 и устройство назначаются один раз по первому касанию.

Инкрементальность

Полная перестройка таблицы. Оконные функции требуют полной истории anonymous_id. Инкрементальная модель по event_date неправильно разбивает сеансы на границах дней.

Отказ

Сеанс с одним просмотром страницы, который не привел к конверсии.

Время на странице

Дельта до следующего события в рамках сеанса. Последний просмотр страницы: null. Значения выше 30 минут: null.

Показатель выходов

Для каждой страницы: процент просмотров этой страницы, которые были последними в своем сеансе.

Новые против вернувшихся

Отметка времени первого события для каждого anonymous_id. Только сеансы с просмотрами страниц.

Устройство

Извлекается из context_user_agent. Порядок важен: планшет перед мобильным; Chrome и Firefox на iOS перед Safari; iOS перед macOS.

Боты

Помечаются и исключаются из витрины трафика. Из сырых данных не удаляются.

Схемные тесты выполняются в CI: уникальность session_id, not_null для всех внешних ключей, поля показателей ограничены от 0 до 1, количество просмотров страниц сверяется между промежуточными таблицами и таблицами событий, а также тест пути пользователя, который выбирает одного идентифицированного человека и проверяет, что количество строк и последовательность его пути совпадают с сырыми событиями.

Шаг 4: Создание дашборда в Hex

Создание дашборда следует пятишаговому агентному процессу. Этот процесс применим к любому BI-инструменту с возможностью ИИ-авторинга, хотя встроенный ИИ-агент Hex делает шаг построения графиков необычайно быстрым.

Первое: запишите разговор о требованиях с маркетинговой командой. Спрашивайте, на что они реально смотрят, а не что, по их мнению, им нужно. Расшифровки надежнее заметок для выявления отчетов, которые люди используют ежедневно и никогда не думают упомянуть.

Второе: изучите стандартные аналоги, в данном случае набор отчетов GA4 по умолчанию, специально чтобы выявить отчеты, которые люди воспринимают как должное и никогда не догадаются запросить. Показатель отказов по целевым страницам, разбивка новых и вернувшихся, время на странице: ни одно из этого не упоминается в разговоре о требованиях, потому что все предполагают, что это будет.

Третье: объедините запросы заинтересованных сторон и стандартные аналоги в приоритизированный список отчетов, затем двигайтесь в обратном направлении: учитывая уже созданные промежуточные модели, какая гранулярность витрин нужна этим отчетам?

Четвертое: спланируйте с ИИ-агентом: сопоставьте промежуточные модели с требуемыми витринами и структурой дашборда. Затем передайте этот план ИИ-агенту Hex с конкретными инструкциями по таблицам и колонкам и позвольте ему построить UI графиков. Агент хорошо строит графики, когда вы точны в том, какую таблицу витрины и колонки использовать; ваша задача — обеспечить эту точность, а не определять семантические определения, которые уже зафиксированы в плане.

Пятое: замкните цикл. Экспортируйте готовый дашборд обратно в планирующего агента и попросите его перепроверить каждую визуализацию на соответствие моделям данных, подтверждая, что каждый график читает предназначенную таблицу и колонку и агрегирует так, как ожидает модель. Это быстрая автоматическая проверка всего приложения.

Итоговый дашборд содержит семь вкладок: 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» соответственно. График с подписью «bounce rate» без уточнения неоднозначен между этими двумя числами.

Текущий незавершенный период виден: графики трендов включают текущую неделю. Маркетологи проверяют дашборды в середине недели, и им нужно видеть неделю на текущий момент, даже если она не завершена.

Порог для показателей: график отказов по целевым страницам использует условие entrances >= 25, чтобы подавить шум единичных визитов. Страница с двумя входами не должна доминировать в сортировке при показателе отказов 100%.

Вкладка PII отделена: web_person_journey содержит person_email в паре с полными путями страниц, временем сеансов и событиями конверсий. Она публикуется как отдельное приложение Hex с более строгим контролем доступа, а не как вкладка в общедоступном дашборде компании.

Запрос для карточки показателей на вкладке 1 иллюстрирует принцип взвешивания по сеансам, который необходимо последовательно применять везде, где вы свертываете ежедневные столбцы с показателями:

Отчет, который GA4 не может вам дать: Pipeline influence

Pipeline influence — это не атрибуция.

Сделка, затронутая N страницами, вносит свою полную сумму в долларах в N строк таблицы. Эти строки не суммируются в общий pipeline. Метрика отвечает на вопрос, какие страницы и каналы появляются на пути к pipeline; она ранжирует их по объему pipeline, которого они касаются; она не распределяет кредит. Всегда представляйте показатели pipeline influence как рейтинг, а не как сумму.

Определение: страница повлияла на сделку, если кто-то из аккаунта этой сделки просмотрел страницу более 20 секунд до создания сделки. Порог в 20 секунд отсеивает случайные загрузки страниц и фокусирует метрику на посещениях с реальным вовлечением. Все временные метки просмотров страниц и сделок сравниваются в едином часовом поясе (UTC), что гарантирует учет просмотров за несколько часов до создания сделки, а не только за несколько дней.

Представление влияния на воронку по умолчанию настроено на New Business. Контакты существующих клиентов активно просматривают документацию, поэтому при смешивании с новым бизнесом воронка продлений существенно искажает отчёт. Измерение record_type содержит New Business и Renewal как отдельные значения; всегда указывайте, какое из них вы просматриваете.

Примерно 40% сделок в этой production-сборке имеют хотя бы один подходящий просмотр страницы до создания сделки. Остальные 60% просто не просматривали маркетинговый сайт в этом окне. Сам показатель покрытия полезен для анализа воронки: он показывает, какая часть воронки нового бизнеса была видима в вебе до её создания.

Поиск по email-путешествию — вторая половина этого раздела и представление, вызвавшее самую сильную реакцию на сессии, где рассматривалась эта сборка. Введите любой адрес электронной почты в параметр Hex, и витрина данных вернёт полный хронологический путь этого человека: каждую посещённую страницу по порядку, канал, который его привёл, время, проведённое на каждой странице, все конверсии и кампании, привязанные к каждой сессии. Это структурно невозможно в GA4 на любом тарифе; для этого требуется объединение поведенческих данных с данными CRM на уровне отдельного человека, в одной системе, в живом запросе. Запрос, стоящий за ним:

Относитесь к web_person_journey как к идентифицированным персональным данным (PII). Витрина данных содержит person_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, и цифры никогда не сойдутся. Закладывайте время на это согласование до начала сборки, а не после.

Резюме