Unit Dependencies

By default, the Publisher Tag is designed to load ads as quickly as possible. Units already in the current viewport, units configured to load out of view, and in-view units that are not blocked by their buffer limits are batched and loaded immediately. This is the recommended setup for most pages because faster ad delivery usually improves engagement and revenue. Use dependencies only when an ad unit genuinely needs to wait for another unit, or for a page-level process such as authentication, subscription detection, or consent-adjacent publisher logic. There are two dependency patterns:

For one Content Ignite unit depending on another Content Ignite unit, use the automatic body helper classes added by the tag. This does not require any publisher development work.
For a unit depending on an external page process, use a publisher-controlled body class that is added when that process is ready.

In both cases, the dependent unit’s CSS selector is prefixed with a class that is not present until the dependency is ready. The tag monitors class changes on document.body. When a body class changes, it checks targeting again, finds any newly matching configs, and loads the units that are now eligible.

Gating a unit with a body class

Say a config normally targets this container:

Normal targeting

.ad-mpu

To make that unit wait, add a body-class prefix in Fusion. For example, if the unit should only load after config 1 has returned empty:

Dependent targeting

.ci-1-empty .ad-mpu

Until the ci-1-empty class exists on the page, the selector will not match. If config 1 receives no ad, the Publisher Tag adds ci-1-empty to document.body, target matching runs again, and the dependent MPU becomes eligible to load.

Body helper classes are added to document.body, so they should be used as a prefix before the dependent unit’s normal selector.

Depend on another ad unit

A common example is a skin or takeover unit. You may want the skin to have the first opportunity to serve. If it does not return an ad, you then unlock one or more fallback units such as MPUs or skyscrapers. In this example:

Config 1 is the skin or takeover unit.
Config 2 is an MPU that should only load if config 1 misses.
Config 2 normally targets .ad-mpu in Fusion.

Set config 2’s selector to:

Fallback targeting

.ci-1-empty .ad-mpu

No event listener or custom JavaScript is required. The Publisher Tag adds ci-1-empty to the body when config 1 has no available ads to serve. Because config 2 only matches after that class exists, it will not load unless config 1 has attempted to serve and returned empty. You can use the same prefix on multiple fallback configs. For example, both a desktop skyscraper and an MPU could use selectors that start with .ci-1-empty if both should wait for the skin to miss. The available unit-state helper classes are:

ci-{CONFIG_ID} - added when at least one target match for the config is present on the page.
ci-{CONFIG_ID}-open - added when at least one of the config’s units is open on the page.
ci-{CONFIG_ID}-empty - added when there are no available ads to serve for the config, and therefore the unit is not shown.

Depend on an external process

Another common dependency is a client-side user authentication or subscription service. For example, a publisher may need to pass a subscription state into ad targeting before any ad requests are made. If ads load before the auth service is ready, some requests may go out without the required value. To avoid that race condition, prefix the affected unit selectors with a class such as show-ads:

Auth-gated targeting

.show-ads .ad-mpu

Then, when the auth service is ready, set the targeting value first and add the class afterwards:

Unlock ads after auth is ready

window.__ciads = window.__ciads || { cmd: [] };

function unlockAdsForUser(user) {
  const subscriptionState = user && user.isPaidSubscriber ? "paid" : "free";

  window.__ciads.cmd.push(function () {
    window.__ciads.setTargeting("subscription_state", subscriptionState);
    document.body.classList.add("show-ads");
  });
}

window.authService.on("ready", unlockAdsForUser);

The important detail is the order: call .setTargeting() before adding the body class. Adding show-ads causes target matching to run again, so the targeting value should already be queued before dependent units become eligible to load.

Do not use .setTargeting() for personal information. Subscription state, entitlement tier, or a non-identifying audience segment is fine; names, email addresses, phone numbers, age, gender, or other personal information should not be passed through targeting.

Avoid blocking ads forever

If an external dependency can fail, timeout, or be blocked by a browser extension, add a fallback path. Otherwise the gated units may never become eligible to load.

Auth dependency with a fallback

window.__ciads = window.__ciads || { cmd: [] };

var adsUnlocked = false;

function unlockAds(subscriptionState) {
  if (adsUnlocked) {
    return;
  }

  adsUnlocked = true;

  window.__ciads.cmd.push(function () {
    window.__ciads.setTargeting("subscription_state", subscriptionState);
    document.body.classList.add("show-ads");
  });
}

window.authService.on("ready", function (user) {
  unlockAds(user && user.isPaidSubscriber ? "paid" : "free");
});

window.setTimeout(function () {
  unlockAds("unknown");
}, 2000);

The timeout value should be agreed with your technical and commercial teams. A short timeout protects revenue and ad delivery; a longer timeout gives the dependency more time to return richer data.

Implementation checklist

Gate only the units that need the dependency. Leave unrelated units loading normally.
For unit-to-unit dependencies, use the automatic helper class for the config being depended on, such as ci-1-empty.
For external dependencies, add the publisher-controlled class to document.body, not to the individual ad container.
If using JS API targeting, set targeting before adding the body class.
Include a fallback if the dependency is controlled by a third-party or publisher-owned service.
Test with ad debugging parameters and browser developer tools to confirm the class is added, target matching reruns, and the dependent config loads.

For more detail on selector targeting, see Publisher Tag Targeting. For more detail on passing targeting values before external dependencies unlock, see Setting targeting.

Getting started

Integrations

Publishers & Tags

Audiences

Orgs & Users

Reporting & Alerts

Gating a unit with a body class

Depend on another ad unit

Depend on an external process

Avoid blocking ads forever

Implementation checklist

​Gating a unit with a body class

​Depend on another ad unit

​Depend on an external process

​Avoid blocking ads forever

​Implementation checklist

Gating a unit with a body class

Depend on another ad unit

Depend on an external process

Avoid blocking ads forever

Implementation checklist