Batch Testing Multiple Ads with Wreltik: Workflows for Creatives at Scale
When you need to test 20+ ad variants, your workflow needs to be systematic. How to batch-test efficiently with Wreltik and extract patterns from the results.
Batch Testing Multiple Ads with Wreltik: Workflows for Creatives at Scale
Testing one ad at a time is straightforward. Testing 20 requires a workflow. Without one, you'll spend more time managing tests than learning from them.
The naming convention
Before testing anything, establish a naming convention that captures what you're testing:
[brand]_[format]_[hook-type]_[length]_[version]- Example:
wreltik_ugc_question-hook_30s_v2
The convention lets you sort, filter, and compare results systematically. Without it, you have a folder of files with arbitrary names and no way to group them analytically.
The batch structure
Group your tests to answer specific questions:
- Batch 1: five hook variants for the same body. Question: which hook structure works best?
- Batch 2: three visual treatments for the winning hook. Question: which visual style amplifies the winning hook?
- Batch 3: two CTA placements for the best hook + visual combination. Question: where should the CTA go?
Each batch answers one question. The answer feeds the next batch. The workflow is sequential, not parallel — learn from batch 1 before designing batch 2.
Extracting patterns
After testing a batch, don't just identify the winner. Look for patterns across the batch:
- Did all the high-performing variants share a structural feature?
- Did all the low-performing variants make the same mistake?
- Is there a dimension (Visual Attention, Emotional Resonance, etc.) that consistently separates winners from losers in your category?
The patterns are more valuable than the individual results because they apply to the next batch and the next campaign. A finding like "specific-number hooks consistently outperform question hooks for our audience" is worth more than "Hook_Variant_3 scored highest."
Documentation
Keep a running document of batch results, patterns observed, and hypotheses generated. Review it before designing each new batch. The document prevents you from testing the same thing twice and reminds you of patterns that might inform current decisions.
The documentation doesn't need to be formal. A running note file with date, batch question, key findings, and next-action hypotheses is enough. What matters is that it exists and gets referenced — not that it's beautifully formatted.