Skip to main content

​
Demand Targeting vs Unit Targeting

It is important to separate two similar-sounding ideas:
  • Demand targeting decides which demand, line items, creatives or campaigns are eligible after an ad request is made.
  • Unit targeting decides whether a Fusion config matches the current page and whether the ad unit should load and make an ad request at all.
Custom key-values are demand targeting. Values set through the JS API, pulled from page metadata, or configured in Fusion are passed into the bid stream and to the ad server. Use these values to control which line items and creatives can serve. Custom key-values do not stop the Publisher Tag from making an ad request. If the unit matches the page, the request can still happen, even if the ad server later decides to serve nothing or a blank creative. To prevent requests on pages that should not show ads, use unit targeting. Fusion unit targeting includes the options described below, such as CSS selector placement, device, geography, browser, viewport and URL path targeting, alongside other publisher and audience controls available in Fusion. These decide whether the config is eligible to match and load.

​
Bespoke Page-Level Decisions

For cases where the publisher decides eligibility on the page itself, such as “do not load ads on pages marked sensitive”, the simplest approach is usually a body class. Add a class such as show-ads to document.body only when ads should be allowed, then prefix the config selector in Fusion:
Until the body has show-ads, the selector does not match, so the unit does not load and no ad request is made for that config. If your site uses a blocking class instead, such as sensitive, target the inverse condition:
This approach is easy to reason about, keeps the decision in unit targeting, and avoids the cost and reporting noise of sending requests to the ad server simply to receive blanks. If you use a blocking class such as sensitive, make sure it is present as early as possible, ideally in the initial server response. Once a unit has matched, it is not later unmatched or removed from the page if the class changes after the fact. For more dynamic cases, you can also use the Target conditional field. This is a JavaScript expression that must evaluate to true before the unit can match and load. For example, if the page exposes a boolean such as window.publisherGlobals.sensitive, the conditional could be:
Use target conditionals for small, reliable checks against values that already exist on the page. If the decision depends on async page logic, a body-class gate is usually easier to test and debug; see Unit Dependencies for that pattern.

​
Positional Targeting

On-page placement of an ad unit is achieved via CSS selectors. You will need to be able to look at your website’s HTML and pick the elements you want to target, and using your knowledge of CSS selectors be able to uniquely identify them in code. Don’t worry if all of this sounds alien, CSS Selector-based targeting is highly flexible, but requires an experienced web developer to implement. If you don’t have a web developer on your team, a member of our team will be available to help!

​
Advanced CSS selectors

Most of your targeting will use basic CSS selectors, as shown in the example tables below. These consist of using classes and IDs to identify and target your desired page elements. However, we support a large range of more advanced selectors, one useful one you may find helpful is the :nth-child selector. These types of selectors allow you to do useful things such as targeting every 3rd paragraph on an article page (.article-page p:nth-child(3n)). Or targeting every 4th paragraph starting with the 1st (.article-page p:nth-child(4n-7)) More information on :nth-child selectors can be found here: https://css-tricks.com/useful-nth-child-recipies/. It is also worth noting that you can include multiple selectors in a single config by simply using a comma, no need for multiple configs! CSS Extension We have implemented an extension to CSS to allow for index selection of matches, this is the :eq(n) selector, where n is a zero indexed number. For example, if you’ve got a list of blog posts listed on a category page, mixed in with other containers, it can actually be very hard to select the “second match” of a given class, because CSS selectors like nth-of-kind always count from the first element, not the first “matched” element. In this example, we could use .blog-post:eq(1) to select the second match! (With zero indexing, the first match is 0, second is 1 etc). Helper Classes & Unit Dependencies When targeting configs to your page, you can make use of helper classes that are automatically added to the body of the page, or to create dependencies between units, or react to unit state. We add the following helper classes to the body of the page, which can be used in your CSS selectors:
  • ci-{CONFIG_ID} - added when at least one target match of the given config is present on the page.
  • ci-{CONFIG_ID}-open - added when at least one of the given config’s units is open on the page (e.g. adhesion unit is expanded, or in-image unit is visible in the viewport).
  • ci-{CONFIG_ID}-empty - added when there are no available ads to serve for the given config, and therefore the unit is not shown.
With these you can accommodate for various scenarios, for example: Say you have a unit on page that serves skin/takeover ads, say config ID 1, and you have two skyscraper units on page that you only want to load if there is no skin/takeover available, you could add the targeting class ci-1-empty to the skyscraper configs, meaning they would only load if there are no skins/takeovers available. For more complex setups, such as waiting for another unit to miss or waiting for an external page process to complete, see the Unit Dependencies guide.

​
In-Image Examples

​
In-Article Examples

​
Device Targeting

You can also target individual configs based on device type (mobile, tablet or desktop), or any combination thereof. Simply select the devices you need, simple! This opens up a huge range of flexibility. Want a video unit that sticks on desktop & tablet, but not on mobile? Easy. Create one config with desktop & tablet selected and sticky enabled. Duplicate the config and select just mobile while disabling sticky. Use as many individual configs as you need to achieve your desired setup!

​
Geographic Targeting

Target countries easily by including or excluding them as required. Target fallback creatives to better match the audience or tailor your ad stack!

​
Browser Targeting

You can target any of the top 7 browsers, representing 95% of all internet traffic. This is great for trialling different ad stacks for the likes of Safari with its intelligent tracking prevention features, vs others.

​
Viewport Targeting

While device targeting as described above allows for quick and easy targeting of key device widths, viewport targeting offers highly customisable width targeting to perfectly match your sites custom breakpoints. If your site has a special wide breakpoint such as anything equal to or above 1400px, you can easily target this with a value of ≥1400px. This field will accept up to two values; a start value and an end value (to capture a breakpoint range), or just one value with an open start or open end (see example below). All values will be assumed px, pixels. We accept the following comparison operators:
  • >= Greater than or equal to.
  • <= Less than or equal to.
  • > Greater than.
  • < Less than.
Remember to enter your viewport declaration in to the field and hit enter to commit it, you can then add a second one if required, hitting enter again.

​
Examples

  1. <576px — Open start, so anything from 0 up to a maximum of 575px
  2. ≥576px — Open end, so anything from 576px upwards
  3. ≥1200px,<1400px — Range, anything from 1200px up to 1399px

​
URL Path Targeting

We also support config targeting down to the URL path. Only want adhesion on article pages? Want to try out a new config on a single old article? Not a problem! URL path targeting is done via one of two behaviours; include or exclude. Selecting “include” enables the config on all pages that match your list of URL paths. “Exclude” enables the config on all pages that don’t match your URL path list. Matches are made against the URL path, the bit highlighted in green here: https://docs.contentignite.com /publishers/tag-targeting/ #advanced-css-selectors So to match the above URL, the target would need to be /publishers/tag-targeting/.

​
Wildcard Matching

We also support wildcard matching where you’d like to match against URL path patterns. For example, take the following common URLs where there is a category and a post name in the URL: What if we wanted to match all “formula-1” articles on this site? This is where the wildcard character comes in; *, it matches any number of characters. To target “formula-1” articles, we can simply use the target:
We always match from the start of the path to the end of the path. In this case, the wildcard character matches anything after /formula-1/, therefore matching any articles within that section as they start with /formula-1/ and end with any other characters. Also, consider the following URLs: We could easily target all result pages with:
In this case, (because we match from the start to the finish) the wildcard character matches any characters at the start of the URL path, and then we match /results at the end of the URL path. Combine wildcard matching with the ability to add as many entries as needed and you can tailor advertising across your site in an incredibly flexible way, down to a hyper-targeted level.
Something or nothingPlease note that * matches anything, including nothing. If you’d like to match “something” like any subsection under /section/, use a double wildcard like so: /section/**

​
Additional Examples

TargetExample Notes
/Matches the home page only
/newsMatches the news page only
e.g. Would match:but wouldn’t match:
/news/*Matches pages within the news section only
e.g. Would match:but wouldn’t match:
/news*Matches any pages whose URL path starts with “news”
e.g. Would match:
/news//01/Could match any news article posted in January (given a well-structured URL)
e.g. Would match:but wouldn’t match:
/news/**Could match any news article posted in January (given a well-structured URL)
e.g. Would match:but wouldn’t match: