Как мы переиспользовали платформенную аналитику для упрощения работы
Привет, Хабр! Меня зовут Вячеслав Сухоруков, я бекэнд-инженер департамента разработки Analytics Platform в Авито. В этой статье я рассказываю о том, как мы написали сервис Marketing Manager (ММ) для размещения данных в рекламных системах. Вы узнаете, что умеет наш менеджер, как он устроен и каким образом это решение экономит время маркетинговых аналитиков.
Мы в Авито привлекаем ликвидность из внешних рекламных платформ и оптимизируем этот процесс через Return On Investment (ROI, возврат инвестиций). Для этого мы передаем в рекламные системы целевые события, например, контакты по айтемам (айтем — это объявление, товар и тому подобное). А они, в свою очередь, используют эти данные в рамках realtime-аукциона за пользователя.
Чтобы решить эту задачу, мы разработали сервис под названием Marketing Manager. Он позволит отправлять данные на основе аналитических событий, возникающих на платформе Авито, сразу в рекламные системы, без 3rd party-маркетингового кода внутри фронта и с возможностью обогащать данные аналитическими моделями.
Проблемы актуального подхода с 3rd party SDK
Все имеющиеся проблемы подхода, от которого мы хотим уйти, можно объединить в три группы:
Консистетность данных:
источник событий — это зачастую некий микросервис, а не фронт;
оптимизируемся на прокcи-метрики, а не на целевые, то есть можем триггерить отправку только на основе действий, происходящих на ui;
не учитываем антиботные механизмы.
Ресурсы и сложности:
поддержка сторонних библиотек на фронтах и доработка событий после каждого продуктового релиза;
отсутствие ресурса разработки в маркетинге. Проблема в том, что продуктовые команды пилят фичи, покрывают их clickstream-событиями, а дальше — серая зона. Либо маркетинг узнает постфактум и требует дополнительные ресурсы разработки, либо просто берем имеющиеся clickstream-события и при помощи MM делаем forward в нужную рекламную систему;
высокий ТТМ, релизный цикл со 100% раскаткой на iOS/Android — от 2 месяцев.
Пояснение по второму пункту, про отсутствие ресурса. Здесь есть две проблемы:
маркетинговому аналитику надо узнать, что появилась новая фича;
маркетинговому аналитику надо найти ресурсы для того, чтобы добавить 3rd party-код для своей маркетинговой компании.
Команды по дефолту покрывают фичи кликстримом, а маркетинговые-аналитики могут использовать ММ для того, чтобы переиспользовать данные и направить их в рекламную систему.
Риски:
отключение внешних инструментов из-за санкций. Наша платформа дает возможность переключить поток событий на альтернативный инструмент максимально оперативно;
риски конкурентного шпионажа;
деградация performance-показателей и наличие «зоопарка» 3rd party SDK влияет на время загрузки страницы, увеличивает TTI, порождает дополнительные сетевые запросы.
Marketing Manager — это платформа, с помощью которой можно конфигурировать, фильтровать, обогащать и отправлять сообщения, построенные на основе clickstream-событий, во внешние рекламные системы (далее — кабинеты) в режиме, близком к реальному времени. В отправке могут участвовать поля событий, которые размечены как не персональные данные. О clickstream-событиях и не только мы ранее говорили в посте, посвященном платформе логгирования аналитических событий.
Верхнеуровневая архитектура
Схема работы
События с источников отправки (сервисы, фронтенды, мобильные приложения) собираются через clickstream, далее проходят flink-джобу основных обогащений и джобу обогащений для сервиса Marketing Manager. После этого они раскладываются по топикам, для каждого кабинета топик отдельный. При вычитке событий из топика происходит создание сообщения для кабинета на основе события и правил трансформации к нему. Далее сообщение отправляется в кабинет.
Гарантии и ограничения
Гарантии доставки — at least once («хотя бы один раз»). Переживаем аварию в 2 дня без потерь, за счет настройки kafka retantion. При проблемах в кабинетах-приемщиках или обогащающем pipeline мы будем пытаться отправить событие бесконечно. Это позволяет пережить значительное время нестабильности кабинетов, но накладывает некоторые ограничения:
события дублируются;
при проблемах в кабинете мы не будем пропускать события, в результате событие может «долетать» до кабинета с задержкой. Если событие не отправится за 2 дня, оно будет потеряно. Достигается это за счет конфигурации backoff-стратегии отправки запросов во внешнюю систему.
Гарантии антиботной очистки — для платформы работает стандартная очистка потоковым антиботом. Потоковый антибот — это flink‑джоба, включающая в себя десятки эвристик, рассчитываемых в реальном времени. Разработкой этой flink-джобы занимается команда clickstream-processing и, возможно, вы еще прочтете об этом продукте в их статьях.
Возможности инструмента
экспорт определенных событий, собираемых через clickstream в кабинеты, без необходимости многократного вызова SDK. Используем его только для генерации идентификатора клиента;
конфигурация экспортируемых сообщений на основе данных из события;
фильтрация экспортируемых данных на двух уровнях (кабинет и сообщение). Фильтрация на уровне кабинета может быть полезна, если вам нужны события не со всех платформ (desktop_site, mobile_site, iOS, Android). Фильтрация на уровне сообщения может потребоваться, если у вас в событии есть специфические данные, по которым требуется дополнительная логика фильтрации;
управление активностью отправки через административную панель;
мониторинг потока отправляемых данных;
поддержка разных рекламных систем и возможность быстрого перевода отправки в случае необходимости.
Пример экспорта в VK Ads
Команде маркетологов в рамках перехода с 3rd party SDK на S2S-события потребовалось настроить экспорт данных, которые логгируются в clickstream-событиях на десктопной и мобильной версиях сайта Авито.
Первым делом мы создали фильтр для всего кабинета (скриншот ниже), который смотрит на все входящие события и проверяет, что значение системного поля business_platform равно одному из значений: desktop_site или mobile_site.
Фильтр на уровне кабинета
Второй шаг — мы приступили к конфигурации экспортируемых сообщений на основе схемы кабинета. Схема — это, по сути, тело запроса, отправляемое в кабинет. Схему в системе заводят разработчики, которые внедряют поддержку нового кабинета.
По итогу получилось создать n-ое количество сообщений на основе clickstream-событий для экспорта в VK Ads.
Таблица экспортируемых сообщений с базовой информацией
Конфигурацию экспортируемого сообщения можно условно разделить на следующие блоки (несмотря на то, что это происходит в рамках одной страницы):
1) ввод названия, выбор события и выбор схемы:
Форма создания нового сообщения
2) после выбора схемы ниже отобразятся её поля, которые нужно заполнить, выбрав и настроив одно из предложенных действий (три скриншот снизу). Действие с точки зрения интерфейса — это виджет, который позволяет определить логику, по которой будет устанавливаться значение поля схемы на основе данных (полей) события. С точки зрения бекэнда — это код, который выполняет манипуляции с этими событиями и записывает их в поле схемы, которое необходимо отправить.
Список полей схемы, для которых нужно настроить действия
Пример выбранного действия для поля 'u'
Пример выбранного и настроенного действия для поля 'u'
3) после заполнения полей страница станет доступной для сохранения, а иконки гаечных ключей, стоящие рядом, станут синего цвета.
Полностью заполненная схема
4) для сохранения и запуска отправки необходимо выставить флажок активности и нажать кнопку «Сохранить».
Выводы и планы
Появление ММ помогло маркетинговым аналитикам проверить ряд гипотез, связанных с переходом с SDK на S2S (server to server) и сделать следующие выводы:
S2S-события — рабочая альтернатива SDK-событиям, они не ухудшают ключевые метрики команды маркетинга;
стратегии, опирающиеся на динамическую ценность (weighted buyer), не показали ожидаемого результата, было принято решения об отказе от использования таких стратегий на наших кампаниях.
Помимо выводов, полученных на основе проверяемых гипотез, получилось решить ряд проблем. А ещё внедрение ММ позволило:
отказаться от излишнего кода на фронтах;
уменьшить ТТМ по настройке экспорта с lde[ месяцев (релизный цикл на iOS/Android) до нескольких дней;
обеспечить гарантию ботной очистки потока за счет онлайн антибота.
В планах у нас — поддержка перехода с 3rd party SDK на S2S всех событий, для которых это возможно. В ходе поддержки ожидаем мелкие доработки, возможно найдутся баги, а в процессе появятся фича-реквесты.
Спасибо вам за уделенное статье время! Если у вас есть вопросы или вы хотите поделиться опытом разработки и использования менеджеров, аналогичных нашему ММ — добро пожаловать в комментарии.
А еще подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
