An A/B-Test Asset Generation Workflow

Meaningful A/B testing requires that the only difference between variant A and variant B is the element under test. When variants are created manually — even by the same person using the same tool — small unintended differences accumulate: a slightly different crop, a marginally different color temperature, a prompt phrasing that inadvertently changes the mood. These uncontrolled differences contaminate the test signal, making it impossible to attribute performance differences to the intended variable. A workflow solves this by encoding all fixed elements as shared upstream nodes and only branching at the specific parameter being tested, guaranteeing that every other dimension of the asset is identical across variants.

The A/B-test asset workflow has two sections. The first section is a fixed shared pipeline: an image generation node with a locked seed value, locked style reference, locked character reference, and locked composition prompt. Everything that must remain constant across variants is upstream of the branch point. The second section is the branch: a Parameter Branch node that holds an array of test values — for example, three different headline copy strings, or four different background color descriptions — and fans out one execution path per value. Each branch path feeds into a Text Overlay or Image Variation node that applies only the differing parameter, then into an output node that labels the result with its variant identifier (A, B, C, D).

The critical implementation detail is the locked seed. Set the same seed value on every generation node across all branch paths. This ensures that the underlying image structure is identical for every variant, and only the overlaid or prompted variation differs. Without a locked seed, the generative randomness itself becomes a confounding variable.

Not every variable is worth testing in an automated variant workflow. The highest-value variables for creative A/B testing are those with a small discrete set of options and a clear hypothesis: "version with a person in the hero image outperforms version without a person" is testable. "Better looking ad" is not a testable hypothesis. Structure your variant branch around a single discrete variable per test run: headline copy (two to four options), primary visual composition (subject present vs. subject absent, or product close-up vs. lifestyle shot), call-to-action button label, or primary color palette.

Avoid testing more than one variable simultaneously in a single workflow run. If you need to test headline copy AND composition simultaneously, you are running a multivariate test, which requires a much larger sample size to reach statistical significance and should be managed through a separate experimental design — typically a full factorial matrix where each workflow run generates one cell of the matrix.

For A/B test results to be actionable, each output asset must be unambiguously labeled with its variant value. In the Floniks workflow, configure the output node on each branch path to embed the variant identifier in the file name — for example: "campaign-hero-v1-headline-A.jpg", "campaign-hero-v1-headline-B.jpg". Also embed the variant metadata (which parameter value corresponds to this file) in the output asset's task record. This metadata record becomes the lookup key when you retrieve performance data from your ad platform and need to match click-through or conversion metrics back to the specific variant configuration.

If you are running multiple test dimensions across multiple campaigns, consider adding a Campaign ID and Test ID field to each output node so the entire asset library is queryable by both dimensions independently.

A single variant workflow tests one variable at a time. When you need to test two or more variables simultaneously — for a multivariate test — expand the workflow into a full or fractional factorial matrix. In Floniks, this is implemented by nesting branch nodes: the first branch fans out by headline (four options), and each headline branch further fans out by background composition (three options), producing twelve total variants from one workflow run. Twelve variants is a reasonable upper bound for a single workflow execution; larger matrices should be decomposed into multiple workflow runs to keep execution time and credit cost predictable. Label the outputs with a combined variant code — for example "H2-BG3" for headline option 2, background option 3 — to make performance data attribution tractable.