Как спай-сервисы собирают данные о рекламе

Главное: спай-сервисы (AdPlexity, Anstrex, Spy.House, BigSpy и их коллеги по цеху) собирают свои базы в основном через регистрацию в качестве паблишеров в сторонних push- и нативных сетях, а дальше снимают каждый bid response, который прилетает на их собственный JavaScript. Сети закрывают на это глаза не случайно: они зарабатывают на одной и той же активности дважды, сначала с оригинального рекламодателя, потом с тех, кто запускает копи. Поэтому реальная защита не в том, чтобы «спрятать креатив» (это невозможно против паблишера, которому платят за показ), а в том, чтобы снизить ценность того, что утекает: узнаваемость бренда, при которой копии выглядят жалко, подписанные click URL с коротким TTL, серверная персонализация лендинга, бот-детект на краю воронки и собственный аудит кампаний с реальных carrier-ASN мобильных прокси — той же точки обзора, с которой работают спай-операторы.

Спай-сервисы для арбитражников (AdPlexity, Anstrex, AdSpy, BigSpy, Spy.House, Mobidea и длинный хвост более мелких конкурентов) продают доступ к базам из миллионов креативов с фильтрами по ГЕО, вертикали, рекламодателю и дате. В публичных текстах про них всё обычно заканчивается на «они собирают рекламу из рекламных сетей», и дальше идут обзоры. А вот реальные механизмы сбора технически интересные, защиты от них неочевидные, и серьёзного материала ни про то, ни про другое практически нет.

Пять механизмов сбора данных

Современную базу спай-сервиса наполняют пять принципиально разных механизмов. У каждого свой инженерный профиль и своя история с защитой:

1. Инфильтрация в паблишеры: регистрация в качестве паблишера в сторонних push/native-сетях, чтобы снимать каждый креатив, который сеть отдаёт. Главная тема этой статьи.
2. Перехват push-подписок: эксплуатация протокола Web Push, чтобы вытаскивать зашифрованные payload’ы уведомлений через service worker под контролем оператора.
3. Публичные библиотеки рекламы и парсинг соцсетей: Meta Ad Library, TikTok Creative Center, Google Ads Transparency Center плюс фарм-аккаунты, которые скроллят ленту ради того, чего в библиотеках нет.
4. MITM in-app SDK: фермы рутованных Android-устройств, перехватывающие трафик рекламных SDK от AppLovin MAX, Google AdMob, ironSource и коллег.
5. Краулинг лендингов и воронок: проход по click-цепочке через трекеры, клоакеры и прелендеры, чтобы вытащить оффер, аффилиатскую сетку, трекерный софт и полную реверс-инженерную картину воронки.

Ментальная модель

Доминирующий механизм для push-, нативных, inpage- и попандер-спаев структурно самый простой: оператор сам становится паблишером.

Представь небольшой трёхэтажный дом. Одна стена выходит на оживлённое шоссе, другая на тихий боковой проезд. Хозяин решает, как нарезать эти стены под рекламу: десять панелей плотно по всей шоссейной стене (много дохода, дом выглядит уродски, посетители реже возвращаются) или один аккуратный баннер на боковой стене (дохода меньше, дом всё ещё выглядит как дом). Вот эта «нарезка» (что и как ты выставляешь под рекламу) и есть то, что в ad-tech называют инвентарём.

Хозяин выставляет конкретный вариант доступного пространства. Рекламная сеть подписывает контракты с обеих сторон: с хозяином, чтобы наполнять слоты, и с брендами, чтобы поставить туда рекламу. Сеть занимается матчингом и забирает свой процент.

Мэппинг на ad-tech:

Это твоя стена. Ты её сдаёшь. Тебе за неё платят. И ты прекрасно видишь, какой именно билборд на ней висит и когда. Всё, что спай-база продаёт как «конкурентную разведку», вытекает из этого одного факта.

Два термина из жаргона, которые встретятся ниже (поясняю один раз и больше не возвращаюсь): вертикаль — это ниша, в которой работает рекламодатель (финансы, страхование, e-commerce); DSP — это buyer-side платформа, через которую рекламодатель реально покупает инвентарь на real-time аукционах. Если это всё в новинку, канонический источник по протоколам — IAB Tech Lab , а основы по Wikipedia про real-time bidding можно освоить за 10 минут.

Три шага

1. Регистрируешься как паблишер. Стандартная форма онбординга в любой push/native-сети. Отдаёшь домен, принимаешь условия, ставишь JavaScript-тег сети или настраиваешь CNAME-сабдомен под push.
2. Гонишь трафик на инвентарь. Дешёвый попандер/редирект-трафик примерно по $0.50 за 1000 импрешнов или самосгенерированные посетители из фермы резидентных/мобильных прокси, которые гоняют реальные браузеры по шелл-странице. Каждый посетитель триггерит ad-вызов.
3. Снимаешь bid response. Сеть отдаёт метаданные креатива простым JSON. JavaScript паблишера (код, который написал сам оператор) читает ответ, отправляет его на коллектор оператора, а потом рендерит рекламу как обычно. Снаружи ничего не видно.

Заявленный масштаб у спай-сервисов вполне реалистичный при такой модели: Spy.House отчитывается о 12 миллионах креативов в день по 185+ странам, AdPlexity и Anstrex закрывают пересекающиеся списки по нейтиву, push-сетям и мобайлу. Одна операция, охватывающая 30 сетей, 50 шелл-сайтов и 95 ГЕО, спокойно набирает такие цифры.

Что реально летает по проводам

Технически вся механика сводится к одному HTTP-запросу и одному HTTP-ответу на один импрешн. И то, и другое полностью видно паблишеру, потому что запрос делает его же собственный JavaScript.

Типичный тег паблишера:

<script async
  src="//cdn.adnetwork.example/sdk.js"
  data-zone-id="1234567"></script>

На загрузке страницы SDK собирает ad-запрос. Если переписать его как curl, по проводам летит примерно следующее:

curl -G "https://srv.adnetwork.example/req" \
  --data-urlencode "zone=1234567" \
  --data-urlencode "geo=DE" \
  --data-urlencode "device=android" \
  --data-urlencode "browser=chrome" \
  --data-urlencode "ua=Mozilla/5.0 (Linux; Android 14; SM-S921B) AppleWebKit/537.36" \
  --data-urlencode "referer=https://shell-site.example" \
  --data-urlencode "screen=412x915" \
  --data-urlencode "lang=de" \
  --data-urlencode "ts=1737542890"

Сеть прогоняет отбор (real-time-bidding аукцион среди DSP для крупных бирж по стандартному протоколу IAB OpenRTB или прямой матчинг кампаний для push/native-специалистов) и возвращает выигравший креатив как JSON:

{
  "zone_id": 1234567,
  "campaign_id": 287465,
  "advertiser_id": 5821,
  "creative": {
    "title": "Stop overpaying for car insurance",
    "body": "Drivers in DE are switching — check rates now",
    "icon": "https://cdn.adnetwork.example/c/874513_icon.jpg",
    "image": "https://cdn.adnetwork.example/c/874513_main.jpg",
    "click_url": "https://trk.adnetwork.example/c?cid=287465&zid=1234567&sid=abc123&v=1.42"
  },
  "pricing": {
    "model": "cpc",
    "bid": 1.42,
    "currency": "USD"
  },
  "targeting_matched": {
    "geo": "DE",
    "carrier": "vodafone-de",
    "device_type": "mobile",
    "os": "android"
  }
}

Заголовок, текст, URL картинок, click destination, ID кампании, ID рекламодателя, цена бида и контекст таргетинга, по которому сработал матч — вся доставка рекламы в одном структурированном объекте. Дальше SDK паблишера рендерит креатив.

Перехват тут чистая механика. Паблишер контролирует JavaScript уровня страницы, который запускается до SDK сети; обёртка над fetch или шим над XMLHttpRequest видят всё:

// грузим до SDK сети
(function () {
  const origFetch = window.fetch;
  window.fetch = async function (input, init) {
    const res = await origFetch(input, init);
    const url = typeof input === 'string' ? input : input.url;
    if (url.includes('adnetwork.example')) {
      // отправляем копию ответа на коллектор, потом возвращаем SDK
      res.clone().json()
        .then(payload => navigator.sendBeacon(
          'https://collector.spy.example/p',
          JSON.stringify({ origin: location.hostname, ts: Date.now(), payload })
        ))
        .catch(() => {});
    }
    return res;
  };
})();

SDK получает идентичный ответ и рендерит рекламу как обычно. Коллектор получает полную запись. Посетитель видит рабочую рекламу. Ни один запрос не заблокирован, ни один ответ не подменён, ни одна метрика ошибок не дёрнулась.

Модели оплаты и что течёт из каждой

В разных сетях разные модели оплаты, и именно модель определяет, какие поля bid response несут полезный сигнал. Базовый словарь:

• CPM (cost per mille): рекламодатель платит за 1000 показов. Стандарт для push, попандера, большей части нейтива. PropellerAds, RichAds, Adsterra. Бид в долларах за 1000.
• CPC (cost per click): рекламодатель платит за клик. Часто на MGID, Taboola, Outbrain в нейтиве. Бид за клик.
• CPA (cost per action): рекламодатель платит за конверсию (регистрация, депозит, инсталл). Используется аффилиатскими сетями (AdCombo, MaxBounty, ClickDealer), редко напрямую рекламными сетями. Конверсия фиксируется на стороне сервера у рекламодателя, поэтому CPA-выплаты в bid response не светятся.
• CPI (cost per install): мобильный CPA, где действие представляет собой инсталл, аттрибутированный через MMP (AppsFlyer, Adjust, Branch).
• CPV (cost per view): видео, оплата за просмотр.

Больше всего разведданных течёт из CPC. Сумма бида работает как сигнал реального времени о том, сколько рекламодатель готов платить за клик в этом ГЕО и вертикали, и обновляется на каждом импрешне. Три месяца истории CPC-бидов по рекламодателю и ГЕО — это датасет конкурентной разведки, на который никто никогда не подписывался, но он накапливается просто как побочка штатного доступа паблишера к bid response.

В итоге внутреннее API спай-сервиса начинает экспонировать примерно такие эндпоинты:

curl -G "https://api.spy-internal.example/v1/bids" \
  -H "Authorization: Bearer $TOKEN" \
  --data-urlencode "advertiser_id=5821" \
  --data-urlencode "geo=DE" \
  --data-urlencode "carrier=vodafone-de" \
  --data-urlencode "model=cpc" \
  --data-urlencode "from=2026-04-19" \
  --data-urlencode "to=2026-05-19"

возвращающие временной ряд:

[
  {"ts":"2026-04-20T08:14Z","creative_id":874513,"campaign_id":287465,"bid":0.78},
  {"ts":"2026-04-21T08:14Z","creative_id":874513,"campaign_id":287465,"bid":0.84},
  {"ts":"2026-04-22T08:14Z","creative_id":874513,"campaign_id":287465,"bid":0.91},
  {"ts":"2026-04-23T08:14Z","creative_id":891204,"campaign_id":289103,"bid":1.12},
  {"ts":"2026-04-24T08:14Z","creative_id":891204,"campaign_id":289103,"bid":1.18}
]

Фронтенд коммерческого спай-сервиса работает поверх ровно такой структуры. Покупатель видит дропдауны фильтров и графики динамики бидов; под капотом тот же временной запрос к нормализованной таблице бидов, которая наполняется импрешн за импрешном тем самым JS-перехватчиком сверху.

CPM меньше течёт на одном импрешне, но полезен в агрегате. Один CPM-бид выражает готовность платить за тысячу показов (доли цента за каждый) и сам по себе мало что говорит о том, сколько рекламодатель считает за клик или конверсию. Это произведение бюджета, соответствия аудитории и давления аукциона за единицу внимания, а не прямой замер экономической модели рекламодателя.

Важна распределённость. На тысячах залогированных импрешнов по одной кампании временной ряд CPM показывает форму бюджета (бид растёт = давление на масштабирование, бид падает = бюджет исчерпан или дейпартинг), ценовые уровни ГЕО (инвентарь DE может закрываться по $3 CPM, VN по $0.30 в той же вертикали, и так подсвечиваются реальные рыночные цены), приоритеты по аудиториям (на какие сегменты таргета идут самые высокие биды) и длительность кампании. Ничего из этого не видно на одном импрешне; всё это всплывает из пары недель накопленной истории.

CPA в bid response вообще не светится: спай-оператор не сидит на эндпоинте конверсии. Чтобы закрыть этот пробел, нужно проходить click destination через трекер, клоакер и offer wall, а это уже совсем другой механизм.

А зачем биду вообще быть в ответе? Логичный вопрос: спай-база читает число, которое сеть в принципе могла бы не отдавать. Пять пересекающихся причин:

1. OpenRTB этого требует. Поле price обязательно в схеме BidResponse.seatbid.bid. Сети, работающие поверх OpenRTB, наследуют эту прозрачность by design.
2. Верификация ревшары паблишера. Push- и нативные сети платят паблишерам 60–80% от бида рекламодателя. Спрятать число → потерять доверие паблишеров → уступить инвентарь конкуренту, который число показывает. Непрозрачность здесь оборачивается конкурентным минусом на стороне supply.
3. Оптимизация yield на стороне паблишера. Паблишеры выставляют CPM-флоры по зонам, A/B-тестят размещения, тюнят плотность креативов. Всё это требует bid-данных на каждый импрешн. Паблишер, который не видит, по какой цене закрывается его инвентарь, не может оптимизировать то, что продаёт.
4. Клиентский рендеринг. Push, нейтив, попандер, inpage рендерятся JavaScript’ом самого паблишера. Бид находится в том же payload, что URL креатива и click URL, которые тегу нужны для рендеринга в принципе, и сеть отдаёт его без дополнительных расходов.
5. Click URL часто содержит бид. Многие сети зашивают значение бида в click-tracking URL для биллинговой сверки между импрешном и кликом. Даже если убрать bid из верхнего уровня JSON, он прилетит в параметрах click URL.

Структурное исключение — это кейс walled gardens, разобранный ниже: Google AdSense агрегирует заработок паблишера до уровня категорий, а не показывает бид по каждому импрешну. Эта непрозрачность — одна из трёх защит, благодаря которым инфильтрация в паблишеры не работает против walled gardens. Сторонние сети могли бы это повторить, но не повторяют, потому что ценность прозрачности для онбординга и удержания паблишеров для них выше, чем издержки от долгосрочной индексации спай-сервисами.

OpenRTB и битстрим

Большинство бирж и многие крупные сети говорят на протоколе IAB OpenRTB. Bid request и response идут по публичной JSON-схеме (BidRequest, Imp, Seatbid, Bid) с задокументированными полями для домена рекламодателя (adomain), разметки креатива (adm), цены бида (price), ID креатива (crid) и таксономии категорий IAB (cat). Для спай-оператора OpenRTB-совместимая сеть оказывается самой удобной целью: имена полей предсказуемые, схема задокументирована, нормализация между сетями делается тривиально.

Практический пайплайн: по одному парсеру на каждый легаси/проприетарный формат сети, один общий парсер на все OpenRTB-совместимые сети, всё на выходе сводится к одной внутренней схеме. Кросс-сетевой поиск во фронтенде спай-сервиса представляет собой тонкую обёртку над этой нормализованной таблицей, поэтому у всех крупных спаев примерно один и тот же набор фильтров (ГЕО, девайс, ОС, браузер, формат рекламы, диапазон дат, кейворд по рекламодателю).

Путь проще: дашборд паблишера

Перехват на уровне трафика — общий случай. Частный случай ещё проще: дашборд паблишера в самой сети работает как поисковый UI поверх тех же данных. Залогинившись паблишером, оператор видит превью креативов, имена или ID рекламодателей, click destination’ы, суммы бидов по обслуженным импрешнам, распределение по времени суток, ID кампаний. Дашборд существует, чтобы легитимные паблишеры могли мониторить, что через них крутится, и проверять brand safety; для спай-оператора это самый удобный интерфейс выгрузки.

Где дашборд богатый, оператор пользуется дашбордом. Где он слабый, отсутствует или плохо задокументирован (особенно в push, где зашифрованный Web Push payload на уровне сети сложнее разобрать без контроля над service worker’ом, который его расшифровывает), пробел закрывается перехватом на уровне трафика. Если умножить это на 25–40 сетей, итоговая база получается структурированной, нормализованной и примерно соответствует живому состоянию всех push/native-кампаний по миру.

Множитель ГЕО

Паблишер из Бразилии видит бразильские креативы. Чтобы снимать креативы из 95 стран, оператору нужно одно из двух:

1. Реальные посетители из каждого ГЕО на шелл-сайты паблишеров, чтобы рекламная сеть отдавала гео-таргетированный инвентарь естественно. Операторы покупают дешёвый трафик (попандер, редирект, push) у других сетей и гонят через свои паблишерские сайты, чтобы триггерить ad-вызовы. Экономика: один редирект-импрешн стоит $0.0005 и даёт один обслуженный креатив для индексации.

2. Синтетические посетители через резидентные или мобильные прокси, которые исполняют страницу паблишера в реальном браузере, чтобы загрузить ad-тег и снять ответ. Этот путь дороже на импрешн, но даёт чистое carrier-сегментированное покрытие, которого редирект-трафик не даёт. Крупнейшие спай-маркетплейсы как раз поэтому кросс-продают вендоров мобильных и резидентных прокси как одну из основных категорий партнёров.

Измерение мобильного оператора важно отдельно: рекламные сети таргетируют по carrier ASN запрашивающего IP. Обычные серверные прокси проходят как «Wi-Fi/unknown» и полностью пропускают carrier-сегментированные кампании. Мобильные прокси через реальные эндпоинты оператора триггерят кампании, которые крутятся только под, скажем, Vodafone IT или Vivo BR, а это ровно тот инвентарь, за которым и охотятся, потому что узкий carrier-таргетинг указывает на прибыльную и тонко настроенную кампанию.

Почему рекламные сети структурно это терпят

Ответ лежит в экономической петле:

Рекламодатель платит Рекламной сети
        ↓
Рекламная сеть отдаёт креатив «паблишеру» спай-оператора
        ↓
Рекламная сеть платит ревшару спай-оператору  ← мотивация сети
        ↓
Спай-оператор логирует каждый креатив, продаёт доступ другим арбитражникам
        ↓
Другие арбитражники запускают копи-кампании через ту же рекламную сеть
        ↓
Рекламная сеть зарабатывает больше с рекламодателей (петля замыкается)

Сеть получает деньги дважды с одной и той же активности. Спенд оригинального рекламодателя финансирует выплату паблишеру-спаю. Спенд копирующего рекламодателя финансирует следующий цикл. У сетей нет мотивации детектить или банить таких паблишеров, и подтверждений этого union’а в открытом доступе хватает: PropellerAds держит у себя на корпоративном блоге отдельный индекс /blog/tag/spy-tools/, RichAds публикует листикл лучших push-спаев, Adsterra выкатывает собственный пост-рекомендацию по best ad-spy tools. Все трое разбирают одни и те же платформы, которые индексируют их же собственный инвентарь, нередко с аффилиатскими ссылками на эти спай-сервисы. Сети не противники спай-экосистемы, они её дополняющий слой.

Чем walled gardens отличаются

Механика выше работает на PropellerAds, RichAds, MGID и ещё 30+ сторонних push/native-сетях, потому что они сидят между рекламодателями и открытой экосистемой независимых паблишеров. Любой с доменом становится паблишером; у сети нет собственной first-party поверхности и нет способа доставить рекламу без паблишера-носителя. Паблишер для сети работает как исходящий канал доставки. Спай-оператор просто становится одним из них.

Google Search, Meta (Facebook и Instagram), TikTok и LinkedIn так не работают. Их реклама крутится на их собственных first-party поверхностях (странице результатов Google Search, ленте Instagram и Facebook, потоке For You в TikTok, таймлайне LinkedIn) и рендерится их же собственными приложениями и серверами. Рекламодатель платит платформе; платформа показывает рекламу пользователям прямо на своей территории. Нет стороннего паблишерского инвентаря для регистрации, нет JS-тега, который кто-то может встроить, чтобы получать sponsored-посты Meta, нет API, чтобы подписаться на Google Search-рекламу снаружи. Поверхность доставки совпадает с платформой.

Там, где у walled gardens всё-таки есть сторонние паблишеры (Google AdSense и более широкий Google Display Network, Meta Audience Network для in-app), от инфильтрации защищают три структурных слоя.

1. Cross-origin iframe’ы

Реклама AdSense грузится внутри iframe, отдаваемого с googleads.g.doubleclick.net или tpc.googlesyndication.com. JavaScript паблишера крутится в родительской странице; реклама внутри iframe; same-origin policy браузера делает содержимое iframe недоступным для кода паблишера:

// JavaScript паблишера пытается заглянуть в ad-iframe
const adFrame = document.querySelector('iframe[src*="doubleclick"]');

adFrame.contentDocument;
// → null  (same-origin policy блокирует доступ)

adFrame.contentWindow.document.body;
// → DOMException: Blocked a frame with origin "https://my-publisher.example"
//                 from accessing a cross-origin frame.

Паблишер сдаёт Google пустой прямоугольник. Со стороны паблишера ни bid-метаданные, ни URL креатива, ни идентичность рекламодателя недоступны.

2. Server-side отбор без открытого bid response

Google решает, какую рекламу показать, на своей инфраструктуре. Паблишер получает отрисованную рекламу внутри изолированного iframe, а не JSON-ответ с ID рекламодателя, ID кампании и метаданными креатива. Дашборд паблишера показывает агрегированный доход по категориям IAB, не историю бидов по креативам, и сами категории намеренно грубые («Финансы → Страхование», а не «Allianz, под-30, EU-кампания»). То, что у тебя крутится, паблишер видит в очень низком разрешении by design.

3. Жёсткие меры на уровне аккаунта

Google и Meta держат собственные trust-and-safety отделы на стороне паблишера, с ML-фрод-детектом плюс прямыми запретами в Terms of Service на парсинг, перехват или фингерпринтинг рекламы, которая идёт через твой аккаунт. Стандартный ответ — это терминация аккаунта плюс заморозка выплат, и применяется массово. Структура мотивации обратная PropellerAds: walled gardens теряют деньги на паблишерском фроде, а не зарабатывают на нём, и поэтому жёстко его пресекают.

Итоговый эффект: единственные программные способы видеть рекламу Meta или Google в масштабе — это собственные библиотеки рекламы этих платформ и фарм-аккаунты, которые скроллят пользовательскую ленту. Перехват на уровне паблишера, универсальный приём в сторонних сетях, об архитектуру walled gardens разбивается.

Детекция со стороны рекламодателя

Если ты крутишь кампанию и хочешь понять, попадаешь ли в спай-базы:

1. Зашей уникальные маркеры в click URL. Query-параметр с per-creative рандомным токеном, который пишется в лог сервера лендинга. Если этот токен всплывёт в выдаче спай-сервиса или в своей же конкурентной разведке, креатив проиндексирован.

2. Просей click-трафик на referrer’ы спай-сервисов. Спай-базы делают превью лендингов с собственной инфраструктуры. User-Agent такого fetch’а, IP-диапазоны (часто известные облачные подсети в EU и US) и отсутствие исполнения JS — всё это детектится на стороне лендинга.

3. Запусти декой-креативы с характерным, но бессмысленным текстом и минимальным бидом. Через 48 часов поищи этот текст в спай-тулах. Те, что показали, у них есть. Те, что нет, пока нет.

Защитные приёмы

Легенда: ✓ полная защита (механизм блокируется) · ◐ частичная (помогает, но не блокирует полностью) · ○ не влияет.

Структурный союз рекламных сетей со спай-базами (сеть зарабатывает дважды на одной активности) означает: если ты платящий рекламодатель в push- или нативной сети, спая не избежать. Креатив утечёт. Рекламодатель реально контролирует две вещи: снизить ценность утечки (чтобы копия не помогала копиру) и сделать утечку коммерчески бесполезной (чтобы даже идеальная копия не двигала продукт). Защиты ниже идут от самого фундаментального к самому тактическому.

Три термина из этого раздела, которые ещё не были введены:

• Лендинг или посадочная: страница, на которую ведёт клик. Креатив — это то, что видно в ленте; лендинг — это страница, которая открывается после клика.
• Воронка: полная цепочка от креатива через трекерные редиректы к лендингу и дальше до того целевого действия, которое нужно рекламодателю (регистрация, покупка, инсталл).
• Клоакер: серверный фильтр на воронке, который показывает разный контент разным посетителям: реальные покупатели видят настоящий оффер, боты и краулеры видят заглушку. Слово прочно ассоциируется с серой аффилиаткой, но сама механика (отличить человека от парсера) представляет собой штатную практику в антифрод-системах, региональной персонализации и бот-защите, и ровно это делают Cloudflare Bot Management , DataDome и FingerprintJS Pro для крупных брендов.

1. Узнаваемость бренда: единственная долгоиграющая защита

Креатив, который сложно скопировать убедительно, ценнее креатива, который сложно найти. Если конкурент берёт твой креатив, меняет название бренда и результат всё ещё выглядит правдоподобно для твоей аудитории, утечка двигает деньги. Если после подмены сразу видно подделку, не двигает. Характерная типографика, цветовая палитра, визуальная структура и тон голоса несут больше защитного веса, чем любая технология. Это та же логика, что век защищает иконические билборд-кампании.

Практический тест: возьми свой креатив, замени бренд на конкурента и спроси, выглядит ли это всё ещё как правдоподобная реклама их продукта. Если да, креатив дженерик, и утечка опасна. Если «это явно не их», утечка почти безвредна. Конкурент с твоим текстом и его именем будет выглядеть как подделка для всех, кто уже знает тебя.

2. Разделить хук и оффер

Узнаваемый креатив сложно скопировать убедительно. А вот креатив, забитый деталями оффера, легко прочитать. Держи специфику (название партнёра, цену, целевой сегмент, конкретный CTA) за кликом, не на самом юните. Реклама вида «Allianz упал до €18/мес для тех, кому до 30, подпишись» отдаёт конкуренту партнёра, цену, сегмент и воронку одним скриншотом. Тот же хук в твоей характерной манере, со спецификой за лендингом, отдаёт угол, но не плейбук.

3. Подписанные click URL с TTL

Каждый click URL несёт per-click токен, подписанный на сервере, с коротким TTL. Четырёх часов достаточно. Лендинг валидирует токен; просроченные или переигранные токены попадают на заглушку вместо реального оффера. Спай-краулер снимает URL один раз, и когда URL всплывёт в спай-базе, он уже мёртв, а самый простой ход конкурентной разведки (переиграть пойманный клик) перестаёт работать.

Креатив несёт один статический URL, указывающий на твой редиректор (https://track.you.com/c/<creative-id>). Это и есть URL, который сеть индексирует и хранит. Когда приходит реальный клик, редиректор выписывает свежий подписанный токен и 302-редиректит посетителя на лендинг с прикреплённым токеном. Используй 302, не 301: 301 кешируется, и тогда один токен заморозится на URL для всех последующих посетителей; 302 заставляет каждый клик снова идти через сервер за свежим токеном.

const crypto = require('node:crypto');

const SECRET = Buffer.from('<rotated server-side secret>');
const TTL = 4 * 3600; // 4 часа

// В редиректоре, на каждый клик:
function sign(creativeId) {
  const nonce = crypto.randomBytes(8).toString('hex');
  const payload = `${creativeId}.${Math.floor(Date.now() / 1000)}.${nonce}`;
  const sig = crypto.createHmac('sha256', SECRET).update(payload).digest('hex').slice(0, 16);
  return `${payload}.${sig}`; // приклеивается к click URL как ?t=...
}

// На лендинге, до раскрытия оффера:
function verify(token) {
  const [creativeId, ts, nonce, sig] = token.split('.');
  const payload = `${creativeId}.${ts}.${nonce}`;
  const expected = crypto.createHmac('sha256', SECRET).update(payload).digest('hex').slice(0, 16);
  const sigBuf = Buffer.from(sig);
  const expBuf = Buffer.from(expected);
  if (sigBuf.length !== expBuf.length) return false;
  return crypto.timingSafeEqual(sigBuf, expBuf)
      && Math.floor(Date.now() / 1000) - parseInt(ts, 10) < TTL;
}

Крупные атрибуционные платформы (AppsFlyer с OneLink и Protect360, Branch, Adjust, Google Campaign Manager 360) генерируют свои per-click ID и крутят серверный фрод-детект (replay клика, спуфинг, бот-трафик) внутри своей инфраструктуры, но вердикт прилетает как пост-атрибуционный флаг в дашборд, а не как примитив, который лендинг может проверить на лету. Шаблон с подписанным токеном выше ложится поверх любой такой платформы; он целится именно в вектор replay’а спай-краулера, под который click-fraud сюиты не заточены.

Окно TTL — это компромисс. Слишком короткое (меньше часа) — и реальные пользователи, открывшие вкладку и вернувшиеся на следующий день, попадают на заглушку, ломая конверсию. Слишком длинное (больше суток) — и спай-базы успевают подцепить живые URL до того, как они истекут. Четыре часа покрывают подавляющее большинство легитимной задержки клика на мобильном трафике и закрывают большинство окон обновления спай-баз. Под длинные кампании ротируй подпись раз в неделю, чтобы даже снятые токены переставали валидироваться против текущего ключа.

4. Серверная персонализация лендинга

Лендинг — это не статический HTML с зашитым в него оффером. Это страница, которая рендерится под каждого посетителя из контекста запроса: ГЕО, девайс, реферер, параметры клика, время. Два посетителя, которые формально приходят на одинаковый URL, видят содержательно разные страницы. Спай-краулер снимает одно синтетическое отображение; снятое отображение не отражает того, что видят реальные клиенты, и в спай-базе твоя кампания распадается на контекст-зависимые срезы, а не записывается как одна каноническая страница для копирования.

Входы, которые гонят вариацию, это контекст-примитивы запроса, которые есть в любом веб-стеке: ГЕО (по IP или параметру клика), carrier ASN, класс девайса, ОС, браузер, энтропия реферера, таймстемп клика и ID кампании/креатива в click URL. Каждый вход сдвигает, какой вариант оффера, какой платёжный метод, какой блок копирайта и какую цену видит посетитель. Спай-краулер из дата-центрового ASN во Франкфурте по click URL, который реально нацелен на Vodafone IT 5G на iOS, видит fallback-вариант, не имеющий ничего общего с настоящим таргетом кампании.

Граница между персонализацией и клоакингом проходит по намерению и раскрытию. Персонализация обращается с каждым легитимным посетителем как с приоритетным и показывает ему оффер, под который он реально был затаргечен; единственные посетители, которые видят заглушку, это те, чей контекст запроса не совпадает ни с одной обслуживаемой аудиторией (боты, спай-краулеры, ad-review трафик от самой сети, когда это уместно). Клоакинг в строгом аффилиатском смысле намеренно обманывает compliance-ревьюеров сети. Механизм один — легитимность определяется тем, что показывается review-трафику сети, а не нецелевому посетителю.

Подвох всей этой ветвящейся логики: проверить её из офиса не получится. Загрузка собственного лендинга через дата-центровый IP, потребительский VPN или ноутбук с домашнего Wi-Fi: все три попадают на fallback-ветку by design, ровно ту, которую правила персонализации и закрывают. Единственный способ протестить «как оно есть на самом деле» — это грузить лендинг через тот контекст запроса, под который ты реально таргетируешь: тот же carrier ASN, то же ГЕО, тот же класс девайса. iProxy.online превращает Android-телефон и локальную SIM в выделенный мобильный прокси на реальном carrier-IP, и можно загрузить лендинг так же, как его увидел бы реальный посетитель на Vodafone IT 5G, и убедиться, что отдаваемый вариант совпадает с таргетингом, до того, как заливать бюджеты. Тот же флот заодно работает аудитом против спая: переиграй URL, снятый спай-сервисом, с того же carrier-IP и проверь, что декой-логика действительно срабатывает под тот контекст, в котором был краулер.

5. Бот-детект на краю воронки

Это та самая легитимная, защищаемая разновидность приёмов класса «клоакинг». Стандартные слои бот-митигейшена на краю лендинга детектят автоматических посетителей и уводят их с реального оффера. Та же инженерия, которую онлайн-ретейл крутит против credential stuffing и inventory hoarding, работает и тут: спай-краулер по сути бот, и бот-детект держит страницу оффера вне его досягаемости. Снятый лендинг становится дженерик-заглушкой, а ценность спай-базы для копирующего конкурента деградирует соответственно.

Что конкретно ловят крупные продукты бот-митигейшена: Cloudflare Bot Management скорит каждый запрос по комбинации TLS-фингерпринта, порядка фреймов HTTP/2, репутации IP, поведенческой истории и challenge’а доверия; DataDome строит схожие сигналы поверх поведения на стороне приложения (движение мыши, ритм скролла, тайминги полей формы); FingerprintJS Pro упор делает на устойчивые фингерпринты браузера, которые переживают очистку cookies и режим инкогнито. Headless-краулер с чистого дата-центрового IP проваливает все три на базовых сигналах; продвинутый краулер с реальным Chromium через резидентный прокси проходит один-два, но редко собирает полный стек.

Где эта защита начинает шуметь, так это на мобильном carrier-трафике. Мобильные прокси с реальных carrier ASN идут через CGNAT и поведенчески неотличимы от легитимных мобильных посетителей: тот же NAT-пул, тот же TLS-профиль, те же фингерпринты девайса. Тупое правило «блочить весь резидентный и мобильный прокси-трафик» убьёт конверсию на реальных мобильных пользователях сильнее, чем замедлит компетентного спай-оператора. Тюнинг порога бот-детекта против конверсии: false positive на мобайле стоит реальных денег, поэтому под мобильный сегмент бери поведенческие сигналы (паттерны взаимодействия, время на странице, вовлечённость в форму) вместо IP-блокировок.

Паттерн, который мы видим чаще всего: команда тюнит правила бот-детекта против формы трафика одного оператора, а потом продолжает им же доверять на другом операторе в том же ГЕО. Сигналы, которые реально разделяют операторов и классы девайсов, сидят ниже того уровня, который антидетект-браузер или облачный телефон могут перекрасить. MTU SIM-карты различается между операторами, TCP-стек различается между классами девайсов, и оба представляют собой примитивы уровня ядра, которые юзерспейс-инструмент подделать не может. Порог, настроенный под Vodafone IT iPhone, через неделю может срабатывать на легитимных посетителях TIM IT Android. Тестируй хотя бы два сочетания «оператор × девайс» на каждый целевой рынок, прежде чем фиксировать порог.

Честный тюнинг порога требует тестов из того же контекста запроса. Мобильный прокси iProxy.online даёт реальный carrier ASN с CGNAT-маршрутизацией и настоящий device TLS-профиль; в паре с антидетект-браузером это позволяет загрузить собственный лендинг и как легитимного мобильного посетителя, и как более продвинутого краулера, который пытается под него мимикрировать. Подкручивай правила вверх, пока они не ловят антидетект-сетап, потом отводи обратно, пока они не перестанут наказывать чистую мобильную базу. Зазор между двумя порогами — и есть рабочее окно.

6. Dynamic Creative Optimization (DCO)

Штатная индустриальная фича в Meta, Google и большинстве программатик-DSP: автоматическая вариация компонентов креатива (заголовок, картинка, CTA, цвет, копи) на лету в момент показа. Когда каждый показанный креатив представляет собой слегка другую комбинацию, спай-база не видит одного чёткого «победителя», который стоит копировать. Она видит фрагментированные варианты, которые не кластеризуются, поэтому конкуренты, запускающие копи-кампании, тестятся под неверные допущения и сливают бюджеты. DCO работает как защита по нулевой дополнительной цене: платформы поддерживают её нативно.

Оси вариации, которые сильнее всего работают на защитную фрагментацию: заголовок (3–10 вариантов), главная картинка (3–8 вариантов), текст CTA-кнопки (3–5 вариантов), акцентный цвет (2–4 варианта). Комбинаторно четыре оси по пять вариантов дают 625 показанных комбинаций. Спай-база, которая снимет 200 импрешнов, видит как будто 200 разных креативов; ни одна комбинация не доминирует, чёткого «лучшего» нет, и конкурент, который запустит копи на пойманном наборе, ровно так же тестит каждый вариант и не учится ничему про то, какой реально конвертит.

DCO сложнее настроить в сторонних push- и нативных сетях, чем в walled gardens. Meta Advantage+ Creative и Google Performance Max делают компонентную вариацию автоматом; PropellerAds и аналогичные push-сети принимают несколько вариантов креатива в одной кампании, но обычно не фрагментируют компоненты внутри одного креатива. Обходной путь для push: грузи 20–30 микро-вариантов креатива отдельными юнитами внутри кампании, чтобы ни один не доминировал по показам. Операционно тяжелее, чем аналог в walled garden, но даёт ту же защитную фрагментацию.

7. Пиксельные водяные знаки

Стеганографические маркеры, зашитые в картинки, видео и тексты креатива: невидимые глазу, восстановимые из снятой копии. Опенсорсные тулчейны вроде watermark-anything от Meta показывают продакшен-уровень устойчивости пэйлоадов в изображениях, которые переживают повторный JPEG-энкод, ресайз и путь «скриншот + перекодировать», по которому спай-краулер обычно поглощает креативы. Тот же принцип распространяется на текст через подмену Unicode-пробелов. Свежая методическая работа каталогизирует приём для заголовков и строк копирайта, где невидимые варианты символов кодируют per-impression ID, не меняя видимого текста. Ни первое, ни второе не предотвращает индексацию. Зато оба позволяют точно определить, какие спай-базы какой креатив сняли и когда. Это полезная разведка о самой конкурентной разведке: кто изучает твои кампании, с каким расписанием, через какие каналы сбора.

8. Скорость важнее скрытности

Спай-базы запаздывают: 24–72 часа у самых быстрых, иногда неделя в длинном хвосте. Команда, которая каждые 48 часов выкатывает новый вариант креатива, стабильно опережает конкурентов, копирующих предыдущий. Под тест-кампании это полная защита; под устойчивое брендовое присутствие защита частичная, и оставшийся вес тащит пункт 1 про узнаваемость бренда.

9. Аудит своих кампаний с точки обзора спай-базы

Защита, которую рекламодатели регулярно игнорируют — это аудит собственных кампаний с той же точки обзора, с которой работает спай-база. Если единственное место, где ты видишь свой креатив, это дашборд отчётности сети, ты понятия не имеешь, как он реально показывается на трафике, который спай-операторы реально снимают: синтетические посетители с резидентных и мобильных carrier-IP в каждом целевом ГЕО. Сети таргетируют по carrier ASN; креатив, который чисто отдаётся в твой офисный Wi-Fi-IP, может вообще никогда не доходить до подписчика Vodafone IT 5G, под которого сеть реально таргетирует. Ты летишь вслепую, ровно мимо той части кампании, которую конкуренты могут купить через спай-сервис.

Сам аудит сводится к чистой механике: подними реальный браузер через carrier-мобильный прокси в каждом целевом ГЕО, загрузи страницу паблишера с нужной сетью и снимай отданный креатив и bid response за окно семплирования. На выходе получишь спай-вид на собственную кампанию: какие креативы реально всплывают, под какие биды, в каком таргет-контексте. Если твой креатив «Vodafone IT 5G under-30s» не появляется в carrier-сегментированном аудите, значит, сеть отдаёт его не так, как ты задумал, и та же дыра доставки невидима для отчётности. Если появляется, теперь ты точно знаешь, какая форма кампании уходит вниз по течению в любую спай-базу. Гоняй аудит-браузер через антидетект-профиль, привязанный к мобильному прокси, чтобы снятое отражение совпадало с тем, что увидел бы реальный посетитель в этом контексте.

10. Дроби carrier-сегменты своей кампании

Кампания с таргетингом «DE mobile» крутится как один широкий бакет. Кампания, разбитая на «DE / Vodafone DE 5G under-30», «DE / Telekom DE 4G all-ages», «DE / O2 DE 5G urban» и так далее, крутится как дюжина узких бакетов. Суммарный объём импрешнов тот же; след в спай-базе — совсем другой.

Спай-операторы запрашивают свою нормализованную базу по ГЕО, девайсу, ОС, браузеру и полям таргет-контекста сети. Кампания с широким бакетом ложится в один непрерывный срез спай-БД: запрос «DE mobile [вертикаль]», и вся кампания всплывает в одной выдаче. Кампания с узкими бакетами разваливается по разным запросам: ни один покупатель конкурентной разведки естественным образом не комбинирует десяток конкретных фильтров по carrier, возрасту и девайсу, чтобы восстановить полную картину, и снятые креативы распадаются по ячейкам, которые выглядят как отдельные мелкие кампании, а не одна большая. Тот же общий спенд, тот же общий охват, принципиально другой сигнал в любой спай-базе.

Работает это, потому что рекламные сети считают carrier ASN полноценным полем таргетинга. То же свойство, которое делает мобильно-прокси-аудит возможным в пункте 9, делает осмысленным дробление carrier-сегментов здесь. Обычные дата-центровые или резидентные прокси, которые маскируют carrier ASN, такой защиты не дадут; пул мобильно-carrier-посетителей у спай-оператора сам сегментирован по операторам, поэтому кампания, которая работает узкими carrier-бакетами, остаётся фрагментированной в спай-базе даже после захвата.

Финальная мысль: билборд всегда копировали

Билборды копируют сто лет, и Coca-Cola не держит ради этого военной комнаты. У них есть кое-что мощнее: креативная идентичность настолько характерная, что копия видна с расстояния. Технические защиты покупают дни; узнаваемость бренда покупает десятилетия.

Дом у шоссе не может запретить людям смотреть на стену. Хозяин может выбрать, что на ней нарисовано, и узнаваемая картина не теряет ценности в тот день, когда кто-то её сфотографировал.