Dynamic Creative Optimization (DCO) for Playable Ads: What Works Offline

Dynamic creative optimization — DCO — is the practice of assembling an ad from interchangeable parts at the moment it is served, choosing the parts from data about the viewer and learning over time which combinations perform best. A travel ad shows the route from the viewer's nearest airport at today's price. A retail ad shows the products the viewer browsed yesterday. The creative is a template; the data fills it.

Playable ads seem like a poor fit for this, and in one respect they are: a playable must be self-contained, with every asset inside it and no network requests, so it cannot fetch a product feed when it loads. But most of what DCO achieves can be reached another way. The trick is being precise about which decisions can happen inside the ad, which must happen when it is built, and which belong to the network.

How classic DCO works

1. A creative template defines the layout and the slots — headline, image, price, call to action.
2. A data feed supplies the values — products, prices, destinations, offers.
3. Rules or a model choose values per impression from signals such as location, time, language, audience segment or past behaviour.
4. The ad server assembles and serves the combination, and reports performance per combination, so the system learns which parts work.

On the open web this happens in a display ad server with a live feed. In-app, the rules are different.

Why a playable cannot do live DCO

Ad networks block outbound requests from playables, and many reject a creative in review for attempting one. So a playable cannot call a feed, a pricing API or a personalisation service. Anything it shows has to be inside the file when it is uploaded. That rules out yesterday's-browsing retargeting assembled inside the creative, and live prices.

It does not rule out being dynamic. It moves most of the dynamism to two other places: signals the ad can read on the device, and variants generated in advance.

What a playable can adapt to at runtime

• Language. The device reports its language, so one file can carry every translation and show the right one. This is the most valuable runtime adaptation a playable has, and it replaces a separate build per locale.
• Orientation and screen shape. The layout can rearrange for portrait, landscape and unusual aspect ratios, which is not personalisation but is the same idea — one creative fitting many contexts.
• Platform. The ad can tell iOS from Android and open the right store — and show the right store badge.
• The viewer's own choices. The largest source of relevance inside a playable is what the viewer does in it. A quiz answer, a chosen colour, a configured product is personalisation the viewer supplies, with no data leaving the device — and it can be carried into the click.
• Parameters on the ad URL. Where a network or ad server appends query parameters to the creative's URL, the ad can read them. Support varies by network and should be checked, not assumed.

What must be built in advance

Everything that depends on a feed becomes a variant: a separate file built from the same template with different values. Per product, per offer, per market, per audience. This is DCO's template-plus-data idea moved from serve time to build time. It works well when the number of variants is in the tens rather than the thousands, and when the data changes slowly — a seasonal offer, a product range, a set of destinations.

Letting the network do the optimisation

The third part of DCO — learning which combination works — is mostly available anyway. Networks rotate the creatives you upload and shift delivery towards the ones that perform. Google App campaigns go further, assembling ads from the assets you supply. Upload several structured variants and the network acts as the optimiser. What you control is the structure of the test.

Running DCO-style testing on playables

1. Build one template with every changeable element as a named slot — hook text, character, colour theme, offer, call to action wording.
2. Change one slot at a time between variants, so a result can be attributed to the change. See A/B testing playables.
3. Name each file after its slot values, so reports read as a matrix rather than a list of opaque file names.
4. Upload variants in groups the network can test fairly, with enough budget each to reach a conclusion.
5. Promote the winning value into the template and test the next slot.

A worked example

Take a food delivery app running in four countries with three seasonal offers. Classic DCO would assemble each impression from a feed. The playable version works like this. One template holds a spin mechanic whose segments are cuisines, a hook line, an offer line and a call to action. The hook and call to action are translated inside the project, so one file per offer serves all four countries, each viewer seeing their own language. The offer line differs per variant, so three files are built — one per offer — named by the offer. Each runs for exactly its offer's dates, so no file ever states an expired deal. The cuisine the viewer lands on is carried into the click, so the app opens on that cuisine's restaurants. Three files cover twelve market-and-offer combinations, and the network's rotation reports which offer performs.

Personalisation the playable is good at

The irony of DCO for playables is that the format already contains the strongest personalisation signal there is: the viewer's own behaviour, in real time. A quiz that recommends a product, a configurator that shows the viewer's build, a swipe deck that learns which destinations they skip — these adapt to the person more precisely than any segment rule, and they do it without using personal data. Carry the result into the click with deep link parameters, and the landing page continues the personalisation. See deep linking in playables.

Data-driven creative in Playable Ads Maker

Playable Ads Maker supports each of these layers. Translations are stored in one project, and the exported ad picks the language from the device. Variables and events turn the viewer's choices into what the ad shows, and deep link parameters carry them into the click. Repeaters and chips build card grids and option rows from a data table, so a catalogue or a plan list is edited as data and rebuilt, not redrawn — the calculator and catalogue guide shows how. Duplicate a project to make a variant, change its slot values, and export.