X5 Group: как BigQuery снизил отток покупателей на 12% без скидочных войн

В 2025–2026 годах средний чек в e-commerce и ритейле продолжает сжиматься — минус 5-8% год к году. Потребители экономят, уходят в дискаунтеры или просто покупают реже. В такой ситуации классический фокус на привлечение «нового лица» даёт отрицательную юнит-экономику: стоимость привлечения (CAC) растёт, а пожизненная ценность (CLV) не успевает окупить его. X5 Group (сети «Пятёрочка», «Перекрёсток», «Чижик») решили пересобрать удержание покупателей на основе данных в BigQuery — без агрессивных скидок и массовых рассылок, которые только добивают маржинальность.

**Задача.** Сети X5 имеют десятки миллионов активных карт лояльности в день. Однако классический RFM-анализ, построенный на витринах транзакций, не давал точности: он не учитывал поведенческие паттерны «тихого ухода» — когда покупатель снижает частоту, но ещё не ушёл полностью. Отток в группах с частотой 2-3 раза в месяц достигал 18% в квартал. Требовалось с помощью BigQuery построить прогнозную модель ухода за 2 недели до фактического оттока и запустить триггерные коммуникации — точечные, а не «процент на всю базу».

**Решение.** Команда data-маркетинга развернула в BigQuery ML модель градиентного бустинга (XGBoost) на исторических данных за 24 месяца. Использовали не только витрину фактов продаж, но и событийные слои:
— динамика средней корзины (тренд за 4 недели против 12 недель);
— снижение доли категорий с высокой маржинальностью (СТМ, свежие продукты);
— время между визитами (увеличение интервала на 30%+ — сильный сигнал);
— поведение в приложении (открытие промо-акций, добавление

— @BigQuery4MarketingPro

**Кросс-доменное отслеживание в GA4: что делать после миграции с Universal Analytics**

— **Проверьте список доменов в интерфейсе GA4.** В разделе «Потоки данных» → «Настройки тега» → «Настройка доменов» добавьте все домены, между которыми ходит пользователь. Это заменяет ручную правку кода из эпохи Universal Analytics.

— **Сверьте условия в GTM (Google Tag Manager).** Убедитесь, что триггеры и переменные в контейнере не ссылаются на старые междоменные правила из Universal Analytics. Остаточные настройки ломают атрибуцию при переходе.

— **Передавайте `_linker` через декорирование ссылок.** Если в воронке есть переход на поддомен или внешний домен, который не учтён в списке выше, добавьте автоматическое декорирование ссылок через GTM или серверный тег.

— **Исключите редиректы и оплату из отслеживания.** Платёжные шлюзы и сторонние редиректы создают ложные межсессионные переходы. Настройте список исключений в GA4, иначе в отчётах по атрибуции появятся разрывы.

— **Свяжите потоки данных по Client ID.** В отчёте «Исследования» (Explorations) и в BigQuery экспорте убедитесь, что идентификатор клиента стабилен между доменами. Это база для сквозной аналитики воронки.

— **Сравните сессии до и после настройки.** Запустите отчёт по источникам трафика за 7 дней до и после включения кросс-домена. Падение числа сессий на 10-20% — сигнал, что дублирование ушло и атрибуция стала честнее.

— **Настройте server-side (серверный) GTM при сложной архитектуре.** Если доменов больше трёх или данные уходят в CDP (Customer Data Platform) — переносите тегирование на сервер. Это убирает зависимость от cookies и готовит стек к privacy-first атрибуции.

**Когда пригодится:** при миграции с Universal Analytics, запуске нового сайта с поддоменами или подключении интернет-магазина к маркетплейсу, когда в отчётах GA4 сессии делятся пополам, а воронка рвётся на этапе перехода.

— @BigQuery4MarketingPro

Как Lamoda связала данные из BigQuery с retention-механикой и отбила падение среднего чека

Контекст

К середине 2025 года Lamoda столкнулась с типичной для e-com картиной 2026-го: средний чек просел на 6-7%, новые покупатели стали реже возвращаться ко второй покупке, а привычная связка «первая покупка по промокоду → бросаем в ремаркетинг» перестала окупаться. При этом в базе бренда лежали терабайты сырых событий: клики, корзины, возвраты, обращения в поддержку, выходы в приложение, подборки, отзывы. Данные собирались в ClickStream, но лежали мёртвым грузом.

Задача

Найти сегменты пользователей, для которых персонализированная коммуникация реально поднимает повторные покупки, и отказаться от массовых рассылок, которые жгут базу и раздражают.

Решение

Команда аналитики собрала в BigQuery единую таблицу user_fact, куда стянулись данные из CRM, мобильного приложения, веб-сайта, программы лояльности и службы доставки. Дальше — по шагам.

— Собрали когорты по дате первой покупки и рассчитали RFM-сегменты (recency, frequency, monetary — давность, частота, средний чек). Сделали это в одном SQL-запросе с оконными функциями, без выгрузок в Python.

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

— На основе этих признаков построили uplift-модель (оценка прироста вероятности повторной покупки именно от коммуникации, а не от базового желания клиента). Здесь BigQuery использовался как хранилище фичей, а обучение шло в Vertex AI.

— Результат модели приземлили обратно в BigQuery и через Airflow раз в сутки обновляли сегменты в CDP (customer data platform — единое хранилище клиентских профилей).

— Коммуникации перестали быть «скидка 10% всем, кто молчит 30 дней». Появились сценарии: для «спящих модников» — подборка новых дропов, для «охотников за распродажами» — ранний доступ к акции, для «мам с детьми» — трехмесячный гайд по подбору размеров. Скидка ушла как основной оффер и стала точечным инструментом.

Результат

— Повторные покупки в целевой когорте выросли на 18% за два квартала.
— Доля пользователей, получавших хотя бы одну коммуникацию в неделю, снизилась с 62% до 34%, при этом выручка от email/пушей (push-уведомления) выросла на 11%.
— Стоимость привлечения повторной покупки упала на 23%, что особенно ценно на фоне общего снижения среднего чека.

Урок

Главный сдвиг произошел не в модели, а в подходе к коммуникации. Бренд перестал спрашивать «кому отправить письмо» и начал спрашивать «кому наше сообщение реально поможет купить». BigQuery здесь выступил не как хранилище ради отчётов, а как нервная система продукта: фичи уходят в модель, предсказания возвращаются в CDP, маркетинг работает по свежим сегментам каждый день. Для рынка, где первая покупка дешевеет, такая связка «данные — модель — коммуникация» становится не конкурентным преимуществом, а гигиеной.

— @BigQuery4MarketingPro

Матричная атрибуция в BigQuery без боли: как связать маркетинг, продажи и customer success в единую модель

Если в 2026-м вы всё ещё считаете результат по «последнему клику», то вы, скорее всего, меряете не продажи, а привычку пользователей к платформам аналитики. Дальше хуже: privacy-first ограничения и рост доли zero-click сценариев ломают точность микро-атрибуции, а бизнес ждёт не отчёт “сколько лидов”, а понимание вклада в выручку и удержание.

Хорошая новость: матричная атрибуция (модель распределения ценности по цепочке касаний) отлично ложится на BigQuery. Плюс она помогает встроить RevOps-подход: маркетинг, продажи и customer success (работа с клиентом) получают общую картину, а не спорят о том, кто “прав” в CRM-таблицах.

Ниже — как построить такую модель в BigQuery так, чтобы она была воспроизводимой, объяснимой и не превращалась в бесконечный проект.

Раздел 1. Сначала договоритесь о «событийной философии»: что считаем касанием, а что — конверсией

Тезис: матричная атрибуция держится не на алгоритме, а на согласованной схеме событий и времени.

Пример: в B2B часто встречаются разные определения:
— “лид создан” (маркетинг событие)
— “MQL подтверждён” (маркетинг-валидация)
— “SQL создан” (продажи)
— “первая сделка” и “подписанный договор” (выручка)
— “активация” и “здоровье аккаунта” (customer success)

Если вы в модели используете касания только на стороне рекламных платформ, но конверсию — в CRM, то неизбежны дырки по времени и каналам. В BigQuery лучше заранее зафиксировать таблицу касаний и таблицу ключевых исходов с единым ключом времени и пользователем/компанией.

Практика:
— Касания: на уровне пользователя или компании (что у вас “склеивается” лучше), с полями session_id или touch_id, timestamp, каналом, типом (реклама/контент/сайт/событие), источником идентификации.
— Исходы: на уровне lead/company/deal, с timestamp (момент ключевого этапа), revenue (если доступно) и стадией воронки.

В BigQuery это может выглядеть как два набора: `touch_events` и `conversion_events`. Важно: один и тот же стандарт времени (обычно UTC) и один и тот же “идентификатор цепочки” (например, `entity_id` = company_id для B2B). Тогда матрица не развалится на сверках.

Раздел 2. Соберите цепочки касаний: от “входного касания” до “момента ценности”

Тезис: матрица должна работать с цепочками, а не с разрозненными событиями — иначе вы получите красивые, но бессмысленные доли.

Пример: допустим, у вас есть вебинар (контент), после него человек читает кейс (SEO), затем дважды видит ретаргетинг (performance), а сделка подписывается через 45 дней. Если вы не построите цепочку, то алгоритм не поймёт, что эти касания относятся к одной “истории” и что маркетинг мог повлиять по нарастающему эффекту.

Как собрать цепочки в BigQuery:
— Выбираете “окно атрибуции” (например, 90 дней до конверсии — как правило, это разумная стартовая гипотеза, дальше уточняете данными).
— Для каждого исхода (`conversion_events`) находите касания того же entity_id в пределах окна.
— Упорядочиваете касания по времени и фиксируете “позицию касания” в цепочке (1-е, 2-е, …) или бинируете по сегментам (ранние/средние/поздние).

Технически полезная идея: делать не один гигантский join “touches к conversions”, а заранее строить “кандидатов касаний” и только потом — финальную матрицу. Это экономит деньги на запросах и повышает управляемость.

В результате вы получите датасет вида:
— `conversion_id`
— список touch_id и их атрибуты (канал/тип/позиция)
— флаг “канал-участник” (чтобы потом агрегировать по структурам)

Раздел 3. Постройте матрицу: простая объяснимая модель лучше сложной, которую никто не защитит

Тезис: в маркетинге выигрывают модели, которые можно объяснить бизнесу; матричная атрибуция — как раз про это.

Пример: “классическая” матрица часто распределяет ценность по касаниям в зависимости от позиции:
— часть ценности — первому касанию (знакомство/привлечение)
— часть — последнему касанию перед сделкой (перевод в действие)
— оставшееся — всем промежуточным (доверие, прогрев)
…

3 инструмента для сквозной аналитики звонков и сделок в BigQuery

Если у вас маркетинг завязан не только на заявки, но и на звонки, сделки и выручку, то в 2026 году уже мало смотреть на last-click. Для B2B, недвижимости и дорогих услуг важнее связать рекламу, телефонию и CRM в единую модель, а потом отдать данные в BigQuery — там удобно считать качество лидов, скорость обработки и вклад каналов в выручку. Ниже — три инструмента одного класса, но с разной силой.

Ringostat — для кого: компании, где звонок = ключевой этап воронки — сильная сторона: хорошо закрывает связку телефонии, CRM и аналитики, помогает видеть не только источник обращения, но и путь до сделки — слабая сторона: меньше подходит тем, у кого продажи почти полностью идут без звонков или через сложный self-service.

Calltouch — для кого: performance-команды, которым нужна атрибуция обращений и контроль окупаемости рекламы — сильная сторона: сильный набор для коллтрекинга, подмены номеров и передачи данных в аналитику, удобно для сравнения каналов по заявкам и звонкам — слабая сторона: при сложной воронке и нескольких системах продаж требует аккуратной настройки событий и статусов, иначе картина искажается.

Roistat — для кого: бизнесы, которым нужна более широкая сквозная аналитика от рекламы до денег — сильная сторона: хорошо смотрится, когда нужно собрать расходы, лиды, сделки и выручку в одном контуре и затем выгрузить это в BigQuery для своих срезов — слабая сторона: универсальность иногда превращается в перегруженность, а без дисциплины по CRM и UTM данные быстро теряют качество.

Как выбирать: если главный вопрос — «откуда пришёл звонок», смотрите на коллтрекинг; если «какой канал дал выручку», важнее сквозная аналитика; если же вы строите собственную модель в BigQuery, выбирайте инструмент по качеству интеграций, глубине статусов и чистоте выгрузки, а не по числу экранов в интерфейсе.

— @BigQuery4MarketingPro

UNSTRUCTURED-данные тянут в BigQuery раньше, чем чистят

Запросы клиентов в аналитику за последний месяц всё чаще звучат одинаково: «у нас уже льются сырые события в BigQuery, а нормализовать под маркетинг мы начнём потом». Имеются в виду данные из CRM, офлайн-заказы, логи колл-центра, выгрузки из POS-систем.

То есть стадия проектирования схемы под маркетинговые задачи фактически пропускается. Команды грузят таблицу «как есть», а затем тратят недели на то, чтобы привести колонки к единому виду, понять, что считать конверсией, и разобраться, какие поля вообще нужны для воронки.

Похоже, что дёшево залить сырьё в облачное хранилище стало проще, чем заранее договориться о структуре. На этапе «просто загрузим и посмотрим» останавливаться перестали — загружают сразу всё.

А у вас как: данные в BigQuery попадают уже в подготовленном виде, или сначала приходит сырьё, а нормализация начинается по факту первого запроса?

— @BigQuery4MarketingPro

BigQuery для performance-маркетинга: считаем инкрементность без last-click

Бренд: крупный B2B-сервис видеосвязи (NDA, сопоставимо с сегментом Zoom/Whereby).

Задача: performance-команда уперлась в потолок. Бюджеты на платный поиск растут, лидов больше не становится, CPO (стоимость привлечения) ползет вверх на 12-15% квартал к кварталу. Классическая last-click модель в Google Ads показывала источник «Google Search / brand», но выручки это не добавляло. Менеджмент потребовал разобраться, какие каналы реально работают, а какие просто перекладывают спрос.

Решение: команда перешла на privacy-first атрибуцию через BigQuery.

— Выгрузили в BigQuery сырые логи сайта, офлайн-конверсии из CRM и расходы по каналам через API рекламных платформ.
— Построили data lineage (происхождение данных): каждый лид получил идентификатор первого и последнего касания, путь по touchpoint'ам (точкам контакта) и факт сделки.
— Связали поведенческие сигналы (повторные визиты, скачивание гайдов, время на странице) с доходом через оконную функцию и марковские цепи (вероятностная модель атрибуции, которая оценивает вклад каждого касания в конверсию).
— Дополнительно запустили гео-тест: отключили платный поиск в двух похожих регионах на 4 недели, замерили разницу с контрольными регионами — это и есть incrementality lift (реальный прирост выручки от рекламы, а не перераспределение спроса).

Результат: last-click завышал долю brand-поиска на 38%. После пересчёта выяснилось, что реальный драйвер нового спроса — контент-маркетинг и органический поиск. Контекстная реклама давала инкремент только по узким коммерческим запросам, которых нашлось 12% от прежнего семантического ядра. Бюджет на остальные 88% перераспределили в SEO-кластер, наращивающий Topical Authority (экспертное покрытие темы) под AI-обзоры поисковиков. Через квартал MQL (маркетинг-квалифицированные лиды) выросли на 24% при том же общем бюджете.

Урок: в эпоху privacy-first атрибуции (server-side, MMM, incrementality) last-click врет все сильнее. BigQuery — дешёвая точка входа, чтобы собрать собственный data layer (слой данных о поведении пользователя) и не зависеть от чужих моделей атрибуции. Маркетолог, который видит реальный вклад каналов, а не отчёт рекламной платформы, иначе разговаривает с CFO (финансовым директором) про бюджет.

— @BigQuery4MarketingPro

BigQuery всё чаще нужен не «аналитику», а маркетингу

Раньше BigQuery в командах воспринимали как склад данных: туда складывают события, а потом кто-то умный разбирается. Сейчас он всё больше становится рабочим столом маркетолога. Когда классический last-click уже плохо объясняет выручку, а в B2B MQL и SQL теряют смысл без RevOps, важнее не отчёт, а единая логика данных. На мой взгляд, BigQuery постепенно превращается в язык согласования между маркетингом, продажами и продуктом.

— @BigQuery4MarketingPro

Атрибуция в эпоху приватности: строим модель на базе Marketing Mix Modeling в BigQuery

В условиях, когда браузеры и операционные системы ограничивают работу cookie-файлов, классическая модель атрибуции по последнему клику (last-click) теряет точность. В 2026 году маркетологам важно переходить к моделированию маркетингового микса (MMM), которое позволяет оценивать вклад каналов в выручку на основе исторических данных, а не персональных трекеров.

Реализуем базовый расчет в BigQuery по шагам:

— Сбор данных. Загрузите в BigQuery таблицу, где каждая строка — это день, а столбцы содержат сумму расходов по каждому каналу (контекст, медийка, блогеры) и итоговую выручку (Revenue). Важно использовать server-side (серверную) передачу данных, чтобы исключить потери из-за блокировщиков рекламы.

— Подготовка признаков. Разверните данные во времени. Для учета эффекта «отложенного спроса» создайте дополнительные колонки с лагами (сдвигом) по каждому каналу на 1–7 дней. Это покажет, как инвестиции вчера влияют на продажи сегодня.

— Регрессионный анализ. Используйте встроенную функцию `ML.LINEAR_REG` для обучения модели. В качестве целевой переменной укажите `revenue`, а в качестве признаков — расходы по каналам с учетом лагов.

— Интерпретация коэффициентов. После выполнения запроса посмотрите на веса (weights) каждого канала. Коэффициент при переменной расхода показывает, насколько увеличится выручка при росте инвестиций в этот канал на единицу.

Пример SQL-запроса для обучения:

CREATE OR REPLACE MODEL `dataset.mmm_model`
OPTIONS(model_type='linear_reg', input_label_cols=['revenue']) AS
SELECT * EXCEPT(date) FROM `dataset.marketing_data`;

— Расчет инкрементальности. Чтобы проверить эффективность канала, сравните предсказанную выручку модели с фактической в периоды, когда вы отключали или снижали бюджет на конкретный источник. Если модель верно предсказывает просадку — вы получили базу для оценки чистого вклада канала в RevOps (процесс управления выручкой).

Этот подход позволит уйти от слепой веры в отчеты рекламных кабинетов и выстроить стратегию на основе данных, которые не зависят от прихотей браузеров. *Главная ценность — переход от оценки клика к оценке влияния инвестиций на бизнес-результат.*

— @BigQuery4MarketingPro

BigQuery — это не про «большие данные», а про скорость маркетинговых решений

Я всё чаще вижу одну и ту же ошибку: BigQuery в маркетинге воспринимают как склад таблиц. Мол, выгрузили рекламу, CRM, веб-аналитику — и на этом проект «с аналитикой» завершён. Но ценность начинается не в хранении, а в том, **как быстро команда превращает данные в действие**.

В 2026-м это особенно заметно. Last-click атрибуция слабеет, privacy-first модели требуют более сложной сборки, а маркетинг всё чаще отвечает не за лиды, а за выручку вместе с продажами и customer success. В такой среде побеждает не тот, у кого «есть данные», а тот, у кого данные связаны в одну логику и доступны без очереди к аналитикам.

Из практики: после того как мы собрали в BigQuery сквозную модель по каналам, CRM и событиям сайта, среднее время ответа на вопрос «что случилось с сегментом и почему просел ROMI?» сократилось примерно с 2–3 дней до 20–30 минут. Не потому что магия SQL. А потому что исчезла ручная сборка отчётов, и команда начала смотреть на одни и те же метрики в одной версии правды.

Мой вывод простой:

— BigQuery полезен не тогда, когда в нём «много данных», а когда в нём есть **единая маркетинговая логика**.
— Если отчёт нельзя обновить быстро, он не управляет решением.
— Если сегменты, события и выручка живут отдельно, вы анализируете не бизнес, а фрагменты бизнеса.

Для маркетинга BigQuery — это не IT-актив и не модный стек. Это способ сделать аналитику рабочей: от гипотезы до решения, без лишних слоёв между ними.

— @BigQuery4MarketingPro

Почему я не строю маркетинговые отчёты вокруг last-click

Я всё чаще вижу одну и ту же ошибку: маркетинг в 2026 году продолжает отчитываться по модели, которая лучше всего подходит не для принятия решений, а для самоуспокоения. Last-click удобно считать, легко объяснить руководству и почти всегда можно быстро свести в таблицу. Но именно поэтому он опасен: он системно переоценивает нижнюю часть воронки и обесценивает каналы, которые создают спрос заранее.

В моей практике это особенно заметно на связках, где есть контент, бренд и платный спрос. Если смотреть только на финальный клик, то SEO, статьи, видео, PR и даже часть ретаргетинга выглядят как «слабые» каналы. А потом оказывается, что без них падает конверсия в платном трафике, растёт стоимость заявки и сужается пул качественных лидов. То есть канал не «не сработал» — он просто работал раньше, чем его умеет видеть last-click.

Поэтому я всё чаще строю аналитику вокруг трёх вопросов:
— что создаёт первичный спрос;
— что помогает дожать решение;
— что реально приносит выручку, а не только лиды.

В BigQuery это хорошо раскладывается по событиям и когортам. Я смотрю не на один путь пользователя, а на вклад канала в цепочку: первое касание, повторные визиты, возвраты, конверсии через 7/14/30 дней, влияние на LTV. Иногда достаточно одного наблюдения, чтобы поменять модель управления: в одном B2B-проекте при переходе от last-click к когортному разбору оказалось, что контент и органика почти не дают «последних» конверсий, но формируют больше 40% всех сделок, если считать полный путь до оплаты.

Мой вывод простой: **если маркетинг не умеет считать вклад в выручку, а не только в последний клик, он неизбежно будет оптимизировать не рост, а видимость роста**.

BigQuery здесь полезен не как «ещё один инструмент отчётности», а как место, где можно собрать честную картину по всей воронке и перестать спорить с маркетингом на уровне ощущений.

— @BigQuery4MarketingPro

Отладка Server-side GTM: пошаговый контроль потоков данных

В эпоху privacy-first (приоритета конфиденциальности) атрибуции, когда данные проходят через серверный контейнер Google Tag Manager, важно убедиться, что события передаются корректно до того, как они попадут в BigQuery. Используйте режим предварительного просмотра для диагностики.

— Запустите режим отладки. Нажмите кнопку Preview (предварительный просмотр) в интерфейсе серверного контейнера, чтобы открыть вкладку мониторинга.
— Синхронизируйте сессию браузера. Откройте ваш сайт в том же окне, где запущен отладчик, чтобы сервер «увидел» запросы именно от вашего экземпляра браузера.
— Изучите структуру входящего запроса. Проверьте во вкладке Incoming Requests (входящие запросы), какие параметры передает ваш клиент (например, Google Analytics 4 или Facebook CAPI) до их обработки.
— Проанализируйте объект данных. Откройте Event Data (данные события), чтобы убедиться, что все переменные (ID транзакции, сумма покупки, параметры пользователя) распознаны системой.
— Проверьте исходящие запросы. Перейдите во вкладку Outgoing Requests (исходящие запросы), чтобы увидеть, в какие конечные точки (BigQuery, CRM или рекламные платформы) сервер пересылает данные.
— Сверьте логи консоли. Обратите внимание на ошибки в журнале консоли, которые могут указывать на проблемы с авторизацией или некорректным форматом JSON при отправке данных в хранилище.

Это пригодится при настройке сбора данных для MMM (маркетингового микс-моделирования) или для проверки корректности передачи LTV (пожизненной ценности клиента) из CRM в BigQuery.

— @BigQuery4MarketingPro

Data Layer: как в BigQuery-аналитике не «замораживать» значение переменной на момент события

Если вы отправляете в BigQuery события из Google Tag Manager (GTM), важно помнить: у GTM Data Layer переменные по триггеру обычно “замораживаются” в состояние именно на момент, когда сработало событие. Это надёжно, пока бизнес-логика одна и та же для всех тегов. Но в маркетинге часто возникает потребность взять “самое актуальное” значение на момент выполнения тега/обработки — и тогда стандартный подход мешает.

Чек-лист для правки схемы передачи в BigQuery:

— Разведите “значение на событии” и “значение сейчас”
Определите, какие поля должны соответствовать конкретному действию пользователя (например, UTM на момент клика), а какие — актуальному контексту (например, текущий статус воронки).

— Проверьте, какие теги полагаются на Data Layer переменные
Если несколько тегов и переменных рассчитываются на одном триггере, проверьте, что все они действительно должны видеть одно и то же значение.

— Добавьте отдельный этап обновления контекста перед нужным тегом
Схема: событие фиксирует факт, но “контекстные” поля подтягивайте отдельным обновлением Data Layer до конкретного тега/серии тегов.

— Транслируйте “актуальное значение” в отдельные поля события в BigQuery
Вместо перезаписи исходного поля создайте новое (например, `campaign_current` рядом с `campaign_at_event`), чтобы не ломать воспроизводимость атрибуции.

— Сделайте валидацию в BigQuery на согласованность значений
Постройте проверки: различаются ли `*_at_event` и `*_current` в реальных сессиях, и совпадает ли это с ожидаемым поведением (например, при смене статуса после загрузки страницы).

— Зафиксируйте логику в документе схемы атрибутов
Коротко пропишите правила: какое поле всегда “на момент триггера”, какое — “после обновления контекста”, и для каких отчётов каждое используется.

— Проверьте влияние на отчёты маркетинга и RevOps
Если у вас выстраиваются MQL/SQL-переходы (в стиле Revenue Operations, ответственность за выручку), убедитесь, что вы не подменяете историческое значение на текущее и не искажаете cohort/воронки.

когда это пригодится: когда в цепочках GTM→BigQuery вы замечаете несостыковки между UTM/статусом/кампанией в разных тегах, хотя событие одно и то же.

— @BigQuery4MarketingPro

Ретроспективная оценка марк. эффективности с учетом сквозных ограничений (incrementality) в BigQuery

Маркетинг в 2026 все чаще упирается в privacy-first атрибуцию: last-click дает неполную картину, а “выгода” кампании зависит от того, сколько конверсий она принесла сверх того, что случилось бы само. На этой неделе можно собрать простую ретроспективную incrementality-модель прямо в BigQuery: сравнить фактические результаты с прогнозом “без кампании” на уровне аудитории и периодов.

1) Зафиксируйте “момент воздействия”
— Выберите одну воронку (например, регистрация → MQL).
— Для каждой кампании определите окно воздействия: start_date кампании и horizon (например, 14 дней).
— На уровне событий задайте флаг treated: event_date ∈ [start_date, start_date + horizon] и пользователя/организацию можно связать с экспонированием (через server-side логи, CRM-выгрузку или внутренний идентификатор).

2) Соберите витрину событий и фичи “до кампании”
Схема минимальной витрины в BigQuery:
— entity_id: идентификатор клиента/пользователя (в B2B удобнее аккаунт/org_id)
— event_date
— metric_flag: 1 если событие — целевое (например, became_mql)
— treated_date (дата экспозиции/зачисления в кампанию)
— covariates: показатели “фонового спроса” на дату (канал в целом, доля бренд/небренд в поиске, цена лида не нужна — только сигналы спроса)
Как сделать:
— Вытяните целевые события за период минимум “до + во время” (например, 8–12 недель).
— Для каждого entity_id сгруппируйте события по неделям (или дням), чтобы уменьшить шум.

3) Постройте прогноз “counterfactual” на обучении без treated
Логика:
— Берем только entity_id и периоды, где treated=0 (или до treated_date).
— Обучаем модель, предсказывающую вероятность/интенсивность целевого события по covariates и истории.
Практичный вариант без сложной ML-инфраструктуры:
— Используйте биграмм/агрегации и логистическую регрессию через BigQuery ML (если у вас она включена).
Что именно предсказывать:
— Либо binary target: случилось ли событие в day/week
— Либо rate: количество MQL на entity-week (с учетом частоты)

4) Сведите фактическое и прогнозное в инкрементальную метрику
После обучения:
— Для treated-периодов подставьте covariates и посчитайте predicted_p (ожидаемое без кампании).
— Инкремент:
incremental = actual_count - expected_count
Как посчитать в запросе:
— expected_count = predicted_p * 1 (или предсказанная интенсивность)
— actual_count = sum(metric_flag) по entity и периоду
Чтобы избежать “ложной уверенности”, агрегируйте минимум по неделям и по сегментам (SMB/Enterprise, отрасль, источник).

5) Проверьте качество на backtest (это обязательный шаг)
— Проведите “ложную кампанию” в прошлые периоды: сдвиньте treated_date на 4–6 недель назад и повторите pipeline.
— Если инкремент в backtest стабильно близок к нулю, а в реальном периоде — заметно выше, значит подход работает.
— Если в backtest тоже много инкремента, у вас, скорее всего, проблемы с фоном/сезонностью или treated связан с сильными базовыми отличиями сегментов.

6) Автоматизируйте выгрузку для RevOps и отчетов
Сделайте итоговую таблицу:
— campaign_id
— segment (опционально)
— period_start
— actual, expected, incremental
— lift = incremental / expected (осторожно с малым expected)
— confidence_proxy: ширина доверительного интервала (если есть) или хотя бы размер выборки entity

Почему это полезно именно сейчас
— В “zero-click” и Topical Authority ценность кампаний часто проявляется позже и частично через спрос, который нельзя атрибутировать по последнему клику.
— Incrementality позволяет говорить о влиянии на выручко-связанные метрики (MQL/SQL, activation), не притворяясь, что трекинг идеален.

Если хотите, пришлите: какая у вас сущность “entity_id” (пользователь или аккаунт), тип целевой метрики (MQL/SQL/первое событие/оплата) и чем подтверждается экспозиция. Я подскажу структуру таблиц и минимальный набор covariates под ваш кейс.

— @BigQuery4MarketingPro

Топика и Zero-click: как я собираю контент-матрицу в BigQuery, когда поиск перестал “вести трафик”

В 2026 я всё чаще вижу одну и ту же проблему у маркетологов: контент перестаёт приводить клики, зато растёт его влияние — через ответы в AI-обзорах и через то, что пользователи закрывают запрос, не переходя по ссылке. В такой реальности “написали 20 статей” больше не работает как KPI. Работает topical authority (тематический авторитет) — то есть связность тем, глубина терминов, охват сценариев и доказуемость экспертизы.

Я перестал строить контент-матрицу от ключевых слов “в лоб”. Теперь я строю её от запросов бизнеса к данным: что мы обязаны объяснить, чтобы довести пользователя до следующего шага воронки — и что именно будет считаться релевантным для модели/системы ранжирования.

Мой практический подход в BigQuery выглядит так.

1) Разворачиваю “вопросы” в сущности
Берём не только семантику, а глоссарий продукта и типовые возражения продаж/сервиса. В BigQuery я завожу таблицу `topic_entities`:
— тема (например, “атрибуция”)
— намерение (информирование, выбор решения, обоснование бюджету)
— сущность (инкрементальность, server-side, MMM, контроль качества данных)
— формат доказательства (кейсовые метрики, чек-лист, модель расчёта)

2) Привязываю к прошлым данным поведения
Дальше — отчётный слой `query_intent_to_engagement`:
— источники поисковых запросов (Search Console/логики воронки)
— сегменты аудитории (B2B роли: маркетинг, аналитика, RevOps/финансы)
— факт взаимодействия (показы/клики/время на странице — где есть; плюс косвенные признаки)
Даже если часть конверсий “не кликается”, нам важно фиксировать не только переходы. В B2B в реальности часто остаются просмотры документов, участие в вебинарах, скачивания, обращения в поддержку — и всё это можно собрать как события.

3) Считаю “coverage gap” не по наличию статьи, а по покрытию сущностей
Самая полезная метрика для редактора — “пробел покрытия”:
— по каждой теме считаю, какие сущности в контенте уже раскрыты
— какие намерения закрыты (информирование vs обоснование)
— какие форматы доказательств отсутствуют
Результат — список “следующих публикаций”, но не очередной контент-план, а точечные темы с недостающими блоками.

Наблюдение из практики: когда мы заменили KPI “кол-во постов” на KPI “закрытие сущностей” (в среднем 10–15 сущностей на тему), органический спрос на платформах с информационным шумом перестал проседать так резко. Улучшение не потому, что алгоритмы “любят текст”, а потому что контент стал структурой знаний, которую проще извлечь и пересказать в Zero-click среде.

Если хотите, опишу, как я делаю витрину `content_coverage` и какие поля обязательно хранить, чтобы контент-матрица жила вместе с аналитикой и RevOps (общая ответственность маркетинга, sales, customer success за выручку).

— @BigQuery4MarketingPro

SQL-запрос в BigQuery обязательно должен быть сложным

**Миф**: «Пока ты не пишешь запросы с пятью JOIN, оконными функциями и рекурсивными CTE — ты не работаешь с BigQuery, а играешь в песочнице».

**Откуда растёт**: из технических блогов и статей по data engineering, где авторы соревнуются в изяществе SQL. Маркетолог читает это, открывает консоль и чувствует, что отстаёт на три поколения. Плюс сами вендоры любят показывать кейсы с километровыми запросами — это продаёт платформу.

**Почему это неправда**: сила BigQuery для маркетинга — в скорости итераций и достоверности ответа, а не в красоте кода. Запрос, который отвечает на бизнес-вопрос, стоит дешевле всего — даже если это `SELECT COUNT(DISTINCT user_id) FROM events WHERE event_date BETWEEN ...`. В 2026 году, когда растёт популярность AI-обзоров и zero-click поведения, маркетинговая аналитика всё чаще сводится к проверке гипотез в три строки, а не к построению витрин на десять слоёв.

Что важнее изощрённого JOIN:

— **Корректная фильтрация** дублей и тестовых кампаний до агрегации, а не после.
— **Явная модель атрибуции** в самом запросе: выбранный столбец источника, окно конверсии, правила дедупликации.
— **Стоимость** сканирования — у BigQuery она прозрачная, и маркер «я молодец» часто неприлично дорогой.
— **Воспроизводимость** через сохранённый запрос и расписание, а не через скриншот в чате.

**Что вместо**: правило «один запрос — один бизнес-вопрос». Сначала формулируем вопрос на языке продукта, потом — минимальный SQL, который даёт честный ответ. JOIN, оконные функции и UDF добавляем только тогда, когда их отсутствие искажает результат. Если ваш отдел умеет держать семь простых запросов под расписание и доверяет их цифрам, это победа. Один красивый монстр на полстраницы, который никто не может проверить, — это технический долг.

— @BigQuery4MarketingPro

Как оптимизировать стоимость привлечения клиента в эпоху снижения среднего чека на примере e-com ритейла

В 2026 году ритейл столкнулся с новой реальностью: покупательская способность стагнирует, а стоимость охвата в каналах с переходом на AI-обзоры (искусственный интеллект в поисковой выдаче) растет. Когда средний чек падает на 6-8%, классическая модель last-click (атрибуция по последнему клику) становится опасной, так как она переоценивает вклад контекстной рекламы и недооценивает retention (удержание клиентов). Разберем, как крупный игрок сегмента одежды перешел от оперативного управления к аналитике на базе BigQuery.

Контекст: компания заметила, что при росте маркетинговых расходов на 15%, выручка увеличивалась лишь на 4%. Стандартные отчеты в рекламных кабинетах показывали эффективность, но в реальности LTV (пожизненная ценность клиента) снижался.

Задача: внедрить server-side (серверную) атрибуцию и перейти от оценки разовых покупок к анализу прибыльности когорт, чтобы перераспределить бюджеты в пользу каналов, приносящих лояльную аудиторию.

Решение:
— Инженеры данных настроили сбор событий напрямую через Measurement Protocol в BigQuery, минуя блокировщики рекламы.
— Была развернута модель данных, объединяющая расходы из рекламных сетей, CRM и данные из Google Analytics 4.
— Для борьбы с размытием данных из-за Zero-click (поисковой выдачи без переходов) внедрили MMM (моделирование маркетингового микса), используя библиотеку LightweightMMM внутри облачной инфраструктуры.
— В таблицу `orders_enriched` в BigQuery добавили атрибут «стоимость привлечения по когорте», который обновлялся каждые 6 часов.

Результат:
Через три месяца после внедрения компания отказалась от автоматического распределения бюджета в пользу каналов с высокой частотой покупок.
— Снижение CAC (стоимости привлечения) на 12% за счет выявления каналов, приводивших «одноразовых» покупателей.
— Рост повторных покупок на 18% благодаря смене стратегии коммуникации для сегментов с высоким потенциалом LTV.
— Увеличение маржинальности на 5% за счет отказа от инвестиций в каналы с низкой долгосрочной доходностью.

Урок для команды:
В условиях, когда каждый рубль на счету, доверие к цифрам в «рекламных кабинетах» — это путь к убыткам. Переход на собственное хранилище BigQuery позволяет объединить разрозненные данные в единую экосистему. Главный вывод: в эпоху RevOps (общей ответственности команд за выручку) аналитик должен отвечать не за количество кликов, а за то, как данные помогают маркетингу и продажам фокусироваться на клиентах, которые возвращаются. Если ваша отчетность до сих пор строится на last-click, вы буквально субсидируете неэффективный трафик, который не дает прироста в длинную.

— @BigQuery4MarketingPro

Как X5 собрали маркетинговую аналитику в BigQuery и перестали спорить о цифрах

В 2026-м маркетинг всё чаще упирается не в «показать больше рекламы», а в то, **как связать каналы с выручкой**. У X5, как и у любой крупной розницы, источников данных десятки: медийка, перформанс, CRM, кассы, приложение, сайт, промо-кампании. Пока каждый канал живёт в своей отчётности, маркетинг быстро превращается в спор о last-click (последнем клике), а не в управление ростом.

Задача была простая на словах и сложная на практике: собрать единую витрину данных, чтобы видеть путь клиента от контакта до покупки и считать не только заявки, но и **доход, повторные покупки и вклад в выручку**.

Что сделали:
— свели в BigQuery данные из рекламных кабинетов, веб-аналитики, CRM и транзакций;
— нормализовали идентификаторы пользователей и событий, чтобы один клиент не дублировался в разных системах;
— построили ежедневные таблицы с ключевыми метриками: расходы, доход, конверсия, частота покупок, LTV (пожизненная ценность клиента);
— добавили сегментацию по регионам, категориям и типам кампаний;
— отдельно вынесли проверку качества данных: пропуски, задержки загрузки, расхождения между источниками.

Самое важное — команда перестала измерять эффективность только по заявкам. В рознице это особенно дорого: средний чек снижается, а значит, выигрыш даёт не первая покупка, а **удержание и повторная выручка**. После переноса отчётности в BigQuery маркетологи смогли быстро сравнивать каналы не по «красивым» CTR, а по маржинальному доходу и повторным визитам.

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

Главный урок: BigQuery в маркетинге — это не про «хранилище ради хранилища». Это способ перевести разговор с уровня «где был последний клик» на уровень **«что реально принесло деньги и вернуло клиента»**. В эпоху privacy-first атрибуции и слабого last-click это уже не удобство, а базовая управленческая необходимость.

— @BigQuery4MarketingPro

Алиса AI будет конкурировать с Google AI Studio

Яндекс разворачивает экосистему AI-агентов на базе Алисы с доступом сначала для компаний, затем для всех. Агенты уже работают в Яндекс Такси и Лавке, скоро появятся в браузере и студии разработки. Платформа интегрирует стандартные функции — заказ такси, покупки, анализ данных. Алиса AI показывает неплохие результаты: менее известна, чем конкуренты, поэтому предлагает щедрые лимиты на видеогенерацию и работу с контентом. Яндекс планирует внедрить…

➡️ Читайте на сайте: https://aff.top/blog/alisa-ai-budet-konkurirovat-s-google-ai-studio

🧠 Ещё больше инсайтов → в канале AFF.top

В Zennoposter добавили ИИ-помощник

Zennolab добавил в Zennoposter встроенный ИИ-кубик с доступом к четырём моделям (Gemini, DeepSeek, Claude, ChatGPT) — 50 бесплатных запросов в сутки. Есть режимы Assistant (чтение) и Agent (автоматическое создание скриптов), плюс новый GET-запрос по API. Нейросети хорошо справляются с регистрацией, постингом, фармингом аккаунтов и простым кодированием, но требуют проверки при парсинге динамических сайтов и диагностике ошибок. В связке с Zennoobr…

➡️ Читайте на сайте: https://aff.top/blog/v-zennoposter-dobavili-ii-pomoschnik

🧠 Ещё больше инсайтов → в канале AFF.top