Delivery Modes Reference
Every delivery mode a passed visitor can be sent through, what actually renders in the browser and on the wire, and the per-platform risk notes that matter when picking one for a specific campaign.
What a delivery mode controls#
moneyAction is the stream setting that picks a visitor's delivery mode — see the Stream Settings Reference's Money Page Delivery section for the field itself. This page goes one level deeper: for each of the 8 modes, exactly what a browser (or an automated scanner fetching the same URL) can observe structurally — address bar behavior, what's visible in page source and DevTools, and the redirect chain shape — since that structural behavior is what an ad platform's own compliance review ultimately reacts to, independent of whether Cloaking X's own bot detection correctly routed that specific request.
The 8 modes, side by side#
Each row: the mode's structural behavior (what renders, what's visible in source/DevTools, and the redirect chain if any), followed by the per-platform risk notes that follow from that behavior.
proxy (default)What renders / structural behavior
Address bar stays on your domain. A single 200 response — the server fetches the destination's HTML and serves it directly, no redirect chain at all. But the destination's <base href> and every asset (images/scripts/stylesheets) still resolve directly against the real money origin, in plaintext, for anyone who reaches it.
Per-platform risk notes
No redirect means this mode alone never trips a redirect-based cloaking check. The trade-off is on the source side: the money origin's real hostname is visible in plaintext to anyone who views page source or opens the Network panel — for high-risk verticals (betting, adult, pharma) that plaintext link between your ad-facing domain and the real brand is exactly the evidence a compliance reviewer looks for. Can also break on destinations built as a JS-framework SPA (Next.js/Nuxt/Angular/React) that try to take over the address bar themselves.
redirect302What renders / structural behavior
Address bar changes to the destination via a temporary (never-cached) redirect, using history replace so the Back button can't loop.
Per-platform risk notes
A same-domain 302 — staying on your own tracking domain before landing — reads as ordinary navigation and isn't itself a red flag. A cross-domain, top-level 302 straight from your ad-facing tracking domain to an unrelated money-page domain is a different story: it's one of the most well-documented cloaking signatures in the industry, and platforms' automated compliance scanners are specifically built to catch exactly that redirect shape. Never a 301 — this product doesn't offer a permanent redirect as an option at all, since a visitor's browser would cache it and bypass the filter forever after one visit.
meta_refreshWhat renders / structural behavior
Reveals the current page first, then inserts a <meta http-equiv="refresh"> tag that navigates after a short delay. Not a guaranteed-synchronous navigation — some browsers/extensions can delay or strip a meta-refresh outright.
Per-platform risk notes
Because the page briefly renders before redirecting, a scanner that only captures the FIRST response (rather than waiting out the refresh) sees your fallback content, not the money page — generally a favorable shape for review. The same non-determinism that helps there (some crawlers wait, some don't) makes it a less predictable choice than a clean redirect302 for high-volume campaigns where consistency matters more.
iframeWhat renders / structural behavior
Renders the destination inside a full-viewport iframe rather than navigating away — address bar never changes. The outer page's source contains a same-origin relay src, not the money page URL itself; the framed document is a same-origin rewrite (PHP/WordPress) or a hop-2 302 onto the money origin (Hosted Ad Link, JS snippet).
Per-platform risk notes
The clean address bar is exactly the property this mode is chosen for — but the injected iframe is visible in DevTools' Elements/Network panels to anyone who inspects the page, and a scanner that walks the DOM (rather than only reading the top-level document) sees the framed content and its real network hop. Fails silently if the destination sets a frame-busting header (X-Frame-Options / CSP frame-ancestors).
iframe_cross_originWhat renders / structural behavior
Same same-origin relay wrapper as iframe, but hop-2 is a real 302 so the framed document IS the money origin — required for domain-locked video players (VTurb/ConverteAI) that refuse a same-origin rewrite.
Per-platform risk notes
Same DevTools-visible iframe exposure as iframe above, plus the money origin's real hostname is now reachable one hop deeper in the Network panel — still never the address bar. Use this only when a domain-locked embed forces your hand; plain iframe has one fewer real hop to the money origin.
js_redirectWhat renders / structural behavior
A straightforward client-side JS navigation (window.location) to the destination — address bar changes as soon as the script runs.
Per-platform risk notes
Requires JavaScript execution. A scanner doing only a raw HTTP GET (no JS engine) never reaches the destination at all and sees just your landing page's initial HTML — a favorable shape for review. A scanner running a full browser engine (most major platforms' review infrastructure does) follows it exactly like redirect302 for cloaking-detection purposes.
click_revealWhat renders / structural behavior
On the JS snippet, shows a Continue button and gates delivery on a genuine click — the destination isn't referenced anywhere in the response until then. On PHP, WordPress, and Hosted Ad Link this aliases to iframe (no page exists to wait for a click on the first response).
Per-platform risk notes
The strongest shape against any fully-automated scanner that doesn't simulate a real user click — the destination literally isn't present until a click event fires. Adds one extra interaction step for real visitors, which can cost a small amount of conversion friction in exchange.
mirrorWhat renders / structural behavior
Fetches the destination's HTML server-side and rewrites every asset reference to route through your own tracking domain — the destination's URL never appears anywhere in the page source, not even as a <base href>. Works best on static landing pages; a detected JS-heavy app renders in place via a best-effort compatibility shim.
Per-platform risk notes
The one mode built specifically to keep the money origin's hostname out of plaintext entirely — the choice for high-risk verticals where proxy's exposed <base href>/asset URLs would otherwise be the concrete evidence a reviewer finds. The trade-off is on the visitor side, not the reviewer side: complex JS apps, absolute-URL forms/anchors the shim doesn't rewrite, and runtime fetch() calls the destination makes on its own can misbehave — worth QA-testing an unfamiliar destination in this mode before sending real budget through it. If the destination can't be fetched at all, the visitor sees your Safe Page — never a redirect to a broken destination.
Choosing a mode
- Default / most streams:
proxyorredirect302— simplest to reason about, works with every tracking-template setup. - High-risk vertical (betting/adult/pharma): prefer
mirroroverproxy— it keeps the money origin's hostname out of plaintext entirely, where proxy exposes it via<base href>and asset URLs. - Domain-locked video embed (VTurb/ConverteAI):
iframe_cross_origin— a same-origin rewrite doesn't satisfy the player's own domain lock. - Maximum resistance to fully-automated scanners:
click_reveal(JS snippet only) — the destination isn't present in the response at all until a real click fires.