Сегменты и аудитории в programmatic: от CSV до поведения

Кампания может показываться только заранее заданному кругу людей или, наоборот, обходить его стороной. Такой круг называют аудиторным сегментом. В programmatic его собирают двумя путями: загружают готовый список идентификаторов (CSV с GAID, OAID или ID клиентов) либо вычисляют по правилам из накопленных данных, например «установлено приложение X, впервые замечено больше 7 дней назад». На ставке DSP проверяет одно: входит ли профиль в множество.

#Какие бывают аудитории

Контекстный таргетинг (по площадке, категории приложения) аудиторией не является: он отбирает место показа, а не человека.

#CSV-аудитории: загрузка и совпадение

Самый понятный способ — загрузить файл с идентификаторами по одному в строке:

gaid
3f1c2a9e-7b44-4c1d-9a0e-2b7d5c8e1f00
a9e2b6d1-0c3f-4e8a-b5d7-91f2e4c6a8b3
...

#Нормализация — половина успеха

Идентификатор из файла должен совпасть побайтно с тем, что приходит в запросе на ставку. Типичные расхождения:

Непрозрачные ID клиентов (user_id) приводить к нижнему регистру нельзя: для них AB12 и ab12 могут быть разными людьми.

#Почему совпадает не весь список

Доля совпадения (match rate) — какая часть списка нашлась среди известных платформе профилей. Она почти никогда не близка к 100%.

Пример (иллюстративный). Загружено 100 000 GAID. 8 000 строк отброшены как мусор (пустые, нулевые, битые). Из 92 000 корректных 58 000 устройств встречались в трафике за последние месяцы. Match rate — 63% от корректных строк. Остальные устройства не появлялись у подключенных SSP, сбросили ID или ограничили трекинг.

Совпадение выше, если граф связывает разные идентификаторы одного человека. Тогда файл с OAID найдет и профиль, который сейчас приходит под GAID. Подробнее — в статье про identity-граф.

#Можно ли обойтись без identity-графа

Можно, но с оговорками. Без графа членство привязывают прямо к сырому идентификатору: строка gaid:3f1c… в списке, и на ставке проверяется тот ID, что пришел в запросе. Для одного типа ID и короткой кампании этого хватает. Потери начинаются в трех местах: пользователь сбросил рекламный ID и выпал из аудитории; устройство приходит под OAID, а в файле только GAID; у площадки есть только свой user.id.

Если графа нет, помогают три приема. Выгружать из CRM или MMP все типы идентификаторов, которые есть, и грузить их отдельными списками с указанием типа. Перезагружать файл регулярно, а не один раз на старте, чтобы подхватывать новые ID после сбросов. Закладывать в медиаплан match rate ниже, чем с графом, и не оценивать аудиторию по числу строк в файле.

#Поведенческие сегменты: правила вместо списков

Поведенческий сегмент описывается правилом над наблюдениями. В мобильной рекламе самое богатое наблюдение — установленные приложения с датами первого и последнего появления в запросах. Из них строятся четыре базовых временных условия:

Условия объединяются булевыми операторами: «все из» (all_of), «хотя бы одно из» (any_of), «ни одного из» (none_of). Группы можно вкладывать друг в друга.

{
  "any_of": [
    { "has_bundle": "ru.loan.alpha", "first_seen_within_days": 7 },
    { "has_bundle": "ru.loan.beta",  "first_seen_within_days": 7 }
  ],
  "none_of": [
    { "has_bundle": "ru.our.bank" }
  ]
}

Это правило читается так: «за последнюю неделю установил одно из двух приложений микрозаймов и при этом не пользуется нашим банком».

#Почему сегмент считается заранее

На ответ SSP у DSP обычно 100–300 мс (tmax), и выполнить аналитический запрос по истории миллионов устройств на каждую ставку невозможно. Поэтому сегмент материализуют: по расписанию вычисляют полный список членов и кладут его в быстрое хранилище. На ставке остается проверка «входит ли профиль в множество» — микросекунды.

У такого подхода две особенности:

• Задержка. Человек, установивший приложение пять минут назад, попадет в сегмент только при следующем пересчете.
• Предохранитель размера. Ошибка в правиле (например, забытое none_of) может превратить сегмент во «всю базу». Разумно ограничивать максимальный размер и останавливать материализацию при его превышении.

#Как часто пересчитывать

Интервал пересчета — компромисс между свежестью и нагрузкой на аналитическую базу.

Частый пересчет широкого сегмента дорог и ничего не дает. Редкий пересчет узкого «горячего» сегмента делает его бесполезным: к моменту попадания в сегмент человек уже сделал выбор.

#Сегмент в кампании: включение, исключение, охват

Сегмент используется двумя способами:

• include — показывать только членам сегмента;
• exclude — не показывать членам сегмента (текущим клиентам, уже конвертировавшимся).

Охват кампании с сегментом считается как цепочка сужений, и каждое условие таргетинга его умножает:

Пример (иллюстративный). Цифры условны, но порядок типичен: сегмент на 400 тысяч дает реальный охват в десятки тысяч. Узкий сегмент плюс узкое гео плюс низкая ставка — частая причина того, что кампания «не крутится».

#CSV или поведенческий сегмент: что выбрать

На практике их комбинируют: поведенческий сегмент «интересуется займами» в include и CSV текущих клиентов в exclude.

#Частые ошибки с сегментами

• Слишком узкое пересечение. Каждое условие all_of умножает охват на долю, и три условия по 20% оставляют меньше 1% исходной базы.
• Устаревший CSV. Список клиентов полугодовой давности исключает тех, кто давно ушел, и пропускает новых.
• Сегмент без исключения конвертировавшихся. Бюджет продолжает уходить на тех, кто уже установил приложение или купил.
• Окно наблюдения короче окна правила. Условие «впервые замечено 90 дней назад» бессмысленно, если история наблюдений хранится меньше.
• Оценка по CTR вместо эксперимента. Высокий CTR сегмента часто объясняется тем, кто в него попал, а не тем, что показ на него что-то изменил.

#Как проверить, что сегмент работает

Высокий CTR кампании на сегменте сам по себе ничего не доказывает: в сегмент могли попасть люди, которые кликнули бы и без него. Честная проверка — эксперимент. Часть сегмента случайно отводится в контрольную группу без показов (holdout) или с нейтральной рекламой, и результаты групп сравниваются. Как правильно делить пользователей и считать значимость, описано в статье про A/B-тесты в рекламе.

#Сегменты и аудитории в Ibiza

В Ibiza есть оба вида множеств. Подробная инструкция — в разделе аудитории.

CSV-аудитории. Файл загружается с указанием типа идентификатора: GAID, OAID или user_id. Обработка идет фоновой задачей. Рекламные UUID приводятся к нижнему регистру, лишние столбцы после разделителя отбрасываются, заголовок распознается. Каждый ID сопоставляется с внутренним профилем через identity-граф, а метка аудитории ставится и на профиль, и на исходный ID — для устройств, которые граф еще не знает. Статус задачи честный: если часть пакетов не записалась, аудитория получает статус «ошибка», а не «обработана», и ее можно перезапустить. Выгрузить исходный файл может только администратор платформы, и каждая выгрузка пишется в журнал аудита.

Поведенческие сегменты. Правила строятся из условий по установленным приложениям: has_bundle с четырьмя временными ограничениями и вложенными all_of/any_of/none_of. Один и тот же компилятор правил превращает их в запрос к аналитической базе — и для кнопки «Посчитать размер», и для периодической материализации. Поэтому оценка размера не расходится с тем, на кого реально идут показы. Для каждого сегмента задается интервал пересчета, а в интерфейсе видны последний размер, время пересчета, статус и ошибка. Материализация прерывается, если сегмент разрастается сверх предела. Сегмент принадлежит рабочему пространству и может быть открыт для других как публичный. Таргетинг ссылается на сегмент по ID, поэтому переименование ничего не ломает.