Data-driven маркетинг: что это, особенности и применение на практике

Data-driven маркетинг: что это, особенности и применение на практике Полезное

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-каналам, и к бренду, ассортименту, цене и удержанию.

OTUS Журнал