В предыдущей статье мы рассказывали, как поднимали для клиента SSP (Supply‑Side Platform). В процессе напоролись на проблему несоответствия.
Несоответствие — одна из самых неопределенных, трудноустранимых и распространенных проблем в AdTech, у неё нет четкого алгоритма исправления. Она может приходить и уходить без видимых причин.
В этой статье расскажем о проблеме в общем, а также о подходах, которые мы использовали для ее решения.
Да что это за несоответствие такое?
Напомним материал прошлой статьи:
SSP — это система, которая позволяет владельцам отдельных сайтов или целых сетей продавать рекламные места и получать доход от размещения объявлений. SSP тесно связанно с DSP. DSP (Demand Side Platform) — это система, которая облегчает процесс покупки и продажи рекламных мест. Рекламодатель подключается к DSP, чтобы покупать и размещать рекламу в интернете, отслеживать результаты, оптимизировать все запущенные кампании — все это на едином сервисе и в одном интерфейсе.
Для успешной интеграции с DSP необходимо учитывать несоответствие количества показов рекламы и их стоимости между отчетами SSP и DSP. Это несоответствие не должно превышать 5%.
В AdTech владельцев сайтов называют издателями. Некоторые издатели используют платформу Google DoubleClick for Publishers (DFP), этот инструмент был переименован в Google Ad Manager (GAM), для управления всей рекламой в одном месте. С помощью этого инструмента издатель создает рекламные места на сайте и в дальнейшем может смотреть статистику по показам.
Несоответствие между SSP и DSP проверяется по отчетам. Эти отчеты формируются на основании трекеров, которые отслеживают показ рекламы на сайте.
Когда мы интегрировали несколько DSP в систему, заметили расхождения между отчетами SSP и DSP на стороне издателя (DFP). Из-за этих несоответствий было сложно оценить влияние SSP на бизнес издателей и рассчитать точную долю дохода. Несоответствие отчетов заблокировало полноценный запуск платформы.
На нескольких сайтах есть расхождения — это вообще проблема?
Когда мы начали расследование расхождений, у нас было около десяти интегрированных издателей. Два-три из них давали расхождение выше 5%, но остальные были в порядке. Мы потратили несколько месяцев на то, чтобы исправить несоответствие для конкретного издателя, и за это время клиент подумал, что система полностью нефункциональна, а мы недостаточно компетентны, чтобы исправить это.
Мы поняли из этого, что в AdTech расхождения встречаются часто. Нужно отслеживать их влияние на бизнес, а не абсолютные значения.
Фактически, с точки зрения бизнеса, наша система дала общее расхождение менее 5%, и 7 из 10 веб-сайтов работали должным образом. Это соответствует отраслевым стандартам для систем AdTech и считается хорошим результатом. Изначально заказчик настаивал на расследовании конкретных случаев с проблемными веб-сайтами, но, увидев общую перспективу, понял, что влияние на бизнес незначительно. Он может получать доход от системы и платить издателям, имея разницу в отчетах < 5%. Это разблокировало запуск проекта.
Все работает нормально, но мы видим несоответствие, что дальше?
Первоначальная оценка SSP-трекера показала, что код для отслеживания показов в браузере выполняется без ошибок, а преобразованные данные отчетов соответствуют сырым данным о показах. Было неясно, что можно сделать, если ничего не выходит из строя. Выглядело заманчивым проигнорировать проблему.
Мы решили ежедневно отслеживать данные и систематически оценивать гипотезы.
Прежде всего, создали электронную таблицу, чтобы отслеживать несоответствия. В нее ежедневно собирали данные о расхождениях. Это был основной инструмент, который позволил оценивать все последующие эксперименты.
Затем мы следовали системному подходу к решению проблемы:
- Выдвигали гипотезу, которая могла объяснить причину проблемы
- Создавали простой тест, который мог подтвердить/опровергнуть гипотезу
- Проводили эксперимент, чтобы проверить гипотезу
- Если эксперимент проходил успешно, внедряли полное исправление, требуемое гипотезой
Это позволило нам ежедневно перебирать гипотезы и быстро отказываться от сложных идей. Клиенту это дало полное понимание ситуации и уверенность в том, что мы достаточно компетентны, чтобы справиться с ней.
Мы рассмотрели три основные области процесса отслеживания, где можно потерять показы
- AdServer (DFP): выбирает победивший креатив и показывает его
- Браузер пользователя: отображает рекламу и запускает уведомление о показе
- Трекер: хранит и обрабатывает показы
Со стороны AdServer очень важно отличать данные SSP от встроенных адаптеров PreBid, установленных и участвующих в аукционе. Вот гипотезы, которые мы оценили:
Наши отчеты могут содержать данные о трафике, обслуживаемом с помощью различных механизмов, но нас интересует трафик через Prebid.js (header bidding).
ПОДТВЕРЖДЕНО. Мы поняли, что Менеджер рекламы Google проводит собственный аукцион, перед тем как показать рекламу в браузере, на котором наша система делает ставку. Иногда он выбирает другую ставку от конкурирующих серверов объявлений, поэтому пришлось отфильтровать этот трафик из наших отчетов (в отчете DFP поле OrderName помогло понять от нашей системы эти показы или нет).
AdServer может отслеживать показы рекламных объявлений (креативов), которые не могут быть отображены по каким-то неизвестным причинам.
ОТКЛОНЕНО. Хотя документация Google подтверждает, что платформа DFP отслеживает показы после того, как браузер начинает загрузку креатива, общее количество показов в отчете DFP было ближе к данным наших отчетов, чем что-либо еще (например, специальные показы «Начало рендеринга» от Google).
На стороне клиента основная проблема заключалась в том, чтобы понять, вызвано ли несоответствие креативом или сложностью веб-сайта издателя. Вот гипотезы, которые мы оценили:
Креативы из определенного DSP не могут отображаться при полностью включенном отслеживании.
ПОДТВЕРЖДЕНО. Мы внедрили код, который фиксирует все визуализированные креативы до того, как они будут добавлены на страницу. Код показал, что существуют креативы, для которых мы не можем отследить показы с вероятностью > 60%. Такие креативы генерировали ~80% расхождений для конкретных сайтов. Хотя мы не внедрили решение для обнаружения и исключения таких креативов из рендеринга (показа рекламы в браузере), оно позволило нам объяснить большое расхождение на некоторых веб-сайтах и отключить SSP, которые приводили к такому расхождению на них.
Объявления могут не отслеживаться на определенных устройствах/ОС/браузерах.
ОТКЛОНЕНО. Мы сравнили необработанные данные с разбивкой по различным параметрам с соответствующими отчетами от партнеров и AdServer и не обнаружили корреляции между расхождениями и устройствами, операционными системами и браузерами.
Веб-сайт инициирует множество одновременных запросов, которые заставляют некоторые запросы завершаться с тайм-аутом, ожидая очереди «max-6-requests» в браузере.
ПОДТВЕРЖДЕНО. Для некоторых веб-сайтов мы проверили вывод консоли во время их рендеринга и обнаружили сотни запросов с ошибками. Это создало впечатление, что проблема с отслеживанием распространена на веб-сайтах. Мы проверили ее, сравнив расхождения между менеджером рекламы и другими встроенными адаптерами prebid. Сайты с большим количеством ошибок имели высокие расхождения и для всех остальных адаптеров.
Браузеры не загружают код трекера (пикселя — img тега) отслеживания показов для оптимизации элементов display:hidden.
ОТКЛОНЕНО. Несмотря на то, что оптимизация существует, мы не увидели заметного влияния на расхождение при использовании разных стилей отслеживания (XHR-запрос, прозрачный пиксель 1x1, скрытый пиксель 0x0 и т. д.).
Пиксель отслеживания показов кэшируется и поэтому не запрашивается.
ОТКЛОНЕНО. Все наши пиксели показов имели уникальные URL-адреса, поскольку они содержали хешированный параметр идентификатора показа.
Некоторые сайты имеют большие расхождения из-за неисправной версии адаптера Prebid.js.
ПОДТВЕРЖДЕНО. На самом деле мы поняли, что один из сайтов использовал старую версию Prebid.js, которая отличалась на 10 минорных версий от обычно используемой. Мы обновились и расхождение значительно уменьшилось. Хотя не у всех пользователей сразу же обновился Prebid.js из-за кеширования js в браузере. Кроме того, мы поместили номер версии Prebid.js в данные трекера показа, чтобы отслеживать такие проблемы в будущем.
Со стороны трекера основным препятствием было объективно оценить, правильно ли работает наш код и отслеживает ли нужные данные. Вот гипотезы, которые мы оценили:
Несоответствие может быть вызвано ошибкой при дедупликации показов.
ПОДТВЕРЖДЕНО. Когда мы показывали одинаковые объявления с разных DSP по одной и той же цене, все эти объявления учитывались как один показ. Мы исправили процесс дедупликации, и добавили проверку от какого DSP пришла реклама.
На входе в SSP стоит балансировщик нагрузки для распределения трафика между серверами. Балансировщик нагрузки может терять запросы к трекеру с информацией о показе до того, как они попадут в наш трекер.
ОТКЛОНЕНО. Мы сравнили файлы журналов балансировщика нагрузки с необработанными данными о показах. Они совпали.
Наш трекер теряет часть информации о показе при обработке.
ОТКЛОНЕНО. Во-первых, мы стали отслеживать коды от SSP и собирать исключения. Никаких ошибок при обработке запросов они не показывали. Во-вторых, развернули дополнительный вспомогательный сторонний трекер (Snowplow) за пределами нашей системы, чтобы сравнить показания и подтвердить, что трекер работает стабильно. Мы сравнили данные между этими двумя трекерами, и они совпали.
Как сделать хорошо и не тратить массу времени? Автоматизируй!
Отчеты от DSP поступали на почту или собирались по API. Первоначально мы собирали данные о несоответствии для конкретного сайта вручную по отчетам DSP. Это работало, когда мы мониторили 2-3 DSP и 3-4 сайта. Когда мы начали масштабировать платформу, ежедневно тратили около часа на сбор необходимой статистики.
Тогда мы создали процесс, который автоматически извлекает отчеты из почтового ящика по мере их поступления, обрабатывает их и сохраняет сводную статистику в базе данных SQL. Позже данные можно было легко визуализировать в Grafana или проанализировать в любом редакторе SQL. Это позволило сделать данные доступными в одном централизованном месте с другими бизнес-метриками платформы и масштабировать мониторинг до 150+ веб-сайтов.
Однако позже мы столкнулись с другой проблемой. Поскольку мы полагались либо на электронные таблицы, либо на автоматизированные скрипты, нам было сложно ответить на такие вопросы, как «какова разбивка показов по устройствам за последние 30 дней». Нам приходилось либо создавать огромные электронные таблицы, либо изменять код, чтобы получить такие результаты. На это уходили часы работы.
В качестве решения мы изменили процедуру сбора несоответствий, чтобы поместить в S3 необработанные не агрегированные отчеты, полученные в результате интеграции с файлами CSV. Затем мы настроили Athena для создания таблиц из этих файлов и сделали данные доступными для запросов. Это позволило нам быстро оценить гипотезы, связанные с данными, и объединить несколько источников данных, чтобы ответить на сложные вопросы (например, какие запросы от вспомогательного трекера также были захвачены нашим трекером, если мы знаем, что креатив был отображен).
Резюмируя: настроили автоматический мониторинг несоответствий и проверили кучу гипотез
- Создали информационную панель Grafana для визуального контроля несоответствий. Сбор несоответствий осуществляется по отчетам SSP и DSP.
- Некоторые DSP поддерживают только отправку ежедневных отчетов на электронную почту поэтому для автоматизации процесса обработки отчетов внедрили SES+Lambda.
- Настроили альтернативный трекер для проверки гипотезы о том что трекер в SSP работает со сбоями.
- Для проверки гипотезы, о том что при показе рекламы на сайте происходит ошибка и трекер не срабатывает, мы добавили аналитический адаптер в Prebid.js, который фиксирует все события по вставке рекламы.
Делимся результатами
- Расхождение в общем количестве показов и доходах между 70+ издателями и SSP не превышает 5 %.
- Несоответствие количества показов и стоимости между SSP и тремя DSP, работающими на более чем 150 веб-сайтах, находится в допустимом пределе 5%.
- Несоответствие отслеживается ежедневно, поэтому клиент может уведомить своих клиентов и приступить к устранению неполадок, как только что-то пойдет не так.
- Информационные панели в Grafana с несоответствием для каждой DSP позволили быстро отслеживать аномалии в работе системы.
- Была проделана трудоемкая работа по выявлению несоответствий и доведения системы до готовности к производству, что позволило нам систематизировать подход к выявлению причин.