Back in the day, when a 300% ROI in gambling was the norm, LeadReactor ran without a hitch, and Google calmly waved grey-hat stuff straight through — we already covered this topic once. The world’s turned upside down since then, but the technical fundamentals haven’t budged an inch. And burying them is a mistake: there’s a swarm of newcomers around, and the old-timers have forgotten half of it anyway. So let’s get back to the fundamentals that turn the tracker’s black box into a tool you actually understand. Let’s start with its core entities.
Flow and Way
Flow. Competitors usually call this a “Campaign.” It’s the tracker’s most global entity there is: create a flow and you get a link — the one you drop into your ad campaign, whether that’s your FB or Google ad account, a push network, or anywhere else you’re expecting traffic from. From there, a flow can be split into ways.
Way. A smaller entity — think of it as the minion to Flow’s big boss. A click from the source lands in the flow, and that’s where the tracker’s algorithms decide which way to send it down.
For example, bot traffic filtered out by the cloak gets dumped onto a separate way called “Trafficback,” inside the “Traffic Filtering” section. Real traffic, meanwhile, can be spread across different ways to different landers, products — pretty much any link at all. And there’s no cap on how many ways a flow can have, so there’s plenty of room for creativity.
Either way, both the Big Boss and its Minion are going to get the user to their casino or dick-cream offer through some specific method. Which one exactly, what the options even are, and when to pick which — that’s what we’re breaking down next.
The Basics: 301, 302, Meta-Refresh, and JS Redirects
Let’s start with the most basic — the classics, you could say.
Redirect by link (302). The poster child of “slap it together and ship it.” Hands over the destination link with zero caching. Only good for sources where moderation either doesn’t exist or is there just for show: push, pop, teaser traffic, and other small fry. You can run this past FB with a cloak; Google won’t take it even with one.
Redirect by link and stick it (301). A slightly smarter option: after the first visit, the link gets glued to the user via caching. Doesn’t matter if you’ve got ten landers running in a split — if someone clicks the ad a second time, they land right back where they were the first time. Even if you’ve already pulled that way from the tracker, it’ll keep working for them. Moderation-wise, it passes exactly the same as 302. Useful for splits, or when you want to mimic a white site in Google’s eyes by sticking the link to the white domain. That last part, though, is a myth plenty of people still swear by.
One nuance applies to both redirects: don’t mix 301 and 302 with other display methods on the same site — some networks read that kind of shuffling as a hacked site and hand out bans for it generously.
Redirect through a separate page (meta-refresh). Now this is a genuinely solid, working redirect for a range of tasks. Facebook will often let an ad campaign through on a link like this with no cloak at all. The method sends both users and moderators to an unremarkable intermediate page that returns a “200” — as far as the system’s concerned, that means “there’s content here,” and it looks perfectly legit. A couple of seconds later, the person flies off to the real destination, launched by a script sitting inside that very page. There are no direct 301/302 headers involved, which also helps you dodge Google’s “Malware” label.
Redirect via JS. The same kind of redirect, just instant and done through JavaScript, with no headers involved at all. Helps you dodge a “Hacked Site” ban, but there’s a catch: especially zealous ad blockers can kill it outright, and then the user doesn’t go anywhere.
iFrame — the Controversial Method for the Hardcore
The next method deserves its own, in-depth conversation: iFrame.
It’s a deeply controversial thing. I figured it was basically extinct — until the HideClick crowd moved over to us, and it turned out a whole cult of iframe devotees was hiding among them.
It works on a principle similar to a webview: there’s a shell site, and inside it a frame unfolds, visible to people — and that’s where all the arbitrage chaos actually happens.
The main upside — nobody needs to be redirected anywhere at all. And moderation stays clean too: the shell site serves up white content, and whatever’s happening inside the iframe matters a lot less.
The second big upside — you can drag a site you don’t even own into the frame: the same casino, or a marketplace. Quick reminder just in case: casino ads aren’t legal everywhere, so check your jurisdiction — and marketplaces honestly scare me with how fast they can swallow all your money at once!
But there’s a fly in the ointment — several, actually. On most sites, iframe runs like absolute dogshit. So either build your own site specifically for it, or check whether the partner site meets every single one of these requirements at once:
- All internal links open in a new window. If a link on the partner’s page points to another page inside the same frame — especially if it’s carrying
target="_top"— the user can get kicked straight out of your wrapper onto the bare donor site, and the whole disguise loses its point. - The right headers are set, with nothing blocking display in an iframe:
X-Frame-Options,CSP frame-ancestors. These are how a site forbids itself from being shown inside someone else’s frame. If the donor sends them, the browser will refuse to draw the page inside your iFrame — the user sees blank space instead of content. - No JS code that “busts” the page out of the iFrame. A script like that (frame-busting), the moment it detects the site isn’t open as a standalone page, forcibly takes over the entire browser window — and your wrapper vanishes without a trace.
- The layout doesn’t depend on
window.top,parent, or anything outside the frame. For security reasons, browsers block access to a parent window from a different domain. If the site’s scripts count on that access, they throw errors, and part of the functionality quietly breaks. - Every resource loads with no errors: CSS, JS, fonts, images. Inside a frame on someone else’s domain, security policies can block some requests differently than they would on a direct visit — the result is a half-loaded, broken page instead of a clean site.
- Forms, popups, and fixed/sticky elements all work properly inside the iFrame. Fixed and “sticky” blocks are anchored to the frame’s own boundaries, not the full browser page: a header meant to span the whole screen can shrink down to just a slice of it, and a modal window can get clipped at the iFrame’s edge.
- No critical dependency on third-party cookies or sessions. To the browser, your frame is a foreign domain, and its cookies are exactly the third-party kind more and more browsers block by default. If the donor relies on cookies for login or a shopping cart, that state might simply not persist inside the iFrame.
- If login exists, it’s been tested specifically inside the iFrame — not just on a direct visit to the site. Because of that same cookie situation, a login that works perfectly on a direct visit can simply fail inside the frame.
- Links and redirects don’t break the flow inside the iFrame. The whole chain of transitions across the donor site needs to run to completion while staying inside the frame, instead of jumping up to the top-level window partway through.
- If the iFrame has a
sandboxattribute set, the site doesn’t run into its restrictions. By default,sandboxstrips out part of a page’s capabilities: scripts, forms, popups, access to its own domain. Whatever you didn’t explicitly allow just won’t work on the site. - No double scrollbars or height/width glitches. If the iFrame’s dimensions don’t match the actual content inside it, you get a scrollbar inside a scrollbar and blocks clipped at the edges — it looks broken and undermines trust in the wrapper.
- Tested separately in Safari and on iPhone. Safari has a stricter policy on third-party cookies and its own logic for auto-fitting frame height — a site that behaves fine in desktop Chrome can fall apart on an iPhone.
- Any interaction with the parent page goes only through
postMessage, including resizing, redirects, and passing events. Scripts from different domains have no direct access to each other, andpostMessageis the only legitimate channel for the frame to ask the wrapper to send the user onward or report a conversion. - System-level access — camera, files, geolocation, payments — has been tested if the site uses any of it. A browser can block access to these APIs, or demand separate permission specifically for iFrame content, so a feature that works fine on a direct visit might simply never get requested inside the frame.
- The browser console is clean: no CSP, CORS, or cookie errors. This is the final trial by fire: if anything on the list above didn’t get finished, errors will show up in the console even when the page looks fine on the surface.
So maybe just say fuck this iFrame thing? If you’re not some old-school purist forged in arbitrage’s trenches, that’s exactly what you should do. There’s no shortage of alternatives!
Stealing Someone Else’s Content: Raw vs. curl
Next up — a family of methods that help you neatly “steal” someone else’s content. We’re talking, of course, about not installing a lander on your own side at all, and instead showing a ready-made lander straight from the affiliate network.
Show content with no processing. For cases where you simply can’t put the target site on your own server. The black pulls content straight from the target site and shows it to the user the cloak let through.
And that lack of processing is exactly the catch. Local paths in forms or images? Instead of a working site, your potential customer gets an empty, broken piece of shit. So the method only really works for the simplest blacks that already use absolute paths, or for showing whites. Pages loaded with extras — captchas, notification prompts, registration forms, scripts, and other nasty stuff — it can’t handle any of that. At all.
Show content by link (curl). Same idea as its little brother above, but this one’s armed to the teeth — with actual processing. The tracker pulls the page and injects a <base> tag into it on the fly, which turns all the relative paths into absolute ones and makes most of the problems above disappear on their own.
The nice part about both methods: tracker macros get substituted not just into the link, but straight into the stolen site’s body too — meaning you can seamlessly stitch click data right into the page. One thing to keep in mind: any click on an internal link sends the user off to the original site.
For simple pages you can’t plug into your own server, this is the best method there is. Some people whine that the <base> tag makes moderation harder. That’s nonsense from the broke and clumsy — the kind who can’t cloak and can’t be bothered with what actually matters: creatives.
Your Own Hosting, Your Own Files: Local File and Storage
Onward with our extravaganza — up next, a pair of twin brothers, both of which need the black and the white to actually belong to you.
Open a local file. The black’s and white’s files sit on shared hosting right next to the tracker’s own processing file. Every click first passes through the tracker, which decides what to pull: white.html or black.html. The charm here is simple: we skip redirects as a concept entirely — we just show different versions of the site to real people versus bots and moderators. One catch: the built-in TDS won’t sign off on this method for security reasons — you’ll need either a self-hosted copy of the tracker, or your own storage. Which brings us to that.
Show a site from storage. The exact same principle, but this is the ideal setup for a tracker: it’s wired directly into that storage, and that’s where all the files live.
Around here, this thing goes by a beautiful name: STORAGE (couldn’t make the letters any bigger, but picture it skywritten right across the clouds). Inside AlterCPA Red and One, the “Sites” block has both the instructions and every tool you need to hook up hosting — and what you end up with is that very STORAGE, where you dump your sites. Inside AlterCPA Lite, it’s built in and active by default. STORAGE. Mmm. Doesn’t that just sound nice.
Under the hood, this is usually a separate, isolated server: sites live there instead of in the tracker’s database, and each one gets a short, encrypted address that gives away neither its number nor how many sites you’ve even got. That physical separation between your ads and the tracker’s own guts also protects you from getting banned “by association” with noisy neighbors on cloud plans. One site can be hooked up to as many flows and ways as you like, and stats — CR, EPC, approval rate — are counted separately for each site. You upload either a ready-made ZIP archive, or just hand over a link, and the tracker mirrors the whole site for you automatically (hello again to the “stealing” section above). From there, you edit everything right in place: a built-in file manager and code editor let you rewrite a form field, tweak a script, or swap out an image — no FTP required.
When you set up flows and ways, all that’s left is picking the right site for the right role — and then everyone does their own job: you pour the traffic, the cloak filters it, the tracker counts it, the bots go fuck themselves, and the profit lands in your pocket.
A Light Flirt With the Moderator: Error Page and Blank Page
And now — some dead-simple methods for throwing dust in the moderator’s eyes without really breaking a sweat.
Show an error page. An error makes a great white for sources where moderation isn’t exactly burdened with brains. And yes, FB is precisely that kind of unsophisticated source. An error page doesn’t break any rules on its own. If you genuinely believe Facebook is somehow optimizing against keywords on the target site, you urgently need an exorcism. All moderators actually do is scan the page for banned words. There aren’t any on an error page — so there you go, welcome to approval. By default it’s a standard nginx-style page, but you can set the code manually too — most people go with an honest 404.
Show a blank page. Used for trafficback, or for whites just as unassuming as the error page. A blank page returns a standard 200 response, same as meta-refresh: as far as the system’s concerned, there’s content, and there are no banned words. Not a single line of HTML — nothing to find fault with.
A typical setup: route the white through a blank page, the black through show-content-by-link. And if your system isn’t a single site but a whole prelander-plus-lander combo — there’s a separate working scheme for that.
Prelander + Lander Combo in Practice
So, a combo means two sites. The scheme is simple: first you warm the visitor up on the prelander, then you grill them on the lander.
Both sites, naturally, need to be hooked up to the tracker — otherwise you won’t get full stats with a CR for each page. What’s more, the tracker counts the jump from prelander to lander as a separate “second step”: the stats show both the number of those transitions and the prelander-to-lander conversion rate for the combo, not just the final result.
For the prelander, use whichever method you’ve grown fond of, but my personal favorites are curl and “show a site from storage.” The choice comes down to whether you actually have the site’s files to upload into that storage in the first place. The storage option is always more stable, faster, and more reliable.
From there, you either just as quickly pull the lander out of STORAGE, or stitch the prelander to the lander together with a 301 or 302 redirect. None of it’s complicated — you just need to poke the right buttons with your paws.
Bottom Line
There’s a huge range of methods to work with. Some are more complex to pull off, some are simpler, but none of them split neatly into “good” and “bad.” Every method has its own time, place, and way of working. What you actually use is entirely up to you, based on the specific job at hand and your own preferences.