Last updated: 21 June 2026

Marcode Integration Progress

Technical status report for the demographic-targeted SERP ad capture pipeline. Everything below has been built, tested, and hardened across 239 merged pull requests.

239
Pull Requests Merged
268
Issues Resolved
129
Security Findings Fixed

Advertiser Identity via Batch Execute

Your first deliverable: for each ad on a Google SERP, resolve the advertiser's name, country, and profile ID using Google's internal batch execute RPC, with full cookie chain continuity from the original search.

Batch Execute Cookie Chain Built

The same browser session's cookies are forwarded from the SERP fetch to the batch execute call. No cookie reconstruction or separate sessions.

  • AEC (bucket cookie) captured from SERP session and forwarded to batchexecute POST
  • SOCS consent cookie pre-injected at session creation — prevents consent wall from suppressing both ads and cookies
  • Session cookies (NID, 1P_JAR) maintained across requests within the same persistent browser context
  • Cookie age validation enforced — AEC younger than 4-hour TTL threshold
  • Geo rollout matrix documented — identified which countries enforce the bucket cookie requirement

Adstransparency Link Extraction Built

Google only injects the adstransparency.google.com/advertiser/AR... URL into the DOM when the user hovers over the ad's disclosure element. It's never present in the initial HTML.

  • CDP-level mouse hover triggers (isTrusted=true events) — synthetic JS events no longer work as of mid-2026
  • Poll window with 2-second hard deadline, decoupled from the hover trigger timing
  • Fallback path through Google Ads Transparency Center for cases where batchexecute doesn't return
  • Hardened across 6 iterations to handle Google's evolving lazy-load behaviour

Ad Extraction from SERP DOM Built

Structured extraction of every ad element from the live rendered page.

  • destination_url — final landing URL, unwrapped from all known Google redirect formats (aclk, ds_dest_url, dest_url, data-rw)
  • display_url — breadcrumb-style URL, coverage lifted to 95%+ across all ad DOM variants (top, bottom, map-pack)
  • advertiser_name and advertiser_country — populated via batchexecute response
  • slot (top/bottom) and position (1-indexed) — correctly differentiated
  • advertiser_link — full Ads Transparency URL when available

Demographic Profile System

Your second deliverable: persistent browser profiles with Google-inferred age and gender, built via YouTube viewing behaviour. No Google login required. This is the capability your standard 50M/mo crawler doesn't have, and that nobody at Prague Crawl would build.

Profile Build Pipeline Built

Full lifecycle from profile creation to demographic verification.

  • API-driven: create profile with target age bucket and gender, trigger build, check status, verify
  • Playwright browser watches 10+ curated YouTube videos selected from a demographic-specific video matrix
  • Verification pass against adssettings.google.com confirms Google's inferred demographics
  • Profile cookies stored in isolated persistent browser contexts — survive across SERP searches
  • 18-minute build timeout with progress tracking

Session Isolation Built

Each demographic profile operates in a fully isolated session with its own cookie jar, cache namespace, and proxy assignment.

  • SERP queries routed through specific profiles via session_pool_id
  • Cache keys namespaced per profile — different personas never share cached results
  • Collision-safe key encoding to prevent cross-profile cache contamination
  • Tenant-level isolation — your sessions are never shared with other platform traffic

Validation status: Profile creation and YouTube warmup pipeline confirmed working in our latest E2E test pass. Multi-profile differentiation (different demographics producing observably different ad sets) is built but pending end-to-end validation under production proxy conditions.

Ad Delivery Optimisation

You asked for searches done "in a way that maximises the ads that appear." We ran deep benchmarking to understand what drives Google's ad delivery decisions, and built optimisations based on the findings.

Research Completed Research

  • Proxy AS/ISP correlation — mapped ad delivery rates by Autonomous System number, identified low-performing IP blocks as blocklist candidates
  • Session stickiness — three-phase benchmark: serial queries per session, warmup count comparison (0/5/10 pre-queries), IP quality scoring
  • Viewport breakpoints — measured ad count at 1280, 1366, and 1920px to determine if narrower viewports suppress ads
  • DoubleClick timing — characterised the async ad loading delay to calibrate extraction timing
  • SOCS consent cookie impact — confirmed that rejecting cookies suppresses ad delivery; pre-accepting resolves this
  • gl= vs proxy geo alignment — verified that mismatches between the Google locale parameter and proxy country reduce ad relevance

Optimisations Implemented Built

  • Independent ad-wait deadline — dedicated 2-second polling budget for DoubleClick ad rendering, decoupled from organic result loading
  • Zero-ad retry gate — when a search returns zero ads, automatically re-fetches with a fresh session, gated by a commercial intent classifier to avoid wasting budget on informational queries
  • SOCS pre-injection — consent-accept cookie set at session creation, preventing the consent wall from ever appearing
  • Resource blocking — images, fonts, CSS, and analytics scripts blocked to reduce bandwidth. DoubleClick, googlesyndication, and ad verification scripts explicitly preserved
  • Session health FSM — sessions track their own health state (active, degraded, rotating) based on scraping outcomes, preventing reuse of burned sessions

UK Market Routing

Your client base is primarily UK brands. All Marcode tenant queries default to GB geo-targeting.

Geo-Targeted Proxy Routing Built

  • Country parameter drives residential proxy selection — UK queries route through UK DataImpulse residential IPs
  • Google gl= parameter aligned with proxy country — no geo mismatches
  • Tenant default country configurable — Marcode set to GB, so queries without explicit country still route correctly
  • Country codes validated against ISO 3166-1 alpha-2 at the API boundary

UK ad fill rate: Our benchmarks consistently show UK ad delivery at ~30% vs US ~80% for the same queries. Our analysis indicates this is Google UK market behaviour (fewer advertisers per keyword category), not a proxy quality issue. We're evaluating ISP proxies (NetNut, Bright Data) to rule out residential IP reputation as a contributing factor. We'll share the benchmark data with you — if you're seeing similar ratios on your own infrastructure, that would confirm the market behaviour hypothesis.

Bandwidth and Cost Optimisation

At 1M requests/month, proxy bandwidth is the dominant cost. We validated the cost structure and built the primary optimisation lever.

T4 Browser is the Floor Validated

We tested whether Google SERP ads could be captured at the HTTP level (no browser). They cannot. Ad content is delivered via async DoubleClick JavaScript — the DOM elements are not present in server-rendered HTML. A full Playwright browser session is required for every ad-bearing search.

Resource Blocking Built

With resource blocking active, page weight drops from 1.5-2 MB to 400-600 KB per request. Ad-serving scripts are explicitly preserved.

  • Images, fonts, stylesheets, and analytics/tracking scripts blocked
  • DoubleClick, googlesyndication, googleadservices, and ad verification domains allowlisted
  • Ad capture rate confirmed unaffected by resource blocking

Proxy Economics Negotiated

  • DataImpulse 1TB bulk plan secured at $0.80/GB (20% below standard PAYG)
  • At 400-600 KB/req with blocking: $320-480 proxy cost per 1M requests
  • At 5TB+ volume: enterprise tier negotiable to ~$0.50/GB via direct arrangement

S3 Batch Delivery

Results delivered to your S3 bucket in the format your pipeline expects.

Delivery Pipeline Built

  • JSONL format — one JSON object per line, each containing query, ad_results with full advertiser identity fields
  • SSE-S3 encryption (AES256) enforced on all uploads
  • Retry policy: 3 attempts with exponential backoff (30s / 120s / 600s)
  • API-triggerable delivery — no manual intervention required
  • Audit trail on every delivery (timestamp, result count, delivery status)
  • Ready to test against your actual S3 bucket once you share credentials

Security Hardening

Every pull request goes through automated security review. 129 findings caught and resolved before merge.

Key Areas Hardened

  • Tenant isolation — your sessions, cache, and data are fully namespaced and never shared with other platform traffic
  • IDOR protection — profile and resource lookups cannot be used to probe for other tenants' data
  • SSRF validation on all proxy URL inputs
  • Path traversal protection on S3 delivery keys
  • Credential redaction in all error logs — no DSN strings, no API keys, no tenant UUIDs in error responses
  • Concurrent request guards — duplicate job submission, profile rebuilds, and verify tasks are deduplicated at the lock level

Next Steps

1

End-to-End Validation

Final acceptance testing under production proxy conditions. One remaining edge case to resolve (engine fallback behaviour on Google timeout), then full 13-test validation pass.

2

Live Demo

A demo environment is being developed for you to run searches and see ad results with advertiser details rendered in real time.

3

Technical Deep-Dive Call

Walk through the batch execute implementation, cookie chain, and demographic profile system in detail. Happy to do this over Telegram or a call — whichever you prefer.

4

Pilot Launch

Connect your S3 bucket, confirm output schema, run initial batch at low volume to validate end-to-end, then scale to target throughput.