01The bottleneck
The team's whole edge is iteration speed: ship a batch of creatives, find the winner, then spin that winner into localized variants for the next cycle. The strategy was sound. The variant production was the choke point.
The moment a concept won, the clock started — and stalled. Every localized, subtitled variant was a manual edit. By the time the variants shipped, the test window had often moved on, so winners got tested late or not at all.
- ·Each localized variant edited by hand after a winner emerged
- ·Subtitle styling re-applied per variant, inconsistently
- ·Variant batch queued behind the editing team
- ·Test windows closed before variants were live
- ·Programmatic variant rendering from a single winning source
- ·Consistent caption styling across every variant
- ·Async delivery wired into creative-ops tooling
- ·Per-campaign usage attribution for spend reporting
- ·No editing queue between a winner and its variants
02The ZapCap workflow
Variant rendering moved into their internal creative-ops tool. When a creative is promoted to "winner," an operator picks the target languages and a campaign caption template, and the tool batches one ZapCap task per variant.
The tool POSTs the winning source URL to /videos, then fires a task per variant with its language and the campaign templateId. Each task returns a taskId; the webhook handler verifies x-signature, dedupes on eventId, and drops the finished renderUrl back into the creative library against the parent winner.
Most variants ship as burned-in .mp4 straight into the ad accounts. For placements that need a clean alpha layer, the same call requests the transparent (prores4444 / vp9 alpha) output instead.
03Technical implementation
The integration landed as a batch action inside the existing creative-ops tool, not a new service. "Promote to winner" gained a "generate variants" step that fans out tasks and tracks each one back to the parent creative.
Failure handling. ZapCap is a normal upstream dependency: signed webhooks, eventId-based dedupe so retries never duplicate a variant, and per-variant status so a single failed render re-queues without blocking the batch.
- "Generate variants" action in the creative-ops tool — fans out one ZapCap task per language variant.
- Campaign templateId (UUID from GET /templates) per program for consistent caption styling.
- Webhook handler · x-signature verified, eventId-deduped, renderUrl filed against the parent winner.
- Dual output — burned-in .mp4 by default, transparent overlay on request for clean-layer placements.
- Per-campaign usage tag so per-minute spend maps to the campaign that generated the batch.
- Per-variant retry — one failed render re-queues independently of the rest of the batch.
04What changed
Variant production stopped gating the test cadence. A winner now spins into its variant batch the moment it's promoted, so the next test cycle starts on schedule instead of waiting on an edit queue.
Spend reporting got sharper. Per-minute usage is tagged per campaign, so each program sees its own variant-rendering cost rather than one shared production line.
- ·Each localized variant hand-edited after a winner emerged
- ·Variant batches queued behind the editing team
- ·Test windows often closed before variants went live
- ·Caption styling drifted between variants
- ·Variant cost lumped into one production line item
- →Programmatic batch — one task per variant on promotion
- →No editing queue between a winner and its variants
- →Winner-to-market moved from days to hours
- →Consistent caption styling via one campaign template
- →Per-minute usage attributed per campaign
05In their words
Our whole model is iteration speed, and variant production was the one part that couldn’t keep up. Now the moment a creative wins, its localized variants render themselves. The editing queue stopped setting our test cadence.