Data-driven маркетинг (маркетинг, управляемый данными) — это подход, при котором решения о каналах, бюджете, предложении и коммуникации принимаются по измеренным данным о клиентах и продажах, а не по интуиции или привычке. Ключевое слово — «решения»: собрать отчеты недостаточно, нужен цикл «вопрос -> метрика -> данные -> проверка гипотезы -> решение -> контроль результата».
Содержание
Тот же подход в управлении компанией в целом называют data-driven менеджментом. Маркетинг — одна из его областей, и часто первая, где его внедряют: рекламные расходы легко измерить. Ниже — какие данные собирают, какие метрики считают, чем пользуются и как выглядит один цикл решения от вопроса до вывода, с расчетом на Python.
Термины, которые путают
| Термин | Что означает | Чем отличается |
|---|---|---|
| Data-driven | Данные — основной аргумент решения | Если данные против мнения руководителя, решает измерение |
| Data-informed | Данные — один из аргументов наряду с опытом, стратегией, этикой | Данные информируют, но не определяют решение |
| Сквозная аналитика | Связка «рекламный контакт -> визит -> заявка -> оплата» в одной системе | Это инструмент сбора данных, а не сам подход |
| Big Data | Данные такого объема и скорости, что обычными средствами их не обработать | Для data-driven маркетинга не обязательна: малому бизнесу хватает таблицы и CRM |
Граница между data-driven и data-informed условная: это не стандарт, а два акцента. На практике зрелые команды совмещают их — измеряют все, что можно измерить, и явно называют решения, которые принимают без данных (например, позиционирование бренда).
Какие данные собирают
- Поведение на сайте и в приложении: визиты, источники трафика, просмотренные страницы, цели (заявка, добавление в корзину, оплата).
- Рекламные расходы и показатели кампаний: показы, клики, стоимость по каждому каналу и объявлению.
- Продажи из CRM и учетной системы: заказы, выручка, себестоимость и маржа, отмены и возвраты.
- Данные о клиенте: повторные покупки, срок жизни, обращения в поддержку, результаты опросов (NPS, CSAT).
- Внешние данные: сезонность, цены конкурентов, спрос в поисковых системах.
Самая частая проблема — не нехватка данных, а их несклеенность: визит живет в системе веб-аналитики, оплата — в CRM, себестоимость — в учетной системе. Пока эти источники не связаны общим идентификатором (номер заявки, client ID, телефон в защищенном виде), считать окупаемость канала можно только приблизительно.
Персональные данные клиентов в России обрабатываются по 152-ФЗ «О персональных данных»: нужны законное основание (обычно согласие), политика обработки и защита хранилища. Для аналитики каналов почти всегда хватает агрегатов и псевдонимизированных идентификаторов — сырые телефоны и email в отчетах не нужны.
Метрики data-driven маркетинга
| Метрика | Формула | Что показывает |
|---|---|---|
| CR (конверсия) | целевые действия / визиты | Доля посетителей, совершивших действие |
| CPA | расходы / целевые действия | Цена одного действия (заявки, заказа) |
| CAC | расходы на привлечение / новые клиенты | Цена нового клиента, а не любого заказа |
| ROAS | выручка / расходы | Сколько выручки приносит рубль рекламы |
| ROMI | (прибыль от канала — расходы) / расходы | Окупаемость с учетом маржи |
| ДРР | расходы / выручка | Доля рекламных расходов в выручке |
| LTV | валовая прибыль от клиента за все время | Сколько клиент приносит за «жизнь» |
| Retention / Churn | доля клиентов, оставшихся / ушедших за период | Удержание и отток |
Две оговорки. Первая: аббревиатура CRR в русскоязычных материалах означает то customer retention rate (удержание), то cost revenue ratio (то же, что ДРР), поэтому в отчетах лучше писать формулу рядом с названием. Вторая: ROMI часто считают по выручке, а не по прибыли, и получают завышенную окупаемость. Разница видна на примере ниже.
Инструменты: задача -> что взять
| Задача | Примеры инструментов | Когда иначе |
|---|---|---|
| Поведение на сайте | Яндекс Метрика, Google Analytics 4 | Для мобильных приложений — AppMetrica, Firebase |
| Сквозная аналитика | Roistat, Calltouch, CoMagic | При своей разработке — выгрузки из систем в собственное хранилище |
| Заказы и клиенты | CRM: Битрикс24, amoCRM | В B2B и дистрибуции часто основной источник — учетная система (1С) |
| Хранение и расчет | SQL: ClickHouse, PostgreSQL; Python (pandas) | На старте хватает таблицы, если данных до десятков тысяч строк |
| Дашборды | Yandex DataLens, Power BI, Looker Studio, Apache Superset | Выбор зависит от источников данных и политики компании |
Универсального набора нет: инструмент выбирают под вопрос и источники данных. Google Universal Analytics прекратил обработку данных 1 июля 2023 года (платная версия 360 — 1 июля 2024-го, тогда же закрыли доступ к старым отчетам) — в старых статьях он встречается, но для новых проектов это GA4, а сервис Google Data Studio переименован в Looker Studio.
Пример цикла решения на данных
Вопрос маркетолога: «В какой канал перераспределить бюджет в следующем месяце?» Метрики: CR, CPA и ROMI, причем ROMI в двух вариантах — по выручке и по валовой прибыли. Данные учебные, за месяц, маржа принята 30%.
import math
GROSS_MARGIN = 0.30 # доля валовой прибыли в выручке (учебное допущение)
# Учебные данные за месяц: расходы в рублях, визиты, заказы, выручка
channels = {
"search": {"spend": 300_000, "visits": 12_000, "orders": 240, "revenue": 1_200_000},
"social": {"spend": 256_000, "visits": 20_000, "orders": 160, "revenue": 640_000},
"email": {"spend": 20_000, "visits": 3_000, "orders": 90, "revenue": 450_000},
"display": {"spend": 150_000, "visits": 9_000, "orders": 0, "revenue": 0},
}
def check(d):
for key in ("spend", "visits", "orders", "revenue"):
v = d.get(key)
if isinstance(v, bool) or not isinstance(v, (int, float)) or not math.isfinite(v) or v < 0:
raise ValueError(f"{key}: нужно конечное неотрицательное число, получено {v!r}")
if d["orders"] > d["visits"]:
raise ValueError("заказов больше, чем визитов: проверьте склейку данных")
def metrics(d):
check(d)
cr = d["orders"] / d["visits"] if d["visits"] else None
cpa = d["spend"] / d["orders"] if d["orders"] else None
if not d["spend"]:
return cr, cpa, None, None
romi_rev = (d["revenue"] - d["spend"]) / d["spend"]
romi_gp = (d["revenue"] * GROSS_MARGIN - d["spend"]) / d["spend"]
return cr, cpa, romi_rev, romi_gp
def fmt(x, pattern):
return "н/д" if x is None else pattern.format(x).replace(",", " ")
print(f"{'канал':<8} {'CR':>6} {'CPA':>7} {'ROMI выр.':>10} {'ROMI приб.':>11}")
for name, d in channels.items():
cr, cpa, rr, rg = metrics(d)
print(f"{name:<8} {fmt(cr, '{:.1%}'):>6} {fmt(cpa, '{:,.0f}'):>7} "
f"{fmt(rr, '{:.0%}'):>10} {fmt(rg, '{:.0%}'):>11}")
Результат (Python 3.14):
канал CR CPA ROMI выр. ROMI приб.
search 2.0% 1 250 300% 20%
social 0.8% 1 600 150% -25%
email 3.0% 222 2150% 575%
display 0.0% н/д -100% -100%
Как читать таблицу. По выручке социальные сети выглядят прибыльными (ROMI 150%), а по прибыли канал убыточен: каждый вложенный рубль возвращает 75 копеек валовой прибыли. Медийная реклама за месяц не дала ни одного заказа, но это еще не приговор: такой канал может работать на узнаваемость, и его оценивают по другим метрикам или через эксперимент с отключением.
Функция check отсекает мусор до расчета — строку вместо числа, NaN, больше заказов, чем визитов:
ValueError: visits: нужно конечное неотрицательное число, получено '12000'
ValueError: visits: нужно конечное неотрицательное число, получено nan
ValueError: заказов больше, чем визитов: проверьте склейку данных
Граница примера: ROMI здесь считается по модели атрибуции «последний канал», когда весь заказ приписан последнему источнику. Если клиент сначала увидел рекламу в соцсетях, а купил после письма, email получит всю заслугу. Поэтому вывод «урезать social» — гипотеза, которую стоит проверить экспериментом, а не готовое решение.
Проверка гипотезы A/B-тестом
Следующий шаг цикла: команда меняет тему письма и сравнивает два варианта. Вариант A получил 30 заказов на 1000 писем, вариант B — 42 заказа на 1000. Рост на 40% выглядит убедительно, но сначала нужна проверка значимости.
from statistics import NormalDist
def ab_test(conv_a, n_a, conv_b, n_b):
"""Двусторонний z-тест для двух долей (нормальное приближение)."""
for v in (conv_a, n_a, conv_b, n_b):
if isinstance(v, bool) or not isinstance(v, int) or v < 0:
raise ValueError(f"нужно целое неотрицательное число, получено {v!r}")
if n_a == 0 or n_b == 0 or conv_a > n_a or conv_b > n_b:
raise ValueError("пустая группа или конверсий больше, чем участников")
p_a, p_b = conv_a / n_a, conv_b / n_b
pooled = (conv_a + conv_b) / (n_a + n_b)
se = (pooled * (1 - pooled) * (1 / n_a + 1 / n_b)) ** 0.5
if se == 0:
raise ValueError("нет вариации: в обеих группах 0% или 100% конверсий")
z = (p_b - p_a) / se
p_value = 2 * (1 - NormalDist().cdf(abs(z)))
return p_a, p_b, z, p_value
def sample_size(p_base, p_target, alpha=0.05, power=0.8):
"""Сколько участников нужно в КАЖДОЙ группе, чтобы заметить разницу."""
for v in (p_base, p_target):
if isinstance(v, bool) or not isinstance(v, (int, float)) or not 0 < v < 1:
raise ValueError(f"конверсия должна быть долей от 0 до 1, получено {v!r}")
if p_base == p_target:
raise ValueError("ожидаемый эффект нулевой: выборку рассчитать нельзя")
z_a = NormalDist().inv_cdf(1 - alpha / 2)
z_b = NormalDist().inv_cdf(power)
p_bar = (p_base + p_target) / 2
num = (z_a * (2 * p_bar * (1 - p_bar)) ** 0.5
+ z_b * (p_base * (1 - p_base) + p_target * (1 - p_target)) ** 0.5) ** 2
return int(-(-num // (p_target - p_base) ** 2)) # округление вверх
p_a, p_b, z, p = ab_test(30, 1000, 42, 1000)
print(f"A: {p_a:.1%} B: {p_b:.1%} рост: {p_b / p_a - 1:+.0%}")
print(f"z = {z:.2f}, p-value = {p:.3f}")
print("нужно в каждой группе:", sample_size(0.03, 0.042))
A: 3.0% B: 4.2% рост: +40%
z = 1.44, p-value = 0.150
нужно в каждой группе: 3782
Неверный вывод: «вариант B лучше на 40%, переключаем всю рассылку». Фактический результат: p-value 0.15 при принятом пороге 0.05, то есть такая разница легко получается случайно. Исправление: заранее рассчитать размер выборки (около 3800 писем на группу, чтобы с вероятностью 80% заметить рост с 3,0% до 4,2%), дождаться его и только потом решать. Z-тест здесь — приближение, оно работает при достаточном числе конверсий в каждой группе; для совсем малых чисел используют точный тест Фишера.
Решение и контроль
Итог цикла — не «истина», а решение с условием пересмотра: например, снизить бюджет social на 30%, запустить тест с отключением медийной рекламы в части регионов, через месяц сравнить общие продажи, а не только метрики канала. Если продажи не просели, гипотеза подтвердилась; если просели — канал работал на вход в воронку, и его возвращают.
Data-driven в B2B и дистрибуции
В B2B и дистрибуции тот же цикл применяют не только к рекламе, но и к ассортименту, скидкам и работе с клиентами. Когда маржинальность снижается, решения по выручке становятся опасными: оборот растет, а прибыль падает. Поэтому здесь особенно важно считать маржу по клиенту, SKU и каналу, как в колонке «ROMI приб.» выше, а не только объем продаж.
Переход к data-driven управлению в таких компаниях обычно начинается с автоматизации учета и связи данных: учетная система, CRM и отчетность должны описывать одни и те же сделки. Без этого аналитик тратит основное время на сверку выгрузок, а не на решения.
Если не получилось
- Цифры заказов в веб-аналитике и CRM расходятся. Это нормально в пределах нескольких процентов (блокировщики, заказы по телефону). При большом расхождении проверить, срабатывает ли цель, передается ли идентификатор заявки и нет ли дублей.
- ROMI отрицательный у всех каналов. Проверить, какая маржа и какой период подставлены: у товаров с повторными покупками окупаемость первого заказа занижена, нужен LTV.
- A/B-тесты никогда не значимы. Выборка мала для ожидаемого эффекта — считать размер выборки до запуска или тестировать более крупные изменения.
- Метрика растет, а бизнес нет. Команда оптимизирует промежуточную метрику (клики, заявки) вместо конечной (оплаты, прибыль). Нужно поднять цель на уровень выше по воронке.
Выводы
- Data-driven маркетинг — это цикл решений на данных: вопрос, метрика, данные, проверка гипотезы, решение и контроль, а не набор отчетов.
- Главное препятствие — не объем данных, а их несклеенность: рекламные расходы, визиты, оплаты и себестоимость должны связываться общим идентификатором.
- ROMI по выручке может показывать прибыль там, где канал убыточен; решения о бюджете принимают по марже.
- Разница в конверсии без проверки значимости и расчета выборки — еще не результат.
- Атрибуция «последний канал» недооценивает каналы верха воронки; спорные выводы проверяют экспериментом.
Где применяется / связь с практикой
Освойте тему на практике
Навыки из этой статьи — формулировать вопрос бизнеса, выбирать метрику, собирать и проверять данные, проводить A/B-тесты и доводить анализ до решения — нужны маркетологам, продуктовым менеджерам и аналитикам. Системно их разбирают на курсе «Принятие решений на основе данных / Data-driven». Чтобы познакомиться с темой и преподавателями до выбора программы, можно посетить открытые уроки Otus.
FAQ
Нужен ли data-driven подход малому бизнесу?
Да, но в облегченной форме: веб-аналитика, CRM и таблица с расходами и продажами по каналам. Хранилище и BI-система окупаются, когда источников и данных становится больше, чем удобно сводить вручную.
Можно ли быть data-driven без программирования?
Базовые расчеты делаются в таблицах и интерфейсах систем аналитики. SQL и Python нужны, когда данных много, источники надо объединять или расчеты повторяются регулярно.
Чем data-driven маркетинг отличается от performance-маркетинга?
Performance-маркетинг — это рекламные каналы с оплатой и оценкой за измеримый результат (клик, заявка). Data-driven — способ принимать решения, который применяют и к performance-каналам, и к бренду, ассортименту, цене и удержанию.



