Як спай-тули збирають дані — і що з цим робити рекламодавцю

Ключове: Спай-тули реклами (AdPlexity, Anstrex, Spy.House, BigSpy і компанія) формують свої бази переважно так: реєструються паблішерами в сторонніх push- і нативних мережах і логують кожну bid-відповідь, яку отримує їхній власний JavaScript. Мережі структурно це терплять, бо заробляють двічі: спершу на оригінальному рекламодавці, потім на копіях. Сталі захисти полягають не в приховуванні (неможливому стосовно паблішера, якому платять за доставку креативу), а в зниженні цінності того, що витекло: бренд-впізнаваність, від якої копії виглядають дешево, токенізовані click URL, серверна персоналізація лендингу, бот-детект на краях воронки і дзеркальний аудит власних кампаній через мобільні проксі з реальним 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. Краулінг лендингів і воронок: проходження клікового маршруту креативу через трекери, клоакери і прелендинги, щоб ідентифікувати оффер, афіліатську мережу, трекерний софт і відновити воронку цілком.

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

Домінантний механізм збору для push, native, inpage і popunder спай-баз структурно найпростіший: оператор сам стає паблішером.

Уяви триповерховий будинок. Одна стіна виходить на жвавий хайвей. Інша частково виходить на тихішу прилеглу дорогу. Власник вирішує, як нарізати ці стіни під рекламу: десять щитів упритул уздовж стіни до траси (багато виторгу, потворний фасад, мало повторних візитів), або один маленький акуратний банер на боковій стіні (менше виторгу, але будинок залишається будинком). Це рішення про нарізку (який простір віддавати і як його різати) ad-tech називає інвентарем.

Власник пропонує конкретну розкладку доступних місць. Рекламна мережа підписує контракти з обох боків: з власником, щоб заповнювати слоти, і з брендами, щоб ставити в них рекламу. Мережа займається матчингом і бере свій відсоток.

Тепер те саме зіставлення з ad-tech:

Це твоя стіна. Ти її продаєш. Тобі за неї платять. Ти точно бачиш, який саме білборд і коли на ній з’явився. Усе, що спай-база продає як «конкурентну розвідку», випливає з цього єдиного факту.

Ще два терміни, які зустрінуться нижче, даю визначення один раз і більше не пояснюю. Вертикаль означає нішу рекламодавця (фінанси, страхування, e-commerce). DSP — це buyer-side платформа, через яку рекламодавець реально купує інвентар на real-time аукціонах. Якщо це нова для тебе територія, IAB Tech Lab дає канонічне джерело з протоколів, а Wikipedia про real-time bidding пояснює основи за 10 хвилин.

Три кроки

1. Реєстрація паблішером. Стандартна форма онбордингу у будь-якій push/native мережі. Віддаєш домен, погоджуєшся з правилами, вставляєш JS-тег мережі або налаштовуєш push-піддомен через CNAME.
2. Жени трафік на свій інвентар. Дешевий popunder/redirect-трафік приблизно $0.50 за 1000, або власні відвідувачі з резидентської чи мобільної проксі-ферми, які крутять реальні браузери на сайті-болванці. Кожен відвідувач тригерить рекламний виклик.
3. Логуй bid-відповідь. Мережа віддає метадані креативу у plain JSON. JavaScript паблішера (а це твій код) читає цю відповідь, відправляє на колектор оператора і нормально рендерить рекламу. Нічого зовні не зламано.

Заявлені обсяги виглядають правдоподібно за такою моделлю: Spy.House публікує цифри в 12 мільйонів креативів на день по 185+ країнах, AdPlexity і Anstrex декларують перетинні покриття по нативу, push і mobile. Один сетап на 30 мереж × 50 шелл-сайтів × 95 гео без зайвих зусиль досягає таких порядків.

Що насправді летить по дроту

Технічне ядро складається з одного HTTP-запиту і однієї HTTP-відповіді на показ. І те, і інше повністю видно паблішеру, бо запит ініціює його ж власний JavaScript.

Типовий тег паблішера:

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

Під час завантаження сторінки SDK збирає рекламний запит. У вигляді 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"

Мережа проганяє свій матчинг (RTB-аукціон серед 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')) {
      // tee the response to the collector before returning to the 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-відповіді реально несуть корисний сигнал. Словник:

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

Найбільш дірявою з погляду розвідки виявляється CPC. Сума ставки є реал-тайм сигналом того, скільки рекламодавець готовий платити за клік у конкретному гео і вертикалі, і він оновлюється на кожному показі. Три місяці CPC-історії за рекламодавцем і гео дають датасет конкурентної розвідки, на який жоден рекламодавець не давав згоди, але він накопичується як побічний продукт звичайного перегляду bid-відповіді паблішером.

Конкретно: внутрішнє 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-відповіді, бо спай-оператор не є ендпойнтом конверсії. Закрити цю прогалину можна тільки проходженням клікового маршруту через трекер, клоакер і офервол, а це вже інший механізм.

Чому ставка взагалі є у відповіді? Чесне запитання, адже спай-база читає число, яке мережа могла б у принципі не віддавати. П’ять перетинних причин:

1. OpenRTB цього вимагає. Поле price обов’язкове в схемі BidResponse.seatbid.bid. Мережі, які працюють на OpenRTB, успадковують цю прозорість by design.
2. Верифікація паблішерського ревшеру. Push і native мережі віддають паблішеру 60–80% ставки рекламодавця. Сховаєш число, втратиш довіру паблішерів, втратиш інвентар на користь конкурента, який це число показує. Непрозорість стає конкурентним мінусом на supply side.
3. Yield-оптимізація на стороні паблішера. Паблішери виставляють CPM-флор по зонах, A/B-тестують розміщення, тюнять щільність креативів. Це все потребує перімпрешенних даних щодо ставок. Паблішер, який не бачить, за якою ціною клірить його інвентар, не може оптимізувати те, що продає.
4. Клієнтський рендеринг. Push, native, popunder, inpage: усе це рендерить JavaScript самого паблішера. Ставка лежить у тому ж payload, що й URL креативу і click URL, які тег і так має, щоб відрендерити рекламу. Ставка тече «безкоштовно» для мережі.
5. Click URL часто кодує ставку. Багато мереж зашивають значення ставки в click-tracking URL для білінг-узгодження між показом і кліком. Навіть якщо викинути bid з топ-рівня JSON, воно поїде в параметрах click URL.

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

OpenRTB і bidstream

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

Конвеєр на практиці: один парсер на кожен legacy/проприєтарний формат мережі, один спільний парсер на всі OpenRTB-сумісні мережі, увесь вивід нормалізований в одну внутрішню схему. Крос-мережевий пошуковий UI у фронті спай-тулу робиться тонким шаром над цією нормалізованою таблицею, тому всі великі спай-сервіси й пропонують по суті однаковий набір фільтрів (гео, девайс, ОС, браузер, тип реклами, діапазон дат, ключове слово рекламодавця).

Простіший шлях: дашборд паблішера

Інтерсепт на рівні дроту — це загальний випадок. Спеціальний випадок ще простіший: власний дашборд паблішера в мережі сам по собі є пошуковим UI над тими самими даними. Залогінений як паблішер, оператор бачить тамбнейли креативів, імена або ID рекламодавців, click destinations, ставки по показам, розподіли за годинами, ID кампаній. Дашборд існує для того, щоб легітимні паблішери моніторили і робили brand-safety перевірку трафіку, що йде через них; для спай-оператора це найзручніший експорт-інтерфейс із можливих.

Там, де дашборд багатий, оператор використовує саме його. Там, де він слабкий, відсутній або недокументований (особливо в push, де зашифрований payload Web Push на дроті важко обробити без контролю над service worker, який його розшифровує), wire-перехоплення затикає діру. Помножено на 25–40 мереж, отримана база виходить структурованою, нормалізованою і приблизно актуальною до живого стану кожної push/native кампанії у світі.

Гео-множник

Паблішер у Бразилії бачить бразильські креативи. Щоб накрити креативи в 95 країнах, оператору потрібно одне з двох:

1. Реальні відвідувачі з кожного гео на шелл-сайти паблішера, щоб мережа віддавала гео-таргетований інвентар природно. Оператори купують дешевий трафік (popunder, redirect, push) у інших мережах і ганяють його через свої ж паблішерські сайти, щоб тригерити рекламні виклики. Економіка: redirect-показ коштує $0.0005 і генерує один виданий креатив, гідний індексації.

2. Синтетичні відвідувачі через резидентські або мобільні проксі, які виконують сторінку паблішера на реальному браузері, щоб підвантажити рекламний тег і зловити відповідь. Цей шлях дорожчий за показ, але дає чистий, сегментований по операторах інвентар, якого дешевий redirect-трафік не виносить. Найбільші спай-маркетплейси не випадково кросселять провайдерів мобільних і резидентських проксі як ключову партнерську категорію.

Окремо важливий мобільно-операторський вимір: рекламні мережі ключують таргетинг по ASN оператора, що піднімає запит. Звичайні серверні проксі видно як «Wi-Fi/unknown», і вони повністю промахуються повз carrier-сегментовані кампанії. Мобільні проксі через реальні точки оператора піднімають кампанії, які націлені тільки на абонентів, скажімо, Vodafone IT чи Київстар UA, а це і є той інвентар, на який варто полювати, бо точність таргетингу натякає на прибуткову й добре відтюнену кампанію.

Чому рекламні мережі це структурно терплять

Економічна петля сама дає відповідь:

Рекламодавець платить рекламній мережі
        ↓
Мережа показує креатив на "паблішерському" сайті спай-оператора
        ↓
Мережа платить паблішерський виторг спай-оператору  ← інтерес мережі
        ↓
Спай-оператор логує креатив і продає доступ іншим афіліатам
        ↓
Інші афіліати запускають копіювальні кампанії через ту саму мережу
        ↓
Мережа знову заробляє на рекламодавцях (петля замикається)

Мережі платять двічі за одну й ту саму активність. Бюджет оригінального рекламодавця фінансує паблішерську виплату спай-сервісу. Бюджет копіювальника фінансує наступний цикл. Жодного стимулу детектити чи банити цих паблішерів у мережі немає, і цьому є наочні докази: PropellerAds тримає окремий тег /blog/tag/spy-tools/ у корпоративному блозі, RichAds публікує добірку топ-push-спай-тулів, Adsterra крутить свій власний best-of матеріал про спай-тули, і всі троє згадують ту саму трійку платформ, які індексують їхній же інвентар, часто з афіліатськими посиланнями на ці тули. Мережі не є супротивниками спай-екосистеми; вони — її комплементарний шар.

Чому walled gardens це окрема історія

Механіка вище працює на PropellerAds, RichAds, MGID і ще тридцяти з гаком сторонніх push/native мережах, бо ці мережі сидять між рекламодавцями і відкритою екосистемою незалежних паблішерів. Будь-хто з доменом може стати паблішером; мережа не має власної first-party поверхні і не може віддати рекламу без паблішера, який її прийме. Паблішер це і є канал доставки мережі. А спай-оператор просто стає одним із них.

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

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

1. Cross-origin iframes

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

// the publisher's page tries to inspect the ad iframe
const adFrame = document.querySelector('iframe[src*="doubleclick"]');

adFrame.contentDocument;
// → null  (same-origin policy blocks access)

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

Паблішер здає Google порожній прямокутник в оренду. З коду паблішера не дотягтися ні до метаданих ставки, ні до URL креативу, ні до особистості рекламодавця.

2. Серверний матчинг без експонування bid-відповіді

Google обирає, яку рекламу показати, на власній інфраструктурі. Паблішер отримує вже відрендерену рекламу всередині сендбоксованого iframe, а не JSON bid-відповідь із advertiser ID, campaign ID і метаданими креативу. Дашборд паблішера показує агрегований дохід по категоріях IAB, а не покреативну історію ставок, і навіть ці категорії навмисно грубі («Фінанси > Страхування», а не «Allianz EU під-30»). Видимість того, що проходить через паблішера, навмисно низькороздільна.

3. Жорстка політика на рівні акаунту

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

Сумарний ефект: єдині програмні шляхи побачити рекламу Meta або Google у масштабі — це власні бібліотеки реклами цих платформ і скрол стрічок через ферми акаунтів проти юзерфейсу. Wire-перехоплення на рівні паблішера — універсальний прийом для сторонніх мереж — контакту з walled garden не переживає.

Детект на стороні рекламодавця

Рекламодавцю, який крутить кампанію і хоче знати, чи його вже індексують:

1. Зашивай унікальні фінгерпринти у click URL. Параметр запиту, який кодує покреативний рандом-токен і логається на лендингу. Якщо цей токен спливає у пошуку спай-тулу або у твоєму ж конкурентному аналізі, креатив уже в індексі.

2. Аудітуй кліковий трафік на referer’и спай-тулів. Спай-бази переглядають лендинги, завантажуючи їх із власної інфраструктури. User-Agent цього фетча, діапазони IP (часто відомі хмарні підмережі в ЄС і США) і відсутність виконання JS, усе це детектиться на лендингу.

3. Запускай креативи-приманки з характерним, але беззмістовним текстом на малих ставках. Шукай цей текст у спай-тулах за 48 годин. Тули, у яких він спливе, вже мають твої дані; ті, в яких не спливе, поки що ні.

Захисні ходи

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

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

Три терміни, які зустрічаються по всьому розділу і яких я ще не визначав:

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

1. Бренд-впізнаваність: єдиний сталий захист

Креатив, який важко правдоподібно скопіювати, цінніший за креатив, який важко знайти. Якщо конкурент може забрати твій креатив, замінити бренд і результат усе одно виглядає правдоподібно для твоєї аудиторії, витік перерозподіляє гроші. Якщо підміна читається як очевидно фейкова, витік грошей не рухає. Характерна типографіка, палітра, візуальна структура і голос несуть більше захисної ваги, ніж будь-які технічні контрзаходи. Це та сама логіка, яка століття захищає культові білбордні кампанії.

Практичний тест: візьми свій креатив, заміни в ньому свій бренд на бренд конкурентів і спитай себе, чи це досі читається як їхня реклама. Якщо так, актив надто загальний і витік небезпечний. Якщо «ні, це явно не вони», витік практично нешкідливий. Конкурент, який крутить ту саму копію з власним ім’ям, для будь-кого, хто тебе вже знає, виглядає як підробка.

2. Розділяй гачок і оффер

Характерний креатив важко правдоподібно скопіювати. Креатив, забитий конкретикою оффера, легко прочитати. Тримай специфіку (партнер, ціна, сегмент, точний CTA) поза самим юнітом і ховай за клік. Реклама «Allianz знизив до €18/міс для тих, кому до 30, підпишись тут» віддає конкуренту партнера, ціну, сегмент і воронку одним скріншотом. Той самий гачок твоїм впізнаваним голосом, із прихованою специфікою на лендингу, віддає кут (angle), але не плейбук.

3. Токенізовані click URL

Кожен click URL несе покліковий токен, серверно підписаний із коротким терміном дії. Однієї–чотирьох годин достатньо. Лендинг валідує токен; протухлий або переграний токен веде на дженерик-сторінку замість реального офферу. Спай-краулер зловив URL один раз, і поки той URL спливе у базі, він уже мертвий, а найпростіший хід конкурентного аналізу (відтворити зловлений клік) перестає працювати.

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

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

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

// In the redirector, on each click:
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}`; // appended to the click URL as ?t=...
}

// On the lander, before revealing the offer:
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) генерують власні поклікові ID і ганяють серверну детекцію фроду (повтор кліку, спуфінг, бот-трафік) у себе всередині, але вирок приходить до тебе постфактум позначкою у дашборді, а не примітивом, який лендинг може перевірити у реальному часі. Шаблон підписаного токена вище працює поверх будь-якої з цих платформ; він цілиться саме у вектор повторного відтворення (replay) від спай-краулера, на який click-fraud сьюти не заточені.

Вікно терміну дії є компромісом. Занадто коротке (менш за годину) і реальні користувачі, які відкрили вкладку й повернулись на наступний день, потрапляють на обманку, що добиває конверсію. Занадто довге (більше доби) і спай-бази встигають взяти живі URL до того, як вони протухнуть. Чотири години покривають переважну частину легітимної затримки кліку на мобільному трафіку і виходять за межі більшості циклів оновлення спай-баз. На довгих кампаніях ротуй ключ підпису раз на тиждень, щоб навіть зловлені токени переставали валідуватись на актуальному ключі.

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

Лендинг — це не статичний HTML-файл із вже зашитою деталізацією оффера. Це сторінка, яку рендерять для кожного відвідувача з контексту запиту: гео, девайс, referer, параметри кліку, час. Два відвідувачі з вигляду однакових URL бачать матеріально різні сторінки. Спай-краулер ловить один синтетичний зріз; зловлений зріз не репрезентує те, що бачать реальні клієнти, і спай-база фрагментує твою кампанію на контекст-специфічні снепшоти замість того, щоб зафіксувати один канонічний лендинг для копіювання.

Інпути, які крутять варіацію, є примітивами контексту запиту, доступними в будь-якому веб-стеку: гео (з IP або параметра кліку), ASN оператора, клас девайсу, ОС, браузер, ентропія referer’а, таймштамп кліку і campaign/creative ID із click URL. Кожен інпут зсуває варіант офферу, варіант оплати, копі-блок і ціну, які бачить відвідувач. Спай-краулер із серверного ASN у Франкфурті, заходячи по click URL, призначеному під Vodafone IT 5G на iOS, бачить fallback-варіант, який не має нічого спільного з реальним таргетингом кампанії.

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

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

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

Це легітимне, юридично захищене застосування технік класу клоакінгу. Стандартні шари бот-мітігації на краях лендингу ідентифікують автоматизованих відвідувачів і відводять їх убік від реального контенту офферу. Та сама машинерія, яку онлайн-рітейлери ганяють проти credential stuffing і ботів-перекупників, працює і тут: спай-краулер це бот; бот-детект тримає сторінку офферу подалі від нього. Зловлений лендинг стає дженериковою обманкою, і цінність спай-бази для копіювальника відповідно деградує.

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

Особливо цей захист починає працювати на мобільно-операторському трафіку. IP мобільних проксі з реальних ASN оператора маршрутизуються через CGNAT і поведінково виглядають як легітимні мобільні відвідувачі: той самий NAT-пул, той самий TLS-профіль, ті самі фінгерпринти девайсу. Тупе правило «блокувати весь резидентський і мобільно-проксі трафік» вдарить по конверсії на справжніх мобільних користувачах сильніше, ніж пригальмує грамотного спай-оператора. Тюнь поріг бот-детекту проти впливу на конверсію: помилкові спрацювання на мобайлі коштують грошей, тому на мобільному сегменті надавай перевагу поведінковим сигналам (патерни взаємодії, час на сторінці, залученість на формі) над блокуваннями за класом IP.

Найчастіший патерн, який ми бачимо: команда тюнить правила бот-детекту під форму трафіку одного оператора, а потім надмірно довіряє цьому правилу на іншому операторі в тому самому гео. Сигнали, які реально розрізняють операторів і класи девайсів, лежать нижче за шари, які антидетект-браузер чи хмарний фон може перемалювати. MTU SIM-карти відрізняється від оператора до оператора, фінгерпринти TCP-стеку відрізняються між класами девайсів, і обидва є примітивами рівня ядра, які userspace-інструмент не підробить. Поріг, відтюнений на айфонах у Vodafone IT, може через тиждень позначити легітимного користувача Android на TIM IT. Тестуй проти щонайменше двох комбінацій оператор × девайс на цільовий ринок, перш ніж фіксувати поріг.

Належно відтюнити цей поріг можна лише тестуючи з самого цього контексту запиту. Мобільний проксі від iProxy.online дає реальний ASN оператора з CGNAT-маршрутизацією і справжнім 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/native мережах, ніж у walled garden. Meta Advantage+ Creative і Google Performance Max роблять варіацію на рівні компонентів автоматично; PropellerAds і подібні push-мережі приймають кілька варіантів креативу під однією кампанією, але всередині одного креативу компоненти зазвичай не фрагментують. Обхід на push: відвантажуй 20–30 мікро-варіантів креативу окремими юнітами в кампанії, стежачи, щоб жоден креатив не домінував у показах. Операційно важче за walled-garden-аналог, але дає ту саму оборонну фрагментацію.

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

Стеганографічні маркери, вбудовані в зображення, відео і копірайт креативу: невидимі для глядача, відновлювані зі зловленої копії. Опенсорсні набори типу watermark-anything від Meta показують промислового рівня payload’и для зображень, які переживають JPEG-передекодування, ресайз і шлях «скріншот → перетиск», через який спай-краулер зазвичай заводить креативи. Той самий принцип поширюється і на текст через підстановку юнікодних пробілів. Свіже методологічне дослідження каталогізує підхід для заголовків і рядків копірайту, де варіанти невидимих символів кодують поімпрешенний ID, не змінюючи відрендерений текст. Жоден із цих прийомів не запобігає індексації. Обидва ідентифікують, які спай-бази зловили які креативи і коли, а це корисна розвідка про самих конкурентних дослідників: хто вивчає твої кампанії, з якою періодичністю і через які канали збору.

8. Швидкість сильніша за приховування

Спай-бази запізнюються: від 24 до 72 годин для найшвидших, іноді до тижня для лонгтейлу. Команда, яка викочує новий варіант креативу раз на 48 годин, стабільно йде попереду конкурентів, які копіюють попередній. Для тестових кампаній це повноцінний захист; для тривалої брендової присутності — частковий, і решту ваги несе пункт #1 про бренд-впізнаваність.

9. Дзеркальний аудит: дивись на себе так само, як спай-бази

Захист, який рекламодавці постійно пропускають, — це аудит власних кампаній із тієї ж точки огляду, з якої знімає дані спай-база. Якщо єдине місце, де ти бачиш власний креатив, — це звітний дашборд мережі, ти не маєш жодного уявлення, як він з’являється для того типу трафіку, з якого реально знімають спай-оператори: синтетичні відвідувачі з резидентських і мобільних IP по кожному цільовому гео. Мережі ключують доставку за ASN оператора; креатив, який бездоганно віддається на твій офісний IP у Wi-Fi, може ніколи не дійти до абонента Vodafone IT 5G, на якого мережа реально таргетиться. У цьому місці ти йдеш наосліп і не знаєш, до чого саме мають доступ конкуренти.

Аудит механічний: запускай реальний браузер через мобільний проксі оператора в кожному цільовому гео, завантажуй сторінку паблішера з потрібною рекламною мережею і фіксуй відданий креатив та bid-відповідь у межах семпл-вікна. Результат це погляд спай-оператора на твою кампанію: які креативи спливають, при яких ставках, на яких таргетингових параметрах. Якщо твій «Vodafone IT 5G under-30» креатив не з’являється у carrier-бакетованому аудиті, мережа віддає його не так, як ти задумав, і та сама щілина у доставці невидима у твоїй звітності. Якщо з’являється, ти точно знаєш, яка форма твоєї кампанії опиниться нижче за течією у будь-якій спай-базі. Ганяй аудитний браузер через антидетект-профіль, прив’язаний до мобільного проксі, щоб зловлений зріз збігався з тим, що бачив би реальний відвідувач у тому ж контексті.

10. Диверсифікація за carrier-бакетами твоїх кампаній

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

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

Це працює, бо рекламні мережі ключують доставку за ASN оператора як поле таргетингу першого класу. Та сама властивість, яка робить можливими аудити мобільних проксі в #9, робить доцільною carrier-диверсифікацію тут. Звичайні серверні чи резидентські проксі, які маскують ASN оператора, цей захист не забезпечують; пул мобільно-carrier відвідувачів спай-оператора сам сегментований за операторами, тож кампанія, що крутиться у вузьких carrier-бакетах, лишається фрагментованою у спай-базі навіть після захвату.

Підсумок: білборди завжди копіювали

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

Будинок на хайвеї не може заборонити людям дивитись на стіну. Але господар сам вирішує, що на ній намальовано, а картина, впізнавана всюди, не втрачає вартості того дня, коли її хтось сфоткав.