Five Prototype Mistakes That Burn Publisher Test Slots

Publisher test slots are rationed. Most publishers run a fixed number of tests per month, and a slot spent on a broken or incomplete prototype is a slot that does not come back. Five mistakes account for most wasted slots, and all five are fixable before submission.

Why test slots are precious

A publisher test slot is not just budget. It is attention.

The team that reviews your test results, interprets the data, and decides whether to proceed has a fixed number of hours. A test that produces bad data because of a preventable mistake costs those hours without generating useful signal.

Worse, a failed test changes how the publisher views your next submission. Not because they hold grudges, but because their internal data shows your studio's test-to-success ratio, and that ratio influences how quickly your next concept gets a slot.

The checklist in Publisher Submission Checklist covers the full submission. What follows are the five mistakes that specifically waste the test itself.

Mistake one: submitting a build that crashes on common devices

The most damaging and the most preventable.

A build that crashes on ten percent of devices during a paid test does not just lose those installs. It skews every metric. Retention looks lower because crashed sessions count as churned users. Session length drops because crashes end sessions. The publisher cannot tell whether the game is weak or the build is broken.

The fix. Test on at least three physical devices before submission, including one low-end Android phone. Run the game for a full session on each. If it crashes once, it will crash a hundred times at test scale. The device strategy is in Android Fragmentation Guide.

Check your crash reporting tool after every build. A clean internal test on three devices is the minimum, not the goal.

Mistake two: missing or broken analytics

A test without analytics is a test without results.

Publishers need specific events: first open, tutorial complete, level complete, session end, and any custom events tied to the core loop. If these are missing, misconfigured, or firing at the wrong moment, the publisher gets install numbers and nothing else.

The fix. Verify every event fires correctly before submission. Do not trust the integration, test it.

Walk through the game with the analytics dashboard open. Complete the tutorial. Finish three levels. Close and reopen the game. Check that every event appeared with the correct parameters and timestamps.

A prototype with broken analytics is invisible to the publisher. The test runs, money is spent, and the data is useless.

Common failures include events that fire on the wrong screen, session events that never close, and level events that do not include the level number. Each makes the data unreadable.

Mistake three: an onboarding that loses half the users

The first thirty seconds of a prototype test determine most of the data.

A confusing opening, a slow loading screen, a permission popup before gameplay, or a tutorial that explains too much before letting the player act will lose players before the core loop is reached. Those lost players look like retention failures in the data, but they are onboarding failures.

The fix. Get the player into the core action within fifteen seconds of first launch. No splash screens, no story setup, no account creation, no permissions. Just the game.

The opening should show the main interaction, let the player do it once with guidance, and then let them play. The detail is in Why Prototypes Fail in the First Ten Seconds.

Test the onboarding by handing the phone to someone who has never seen the game. Watch silently. If they are not playing within fifteen seconds, the onboarding needs cutting.

Mistake four: a core loop that is not visible in the test video

Publishers evaluate the video before deciding to test. A video that does not clearly show the core loop, what the player does over and over, can either prevent the test from being approved or set wrong expectations about what the game is.

The fix. The first five seconds of the video must show the core action. Not the menu, not the logo, not a cinematic. The action.

Structure the video as:

1. The core action, shown clearly.
2. A win or completion moment.
3. A second round showing progression or variation.
4. The hook or twist that makes this concept different.

Total length: thirty to sixty seconds. No narration. No text overlays explaining what the player is doing. If the action needs explaining, the action is not clear enough.

The video is also the basis for the test creative. A clear video produces a clear ad, which produces a clean CPI read. A confusing video produces a confusing ad, which produces a CPI that measures the ad rather than the concept.

Mistake five: testing the wrong question

A prototype should answer one question, per A Prototype Answers One Question. A prototype that tries to test everything tests nothing.

If the core loop is unproven, test the core loop. Do not also test monetization, meta progression, social features, and live events. Each addition dilutes the signal and increases the chance that something breaks.

The fix. Write down the one question the test should answer before building the prototype. Then remove everything from the build that is not needed to answer that question.

Common bad questions:

• "Is this game good?" Too vague to test.
• "Will people pay?" Too early, requires retention first.
• "Does the whole game work?" Too broad for a prototype.

Good questions:

• "Does this core mechanic produce a CPI below $0.30?"
• "Does the first session hold players past level three?"
• "Does the hook in the creative match the gameplay?"

A good question has a number in it. If the question cannot be answered with data, it is not a test question.

What we would do

Before submitting a prototype for a publisher test, run through these five checks as a gate.

Test on three devices and confirm zero crashes. Walk through the game with analytics open and verify every event. Hand the phone to someone new and time how long it takes them to reach the core action.

Record a test video and watch whether the loop is clear in the first five seconds. Write the one question the test answers and cut everything that does not serve it.

This takes half a day. A wasted test slot costs weeks.

The short version

• A wasted test slot changes how the publisher views your next submission.
• Test on three physical devices, including one low-end Android, and confirm zero crashes.
• Walk through the game with the analytics dashboard open and verify every event.
• Get the player into the core action within fifteen seconds, with no setup screens.
• Show the core loop in the first five seconds of the test video.
• Write the one question the test answers and remove everything else from the build.

Run the five checks before your next publisher submission. If you want a prototype built to clear publisher test gates, reach out.

Related reading: Publisher Submission Checklist, Prototypes Fail in the First Ten Seconds, and A Prototype Answers One Question.