Pop-under, tab-under and direct-link placements

Pop traffic in Epom is served by a placement that answers an ad request with an HTTP 302 redirect to the advertiser’s landing page instead of with ad markup. The same mechanism is behind a pop-under, a tab-under, a “direct link” sold to a traffic source, and a pop bought from an OpenRTB demand partner. This page shows how to set one up, what the reports count for it and how to frequency-cap it.

Who this is for

Network managers and publishers who sell or buy pop / direct-link traffic. The Always redirect checkbox needs the Always Redirect permission; without it the checkbox is not on the placement page.

Prerequisites

• A site and zone to hold the placement, and permission to create a Non-standard Placement (Non-Standard Site Placements) or a Mobile Site Placement (Mobile Site Placements).
• The Always Redirect permission, for the checkbox on the placement.
• The Direct URL invocation code for that placement type (it appears under the placement type in Roles), so the Direct URL tab is shown.
• Demand that produces a URL: a campaign you can add Template banners to (Template permission), or an OpenRTB DSP partner that returns pops.

How a pop is served

Three pieces have to meet — if any is missing the placement returns ordinary markup instead of a redirect:

1. A Non-standard Placement or a Mobile Site Placement with Always redirect ticked (Basic info → Advanced settings). The checkbox exists only on those two types.
2. A linked banner that produces a URL: either a Template banner built on a template with Always redirect with 302 response code ticked, or an OpenRTB (DSP) banner whose partner returns a pop.
3. A request to the placement’s Direct URL (…/ads?key=…, the Direct URL tab of Ad Tags & API). This is the link you hand to the traffic source or open from your own pop script.

When a banner wins, the server answers 302 Found with the banner’s URL in Location. When nothing can serve — no banner matches the targeting, every candidate is capped or limited — it answers 404 Not Found and records a no ad for the request. Nothing is appended to the redirect URL: no impression beacon, no overlay, no cookie-sync pixels.

Steps — sell a direct link or a pop-under

1. Account → Publishers → site → zone → Add placement, type Non-standard Placement.
2. Open the placement, expand Basic info → Advanced settings and tick Always redirect. Save.
3. Create the demand: in the campaign, add a Template banner and pick the template Always Redirect with 302 Response Code (a system template every network has; your network administrator may have renamed or added others). Fill its one property, Url, with the landing page — up to 2,000 characters. Link the banner to the placement.
4. Open Ad Tags & API → Direct URL on the placement and copy the URL.
5. Test it: paste the URL into a browser address bar. You should land on the banner’s URL. A blank 404 page means no banner could serve — check linking, targeting, capping and limits as for any banner (My ad is not serving).
6. Give the URL to the traffic source, or call it from your own pop/tab-under script with window.open(url).

Note — test from the countries you target. A browser request carries your own IP, so a banner targeted at another country answers 404 from your desk. Use a placement-level test banner with Global targeting, or the Preview page’s IP override on a non-redirect placement, to check the setup first.

Macros in the direct URL

The template’s Url value is macro-processed before the redirect, with the publisher and advertiser macro sets — so a landing page can carry the placement, the traffic source’s sub-IDs and a click ID:

https://landing.example/offer?src=$$PLACEMENT_ID$$&sub=$$CUSTOM_PARAM(source)$$&cid=$$CLICK_ID$$

Anything you append to the direct URL as cp.<name>= (for example &cp.source={zoneid} filled by the traffic source) is available as $$CUSTOM_PARAM(<name>)$$. See the Macros reference for the full list and the _ESC (URL-encoded) variants.

What counts as an impression and a click

Event	When it is recorded for a redirect placement
Request	Every call to the direct URL
Impression	At the moment of the redirect, server-side — only if the template has Template impressions record ticked, or the banner is an OpenRTB pop. The system 302 template has it ticked.
No ad	A call that ended in 404
Click	Not recorded automatically. A redirect has no click of its own. If you need clicks, route the landing page through the click redirect: put $$CLICK_REDIRECT_URL$$ in front of it in the template’s Url

So with a pop capped at “1 impression per 30 minutes”, one impression is one pop opened for one visitor; a second page view inside the 30 minutes asks again, gets a 404 and shows up as a request without an impression.

Corner case — a copy of the template without Template impressions record redirects fine but records no impression, because nothing else in the redirect path counts one. If a pop placement shows requests and zero impressions, check that flag on the template.

Do tracking pixels fire on a pop?

No pixel in the page sense. A pop is a 302 redirect: the visitor’s browser receives a Location header and goes straight to the landing page, and no HTML from Epom is ever loaded. So nothing that is markup runs:

• the banner’s third-party tracking code (impression pixels, JS trackers) is not added — redirect content is a bare URL, and anything appended would break it;
• Epom’s own impression beacon is not used either — the impression is recorded on the server at the moment of the redirect (see What counts as an impression and a click).

What does work for a third party:

• Server-side trackers on the banner or the placement. An Impression tracker is called by the ad server itself when the pop’s impression is recorded, with macros filled in; a Request tracker on every redirect served. This is the way to give a partner an impression count for pops.
• Their tracking link in the redirect chain — put the partner’s click/redirect URL in the template’s Url with your landing page inside it, so the visitor passes through their server on the way.
• Epom’s click redirect — $$CLICK_REDIRECT_URL$$ in front of the landing page records a click in Epom (a pop has no click otherwise).

Pops in a native app or WebView

There is no Epom SDK for pops — and none is needed. The app requests the placement’s Direct URL like a browser would (from the app’s HTTP client or by opening it in a WebView or the system browser) and follows the 302: the Location header is the landing page to open, a 404 means no ad. The impression is recorded at the redirect, server-side, so nothing has to run inside the app afterwards.

What the app should send:

• The device’s real user agent — a request whose user agent matches a known bot gets an empty answer instead of a redirect.
• &bundle= and &ifa= (the app’s bundle ID and the device advertising ID) and anything else you target or pass through macros, such as &cp.<name>= values — see Ad request parameters.
• The real visitor IP: when your server calls the Direct URL on the app’s behalf rather than the device itself, geo targeting and capping see your server’s IP.

Cookie-based frequency capping cannot work in most apps — switch the placement or campaign to server-side capping (see Frequency capping for pops).

Script-based pops and tab-unders

A pop that opens from your page — on the visitor’s first click, on a click on a link, or on a CSS selector you choose — is JavaScript. Epom does not ship a built-in pop script: such formats are Template banners your network adds under Account → Templates (or that your network administrator adds for you), served on a Non-standard placement through the Universal JS tag like any other template. Their trigger, their own “show once per N minutes” setting and where they keep that state are whatever that template’s code does — read the template’s properties.

Two settings matter for the counts:

• A template that opens the pop on a click should have Template impressions record ticked and fire $$IMPRESSION_TAG_JS$$ (or load $$IMPRESSION_IMG_URL$$) when the pop actually opens. Without the flag the impression is counted when the script is delivered to the page, whether or not the visitor ever clicks.
• The script usually opens the placement’s direct URL — so the pop itself is the redirect placement above, and its capping is the redirect placement’s capping.

Frequency capping for pops: cookie, server-side or mixed (Safari)

Cap pops in the placement’s or campaign’s Frequency Capping card (Set up frequency capping). The Subject decides where the counter lives, and that matters more for pops than for anything else because pop traffic is heavy on Safari and mobile:

Subject	Where the count lives	Pops on Safari / iOS / Firefox
User (cookie-based)	A cookie on the serving domain	Not reliable — these browsers block or drop the cookie, so every request looks like a new visitor
User (server-side storage)	Server-side, keyed by the visitor’s ID	Works
User (cookie-based + server-side storage)	Cookie where cookies work, server-side otherwise	Works — the default choice for pops

The mixed subject switches to the server-side counter whenever cookies cannot be trusted: the visitor is in a private window (im=1), the browser is Safari, Mobile Safari, Firefox, Firefox Mobile, Brave or DuckDuckGo, or the OS is iOS, iPadOS or Apple TV.

Corner case — no Subject column? It appears only when your network has server-side capping storage switched on, which is a server-side setting. Without it every cap is a cookie cap and Safari visitors see the pop on every page view. Ask Epom support or your account manager to enable server-side capping if you sell pops.

Corner case — consent turns server-side capping off. A request whose cookie policy says “no cookies” (data-cookie-policy="1") is not written to server-side storage either.

Flat capping applies too: 4 per 24 hours, Flat allows one pop every 6 hours rather than four in a row.

Buying pops from an OpenRTB partner

Link an OpenRTB (DSP) banner to the always-redirect placement. Epom then flags the bid request as a pop for that partner — imp.ext.type = "pop" for a custom partner, the partner’s own convention for the built-in pop networks — and expects a landing URL back in adm (some built-in pop partners answer in their XML format, which Epom reads). A bid whose adm is not a valid URL is dropped. The winning URL is served as the 302, and the impression is recorded at that moment at the auction price. Setting up the partner itself is in Configure DSP partners.

Corner cases and gotchas

Corner case — Always redirect on a Site Placement does nothing. The flag is honoured only on Non-standard and Mobile Site placements, and only for a redirect template or an OpenRTB banner. Any other banner on the same placement is served as normal markup.

Corner case — header bidding. An always-redirect placement answers with a URL, so it cannot be sold through a header-bidding tag.

Corner case — discrepancies with the traffic source are larger for pops than for banners: the source counts the visits it sent, Epom counts the redirects it served. Requests that were capped, out of targeting, or from bots answer 404 or are filtered. See Analytics discrepancies.

Per-role notes

• Publishers without Always Redirect: the checkbox is absent; ask the network manager.
• Read-only / shared (Can view): you can copy the Direct URL but not change the flag.
• Demo account: redirects work against demo banners.

Related

• Display placements
• Ad tags, invocation codes and the API
• Create and manage banner templates
• Set up frequency capping
• Configure DSP partners
• Macros reference