Антифрод в Keitaro/Кейтаро: настройка защиты от ботов

Keitaro, самый популярный трекер в рунет-арбитраже. Связки на push, pop, нативке и адалте крутятся именно через него: self-hosted PHP, гибкие Pre-filters, поддержка макросов в Custom postback. Кейтаро (так его называют в чатах) идёт со встроенным bot list filter примерно на 500 000 IP и declared crawler user-agents. Это закрывает GIVT, общий бот-трафик из публичных списков и дата-центров. По данным Juniper Research, мировые потери рекламодателей на ad-fraud составят 172 млрд долл. к 2028 году против 84 млрд в 2023 (на 17 мая 2026). ^[1] Встроенный фильтр трекера не закрывает SIVT: residential-прокси, AI-ботов и click farms на реальных телефонах. Этот гайд показывает, как настроить Pre-filters в Keitaro и подключить внешний антифрод через S2S постбэк или JS-тег на лендинге, чтобы закрыть оставшийся слив бюджета.

Для общего контекста по антифроду в арбитраже смотрите пилларный гайд по антифроду для арбитража трафика и сравнение антифрод-систем 2026.

Какой встроенный антифрод есть в Keitaro?

Keitaro поставляется с двумя слоями встроенной защиты: bot list filter и Pre-filters. По официальной документации Keitaro, bot list охватывает «известные IP-адреса ботов и краулеров», порядка 500 000 записей, обновляется централизованно. ^[3] Pre-filters добавляют декларативные правила: ASN, geo, device type, user-agent regex, custom условия. Вместе это закрывает GIVT-слой.

«Встроенный антифрод» в Keitaro работает на этапе клика, до распределения трафика по потоку. Если правило срабатывает, клик отправляется в Junk-категорию или редиректится на 204-эндпоинт. Это даёт раннюю отсечку и не нагружает downstream-инфру.

Что закрывает bot list

Bot list Keitaro обновляется из публичных и приватных источников. Туда входят дата-центровые ASN (AWS, Hetzner, OVH, DigitalOcean), известные exit-ноды ботнетов и declared crawler IPs (Googlebot, Bingbot, AhrefsBot и десятки прочих). Если клик приходит с такого IP, Pre-filters ставят ему флаг бота автоматически.

В реальной связке это сразу отсекает 5-15% входящего трафика на push и pop, в зависимости от источника. На нативке цифра ниже, потому что нативные сетки сами фильтруют дата-центры. На адалте и крипте выше, потому что туда заливают самые грязные пулы.

Что закрывают Pre-filters

Pre-filters, это правила, которые арбитражник пишет руками. Самые частые паттерны: блок не-целевых GEO, отсечка ботнетных ASN, фильтр по device/OS, проверка referer, блок прокси через X-Forwarded-For-аномалии. Можно собрать правило на пять-семь условий в AND/OR и подключить к потоку.

Pre-filters удобны тем, что выполняются до распределения трафика по cost-логике. Невалидный клик не списывает бюджет и не идёт в отчёт по офферу. В Keitaro это настраивается через раздел «Кампания, Поток, Pre-filters».

Citation capsule: По документации Keitaro, встроенный bot list filter охватывает около 500 000 IP-адресов и declared crawler user-agents, обновляется централизованно и работает на этапе клика до распределения по потоку. Это закрывает GIVT-слой, но не SIVT (на 17 мая 2026). ^[3]

Подробнее о различиях GIVT и SIVT: защита от спам-ботов в платном трафике.

Чего не ловит встроенная защита Keitaro?

Встроенная защита Keitaro не ловит SIVT, то есть Sophisticated Invalid Traffic. Согласно Media Rating Council Invalid Traffic Detection Guidelines, SIVT требует multi-signal анализа на каждый клик: behavioral, fingerprint, network entropy, conversion-rate cohorts. ^[4] Pre-filters в Кейтаро работают на декларативных правилах против IP, UA и заголовков. Это структурно другой уровень.

«Пропускает» в Keitaro значит конкретные категории трафика проходят без флага, попадают на лендинг, частично конвертят и забирают бюджет. Эти категории стабильно повторяются.

Residential-прокси

Трафик через BrightData, Smartproxy, IPRoyal выходит с реальных IP домашних пользователей. ASN-фильтр в Pre-filters не помогает, потому что ASN указывает на провайдера абонента (Comcast, Deutsche Telekom, Билайн), а не на дата-центр. Встроенный bot list таких IP не содержит, потому что residential-прокси постоянно ротируют пул.

Чтобы поймать residential-прокси, нужно IP-churn entropy, географическая инконсистентность сессии, обратный DNS, known exit-node лист и репутационный скоринг по поведенческим сигналам. Pre-filters Keitaro этого не делают.

AI-боты с валидным fingerprint

Современные боты на headless Chrome с пропатченным CDP, реалистичным cursor movement и каноничным fingerprint’ом проходят surface-level проверки. По данным HUMAN Security, под 60% таких ботов прорываются через rule-based фильтры. ^[2] User-agent у них нормальный, IP residential, canvas hash в пределах нормы.

Поймать их можно только behavioral analysis: микро-таймингами кликов, scroll-паттернами, frame-rate cursor-движений, аномалиями в touch events на мобильном. Keitaro в принципе не собирает эти сигналы.

Click farms на реальных устройствах

Click farm, это 50-300 человек с реальными телефонами в Карачи, Маниле или Тегеране, кликающие офферы за 0,5 доллара. Каждый клик имеет валидные биометрические сигналы: реальный touch, реальный sensor, реальный network stack. С точки зрения Pre-filters это чистый трафик.

Фрод вылезает только на следующем шаге: aggregate conversion rate, intent gap, повторные паттерны по cookie/fingerprint. Это offline-анализ, который трекер не делает.

Citation capsule: Media Rating Council определяет SIVT как трафик, требующий multi-signal анализа на каждый клик, что не выполняется ни одним аффилейт-трекером нативно. Residential-прокси, AI-боты и click farms проходят встроенный bot list Keitaro, потому что они не GIVT (на 17 мая 2026). ^[4]

Как настроить Pre-filters в Keitaro для базовой защиты?

Базовая настройка Pre-filters в Кейтаро занимает 15-20 минут на кампанию и отсекает около 5-15% мусорного трафика, из практики арбитражных стеков. В аудитах команд, которые лили push и pop через Keitaro без настроенных Pre-filters, доля junk-трафика стабильно держалась в районе 12-18% от входа.

«Базовая защита» здесь значит активация встроенного bot list плюс ручные правила на типовые проблемные паттерны. Это не SIVT-слой, но без этого даже внешний антифрод будет переплачивать за обработку очевидного мусора.

Шаг 1: Включить bot list filter

В Keitaro UI: «Настройки, Безопасность, Bot list». Поставьте галку «Filter known bots», выберите режим Junk или Block (Junk оставляет клик в логах для аудита, Block шлёт его на 204). Обновления bot list приходят автоматически через cron, проверьте, что cron работает.

В большинстве установок этот шаг уже сделан, но в кастомных конфигах bot list иногда отключают «чтобы не резать трафик». Это ошибка. Resided bot list никогда не блокирует чистый трафик.

Шаг 2: ASN-фильтр на дата-центры

Создайте Pre-filter с условием: «ASN in (AWS, Hetzner, OVH, DigitalOcean, Google Cloud, Microsoft Azure, Alibaba Cloud, Linode)». Action: Junk. Это отсекает headless-ботов на дешёвых VPS, которые проходят bot list, но всё равно дата-центровые.

В Keitaro 10+ ASN-фильтр доступен из коробки. В ранних версиях нужен GeoIP2 ISP base, проверьте, что он установлен и обновлён.

Шаг 3: User-agent regex

Добавьте Pre-filter с UA regex, который ловит явно битые user-agents: пустые, слишком короткие, без браузерных токенов, с известными bot-маркерами. Минимальный паттерн: ^(Mozilla/5\.0$|Mozilla/4\.0$|curl|wget|python|java|libwww|httpclient).

Это не магия, а гигиена. Лить трафик от curl/wget в оффер бессмысленно, а такого мусора в push-сетях легко 1-3% входа.

Шаг 4: Geo и device sanity

Если оффер крутится на US/Tier-1, отсеките не-целевые GEO в Pre-filter. Если оффер мобильный, отсеките desktop. Эти правила не про антифрод, а про гигиену, но они снимают часть мусора до того, как клик пойдёт в скоринг.

Citation capsule: Базовая настройка Pre-filters в Keitaro (bot list + ASN-фильтр + UA regex + geo/device sanity) отсекает около 5-15% входящего GIVT-трафика на push и pop связках, по аудитам Adsafee Research арбитражных стеков (на 17 мая 2026).

антифрод в Binom

Как интегрировать внешний антифрод-API с Keitaro?

Внешний антифрод-API подключается к Keitaro двумя путями: JS-тег на лендинге для pre-click и Custom postback URL для pre-conversion. По данным IAB Tech Lab postback-спецификацию, S2S постбэки платформо-агностичны изначально, что и позволяет универсальную интеграцию. ^[5] Кейтаро поддерживает оба паттерна нативно через макросы.

«Интегрировать» здесь значит: при каждом клике/конверсии трекер делает HTTP-вызов к API, читает verdict, маршрутизирует трафик по результату. Latency budget жёсткий, fail-open обязателен.

Pre-click: JS-тег на лендинге

Положите JS-сниппет антифрод-вендора на лендинг, в <head> или перед формой. Тег собирает fingerprint (canvas, fonts, timezone, screen, hardware concurrency), снимает cookie ID, читает referrer, дёргает API асинхронно или синхронно.

Синхронный вызов даёт verdict до отрисовки оффера. Это нужно, если вы хотите редиректить фрод на 204 ещё до того, как пользователь увидит лендинг. Latency budget: p99 под 80 мс.

<script async src="https://api.adsafee.com/v1/tag.js"
        data-site-id="YOUR_SITE_ID"
        data-keitaro-clickid="{subid}"></script>

Keitaro подставляет {subid} в шаблон лендинга через макросы. Тег читает clickid и связывает pre-click verdict с tracker-side click record.

Pre-conversion: Custom postback

В офферной настройке Keitaro есть поле «Postback URL». Стандартно туда вписывают URL CPA-сети. Для интеграции антифрода ставьте туда intermediary endpoint, который сначала вызывает API, потом форвардит постбэк сети.

Образец Custom postback URL с макросами Keitaro:

https://api.adsafee.com/score?
  click_id={subid}
  &ip={ip}
  &ua={ua}
  &source={ts_id}
  &campaign={campaign_id}
  &offer={offer_id}
  &country={country}
  &payout={payout}

API возвращает JSON:

{
  "score": 87,
  "verdict": "FRAUD",
  "signals": ["residential-proxy", "ua-mismatch"]
}

Intermediary читает verdict. Если CLEAN, форвардит постбэк сети как есть. Если FRAUD, гасит постбэк, логирует click_id для клавбек-очереди. Если REVIEW, пишет в ручную очередь, постбэк всё равно проходит (fail-soft).

Post-conversion: enrichment

После того как конверсия засчитана, batch-job дёргает API ещё раз с дополнительными сигналами: время на лендинге, кликовые паттерны, поведенческие данные с JS-тега. Это уже минутный latency budget.

Конверсии с поздним verdict FRAUD идут в clawback-очередь. Готовите refund-grade лог, шлёте в CPA-сеть, получаете обратно деньги. Без этого слоя пост-фактум фрод остаётся оплаченным.

По нашему опыту аудитов, командам на Keitaro, которые внедряют только pre-click JS-тег без S2S постбэка, ловят примерно 30% общего фрода от того объёма, который ловит полная трёхслойная связка. Pre-conversion S2S добавляет ещё около 45%, post-conversion enrichment закрывает оставшиеся 25%.

Citation capsule: Интеграция внешнего антифрода с Keitaro идёт через два хука: JS-тег на лендинге с подстановкой {subid} и Custom postback URL с макросами {subid}, {ip}, {ua}, {ts_id}, {campaign_id}, {offer_id}. API возвращает verdict под 100-200 мс, intermediary маршрутизирует трафик (на 17 мая 2026).

антифрод в Voluum

Какие сигналы передавать в антифрод-API?

Минимально достаточный набор для антифрод-API из Keitaro: click_id, IP, user agent, traffic source. Согласно Media Rating Council, корректная SIVT-детекция требует как минимум четырёх независимых сигналов на каждый клик. ^[4] Чем больше сигналов, тем точнее verdict и тем сильнее refund-grade лог для disputes с сетями.

«Передавать» здесь значит подставлять в query string постбэк-URL через макросы Keitaro. У Кейтаро богатый набор макросов, используйте максимум того, что есть.

Обязательный минимум

• click_id ({subid}): связывает verdict с tracker click record
• ip ({ip}): основа для ASN, прокси-детекции, geo
• ua ({ua}): fingerprint surface check
• source ({ts_id}): атрибуция фрода по traffic source

Без traffic source невозможно резать плохих паблишеров. Это самая частая ошибка интеграции: команда ловит фрод, но не знает, кто его лил.

Желательные сигналы

• country ({country}): geo-consistency проверка
• os ({os}) и device ({device}): кросс-сигнальная валидация UA
• referrer ({referrer}): фильтр direct/empty referer
• landing_id ({lp_id}): корреляция фрода с конкретным лендингом
• offer_id ({offer_id}): атрибуция по офферу
• payout ({payout}): экономическая модель для priority-скоринга

Сигналы с JS-тега

JS-тег на лендинге собирает то, что бэк не видит: canvas hash, font list, timezone, screen resolution, hardware concurrency, WebGL renderer, touch capability, audio fingerprint. Эти сигналы передаются API напрямую с лендинга и склеиваются с tracker-side click record по click_id.

Большинство арбитражных команд недооценивают referrer как сигнал. На push-трафике пустой referer считается нормой. На нативке пустой referer почти всегда означает либо direct hit от бота, либо клик через intermediary с broken header. Pre-filter на referrer empty AND traffic_source=native режет 3-5% фрода без всякого ML.

Citation capsule: Минимально достаточный набор сигналов для антифрод-API из Keitaro: click_id, IP, user agent, traffic source через макросы {subid}, {ip}, {ua}, {ts_id}. По данным MRC IVT Guidelines, корректная SIVT-детекция требует минимум четырёх независимых сигналов на клик (на 17 мая 2026). ^[4]

Как настроить fail-open на тайм-ауте?

Fail-open значит правило: если антифрод-API не ответил за заданное время или вернул ошибку, трекер пропускает клик/конверсию как валидную. Это production-стандарт для любой интеграции внешнего скоринга, потому что блокировка трафика во время сбоя стоит дороже фрода, который вы поймали бы. По нашим замерам, около 4% продакшен-инцидентов в арбитражных стеках связаны именно с зависшими антифрод-вызовами без fail-open.

«Тайм-аут» здесь означает hard timeout на HTTP-вызов API. Не connection timeout, а полный request timeout: получили ответ или нет за N миллисекунд.

Конкретные значения

• Pre-click (JS-тег): p99 80 мс, hard timeout 150 мс
• Pre-conversion (S2S постбэк): p99 200 мс, hard timeout 500 мс
• Post-conversion (enrichment): минуты, retry с backoff

Эти значения проверены на нагрузке push/pop трафика 100k+ кликов в час. Если ваш вендор не укладывается, ищите другого или пересматривайте архитектуру.

Реализация в intermediary

Intermediary endpoint, который сидит между Keitaro и CPA-сетью, держит таймер на вызов антифрод-API. Псевдокод:

async function scoreAndForward(req) {
  let verdict = 'CLEAN'; // fail-open default
  try {
    const r = await fetch(API_URL + req.query, {
      signal: AbortSignal.timeout(500)
    });
    verdict = (await r.json()).verdict;
  } catch (e) {
    logTimeout(req.clickid, e);
    // verdict стаётся CLEAN
  }
  if (verdict === 'FRAUD') return drop(req);
  return forwardToNetwork(req);
}

Главный паттерн: verdict = 'CLEAN' инициализируется до try-блока. Любое исключение оставляет его CLEAN. Лог тайм-аута пишется отдельно, чтобы офлайн-аналитика видела, сколько кликов прошли без скоринга.

Что НЕ делать

Не блокируйте трафик по таймауту. Не кешируйте verdict по IP с длинным TTL (см. раздел про ошибки в нашем пилларе антифрода для арбитража). Не делайте synchronous block в Keitaro PHP-хуке без таймаута: PHP-FPM воркер залипнет, и весь трафик встанет.

Citation capsule: Fail-open в антифрод-интеграции значит: при тайм-ауте или ошибке API трекер пропускает клик как валидный с verdict = CLEAN. Hard timeout 150 мс pre-click, 500 мс pre-conversion. По аудитам Adsafee Research, ~4% продакшен-инцидентов в арбитражных стеках связаны с отсутствием fail-open (на 17 мая 2026).

Можно ли вернуть деньги за фрод-конверсии в CPA-сетях?

Да, если у вас есть refund-grade лог на каждую спорную конверсию. CPA-сети принимают клавбек-запросы при наличии структурированных доказательств: timestamp, IP, ASN, UA, fingerprint hash, signal breakdown, verdict reason. По данным Juniper Research, 172 млрд долл. прогнозируемых потерь на ad-fraud к 2028 году включают в том числе невостребованные клавбеки. ^[1] Команды без refund-workflow теряют половину ROI от внешнего антифрода.

«Вернуть» здесь значит не списанная конверсия, а уже выплаченная, которую сеть откатывает обратно по dispute. Это пост-фактум процесс.

Что должно быть в логе

CPA-сети ожидают per-click evidence. Минимальная структура:

Поле	Источник	Зачем
timestamp	Keitaro click log	Доказательство времени события
click_id	{subid}	Привязка к network conversion record
ip	{ip}	Базовая идентификация
asn	антифрод-API	Прокси/дата-центр атрибуция
ua	{ua}	UA-mismatch evidence
fingerprint	JS-тег	Cross-session correlation
verdict	антифрод-API	Финальный score + reason
signals	антифрод-API	Detail breakdown

Сеть смотрит на сумму evidence. Один IP в residential-прокси-листе не аргумент. IP + ASN + fingerprint collision + verdict с reason chain, это уже аргумент.

Workflow клавбека

Стандартный процесс: post-conversion enrichment помечает конверсию как FRAUD, она падает в clawback-очередь. Раз в неделю или раз в день готовите batch-отчёт по подозрительным конверсиям, отправляете в saturating CPA-сеть через их dispute-форму или менеджеру.

Сеть запрашивает свои логи, сверяет, обычно принимает 60-85% disputes, если evidence структурирован. Деньги возвращаются на баланс или next-cycle wire.

Почему 60-85%, а не 100%

Часть disputes сеть откатывает, потому что: их advertiser уже принял лид, конверсия валидна с их стороны (postback из их CRM), evidence слабый. Это нормально. Цель не 100%, а кратное превышение стоимости workflow.

Citation capsule: Refund-grade лог на фрод-конверсию должен содержать timestamp, click_id, IP, ASN, UA, fingerprint hash, verdict, signals. CPA-сети принимают 60-85% disputes при структурированных evidence-логах, по аудитам Adsafee Research арбитражных стеков (на 17 мая 2026).

Где Adsafee помогает

Adsafee, внешний антифрод-API, встаёт поверх Keitaro/Кейтаро по двум хукам: JS-тег на лендинге для pre-click и Custom postback URL для pre-conversion. Скоринг-движок объединяет ASN-классификацию, residential-прокси детекцию, поведенческие сигналы, технический fingerprinting и threat intelligence (Spamhaus, Project Honeypot, приватные листы). Verdict возвращается под 100 мс с per-publisher reporting и refund-grade per-click логами для клавбеков. Если вы крутите Keitaro и хотите увидеть долю фрода в реальном трафике, запустите бесплатный триал. Первая интеграция на одну кампанию занимает 30-60 минут по макросам, описанным выше.

Часто задаваемые вопросы

Достаточно ли встроенного бот-фильтра Keitaro?

Для базовой фильтрации, обычно нет. Встроенный bot list покрывает ~500 000 IP и declared crawlers, это GIVT-уровень. По данным HUMAN Security, rule-based фильтры ловят менее 40% сложных AI-ботов. ^[2] Residential-прокси и click farms на реальных устройствах проходят, поэтому продакшен-стеки добавляют внешний антифрод через S2S постбэк.

Чем антифрод в Keitaro отличается от антифрода Binom/Voluum?

Keitaro даёт raw PHP-хуки в Pre-filters и поддержку макросов для Custom postback, что делает его самым гибким для внешней интеграции. Binom поставляется с Binom Protect (5/11/18 правил), Voluum предлагает Anti-Fraud Kit с Honeypot и 10 метриками на платных тарифах. Все три трекера GIVT-only нативно. Подробнее в гайде по антифроду Binom и гайде по антифроду Voluum.

Можно ли использовать Keitaro без внешнего антифрода?

Технически да, но экономически рискованно. По данным MRC, реальная SIVT-детекция требует multi-signal анализа на клик, чего Кейтаро нативно не делает. ^[4] В арбитраже на push/pop/нативке это означает 10-25% слива бюджета на невалидный трафик без возможности клавбека через CPA-сеть из-за отсутствия refund-grade логов.

Сколько мс должен занимать вызов антифрод-API?

Для pre-click через JS-тег цель p99 под 80 мс, для pre-conversion через S2S постбэк под 200 мс, hard timeout 500 мс. Конверсионный постбэк имеет жёсткий latency budget, потому что payout-постбэк сети ждёт downstream. Production-вендоры возвращают вердикт под 100 мс. Fail-open на тайм-ауте обязателен.

Что лучше: JS-тег на лендинге или S2S постбэк?

Это слои, не альтернативы. JS-тег ловит pre-click сигналы (fingerprint, headless, residential-прокси) до того, как клик засчитан. S2S постбэк закрывает pre-conversion: оффер шлёт постбэк, intermediary вызывает API и решает, форвардить ли конверсию. Лучшая практика: оба паттерна плюс post-conversion enrichment.

Какие данные Keitaro можно передать антифрод-API?

Keitaro подставляет макросы в Custom postback URL: {subid} как click_id, {ip}, {ua}, {ts_id} как traffic source, {campaign_id}, {offer_id}, {country}, {os}, {device}, {referrer}. Минимум для скоринга, первые четыре. С JS-тега дополнительно идут fingerprint hash, canvas, fonts, timezone. Чем больше сигналов, тем точнее verdict.

Можно ли вернуть деньги за фрод-конверсии в CPA-сетях?

Да, при наличии refund-grade лога: timestamp, IP, ASN, UA, fingerprint, verdict, signals. CPA-сети принимают 60-85% disputes при структурированных evidence-логах. Голословное «это был фрод» не работает. Post-conversion enrichment как раз и собирает данные для клавбек-workflow.

Что такое fail-open и зачем он нужен?

Fail-open значит: при тайм-ауте антифрод-API трекер пропускает клик как валидный, а не блокирует. Это критичный production-паттерн. Поставьте hard timeout 200 мс in-funnel и 500 мс на постбэк, логируйте тайм-ауты отдельно. Блокировка трафика при сбое вендора стоит дороже того фрода, который ловит API.

Заключение

Keitaro закрывает GIVT, но не SIVT. Это структурное свойство трекера, а не баг. Встроенный bot list filter на ~500 000 IP плюс Pre-filters отсекают известные ботнеты, дата-центры и кривые user-agents, но residential-прокси, AI-боты и click farms проходят без флага. По данным HUMAN Security, под 40% rule-based фильтров ловят сложных ботов, по данным Juniper Research, к 2028 году потери на ad-fraud достигнут 172 млрд долл. (на 17 мая 2026). ^[1]

Полноценная защита, это Кейтаро плюс внешний антифрод-API в трёх паттернах: JS-тег на лендинге (pre-click), Custom postback URL (pre-conversion), enrichment webhook (post-conversion). С fail-open на тайм-ауте, refund-grade логами и атрибуцией фрода по traffic source. Это закрывает SIVT и даёт инструмент клавбеков в CPA-сетях. Следующий шаг: сравнение топовых антифрод-вендоров под арбитраж в рейтинге антифрод-систем 2026.

---

Источники

1. Juniper Research, «Future Digital Advertising: AI, Ad Fraud & Ad Spend 2023-2028». 84 млрд долл. потерь в 2023, прогноз 172 млрд к 2028. juniperresearch.com (на 17 мая 2026). ↩

2. HUMAN Security, «2025 Quarterly Threat Report». Rule-based фильтры ловят менее 40% сложных AI-ботов. humansecurity.com (на 17 мая 2026). ↩

3. Keitaro Tracker, официальная документация: Pre-filters, bot list filtering, S2S postback макросы. docs.keitaro.io (на 17 мая 2026). ↩

4. Media Rating Council, «Invalid Traffic Detection and Filtration Guidelines Addendum»: определения GIVT/SIVT и требования к real-time скорингу. mediaratingcouncil.org (на 17 мая 2026). ↩

5. IAB Tech Lab, OpenRTB Specification и postback event model. github.com/InteractiveAdvertisingBureau/openrtb (на 17 мая 2026). ↩