Стоимость привлечения растёт, а глубина данных о клиенте — нет

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

Типичная картина в BigQuery у заказчика:
— события из GA4 и CRM разложены по разным проектам, иногда в разных аккаунтах
— user_id прокинут через пол-воронки, дальше обрыв
— заказы есть, а нормальной таблицы клиентов с историей покупок нет
— повторные продажи считаются вручную в Looker Studio поверх CSV

При этом тот же клиент спокойно вкладывается в performance и ждёт снижения CPO (стоимости привлечения заказа). Но без связки «расход → поведение → повторная выручка» эта метрика превращается в метрику первого касания, а не в метрику привлечения клиента.

Складывается ощущение, что индустрия упёрлась в разрыв: инструменты для сбора данных есть, а привычка собирать их в одну модель под LTV (пожизненную ценность клиента) и retention (удержание) — нет.

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

— @BigQuery4MarketingPro

Настройка Facebook Customer Chat в GTM: пошаговый чек-лист для передачи данных в BigQuery

Facebook Customer Chat — стандартный виджет для связи с клиентами, но его события (открытие диалога, отправка сообщения, завершение) по умолчанию не попадают в вашу аналитику. Без них невозможно оценить влияние чата на конверсию, LTV и retention. Используем неофициальный шаблон тега от Simo Ahava — он загружает SDK и цепляет обработчики событий API.

— Скачайте шаблон Custom Tag Template из библиотеки Simo Ahava и импортируйте в Google Tag Manager. В шаблоне уже прописана структура для загрузки SDK и подписки на события `onCustomerChatDialogHidden`, `onCustomerChatDialogShown`, `onSendMessage`, `onMarkSeen` и др.

— В параметрах шаблона укажите Page ID вашей страницы Facebook (берётся из настроек виджета). Включите опцию «Automatically load SDK» — это загрузит скрипт динамически, без замедления загрузки страницы.

— Создайте новый тег с этим шаблоном и триггером «All Pages — DOM Ready». Не используйте Page View, так как SDK должен загрузиться после построения DOM. Убедитесь, что тег не блокируется согласием на cookie — сам SDK уже обрабатывает согласие, ваша задача только собрать события.

— Внутри шаблона настройте **Push to Data Layer** для каждого нужного события. Например, при `onSendMessage` передавайте в dataLayer объект `{event: 'fb_chat_message', fbChatEvent: 'sent', fbChatTimestamp: timestamp}`. Это позволит триггерам GTM ловить эти события.

— Создайте переменные dataLayer для захвата типа события (`fbChatEvent`), метки времени, а при желании — анонимизированного ID диалога (если передаётся в API). **Важно**: не собирайте сам текст сообщения или личные данные — это нарушает policy Facebook и принципы privacy-first аналитики.

— Настройте тег GA4 Event или тег-отправку в BigQuery через HTTP-запрос (например, Server Container с endpoint вашей таблицы). Для BigQuery: используйте собственный тег с шаблоном `HTTP Request`, отправляющий JSON-объект с параметрами события, либо используйте коннектор BigQuery в GTM (если он развёрнут). События с Chat SDK имеют малый объём — можно писать напрямую без буфера.

— Проверьте в GTM Preview mode: открывайте чат на сайте — в Data Layer должны появляться объекты `fb_chat_message`. Убедитесь, что тег срабатывает корректно, а в BigQuery появляются строки с полями `event_name`, `fb_chat_event`, `client_id` (если используете GA4 Client ID для связки), `page_location`, `timestamp_micros`.

Когда это пригодится: при построении когортного анализа пользователей, которые взаимодействовали с чатом, для расчёта влияния чат-поддержки на LTV (e-com 2026 — ставка на retention) и при переходе от last-click к mmix-модели с учётом касаний в чате.

— @BigQuery4MarketingPro

Почему я перестал доверять одному отчёту по CAC

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

Почему? Потому что CAC отвечает только на вопрос «сколько стоило привлечение», но не отвечает на более важные вопросы: кого мы привлекли, как быстро человек окупится, и что будет с выручкой через 3–6 месяцев. В B2B это особенно заметно: один и тот же канал может давать дорогие лиды, но при этом приводить клиентов с вдвое большей выручкой. А в e-com ситуация ещё жестче — средний чек снижается, и первая покупка всё чаще не покрывает стоимость привлечения без учёта повторных заказов.

Мой практический вывод простой: **CAC без когорт и LTV — это не метрика эффективности, а лишь витрина расходов**.

В BigQuery я обычно собираю не один отчёт, а связку:
— CAC по каналам и кампаниям;
— LTV по когортам первого касания или первой покупки;
— срок окупаемости в днях или месяцах;
— долю повторных покупок и выручку на клиента по сегментам.

Один показательный кейс: на первом уровне отчётности канал выглядел слабым — CAC был на 28% выше среднего. Но когда мы посмотрели когорты в разрезе 90 дней, оказалось, что этот же канал давал на 41% выше LTV и быстрее выходил в окупаемость. Если бы мы смотрели только на CAC, канал бы закрыли раньше времени.

Сейчас, когда last-click теряет вес, а privacy-first атрибуция и MMM требуют большего контекста, маркетологу нужно меньше верить одной цифре и больше строить систему связей между метриками.

Мой принцип такой: не спрашиваю «какой у нас CAC?», пока не вижу рядом ответ на три вопроса — **какая когорта, какой LTV и когда окупаемся**.

— @BigQuery4MarketingPro

ЕЮ Иванов продолжает кошмарить АффПапу, конторку, которая накинула говна на вентилятор этим летом. Тогда в AffPapa не знали, с каким говном идут бодаться, поэтому заслуженно проиграли. 😏

На этот раз ЕЮ зарегал товарный знак AffPapa — совсем скоро имя компании будет официально принадлежать ему. Чтобы убедиться в трушности мува, переходим по ссыл-Очке и вводим серийный номер: 2026793242. Там видим, что заявка на регистрацию подана лично Евгением Юрьичем.

Всё это выглядит забавно, но давайте не забывать, в какой сфере мы работаем и что реально может произойти с жирным троллем за воровство нейминга. Впрочем, толстому не привыкать отхватывать пиздов за проделки в интернете, поэтому ждем очередную фотку разбитого ебала и длинный пост с извинениями. 😏😏😏

В арбитраже денег нет 💵

Кейс «Самоката»: как BigQuery помог пересобрать retention вместо борьбы за первую покупку

В 2024-2025 у «Самоката» одна из самых дорогих метрик в e-grocery — повторный заказ. Средний чек в сегменте экспресс-доставки продуктов просел на 6-8%, конкуренция с «Яндекс Лавкой» и «ВкусВилл» обострилась до предела. Привлекать нового клиента стало в 2,3 раза дороже, чем удержать старого. Команда «Самоката» сфокусировалась на retention и LTV (пожизненной ценности клиента) — и тут на сцену вышел BigQuery.

**Контекст**

Данные лежали в трёх местах: заказы в PostgreSQL, события приложения в ClickHouse, маркетинговые расходы в API рекламных кабинетов. Соединить их вручную через SQL-запросы аналитика занимало 3-4 дня. Маркетинг не мог отвечать на вопрос «какой когорте какой промокод дать» быстрее, чем за неделю.

**Задача**

Сократить цикл «гипотеза — эксперимент — вывод» до 24 часов. Научиться считать реальный LTV по когортам с учётом оттока, а не по средней температуре по больнице.

**Решение**

Команда собрала единое хранилище на BigQuery: потоковые данные из приложения через Firebase → Streaming Insert, батчи из 1С и рекламных систем через Cloud Functions. Всё сводится в таблицы фактов по схеме «звезда»: в центре таблица заказов, вокруг — справочники клиентов, товаров, промо-акций.

Дальше появился ключевой запрос — когортный LTV с окном 90 дней:

— считаем день первой покупки для каждого клиента
— группируем по неделям когорты
— считаем накопительную выручку и churn rate (отток)
— отнимаем CAC (стоимость привлечения) по каждому каналу

Всё это в материализованном представлении, которое пересчитывается каждые 6 часов. Маркетолог сам открывает Looker Studio и видит, какая когорта из какого канала окупается на 60-й, 90-й, 120-й день.

**Результат**

За 8 месяцев: цикл эксперимента сократился с 7 дней до 18 часов, доля когорт с положительным LTV на горизонте 90 дней выросла с 34% до 51%, бюджет на привлечение перераспределили в пользу каналов с лучшей retention-кривой. Отдельный инсайт: когорты из push-подписчиков показали LTV на 27% выше, чем из платного трафика — но только при условии, что первый заказ случался в течение 48 часов после подписки.

**Урок**

Когда воронка дорожает, retention-метрики в BigQuery превращаются из «дашборда для CFO» в рабочий инструмент маркетинга. Главное — не считать LTV как среднее по всем клиентам, а строить его по когортам с поправкой на канал привлечения. Иначе оптимизируешь прошлогодний снег.

В 2026 году эта логика становится стандартом: privacy-first атрибуция (серверная, MMM, incrementality) вытесняет last-click, и без нормальной когортной аналитики в BigQuery маркетинг просто не увидит, где он зарабатывает, а где сливает.

— @BigQuery4MarketingPro

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

Я часто вижу одну и ту же ошибку: команда подключает BigQuery, строит десятки витрин, а потом спорит не о выводах, а о том, какая таблица «правильная». В 2026 году это особенно дорого. Когда last-click уже не спасает, а privacy-first атрибуция, server-side и MMM требуют согласованности, главная ценность BigQuery — не в объёме данных, а в едином методе расчёта.

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

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

Я однажды сводил данные по 14 каналам для B2B-воронки. После очистки и унификации событий объём «полезных» строк оказался почти на 40% меньше, чем ожидала команда. И это была хорошая новость: мы наконец-то увидели не шум, а реальную структуру спроса. Решения по перераспределению бюджета после этого стали проще и быстрее.

BigQuery в маркетинге выигрывает не тогда, когда вы строите ещё один дашборд. А когда фиксируете правила, по которым любой новый отчёт будет считаться так же, как предыдущий. В эпоху, где ценится не объём отчётности, а доверие к цифре, это и есть конкурентное преимущество.

— @BigQuery4MarketingPro

Маркетинг-таблица “в один клик” не нужна: как я собираю витрину в BigQuery под RevOps (выручка, а не отчёты)

В 2026 я всё чаще вижу одну и ту же ловушку: маркетинг собирает “универсальную” витрину под любые вопросы, а потом годами обслуживает её, добавляя новые поля и костыли. В итоге аналитика отвечает долго, данные спорят друг с другом, а решения всё равно принимаются по последнему знакомому графику. Я считаю, что в RevOps (общей ответственности маркетинга, продаж и customer success за выручку) выигрывает не “таблица на все случаи”, а витрина под конкретный цикл ценности.

Как я делаю это в BigQuery:

1) Начинаю не с событий, а с бизнес-метрики. Для B2B и e-com это обычно один и тот же каркас:
— конверсия в целевое действие (лид/сделка/заказ)
— время до следующего шага (n дней)
— источник/кампания на момент первого контакта
— и ключевое: связь “маркетинг → выручка” через единый идентификатор (customer_id / account_id / lead_id), а не через набор разрозненных полей.

2) Сразу закладываю privacy-first атрибуцию. Если у вас есть хоть какая-то вероятностная связка (серверная), я фиксирую это как отдельный признак доверия (например, confidence_score) и храню его вместе с атрибуцией. Это не “техническая красота”, а способ избежать ложной точности: команды перестают спорить о том, какая модель “правильнее”, потому что видно границы уверенности.

3) Развожу “сырые события” и “витрину для решений”. В raw-слое я держу всё как пришло (именно для расследований и качества), а в витрине — только то, что нужно для расчётов: ключи, временные метки, атрибуты кампании, агрегаты. В итоге витрина живёт быстрее и меньше ломается при изменениях трекинга.

Один практический показатель из моих проектов: когда мы перестали делать единую “универсальную” таблицу и перешли к витрине под жизненный цикл (первичный контакт → целевое событие → выручка в окне), скорость построения отчётов выросла примерно в 2–3 раза, а количество разбирательств “чьи данные верные” заметно снизилось. Не потому что запрос стал короче, а потому что исчезли неоднозначности в логике.

Если коротко, моя позиция такая: в BigQuery ценность не в количестве таблиц, а в дисциплине контракта данных. Витрина должна отвечать на один бизнес-тип решения — тогда она действительно ускоряет RevOps, а не превращается в склад “на всякий случай”.

— @BigQuery4MarketingPro

Как маркетингу в 2026 смотреть на выручку, а не на клики: кейс с BigQuery

Обычно маркетинг отчитывается по кликам, лидам и стоимости заявки. Но в 2026 этого уже мало: в B2B слабеет классическая связка MQL → SQL, в e-com растёт давление на маржу, а last-click всё хуже объясняет, что реально принесло деньги.

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

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

Что это дало:
— стало видно, какие каналы дают не просто трафик, а деньги;
— появилась возможность сравнивать не CPL, а стоимость привлечения выручки;
— команда быстрее находила, где воронка «протекает»: в рекламе, на сайте, в обработке лидов или в sales-процессе.

Главный урок здесь не в самом BigQuery, а в логике. Когда данные лежат в одной витрине, маркетинг перестаёт спорить про красивые отчёты и начинает управлять вкладом в выручку. Это особенно важно сейчас, когда privacy-first атрибуция, server-side сбор и MMM постепенно вытесняют привычный last-click.

Если у вас в отчётах до сих пор живут отдельные цифры по рекламе, CRM и продажам, первый шаг не в новой модели атрибуции. Первый шаг — собрать единую правду о клиентском пути в одном хранилище.

— @BigQuery4MarketingPro

BigQuery перестал быть просто складом данных

В маркетинге это уже не «куда слили отчёты», а место, где проверяют, что вообще правда в воронке. Когда last-click теряет вес, а server-side, MMM и incremental-оценка становятся нормой, BigQuery превращается в рабочую книгу всей команды. И это, по-моему, главный сдвиг 2026 года: ценность не в том, чтобы хранить больше, а в том, чтобы быстрее отличать сигнал от шума.

— @BigQuery4MarketingPro