---
name: run-multiple-simultaneous-tests
description: "Run a few small ad tests with clear limits. Compare the same goal when each test ends."
category: Dollar a Day Campaigns
stage: Promote
definitive_article: /dad
status: complete
---

# Run multiple simultaneous tests

You want to learn which post or group is a better fit. This guide helps you plan a few small tests at once. Start with one clear question and the total amount you can use.

**The path:** One question → priced test rows → bounded runs → fair review.

**Use this when:** More than one proven creative or audience hypothesis is ready and the budget and review capacity support parallel tests.

## Inputs
- Qualified posts, reviewed audience rows, a common goal and target; enough evidence to define a useful comparison.
- Exact account/currency/time zone, permitted budget controls, approved total amount and dates.
- Access for the planned actions and a shared log of active tests, remaining commitments, safety rules and review owner.

## First-run prompt

> Build a small test matrix for this question and total budget. Keep each row identifiable, priced and due for review. Compare one planned variable at a time, note overlap, and carry out only authorized launches. Do not create a fixed quota of tests or add budget to make an unsupported minimum fit.

## Steps
1. Choose the question first: two eligible posts with the same audience, or the same post with two audience settings. Do not change the goal, creative, audience and landing page together and call the result an explanation of one factor.
2. Start with only as many rows as the budget and reviewer can handle. The core method can layer one post per day; parallel testing is an option, not a requirement to launch 10–30 cells at once.
3. Create a row for every planned test with source post ID, audience, goal, budget type, amount, start/end times and success rule. Where Google Ads is used, budget belongs to the campaign; do not pretend each ad group has an independent cap.
4. Price the whole plan before launch. Three nominal $1/day tests for seven days mean $21, not $7. Verify platform minimums, average-versus-total behavior, fees and true limits; fewer tests or a pending plan is better than an unapproved increase.
5. Check shared/campaign budget behavior. If the chosen setup can move money across rows, report that allocation limit. Separate settings alone do not guarantee equal spend or a randomized experiment.
6. Inspect previews and saved settings, then launch only within the existing authority. Read back all IDs, dates and budgets. On a retry, reconcile the log first so the same row is not launched twice.
7. Check early delivery, broken links, missing events and ceiling drift. Avoid unnecessary changes during the planned window, but apply already authorized protective stops. Record any change and its date.
8. Review each row after its own full window. For staggered launches, due dates differ. Compare matching metrics, note sample and auction limits, and send every row to a keep, stop or bounded hold decision.

## Definition of done (QA checklist)

- [ ] The matrix answers one clear question with identified source posts.
- [ ] All row commitments fit the actual authorized total and current platform controls.
- [ ] Independent budgets are not claimed where allocation is pooled.
- [ ] Launch/retry checks prevent duplicate active rows and record early issues.
- [ ] Every row has its own due date and evidence-qualified verdict.

## Example(s)

**Fictional teaching example:** A shop has $21 for three seven-day tests in a setup that supports the plan. The matrix records three $7 nominal commitments and the actual spend controls. All use one goal, but only A and B compare two clips with the same audience; C explores a different audience and is labeled exploratory. If a row is rejected or receives too little delivery, it is not called a loser from zero results alone. The final report preserves actual spend instead of filling each row with a made-up $7.

## Handoff and Content Factory context

Send each due row to [analyze cost per result and engagement](https://local-service-spotlight.github.io/task-library/?task=analyze-cost-per-result-and-engagement#task-analyze-cost-per-result-and-engagement). The campaign owner controls the remaining commitments and any new test plan; stopped rows go to [kill underperforming ads](https://local-service-spotlight.github.io/task-library/?task=kill-underperforming-ads#task-kill-underperforming-ads).

This task is in Promote within the [Content Factory](https://blitzmetrics.com/content-factory/). Produce gathers real source material; Process makes useful assets; Post places and checks them; Promote distributes suitable work within its own scope. Use the proof and checked posts from earlier stages; a Promote task does not automatically redo all four stages. Use the actual next step above; catalog neighbors are not prerequisites.

## When this runs

One bounded matrix. Staggered additions or recurring batches are optional, with a real total budget, reviewer and trigger. A model or task pack does not create either a spend limit or a schedule.

## First-run setup and continuity

Open the supplied task file and its linked source. Verify the project’s real inputs, account, access and output folder before work. This Markdown file is a guide; it does not install an app, connect an account, supply a subscription or create a schedule. Carry out work already authorized; do not ask for the same approval again. Keep any unsupplied destination or new action outside that scope clearly pending.

Save source IDs, versions, decisions, checked outputs and next owner in the project tracker. Before a retry, check the saved state and other workers’ changes. A model name does not guarantee memory or a running timer. Repeated work needs an actual configured trigger and durable state; one-off work can be started by the prompt above.

Keep agent media muted with volume zero before playback. If mute cannot be verified, use captions, metadata or still frames. State the limit: silent visual checks do not prove spoken-word accuracy or audio quality. Do not start sound through the user’s speakers unless explicitly asked.

## Write up the real run

For every actual attempt, [write its meta article](https://blitzmetrics.com/meta-article-prompt/) with this recipe and revision, trigger, steps performed, output evidence, measured result, gaps and next owner. Failed, blocked and partial attempts also get a written record. A draft can satisfy writing; publishing it follows the existing job scope.

Keep one stable execution ID across retries and edits. A separately scoped child task may have its own ID linked to its parent. Writing the parent’s meta record is part of that run, not an endless new chain. The [recipe and meta-article guide](https://localservicespotlight.com/meta-articles/) explains this distinction. Teaching examples are not real executions and must not enter the run count.


<!-- factory-layer:start -->

## Factory chain (do not treat this as isolated)

- **Phase:** Promote
- **Importance:** 5/5 `●●●●●` — frequency 4, revenue 5, gating 3 (runs every factory cycle or weekly; ads/revenue path)
- **Suggested previous station:** `set-up-remarketing-ads-for-landing-page-abandoners`
- **Suggested next station:** `analyze-cost-per-result-and-engagement`
These stations are generated neighbors, not verified prerequisites or handoffs. Follow the task’s actual Inputs and Handoff sections.
- **Handoff:** Organic metrics CSV (or Ads Manager export), pixel ID, creative filenames, kill/scale log. Next week's ranking starts from this file.

## Model routing (same factory, any engine)

- **This task's lane:** `computer` — Logged-in UI (Meta Ads Manager, Descript, GSC, wp-admin when REST is blocked). Requires a supported browser tool and the right account access.
- **Single-engine path:** Use the capable AI app you already have. Check its required tools and access before starting. Pass the actual result and proof to the next task.
- **Optional multi-engine:** A tested local model may draft; a stronger model may review facts and voice. Use supported tools for approved actions. Pick models from observed quality and cost; a model name does not prove it can run this task.
- **Never** store the working state in one vendor's memory. Files in the Content Library are the bridge.

<!-- factory-layer:end -->
## Definitive article & links

- Maintained method: https://blitzmetrics.com/dollar-a-day/
- Source mapping needs reconciliation: the preserved `definitive_article: /dad` points to the coaching program. The method page above is `/dollar-a-day/`; this record does not certify the coaching page as a task recipe.
- Exact task: [Run multiple simultaneous tests](https://local-service-spotlight.github.io/task-library/?task=run-multiple-simultaneous-tests#task-run-multiple-simultaneous-tests)
- Writing standard: [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Dollar-a-Day method](https://blitzmetrics.com/dollar-a-day/)
- [Goals, Content, and Targeting](https://blitzmetrics.com/gct-business-strategy/)
- [Google Ads campaign budgets](https://support.google.com/google-ads/answer/2375454?hl=en)
- [Meta budget help](https://www.facebook.com/business/help/190490051321426)

## Review and evidence still needed

The source contributor status is preserved. It is not certification of this draft or proof of account access, completed work or a live outcome. The worked example teaches the method and is explicitly fictional.
- A real platform may not support the nominal $1/day plan or yield enough data in seven days.
- No matrix was launched or account/scheduler connected during guide authoring.