Таргетинг по установленным приложениям: как работает и зачем

Список приложений, установленных на телефоне, часто приходит прямо в рекламном запросе (поле iApp), и по нему можно отбирать показы: «показывать тем, у кого есть хотя бы одно из приложений X, Y, Z» или «не показывать тем, у кого уже стоит наше». Это один из самых сильных сигналов интереса в мобильной рекламе, и он доступен без cookie и внешних данных.

#Почему установленные приложения — сильный сигнал

Установка требует усилия: человек нашел приложение, скачал его и не удалил. Поэтому набор приложений на телефоне честнее описывает интересы, чем один просмотр страницы.

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

#Где список лежит в запросе

Ни в OpenRTB 2.5, ни в 2.6 стандартного поля для установленных приложений нет, поэтому SSP передают список по-разному:

{
  "app": { "bundle": "ru.example.news" },
  "device": {
    "os": "android",
    "ext": { "iapp": ["ru.bank.mobile", "com.game.puzzle", "ru.market.app"] }
  }
}

Элементы списка — bundle ID приложений, такие же, как в app.bundle площадки. Все четыре формы — договоренности конкретных SSP: объекты ext и user.data в спецификации есть, а их наполнение для установленных приложений не стандартизовано. Поэтому формат стоит уточнять при подключении каждого источника.

Важно. Поле bapp (blocked apps) в OpenRTB означает приложения, рекламу которых нельзя показывать на площадке. Это не установленные приложения. Некоторые SSP исторически клали в bapp установленные приложения, и если принять одно за другое, таргетинг отберет не тех людей.

#Как устроены правила таргетинга

Правило — это множество bundle ID и оператор сравнения со списком из запроса:

Правила применимы только к in-app трафику. На web-запросах списка нет, и правило там не должно отсекать показ. Иначе include-правило молча обнулит весь web.

#Отсутствие списка — не «пустой телефон»

Большинство запросов списка не несут: SSP его не передает, или пользователь ограничил трекинг. Включающее правило (include) такие запросы отсечет — и это правильно, ведь подтвердить интерес нечем. Исключающее правило (exclude) их пропустит: доказать, что приложение уже стоит, тоже нечем. Отсюда следствие для медиапланирования. Кампания с include-правилом по iApp физически не может закупать трафик источников без iApp, и ее охват ограничен долей таких запросов.

#Как прикинуть охват заранее

Охват include-правила — произведение трех долей: запросов со списком, запросов из нужного гео и с нужной ОС, устройств, где есть хотя бы одно приложение из списка.

Пример (иллюстративный). Источник присылает 10 млн запросов в сутки. Список iApp есть в 40% из них — 4 млн. После гео и ОС остается 1,5 млн. Хотя бы одно из 12 приложений конкурентов установлено на 6% этих устройств — 90 тысяч запросов в сутки. При win rate 20% это около 18 тысяч показов, и именно столько кампания может купить, сколько бы ни стоил бюджет.

Если охвата не хватает, расширяют список приложений или переходят к сегменту с более мягкими временными условиями, а не поднимают ставку: ставка не создаст запросов, которых нет.

#Шум: приложения, которые «установлены у всех»

Список формирует SDK или площадка, и иногда в нем оказываются приложения, которые на самом деле не установлены: системные, предустановленные производителем или вставленные самой площадкой. Признак шума — неправдоподобная концентрация. Реальное приложение не стоит почти на каждом устройстве сети, а «шаблонное» — стоит.

Пример (иллюстративный). В сети 100 000 устройств. Bundle com.vendor.store встречается в списке у 97 000, а самое популярное из реальных приложений — у 31 000. Первое — шаблон источника, а не интерес, и для таргетинга его нужно убрать.

Чистить шум лучше по каждой сети отдельно: у разных SSP разные шаблоны. Для расчета частот при этом нужен сырой, неочищенный поток наблюдений, иначе детектор шума перестанет видеть собственный вход.

#Аффинити и CTR по приложениям

Кроме прямого таргетинга, список полезен как аналитика: какие установленные приложения отличают тех, кто кликает и конвертирует.

Аффинити (lift) приложения A для кампании:

lift(A) = CTR среди показов, где A установлено / CTR кампании в целом

Пример (иллюстративный). Кампания: 2 000 000 показов, 10 000 кликов, CTR 0,50%. Среди показов, где установлено приложение A, — 40 000 показов и 400 кликов, CTR 1,00%. Lift = 2,0: у владельцев A кликабельность вдвое выше. Если у приложения B 600 показов и 6 кликов (тоже 1,00%), выводов делать нельзя: при таком объеме разница укладывается в случайность.

Малые выборки — главная ловушка. Корректный прием — сглаживание к среднему (эмпирический Байес): CTR приложения с малым числом показов «подтягивается» к CTR кампании тем сильнее, чем меньше данных:

CTR_сглаж = (клики + p0 · k) / (показы + k)

Здесь p0 — общий CTR кампании, k — сила априорного знания, выраженная в показах. Для приложения B при k = 1000 получаем (6 + 5) / (600 + 1000) ≈ 0,69% — вместо громких 1,00%.

Из аналитики получается практический цикл: найти приложения с устойчиво высоким lift, собрать из них include-правило или поведенческий сегмент, затем проверить эффект A/B-тестом, а не сравнением «до и после».

#Типовые правила для разных задач

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

• Список из одного-двух приложений. Охват падает до доли устройств с этими приложениями среди запросов, где список вообще есть, а это может быть совсем немного.
• Таргетинг по bapp вместо iApp. Отбирает площадки по их запретам, а не людей по интересам.
• Забытое исключение собственного приложения в кампании на установку.
• Выводы по lift на сотнях показов. Без сглаживания самые «аффинные» приложения почти всегда оказываются самыми редкими.

#Список приложений как признак ML-модели

Для модели кликабельности список превращается в вектор «интересов устройства», который сопоставляется с рекламируемым приложением. Отдельно полезен бинарный признак «продвигаемое приложение уже установлено». Как такой мультизначный признак кодируют, разобрано в статье о том, как машинное обучение предсказывает CTR.

#Приватность: что учитывать

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

• Уважать ограничения трекинга. При LMT, DNT, COPPA или отсутствии согласия по GDPR идентификаторы из запроса удаляются. Список тогда нельзя привязать к человеку и накапливать в профиле.
• Хранить наблюдения, а не сырые запросы. Для сегментов достаточно пар «профиль — приложение» с датами первого и последнего наблюдения.
• Ограничивать срок хранения и доступ к выгрузкам списков устройств.
• Не строить таргетинги на чувствительных категориях, даже если технически это возможно.

Важно. Требования к обработке таких данных зависят от юрисдикции и договора с поставщиком трафика. Это не юридическая консультация.

#Таргетинг по приложениям в Ibiza

DSP Ibiza считает установленными только списки iApp; поле bapp используется в стандартном смысле OpenRTB. Список ищется в device.ext.iapp/iapps, затем в вариантах написания и форматах в device.ext, корневом ext и app.ext (строки или объекты с полем bundle), затем в user.data с сегментом installed_app. Отдельный ежесуточный процесс по каждой сети находит «шаблонные» bundle, которые встречаются на неправдоподобно большой доле устройств, и они не участвуют в таргетинге.

Правило по установленным приложениям задается в настройках таргетинга операторами include/exclude и наследуется по цепочке рекламодатель → кампания → группа → объявление. На web-запросах правило пропускается. В конструкторе отчетов есть измерение «установленное приложение»: CTR и другие метрики можно разложить по iApp и ограничить приложениями, на которые кампания таргетируется. Наблюдения «профиль — приложение» пишутся только для запросов с устойчивым профилем и дальше питают поведенческие сегменты. CTR-модель Ibiza видит первые 20 приложений списка и признак «продвигаемое приложение уже установлено».