Настройка 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

BigQuery как оперативная память маркетинга: зачем хранить не отчёты, а путь решения

В 2026 году маркетинг всё меньше живёт в логике «собрали отчёт — сделали вывод». Запрос меняется: не просто увидеть, что случилось, а быстро понять, почему это случилось и что с этим делать дальше. Для этого BigQuery особенно полезен не как «склад данных», а как оперативная память команды — место, где остаются следы поведения, затрат, контента, продаж и сервиса. И чем сложнее воронка, тем важнее не отдельные таблицы, а связанная история.

Если смотреть на зрелый маркетинг, BigQuery уже не про аналитику ради аналитики. Он нужен, чтобы соединить разрозненные сигналы: клики из рекламы, визиты на сайт, события из CRM, обращения в поддержку, повторные покупки, возвраты. Когда эти данные лежат в одной среде, вопрос «что сработало?» перестаёт быть гаданием. Начинается работа с причинностью.

Первый полезный сдвиг — перестать хранить в голове каналы отдельно от бизнеса.

Типичная ошибка в performance-маркетинге — считать успех по последнему клику. Но в эпоху privacy-first атрибуции last-click всё хуже объясняет результат. В BigQuery можно собрать цепочки касаний и посмотреть, какие комбинации каналов приводят к продаже или заявке. Например, в B2B часто видно, что первая встреча с брендом случается через контент или поиск, затем человек возвращается через ретаргетинг, а конверсия происходит после письма от sales. Если смотреть только на последнее событие, вклад первых касаний исчезает. Если считать путь целиком, становится понятно, где на самом деле создаётся спрос.

Второй сдвиг — считать не только привлечение, но и удержание.

Для e-com это особенно заметно: средний чек проседает, а значит, ценность первой покупки снижается. В такой ситуации маркетинг выигрывает не у того, кто дешевле приводит клиента, а у того, кто лучше удерживает. BigQuery позволяет связать рекламное привлечение с повторными заказами, частотой покупок, возвратами и LTV. Допустим, две кампании дают одинаковую цену заявки. Но в одной группе пользователи покупают повторно через 30 дней чаще, а в другой — почти не возвращаются. Без общей таблицы это выглядит как одинаковый результат. С общей таблицей становится ясно, что одна кампания покупает выручку, а другая — только первое касание.

Третий сдвиг — видеть контент как источник спроса, а не как «единицу публикации».

Из-за zero-click-эпохи и роста AI-overviews ценность текста всё чаще определяется не количеством показов, а тем, насколько он помогает человеку принять решение и запомнить бренд. В BigQuery можно соединить публикации, переходы, глубину просмотра, возвраты на сайт, лид-формы и влияние контента на следующие шаги. Например, статья не обязательно приводит к конверсии сразу. Но если после её прочтения человек позже приходит напрямую, ищет бренд по названию и читает материалы по той же теме, значит, контент работает как топик-авторитетность — строит узнаваемость и доверие. Это особенно важно в B2B, где длинный цикл сделки и редкие касания делают контент частью продажи, а не украшением.

Четвёртый сдвиг — использовать BigQuery не как архив, а как среду для решений.

Когда маркетинг, sales и customer success начинают смотреть на одни и те же данные, меняется сама управленческая логика. RevOps — это не модное слово, а попытка связать выручку из разных функций в один контур. В BigQuery можно собрать единый слой: кто пришёл, с каким запросом, как отработал отдел продаж, что случилось после сделки, где клиент «остыл», а где вырос в повторную выручку. Простой пример: отдел маркетинга приводит меньше лидов, но больше аккаунтов с высоким шансом на сделку. Отдел продаж закрывает их быстрее. Customer success удерживает их дольше. В разрозненных отчётах это выглядит как разные победы. В общей модели — как одна система выручки.
…

BigQuery как истина в последней инстанции для RevOps

Классическая воронка MQL → SQL заканчивается там, где маркетинг перестаёт быть «генератором лидов» и становится полноценным участником выручки. В 2026 году это уже не тренд, а условие выживания B2B-компаний. Маркетинг, sales и success работают по единому P&L, и единственный способ не утонуть в спорах «чей лид теплее» — единая правда данных. BigQuery здесь — не просто хранилище, а судебный пристав сквозной аналитики.

Я вижу системную ошибку: компании завозят в BQ сырые CRM-данные, подключают пару дашбордов и называют это RevOps. На деле RevOps требует сшивки трёх слоёв: тугова (контакты с сайта, вебинар, чат), мидла (переходы между стадиями в CRM, касания AE) и лонга (LTV, churn, upsell). Без единого user_id на уровне BigQuery вы получаете три разные вселенные.

Пример из практики: недавно собирали сквозную модель для SaaS с циклом сделки 4 месяца. Оказалось, что 30% «мёртвых» MQL на самом деле уходили в отложенный спрос и возвращались через 45-60 дней — но sales их не обрабатывал, потому что в CRM не было метки «пауза/дозрев». В BQ мы просто наложили окна LAG() по user_id и увидели паттерн. Маркетинг перестал тратить бюджет на повторный прогрев тех, кто и так уже был «тёплым». Экономия на ретаргетинге — 22% за квартал.

Ваша задача как аналитика в команде RevOps — не просто считать конверсии, а построить в BigQuery единую шину, где каждое касание имеет временную метку и скоринг готовности к покупке. SQL-запрос, объединяющий GA4, CRM и платёжный модуль по client_id, сегодня стоит дороже любой CRM-интеграции. Потому что он даёт ответ не «сколько MQL», а «какая комбинация каналов даёт контракт с LTV > 300К».

Не ждите, пока маркетинг и sales договорятся. Сшейте данные в BigQuery — и пусть они спорят с витриной, а не с вами.

— @BigQuery4MarketingPro

В роликах Youtube теперь можно рекламировать товары Amazone

➡️ Читайте на сайте: https://aff.top/blog/v-rolikakh-youtube-teper-mozhno-reklamirovat-tovary-amazone

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

Google выпустил Gemini Omni 1.1 Flash

Google обновил Gemini Omni для генерации видео: модель умеет продолжать сцены с учётом до 10 секунд контекста и собирать ролик до 40 секунд, работать по референсу и делать переходы между кадрами. Главный вывод — инструмент стал практичнее для продакшена, а посекундная цена делает его заметно доступнее для тестов и рабочих задач.

➡️ Читайте на сайте: https://aff.top/blog/google-vypustil-gemini-omni-1-1-flash

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

Топ 5 PWA-сервисов для залива дейтинга

Статья показывает, что PWA выгодны не только для гемблы: в дейтинге они дают пуш-базу, больше траста и помогают маскировать оффер под бренд. Главный выбор зависит от цены инсталлов и теста GEO: для старта лучше бесплатные или дешёвые решения, а Progressier выделяется как самый практичный вариант для залива дейтинга.

➡️ Читайте на сайте: https://aff.top/blog/top-5-pwa-servisov-dlia-zaliva-deitinga

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

Как X5 собрала единый отчёт по промо и перестала спорить о «не тех» цифрах

У X5 была типичная для крупного ритейла проблема: маркетинг, e-com и CRM смотрели на промо через разные системы. В одном отчёте считали выручку по чекам, в другом — по заказам, в третьем — по трафику и кликам. В итоге одна и та же акция могла выглядеть как успешная в перформансе и слабая в продажах.

**Контекст** был простой: растёт доля цифровых касаний, а средний чек в ритейле под давлением и без аккуратной аналитики промо быстро «съедает» маржу. Для X5 это означало не только измерить эффект кампаний, но и понять, где акция реально увеличивает корзину, а где лишь переносит спрос между неделями.

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

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

**Решение** строили вокруг BigQuery как единого слоя правды:
— нормализовали источники в общую модель;
— считали инкрементальность промо по когорте и контрольным группам;
— выделяли uplift (прирост) не только по выручке, но и по марже;
— собирали ежедневные витрины для маркетинга и коммерции.

Практически это дало возможность смотреть не на last-click (последний клик), а на вклад кампании в деньги. В 2026 это особенно важно: privacy-first атрибуция, server-side и MMM (маркетинг-микс-моделирование) всё чаще дополняют, а не заменяют друг друга.

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

**Урок** для маркетолога: BigQuery полезен не как хранилище ради хранилища, а как инструмент согласовать маркетинг, продажи и финансы на одной цифре. В эпоху, когда MQL/SQL теряют силу, а на первый план выходит RevOps, это уже не «хорошая аналитика», а базовая операционная необходимость.

— @BigQuery4MarketingPro