Ретраи запроса ставки в RTB: что повторять после 204 и nbr

Повторять запрос ставки (делать ретрай) стоит только при технических сбоях: соединение не установилось, партнер вернул ошибку сервера, и при этом в бюджете tmax еще есть время. Отказ от ставки — HTTP 204 или ответ с кодом nbr — повторять бессмысленно, а при причинах вроде «бот» или «невалидный запрос» и вредно.

#Как покупатель говорит «нет»: 204, пустой ответ и nbr

Спецификация OpenRTB 2.5 задает три HTTP-кода для обмена ставками:

В заметках к OpenRTB 2.6 IAB перечисляет формы no-bid, которые принимают многие биржи:

{}
{"id": "1234567890", "seatbid": []}
{"id": "1234567890", "seatbid": [], "nbr": 2}

Плюс пустой ответ с кодом 204 — самый экономный по трафику. Только последний вариант сообщает причину. Поле BidResponse.nbr необязательное: многие DSP его не заполняют, и 204 без причины — просто «не ставлю», без подробностей.

#Откуда берутся коды nbr

Расшифровка каждого кода — в статье глоссария nbr. Для ретраев достаточно знать, какие коды вообще встречаются. Коды 0–10 заданы в OpenRTB 2.5 (раздел 5.24). Версия 2.6 своих перечислений не содержит и ссылается на список OpenRTB 3.0: там те же 0–10 и новые 11–17 про ads.txt, ads.cert, нехватку времени и schain. Значения от 500 — частные коды биржи, их смысл согласуют заранее. Причины проигрыша уже сделанной ставки — другой список, его разбирает статья «Почему проиграл аукцион».

#Код → что значит → что делать

Главная мысль таблицы: почти все коды nbr описывают свойство запроса, пользователя или площадки. За миллисекунды оно не меняется, поэтому повтор тратит ресурсы обеих сторон и ничего не приносит.

#Где ретрай уместен, а где вредит

Различайте два вида повторов.

Внутри аукциона. SSP или биржа повторяет запрос к партнеру, пока показ еще ждет. Уместно, только если первая попытка упала до того, как партнер начал обработку: отказ в соединении, обрыв при установке TLS, мгновенный 503. Если же запрос ушел и партнер не ответил вовремя, повтор почти наверняка тоже не успеет — время уже потрачено.

Между аукционами. SDK или страница запрашивает рекламу заново, потому что предыдущая попытка не заполнила место. Здесь ретрай — по сути новый аукцион, и он должен идти с задержкой, а не в цикле. No-fill не ошибка: если подряд три пустых ответа, четвертый запрос через 100 мс почти наверняка тоже будет пустым.

Чем вредит неаккуратный ретрай:

• Дубли показов. Покупатель получил первый запрос, ответил, но ответ потерялся; повтор с новым id выглядит как второй показ — покупатель может дважды учесть частоту или дважды поставить на один показ.
• Лавина. Партнер тормозит под нагрузкой, все ретраят — нагрузка удваивается, и он падает окончательно.
• Опоздание. Ретрай съедает время, которое нужно на ответ вверх по цепочке, и показ теряется целиком.

#Правила безопасного ретрая

1. Только идемпотентные сбои. Повторять можно ошибки, при которых партнер точно не обработал запрос или повтор не создаст нового события: отказ соединения, 502/503 до чтения тела. No-bid и nbr не повторять.
2. Одна-две попытки, не больше. Каждая следующая попытка успешна реже предыдущей, а стоит столько же.
3. Только в остатке tmax. Перед повтором проверить: хватит ли оставшегося времени на сеть туда, обработку партнера, сеть обратно и собственный ответ.
4. Тот же BidRequest.id. Повтор того же аукциона — тот же показ, поэтому идентификатор не меняется: так покупатель может склеить дубль. Если по договоренности с партнером повторы помечают (например, в ext), это делают явно — стандартного поля для пометки нет.
5. Дедупликация на приеме. Обработчики ответов и уведомлений должны выдерживать повторную доставку: ключ — ID запроса и ID показа.
6. Экспоненциальная задержка с джиттером — для повторов между аукционами и для фоновых операций вроде отправки уведомлений:

задержка(n) = случайное(0; min(потолок; база × 2^n))
n = 0, 1, 2…   база = 200 мс   потолок = 10 с

Случайная составляющая (джиттер) не дает тысячам клиентов повторять запрос синхронно, в одну и ту же миллисекунду. Для уведомлений о биллинге заметки к OpenRTB 2.6 советуют повторять вызов, если ответ не 200 и не 204, — например, раз в 10 секунд в течение минуты, — а принимающую сторону просят сделать обработчик идемпотентным, чтобы не считать показ дважды.

7. Circuit breaker. Если доля ошибок партнера превысила порог, запросы к нему на время прекращаются полностью, затем пропускается пробная порция. Это защищает и партнера, и собственный аукцион: зачем ждать таймаута от того, кто сейчас не отвечает никому.

#Пример: хватит ли времени на ретрай

Иллюстративный пример. SSP получила запрос с tmax = 300 мс и проводит аукцион среди партнеров.

Случай А. Партнер отказал в соединении через 15 мс. Осталось 245 мс — больше таймаута в 120 мс. Один повтор возможен, и даже при неудаче аукцион закончится вовремя: 15 + 120 = 135 мс < 260.

Случай Б. Партнер не ответил за 120 мс. Повтор с тем же таймаутом закончится на 240 мс — формально в бюджете. Но первая попытка уже показала, что партнер медленный; вероятность, что вторая успеет, низкая, а остальные ответы ждут. Здесь правильнее не повторять.

Случай В. Партнер вернул nbr: 5 (датацентр) за 30 мс. Времени много, но повтор бессмыслен: IP пользователя за это время не изменится.

#Метрики, без которых ретраи вслепую

Если успешность ретраев близка к нулю, их нужно выключать: они только добавляют нагрузку. Связь этих метрик со ставками и показами удобно смотреть в воронке RTB.

#Таймауты и отказы на бирже Ibiza

Биржа Ibiza опрашивает демандов общего аукциона параллельно и не повторяет запрос к партнеру после ошибки или таймаута. У каждого партнера свой таймаут, а общий срок аукциона — меньшее из настройки биржи и остатка tmax источника за вычетом резерва. В исходящем запросе биржа уменьшает tmax, чтобы деманд видел реальное время на ответ, а не исходное значение SSP. Каждый партнер работает через свой circuit breaker, а число одновременных соединений к нему ограничено, чтобы тормозящий деманд не утянул за собой весь аукцион. Ответ 204 от деманда — no-bid, а не ошибка; любой код кроме 200 и 204 — ошибка. Источнику биржа отвечает 204, если ставки нет или источник выключен, и 400 на неразбираемый запрос. DSP Ibiza отказывается от ставки ответом 204 без поля nbr, в том числе при перегрузке, и отвечает 400 на запросы без обязательных полей. Коды ответов для источников — в документации «Подключение SSP».