Condition Variants

To verify internally before publishing — these points came up as uncertain on the call this draft is based on:

• The exact weather data provider (referred to as "possibly IBM") and how the associated API cost is billed back to the account.

• Whether the URL condition currently supports wildcards, or only a "starts with" match.

• The precise rule when several rows in the Conditions Table match at once — described as an even random split, but not confirmed.

• Whether "Dynamic" only appears as a Layout Variant option once at least one Layout Variant has been created on the creative.

Overview

Condition Variants let a single ad automatically show a different version of itself depending on the conditions of the person viewing it — for example their local weather, the time of day, their language, or the page they're on. Unlike Data Variants, which are fixed at export time, Condition Variants are evaluated live, every time the ad is served.

This guide walks through the full journey: setting up a creative to support Condition Variants, building the Conditions Table, testing it, and taking it all the way through to a live Deployment.

How this is different from other variant types

ResponsiveAds has a few different ways to make an ad change — they all live under Variants, but they solve different problems:

• Condition Variants (this guide): the ad checks the viewer's conditions at the moment it loads and picks the matching layout. Nothing is exported per-variant — one tag serves every version.

• Data Variants (CSV): you define a fixed list of versions up front (e.g. one per dealership) and export or deploy each one explicitly. There's no "checking" happening — you choose which version to use.

• Data Feed (JSON): similar to Condition Variants in that it's live and dynamic, but it's driven by an external feed rather than the Conditions Table — most commonly used for carousels.

See the comparison table on the Variants overview page for a side-by-side view.

---

Step-by-Step Guide

Step 1: Set Up Your Creative

Before a creative can use Condition Variants, it needs Layout Variants — the different visual states the ad can switch between (for example, a "sunny" version and a "rainy" version, or a hot coffee cup versus a cold one).

1. In the Fluid Ad Creator, build out each version of your ad as a Layout Variant, showing and hiding elements as needed for that version.

2. This part of the process is identical whether you're setting up for Condition Variants or for CSV Data Variants — the difference only shows up later, in how the variant gets triggered.

Add layout variants buttonn accessed from the variants panel in the Fluid Ad Creator

Step 2: Build the Conditions Table

The Conditions Table lives inside a Deployment, on the Summary Page.

1. Open the creative's Summary Page and go to Ad Tags (Deployments & Ad Serving).

2. Create a new Deployment (or edit an existing one) and set Layout Variant to Dynamic. This reveals the Conditions Table.

   

   Ad Tags Section expanded with two Dynamic Depolments created. 'Open Conditions Table' button is highlighted
3. Add a row for each condition you want to check. Available condition types include:

   • Location (e.g. by ZIP code)

   • Weather (sunny, rainy, snowy, windy, etc. — see note below)

   • Time of day

   • Language (pulled from the browser's supported language list)

   • URL (matches against the page the ad is running on)

4. For each row, choose which Layout Variant should display when that condition is met.

5. Add a Default row — this is what displays if none of the other rows match.

Example conditions table for different content based on URL

Working with the table: rows can't currently be reordered or duplicated — each new row starts from scratch with default values, so build it top to bottom. If you already have a Conditions Table set up elsewhere (on another deployment, another creative, or even in Google Sheets), you can use Copy Table / Paste Table to bring it across, which can save a lot of re-typing.

How matching works: when the ad is served, it reads the viewer's conditions and checks them against your rows.

• If nothing matches, the Default variant is shown.

• If more than one row matches, the ad picks one at random from the matching rows (this is not something to rely on for A/B testing — it isn't set up to report on which version "won").

A note on Weather conditions

The Weather condition works differently from the others, since a browser doesn't natively know the weather. Instead, the ad makes a separate API call, using the viewer's IP address to look up their location, then their local weather.

• This carries its own cost, separate from standard ad serving.

• Some publishers with local editions of their site (e.g. a New York edition vs. a Washington edition) want the weather to match their edition's location rather than the viewer's actual location — for example, so a reader on the New York edition sees New York weather even if they're browsing from elsewhere. This can be configured, but needs a location list shared in advance for each site/edition.

A note on URL conditions

The URL condition matches against the start of the page URL the ad is running on. This is commonly used to serve a different variant depending on which of several sites or environments the ad is embedded on.

Step 3: Preview and Test

Before deploying, check that each condition shows the right variant:

1. Open the Preview Page for the creative.

2. Use the Conditions Simulator to manually set conditions (e.g. "rainy," a specific ZIP code) and confirm the correct Layout Variant appears.

3. Use Breakout View to see every variant laid out side by side at once, rather than stepping through conditions one at a time.

Preview page with Layout Variants dropdown expanded

Step 4: Deploy

Condition Variants are configured at the Deployment level, so deploying them is the same as deploying any other ad tag:

1. From the Summary Page, go to Ad Serving Tags.

2. Publish the Deployment that has your Conditions Table configured.

3. Copy the resulting ad tag and place it on the page(s) where it should run.

Deployments always start empty. Duplicating a creative or starting from a template does not carry a Conditions Table across — it has to be rebuilt (or copied in via Copy Table / Paste Table) on the new deployment. This is intentional: trackers and click-through URLs on a deployment usually need to reflect that specific run of the campaign, so nothing is pre-filled that might be wrong.

---

Tips for a Smooth Workflow

• Start simple: get one condition (like Location) working end-to-end before layering in more.

• Always set a Default: without one, an unmatched viewer will see nothing configured for their situation.

• Use Copy Table / Paste Table to avoid rebuilding a Conditions Table from scratch across deployments or creatives.

• Type carefully: condition values need to match what's set up in the editor exactly — there's no validation to catch typos.

• Use Breakout View early — it's the fastest way to sanity-check every variant at once, rather than manually stepping through conditions.