Cách công cụ spy quảng cáo thu thập dữ liệu và cách phòng vệ

Điểm cốt lõi: Các công cụ spy quảng cáo (AdPlexity, Anstrex, Spy.House, BigSpy và các đồng nghiệp) xây database chủ yếu bằng cách đăng ký làm publisher trên các mạng push và native bên thứ ba, rồi bắt mọi bid response mà JavaScript của họ nhận được. Về mặt cấu trúc, các mạng dung dưỡng việc này vì họ kiếm tiền hai lần từ cùng một hoạt động: một lần từ nhà quảng cáo gốc, lần nữa từ các bên copycat. Phòng vệ bền vững không phải là che giấu (bất khả thi khi publisher được trả tiền để giao creative) mà là giảm giá trị của thứ rò rỉ: bản sắc thương hiệu khiến bản copy lộ rõ là hàng nhái, URL click gắn token, cá nhân hóa lander từ phía server, bot detection ở rìa funnel, và soi chiếu góc nhìn của chính bên spy về chiến dịch của bạn qua audit proxy di động trên ASN nhà mạng thật.

Các nền tảng ad intelligence trong giới affiliate (AdPlexity, Anstrex, AdSpy, BigSpy, Spy.House, Mobidea và rất nhiều đối thủ nhỏ hơn) bán quyền truy cập vào database hàng triệu creative quảng cáo, tìm kiếm được theo GEO, vertical, nhà quảng cáo và ngày tháng. Hầu hết bài viết công khai về chúng dừng ở câu “họ thu thập quảng cáo từ ad network” rồi chuyển sang review sản phẩm. Còn cơ chế thu thập thực tế thì thú vị về mặt kỹ thuật, các phòng vệ thì không hiển nhiên, và gần như không có bài nào nghiêm túc viết về cả hai mảng.

Năm cơ chế thu thập

Năm cơ chế khác nhau về bản chất cung cấp dữ liệu cho một database spy quảng cáo hiện đại, mỗi cơ chế có hồ sơ kỹ thuật và câu chuyện phòng vệ riêng:

1. Publisher infiltration: đăng ký làm publisher trên các mạng push/native bên thứ ba để bắt mọi creative họ phục vụ. Chủ đề của bài viết này.
2. Thu thập push subscription: khai thác giao thức Web Push để bắt payload thông báo đã mã hóa qua một service worker do bên spy kiểm soát.
3. Ad library công khai và scraping social ads: Meta Ad Library, TikTok Creative Center, Google Ads Transparency Center, cộng thêm việc cuộn feed bằng account farm cho phần mà library không phơi bày.
4. MITM SDK in-app: trang trại thiết bị Android đã root chặn lưu lượng ad SDK từ AppLovin MAX, Google AdMob, ironSource và các SDK cùng loại.
5. Crawl landing page và funnel: lần theo điểm đến click của creative qua chuỗi tracker, cloaker, prelander để nhận diện offer, mạng affiliate, phần mềm tracker và toàn bộ funnel được dịch ngược lại.

Mô hình tư duy

Cơ chế thu thập chủ đạo cho các database spy push, native, inpage và popunder lại là cơ chế đơn giản nhất về cấu trúc: bên vận hành spy trở thành publisher.

Hãy hình dung một ngôi nhà nhỏ ba tầng. Một bức tường quay ra đường cao tốc đông đúc. Bức tường khác quay một phần ra con đường ngang yên tĩnh. Chủ nhà tự quyết định chia tường thành các ô quảng cáo thế nào: mười tấm dán kín bức tường nhìn ra cao tốc (nhiều doanh thu, nhà xấu, ít khách quay lại), hay một biển nhỏ trang nhã ở tường bên (ít doanh thu, ngôi nhà vẫn là một ngôi nhà). Quyết định chia ô đó (chừa bao nhiêu không gian và chia ra sao) chính là cái mà ad-tech gọi là inventory.

Chủ nhà cung cấp một bố cục không gian sẵn có. Một mạng quảng cáo ký hợp đồng hai phía: với chủ nhà để lấp đầy các ô, với các thương hiệu để treo quảng cáo lên đó. Mạng lo việc ghép cặp và lấy hoa hồng.

Ánh xạ sang ad-tech:

Đó là tường của bạn. Bạn bán nó. Bạn được trả tiền cho nó. Bạn thấy rõ tấm biển nào được dán lên, khi nào. Mọi thứ mà một database spy bán dưới mác “competitive intelligence” đều phái sinh từ một sự thật đó.

Thêm hai thuật ngữ sẽ dùng dưới đây, định nghĩa một lần rồi không nhắc lại: vertical là ngành dọc mà nhà quảng cáo hoạt động (tài chính, bảo hiểm, e-commerce); DSP là nền tảng phía mua mà nhà quảng cáo dùng để thực sự mua inventory trong phiên đấu giá real-time. Nếu mảng này còn xa lạ, IAB Tech Lab là nguồn chuẩn cho các giao thức và Wikipedia về real-time bidding tóm tắt cơ bản trong 10 phút.

Ba bước

1. Đăng ký làm publisher. Form onboarding tiêu chuẩn trên mọi mạng push/native. Khai báo một domain, chấp nhận điều khoản, nhúng thẻ JavaScript của mạng hoặc cấu hình subdomain CNAME cho push.
2. Dẫn khách vào inventory. Traffic popunder/redirect giá rẻ khoảng 0,50 USD trên 1000 lượt, hoặc tự sinh khách từ một trang trại proxy residential/mobile chạy trình duyệt thật vào shell page. Mỗi khách kích hoạt một lệnh gọi quảng cáo.
3. Bắt bid response. Mạng gửi metadata creative dưới dạng JSON plaintext. JS của publisher (code do bên vận hành tự viết) đọc response, gửi sang endpoint thu thập của bên vận hành, rồi render quảng cáo bình thường để không có gì trông sai lệch.

Các tuyên bố về quy mô được công bố là thực tế trong mô hình này: Spy.House công bố mức nạp 12 triệu creative mỗi ngày trên 185+ quốc gia, còn AdPlexity và Anstrex công bố vùng phủ chồng lấp trên các định dạng native, push và mobile. Một hệ thống 30 mạng, 50 shell site, 95 GEO rơi đúng vào dải đó mà không cần cố gắng nhiều.

Dữ liệu thực sự đi qua wire

Lõi kỹ thuật là một HTTP request và một HTTP response cho mỗi impression, cả hai hoàn toàn lộ ra với publisher vì chính JavaScript của publisher tạo ra request đó.

Một thẻ publisher điển hình:

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

Khi page load, SDK ráp một ad request. Diễn tả bằng curl, đây là dữ liệu được gửi đi:

curl -G "https://srv.adnetwork.example/req" \
  --data-urlencode "zone=1234567" \
  --data-urlencode "geo=VN" \
  --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=vi" \
  --data-urlencode "ts=1737542890"

Mạng chạy bước chọn lọc của nó (đấu giá real-time qua các DSP cho những sàn lớn theo giao thức tiêu chuẩn IAB OpenRTB , hoặc khớp campaign trực tiếp với các mạng chuyên về push/native) và trả về creative thắng dưới dạng JSON:

{
  "zone_id": 1234567,
  "campaign_id": 287465,
  "advertiser_id": 5821,
  "creative": {
    "title": "Đừng trả quá nhiều cho bảo hiểm ô tô",
    "body": "Tài xế ở VN đang đổi nhà cung cấp, kiểm tra giá ngay",
    "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": "VN",
    "carrier": "viettel-vn",
    "device_type": "mobile",
    "os": "android"
  }
}

Tiêu đề, body, URL ảnh, đích click, campaign ID, advertiser ID, giá bid, và bối cảnh targeting đã kích hoạt phiên khớp: toàn bộ quá trình giao quảng cáo nằm trong một đối tượng có cấu trúc. Sau đó SDK của publisher render quảng cáo.

Việc chặn bắt mang tính cơ học thuần túy. Publisher kiểm soát JavaScript cấp page chạy trước SDK; một wrapper fetch hoặc shim XMLHttpRequest thấy được mọi thứ:

// nạp trước SDK của ad network
(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 response sang collector trước khi trả lại cho 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 thấy một response y hệt và render quảng cáo bình thường. Collector nhận đủ bản ghi. Khách truy cập thấy một quảng cáo hoạt động bình thường. Không request nào bị chặn, không response nào bị sửa, không có chỉ số lỗi nào tăng lên ở đâu cả.

Mô hình giá và mỗi loại rò rỉ thứ gì

Các mạng khác nhau dùng mô hình giá khác nhau, và mô hình quyết định trường nào trong bid response thực sự mang tín hiệu hữu ích. Bộ từ vựng:

• CPM (cost per mille): nhà quảng cáo trả theo 1000 impression. Mặc định cho push, popunder, đa số native. PropellerAds, RichAds, Adsterra. Bid biểu diễn bằng USD trên 1000.
• CPC (cost per click): nhà quảng cáo trả theo click. Phổ biến trên MGID, Taboola, Outbrain native. Bid theo từng click.
• CPA (cost per action): nhà quảng cáo trả khi có conversion (đăng ký, nạp tiền, install). Được dùng bởi các mạng affiliate (AdCombo, MaxBounty, ClickDealer), hiếm khi trực tiếp bởi ad network. Conversion xảy ra server-side tại nhà quảng cáo, nên payout CPA không hiển thị trong bid response.
• CPI (cost per install): CPA cho ứng dụng mobile, action là một lượt install được MMP (AppsFlyer, Adjust, Branch) gán nguồn.
• CPV (cost per view): video, trả theo lượt xem hoàn tất.

Mô hình rò rỉ thông tin nhiều nhất là CPC. Mức bid là tín hiệu real-time về mức nhà quảng cáo sẵn sàng trả mỗi click tại GEO và vertical đó, hiện ra tươi mới trên mỗi impression. Ba tháng lịch sử bid CPC cho mỗi nhà quảng cáo, mỗi GEO là một tập dữ liệu competitive intelligence mà không nhà quảng cáo nào từng đồng ý chia sẻ, vậy mà nó tích lũy như một sản phẩm phụ của việc publisher xem bid response một cách bình thường.

Cụ thể, API truy vấn nội bộ của bên spy cuối cùng phơi bày các endpoint như:

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

trả về chuỗi thời gian:

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

Giao diện thương mại của công cụ spy thực ra chỉ là một thanh tìm kiếm trên đúng hình thái dữ liệu này. Khách hàng thấy các dropdown lọc và biểu đồ quỹ đạo bid; bên dưới là cùng một truy vấn time-series trên cùng một bảng bid đã chuẩn hóa, được nạp từng impression một bởi khối JS chặn bắt phía trên.

CPM rò ít hơn trên mỗi impression nhưng hữu ích khi gộp lại. Một bid CPM riêng lẻ thể hiện mức sẵn sàng trả cho mỗi nghìn impression (chỉ một phần nhỏ của một cent), và tự nó nói rất ít về cách nhà quảng cáo định giá một click hay một conversion. Đó là kết quả của ngân sách × mức khớp audience × áp lực phiên đấu trên một đơn vị chú ý, không phải tín hiệu trực tiếp về mô hình kinh tế của nhà quảng cáo.

Cái quan trọng là phân phối. Trên hàng nghìn impression đã log của cùng một campaign, chuỗi CPM theo thời gian lộ ra hình dáng ngân sách (bid tăng = đang nhấn ga, bid giảm = ngân sách cạn hoặc dayparting), mức giá theo GEO (inventory DE có thể clear ở 3 USD CPM trong khi VN clear ở 0,30 USD cho cùng vertical, phơi mức giá thực của thị trường), ưu tiên audience (rổ targeting nào hút bid cao nhất), và tuổi thọ campaign. Không cái nào trong số đó hiện ra trong một impression riêng lẻ; tất cả nổi lên từ vài tuần lịch sử tích lũy.

CPA hoàn toàn không hiện trong bid response: bên vận hành spy không phải là endpoint nhận conversion. Lấp khoảng trống đó đòi hỏi lần theo đích click qua tracker, cloaker và offer wall, vốn là một cơ chế hoàn toàn khác.

Tại sao bid lại nằm trong response? Một câu hỏi lấp khoảng trống chính đáng: database spy đang đọc một con số mà mạng về nguyên tắc có thể không gửi. Năm lý do chồng lấn:

1. OpenRTB yêu cầu. Trường price là bắt buộc trong schema BidResponse.seatbid.bid. Mạng chạy trên OpenRTB thừa kế độ minh bạch đó theo thiết kế.
2. Xác minh revshare cho publisher. Mạng push và native trả publisher 60–80% mức bid của nhà quảng cáo. Giấu số đi → mất niềm tin publisher → mất inventory cho đối thủ chịu công khai. Sự thiếu minh bạch là bất lợi cạnh tranh ở phía cung.
3. Tối ưu yield phía publisher. Publisher đặt floor CPM theo zone, A/B test vị trí, tinh chỉnh mật độ creative. Tất cả đều cần dữ liệu bid mỗi impression. Publisher không thấy inventory mình clear ở đâu thì không thể tối ưu thứ mình bán.
4. Render client-side. Push, native, popunder, inpage đều do JavaScript của publisher render. Bid nằm cùng payload với URL creative và URL click mà thẻ cần để render được; rò ra mà mạng không tốn thêm gì.
5. URL click thường mã hóa bid bên trong. Nhiều mạng nhét giá bid vào URL tracking click để đối chiếu billing giữa impression và click. Dù bạn có lột bid khỏi JSON cấp cao, nó vẫn đi kèm trong tham số URL click.

Ngoại lệ cấu trúc là trường hợp walled garden trình bày bên dưới: Google AdSense gộp doanh thu publisher về mức danh mục thay vì phơi bid theo từng impression. Sự mờ đó là một trong ba phòng vệ khiến publisher infiltration thất bại trước walled garden, và là lựa chọn các mạng bên thứ ba có thể bắt chước nhưng không làm, vì giá trị của minh bạch publisher ở khâu onboarding và giữ chân lớn hơn chi phí của việc bị index dài hạn bởi spy.

OpenRTB và bidstream

Hầu hết các sàn và nhiều mạng lớn nói giao thức IAB OpenRTB. Bid request và response theo schema JSON công khai , gồm BidRequest, Imp, Seatbid, Bid, với các trường tài liệu hóa cho advertiser domain (adomain), markup creative (adm), giá bid (price), creative ID (crid) và taxonomy danh mục IAB (cat). Với bên vận hành spy, mạng tuân thủ OpenRTB là mục tiêu thân thiện nhất: tên trường dễ đoán, schema có tài liệu, chuẩn hóa qua các mạng là chuyện vặt.

Pipeline thực tế: một parser cho mỗi định dạng mạng cũ/đặc thù, một parser dùng chung cho mọi mạng tuân thủ OpenRTB, mọi output chuẩn hóa về một schema nội bộ duy nhất. Giao diện tìm kiếm cross-network trên frontend của công cụ spy chỉ là lớp mỏng trên bảng đã chuẩn hóa đó, lý do mọi dịch vụ spy lớn phơi gần như cùng một bộ lọc (GEO, device, OS, browser, ad type, khoảng ngày, từ khóa nhà quảng cáo).

Con đường dễ hơn: dashboard của publisher

Chặn bắt ở cấp wire là phương án tổng quát. Trường hợp riêng còn đơn giản hơn: dashboard publisher của chính mạng là giao diện tìm kiếm trên cùng bộ dữ liệu. Đăng nhập với tư cách publisher, bên vận hành thấy thumbnail creative, tên hoặc ID nhà quảng cáo, đích click, mức bid trên các impression đã phục vụ, phân phối theo khung giờ, campaign ID. Dashboard tồn tại để publisher hợp pháp giám sát và kiểm tra an toàn thương hiệu những gì chạy qua họ; với bên vận hành spy, đó là giao diện xuất dữ liệu dễ nhất có thể.

Nơi nào dashboard phong phú, bên vận hành dùng. Nơi nào dashboard yếu, thiếu hoặc không có tài liệu (đặc biệt push, nơi payload Web Push đã mã hóa ở wire khó xử lý nếu không kiểm soát service worker giải mã nó), chặn bắt wire bít khe. Nhân lên trên 25–40 mạng, database thu được có cấu trúc, đã chuẩn hóa và đại khái cập nhật với trạng thái sống của mọi campaign push/native đang chạy trên toàn cầu.

Hệ số nhân GEO

Một publisher ở Brazil thấy creative Brazil. Để bắt creative ở 95 quốc gia, bên vận hành cần một trong hai:

1. Khách thật từ mỗi GEO đến các shell site publisher, để ad network phục vụ inventory nhắm theo GEO một cách tự nhiên. Bên vận hành mua traffic giá rẻ (popunder, redirect, push) từ mạng khác và định tuyến qua chính các site publisher của họ để kích hoạt ad call. Bài toán kinh tế: một impression redirect tốn 0,0005 USD và sinh ra một creative đáng index.

2. Khách giả lập qua proxy residential hoặc proxy di động, thực thi page publisher bằng trình duyệt thật để nạp ad tag và bắt response. Cách này đắt hơn trên mỗi impression nhưng cho vùng phủ sạch, phân đoạn theo nhà mạng mà traffic redirect giá rẻ không có được. Các marketplace spy lớn nhất bán chéo các nhà cung cấp proxy di động và residential như một loại đối tác chính, chính vì lý do này.

Khía cạnh mạng di động đặc biệt quan trọng: ad network khớp targeting dựa trên ASN nhà mạng của IP yêu cầu. Proxy datacenter chung chung bị nhận dạng là “Wi-Fi/unknown” và bỏ sót hoàn toàn các campaign nhắm theo nhà mạng. Proxy di động qua endpoint nhà mạng thật làm nổi lên những campaign chỉ kích hoạt cho thuê bao Viettel VN hoặc MobiFone VN chẳng hạn, mà đó chính là inventory đáng spy nhất, vì targeting kiểu đó gợi ý một chiến dịch sinh lời, đã được tinh chỉnh kỹ.

Vì sao về mặt cấu trúc các ad network dung dưỡng việc này

Vòng kinh tế là câu trả lời:

Advertiser trả tiền cho Ad Network
        ↓
Ad Network phục vụ creative đến site "publisher" của bên spy
        ↓
Ad Network trả doanh thu publisher cho bên spy  ← động lực của mạng
        ↓
Bên spy log mọi creative, bán quyền truy cập cho affiliate khác
        ↓
Các affiliate khác phóng chiến dịch copy qua cùng Ad Network
        ↓
Ad Network kiếm thêm doanh thu advertiser (vòng khép kín)

Ad network được trả hai lần từ cùng một hoạt động. Chi tiêu của nhà quảng cáo gốc nuôi payout publisher cho bên spy. Chi tiêu của nhà quảng cáo copy nuôi chu kỳ kế tiếp. Mạng không có động lực phát hiện hay cấm những publisher này, và có bằng chứng quan sát được về sự đồng thuận này: PropellerAds duy trì hẳn một index /blog/tag/spy-tools/ trên blog công ty, RichAds đăng listicle về top push spy tool, Adsterra chạy post recommendation về best ad spy tool của riêng họ; cả ba đều phủ cùng nhóm nền tảng đang index inventory của chính họ, thường kèm liên kết affiliate đến các công cụ đó. Mạng không phải kẻ thù của hệ sinh thái spy mà là một lớp bổ sung.

Vì sao walled garden khác

Cơ chế trên hoạt động trên PropellerAds, RichAds, MGID và 30+ mạng push/native bên thứ ba khác vì các mạng đó nằm giữa nhà quảng cáo và một hệ sinh thái mở gồm các publisher độc lập. Ai có domain đều có thể trở thành publisher; mạng không có bề mặt first-party của riêng nó và không có cách nào giao quảng cáo mà không có publisher để host. Publisher là kênh giao quảng cáo đi ra của mạng. Bên vận hành spy trở thành một publisher như vậy.

Google Search, Meta (Facebook và Instagram), TikTok và LinkedIn không hoạt động kiểu này. Quảng cáo của họ chạy trên các bề mặt first-party của chính họ (trang kết quả tìm kiếm Google, feed Instagram và Facebook, dòng For You của TikTok, timeline LinkedIn), được render bởi chính ứng dụng và server của họ. Nhà quảng cáo trả tiền cho họ; họ hiển thị quảng cáo trực tiếp đến người dùng trên tài sản của họ. Không có inventory publisher bên thứ ba để đăng ký vào, không có thẻ JS nào bạn có thể nhúng để nhận quảng cáo Meta, không có API để đăng ký nhận Google Search ads từ bên ngoài bề mặt của Google. Bề mặt phân phối chính là nền tảng.

Ở những chỗ walled garden có mạng publisher bên thứ ba (Google AdSense và Google Display Network rộng hơn, Meta Audience Network cho in-app), ba phòng vệ cấu trúc khiến publisher infiltration không hoạt động.

1. Iframe cross-origin

Quảng cáo AdSense nạp bên trong iframe phục vụ từ googleads.g.doubleclick.net hoặc tpc.googlesyndication.com. JavaScript của publisher chạy ở page cha; quảng cáo chạy trong iframe; chính sách same-origin của trình duyệt khiến nội dung iframe vô hình với code phía publisher:

// page của publisher cố gắng inspect iframe quảng cáo
const adFrame = document.querySelector('iframe[src*="doubleclick"]');

adFrame.contentDocument;
// → null  (chính sách same-origin chặn truy cập)

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

Publisher cho Google thuê một hình chữ nhật rỗng. Không metadata bid, không URL creative, không danh tính advertiser nào với tới được từ code phía publisher.

2. Chọn lọc server-side, không có bid response phơi ra

Google chọn quảng cáo nào hiển thị trên hạ tầng của chính họ. Publisher nhận về một quảng cáo đã render bên trong iframe sandbox, không phải một JSON bid response với advertiser ID, campaign ID và metadata creative. Dashboard publisher hiển thị doanh thu gộp theo danh mục IAB, không phải lịch sử bid theo từng creative, và ngay cả các danh mục đó cũng cố tình thô (“Finance > Insurance”, không phải “Allianz under-30s EU campaign”). Góc nhìn của publisher về thứ chạy qua họ có độ phân giải thấp một cách có chủ ý.

3. Cưỡng chế quyết liệt ở cấp tài khoản

Cả Google và Meta đều vận hành nhóm trust & safety chuyên trách phía publisher, kèm phát hiện gian lận dựa trên ML cộng với điều khoản dịch vụ cấm một cách tường minh việc scrape, chặn bắt hay fingerprint quảng cáo phục vụ qua tài khoản của bạn. Chấm dứt tài khoản kèm giữ lại doanh thu là phản ứng tiêu chuẩn, được áp dụng trên quy mô lớn. Cấu trúc động lực ngược lại với PropellerAds: walled garden mất tiền vì gian lận publisher chứ không kiếm thêm từ đó, nên họ kiểm soát chặt.

Tác động kết hợp: cách duy nhất để thấy quảng cáo Meta hoặc Google ở quy mô lập trình là dùng chính ad library của các nền tảng và cuộn feed bằng account farm trên bề mặt hướng người dùng. Chặn bắt publisher cấp wire, thủ thuật phổ quát trên các mạng bên thứ ba, không trụ được trước kiến trúc walled garden.

Phát hiện từ phía nhà quảng cáo

Cho một nhà quảng cáo đang chạy chiến dịch và muốn biết có bị index hay không:

1. Nhúng fingerprint duy nhất vào URL click. Một tham số mã hóa token ngẫu nhiên theo từng creative, được log trên server landing. Nếu token đó xuất hiện trong kết quả tìm kiếm của công cụ spy, hoặc trong phân tích đối thủ của chính bạn, creative đã bị index.

2. Audit traffic click tìm referer của công cụ spy. Database spy preview landing page bằng cách fetch từ hạ tầng của họ. User-Agent fetch, dải IP (thường là subnet cloud quen thuộc ở EU và US), và việc không chạy JS đều phát hiện được trên server landing.

3. Tung creative mồi với text đặc trưng nhưng vô nghĩa ở mức bid nhỏ. Tìm text đó trên các công cụ spy sau 48 giờ. Công cụ nào làm nổi nó lên là công cụ đó đã có; công cụ chưa thì chưa.

Các nước đi phòng vệ

Chú giải: ✓ phủ đầy đủ (phòng vệ thực sự chặn được cơ chế) · ◐ một phần (giúp nhưng không chặn hoàn toàn) · ○ không tác dụng.

Sự đồng thuận cấu trúc giữa ad network và database spy (mạng được trả hai lần cho cùng một hoạt động) nghĩa là không có cách nào vừa là nhà quảng cáo trả phí trên mạng push hoặc native vừa tránh bị index. Creative sẽ rò. Thứ nhà quảng cáo kiểm soát được là hai điều: giảm giá trị của thứ bị rò (để bản copy không giúp được bên copy), và làm cho rò rỉ trở nên vô dụng về mặt thương mại (để dù copy hoàn hảo cũng không bán được hàng). Các phòng vệ dưới đây đi từ cơ bản nhất đến chiến thuật nhất.

Ba thuật ngữ dùng xuyên suốt phần này, vì chúng chưa được giới thiệu trước đó:

• Lander hoặc landing page: website đích mà click dẫn đến. Creative là thứ hiện trong feed người dùng; lander là page nạp sau khi click.
• Funnel: toàn bộ chuỗi từ creative, qua các redirect tracking, đến lander và tiếp tục đến hành động mà nhà quảng cáo thực sự muốn (đăng ký, mua hàng, install).
• Cloaker: bộ lọc server-side ở funnel hiển thị nội dung khác nhau cho các loại khách khác nhau: người mua thật thấy offer thật, bot và crawler thấy nội dung mồi chung chung. Từ này gắn nhiều với mảng affiliate vùng xám, nhưng cơ chế nền bên dưới (phân biệt khách thật với scraper) là practice tiêu chuẩn trong phòng chống gian lận hợp pháp, cá nhân hóa theo vùng và phòng vệ bot, đúng thứ mà Cloudflare Bot Management , DataDome và FingerprintJS Pro làm cho các thương hiệu lớn.

1. Bản sắc thương hiệu: phòng vệ duy nhất bền vững

Một creative khó copy thuyết phục có giá trị hơn một creative khó tìm. Nếu đối thủ có thể lấy creative của bạn, đổi tên thương hiệu, và kết quả vẫn nghe có lý với audience của bạn, rò rỉ đó dịch chuyển tiền. Nếu phép đổi đó đọc lên thấy giả lộ liễu, thì không. Typography đặc trưng, bảng màu, cấu trúc thị giác và giọng điệu mang sức nặng phòng vệ lớn hơn bất cứ biện pháp kỹ thuật nào, đúng theo logic đã bảo vệ các chiến dịch biển quảng cáo huyền thoại suốt một thế kỷ.

Bài test thực tế: lấy creative của bạn, thay thương hiệu của bạn bằng thương hiệu đối thủ, rồi hỏi xem nó còn đọc như một quảng cáo đáng tin của họ không. Nếu có, tài sản creative là chung chung và rò rỉ đó nguy hiểm. Nếu kết luận là “rõ ràng không phải của họ,” rò rỉ phần lớn vô hại. Một đối thủ chạy cùng copy với tên của họ trông như hàng nhái với bất kỳ ai đã biết bạn.

2. Tách hook khỏi offer

Creative đặc trưng thì khó copy thuyết phục. Creative chứa đầy offer thì dễ đọc. Giữ các chi tiết cụ thể (tên đối tác, giá, phân khúc mục tiêu, CTA chính xác) ra khỏi bản thân unit và đặt sau cú click. Một quảng cáo đọc “Bảo hiểm Bảo Việt giảm còn 500K/tháng cho dưới 30 tuổi, đăng ký tại đây” trao đối tác, giá, phân khúc và funnel cho đối thủ trong một ảnh chụp màn hình. Cùng hook đó trong giọng điệu đặc trưng của bạn, với phần thông số bị giữ kín sau lander, lộ ra góc tiếp cận nhưng không lộ playbook.

3. Click URL gắn token

Mỗi URL click mang một token theo từng click, ký server-side với thời hạn ngắn. Một đến bốn giờ là đủ. Lander của bạn xác thực token; token hết hạn hoặc bị replay sẽ rơi vào trang chung thay vì offer thật. Crawler spy bắt URL một lần, URL đã chết khi nó nổi trên database spy, và thao tác phân tích cạnh tranh đơn giản nhất (replay cú click đã bắt) không còn hiệu quả.

Creative chứa một URL tĩnh duy nhất trỏ vào redirector của chính bạn (https://track.you.com/c/<creative-id>). Đó là URL mạng index và lưu lại. Khi cú click thật đến, redirector phát ra một token đã ký mới và 302 khách đến lander kèm token. Dùng 302, không phải 301: vì 301 có thể cache, sẽ cố định một token vào URL cho mọi khách kế tiếp; 302 ép mỗi click quay về server của bạn để lấy token tươi.

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

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

// Trong redirector, với mỗi 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}`; // gắn vào URL click dưới dạng ?t=...
}

// Trên lander, trước khi tiết lộ 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;
}

Các nền tảng attribution lớn (AppsFlyer với OneLink + Protect360, Branch, Adjust, Google Campaign Manager 360) tự sinh click ID của mình và chạy phát hiện gian lận server-side (click replay, spoof, bot traffic) bên trong hạ tầng của họ, nhưng verdict đến dưới dạng cờ post-attribution trên dashboard chứ không phải primitive mà lander có thể kiểm tra ngay tại thời điểm request. Mẫu signed-token ở trên ngồi trên nền tảng bạn đang dùng; nó nhắm cụ thể vào vector replay của crawler spy, thứ mà các bộ chống gian lận click không được thiết kế để xử lý.

Cửa sổ hết hạn là một đánh đổi. Quá ngắn (dưới một giờ) thì người dùng thật mở tab và quay lại hôm sau sẽ rơi vào trang mồi, làm hại tỷ lệ chuyển đổi. Quá dài (hơn một ngày) thì database spy bắt URL còn sống nhanh hơn tốc độ chúng hết hạn. Bốn giờ phủ phần lớn độ trễ click hợp pháp trên traffic mobile và vượt qua hầu hết chu kỳ refresh của database spy. Với chiến dịch chạy dài, xoay khóa ký theo tuần để cả khi token bị bắt thì cũng không còn xác thực được với khóa hiện tại.

4. Cá nhân hóa server-side trên lander

Lander không phải file HTML tĩnh đã đóng đinh chi tiết offer. Nó được render theo từng khách từ ngữ cảnh request: GEO, device, referer, tham số click, thời gian. Hai khách bấm vào URL trông giống hệt nhau lại thấy hai trang khác nhau về bản chất. Crawler spy bắt một góc nhìn nhân tạo; góc nhìn bị bắt đó không đại diện cho thứ khách hàng thật thấy, và database spy phân mảnh chiến dịch của bạn thành các snapshot theo ngữ cảnh thay vì ghi lại một lander chuẩn để copy.

Các đầu vào dẫn dắt biến thể là các primitive ngữ cảnh request mà mọi stack web đều có sẵn: GEO (từ IP hoặc tham số click), ASN nhà mạng, hạng device, OS, browser, entropy referer, timestamp click, và campaign/creative ID mang trong URL click. Mỗi đầu vào dịch chuyển biến thể offer, phương thức thanh toán, khối copy và mức giá mà khách thấy. Crawler spy chạy từ ASN datacenter ở Frankfurt vào URL click dành cho Viettel 5G iOS sẽ thấy biến thể fallback chẳng liên quan gì đến targeting thực của chiến dịch.

Ranh giới giữa cá nhân hóa và cloaking là chủ ý và tính minh bạch. Cá nhân hóa đối xử mọi khách hợp pháp như trường hợp first-class và hiển thị offer mà họ thực sự được nhắm tới; chỉ có những khách mà ngữ cảnh request không khớp audience nào mới thấy nội dung mồi (bot, crawler spy, traffic ad review của chính mạng khi liên quan). Cloaking theo nghĩa affiliate chặt chẽ cố tình lừa người duyệt compliance của ad network. Cùng cơ chế, nhưng tính chính danh nằm ở thứ hiển thị cho traffic review của mạng so với một khách không nằm trong nhóm targeting.

Vấn đề với toàn bộ logic phân nhánh này: bạn không thể xác minh nó từ văn phòng. Nạp chính lander của mình qua IP datacenter, VPN người dùng, hay laptop trên Wi-Fi nhà đều rơi vào nhánh fallback có chủ đích, đúng cái mà luật cá nhân hóa chặn. Cách duy nhất để test ground-truth là nạp lander qua đúng ngữ cảnh request bạn nhắm tới: cùng ASN nhà mạng, cùng GEO, cùng hạng device. iProxy.online biến điện thoại Android và SIM nội địa thành proxy di động chuyên dụng trên IP nhà mạng thật, để bạn có thể nạp lander như một khách Viettel 5G thật sẽ thấy và xác nhận biến thể phục vụ khớp targeting trước khi tăng chi tiêu. Cũng đội đó đảm nhiệm vai trò audit phòng vệ spy: replay URL đã bị bắt trong database spy từ cùng IP nhà mạng và kiểm tra xem logic mồi của bạn có thực sự kích hoạt cho ngữ cảnh mà crawler đã ở trong đó.

5. Bot detection ở rìa funnel

Đây là ứng dụng hợp pháp, có thể bảo vệ được của các kỹ thuật loại cloaking. Lớp giảm thiểu bot tiêu chuẩn ở rìa lander nhận diện khách tự động và dẫn họ tránh nội dung offer thật. Cùng bộ máy mà các nhà bán lẻ online chạy chống credential stuffing và bot tích trữ hàng cũng áp dụng ở đây: crawler spy là một bot; bot detection giữ trang offer ngoài tầm với của nó. Lander bị bắt trở thành một mồi nhử chung, và giá trị của database spy với đối thủ copy suy giảm tương ứng.

Cụ thể, các sản phẩm giảm thiểu bot lớn bắt được gì: Cloudflare Bot Management chấm điểm mỗi request trên tổ hợp TLS fingerprint, thứ tự frame HTTP/2, danh tiếng IP, lịch sử hành vi và một challenge độ tin cậy; DataDome chồng các tín hiệu tương tự với trọng tâm là hành vi cấp ứng dụng (chuyển động chuột, nhịp scroll, thời điểm điền form); FingerprintJS Pro nhấn mạnh các fingerprint trình duyệt bền vững sống sót qua xóa cookie và chế độ ẩn danh. Một crawler spy headless browser chạy từ IP datacenter sạch trượt cả ba ở tín hiệu cơ bản; một crawler tinh vi chạy bản Chromium thật sau proxy residential có thể qua một hoặc hai nhưng hiếm khi qua toàn bộ stack.

Phòng vệ này gây nhiễu nhất với traffic mạng di động. IP proxy di động từ ASN nhà mạng thật đi qua CGNAT và trông giống hệt khách di động hợp pháp về hành vi: cùng pool NAT, cùng profile TLS, cùng fingerprint thiết bị. Quy tắc “chặn hết traffic residential hoặc proxy di động” thô sơ sẽ làm hại tỷ lệ chuyển đổi của khách mobile thật hơn là làm chậm bên vận hành spy có nghề. Tinh chỉnh ngưỡng bot detection theo tác động lên conversion: false positive trên mobile mất tiền thật, nên ưu tiên tín hiệu hành vi (mô hình tương tác, thời gian on-page, mức độ tham gia form) hơn là chặn theo hạng IP cho phân khúc mobile.

Tình huống hay gặp nhất: đội ngũ tinh chỉnh quy tắc bot detection theo hình thái traffic của một nhà mạng, rồi quá tin vào quy tắc đó trên một nhà mạng khác cùng GEO. Tín hiệu thực sự tách biệt giữa nhà mạng và hạng device nằm ở dưới các lớp mà antidetect browser hay cloud phone có thể tô lại: MTU SIM khác nhau giữa các nhà mạng, fingerprint TCP stack khác nhau giữa các hạng device, và cả hai đều là primitive cấp kernel mà công cụ userspace không thể giả mạo. Ngưỡng tinh chỉnh trên iPhone Viettel có thể gắn cờ khách MobiFone Android hợp pháp một tuần sau. Test trên ít nhất hai tổ hợp nhà mạng × device cho mỗi thị trường mục tiêu trước khi chốt ngưỡng.

Tinh chỉnh ngưỡng đó một cách trung thực đòi hỏi test từ chính ngữ cảnh request. Một proxy di động iProxy.online cho bạn ASN nhà mạng thật với định tuyến CGNAT và profile TLS device thật; kết hợp với trình duyệt antidetect, cho phép bạn nạp chính lander của mình vừa như một khách di động hợp pháp vừa như một crawler tinh vi đang cố mô phỏng một khách. Đẩy luật lên đến khi nó bắt được cấu hình antidetect, rồi đẩy xuống đến khi nó không trừng phạt baseline mobile trần. Khoảng giữa hai ngưỡng đó là cửa sổ vận hành của bạn.

6. Dynamic Creative Optimization (DCO)

Tính năng tiêu chuẩn của ngành trên Meta, Google và hầu hết DSP programmatic: biến đổi tự động các thành phần creative (tiêu đề, ảnh, CTA, màu, copy) tại thời điểm impression. Khi mỗi creative phục vụ là một tổ hợp hơi khác, database spy không thấy một “kẻ thắng” rõ ràng đáng copy. Nó thấy các biến thể vỡ vụn không clustering, nên đối thủ chạy chiến dịch copy test sai giả định và đốt ngân sách. DCO là động tác phòng vệ không tốn thêm chi phí: nền tảng hỗ trợ sẵn.

Các trục biến thể quan trọng nhất cho việc phân mảnh phòng vệ: tiêu đề (3–10 biến thể), ảnh chính (3–8 biến thể), text nút CTA (3–5 biến thể), và màu nhấn (2–4 biến thể). Tổ hợp: bốn trục với năm biến thể mỗi trục cho 625 tổ hợp phục vụ. Database spy scrape 200 impression thấy trông như 200 creative riêng biệt; không tổ hợp nào áp đảo dữ liệu, không “tốt nhất” rõ ràng nào hiện ra, và đối thủ chạy chiến dịch copy đối với bộ đã bắt được test mọi biến thể như nhau và học chẳng được gì về biến thể nào convert.

DCO khó thoát hơn trên mạng push và native bên thứ ba so với walled garden. Meta Advantage+ Creative và Google Performance Max tự biến đổi cấp thành phần; PropellerAds và các mạng push tương tự chấp nhận nhiều biến thể creative dưới một campaign nhưng thường không phân mảnh thành phần bên trong một creative. Cách giải quyết với push: ship 20–30 micro-variant của creative dưới dạng đơn vị riêng trong campaign, đảm bảo không creative nào áp đảo impression. Việc vận hành nặng hơn so với walled garden nhưng đạt cùng hiệu ứng phân mảnh phòng vệ.

7. Watermark cấp pixel

Đánh dấu steganographic nhúng trong ảnh, video và copy của creative: vô hình với người xem, lấy lại được từ bản copy đã bị bắt. Các bộ công cụ mã nguồn mở như watermark-anything của Meta minh chứng payload ảnh cấp sản phẩm sống sót qua tái mã hóa JPEG, thay đổi kích thước và đường screenshot-rồi-nén mà crawler spy thường dùng để nạp creative. Cùng nguyên lý mở rộng cho text qua thay thế ký tự khoảng trắng Unicode. Một bài phương pháp gần đây liệt kê hướng tiếp cận này cho tiêu đề và dòng copy, nơi các biến thể ký tự vô hình mã hóa ID theo từng impression mà không thay đổi text được render. Cả hai đều không ngăn được index. Cả hai đều xác định database spy nào đã bắt creative nào và khi nào, là thông tin tình báo hữu ích về nghiên cứu cạnh tranh: ai đang nghiên cứu chiến dịch của bạn, theo lịch nào, qua đường thu thập nào.

8. Tốc độ thắng che giấu

Database spy có độ trễ: 24 đến 72 giờ cho cái nhanh nhất, đôi khi cả tuần cho phần đuôi (long tail). Một đội ship biến thể creative mới mỗi 48 giờ luôn đi trước đối thủ đang copy bản cũ. Với chiến dịch test thì đây là phòng vệ trọn vẹn; với hiện diện brand chạy dài thì chỉ một phần, và điểm bản sắc thương hiệu ở #1 gánh phần còn lại.

9. Soi chiếu góc nhìn của database spy

Phòng vệ mà các nhà quảng cáo bỏ qua nhất quán là audit chính chiến dịch của mình từ cùng góc nhìn mà database spy dùng. Nếu chỗ duy nhất bạn thấy creative của mình là trên dashboard báo cáo của mạng, bạn không có ý niệm gì về cách nó hiện ra cho loại traffic mà bên vận hành spy thực sự bắt: khách giả lập từ IP residential và IP nhà mạng di động trên mọi GEO mục tiêu. Mạng khớp giao quảng cáo theo ASN nhà mạng; một creative chạy sạch đến IP văn phòng trên Wi-Fi có thể không bao giờ tới được thuê bao Viettel 5G mà mạng đang nhắm. Bạn bay mù về thứ đối thủ có thể mua quyền truy cập.

Audit là chuyện cơ học: dựng một trình duyệt thật qua proxy nhà mạng di động ở mỗi GEO mục tiêu, nạp một trang publisher chạy ad network liên quan, và bắt creative phục vụ cùng bid response trong một cửa sổ mẫu. Kết quả là góc nhìn của bên vận hành spy về chiến dịch của bạn: những creative nào hiện ra, ở mức bid nào, đối với tham số targeting nào. Nếu creative “Viettel 5G dưới 30 tuổi” của bạn không xuất hiện trong audit theo rổ nhà mạng, mạng không đang giao đúng cách bạn định, và cùng khoảng trống giao đó vô hình với báo cáo của bạn. Nếu nó có xuất hiện, bạn biết chính xác hình hài chiến dịch của bạn ở phía hạ nguồn của bất kỳ database spy nào. Chạy trình duyệt audit qua một profile antidetect được gắn với proxy di động để góc nhìn bắt được khớp với thứ một khách thật trong ngữ cảnh đó sẽ thấy.

10. Đa dạng hóa rổ nhà mạng cho chiến dịch

Một campaign nhắm “VN mobile” chạy như một rổ rộng duy nhất. Một campaign phân thành “VN / Viettel 5G dưới 30 tuổi”, “VN / MobiFone 4G mọi lứa tuổi”, “VN / Vinaphone 5G đô thị” và cứ thế, chạy như cả tá rổ hẹp. Tổng lượng impression không đổi; dấu chân trên database spy thì khác.

Bên vận hành spy truy vấn database đã chuẩn hóa của họ theo GEO, device, OS, browser và các trường ngữ cảnh targeting của mạng. Một campaign rổ rộng cluster vào một lát liền mạch của DB spy: truy vấn “VN mobile [vertical]” thì cả campaign hiện ra trong một góc nhìn. Một campaign rổ hẹp vỡ vụn qua các truy vấn: không bên mua competitive intelligence nào tự nhiên kết hợp cả tá filter nhà mạng, độ tuổi và device cụ thể để dựng lại toàn bộ campaign, và các creative đã bắt vỡ ra trong các ô trông như những campaign nhỏ riêng rẽ chứ không phải một campaign lớn. Cùng tổng chi tiêu, cùng tổng reach, tín hiệu trên database spy khác về bản chất.

Cách này hiệu quả vì ad network khớp giao quảng cáo theo ASN nhà mạng như trường targeting first-class. Cùng đặc tính khiến audit proxy di động khả thi ở #9 cũng làm cho việc đa dạng hóa rổ nhà mạng có ý nghĩa ở đây. Proxy datacenter hoặc residential chung chung che mất ASN nhà mạng không thực hiện được phòng vệ này; pool khách di động của bên vận hành spy tự nó phân theo nhà mạng, nên một campaign hoạt động trong các rổ nhà mạng hẹp vẫn vỡ vụn trên database spy sau khi bị bắt.

Lời kết: tấm biển luôn có người chép lại

Quảng cáo biển bảng đã bị copy suốt một thế kỷ, và Coca-Cola không lập phòng tác chiến để ngăn chuyện đó. Họ có thứ mạnh hơn: một bản sắc sáng tạo đặc trưng đến mức bản copy lộ rõ là copy. Phòng vệ kỹ thuật mua được vài ngày; bản sắc thương hiệu mua được vài thập kỷ.

Ngôi nhà bên đường cao tốc không bao giờ có thể ngăn người ta nhìn vào bức tường. Chủ nhà chỉ có thể chọn vẽ gì lên đó, và một bức tranh được nhận ra ở khắp mọi nơi không mất giá trị vào cái ngày có người chụp lại nó.