Разработать систему отчетности по бизнес и системным показателям, подготовить систему к запуску новых сервисов.
Проведена оптимизация производительности системы для запуска новых сервисов и повышения нагрузки, разработанная система мониторинга и отчетности позволяет отслеживать как технические показатели системы, так и экономические.
Выходящее за рамки традиционных издательских услуг, путем встраивания интерактивных рекламных блоков в качестве дополнения к стандартной видео- и медийной рекламе в виде викторин, опросов и избранного контента. Эта стратегия доказала, что увеличивает вовлеченность посетителей и ценность рекламного пространства для издателей.
Основываясь на успехе, начала создавать собственную SSP с целью иметь возможность тонко настраивать назначение ставок и доступ к широкому кругу ведущих рекламодателей.
Для трекера и биржи. 
Для сбора отчетов о расхождениях. 
Для сбора отчетов. 
Для пересылки сообщений электронной почты с отчетами о расхождениях в обработку. 
Для хранения необработанных отчетов и AWS Athena для выполнения специальных запросов поверх них. 
Для визуализации метрик. Важно отличать данные SSP от встроенных адаптеров PreBid, установленных и участвующих в аукционе. Вот гипотезы, которые мы оценили:
Поняли, что Менеджер рекламы Google проводит собственный аукцион на котором наша система делает ставку. Иногда он выбирает другую ставку от конкурирующих серверов объявлений, поэтому пришлось отфильтровать этот трафик из наших отчетов (используя OrderName).
Хотя документация Google подтверждает, что GAM отслеживает показы после того, как клиент начинает загрузку креатива, общее количество их показов было ближе к нашим данным, чем что-либо еще (например, специальные показы «Начало рендеринга» от Google).
Основная проблема заключалась в том, чтобы понять, вызвано ли несоответствие блоком рекламы или сложностью самого веб-сайта издателя. Вот гипотезы, которые мы оценили:
Внедрили код, который фиксирует все визуализированные креативы до того, как они будут добавлены на страницу. Код показал, что существуют креативы, для которых нельзя отследить показы с вероятностью > 60%. Такие креативы генерировали ~80% расхождений для конкретных сайтов. Хотя мы не внедрили решение для обнаружения и исключения таких креативов из рендеринга, оно позволило объяснить большое расхождение на некоторых веб-сайтах и отключить SSP, которые приводили к такому расхождению на них.
Сравнили необработанные данные с разбивкой по различным параметрам с соответствующими отчетами от партнеров и AdServer, и не обнаружили корреляции между расхождениями и устройствами, операционными системами и браузерами.
Для некоторых веб-сайтов проверили вывод консоли во время их рендеринга и обнаружили сотни запросов с ошибками. Это создало впечатление, что проблема с отслеживанием распространена на веб-сайтах, и мы проверили ее, сравнив расхождения между менеджером рекламы и другими встроенными адаптерами prebid. Сайты с большим количеством ошибок имели высокие расхождения и для всех остальных адаптеров.
Несмотря на то, что оптимизация существует, мы не увидели заметного влияния на расхождение при использовании разных стилей отслеживания (XHR-запрос, прозрачный пиксель 1x1, скрытый пиксель 0x0 и т. д.).
Поняли, что один из сайтов использовал старую версию PreBid, которая отличалась на 10 минорных версий от обычно используемой. После обновления версии расхождение значительно уменьшилось. Хотя пришлось иметь дело с кешированной неисправной версии в течение нескольких дней после релиза. Кроме того, мы поместили версию скрипта отслеживания в данные импрешена, чтобы отслеживать такие проблемы в будущем.
Все пиксели показов имели уникальные URL-адреса, поскольку они содержали хешированный параметр идентификатора показа.
Основным препятствием было объективно оценить, правильно ли работает наш код и отслеживает ли нужные данные. Вот гипотезы, которые мы оценили:
Когда мы показывали несколько объявлений с разных бирж по одной и той же ставке, все объявления учитывались как один показ. Мы исправили процесс дедупликации, чтобы учитывать (dsp_name + Impression_id) для поиска повторяющихся показов.
Сравнили файлы журналов балансировщика нагрузки с необработанными данными о показах, они совпали.
Прежде всего, мы покрыли эндпоинт отслеживания процедурами мониторинга кодов состояния и сбора исключений. Никаких ошибок при обработке запросов они не показывали. Во-вторых, развернули дополнительный вспомогательный сторонний трекер (Snowplow), который вообще не был подключен к нашей инфраструктуре. Сравнили данные между этими трекерами, и они совпали.
Инфраструктура отслеживания операций, у которой нет проблем, вызывающих расхождения с партнерами.
Автоматический мониторинг расхождений, визуализированный с помощью информационных панелей Grafana.
Зеркальный сторонний трекер, который используется для оценки эффективности основного.
Сборщик аналитики со стороны PreBid, который фиксирует все рендеры рекламы.
Отправь заявку