Pitch a Data-Responsive Ad Without Pretending the Sample Is a Live Feed

The deck usually arrives as five beautiful boards. Price at $19.99. Price at $24.99. "Only three left." A storefront in a different city. Every one of those frames was typed by hand, and nothing in the deck says so. The client is being asked to approve a behavior that has been illustrated but never described, and the first question in the room — what does it say when the number is missing? — lands like a trap.

It isn't a trap. It's the part of the pitch the treatment was supposed to carry.

A data-responsive commercial is a rule with edges. So the treatment needs four things, and everything else can stay open:

• The input. One named field, and where it's proposed to come from.
• The change. Which element on screen it controls, and what stays fixed.
• The states. Valid, overlong, missing, stale, out of range — and what the ad says in each.
• The label. Which frames are hand-built samples, and which behaviors are still unconfirmed.

Permissions, refresh intervals, validation ownership and implementation come later. The treatment should say they're later rather than quietly implying they're solved.

Name the changing input and what it changes on screen

"Live" is not an input. Neither is "personalized." Both describe a feeling the client is buying, not a field a system can read. An input is specific enough to have a name and a shape: a price, a stock count, a temperature, the next available appointment window for a named service area.

Then comes the second half, which is the one people skip: which element does that field control?

Take an invented example, used for the rest of this piece. Halyard Appliance Repair — fictional, along with all the place names — runs a commercial with three parts: a headline line, a subline naming the service area, and a button. The responsive surface is two fields. next_window is the next open two-hour appointment slot. area_label is the service area that slot belongs to. Halyard's declared service days are Monday to Saturday, 8 a.m. to 6 p.m.

Everything else in the spot is fixed: the brand name, the promise that a technician comes to you, the waived diagnostic fee, the button verb.

Sample data, typed by hand for this pitch. No connected feed, account, sheet, or live ad is involved.

Two fields, one headline, one subline. That's the whole responsive idea, and stating it in one sentence is what lets a client argue with it. "Should the fee change too?" becomes a question about scope. Before the sentence existed, nobody could ask it.

It's worth separating kinds of change, too, because they carry different risk. A headline that reads "Thursday, 2–4 p.m." instead of "Tomorrow" is a changed message. A photograph that swaps from a dishwasher to a dryer is a changed image. A price, a slot, a stock count, or a travel time is a claim with consequences if it's wrong. The last group needs the strictest validation and the best fallback, which is usually a good argument for making it the only responsive part of the commercial rather than one of five.

Give every important data state a meaningful response

Row 1 is the easy case, and it should be the smallest part of this section. next_window reads Thursday, 2–4 p.m., so the headline says:

Appointments available Thursday, 2–4 p.m. Kestrel Falls and nearby. Book a visit.

Row 2 changes only the label, and the label doesn't fit. It's a list of neighborhoods that will swamp the subline and push the button off the frame. The rule should be: if the label exceeds the declared length, replace the whole thing with the declared region default — "Kestrel Falls and nearby" — which is a sentence somebody wrote and somebody approved. Not truncate. A mechanical cut at a character count can turn "Lower Wharf — waitlist only" into "Lower Wharf," which promises a service area the original string took back. Truncation needs per-value review. A declared default needs one review, once.

Row 3 has no value at all. The ad goes to its authored neutral version:

Appointment windows change daily. See what's open. Kestrel Falls and nearby. Book a visit.

Row 4 is the interesting one. The value parses perfectly. The timestamp is three days old. Assume, for the sake of this table, a freshness limit of 24 hours — a stand-in that makes the demonstration concrete, not a recommendation, and one that leaves the verdict on this row provisional until the real threshold is set with the data owner. On that assumed limit, the ad cannot say "Saturday, 10 a.m.–12 p.m." — not because that's certainly wrong, but because nothing supports it. The slot may have been booked on Monday afternoon. So: neutral board, plus a flag to whoever owns the field.

Which gives us a workable definition. A value is stale when its timestamp is older than the point at which the ad can no longer stand behind the claim. That's an editorial threshold, and it depends on two things nobody in the room currently knows: how fast the slots actually go, and how the source updates. The treatment should name the threshold as an item to be set with the data owner before launch, not quietly assume a number that happens to make the boards look tidy. The 24 hours used above is a placeholder for that decision, not the decision.

A window whose start time has already passed is a separate case, and worth separating. That value isn't stale; it's false, and it should never be shown regardless of how fresh the timestamp is. Two conditions, not one.

Row 5 reads "Sun, 11 a.m.–1 p.m." It parses as a time. Halyard doesn't work Sundays. A validator that only checks formatting waves it straight through to the ad, which is why validation has to mean "is this usable" rather than "is this a time." Neutral board, plus a flag.

Three of the five rows produce identical copy. That is the least glamorous and most useful slide in the deck.

One more thing about the stale case, because it's the one that gets dressed up as a design decision. Reusing yesterday's window because it fits the layout is not neutral. If the copy says "available this afternoon," a three-day-old value isn't a placeholder — it's a statement about this afternoon. The layout wanting a value is a production problem. The audience reading it as current is a truth problem, and it's the bigger one.

Keep the sample separate from the system it proposes

Every board in the deck should carry one of three labels: composed sample, proposed rule, or confirmed behavior. In this example, only the first is real. The table above is sample data. The mapping from field to headline is a proposed rule. Nothing is confirmed, and that's fine — as long as it's said out loud.

What hasn't been confirmed is a list, and it's worth writing the list into the treatment rather than leaving it for a production meeting:

• Authorized source. Is the scheduling data ours to use in an ad, and who says so? Whether a slot exists and whether we may publish it are two different questions with two different owners.
• Update ownership. If the field is wrong at 9 a.m. Tuesday, who fixes it? A field nobody owns is a field that drifts.
• Validation. When the ad rejects a value, where does it go? If nobody receives it, the ad silently treats a broken source as a quiet week.
• Refresh behavior. How often does the value change in the source, and how does the ad learn that it changed?
• Exception handling. When the source is unreachable, does the ad show the neutral board or the last known value? By the rule above, the neutral board. That decision belongs in the treatment, not in a ticket.
• Fallback ownership. Who signs the neutral line, and how often is it re-read? A default approved two years ago is a default nobody currently owns.

Feed capability and creative coherence are different claims, and they need different evidence. Google Studio's dynamic-feed help documentation (support.google.com/richmedia/answer/3399836, inspected in September 2026) describes feed fields that drive changing creative elements, optional default and active columns, and a comparison between feed values and the creative. Its usefulness here is narrow and real: it shows one platform treating a field's value and a default handling of that value as separate, controllable things. That is exactly the structure proposed above, which is reassuring about the shape of the idea.

What it doesn't do is supply a universal freshness rule, authorize any data source, or demonstrate this campaign. It's one provider's system, and no feed, account, linked sheet, live ad, or fallback was tested to produce this piece.

Review the fallback as part of the commercial

Pull the valid board and the neutral board out of the deck and read them as two finished ads, side by side. Not as a layout with a hole in it.

Three checks.

Does the action still follow? "See what's open" into "Book a visit" holds together — arguably better than "Appointments available Thursday" into "Book a visit," because the ad isn't asserting that a slot exists. But if the button reads "Claim Thursday's slot," it doesn't survive the swap, and you find that out now rather than in post.

Does the frame still claim something the copy has backed away from? Copy is only part of an ad. A calendar graphic, a "today only" sticker, a countdown, an orange chip in the corner — if those travel with the valid version and the neutral version inherits them, the picture is asserting availability the words have given up. The fallback includes the image, and sometimes it needs its own.

Has the swap quietly made a different ad? If the whole spot is built on the thrill of a named window, the neutral version is a weaker commercial. That's a real cost of the responsive idea, and the treatment should say so instead of hiding it. It's also the argument for keeping the responsive surface small: the less of the ad that moves, the less the fallback has to carry.

And the proportion matters more than treatments usually admit. If the source fails often, the neutral version could be the most-seen version of the commercial, and right now nobody in the room can estimate how often that would be. That's a question for the data owner, not a footnote.

So give the fallback a board. Name it Default. Put it in the main sequence, next to the valid one, with the same care as the valid one. If it only appears in the appendix, the audience will meet it before the client does.

---

Strip the whole treatment back and it should still say this in three sentences:

The ad reads the next open appointment window for Kestrel Falls, and a subline naming the service area that slot belongs to. If the window is missing, outside Halyard's Monday–Saturday service days, already past its start time, or older than a freshness limit still to be set with the data owner, the ad reads: Appointment windows change daily. See what's open. Where the area name runs past its declared length, the subline falls back to the declared region default, "Kestrel Falls and nearby."

Everything else — the source, the permission, the refresh interval, the owner, the exact freshness threshold — stays open, and saying so is what makes the rest of the pitch credible. Two attractive boards don't establish that every possible value produces a usable ad. A declared rule and a written fallback at least tell the client what they're approving.

The sample is a sample. Say so on the board, and spend the rest of the pitch on the rule.

Frequently asked questions

What four elements turn a data-responsive ad from an illustrated behavior into a rule with edges?

The input (one named field and where it is proposed to come from), the change (which on-screen element it controls and what stays fixed), the states (valid, overlong, missing, stale, out of range, and what the ad says in each), and the label (which frames are hand-built samples and which behaviors are unconfirmed). Permissions, refresh intervals, validation ownership, and implementation come later, and the treatment should say so.

Why are “live” and “personalized” insufficient as the changing input?

They describe a feeling the client is buying, not a field a system can read. An input needs a name and a shape: a price, stock count, temperature, or the next available appointment window for a named service area. The pitch also has to say which element that field controls, such as a headline, subline, or button.

How should a treatment handle missing, overlong, stale, and out-of-range values?

Missing values go to an authored neutral version. An overlong area label should be replaced with a declared region default, not truncated, because a mechanical cut can turn a waitlist-only area into a promise. Stale means the timestamp is older than the point at which the ad can no longer stand behind the claim; that threshold is editorial and should be set with the data owner. A window whose start time has already passed is false, not merely stale, and should never be shown.

What should the deck label as sample, proposed, or confirmed?

Every board should carry one of three labels: composed sample, proposed rule, or confirmed behavior. In the example, the table is sample data, the field-to-headline mapping is a proposed rule, and nothing is confirmed. The treatment should also list what remains open: authorized source, update ownership, validation, refresh behavior, exception handling, and fallback ownership.

Does feed-platform documentation prove the campaign will work?

No. Google Studio’s dynamic-feed help documentation shows one platform treating feed values and optional default columns as separate, controllable things, which supports the proposed structure. It does not supply a universal freshness rule, authorize a data source, or demonstrate the campaign. No feed, account, linked sheet, live ad, or fallback was tested to produce the piece.

Further reading

• End the Commercial at a Real Next Step, Not a Fictional Button — Follow this when the fallback and valid boards both end on an action: it tests whether 'Book a visit' or a rendered button matches a real route.
• Pitch a Playable Ad Without Pretending It Is the Full Product — Compare this when the responsive sample could be mistaken for the finished experience; it names what an interaction sample is and what simplification must be disclosed.