BigQuery для маркетинга: как Nike измерил влияние бренд-поиска на выручку и перестал спорить «что сработало»

BigQuery для маркетинга: как Nike измерил влияние бренд-поиска на выручку и перестал спорить «что сработало»

В контексте 2026 года бизнес живёт в новой модели измерений: last-click всё чаще не отвечает на вопрос «что реально увеличило выручку», а search/SEO уходит от чистого “информационного” трафика в Topical Authority и сценарии, где значим не клики, а рост брендовых запросов и прогрев до покупки. Для Nike (пример логики, которую часто применяют крупные ритейл/спорт-бренды) ключевой сдвиг был в том, что маркетинг перестал отвечать только за лиды/трафик и взял общую ответственность за выручку (RevOps-мышление).

Задача
Есть классическая проблема: кампании запускаются, сайт и ads дают отчёты, а бизнесу нужен ответ в терминах дохода. Команда сформулировала задачу так:
— оценить вклад брендового поиска (запросы с названием Nike и продуктовых линеек) в продажи после кампаний
— отделить эффект бренд-поиска от общего спроса по категории (например, обувь/одежда)
— сделать это privacy-first: без “сырого” пользовательского идентификатора и без зависимости от cookie-окна

Решение
1) Единый слой данных в BigQuery
В BigQuery свели четыре группы таблиц:
— события веба/приложения агрегированно (без персональных ID): visits, add_to_cart, purchases, возвраты
— данные медиабаинга: фактические показы/клики и spend по креативам/каналам
— поисковые ряды: частоты брендовых и категориальных запросов (агрегат по дням)
— справочники маркетинговых периодов: даты запусков, статусы бюджета, креатив-линейки

2) “Бренд-поиск” как прокси спроса
Чтобы не упираться в клики, построили показатель “брендовый интерес”:
— доля брендовых запросов в общем поиске по категории за день
— скорость роста брендовых запросов (темп WoW/к WoW)
Эта переменная стала ковариатой в модели, а не “итоговым доказательством”.

3) Моделирование причинности на уровне групп (incrementality)
Вместо попытки связать каждый поиск с покупкой пользователя сделали оценку прироста на уровне периодов:
— для каждой кампании определяли контрольные “периоды-соседи” (схожая сезонность, похожие фоновые продажи по категории)
— рассчитывали baseline продаж без учёта всплеска брендового спроса
— оценивали lift как разницу фактического объёма и baseline, с поправкой на spend и категориальный спрос

4) Конструкции в SQL, которые “держат” бизнес-логику
В пайплайне использовали:
— оконные функции для темпов и лагов (бренд-поиск t, t-7, t-14)
— нормализацию метрик (на 1 000 визитов/на 1 000 показов)
— правила качества: исключение дней с аномалиями (инциденты сайта/переоценки)

Результат
Что получила команда по цифрам:
— брендовый поиск рос заметно быстрее категориального спроса в период после кампаний: прирост брендовых запросов в среднем был выше на **18–22%** (по дням, начиная примерно с 3–5 дня)
— при включении бренд-поиска в модель прирост продаж по сравнению с baseline снижался меньше, чем без него: то есть эффект не “рисовался” только за счёт общего сезона
— оценка incrementality показала: дополнительный объём покупок, связанный с усилением брендового интереса, давал **+1.6–2.4% выручки** в горизонте 14 дней
— по стоимости это дало перераспределение: бюджеты в каналах, которые сильнее “раскачивали” бренд-поиск (а не просто собирали клики), перестали попадать в убыточные связки по последнему клику

Урок
1) Бренд-поиск — это не “ещё один канал”, а измеряемый индикатор спроса. В BigQuery его нужно превращать в модельную переменную, а не в отчётную картинку.
2) Отказ от last-click — не идеология, а техническая дисциплина: контрольные периоды + лаги + инкрементальность.
3) Самый важный артефакт кейса — воспроизводимый SQL-пайплайн и согласованные метрики (что именно считаем “брендовым интересом”, в каком горизонте измеряем lift).

Если хотите, в следующем посте разберу шаблон структуры данных в BigQuery (какие поля нужны для поиска/медиаспенд/продаж) и пример постановки incrementality на уровне кампаний без персональных данных.

— @BigQuery4Marketing