Targeting answers two questions: where the campaign is allowed to appear, and who is allowed to see it.
Decided on the server, in PHP:
Anything tied to the URL or the logged in user is evaluated before the page is sent. A campaign that does not apply is never handed to the browser at all, so it costs nothing and cannot be read out of the page source.
- Where: show everywhere, or include and exclude specific page IDs, plus a toggle for the home page
- Who: login state, either everyone, logged out only or logged in only
- From where: referrer contains, referrer does not contain, or direct visits only
- From where: a URL parameter name and optional value, so a launch bar can be aimed at utm_source=newsletter traffic only
- When: a start date and an end date
Decided in the browser, in JavaScript:
These rules must run client side, because a page served from a full page cache is byte identical for every visitor. Deciding them on the server would mean the first visitor's answer gets cached and served to everybody else.
- Device: desktop, tablet, mobile, chosen by viewport width
- Visitor: everyone, new visitors only, or returning visitors only
- Frequency capping and hide after conversion
The campaign configuration also carries rules for post types, taxonomy terms, user roles, days of the week and hours of the day. These are honoured by the server side matcher, but the builder does not currently expose controls for them, so treat the list above as what you can set from the interface today.
A practical targeting pattern:
Run a general opt-in campaign everywhere, then exclude your checkout, thank you and lead magnet delivery pages by ID. That stops you interrupting somebody who is already in the middle of converting.
Every rule is combined with AND. A campaign shows only when the schedule, the login state, the referrer, the URL parameter and the location rules all pass.