Настройка Header Bidding для Accelerated Mobile Pages (AMP) требует специфической архитектуры, основанной на компоненте amp-ad и функции Real-Time Config (RTC). В отличие от стандартных веб-сред, AMP ограничивает произвольное выполнение JavaScript, что означает, что вы должны использовать поддерживаемый фреймворк поставщика для связи с партнерами по спросу. Настроив теги Google Ad Manager (GAM) для включения RTC, вы позволяете браузеру получать ставки от нескольких рекламных бирж одновременно до завершения запроса объявления.
Эта стратегия реализации гарантирует, что ваш сайт сохранит высокую производительность, участвуя при этом в конкурентных торгах. Поскольку страницы AMP часто обслуживаются из кэша Google AMP, поток запросов объявлений должен быть максимально оптимизирован, чтобы избежать задержек. Издатели, которые делают это правильно, видят улучшение показателей заполняемости, поскольку рекламный сервер получает больше контекста о доступном инвентаре перед выбором финального креатива.
Как работает Header Bidding на AMP?
На традиционном сайте Header Bidding часто управляется с помощью скрипта-обертки, такого как Prebid.js. На AMP среда контролируется для обеспечения производительности. Процесс основан на RTC, который позволяет среде выполнения AMP отправлять запросы к набору конечных точек, определенных в вашей конфигурации объявлений. Как только ответы поступают, данные передаются на рекламный сервер, который затем решает, какой креатив победит, основываясь на самой высокой ставке.
Среда выполнения AMP выступает в роли оркестратора. Когда страница загружается, среда выполнения идентифицирует конфигурацию RTC внутри тега объявления. Затем она отправляет параллельные запросы указанным партнерам по спросу. Эти партнеры возвращают JSON-ответ, содержащий ключи таргетинга, которые внедряются в финальный запрос объявления к GAM. Весь этот процесс происходит в фоновом режиме, сохраняя пользовательский опыт чистым и быстрым.
В типичном развертывании у вас может быть три или четыре конкурирующих участника торгов. Среда выполнения AMP управляет этими запросами со строгими ограничениями по времени. Если участник торгов не отвечает в течение определенного окна, среда выполнения продолжает работу без его ставки, чтобы гарантировать, что рекламный слот не останется пустым. Этот приоритет пользовательского опыта над завершением индивидуальной ставки — то, что делает рекламный фреймворк AMP уникальным.
Каковы основные требования для настройки?
- Функционирующая учетная запись Google Ad Manager с определенными соответствующими рекламными блоками.
- Список поддерживаемых поставщиков Header Bidding, предоставляющих конечную точку, совместимую с RTC.
- Доступ к HTML вашей страницы AMP для изменения конфигураций тегов amp-ad.
- Действительные файлы конфигурации JSON для конечных точек RTC.
- Безопасный хостинг HTTPS для всех конечных точек участников торгов, чтобы предотвратить ошибки смешанного контента.
Перед началом убедитесь, что ваши рекламные блоки правильно сопоставлены в Google Ad Manager. Если идентификаторы рекламных блоков не совпадают с тем, что определено в вашей конфигурации RTC, сигналы ставок не достигнут нужного инвентаря. Вы также должны проверить, поддерживают ли выбранные вами участники торгов протокол AMP, так как не у каждого партнера по спросу есть интеграция, совместимая с RTC.
Документация здесь является ключевым моментом. Ведите учет того, какой участник торгов соответствует какому URL конечной точки. Если вы управляете несколькими сайтами, ведите мастер-файл ваших конфигураций. Это позволяет избежать распространенной ловушки использования устаревших конечных точек, которые могут привести к сбоям запросов или снижению производительности в часы пиковой нагрузки.
Как реализовать конфигурацию RTC?
Для начала вы должны добавить атрибут rtc-config к вашим тегам amp-ad. Этот атрибут содержит объект JSON, в котором перечислены поставщики, которых вы хотите опрашивать. Каждый поставщик предоставляет определенную структуру URL запроса. Убедитесь, что ваш сервер, на котором размещены эти конфигурации, следует строгим политикам безопасности, требуемым AMP, особенно в отношении заголовков CORS и форматов ответов.
Структура JSON для атрибута rtc-config обычно следует определенной схеме. Вы определяете поставщиков и их соответствующие URL запросов внутри объекта конфигурации. Важно сохранять объект легким. Добавление слишком большого количества участников торгов может увеличить размер запроса и потенциально замедлить вызов объявления, что может негативно повлиять на общую производительность загрузки страницы.
Как только конфигурация добавлена в HTML, среда выполнения AMP берет на себя остальное. Вам не нужно писать пользовательский JavaScript для запуска этих вызовов. Просто убедитесь, что ваша страница соответствует требованиям валидации AMP после добавления тегов. Небольшая ошибка в синтаксисе JSON приведет к тому, что рекламный компонент молча не сработает, поэтому всегда проверяйте свой код с помощью официального инструмента валидации AMP.
Google AMP Cache — это прокси-сеть доставки контента, которая обслуживает действительные страницы AMP для повышения скорости загрузки.
Google Search Central
Как Alien Road применяет эту технологию
В Alien Road мы следуем строгому жизненному циклу развертывания для наших клиентов. Мы начинаем с аудита текущего рекламного стека, чтобы определить, какие партнеры по спросу предлагают наилучшую доходность для их конкретного профиля трафика. Затем мы создаем тестовую среду для проверки времени отклика RTC, так как медленные ответы участников торгов могут негативно повлиять на показатели загрузки страницы. После проверки мы отправляем конфигурацию на рабочие страницы AMP и отслеживаем показатели заполняемости в панели управления Google Ad Manager.
В типичном проекте мы часто обнаруживаем, что у клиентов настроено слишком много участников торгов. Мы работаем над оптимизацией этого процесса, выбирая только тех партнеров, которые обеспечивают стабильные результаты. Затем мы настраиваем оповещения мониторинга в Google Ad Manager, чтобы обнаруживать, если какой-либо конкретный участник торгов начинает возвращать ошибки или высокую задержку. Сохраняя конфигурацию компактной, мы гарантируем, что доходы от рекламы остаются высокими, не жертвуя скоростью, которая делает AMP ценным.
Каких распространенных ошибок следует избегать?
Частая ошибка — неспособность управлять настройками тайм-аута для участников торгов. Если участнику торгов требуется слишком много времени для ответа, это задерживает всю доставку рекламы, что вредит вашему пользовательскому опыту и потенциально вашим показателям скорости страницы. Другая проблема — неправильная конфигурация CORS на стороне поставщика, из-за чего браузер блокирует запрос. Всегда проверяйте, доступны ли ваши конечные точки и возвращают ли они действительный JSON.
Еще одна распространенная ошибка — игнорирование влияния блокировщиков рекламы на вашу конфигурацию. Хотя RTC происходит на уровне «сервер-сервер» или «среда выполнения-участник торгов», некоторые пользователи все равно могут блокировать запросы объявлений самостоятельно. Всегда тестируйте свою реализацию в чистой среде браузера без расширений, чтобы убедиться, что базовый рекламный блок загружается, даже если сигналы Header Bidding по какой-то причине не срабатывают.
Как проверить ваши данные о производительности?
После внедрения ваше основное внимание должно быть сосредоточено на отчете об участии в торгах в Google Ad Manager. Этот отчет покажет вам, как часто ваши участники торгов возвращают действительный ценовой сигнал. Если вы заметите большое расхождение между количеством запросов и количеством возвращенных ставок, вам может потребоваться настроить параметры тайм-аута или пересмотреть список участников торгов.
- Используйте инструмент AMP Validator, чтобы убедиться, что ваши новые атрибуты amp-ad не нарушают валидность страницы.
- Проверьте консоль браузера на наличие сетевых запросов к вашим определенным конечным точкам RTC.
- Просматривайте отчеты об участии в торгах внутри Google Ad Manager.
- Запустите A/B-тест, сравнивая новую настройку с предыдущими данными о производительности рекламы.
- Отслеживайте Core Web Vitals, чтобы убедиться, что конфигурация рекламы не вызывает сдвигов макета.
С чего начать на этой неделе
Начните с определения одной целевой страницы с высоким трафиком для тестирования вашей новой конфигурации RTC. Не применяйте изменения ко всему сайту сразу. Убедитесь, что рекламные блоки правильно отображаются в инструменте предварительного просмотра Google Ad Manager, затем отслеживайте показатели дохода в течение 48 часов, чтобы подтвердить, что настройка Header Bidding дает ожидаемые результаты, прежде чем масштабировать ее на весь инвентарь вашего сайта.