The Pre-Test Checklist Before You Spend a Dollar on UA

Before spending on installs, five things must be true: the build is stable on a cold launch, analytics events arrive from a release build, the store listing converts, the creatives are genuinely different from each other, and the budget and geography are set so the result can be read. Any one missing invalidates the test.

Why this matters

A test that cannot produce a clean answer still costs full price. Worse, it produces a number, and numbers get acted on.

The most expensive version of this is a concept killed by a broken test. You conclude the game does not work, when in fact the events were not firing or the store page was empty.

Every item below takes minutes. The test takes days and real money.

The purpose of a test is a decision. If a failure in setup could explain the result, the test cannot support a decision.

Build readiness

Run these on the exact build you will advertise, on a real device.

1. Cold launch works from a fresh install, with no crash and no long black screen.
2. The first playable action is reachable in seconds, with nothing gating it.
3. No placeholder content is visible: debug overlays, lorem text, build numbers.
4. It runs on your device floor, not only on the newest phone in the office.
5. The store build and the test build are the same version. Advertising one build while another is live is a surprisingly common mistake.
6. The advertised moment exists and is reachable early, per Why Most Prototypes Fail in the First Ten Seconds.

Analytics readiness

This is where tests are most often silently broken.

• Events fire from a release build, verified in the dashboard rather than the console.
• Install and first session are recorded, and a reinstall counts correctly.
• The funnel is instrumented: launch, first input, first win, second session.
• Attribution is connected, so installs map back to the campaign and creative.
• Consent handling does not block events where consent is granted.
• Time zones and date handling are consistent between your analytics and the ad platform, since a mismatch makes day-one retention look wrong.

Code stripping removing an event path in a release build is the classic failure here, and it is covered in Porting a Unity Prototype to a Publisher SDK.

Store listing readiness

The store page sits between your ad and your install, and a weak one distorts everything.

If the store page is weak, your test measures the store page rather than the creative. Fix the first screenshot and the icon before spending, since they carry most of the conversion.

Creative readiness

The creative is the thing being tested, so it needs to be a fair test.

• Two or three creatives, no more, each genuinely different in hook rather than in detail.
• Comparable production quality, so you are not comparing an idea against a finish.
• Correct aspect ratios for each placement, rather than one asset stretched everywhere.
• Readable with sound off, since most impressions start muted.
• The first frame is deliberate. It is the only frame many viewers will see.
• No claims the game does not deliver, for the reasons in Three Ad Creatives That Beat the Game.

Budget and geography setup

Setup decisions determine whether the result is readable.

1. One or two markets, held constant across creatives.
2. Equal budget per creative, in separate ad sets, so the platform does not pick a winner early.
3. A daily cap so nothing burns the budget in an afternoon.
4. At least three full days, to clear the learning period and cover day-of-week effects.
5. A shallow optimisation event, because low volume cannot support a deep one.
6. A written stopping rule, agreed before the test starts, so results are not evaluated emotionally halfway through.

The full reasoning at small budgets is in Creative Testing on a $500 Budget.

The one-page version

Print this and tick it before every test.

• Cold launch clean on the device floor
• First action within seconds, advertised moment reachable early
• Events verified in the dashboard from a release build
• Attribution connected, install and reinstall counted correctly
• Icon and first screenshot show the mechanic
• Two or three genuinely different creatives, equal quality
• Correct aspect ratios, readable muted
• One or two markets, equal budgets, separate ad sets
• Daily cap set, minimum three days, shallow optimisation event
• Stopping rule written down before launch

What we would do

Run a one-day, very small spend as a smoke test before the real test. Its only purpose is to confirm installs arrive and events appear. It costs little and it catches the failures that would otherwise ruin the main test.

Write the decision rule before spending anything. What result leads to continuing, what result leads to stopping, and what result means the test was inconclusive. Deciding this in advance is what stops a marginal result becoming whatever you hoped for.

Then keep the setup identical between tests. Comparability across rounds is worth more than optimising any single one.

The short version

• Verify the build cold on your device floor, with the advertised moment reachable early.
• Confirm events arrive in the dashboard from a release build, not the console.
• Fix the icon and first screenshot before spending, since they gate conversion.
• Two or three creatives, genuinely different, equal production quality.
• Equal budgets in separate ad sets, one or two markets, at least three days.
• Run a tiny smoke test first, and write the decision rule before you spend.

Tick the one-page list before your next test, and run the smoke test first. If you want the checklist run over a campaign before it goes live, send us the details.

Related reading: Setting Up Your First Facebook Creative Test, The Publisher Submission Checklist, and Soft Launch: How to Test Before You Spend.