Личный опыт: создание собственного AdTech-продукта

В Media Instinct за продуктовую разработку и инновации отвечает целая дирекция. Это укомплектованная команда с IT-бэкграундом. В ее составе находятся продуктовые и проектные менеджеры, разработчики backend и frontend, аналитики, DevOps-инженеры и data-scientist. Основной задачей нашей дирекции стало создание продуктов, которые увеличат возврат рекламных инвестиций клиентов.

На старте, погрузившись в рекламную индустрию изнутри, мы встали перед выбором между имплементацией существующих решений и разработкой собственных. Видимое изобилие технологических решений на рынке рекламы после проведенного анализа оказалось мнимым.

Особенность рекламного рынка в том, что любое инновационное решение сопровождается пресс-релизами с обтекаемыми формулировками, в которых повествуется о новейших технологиях и потенциале их применения, но ни слова о разработке, технической документации или доступе к тестовой среде.

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

Далее расскажем о реальных технологиях, решающих конкретные задачи рекламодателей.

Анализ рынка

На рынке digital-медиа стек Adtech-решений можно разделить на два типа:

1. Открутка инвентаря и все, что связано с доставкой рекламы (по сути, ядро любой кампании).
2. Технологии и решения, создающие добавленную стоимость: таргетирование, персонализация, оптимизация рекламных кампаний, планирование, отчетность и прочие составляющие.

Major-инвентарь не дает необходимой гибкости для оптимизации. Сторонний инвентарь не дает достаточной прозрачности.

В 2020 на рынке хватало предложений инвентаря, начиная с рекламных кабинетов игроков (таких как Mail.ru, «Яндекс», Google, Facebook) и заканчивая большим выбором небольших DSP и программатик-платформ, работающих как на селф-сервисе, так и на полном сопровождении. В первую очередь мы решили подробнее рассмотреть, какие проблемы стоят за каждым таким решением.

Выводы:

1. Major-игроки в значительной степени закрыты от внешних взаимодействий и предоставляют единые для всех и весьма ограниченные возможности по работе с рекламными кампаниями.
2. Сторонние решения остаются недостаточно прозрачными и не допускают контроля и аудита процессов третьей стороной.

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

Подобные разработки содержат в себе нечеткую логику, системы распределены и настроены под конкретную конфигурацию. Коробочное решение выглядит как сложный технологический объект, который можно настроить и запустить, но дальше лучше не трогать. Кастомизация и усовершенствование таких продуктов закончится непредсказуемым результатом либо полным отказом системы.

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

Собственная разработка

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

Начало разработки — февраль 2020

Несмотря на внушительное число действующих DSP-платформ как на мировом рынке, так и на рынке РФ, техническая документация по ним практически отсутствует. Поэтому сроки мы прогнозировали, опираясь на собственные представления. В статьях от зарубежных вендоров срок разработки варьировался от двух до четырех лет. Мы понимали, что в реалиях российского бизнеса такие сроки не могут рассматриваться, поэтому масштабное тестирование мы запланировали на осень 2020. Сжатые сроки влияли на энтузиазм команды.

Анализ моделей данных, проектирование архитектуры, сбор и обработка статистики, разработка модуля принятия решения и загрузчик креативов мы завершили уже в июне. Тестирование удалось начать в июле. Оно выявило несколько багов, но в целом у нас был стабильно работающий биддер, который уже зарегистрирован в Роспатенте.

На выходе мы создали DSP с предельной нагрузкой в 100 тысяч запросов в секунду, протоколом OpenRTB, CPC-моделью оптимизации, основанной на прокачанной логистической регрессии с поддержкой всех популярных форматов, самодельным антифрод-модулем и таргетингами аудиторий, географии и прочего.

Как оказалось после, мы зря так фокусировались именно на цене клика, но на тот момент это не было очевидно.

По сути, не было изобретено ничего нового, но весь функционал от и до был разработан с нуля внутри нашей организации. А это значит — дальше можно с этим работать так, как нам и нашим клиентам необходимо. Дорабатывать все что угодно с полным осознанием всех узких мест и «что может пойти не так».

Наша DSP-платформа называется q.bid. Наличие собственной DSP позволяет закупать трафик без наценок и полностью контролировать качество трафика, так как платформа подразумевает отказ от посредников в цепочке от сайта, на котором осуществится показ.

Развитие продукта

Следующим шагом продуктовой разработки было создание дополнительных модулей DSP q.bid, решающих бизнес-задачи наших клиентов, которые на текущий момент отличают нашу DSP от существующих решений на рынке:

• pre-bid-верификация (верификация не после проведения рекламной кампании, а непосредственно в момент закупки);
• интерактивные и нативные рекламные форматы;
• классификаторы закупки: CPC, CPV, СРА;
• построенные ML-модели для разного типа бизнеса (авто, фарма, FMCG, телеком, банки и т. д.);
• DCO (динамическая персонализация креативов).

Первоначально мы пользовались различными счетчиками трафика, а также информацией, приходящей в бид-запросе, однако стало понятно, что этого мало. По опыту работы с различными DMP, наибольшую ценность представляют поведенческие признаки, так что мы разработали собственную DMP с систематизацией всей информации и назвали MI DMP.

По пользователям были собраны обезличенные данные о поведении в интернете (какие страницы посещали, в какое время и т. д.). Далее была проанализирована информация с этих сайтов с помощью современных техник обработки текстовой информации (NLP). Для пользователей были составлены его «профили» в виде вектора (была использована модель fasttext, разработанная исследователями в области машинного обучения из facebook). Аналогичный вектор той же модели был получен для тематики рекламного объявления.

В итоге объявление показывалось только тем пользователям, вектор которых находится достаточно «близко» к вектору объявления (считалось расстояние между векторами с помощью алгоритма k-Nearest Neighbours).

От оптимизации трафика до постклика

После некоторого времени открутки появилось осознание, что технические показатели относительно легко достижимы даже без ML-классификатора, однако надо что-то делать с посткликом. Более того, работа классификатора осложняет постклик-оптимизацию, поскольку чем выше CTR, тем больше случайных заходов попадает на посадочную страницу.

Для day-to-day-оптимизации мы разработали макросы, благодаря которым в системы постклик-аналитики передавались параметры открутки (страница, время, креатив, гео, сегмент и т. д.). Это позволило находить неочевидные комбинации таргетингов.

Следующим шагом стала интеграция q.bid с ресурсами клиентов для увеличения качества постклика. Мы разработали свой пиксель и попросили нескольких клиентов установить его на сайте через GTM. Результаты не заставили себя долго ждать: после получения данных о пользователях, совершающих целевые действия на сайте, мы построили несколько ML-моделей по типу конверсий на сайте. Особый повод для гордости — автомобильная сфера. CR «запись к дилеру» мы увеличили с 0,6 до 2,1%.

Решение бизнес-задач клиентов

Для выполнения performance KPI и оценки влияния медийных инвестиций на performance KPI, в том числе для офлайн-действий (продажи, звонки, посещения отделений), нам нужно было синхронизировать данные собственной MI DMP с данными клиентов. Разработка метода синхронизации позволила нам обмениваться данными с клиентами без передачи персональных данных.

Данная интеграция представляет собой метод связки идентификаторов агентства и идентификаторов клиента. Основная сложность заключается в том, что офлайн-данные клиентов невозможно привязать к онлайн-идентификаторам без доработок на стороне клиента.

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

После накопления достаточного количества связок появились следующие возможности:

• построение пост-вью-моделей, то есть оценка влияния рекламных показов креативов на фактические бизнес-показатели;
• построение ML для таргетинга, обученных на пользователях на разных стадиях воронки;
• построение многоканальной коммуникации и учет кросс-охвата между площадками;
• использование дополнительных каналов коммуникации (SMS, push, voice).

Все это позволяет корректно планировать, реализовывать и анализировать рекламные активности с участием q.bid DSP.

Проводя многочисленные тесты с данными MI DMP, данными собственной DMP + CRM клиента, мы пришли к выводу, что большое значение имеют не только контекст для показа креатива (площадки, сайты), но и контент креатива.

Динамическая оптимизация и персонализация креативов

Аудиторные таргетинги показывали недостаточную эффективность. Эффект был, но мы стремились к большему, поскольку страницы уже были категоризированы для сегментации пользователей. Мы сделали собственный справочник для q.bid, что стало верным решением. Таргетинг на контент страницы совместно с таргетингом на заинтересованную аудиторию начал приносить результаты.

Для эффективной работы системы нам необходимо было получить вводные данные по целевым аудиториям от клиентов. Мы столкнулись с проблемой полного непонимания со стороны клиентов своей аудитории. Все дело в том, что признаки, превалирующие в маркетинговых стратегиях, зачастую оказываются не самыми важными, поэтому мы основываем определение ЦА по принципу максимального изменения энтропии в классификаторе.

В нашем случае, когда решается задача классификации, мы не знаем, как делить классы, и энтропия максимальна. В деревьях решений (бинарный случай) наблюдения делятся в узлах деревьев на два листа, деление происходит по какому-то из факторов. Фактор и порог деления выбирается исходя из минимизации энтропии.

После построения всех деревьев мы можем определить, сколько раз фактор делил данные в узлах и какое суммарное значение энтропии было в них при делении. Эта сумма и есть показатель важности. Вычисляется для всех факторов их суммарное уменьшение энтропии. Далее полученные значения энтропий факторов делятся на их сумму для получения доли и интерпретации вклада каждого фактора.

Пример для понимания:

Нам необходимо определить ЦА игры Sims. 80% играющей аудитории — женщины 14–28 лет. Казалось бы, вот и определена наша целевая аудитория. На основании жизненного опыта можно построить портрет этой аудитории, вспомнить свою племянницу и бывшую коллегу, удостовериться, что обе они принадлежат ЦА. При этом они обе не замужем и интересуются шопингом. Вот и готово, все сходится.

Подход по определению подобных гипотез до сих пор крайне часто встречается. Ошибка здесь кроется в том, что хоть большая часть аудитории Sims и женщины, однако неверно то, что большая часть всех женщин играет в Sims. То же относится и к незамужним и любителям шопинга. Иначе говоря, описание ЦА построено хоть и на признаках, соответствующих аудитории, но не на определяющих признаках, то есть не на тех, которые на самом деле отличают аудиторию от всех остальных.

Использование персонализированных креативов для микросегментов в 8 из 10 случаев давало увеличение медийных показателей на статистически значимую величину. У нас ушло несколько месяцев на анализ существующих решений. Персонализация для сегмента пользователей нас не устраивала (так как один и тот же пользователь находится в сотне разных сегментов), поэтому разрабатывали свой DCO-модуль.

В q.bid на текущий момент доступен модуль DCO для баннеров любого формата — мы на этапе масштабного тестирования. Параметрами персонализации служат не только данные DMP или данные клиента, но и внешние триггеры (погода, курс валют и прочие). Отличие нашего DCO от всех существующих на рынке решений — персонализация не для сегмента пользователей, а для конкретного пользователя. Собственная платформа для закупки трафика позволяет формировать креатив «на лету», в момент отрисовки креатива на странице.

Проблемы и ошибки

Разрабатывая технологически сложный продукт, любая история взлетов без падений будет утопией. Наш случай не был исключением, мы сталкивались с серьезными препятствиями и допускали ошибки с самого старта разработки DSP.

Проблема № 1 — недооцененный эффект нагрузки

В самом начале мы сосредоточились на логике самих рекламных кампаний, потому как необходимо было продумать настройки, механику ограничений, применения таргетингов, разделения на сущности. Естественным казался принцип минимизации сетевых обращений, то есть хотелось все необходимые данные получать одним запросом.

Поскольку кампаний не предполагалось много (десятки тысяч), то мы решили использовать плоскую таблицу с индексами, определили, какие потребуются фильтры и ограничения, а также типы сущностей.

Получилась довольно простая реализация пребидовых фильтров, показавшая в процессе разработки хорошие результаты. Многочисленная индексация данных отбирала большое количества места, но им пришлось пожертвовать в пользу скорости.

Проблема № 2 — разобщенность протокола

За основу самого API взят OpenRTB 2.5 как самый распространенный. При первом рассмотрении в протоколе нет ничего сложного, но он обладает множеством степеней свободы, так что чуть более десяти параметров являются обязательными, остальные — максимум рекомендуемые.

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

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

Проблема №3 — неопределенность тестирования

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

Логика в системе кампаний сложная, огромное количество проверок в зависимости не только от настроек, но и от значений входящих запросов. Реальных запросов нет, а комбинаций может быть великое множество.

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

В итоге мы написали генератор рандомных кампаний внутри q.bid так, чтобы настройки были максимально приближены к «живой» рекламной кампании: отсутствие взаимоисключающих настроек, реальные таргетинги, ограничения, различные форматы креативов.

Написание подобного генератора заняло уйму времени. Параллельно мы писали сам нагрузчик примерно с таким же набором логики. Для корреляции систем пришлось завести отдельный словарик различных вариантов настроек.

Таким образом мы и «отлаживались», проверяли логику выбора списка кампаний с подходящими настройками, ограничения цены, частоты контакта и так далее.

Проблема №4 — зависимость логики работы от структуры хранения

Далее дошли до нагрузки системы q.bid DSP, и нам пришлось вернуться к первой проблеме. Запросы на сильной нагрузке начали проседать по времени ответа: учитывая одновременную запись, индексы не успевали.

Поскольку у нас были транзакции по операции сравнения, движок не всегда понимал, надо ли использовать индекс. Единственным возможным вариантом в такой ситуации стало использование данных в виде «ключ-значение». Но появилась другая проблема.

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

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

Для теста в среде разработки мы использовали 100 000 тестовых рекламных кампаний с самыми разнообразными параметрами настройки. Данное количество значительно превышало предполагаемое количество активных кампаний. Новая схема работала хорошо, и после устранения некоторых нюансов мы перешли к боевому тестированию.

Тут-то и начались проблемы: оказалось, что наше тестирование далеко до идеального, потому как каждая SSP передает какой-то свой набор полей и не передает другие; где-то поддерживаются одни макросы, где-то остальные. Кто-то не использует некоторые поля, для других их недополучение приравнивается к ошибке. Не говоря еще и о том, что разные системы могут опираться на разные версии протоколов, а где-то протокол может кардинально отличаться (например, у major-игроков).

Начав исправлять ситуацию, мы поняли, что не так с нашей новой архитектурой: изменение логики фильтрации приводило к изменению ключей, а каждое новое значение поля рождало удвоение их количества.

В итоге на адаптацию нам пришлось затратить много времени и ресурсов.

В интернете есть масса статей в стиле: «DSP — просто о сложном», однако нигде нет истории от и до по реализации подобной системы.

Проблемы и ошибки были почти во всем: использование ML для оптимизации, использование кэша, сетевые настройки, балансировка и еще многие другие. Но мы прошли этот тернистый путь, не бросая разработку, не смиряясь с недостатками. Барьеры мы преодолели и получили тот продукт, на который целились.

В сухом остатке

На текущий момент мы завершили разработку и тестирование трех основных модулей всего цикла реализации инвентаря: DSP + DMP + DCO. Речь идет о собственном биддере (покрытие 90% рунета), собственной сегментации пользователей (более 900 таксонов по поведению онлайн/офлайн и более 20 ML-моделей для клиентов разных сфер), собственном конструкторе креативов. Такая конфигурация q.bid DSP позволяет не только максимально качественно контактировать с пользователем, но и проводить A/B-тестирование, замерять эффект влияния на узнаваемость и продажи бренда.

Рекламные кампании 2020 года были успешны как с точки зрения заявленных KPI, так и с точки зрения эффективности для бизнеса клиентов. Впереди мы поставили амбициозные задачи развития q.bid: повышение эффективности модуля CPA-оптимизации, внедрение новых алгоритмов верификации трафика и добавление новых форматов размещения, собственный измеритель и автоматизацию нетривиальных для рынка DSP систем медиа — работу с инфлюенсерами и наружную рекламу. Но об этом мы напишем позже, следите за обновлениями.