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
Если вы отправляете в 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
Маркетинг в 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
В 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
**Миф**: «Пока ты не пишешь запросы с пятью 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
В 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
Forwarded from Потрачено! Клуб спящих бизнесменов!
This media is not supported in your browser
VIEW IN TELEGRAM
🚀 aff.top — вся индустрия арбитража в одном месте
🧠 Блог про арбитраж и ИИ — как нейросети меняют залив и антифрод
🚨 База спамеров — ежедневно собираем спамеров и ведём рейтинг
🛠 70+ инструментов — от клоаки до антифрод-чека
🎬 1000+ видео — весь YouTube про трафик в одной ленте
👤 2400+ персон — байеры и фаундеры с контактами напрямую
Без регистрации, без платных «премиумов».
👇 Подписывайся на канал
🧠 Блог про арбитраж и ИИ — как нейросети меняют залив и антифрод
🚨 База спамеров — ежедневно собираем спамеров и ведём рейтинг
🛠 70+ инструментов — от клоаки до антифрод-чека
🎬 1000+ видео — весь YouTube про трафик в одной ленте
👤 2400+ персон — байеры и фаундеры с контактами напрямую
Без регистрации, без платных «премиумов».
👇 Подписывайся на канал
Как X5 собрали маркетинговую аналитику в BigQuery и перестали спорить о цифрах
В 2026-м маркетинг всё чаще упирается не в «показать больше рекламы», а в то, **как связать каналы с выручкой**. У X5, как и у любой крупной розницы, источников данных десятки: медийка, перформанс, CRM, кассы, приложение, сайт, промо-кампании. Пока каждый канал живёт в своей отчётности, маркетинг быстро превращается в спор о last-click (последнем клике), а не в управление ростом.
Задача была простая на словах и сложная на практике: собрать единую витрину данных, чтобы видеть путь клиента от контакта до покупки и считать не только заявки, но и **доход, повторные покупки и вклад в выручку**.
Что сделали:
— свели в BigQuery данные из рекламных кабинетов, веб-аналитики, CRM и транзакций;
— нормализовали идентификаторы пользователей и событий, чтобы один клиент не дублировался в разных системах;
— построили ежедневные таблицы с ключевыми метриками: расходы, доход, конверсия, частота покупок, LTV (пожизненная ценность клиента);
— добавили сегментацию по регионам, категориям и типам кампаний;
— отдельно вынесли проверку качества данных: пропуски, задержки загрузки, расхождения между источниками.
Самое важное — команда перестала измерять эффективность только по заявкам. В рознице это особенно дорого: средний чек снижается, а значит, выигрыш даёт не первая покупка, а **удержание и повторная выручка**. После переноса отчётности в BigQuery маркетологи смогли быстро сравнивать каналы не по «красивым» CTR, а по маржинальному доходу и повторным визитам.
Результат обычно выглядит так:
— меньше ручной сверки отчётов;
— быстрее пересмотр бюджетов между каналами;
— прозрачнее вклад промо в выручку;
— проще защищать решения перед продажами и финансами.
Главный урок: BigQuery в маркетинге — это не про «хранилище ради хранилища». Это способ перевести разговор с уровня «где был последний клик» на уровень **«что реально принесло деньги и вернуло клиента»**. В эпоху privacy-first атрибуции и слабого last-click это уже не удобство, а базовая управленческая необходимость.
— @BigQuery4MarketingPro
В 2026-м маркетинг всё чаще упирается не в «показать больше рекламы», а в то, **как связать каналы с выручкой**. У X5, как и у любой крупной розницы, источников данных десятки: медийка, перформанс, CRM, кассы, приложение, сайт, промо-кампании. Пока каждый канал живёт в своей отчётности, маркетинг быстро превращается в спор о last-click (последнем клике), а не в управление ростом.
Задача была простая на словах и сложная на практике: собрать единую витрину данных, чтобы видеть путь клиента от контакта до покупки и считать не только заявки, но и **доход, повторные покупки и вклад в выручку**.
Что сделали:
— свели в BigQuery данные из рекламных кабинетов, веб-аналитики, CRM и транзакций;
— нормализовали идентификаторы пользователей и событий, чтобы один клиент не дублировался в разных системах;
— построили ежедневные таблицы с ключевыми метриками: расходы, доход, конверсия, частота покупок, LTV (пожизненная ценность клиента);
— добавили сегментацию по регионам, категориям и типам кампаний;
— отдельно вынесли проверку качества данных: пропуски, задержки загрузки, расхождения между источниками.
Самое важное — команда перестала измерять эффективность только по заявкам. В рознице это особенно дорого: средний чек снижается, а значит, выигрыш даёт не первая покупка, а **удержание и повторная выручка**. После переноса отчётности в BigQuery маркетологи смогли быстро сравнивать каналы не по «красивым» CTR, а по маржинальному доходу и повторным визитам.
Результат обычно выглядит так:
— меньше ручной сверки отчётов;
— быстрее пересмотр бюджетов между каналами;
— прозрачнее вклад промо в выручку;
— проще защищать решения перед продажами и финансами.
Главный урок: BigQuery в маркетинге — это не про «хранилище ради хранилища». Это способ перевести разговор с уровня «где был последний клик» на уровень **«что реально принесло деньги и вернуло клиента»**. В эпоху privacy-first атрибуции и слабого last-click это уже не удобство, а базовая управленческая необходимость.
— @BigQuery4MarketingPro
This media is not supported in your browser
VIEW IN TELEGRAM
Алиса AI будет конкурировать с Google AI Studio
Яндекс разворачивает экосистему AI-агентов на базе Алисы с доступом сначала для компаний, затем для всех. Агенты уже работают в Яндекс Такси и Лавке, скоро появятся в браузере и студии разработки. Платформа интегрирует стандартные функции — заказ такси, покупки, анализ данных. Алиса AI показывает неплохие результаты: менее известна, чем конкуренты, поэтому предлагает щедрые лимиты на видеогенерацию и работу с контентом. Яндекс планирует внедрить…
➡️ Читайте на сайте: https://aff.top/blog/alisa-ai-budet-konkurirovat-s-google-ai-studio
🧠 Ещё больше инсайтов → в канале AFF.top
Яндекс разворачивает экосистему AI-агентов на базе Алисы с доступом сначала для компаний, затем для всех. Агенты уже работают в Яндекс Такси и Лавке, скоро появятся в браузере и студии разработки. Платформа интегрирует стандартные функции — заказ такси, покупки, анализ данных. Алиса AI показывает неплохие результаты: менее известна, чем конкуренты, поэтому предлагает щедрые лимиты на видеогенерацию и работу с контентом. Яндекс планирует внедрить…
➡️ Читайте на сайте: https://aff.top/blog/alisa-ai-budet-konkurirovat-s-google-ai-studio
🧠 Ещё больше инсайтов → в канале AFF.top
This media is not supported in your browser
VIEW IN TELEGRAM
В Zennoposter добавили ИИ-помощник
Zennolab добавил в Zennoposter встроенный ИИ-кубик с доступом к четырём моделям (Gemini, DeepSeek, Claude, ChatGPT) — 50 бесплатных запросов в сутки. Есть режимы Assistant (чтение) и Agent (автоматическое создание скриптов), плюс новый GET-запрос по API. Нейросети хорошо справляются с регистрацией, постингом, фармингом аккаунтов и простым кодированием, но требуют проверки при парсинге динамических сайтов и диагностике ошибок. В связке с Zennoobr…
➡️ Читайте на сайте: https://aff.top/blog/v-zennoposter-dobavili-ii-pomoschnik
🧠 Ещё больше инсайтов → в канале AFF.top
Zennolab добавил в Zennoposter встроенный ИИ-кубик с доступом к четырём моделям (Gemini, DeepSeek, Claude, ChatGPT) — 50 бесплатных запросов в сутки. Есть режимы Assistant (чтение) и Agent (автоматическое создание скриптов), плюс новый GET-запрос по API. Нейросети хорошо справляются с регистрацией, постингом, фармингом аккаунтов и простым кодированием, но требуют проверки при парсинге динамических сайтов и диагностике ошибок. В связке с Zennoobr…
➡️ Читайте на сайте: https://aff.top/blog/v-zennoposter-dobavili-ii-pomoschnik
🧠 Ещё больше инсайтов → в канале AFF.top
Маркетинговый RevOps и BigQuery: как связали лиды, продажи и удержание в одну модель выручки
Компания (кейсово): B2B-сервис с циклом сделки 2–4 месяца. До 2026 маркетинг отвечал в основном за MQL (marketing qualified lead), однако конверсия из MQL в SQL (sales qualified lead) проседала, а ответственность за выручку постепенно перекладывали на RevOps — маркетинг, sales и customer success совместно ведут процесс до денег.
Задача: перестать измерять «воронку ради воронки» и увидеть, какие источники и кампании реально двигают выручку и удержание.
Проблемы были типичными:
— лиды и сделки жили в разных системах (CRM, формы, веб-аналитика)
— атрибуция часто была last-click (за пределами достоверности в privacy-first эпоху)
— нельзя было оценить вклад кампаний в качество лидов и повторные продажи
Решение в BigQuery:
1) Единый слой данных
— собрали события привлечения (UTM-метки/канал/кампания), формы и идентификаторы посетителей
— замапили на сущности CRM: lead, deal, pipeline stage, даты ключевых статусов
— добавили таблицу customer success: дата активации, отмены/продления, cohort по месяцу старта
2) Модель «доходного» пайплайна
— построили таблицу grain на уровне lead_id + deal_id: путь лида во времени (от первого касания до SQL и закрытия)
— рассчитали метрики качества: время до SQL, доля прохода по стадиям, вероятность закрытия
— отдельно посчитали retention: доля клиентов, удержанных в 1–3–6 месяцев после активации (retention — удержание)
3) Атрибуция без иллюзий last-click
— отказались от «одного победителя» и перешли на сценарный подход: распределяли кредит между касаниями по окнам (например, 7/30/90 дней до SQL и до закрытия), фиксируя uncertainty
— для кампаний считали не только CPA/CPL, но и *expected revenue contribution* (оценочный вклад в выручку) через связывание закрытых сделок с источниками
4) Дашборды для RevOps-ритуалов
— настроили витрины: Top-источники по выручке и по удержанию, разрезы по сегментам компаний, отчётность для sales (где качество лидов лучше) и для customer success (где больше churn-пики)
Конкретный результат (что обычно удаётся подтвердить цифрами в таких проектах):
— улучшили прозрачность: доля лидов с корректно восстановленной связью между привлечением и CRM выросла до уровня, достаточного для принятия решений (в среднем на практике поднимается с «неполных» 60–70% до 90%+ за счёт нормализации ключей и дедупликации)
— изменили управленческие KPI: бюджет начали перераспределять не по MQL-объёму, а по *вероятности закрытия + retention*; в горизонте 1 квартала это даёт заметную коррекцию в миксе источников (обычно компании видят рост доли сделок, прошедших нужные стадии, и более низкий churn в когортах с «качественных» кампаний)
— сократили время на сбор отчётности для встреч RevOps: с ручных выгрузок на «построил один раз — обновляй по расписанию»
Урок для читателя:
Если вы всё ещё оптимизируете маркетинг под воронку без привязки к стадии revenue-циклов и удержанию, BigQuery будет просто хранилищем. Переведите модель на конечный результат: свяжите lead → deal → retention, и считайте вклад кампаний через *качество и деньги*, а не только через клики/лиды. В 2026 это быстрее всего возвращает доверие между маркетингом, sales и customer success — и даёт основу для privacy-first атрибуции, где last-click не должен быть единственной правдой.
— @BigQuery4MarketingPro
Компания (кейсово): B2B-сервис с циклом сделки 2–4 месяца. До 2026 маркетинг отвечал в основном за MQL (marketing qualified lead), однако конверсия из MQL в SQL (sales qualified lead) проседала, а ответственность за выручку постепенно перекладывали на RevOps — маркетинг, sales и customer success совместно ведут процесс до денег.
Задача: перестать измерять «воронку ради воронки» и увидеть, какие источники и кампании реально двигают выручку и удержание.
Проблемы были типичными:
— лиды и сделки жили в разных системах (CRM, формы, веб-аналитика)
— атрибуция часто была last-click (за пределами достоверности в privacy-first эпоху)
— нельзя было оценить вклад кампаний в качество лидов и повторные продажи
Решение в BigQuery:
1) Единый слой данных
— собрали события привлечения (UTM-метки/канал/кампания), формы и идентификаторы посетителей
— замапили на сущности CRM: lead, deal, pipeline stage, даты ключевых статусов
— добавили таблицу customer success: дата активации, отмены/продления, cohort по месяцу старта
2) Модель «доходного» пайплайна
— построили таблицу grain на уровне lead_id + deal_id: путь лида во времени (от первого касания до SQL и закрытия)
— рассчитали метрики качества: время до SQL, доля прохода по стадиям, вероятность закрытия
— отдельно посчитали retention: доля клиентов, удержанных в 1–3–6 месяцев после активации (retention — удержание)
3) Атрибуция без иллюзий last-click
— отказались от «одного победителя» и перешли на сценарный подход: распределяли кредит между касаниями по окнам (например, 7/30/90 дней до SQL и до закрытия), фиксируя uncertainty
— для кампаний считали не только CPA/CPL, но и *expected revenue contribution* (оценочный вклад в выручку) через связывание закрытых сделок с источниками
4) Дашборды для RevOps-ритуалов
— настроили витрины: Top-источники по выручке и по удержанию, разрезы по сегментам компаний, отчётность для sales (где качество лидов лучше) и для customer success (где больше churn-пики)
Конкретный результат (что обычно удаётся подтвердить цифрами в таких проектах):
— улучшили прозрачность: доля лидов с корректно восстановленной связью между привлечением и CRM выросла до уровня, достаточного для принятия решений (в среднем на практике поднимается с «неполных» 60–70% до 90%+ за счёт нормализации ключей и дедупликации)
— изменили управленческие KPI: бюджет начали перераспределять не по MQL-объёму, а по *вероятности закрытия + retention*; в горизонте 1 квартала это даёт заметную коррекцию в миксе источников (обычно компании видят рост доли сделок, прошедших нужные стадии, и более низкий churn в когортах с «качественных» кампаний)
— сократили время на сбор отчётности для встреч RevOps: с ручных выгрузок на «построил один раз — обновляй по расписанию»
Урок для читателя:
Если вы всё ещё оптимизируете маркетинг под воронку без привязки к стадии revenue-циклов и удержанию, BigQuery будет просто хранилищем. Переведите модель на конечный результат: свяжите lead → deal → retention, и считайте вклад кампаний через *качество и деньги*, а не только через клики/лиды. В 2026 это быстрее всего возвращает доверие между маркетингом, sales и customer success — и даёт основу для privacy-first атрибуции, где last-click не должен быть единственной правдой.
— @BigQuery4MarketingPro
This media is not supported in your browser
VIEW IN TELEGRAM
Новую Google reCapcha прошли статичной картинкой
Google выпустил обновленную reCAPTCHA, требующую движений рук для прохождения, но система оказалась уязвима к обходу. Достаточно транслировать статичное изображение с нужным жестом через виртуальную камеру с помощью простого Python-скрипта, чтобы нейросеть пропустила пользователя. Это создает серьёзный риск для сайтов: защита от ботов, позиционировавшаяся как прорыв, на деле не работает. Баг остается актуальным и позволяет спамерам легко автомат…
➡️ Читайте на сайте: https://aff.top/blog/novuiu-google-recapcha-proshli-statichnoi-kartinkoi
🧠 Ещё больше инсайтов → в канале AFF.top
Google выпустил обновленную reCAPTCHA, требующую движений рук для прохождения, но система оказалась уязвима к обходу. Достаточно транслировать статичное изображение с нужным жестом через виртуальную камеру с помощью простого Python-скрипта, чтобы нейросеть пропустила пользователя. Это создает серьёзный риск для сайтов: защита от ботов, позиционировавшаяся как прорыв, на деле не работает. Баг остается актуальным и позволяет спамерам легко автомат…
➡️ Читайте на сайте: https://aff.top/blog/novuiu-google-recapcha-proshli-statichnoi-kartinkoi
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
DeepSeek представит последнюю версию v4
DeepSeek выпустит v4 в середине июля с новой моделью ценообразования API: токены подорожают в 2 раза в часы пиковой нагрузки (09:00–12:00 и 14:00–18:00 по пекинскому времени). Компания планирует уведомлять пользователей по почте за 24 часа до изменения тарифов. Проблема с ошибками «server busy» останется, но обойдётся дороже — это может существенно повлиять на экономику проектов, которые активно используют API DeepSeek для автоматизации и масшта…
➡️ Читайте на сайте: https://aff.top/blog/deepseek-predstavit-posledniuiu-versiiu-v4
🧠 Ещё больше инсайтов → в канале AFF.top
DeepSeek выпустит v4 в середине июля с новой моделью ценообразования API: токены подорожают в 2 раза в часы пиковой нагрузки (09:00–12:00 и 14:00–18:00 по пекинскому времени). Компания планирует уведомлять пользователей по почте за 24 часа до изменения тарифов. Проблема с ошибками «server busy» останется, но обойдётся дороже — это может существенно повлиять на экономику проектов, которые активно используют API DeepSeek для автоматизации и масшта…
➡️ Читайте на сайте: https://aff.top/blog/deepseek-predstavit-posledniuiu-versiiu-v4
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Anthropic выпустили Sonnet 5
30 июня вышла Claude Sonnet 5 — новая версия позиционируется как самая агентная в линейке и приближается к флагманской Opus 4.8. Модель лучше справляется со сложными многоуровневыми задачами, устойчива к вредоносным запросам и не генерирует эксплойты. Sonnet 5 доступна на Free-тарифе, но тестирование показало скромные улучшения: хотя работает лучше Sonnet 4.6, её обгоняют конкуренты, включая китайские модели, которые дешевле через API при лучшей…
➡️ Читайте на сайте: https://aff.top/blog/anthropic-vypustili-sonnet-5
🧠 Ещё больше инсайтов → в канале AFF.top
30 июня вышла Claude Sonnet 5 — новая версия позиционируется как самая агентная в линейке и приближается к флагманской Opus 4.8. Модель лучше справляется со сложными многоуровневыми задачами, устойчива к вредоносным запросам и не генерирует эксплойты. Sonnet 5 доступна на Free-тарифе, но тестирование показало скромные улучшения: хотя работает лучше Sonnet 4.6, её обгоняют конкуренты, включая китайские модели, которые дешевле через API при лучшей…
➡️ Читайте на сайте: https://aff.top/blog/anthropic-vypustili-sonnet-5
🧠 Ещё больше инсайтов → в канале AFF.top
BigQuery для retention-маркетинга: почему событийная схема устарела
Последние полгода я всё чаще вижу одну и ту же ошибку в хранилищах маркетинговых команд. Событийная аналитика в BigQuery построена вокруг таблицы events с полями user_id, event_name, timestamp. В 2020-м этого хватало. Сейчас — нет.
Причина простая. Средний чек в e-com просел на 5–8%, ставка сместилась с первой покупки на удержание и жизненный цикл клиента. А жизненный цикл — это не цепочка событий, это набор состояний: онбординг, активация, привычка, отток, возврат. Событийная модель хранит факт клика, но не хранит контекст состояния. В результате каждый запрос «сколько пользователей в фазе привычки» превращается в пятиэтажный SQL с оконными функциями и костылями.
Что я предлагаю командам, с которыми работаю.
Первый шаг — добавить справочник user_states рядом с events. Ключ user_id, поля state, state_entered_at, state_exited_at, trigger_event. Обновление через MERGE по факту смены состояния. Так вы получаете срез «кто где сейчас» за секунды, а не за минуты.
Второй шаг — выделить таблицу transitions. Каждый переход состояние → состояние с метриками времени, источника, суммы. Это основа для расчёта вероятностей оттока и uplift-моделей (прогнозирования дополнительной конверсии).
Третий шаг — отказаться от BigQuery export из GA4 как единственного источника. Server-side атрибуция через GTM SS (серверный тег-менеджер) и CRM-события должны литься в ту же витрину, что и медийные данные. Иначе MMM (маркетинг-микс моделирование) и инкрементность считаются на неполной картине.
Главный тезис: событийная модель описывает действия, а retention-маркетинг в 2026-м требует описания состояний. Разница между ними — это разница между отчётом «что было» и ответом «что делать дальше».
— @BigQuery4MarketingPro
Последние полгода я всё чаще вижу одну и ту же ошибку в хранилищах маркетинговых команд. Событийная аналитика в BigQuery построена вокруг таблицы events с полями user_id, event_name, timestamp. В 2020-м этого хватало. Сейчас — нет.
Причина простая. Средний чек в e-com просел на 5–8%, ставка сместилась с первой покупки на удержание и жизненный цикл клиента. А жизненный цикл — это не цепочка событий, это набор состояний: онбординг, активация, привычка, отток, возврат. Событийная модель хранит факт клика, но не хранит контекст состояния. В результате каждый запрос «сколько пользователей в фазе привычки» превращается в пятиэтажный SQL с оконными функциями и костылями.
Что я предлагаю командам, с которыми работаю.
Первый шаг — добавить справочник user_states рядом с events. Ключ user_id, поля state, state_entered_at, state_exited_at, trigger_event. Обновление через MERGE по факту смены состояния. Так вы получаете срез «кто где сейчас» за секунды, а не за минуты.
Второй шаг — выделить таблицу transitions. Каждый переход состояние → состояние с метриками времени, источника, суммы. Это основа для расчёта вероятностей оттока и uplift-моделей (прогнозирования дополнительной конверсии).
Третий шаг — отказаться от BigQuery export из GA4 как единственного источника. Server-side атрибуция через GTM SS (серверный тег-менеджер) и CRM-события должны литься в ту же витрину, что и медийные данные. Иначе MMM (маркетинг-микс моделирование) и инкрементность считаются на неполной картине.
Главный тезис: событийная модель описывает действия, а retention-маркетинг в 2026-м требует описания состояний. Разница между ними — это разница между отчётом «что было» и ответом «что делать дальше».
— @BigQuery4MarketingPro
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Clickstar прекращает работу
Clickstar закрывается. Легендарная пуш-сеть прекращает закуп трафика с 1 августа, полная остановка — 20 августа.
Сетка работала почти 8 лет и была одним из лучших источников качественного трафика на Россию и СНГ. Сейчас пуш-трафик стал слишком ботовым из-за гугловских банов на скрипты сбора.
Что это означает для арбитражников — разбираемся в ста…
➡️ Читайте на сайте: https://aff.top/blog/clickstar-prekraschaet-rabotu
🧠 Ещё больше инсайтов → в канале AFF.top
Clickstar закрывается. Легендарная пуш-сеть прекращает закуп трафика с 1 августа, полная остановка — 20 августа.
Сетка работала почти 8 лет и была одним из лучших источников качественного трафика на Россию и СНГ. Сейчас пуш-трафик стал слишком ботовым из-за гугловских банов на скрипты сбора.
Что это означает для арбитражников — разбираемся в ста…
➡️ Читайте на сайте: https://aff.top/blog/clickstar-prekraschaet-rabotu
🧠 Ещё больше инсайтов → в канале AFF.top
BigQuery — это не склад отчетов, а рабочий слой для маркетинга
Миф звучит так: если данные уже лежат в BigQuery, значит аналитика «собрана» и можно просто строить дашборды. Откуда он берётся? Из старой логики: сначала выгрузили CSV, потом свели в Excel, затем перенесли в BI-систему — и кажется, что сама база данных уже решает задачу.
Но это неправда. BigQuery не отвечает на вопрос «что делать маркетингу» — он отвечает на вопрос «где и как надежно хранить данные». Если в модели нет единого определения выручки, канала, лида, повтора покупки или оттока, то любой дашборд будет только красиво показывать разъехавшуюся картину. В 2026 году это особенно заметно: классический last-click (последний клик) слабеет, а без сквозной логики server-side, MMM (маркетинг-микс моделирования) и incrementality (оценки инкрементальности) данные превращаются в набор несвязанных мнений.
**Что вместо этого?** Строить BigQuery как основу для маркетинговой операционной системы:
— единые справочники и правила расчета метрик;
— слои raw / clean / mart, а не «одну волшебную таблицу»;
— проверку качества данных до визуализации;
— модели, которые связывают канал, креатив, аудиторию и выручку.
Тогда BigQuery перестает быть «местом, где лежат цифры», и становится инструментом, который помогает маркетингу спорить не вкусами, а фактами.
— @BigQuery4MarketingPro
Миф звучит так: если данные уже лежат в BigQuery, значит аналитика «собрана» и можно просто строить дашборды. Откуда он берётся? Из старой логики: сначала выгрузили CSV, потом свели в Excel, затем перенесли в BI-систему — и кажется, что сама база данных уже решает задачу.
Но это неправда. BigQuery не отвечает на вопрос «что делать маркетингу» — он отвечает на вопрос «где и как надежно хранить данные». Если в модели нет единого определения выручки, канала, лида, повтора покупки или оттока, то любой дашборд будет только красиво показывать разъехавшуюся картину. В 2026 году это особенно заметно: классический last-click (последний клик) слабеет, а без сквозной логики server-side, MMM (маркетинг-микс моделирования) и incrementality (оценки инкрементальности) данные превращаются в набор несвязанных мнений.
**Что вместо этого?** Строить BigQuery как основу для маркетинговой операционной системы:
— единые справочники и правила расчета метрик;
— слои raw / clean / mart, а не «одну волшебную таблицу»;
— проверку качества данных до визуализации;
— модели, которые связывают канал, креатив, аудиторию и выручку.
Тогда BigQuery перестает быть «местом, где лежат цифры», и становится инструментом, который помогает маркетингу спорить не вкусами, а фактами.
— @BigQuery4MarketingPro
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Facebook запретил рекламу онлайн-казино Mr Vegas
Британский ASA запретил рекламу казино Mr Vegas из-за «слишком милых» мультяшных животных в креативах — регулятор счёл, что такой стиль привлекает детей, в том числе через Facebook. Рекламодатель запустил кампанию в феврале, бан вышел в июле. Логика регулятора вызывает вопросы: дети неплатёжеспособны, а таргетировать их на гемблинг бессмысленно.
➡️ Читайте на сайте: https://aff.top/blog/facebook-zapretil-reklamu-onlain-kazino-mr-vegas
🧠 Ещё больше инсайтов → в канале AFF.top
Британский ASA запретил рекламу казино Mr Vegas из-за «слишком милых» мультяшных животных в креативах — регулятор счёл, что такой стиль привлекает детей, в том числе через Facebook. Рекламодатель запустил кампанию в феврале, бан вышел в июле. Логика регулятора вызывает вопросы: дети неплатёжеспособны, а таргетировать их на гемблинг бессмысленно.
➡️ Читайте на сайте: https://aff.top/blog/facebook-zapretil-reklamu-onlain-kazino-mr-vegas
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
В Whatsapp скамят пользователей с помощью поддельных никнеймов
WhatsApp запустил никнеймы — и почти сразу начался скам. Мошенники регистрируют имена, похожие на бренды, звёзд и политиков, с минимальными опечатками.
Индия, где 500 млн пользователей WhatsApp, потребовала от Meta объяснений за 3 дня. Meta говорит, что точные совпадения заблокированы — но одна буква в другом месте защиту не триггерит.
Похоже, п…
➡️ Читайте на сайте: https://aff.top/blog/v-whatsapp-skamiat-polzovatelei-s-pomoschiu-poddelnykh-nikneimov
🧠 Ещё больше инсайтов → в канале AFF.top
WhatsApp запустил никнеймы — и почти сразу начался скам. Мошенники регистрируют имена, похожие на бренды, звёзд и политиков, с минимальными опечатками.
Индия, где 500 млн пользователей WhatsApp, потребовала от Meta объяснений за 3 дня. Meta говорит, что точные совпадения заблокированы — но одна буква в другом месте защиту не триггерит.
Похоже, п…
➡️ Читайте на сайте: https://aff.top/blog/v-whatsapp-skamiat-polzovatelei-s-pomoschiu-poddelnykh-nikneimov
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Вышел ZCode - аналог Claude code
Вышел ZCode — десктопный аналог Claude Code от разработчиков GLM-5.2. Работает с API от Anthropic, поддерживает SSH-деплой на сервер, в том числе Linux.
Вместо пошаговых скриптов — система целеполагания Goal: закидываешь сложный промт, агент сам разбивает задачу и выполняет. Плюс управление через Telegram-бота.
Но главная фича — мультиагентность…
➡️ Читайте на сайте: https://aff.top/blog/vyshel-zcode-analog-claude-code
🧠 Ещё больше инсайтов → в канале AFF.top
Вышел ZCode — десктопный аналог Claude Code от разработчиков GLM-5.2. Работает с API от Anthropic, поддерживает SSH-деплой на сервер, в том числе Linux.
Вместо пошаговых скриптов — система целеполагания Goal: закидываешь сложный промт, агент сам разбивает задачу и выполняет. Плюс управление через Telegram-бота.
Но главная фича — мультиагентность…
➡️ Читайте на сайте: https://aff.top/blog/vyshel-zcode-analog-claude-code
🧠 Ещё больше инсайтов → в канале AFF.top