Proxies for Affiliate and Coupon Verification

An affiliate program pays for an outcome it never directly observed. The publisher controls the page, the redirect, the creative, and the coupon copy. Your platform records a click event and a conversion event, then infers that everything between them was legitimate. Every serious form of affiliate abuse lives inside that inference gap.

The usual audit is a compliance manager with a spreadsheet of partner URLs: click ten, confirm they land on the right product page, mark the rows green. That test fails twice over at scale. It samples ten links out of several thousand, and it runs from one IP, one browser profile, one country, in a browser that has visited your own site hundreds of times.

Verification is really five separate measurements, and they need different tooling:

Only the first is text processing. The other four need a browser and, critically, an IP that puts you where the customer is.

This is the part most compliance write-ups skip. Checking from one IP does not produce noisy false alarms. It produces the opposite, quiet false negatives, where the check passes and the violation keeps running. Four separate mechanisms cause it.

Geo routing inside the link itself. Affiliate redirectors routinely branch on IP country so a click from France lands on the French storefront. A partner who has pointed the non-domestic branch at a different merchant, or at a withdrawn offer, looks perfectly compliant from your head office because you only ever exercise the domestic branch. Geo-targeting is a first-class feature of proxy infrastructure for exactly this reason, and if the concept is new to your team, our explainer on what geo-targeting means in proxies covers the mechanics.

Edge caching. Publisher pages and creative assets sit behind CDNs with per-point-of-presence caches. An expired banner or a pulled offer can persist in the Sydney or Sao Paulo cache for hours after it left the origin. The version you fetch from a London office is fresh. The version a customer gets is not.

Your own cookie state. This is why cookie-stuffing audits fail. Many trackers write a click cookie only when one is absent, and many publisher scripts fire their aggressive path only for first-time visitors. Your browser, and your office network more broadly, is never a first-time visitor to your own brand, so the behaviour you are hunting is specifically the behaviour that does not fire for you.

IP reputation and repeat-visit fingerprinting. A publisher running a cloaking layer can serve the compliant version of a page to any IP that has hit it thirty times this month, which is exactly what a compliance team's office range looks like. Cloaking by IP and ASN is why datacenter ranges belonging to known monitoring vendors get clean pages while consumer IPs get the real one.

Fix all four the same way: rotate through consumer-grade IPs in the markets your customers are in, start each check from a clean browser profile, and avoid letting two checks of the same link share an exit IP. The same reasoning drives ad verification for brands, which handles the display and programmatic side of the same trust problem.

Start with the cheapest check, because it catches the crudest problems. For every active partner link, record the full chain, not just the endpoint.

Capture per hop: status code, host, full URL, whether the hop was an HTTP redirect or a JavaScript or meta-refresh navigation, and elapsed time. Then evaluate the chain against the approved destination.

Signals worth an automatic flag:

• Final host mismatch. The chain ends on a domain that is not yours and not an approved regional storefront.
• Cross-network handoff. Your tracking parameters are present at hop two, and a different network's parameters appear at hop four. The partner is arbitraging your traffic into someone else's program.
• Unapproved intermediates. New tracking hosts appear that were not in the chain last week, especially freshly registered domains.
• Parked or dead hops. A 404, a domain-for-sale interstitial, or a redirect to a registrar parking page. Common with older partners who let a microsite lapse.
• Sub-ID injection. The affiliate ID or sub-ID at the final hop does not match the partner the link was issued to.
• Silent hops. The HTTP chain resolves cleanly, then a JavaScript redirect or meta refresh moves the browser again after load. A curl -L style check never sees this. A rendered check does.

That last point matters more each year. A growing share of redirect logic runs client side, so a text-only chain walker reports a clean two-hop path while the browser actually takes five.

To be unambiguous about the framing: this section describes how to detect these behaviours on a partner's property. It does not describe how to perform them, and nothing here should be used to manufacture attribution.

Cookie stuffing is the placement of a program's click cookie on a visitor's browser without that visitor deliberately clicking an affiliate link. Forced clicking is programmatic triggering of the click endpoint itself, typically through a hidden iframe, a one-pixel image whose source is the click URL, an auto-submitting form, or a background window. Both produce the same commercial effect: the publisher wins last-click credit on purchases they had no part in influencing.

The zero-interaction load test

The core detection method works entirely from the outside:

1. Open a clean browser profile with no prior cookies for your domain or your tracking domain.
2. Route the session through a residential IP in a market where the publisher gets traffic.
3. Load the publisher's page.
4. Interact with nothing. No clicks, no elements you trigger yourself.
5. Once load settles, read document.cookie for cookies scoped to your tracking domain, and enumerate every iframe, img, and script whose source matches your click-tracking hosts.

If your click cookie exists after a load with zero interaction, you have a stuffing signal. If a one-pixel image is requesting your /click endpoint on page load, you have a forced-click signal. Neither is proof alone, since a legitimate page can preload a tracking script without firing a click, but both justify a manual review and a partner conversation.

What to record as evidence

Partners dispute these findings, so capture more than a screenshot:

• The exact cookie names, values, domains, and expiry timestamps present after load.
• The full request URLs that hit your click endpoint, with their referrer.
• The HTML snippet containing the offending element, with surrounding context.
• A full-page screenshot with a visible timestamp.
• The exit IP country and the time in that market's timezone.
• A control run: the same page from a different country and a different clean profile.

The control run turns an anecdote into a finding. If the cookie fires for a fresh Brazilian IP and not for a fresh German IP, you have documented geo-fenced behaviour, which is much harder for a partner to explain away.

Volume-side corroboration

Detection has a statistical half that costs nothing. Compare each partner's click volume against their referring page volume and the dwell time between click and conversion. A publisher whose median click-to-conversion gap is under two seconds is not sending humans who browsed. Use those anomalies to decide who gets the expensive browser-based audit.

Nearly every program forbids affiliates from bidding on the brand name, brand plus "coupon", brand plus "discount code", and common misspellings. Enforcement fails for a mechanical reason: paid search is targeted, and violators target away from you.

An affiliate running brand-term ads can exclude your office city, exclude your IP range, run the campaign only between 22:00 and 06:00 local time, or restrict it to mobile devices. Any of those makes your desktop check at 10am from headquarters come back clean while the ads run every night in three countries.

A workable check has four dimensions:

For each captured ad, record the headline, the display URL, and the final URL after resolving the click destination, then check that final URL for your affiliate parameter. Two violations show up here. The first is a partner sending paid traffic to their own landing page and then on to you, which at least adds a page. The second is direct linking, where the ad points straight at your site with an affiliate ID appended and the partner contributes nothing except an intercepted branded search.

Collecting search results at this cadence is its own engineering problem, and our guide on scraping Google search results covers the parsing detail. The compliance-specific requirement is that the exit IP sits in the market you are auditing, with search locale parameters set to match, or you read a SERP no customer in that country ever sees.

Treat a coupon code as two objects that happen to share a string. It is a discount, and it is an attribution key. Verifying one without the other misses most of the real problems.

The test sequence for a single code:

1. Fresh browser profile, exit IP in the target market.
2. Add a known SKU to the cart, ideally one with a stable price you can assert against.
3. Apply the code.
4. Read the discount line. Is the code accepted, and is the value the one you authorised?
5. Read the attribution state in the same session. Which affiliate cookie or tracking parameter is now attached to this cart?
6. Abandon the cart. Never complete a test purchase against production payment.

Step five is the one programs skip, and here is the failure it catches. A customer arrives through partner A's genuine content link, leaves to search for a code, and lands on aggregator B. If B's code page sets a click cookie on reveal, B takes last-click credit for a sale A generated. The code applied correctly, the discount was right, and the attribution went to the wrong partner. Only a session-level read catches it.

Run this against your own storefront. You own the site, the codes, and the program, so testing them is ordinary quality assurance carried out from a customer's vantage point.

Coupon aggregators sit at the very bottom of the funnel and compete for last-click credit. Some are excellent partners. Some list codes that expired months ago, and a few list codes that never existed.

Fabricated and expired codes are not harmless clutter, and the mechanic is deliberate. A visitor searching "yourbrand coupon" lands on an aggregator and opens the code list. Each "reveal code" click opens your site in a new tab, setting the aggregator's cookie. The visitor tries four dead codes, then the fifth works, and it is the sitewide code already printed in your own site header. The aggregator intercepted a customer who was already checking out, and it books the commission.

The metric that makes this manageable is a per-aggregator code failure rate: count the codes listed for your brand, test each one in a live cart, and compute the share that applies at the advertised value. Track it monthly.

A well-maintained aggregator generally lands well above a 70 percent apply rate. A site sitting at 10 or 15 percent is not badly maintained, it is running a volume strategy on dead codes, and that number is a defensible basis for a partner conversation. Pair it with two more measures: how many of your exclusive codes appear on sites never issued them, and how many listed codes are strings your promotions team never generated at all.

Collecting this means fetching aggregator pages from the geography whose code list you care about, since aggregators localise their listings. This is close cousin work to brand protection monitoring, and most brands eventually run both off one collection layer.

The SparkProxy Scraping API handles rendering, geo-targeting, and IP rotation, so your compliance code stays focused on the assertions. Base endpoint: https://scrape.sparkproxy.io/api/v1, authenticated with an X-API-Key header. Start with the simplest check, resolving a partner link from a specific country:

curl -H "X-API-Key: $SPARKPROXY_API_KEY" \
  --get "https://scrape.sparkproxy.io/api/v1" \
  --data-urlencode "url=https://go.sparkproxy.io/aff/ab12cd" \
  --data-urlencode "render_js=true" \
  --data-urlencode "country_code=DE" \
  --data-urlencode "json_response=true"

The JSON envelope returns status_code, duration_ms, and a meta block with the resolved page title, which is enough to assert that a German click lands on the German storefront and not somewhere unexpected.

Next, pull the landing page identity as structured fields rather than raw HTML, so the comparison becomes a string equality test:

import requests, json

API = "https://scrape.sparkproxy.io/api/v1"
API_KEY = "sk-xxxxxxxxxxxxxxxx"

def resolve_landing(affiliate_url, country):
    params = {
        "url": affiliate_url,
        "country_code": country,      # exit in the customer's market
        "premium_proxy": True,        # residential IP, reads like a consumer
        "render_js": True,            # catches JS and meta-refresh hops
        "format": "json",
        "extract_rules": json.dumps({
            "canonical":   "link[rel=canonical]",
            "h1":          "h1",
            "offer_id":    "[data-offer-id]",
            "disclosure":  ".affiliate-disclosure",
        }),
        "tag": "affiliate/landing",
    }
    r = requests.get(API, headers={"X-API-Key": API_KEY}, params=params)
    return r.json()

de = resolve_landing("https://go.sparkproxy.io/aff/ab12cd", "DE")

Run the same link across every market in one pass. This is the check that surfaces geo-routed misdirection:

MARKETS = ["US", "GB", "DE", "FR", "ES", "IT", "BR", "AU", "CA", "JP"]

def audit_link_across_markets(affiliate_url, approved_hosts):
    findings = []
    for cc in MARKETS:
        data = resolve_landing(affiliate_url, cc)
        canonical = (data.get("extracted") or {}).get("canonical", "")
        host = canonical.split("/")[2] if "//" in canonical else ""
        if host and host not in approved_hosts:
            findings.append({"country": cc, "resolved_host": host, "url": canonical})
    return findings

print(audit_link_across_markets(
    "https://go.sparkproxy.io/aff/ab12cd",
    approved_hosts={"sparkproxy.io", "de.sparkproxy.io", "shop.sparkproxy.io"},
))

Now the zero-interaction cookie test. A js_scenario with an evaluate instruction reads cookie and DOM state after load without any click:

scenario = {
    "instructions": [
        {"wait_for": "body"},
        {"wait": 4},
        {"evaluate": """
            JSON.stringify({
              cookies: document.cookie,
              iframes: Array.from(document.querySelectorAll('iframe'))
                            .map(f => f.src).filter(Boolean),
              pixels:  Array.from(document.querySelectorAll('img'))
                            .filter(i => i.width <= 2 && i.height <= 2)
                            .map(i => i.src),
              scripts: Array.from(document.querySelectorAll('script[src]'))
                            .map(s => s.src)
            })
        """}
    ]
}

r = requests.post(
    API,
    headers={"X-API-Key": API_KEY, "Content-Type": "application/json"},
    json={
        "url": "https://partner-site.sparkproxy.io/deals/summer",
        "country_code": "BR",
        "premium_proxy": True,
        "render_js": True,
        "stealth": True,
        "js_scenario": scenario,
        "json_response": True,
        "tag": "affiliate/zero-interaction",
    },
    timeout=120,
)

The assertion is then a few lines. Anything touching your click host without a click is a finding:

CLICK_HOSTS  = ("go.sparkproxy.io", "track.sparkproxy.io")
CLICK_COOKIE = "sp_aff_click"

def flag_stuffing(observed, partner_id, country):
    hits = []
    if CLICK_COOKIE in observed.get("cookies", ""):
        hits.append("click cookie set with zero interaction")
    for bucket in ("iframes", "pixels", "scripts"):
        for src in observed.get(bucket, []):
            if any(h in src for h in CLICK_HOSTS):
                hits.append(f"{bucket[:-1]} requesting click host: {src}")
    return {"partner": partner_id, "country": country, "signals": hits} if hits else None

Capture visual evidence from the same market, straight to a dated file:

curl -H "X-API-Key: $SPARKPROXY_API_KEY" \
  --get "https://scrape.sparkproxy.io/api/v1" \
  --data-urlencode "url=https://partner-site.sparkproxy.io/deals/summer" \
  --data-urlencode "country_code=BR" \
  --data-urlencode "premium_proxy=true" \
  --data-urlencode "render_js=true" \
  --data-urlencode "format=screenshot" \
  --output evidence_partner412_br_2026-08-18.png

For the coupon test, drive a real cart and read both the discount and the attribution in one session:

coupon_scenario = {
    "instructions": [
        {"click": "#add-to-cart"},
        {"wait_for": "#cart-summary"},
        {"click": "#promo-toggle"},
        {"fill": {"selector": "#promo-code", "value": "SUMMER20"}},
        {"click": "#promo-apply"},
        {"wait": 3},
        {"evaluate": """
            JSON.stringify({
              discount:    (document.querySelector('#discount-line') || {}).innerText || '',
              total:       (document.querySelector('#order-total')   || {}).innerText || '',
              error:       (document.querySelector('.promo-error')   || {}).innerText || '',
              attribution: document.cookie
            })
        """}
    ]
}

r = requests.post(
    API,
    headers={"X-API-Key": API_KEY, "Content-Type": "application/json"},
    json={
        "url": "https://www.sparkproxy.io/demo-shop/product/sku-44821",
        "country_code": "GB",
        "premium_proxy": True,
        "render_js": True,
        "js_scenario": coupon_scenario,
        "json_response": True,
        "tag": "coupon/apply-test",
    },
    timeout=180,
)

Harvest the codes an aggregator lists for your brand before you test them:

params = {
    "url": "https://coupons.sparkproxy.io/stores/sparkproxy",
    "country_code": "US",
    "render_js": True,
    "format": "json",
    "extract_rules": json.dumps({
        "codes":    ".offer-card .code",
        "titles":   ".offer-card .offer-title",
        "expiry":   ".offer-card .expires",
        "verified": ".offer-card .verified-badge",
    }),
    "tag": "coupon/aggregator-sweep",
}
listing = requests.get(API, headers={"X-API-Key": API_KEY}, params=params).json()

Brand-term SERP capture per market, for the trademark bidding check:

def brand_serp(query, cc, device="desktop"):
    params = {
        "url": f"https://www.google.com/search?q={query}&gl={cc.lower()}&num=20",
        "country_code": cc,
        "premium_proxy": True,
        "render_js": True,
        "stealth": True,
        "device": device,
        "format": "json",
        "extract_rules": json.dumps({
            "ad_titles":  "[data-text-ad] [role=heading]",
            "ad_display": "[data-text-ad] cite",
            "ad_links":   "[data-text-ad] a@href",
        }),
        "tag": f"tm-bidding/{cc}",
    }
    return requests.get(API, headers={"X-API-Key": API_KEY}, params=params).json()

for cc in ["US", "GB", "DE", "AU"]:
    for q in ["sparkproxy+coupon", "sparkproxy+discount+code", "sparkpoxy"]:
        print(cc, q, brand_serp(q, cc))

Large sweeps should not be synchronous. Fire them with a webhook and let results arrive as they finish:

requests.post(
    API,
    headers={"X-API-Key": API_KEY, "Content-Type": "application/json"},
    json={
        "url": "https://coupons.sparkproxy.io/stores/sparkproxy",
        "country_code": "FR",
        "render_js": True,
        "callback_url": "https://hooks.sparkproxy.io/affiliate-audit",
        "tag": "coupon/fr-nightly",
    },
)

The API returns 202 immediately in this mode, which matters when a nightly audit covers a few thousand partner URLs across ten markets.

Not every check deserves the same frequency. Rendering costs credits, so spend them where the money is.

Two rules make the evidence usable. Timestamp everything in the target market's local timezone, since "the ad was not running" is the first defence you will hear and a UTC timestamp invites argument. And always store a control run from a clean profile in a second country, so a finding reads as "this fired in Brazil and not in Germany" rather than "we saw something once".

Both types have a place. Choose per check rather than picking one for the whole program.

The pattern is consistent: datacenter IPs where you read public content at volume, residential IPs wherever the target's behaviour depends on believing you are a consumer. If your team is choosing between pools, our overview of residential proxies, their types and use cases covers the trade-offs.

One practical note on geography: country-level targeting handles most affiliate checks, but paid search violations are often city-targeted, so sample several metros in your two largest markets rather than a single national exit.

This work is defensible when it stays inside a few clear lines.

You are auditing your own program. The links carry your tracking parameters, the codes are your codes, the ads reference your trademark, and your partner agreement almost certainly grants a right to monitor compliance. That is a different posture from collecting a third party's private data.

Stay on public pages. Test carts on your own storefront, abandon every one of them, and never complete a purchase against production payment systems.

Do not click partners' or competitors' paid ads to test them. Every click costs the advertiser money, and repeated automated clicks look exactly like click fraud. Capture the ad and resolve its destination from the recorded href instead.

Rate-limit yourself. Aggregators and publisher sites are small operations relative to your monitoring capacity. Pace requests, cache aggressively, and poll no faster than the data changes. Our guide to ethical scraping and rate limiting sets out reasonable defaults.

Detect, do not replicate. Nothing here requires building a cookie stuffer or a forced-click page to prove the detector works. Test detection against your own instrumented pages, never against live partners' customers.

Give partners a right of reply. Store the evidence, present it, and allow an explanation before termination. Many findings turn out to be a stale third-party widget or an ad network's automated expansion rather than deliberate fraud, and a program that terminates on one unverified screenshot will lose good publishers.