Reklam casus araçları veriyi nasıl toplar

Anahtar Çıkarım: Reklam casus araçları (AdPlexity, Anstrex, Spy.House, BigSpy ve emsalleri) veritabanlarını çoğunlukla üçüncü taraf push ve native reklam ağlarına publisher olarak kaydolup kendi JavaScript’lerinin aldığı her bid yanıtını yakalayarak oluşturur. Ağlar bunu yapısal olarak hoş görür çünkü aynı faaliyetten iki kez gelir elde ederler: bir kez orijinal reklamverenden, sonra kopyalayanlardan. Kalıcı savunma, sızıntıyı gizlemek değildir (kreatifi sunması için ödeme alan bir publisher karşısında imkânsız), sızıntının değerini azaltmaktır: kopyaları gözle görülür biçimde kalitesiz gösteren marka belirginliği, token bağlı click URL’leri, sunucu tarafı lander kişiselleştirmesi, funnel kenarında bot tespiti ve casus operatörlerin kendi vantage point’ini gerçek operatör ASN’li mobil proxy denetimleriyle yansıtmak.

Affiliate reklam istihbarat platformları (AdPlexity, Anstrex, AdSpy, BigSpy, Spy.House, Mobidea ve daha küçük rakiplerden oluşan uzun bir kuyruk) milyonlarca reklam kreatifinden oluşan veritabanlarına erişim satar; GEO, dikey, reklamveren ve tarih bazında aranabilir. Bu konuda yazılan çoğu metin “reklam ağlarından reklamları toplarlar” deyip ürün incelemesine geçer. Asıl toplama yöntemleri teknik olarak ilginçtir, savunmalar bariz değildir ve hiçbiri hakkında neredeyse ciddi bir yazı yok.

Beş toplama yöntemi

Modern bir reklam casus veritabanını besleyen, her biri kendi mühendislik profiline ve kendi savunma hikâyesine sahip, temelden farklı beş yöntem vardır:

1. Publisher sızması: üçüncü taraf push/native reklam ağlarına publisher olarak kaydolup sundukları her kreatifi yakalamak. Bu yazının konusu.
2. Push abonelik hasadı: Web Push protokolünü kötüye kullanarak casus operatörün kontrolündeki bir service worker üzerinden şifrelenmiş bildirim yüklerini yakalamak.
3. Halka açık reklam kütüphaneleri ve sosyal reklam taraması: Meta Ad Library, TikTok Creative Center, Google Ads Transparency Center; kütüphanelerin göstermediğini ele geçirmek için ise hesap çiftliği feed kaydırması.
4. Uygulama içi SDK MITM: AppLovin MAX, Google AdMob, ironSource ve emsallerinin reklam SDK trafiğini araya giren root’lu Android cihaz çiftlikleri.
5. Landing sayfası ve funnel taraması: kreatif click hedeflerini tracker, cloaker ve prelander zincirlerinden takip ederek teklifi, affiliate ağını, tracker yazılımını ve tersine mühendisliği yapılmış tüm funnel’ı belirlemek.

Zihinsel model

Push, native, inpage ve popunder reklamlarda casus veritabanları için baskın toplama yöntemi yapısal olarak en basit olanıdır: casus operatör bir publisher olur.

Küçük, üç katlı bir ev hayal edin. Bir duvarı yoğun bir otoyola, başka bir duvarı kısmen daha sakin bir kavşağa bakıyor. Sahibi bu duvarları reklam için nasıl böleceğine karar veriyor: otoyola bakan duvara on panel sıkıştır (bol gelir, çirkin ev, daha az dönen ziyaretçi) ya da yan duvara tek küçük, zarif bir banner koy (daha az gelir, ev hâlâ ev olarak işlev görüyor). Bu bölme kararı (hangi alanın sunulduğu ve nasıl parçalandığı), reklam teknolojisinde envanter dediğimiz şeydir.

Sahibi belli bir kullanılabilir alan düzeni sunar. Bir reklam ağı her iki tarafla sözleşme imzalar: yuvaları doldurması için sahibiyle, içine reklam koyması için markalarla. Ağ eşleştirmeyi yönetir ve komisyon alır.

Reklam teknolojisine çapraz eşleme:

Duvar sizin. Sizin satıyor. Karşılığında ödeme alıyorsunuz. Üzerine hangi billboard’ın çıktığını ve ne zaman çıktığını tam olarak görüyorsunuz. Bir casus veritabanının “rekabet istihbaratı” diye sattığı her şey bu tek olgudan türer.

Aşağıda bir kez açıklanıp bırakacağımız iki jargon parçası daha: dikey (vertical), bir reklamverenin faaliyet gösterdiği niş (finans, sigorta, e-ticaret); DSP ise reklamverenin gerçek zamanlı açık artırmalarda envanter satın almak için kullandığı alıcı tarafı platformudur. Bu kavramlar yeniyse, protokoller için kanonik kaynak IAB Tech Lab , gerçek zamanlı teklif vermenin temelleri için de en.wikipedia.org’un real-time bidding sayfası on dakikada işi görür.

Üç adım

1. Publisher olarak kaydol. Her push/native reklam ağında standart onboarding formu. Bir alan adı verin, şartları kabul edin, ağın JavaScript tag’ini gömün veya bir push CNAME alt alanı yapılandırın.
2. Envantere ziyaretçi gönder. 1000 gösterim başına yaklaşık 0,50 dolardan ucuz popunder/redirect trafiği veya paravan sayfaya karşı gerçek tarayıcılar çalıştıran konut ya da mobil proxy çiftliğinden gelen kendi ürettiği ziyaretçiler. Her ziyaretçi bir reklam çağrısı tetikler.
3. Bid yanıtını yakala. Ağ, kreatif meta verisini düz JSON olarak gönderir. Publisher’ın JS’i (operatörün yazdığı kod) yanıtı okur, operatörün toplama uç noktasına gönderir, sonra reklamı normal şekilde render eder; hiçbir şey tuhaf görünmez.

Yayınlanmış ölçek iddiaları bu modele göre gerçekçidir: Spy.House 185+ ülkede günde 12 milyon kreatif alım iddiasında bulunuyor; AdPlexity ve Anstrex ise native, push ve mobil formatlarda örtüşen kapsama listeleri yayınlıyor. 30 ağ, 50 paravan site ve 95 GEO üzerinden yürütülen tek bir operasyon zahmetsizce bu aralığa oturur.

Wire üzerinde ne taşınıyor

Teknik çekirdek, gösterim başına bir HTTP isteği ve bir HTTP yanıtıdır; her ikisi de publisher’ın görüş alanındadır, çünkü isteği yapan publisher’ın kendi JavaScript’idir.

Tipik bir publisher tag’i:

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

Sayfa yüklenirken SDK bir reklam isteği oluşturur. Curl olarak telden geçen şey şuna benzer:

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"

Ağ seçim sürecini yürütür (büyük exchange’ler için DSP’ler arasında gerçek zamanlı teklif açık artırması; standart protokol IAB OpenRTB , push/native uzmanları içinse doğrudan kampanya eşleştirmesi) ve kazanan kreatifi JSON olarak döner:

{
  "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"
  }
}

Başlık, gövde, görsel URL’leri, click hedefi, kampanya ID, reklamveren ID, teklif fiyatı ve eşleşmeyi tetikleyen hedefleme bağlamı: tek bir yapılandırılmış nesnenin içinde tüm reklam teslimi. Publisher’ın SDK’sı sonra reklamı render eder.

Araya girmek rutin bir iştir. Publisher, SDK’dan önce çalışan sayfa düzeyi JavaScript’i kontrol eder; bir fetch sarmalayıcı veya XMLHttpRequest shim’i her şeyi görür:

// ağın SDK'sından önce yüklenir
(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'ya dönmeden önce yanıtı toplayıcıya kopyala
      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 aynı yanıtı görür ve reklamı normal şekilde render eder. Toplayıcı tam kaydı alır. Ziyaretçi çalışan bir reklam görür. Hiçbir istek engellenmedi, yanıt değiştirilmedi, hiçbir başarısızlık metriği yükselmedi.

Fiyatlandırma modelleri ve her birinin sızdırdığı şey

Farklı ağlar farklı fiyatlandırma modelleri kullanır ve model, bid yanıtında hangi alanların gerçekten anlamlı sinyal taşıdığını belirler. Sözlük:

• CPM (cost per mille): reklamveren 1000 gösterim başına öder. Push, popunder ve çoğu native için varsayılan. PropellerAds, RichAds, Adsterra. Teklif 1000 başına dolar olarak ifade edilir.
• CPC (cost per click): reklamveren tıklama başına öder. MGID, Taboola, Outbrain native’de yaygın. Tıklama başına teklif.
• CPA (cost per action): reklamveren dönüşümde (kayıt, depozito, install) öder. Affiliate ağlarda (AdCombo, MaxBounty, ClickDealer) kullanılır; reklam ağları nadiren doğrudan kullanır. Dönüşüm, reklamveren tarafında sunucu seviyesinde gerçekleşir, bu nedenle CPA ödemeleri bid yanıtında görünmez.
• CPI (cost per install): aksiyonun bir MMP (AppsFlyer, Adjust, Branch) tarafından atfedildiği install olduğu mobil uygulama CPA’sı.
• CPV (cost per view): video; izleme tamamlaması başına öder.

En çok istihbarat sızdıran model CPC’dir. Teklif tutarı, reklamverenlerin o GEO ve dikeyde tıklama başına ödemeye hazır olduğu fiyatın gerçek zamanlı sinyalidir ve her gösterimde tazedir. Reklamveren ve GEO başına üç aylık CPC teklif geçmişi, hiçbir reklamverenin paylaşmaya rıza göstermediği bir rekabet istihbaratı veri setidir; bid yanıtını gören publisher’ın doğal görüş alanının yan etkisi olarak birikir.

Somut olarak, casus operatörün dahili sorgu API’si şu tarz uç noktaları açar:

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"

ve bir zaman serisi döner:

[
  {"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}
]

Ticari casus aracının önyüzü, tam olarak bu yapının üzerine konmuş bir arama kutusudur. Müşteri filtre açılır menüleri ve teklif yörüngesi grafikleri görür; altında, yukarıdaki JS interception bloğundan gösterim gösterim doldurulmuş aynı normalize edilmiş bid tablosuna karşı çalışan aynı zaman serisi sorgusu vardır.

CPM, gösterim başına daha az sızdırır ama toplu hâlde işe yarar. Tek bir CPM teklifi bin gösterim başına ödeme isteğini ifade eder (her biri bir kuruşun kesirleri) ve tek başına reklamverenin bir tıklamayı veya dönüşümü nasıl değerlendirdiği hakkında çok az şey söyler. Bu, bütçe × kitle eşleşmesi × bir dikkat birimi için ihale baskısının bir işlevidir, reklamverenin ekonomik modelinin doğrudan okuması değil.

Önemli olan dağılımdır. Aynı kampanya için binlerce loglanmış gösterim üzerinde CPM zaman serisi bütçe şeklini (yükselen teklifler = ölçeklendirme baskısı, düşen teklifler = bütçe tükenmesi veya dayparting), GEO fiyat seviyelerini (DE envanteri aynı dikeyde 3 dolar CPM’de temizlenirken VN 0,30 dolarda temizlenebilir; gerçek pazar seviyesi fiyatlandırmayı yüzeye çıkarır), kitle önceliklerini (hangi hedefleme kovaları en yüksek teklifi çeker) ve kampanya yaşam süresini açığa çıkarır. Bunların hiçbiri tek gösterimde görünmez; hepsi birkaç haftalık birikmiş geçmişten ortaya çıkar.

CPA bid yanıtında hiç görünmez: casus operatör dönüşüm uç noktası değildir. Bu boşluğu kapatmak click hedefini tracker, cloaker ve offer wall zincirinde takip etmeyi gerektirir; bu tamamen farklı bir yöntemdir.

Teklif neden yanıtta yer alıyor? Adil bir boşluk dolduran soru: casus veritabanı, ağın prensip olarak göndermek zorunda olmadığı bir sayıyı okuyor. Beş örtüşen sebep:

1. OpenRTB bunu gerektirir. price alanı BidResponse.seatbid.bid şemasında zorunludur. OpenRTB üzerine kurulu ağlar bu şeffaflığı tasarım gereği devralır.
2. Publisher revshare doğrulaması. Push ve native ağları publisher’lara reklamveren teklifinin %60–80’ini öder. Rakamı sakla → publisher güvenini kaybet → envanteri gösterene kaptır. Şeffaflık eksikliği arz tarafında rekabet dezavantajıdır.
3. Publisher tarafında yield optimizasyonu. Publisher’lar zone başına CPM tabanı belirler, yerleşim A/B testi yapar, kreatif yoğunluğunu ayarlar. Bunların hepsi gösterim başına teklif verisi gerektirir. Envanterinin hangi fiyattan temizlendiğini göremeyen publisher, sattığı şeyi optimize edemez.
4. İstemci tarafında render. Push, native, popunder, inpage hepsi publisher’ın kendi JavaScript’iyle render edilir. Teklif, tag’in zaten render için ihtiyaç duyduğu kreatif URL’si ve click URL’siyle aynı yükte oturur; ağa hiçbir ek maliyet getirmeden sızar.
5. Click URL’si genelde teklifi içinde kodlar. Birçok ağ, gösterim ile tıklama arasındaki ücretlendirme mutabakatı için teklif değerini click tracking URL’sine yerleştirir. Üst seviye JSON’dan bid alanını çıkarsanız bile click URL parametrelerinde gelmeye devam eder.

Yapısal istisna aşağıda detaylandırılan walled garden senaryosudur: Google AdSense publisher kazançlarını gösterim başına teklifleri açığa çıkarmak yerine kategori seviyesinde toplulaştırır. Bu opaklık, publisher sızmasının walled garden’lara karşı başarısız olmasını sağlayan üç savunmadan biridir ve üçüncü taraf ağların kopyalayabileceği ama kopyalamadığı bir tercihtir. Çünkü onboarding ve elde tutmada publisher şeffaflığının değeri, uzun kuyruk casus endekslemesinin maliyetinden ağır basar.

OpenRTB ve bidstream

Çoğu exchange ve büyük ağ IAB OpenRTB protokolünü konuşur. Bid request ve response, reklamveren alan adı (adomain), kreatif markup (adm), teklif fiyatı (price), kreatif ID (crid) ve IAB kategori taksonomisi (cat) için belgelenmiş alanlarla halka açık bir JSON şemasını izler: BidRequest, Imp, Seatbid, Bid. Bir casus operatör için OpenRTB uyumlu ağ en elverişli ortamdır: alan adları öngörülebilir, şema belgelenmiş, ağlar arasında normalleştirme önemsiz.

Pratik pipeline: legacy/proprietary ağ formatı başına bir parser, tüm OpenRTB uyumlu ağlar için ortak bir parser, tüm çıktı tek bir dahili şemaya normalize edilir. Casus aracın önyüzündeki ağlar arası arama UI’si bu normalize edilmiş tablo üzerinde ince bir katmandır; bu yüzden her büyük casus servisi temelde aynı filtre setini (GEO, cihaz, OS, tarayıcı, reklam türü, tarih aralığı, reklamveren anahtar kelimesi) sunar.

Daha kolay yol: publisher dashboard’u

Wire seviyesinde araya girme genel durumdur. Özel durum daha da basit: ağın kendi publisher dashboard’u aynı verinin üzerinde bir arama UI’sidir. Publisher olarak giriş yapan operatör kreatif önizlemelerini, reklamveren adlarını veya ID’lerini, click hedeflerini, sunulan gösterimlerdeki teklif tutarlarını, gün içi dağılımı, kampanya ID’lerini görür. Dashboard, meşru publisher’ların üzerlerinden geçen şeyi izlemesi ve marka güvenliği kontrolü yapabilmesi için vardır; bir casus operatör için ise olası en kolay export arayüzüdür.

Dashboard’un zengin olduğu yerde casus operatör onu kullanır. Zayıf, eksik veya belgelenmemiş olduğu yerde (özellikle push’ta, çünkü wire’daki şifrelenmiş Web Push yükünün, şifre çözen service worker’ı kontrol etmeden ele alınması zordur) wire interception boşluğu doldurur. 25–40 ağ arasında çarpıldığında ortaya çıkan veritabanı yapılandırılmış, normalize edilmiş ve dünya çapında çalışan her push/native kampanyanın canlı durumuyla yaklaşık olarak güncel olur.

GEO çarpanı

Brezilya’daki bir publisher Brezilya kreatiflerini görür. 95 ülkede kreatif yakalamak için operatörün şunlardan birine ihtiyacı vardır:

1. Her GEO’dan paravan publisher sitelerine gerçek ziyaretçiler: ağ doğal olarak GEO hedefli envanteri sunar. Operatörler ucuz trafik (popunder, redirect, push) başka ağlardan satın alır ve kendi publisher sitelerinden geçirip reklam çağrılarını tetikler. Ekonomi: 0,0005 dolara redirect gösterimi, endekslemeye değer bir kreatif sunumu üretir.

2. Konut veya mobil proxy’ler üzerinden sentetik ziyaretçiler: reklam tag’ini yüklemek ve yanıtı yakalamak için publisher sayfasını gerçek tarayıcıyla çalıştırır. Bu yol gösterim başına daha pahalıdır ancak ucuz redirect trafiğinin üretmediği temiz, operatör segmentli kapsam üretir. En büyük casus pazaryerlerinin mobil ve konut proxy satıcılarını başlıca iş ortağı kategorisi olarak çapraz satmasının sebebi tam da budur.

Mobil operatör boyutu özellikle önemlidir: reklam ağları hedeflemeyi istek yapan IP’nin operatör ASN’sine bağlar. Jenerik veri merkezi proxy’leri “Wi-Fi/unknown” olarak görünür ve operatör segmentli kampanyaları tamamen ıskalar. Gerçek operatör uç noktalarından geçen mobil proxy’ler, yalnızca diyelim Turkcell, Vodafone TR veya Vodafone IT abonelerine ateşlenen kampanyaları yüzeye çıkarır; tam da casusluk yapılmaya değer envanter; çünkü o hedefleme kârlı ve iyi ayarlanmış bir kampanyaya işaret eder.

Reklam ağları bunu neden yapısal olarak hoş görür

Cevap ekonomik döngüde:

Reklamveren Reklam Ağına öder
        ↓
Reklam Ağı kreatifi casus operatörün "publisher" sitesine sunar
        ↓
Reklam Ağı publisher gelirini casus operatöre öder  ← ağın teşviki
        ↓
Casus operatör her kreatifi loglar, diğer affiliate'lere erişim satar
        ↓
Diğer affiliate'ler aynı Reklam Ağı üzerinden kopya kampanyalar başlatır
        ↓
Reklam Ağı daha fazla reklamveren geliri kazanır (döngü kapanır)

Reklam ağı aynı faaliyetten iki kez ödeme alır. Orijinal reklamverenin harcaması casus operatöre giden publisher ödemesini finanse eder. Kopyalayan reklamverenin harcaması bir sonraki döngüyü finanse eder. Ağların bu publisher’ları tespit veya yasaklama teşviki yoktur ve bu hizalanmanın gözlemlenebilir kanıtı vardır: PropellerAds kurumsal blogunda özel bir /blog/tag/spy-tools/ indeksi tutar, RichAds en iyi push casus araçları liste yazısı yayınlar ve Adsterra kendi en iyi reklam casus araçları öneri yazısını yürütür. Üçü de kendi envanterlerini endeksleyen aynı platformları, çoğu zaman bu araçlara affiliate bağlantılarıyla kapsıyor. Ağlar casus ekosisteminin hasımları değil, tamamlayıcı bir katmanıdır.

Walled garden’lar neden farklı

Yukarıdaki yöntem PropellerAds, RichAds, MGID ve diğer 30’dan fazla üçüncü taraf push/native ağda çalışır çünkü bu ağlar reklamverenler ile bağımsız publisher’lardan oluşan açık bir ekosistem arasında oturur. Bir alan adı olan herkes publisher olur; ağın kendi birinci taraf yüzeyi yoktur ve reklamı barındıracak bir publisher olmadan reklam sunamaz. Publisher, ağın dışa teslim kanalıdır. Casus operatör de bunlardan biri olur.

Google Search, Meta (Facebook ve Instagram), TikTok ve LinkedIn böyle çalışmaz. Reklamları kendi birinci taraf yüzeylerinde, kendi uygulama ve sunucularıyla render edilerek çalışır: Google arama sonuçları sayfası, Instagram ve Facebook feed’leri, TikTok For You akışı, LinkedIn timeline’ı. Reklamveren onlara öder; onlar da reklamı kendi mülkleri üzerinde kullanıcılara doğrudan gösterir. Üzerine kayıt olabileceğin üçüncü taraf publisher envanteri yok, Meta sponsorlu postlarını alacak gömülebilir JS tag’i yok, Google Search reklamlarına Google’ın kendi yüzeyleri dışından abone olunacak API yok. Sunum yüzeyi platformun kendisidir.

Walled garden’ların üçüncü taraf publisher ağları olduğu yerlerde (Google AdSense ve daha geniş Google Display Network, in-app için Meta Audience Network) üç yapısal savunma publisher sızmasının çalışmasını engeller.

1. Cross-origin iframe’ler

AdSense reklamları googleads.g.doubleclick.net veya tpc.googlesyndication.com üzerinden sunulan bir iframe içinde yüklenir. Publisher’ın JavaScript’i ana sayfada çalışır; reklam iframe’de çalışır; tarayıcının same-origin policy’si iframe içeriğini publisher kodundan görünmez kılar:

// publisher'ın sayfası reklam iframe'ini incelemeye çalışıyor
const adFrame = document.querySelector('iframe[src*="doubleclick"]');

adFrame.contentDocument;
// → null  (same-origin policy erişimi engeller)

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

Publisher, Google’a boş bir dikdörtgen kiraya verir. Publisher tarafı koddan erişilebilen bid meta verisi, kreatif URL’si, reklamveren kimliği yok.

2. Sunucu tarafında seçim, açığa çıkarılmış bid yanıtı yok

Google hangi reklamın gösterileceğini kendi altyapısında seçer. Publisher, reklamveren ID’si, kampanya ID’si ve kreatif meta veriyle dolu bir JSON bid yanıtı değil, sandbox’lanmış iframe içinde render edilmiş bir reklam alır. Publisher dashboard’u kreatif başına teklif geçmişi değil, IAB kategorisi başına toplulaştırılmış gelir gösterir; bu kategoriler de tasarım gereği kabadır (“Finance > Insurance”, “Allianz under-30s EU campaign” değil). Publisher’ın üzerinden geçen şeye dair görüş alanı tasarım gereği düşük çözünürlüklüdür.

3. Agresif hesap düzeyinde uygulama

Hem Google hem de Meta publisher tarafında özel güven ve güvenlik operasyonları yürütür; ML tabanlı sahtekârlık tespiti artı hesabınız üzerinden sunulan reklamların kazınması, araya girilmesi veya parmak izlerinin alınmasını yasaklayan açık Hizmet Şartları. Hesap feshi artı gelir dondurmaları standart yanıttır ve ölçekte uygulanır. Teşvik yapısı, PropellerAds’in teşvik yapısının tersidir: walled garden’lar publisher dolandırıcılığından kazanmak yerine kaybeder, bu yüzden polislik yapar.

Bileşik etki: Meta veya Google reklamlarını ölçekte programatik olarak görmenin tek yolu platformların kendi reklam kütüphaneleri ve kullanıcıya yönelik yüzeye karşı hesap çiftliği feed kaydırmasıdır. Üçüncü taraf ağlardaki evrensel hile olan wire seviyesinde publisher araya girme, walled garden mimarisiyle temas anında hayatta kalmaz.

Reklamveren tarafından tespit

Bir kampanya yürüten ve endekslenip endekslenmediğini bilmek isteyen reklamveren için:

1. Click URL’lerine benzersiz parmak izi yerleştirin. Kreatif başına rastgele bir token’ı kodlayan ve landing sunucusunda loglanan bir query parametresi. O token bir casus aracın arama sonuçlarında veya kendi rakip analizinizde belirirse, kreatif endekslenmiştir.

2. Click trafiğini casus aracı referer’ları için denetleyin. Casus veritabanları landing sayfalarını kendi altyapılarından fetch ederek önizler. Fetch’in User-Agent’ı, IP aralıkları (genellikle EU ve US’teki bilinen cloud subnet’leri) ve JS yürütmesinin yokluğu landing sunucusunda tespit edilebilir.

3. Tuzak kreatifler yayınlayın: küçük teklif tutarlarında, belirgin ama anlamsız metinli. Bu metni casus araçlarda 48 saat sonra arayın. Onu yüzeye çıkaran araçlar onu yakaladı, çıkarmayanlar henüz değil.

Savunma hamleleri

Açıklama: ✓ tam kapsama (savunma yöntemi büyük ölçüde engeller) · ◐ kısmi (yardımcı olur ama tamamen engellemez) · ○ etki yok.

Reklam ağları ile casus veritabanları arasındaki yapısal hizalanma — aynı faaliyet için ağlara iki kez ödeme yapılması — şu anlama gelir: push veya native ağlarda ödeme yapan bir reklamveren olarak endekslenmemenin bir yolu yoktur. Kreatif sızacaktır. Reklamverenin gerçekten kontrol edebildiği iki şey vardır: sızanın değerini azaltmak (kopya kopyalayana yaramasın) ve sızıntıyı ticari olarak işe yaramaz kılmak (mükemmel kopya bile ürün satışını hareket ettirmesin). Aşağıdaki savunmalar en temelden en taktike doğru sıralı.

Bu bölümde kullanılan ve daha önce tanıtılmamış üç terim:

• Lander veya landing page: tıklamanın götürdüğü hedef web sitesi. Kreatif kullanıcının feed’inde görünendir; lander, tıklamadan sonra yüklenen sayfadır.
• Funnel: kreatiften, tracking yönlendirmeleri üzerinden, lander’a ve oradan reklamverenin gerçekte istediği aksiyona (kayıt, satın alma, install) kadar uzanan tam zincir.
• Cloaker: funnel’da farklı ziyaretçi türlerine farklı içerik gösteren sunucu tarafı filtre. Gerçek alışverişçiler asıl teklifi görür, bot ve crawler’lar jenerik bir tuzak görür. Terim, en çok gri alandaki affiliate pazarlamayla anılır, ama altta yatan mekanizma (insan ziyaretçiyi bir kazıyıcıdan ayırmak) meşru dolandırıcılık önleme, bölgesel kişiselleştirme ve bot savunmasında standart uygulamadır; tam olarak Cloudflare Bot Management , DataDome ve FingerprintJS Pro gibi araçların büyük markalar için yaptığı iş.

1. Marka belirginliği: tek kalıcı savunma

İnandırıcı şekilde kopyalanması zor olan bir kreatif, bulunması zor olandan daha değerlidir. Bir rakip sizin kreatifinizi alıp marka adını değiştirir ve sonuç kitlenize hâlâ inandırıcı görünüyorsa, sızıntı para taşır. Eğer değişim açıkça sahte okunuyorsa, taşımaz. Belirgin tipografi, renk paleti, görsel yapı ve ses tonu, herhangi bir teknik karşı önlemden daha fazla savunma ağırlığı taşır; bir yüzyıl boyunca ikonik billboard kampanyalarını koruyan mantığın aynısı.

Pratik test: kreatifinizi alın, markanızı bir rakibin markasıyla değiştirin ve onlar için inandırıcı bir reklam gibi okunup okunmadığını sorun. Evetse, varlık jeneriktir ve sızıntı tehlikelidir. “Bu kesinlikle onların değil” diye okunuyorsa, sızıntı çoğunlukla zararsızdır. Aynı metni kendi adıyla yürüten bir rakip, sizi zaten tanıyan herkese kötü bir kopya gibi görünür.

2. Kancayı tekliften ayır

Belirgin bir kreatifi inandırıcı şekilde kopyalamak zordur. Teklif yüklü bir kreatifi okumak kolaydır. Spesifikleri (partner adı, fiyat, hedef segment, tam CTA) reklam biriminin üzerinden çıkarın ve tıklamanın arkasına gizleyin. “Allianz, 30 yaş altı için aylık 18 €‘ya düşüyor, buradan kaydolun” diyen bir reklam, partneri, fiyatı, segmenti ve funnel’ı tek ekran görüntüsünde rakibe verir. Aynı kanca, kendi belirgin ses tonunuzda, özel lander’a saklanmış hâlde, açıyı verir ama playbook’u vermez.

3. Token bağlı click URL’leri

Her click URL’si sunucu tarafında kısa süreyle imzalanmış, tıklama başına bir token taşır. Bir ile dört saat yeterlidir. Lander’ınız token’ı doğrular; süresi dolmuş veya tekrar oynatılmış token’lar gerçek teklif yerine jenerik bir sayfaya iner. Casus crawler URL’yi bir kez yakalar, URL casus veritabanında yüzeye çıktığında ölmüştür ve en basit rekabet analizi hamlesi (yakalanan tıklamayı yeniden oynat) çalışmayı keser.

Kreatif kendi yönlendiricinizi gösteren tek bir statik URL taşır (https://track.you.com/c/<creative-id>). Ağın endekslediği ve sakladığı URL budur. Gerçek bir tıklama geldiğinde yönlendirici taze imzalı bir token üretir ve ziyaretçiyi token eklenmiş halde 302 ile lander’a gönderir. 301 değil, 302 kullanın: 301 önbelleklenebilir, bu da sonraki her ziyaretçi için tek bir token’ı URL’ye dondurur; 302 her tıklamayı taze bir token için sunucunuza geri zorlar.

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

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

// Yönlendiricide, her tıklamada:
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'sine ?t=... olarak eklenir
}

// Lander'da, teklifi göstermeden önce:
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;
}

Büyük atıf platformları (AppsFlyer (OneLink + Protect360), Branch, Adjust, Google Campaign Manager 360) tıklama başına kendi ID’lerini üretir ve altyapılarında sunucu tarafı sahtekârlık tespiti (click replay, spoofing, bot trafiği) çalıştırır; ama karar lander’ınızın istek anında kontrol edebileceği bir primitif olarak değil, dashboard’unuzda atıf sonrası bayrak olarak gelir. Yukarıdaki imzalı token deseni hangi platformu kullanırsanız kullanın onun üzerine oturur; özellikle click-fraud paketlerinin ele almak için tasarlanmadığı casus crawler replay vektörünü hedefler.

Süre penceresi bir tradeoff’tur. Çok kısa (bir saatin altı) ve sekmeyi açıp ertesi gün geri gelen gerçek kullanıcılar tuzak sayfaya iner, dönüşümü zedeler. Çok uzun (bir günden fazla) ve casus veritabanları canlı URL’leri sona ermeden önce yakalar. Dört saat, mobil trafikteki meşru tıklama gecikmesinin büyük çoğunluğunu kapsar ve çoğu casus veritabanı yenileme penceresini aşar. Sürekli kampanyalar için imzalama anahtarını haftada bir döndürün; böylece yakalanmış token’lar bile geçerli anahtara karşı doğrulanmaktan keser.

4. Lander’da sunucu tarafı kişiselleştirme

Lander, teklif detayları içine pişirilmiş statik bir HTML dosyası değildir. Ziyaretçi başına istek bağlamından render edilir: GEO, cihaz, referer, click parametreleri, zaman. Aynı görünen URL’lere giren iki ziyaretçi esaslı biçimde farklı sayfalar görür. Casus crawler tek bir sentetik görüntüyü yakalar; yakalanan görüntü gerçek müşterilerin gördüğünü temsil etmez ve casus veritabanı kampanyanızı kopyalanacak tek bir kanonik lander kaydetmek yerine bağlama özgü anlık görüntülere böler.

Varyasyonu yönlendiren girdiler her web stack’inin zaten sahip olduğu istek bağlamı primitifleridir: GEO (IP’den veya click parametresinden), operatör ASN, cihaz sınıfı, OS, tarayıcı, referer entropisi, click zaman damgası, ve click URL’sinde taşınan kampanya/kreatif ID’leri. Her girdi ziyaretçinin gördüğü teklif varyantını, ödeme yöntemini, metin bloğunu ve fiyatı kaydırır. Frankfurt’taki veri merkezi ASN’inden gelen, Vodafone IT 5G iOS için tasarlanmış bir click URL’sini ziyaret eden casus crawler, kampanyanın gerçek hedeflemesiyle hiç ilgisi olmayan bir fallback varyantı görür.

Kişiselleştirme ile cloaking arasındaki çizgi niyet ve şeffaflıktır. Kişiselleştirme her meşru ziyaretçiyi birinci sınıf vaka olarak ele alır ve gerçekten hedeflendikleri teklifi gösterir; tuzak içerik gören tek ziyaretçi, istek bağlamı sunulan hiçbir kitleye uymayanlardır (botlar, casus crawler’lar, alakalı olduğunda ağın kendi reklam inceleme trafiği). Katı affiliate anlamında cloaking, reklam ağının uyumluluk denetçilerini kasten aldatır. Aynı mekanizma her ikisini de uygular; meşruiyet, ağın inceleme trafiğine karşı gösterilen ile hedeflenmemiş bir ziyaretçiye gösterilen arasındaki farkta yaşar.

Bütün bu dallanma mantığının bir tuzağı var: ofisten doğrulayamazsınız. Kendi lander’ınızı veri merkezi IP’sinden, tüketici VPN’inden veya ev Wi-Fi’sindeki laptoptan yüklemek tasarım gereği fallback dalına vurur; tam olarak kişiselleştirme kurallarının engellediği şey. Tek ground-truth testi, gerçekten hedeflediğiniz istek bağlamından lander’ı yüklemektir: aynı operatör ASN’i, aynı GEO, aynı cihaz sınıfı. iProxy.online bir Android telefonu ve yerel SIM’i gerçek operatör IP’si üzerinde adanmış bir mobil proxy’ye dönüştürür; böylece lander’ı gerçek bir Vodafone IT 5G ziyaretçisinin yükleyeceği gibi yükleyebilir ve harcamayı ölçeklemeden önce sunulan varyantın hedeflemeyle eşleştiğini doğrulayabilirsiniz. Aynı filo casus savunma denetimi olarak da iş görür: bir casus veritabanında yakalanan URL’yi aynı operatör IP’sinden tekrar oynatın ve tuzak mantığınızın crawler’ın bulunduğu bağlamda gerçekten devreye girdiğini kontrol edin.

5. Funnel kenarlarında bot tespiti

Cloaking sınıfı tekniklerin meşru, savunulabilir uygulaması budur. Lander kenarındaki standart bot azaltma katmanları otomatik ziyaretçileri tanımlar ve onları gerçek teklif içeriğinden uzağa yönlendirir. Büyük online perakendecilerin kimlik bilgisi doldurma ve envanter biriktirme botlarına karşı çalıştırdığı aynı makine burada da geçerlidir: casus crawler bir bottur; bot tespiti teklif sayfasını onun erişiminden uzak tutar. Yakalanan lander jenerik bir tuzak haline gelir ve casus veritabanının kopyalayan rakip için değeri buna göre azalır.

Büyük bot azaltma ürünlerinin somut olarak ne yakaladığı: Cloudflare Bot Management her isteği TLS parmak izi, HTTP/2 frame sıralaması, IP itibarı, davranış geçmişi ve güven testinin kombinasyonunda puanlar; DataDome benzer sinyalleri uygulama tarafı davranışa odaklı katmanlarla (fare hareketi, kaydırma temposu, form alanı zamanlaması) katmanlar; FingerprintJS Pro cookie temizliğini ve incognito modunu atlatan kalıcı tarayıcı parmak izlerini vurgular. Temiz veri merkezi IP’sinden çalışan headless tarayıcı casus crawler’ı üçünde de temel sinyallerde başarısız olur; konut proxy arkasında gerçek bir Chromium build’i çalıştıran sofistike crawler bir ya da ikisini geçer ama tam yığını nadiren.

Bu savunmanın gürültülü olduğu yer mobil operatör trafiği etrafıdır. Gerçek operatör ASN’lerinden gelen mobil proxy IP’leri CGNAT üzerinden geçer ve davranışsal olarak meşru mobil ziyaretçilerle aynı görünür: aynı NAT havuzu, aynı TLS profili, aynı cihaz parmak izleri. Kaba bir “tüm konut veya mobil proxy trafiğini engelle” kuralı, dönüşüm oranınızı, becerikli bir casus operatörü yavaşlatmaktan daha fazla zedeler. Bot tespit eşiğini dönüşüm etkisine karşı ayarlayın: mobil tarafta yanlış pozitifler gerçek para maliyetindedir, bu yüzden mobil segment için IP sınıf engellerinden çok davranış sinyallerini (etkileşim örüntüleri, sayfada geçen süre, form etkileşimi) tercih edin.

En sık gördüğümüz örüntü: bir takım bot tespit kurallarını bir operatörün trafik şekline karşı ayarlar, sonra aynı GEO’da farklı bir operatörde aynı kurala fazla güvenir. Operatörleri ve cihaz sınıflarını gerçekten ayıran sinyaller, bir antidetect tarayıcının ya da cloud telefonun yeniden boyayabileceği katmanların altında oturur: SIM MTU’su operatörden operatöre farklıdır, TCP stack parmak izleri cihaz sınıfları arasında farklıdır ve her ikisi de userspace bir aracın taklit edemeyeceği kernel seviyesi primitiflerdir. Vodafone IT iPhone’lara karşı ayarlanmış bir eşik, bir hafta sonra meşru TIM IT Android ziyaretçilerini işaretleyebilir. Eşiği kilitlemeden önce hedef pazar başına en az iki operatör × cihaz kombinasyonuna karşı test edin.

O eşiği dürüstçe ayarlamak istek bağlamının kendisinden test etmeyi gerektirir. Bir iProxy.online mobil proxy size CGNAT yönlendirmeli gerçek operatör ASN’i ve özgün bir cihaz TLS profili verir; antidetect tarayıcıyla eşlendiğinde lander’ınızı hem meşru bir mobil ziyaretçi hem de onu taklit etmeye çalışan daha sofistike bir crawler olarak yüklemenize izin verir. Kuralları antidetect kurulumunu yakalayana kadar yukarı çıkarın, sonra çıplak mobil temel çizgisini cezalandırmayı kesene kadar geri indirin. Bu iki eşik arasındaki aralık operasyon pencerenizdir.

6. Dynamic Creative Optimization (DCO)

Meta, Google ve çoğu programatik DSP’de standart endüstri özelliği: gösterim anında kreatif bileşenlerinin (başlık, görsel, CTA, renk, metin) otomatik varyasyonu. Sunulan her kreatif biraz farklı bir kombinasyon olduğunda, casus veritabanı kopyalamaya değer tek bir net “kazanan” görmez. Kümelenmeyen parçalı varyantlar görür; bu yüzden kopya kampanya yürüten rakipler yanlış varsayımlara karşı test eder ve bütçeyi boşa harcar. DCO ek maliyetsiz bir savunma hamlesidir; platformlar yerel olarak destekler.

Savunma amaçlı parçalama için en önemli varyasyon eksenleri: başlık (3–10 varyant), birincil görsel (3–8 varyant), CTA buton metni (3–5 varyant) ve vurgu rengi (2–4 varyant). Kombinatoryal olarak, her birinde beş varyant olan dört eksen 625 sunulan kombinasyon üretir. Bu gösterimlerden 200’ünü kazıyan bir casus veritabanı 200 farklı kreatif gibi görünen şeyi görür; tek bir kombinasyon veriyi domine etmez, net bir “en iyi” ortaya çıkmaz ve kopya kampanyasını yakalanan sete karşı yürüten bir rakip her varyantı eşit test eder ve hangisinin dönüştüğü hakkında hiçbir şey öğrenmez.

DCO’dan kaçınmak üçüncü taraf push ve native ağlarda walled garden’lardan daha zordur. Meta Advantage+ Creative ve Google Performance Max bileşen düzeyinde varyasyonu otomatik yapar; PropellerAds ve benzeri push ağları tek bir kampanya altında birden fazla kreatif varyantını kabul eder ama genellikle tek bir kreatif içindeki bileşenleri parçalamaz. Push’ta çözüm: kampanya içinde ayrı birimler olarak kreatifin 20–30 mikro-varyantını yayınlayın ve hiçbir tek kreatifin gösterimleri domine etmemesini sağlayın. Walled garden eşdeğerinden operasyonel olarak daha ağır, ama aynı savunma amaçlı parçalamayı sağlar.

7. Piksel seviyesinde watermarking

Kreatif görsellere, videolara ve metne gömülmüş steganografik işaretler: izleyicilere algılanamaz, yakalanan kopyadan kurtarılabilir. Meta’nın watermark-anything gibi açık kaynaklı toolchain’leri JPEG yeniden kodlama, yeniden boyutlandırma ve bir casus crawler’ın genelde kreatifleri ingest etmek için kullandığı ekran görüntüsü-yeniden-sıkıştır yolundan sağ çıkan üretim kalitesinde görsel yükleri gösterir. Aynı prensip metne Unicode boşluk yer değiştirmesi yoluyla uzanır. Yakın tarihli bir yöntem makalesi yaklaşımı başlık ve metin satırları için kataloglar; render edilmiş metni değiştirmeden görünmez karakter varyantları gösterim başına bir ID kodlar. Hiçbiri endekslemeyi önlemez. Her ikisi de hangi casus veritabanlarının hangi kreatifleri ne zaman yakaladığını tanımlar ki bu rekabet araştırması hakkında işe yarayan istihbarattır: kim kampanyalarınızı inceliyor, hangi takvimde, hangi toplama yollarıyla.

8. Hız gizlemeyi yener

Casus veritabanları gecikir: en hızlısı için 24 ila 72 saat, uzun kuyruk için bazen bir hafta. 48 saatte bir yeni kreatif varyantı yayınlayan bir takım, öncekini kopyalayan rakiplerin sürekli önündedir. Test kampanyaları için bu tam bir savunmadır; sürekli marka varlığı için kısmidir ve #1’deki marka belirginliği noktası kalan ağırlığı taşır.

9. Casus veritabanlarının gördüğünü yansıt

Reklamverenlerin sürekli atladığı savunma, kendi kampanyalarını bir casus veritabanının kullandığı vantage point’ten denetlemektir. Kendi kreatifinizi sadece ağın raporlama dashboard’unda görüyorsanız, casus operatörlerin gerçekten yakaladığı trafik türüne nasıl yüzeye çıktığı hakkında hiçbir fikriniz yoktur: her hedef GEO’da konut ve mobil operatör IP’lerinden gelen sentetik ziyaretçiler. Ağlar teslimi operatör ASN’sine bağlar; ofis IP’nizde Wi-Fi üzerinde temiz sunulan bir kreatif, ağın aslında hedeflediği Vodafone IT 5G abonesine asla ulaşmayabilir. Rakiplerinizin erişim satın alabileceği şey konusunda kör uçuyorsunuz.

Denetim mekanik: her hedef GEO’da mobil operatör proxy üzerinden gerçek bir tarayıcı çalıştırın, ilgili reklam ağını yürüten bir publisher sayfasını yükleyin ve bir örnekleme penceresi boyunca sunulan kreatifi ve bid yanıtını yakalayın. Sonuç casus operatörün kampanyanızı görüş açısıdır: hangi kreatifler yüzeye çıkıyor, hangi teklif seviyelerinde, hangi hedefleme parametrelerine karşı. “Vodafone IT 5G 30 yaş altı” kreatifiniz operatör bazlı denetimde görünmüyorsa, ağ amaçladığınız şekilde sunmuyor demektir ve aynı teslim boşluğu raporlamanıza görünmezdir. Görünüyorsa, kampanyanızın hangi şeklinin herhangi bir casus veritabanının aşağı akışında olduğunu tam olarak bilirsiniz. Denetim tarayıcısını mobil proxy’ye bağlı bir antidetect profil üzerinden çalıştırın ki yakalanan görüntü o bağlamdaki gerçek bir ziyaretçinin göreceğiyle eşleşsin.

10. Kampanyalarınızın operatör kova yüzeyini çeşitlendirin

“DE mobile” hedefleyen bir kampanya tek geniş kova olarak çalışır. “DE / Vodafone DE 5G 30 yaş altı”, “DE / Telekom DE 4G tüm yaşlar”, “DE / O2 DE 5G şehirli” şeklinde segmentlere ayrılmış bir kampanya bir düzine dar kova olarak çalışır. Toplam gösterim hacmi aynı; casus veritabanı ayak izi değil.

Casus operatörler normalize edilmiş veritabanlarını GEO, cihaz, OS, tarayıcı ve ağın hedefleme bağlam alanlarıyla sorgular. Geniş kovalı bir kampanya casus DB’nin tek bir bitişik diliminde kümelenir: “DE mobile [dikey]” sorgulayın ve tüm kampanya tek görünümde yüzeye çıkar. Dar kovalı kampanya sorgulara dağılır: hiçbir rekabet istihbaratı alıcısı tüm kampanyayı yeniden kurmak için doğal olarak bir düzine spesifik operatör, yaş ve cihaz filtresini birleştirmez, ve yakalanan kreatifler tek büyük kampanyadan çok ayrı küçük kampanyalar gibi görünen hücrelere bölünür. Aynı toplam harcama, aynı toplam erişim, herhangi bir casus veritabanında temelden farklı bir sinyal.

Bu işe yarar çünkü reklam ağları teslimi birinci sınıf hedefleme alanı olarak operatör ASN’ye bağlar. #9’da mobil proxy denetimlerini mümkün kılan aynı özellik, burada operatör kova çeşitlendirmesini anlamlı kılar. Operatör ASN’sini maskeleyen jenerik veri merkezi veya konut proxy’leri bu savunmayı sunamaz; casus operatörün mobil operatör ziyaretçi havuzu zaten operatöre göre segmentlidir, bu yüzden dar operatör kovalarında çalışan bir kampanya yakalamadan sonra bile casus veritabanı genelinde parçalı kalır.

Kapanış düşüncesi: billboard her zaman kopyalanmıştır

Billboard reklamcılığı bir yüzyıldır taklit edilir ve Coca-Cola bunu durdurmak için bir savaş odası kurmaz. Daha güçlü bir şeyleri vardır: bir kopyanın görünür biçimde kopya olduğu kadar belirgin bir kreatif kimliği. Teknik savunmalar günler kazandırır; marka belirginliği on yıllar kazandırır.

Otoyoldaki ev, insanların duvara bakmasını asla durduramaz. Sahibi duvara ne yapılacağına karar verir; her yerde tanınan bir resim, biri fotoğrafını çektiği gün değerini kaybetmez.