How to run a Steam Playtest: a studio's guide to setup, recruiting and feedback

A playtest can end with a Discord full of opinions and no decision anyone can defend. The build ran fine, a bunch of people played, and the team still can't agree on what to change. Usually the issue is upstream, a Steam Playtest that opened to sign-ups before a game team decided what the test was supposed to answer.

This playbook is for anyone new to running playtests, or new to running one on Steam: how a Steam Playtest works and how to turn feedback into decisions.

What is a playtest?

A playtest is a structured test where real players play an unfinished build and you find out what happens. It isn't QA. You aren't looking for crashes and broken collision, you're looking at whether the game reads the way you intended: whether players understand what to do, whether the thing you think is fun is the thing they think is fun, and where they stop.

Six months into a build, often the team can no longer remove bias to identify confusion or 'fun' in your own game. That is exactly the reason to run a playtest.

Different stages want different tests. At concept stage you're asking whether the core idea lands at all, with small numbers and one question. In production it's onboarding, comprehension and progression, where most playtests earn their keep because there's still time to act.

What is a Steam Playtest?

A Steam Playtest is a separate application that lives alongside your game. You create it from the Associated Packages & DLC page of your main app, and it gets its own appID, its own builds, and the same Steamworks features as the main game. Players never see a separate store page; Valve's documentation is clear that the playtest "will only show up as a section on the base game's page". The request-to-join button sits there, so the people clicking it are already looking at your game.

Valve describes it as "a completely free feature for both customers and Steam developers", and you aren't distributing the build yourself. Because the playtest is its own app, playtime, wishlists, reviews and refunds stay separate from your real game: someone who only played the playtest can't review the game.

What it isn't is confidential. Valve puts it plainly: players signing up "aren't under nondisclosure agreements with you, and there shouldn't be an expectation of secrecy", and admitting ten people instead of ten thousand doesn't change that. A quieter setup is possible with keys, covered below, but nothing binds a tester to silence unless you build the registration and NDA process yourself. Valve's own guidance is that "it's best to announce your game first, before running any external playtests outside of your organization".

Decide what the test has to answer

Write the questions down before you set anything up. Without them you get opinions you can't act on.

Good objectives are specific enough to be wrong:

• Do players understand what to do in the first ten minutes without being told?
• Does the crafting system read as a core mechanic or as an optional distraction?

Then write down what you are not testing. Balance, audio mix, placeholder art, the inventory screen you already know is broken. That list keeps a playtest from sliding into a general bug hunt, and it goes in front of testers so they don't spend a session reporting things you know about.

Decide how many players you need before you decide anything about admission.

• around 10 players will surface the usability problems and the blockers to fun, because the same walls come up again and again.
• For long-form progression testing we plan for 15 to 20, which gives enough variation to tell a personal preference from a structural problem.

Set up the playtest and choose how testers get in

A Steam playtest game build goes through Valve's review before it can go live. It's lighter than a full store page review, covering capsule images and icons rather than the whole listing, but it isn't instant, so don't plan a playtest that opens the same week you decide to run one. Sign-ups are switched on from the Special Settings tab of your main game's store page tools, not from the playtest app.

After that, decide how people actually get in.

Limited signup

The default, and the right choice for most tests. Players request access from your store page and enter a pool, and you admit them in batches, choosing the size and timing of each wave. You don't choose the individuals: Valve's documentation is explicit that "Steam will choose playtesters at random from the set of Steam accounts that have requested access". Bring in twenty players, watch what happens, fix the three things that broke, then open the tap further. Each wave arrives with no prior exposure, which is what lets the second one tell you whether your fix worked.

Open signup

Every player who requests access is admitted automatically. It suits volume work such as a stress test or activity timed to a festival, and it's a poor fit for careful observation. Switching to open also kicks off a process that accepts everyone already waiting in the pool, generally starting within a few minutes. You can switch back to stop new admissions, but the players already in stay in; removing them means resetting the playtest, which clears everyone.

Access Keys for Playtesting

For tighter restricted control if you want it., you can request Steam keys for the playtest app and hand them to specific players. Valve is explicit that this doesn't depend on your store presence: "you can generate and distribute keys for a Playtest even if your store page is not live yet", and it's "not a requirement that your Steam store page is publicly visible on Steam to run your playtest using Steam keys". That makes keys the practical option for testing before announcement, for press and creators, and for anyone you've promised a place to.

This is also the mechanism Valve points to when a test genuinely has to stay quiet: run the playtest with keys and store visibility set to Hidden, or use the base game's appID with release override keys. Either way the registration and any NDA are yours to handle.

Some mechanics worth planning around. Playtest keys are standard release keys, so a key only opens the game while the playtest is set to Playable. A key already granted stays granted: marking the playtest Not Playable stops it launching but doesn't take the key back. Keys are free, but Valve restricts how you use them: "it's not OK to charge customers to access your Steam Playtest, and you should never sell Steam Playtest Steam keys or include them in paid Steam key bundles or subscriptions".

Valve recommends playtest keys over release override keys on the base game, partly on volume: override keys on your main app are capped at around 2,500, while playtest key requests can go much higher. Ask for more than 50,000 and Valve's position is that what you are running is effectively an open beta, and that you should open store sign-ups instead.

Friend invites

Available whichever route you use: admitted players can invite 1, 2 or 3 friends, and those friends can invite theirs, so numbers compound faster than most teams expect. Steam only allows invites to friends of at least 30 days' standing, which rules out accounts added for the purpose. You can pause new invites or limit them to players who joined by a given date, though an invite already sent stays live either way.

Genuinely useful for co-op and multiplayer, where a player testing alone tells you very little, but watch what it does to your sample: friends tend to resemble the player who invited them.

What else you control

Access can be restricted by country, which matters for anything with a server component, where latency is critical or you want to only run dev servers in particular locations. You also control whether the build is playable and whether sign-ups are open. Leaving it unplayable while sign-ups run builds a queue before there is anything to play. Keeping it playable with sign-ups closed lets your current testers carry on while the pool stops growing.

Ending a test uses the same pair in a specific order: close store-page sign-ups first, because the Not Playable option stays hidden while they're open. Come back for a later wave and everyone previously admitted still has access without signing up again.

Clearing the tester list is heavier. Resetting the playtest removes every participant and everyone waiting, disables all keys including unactivated ones, and archives pending friend invites. It can't be undone, and Steam won't allow it until the playtest is Not Playable, hidden, back on limited signup and with friend invites paused. It's for starting a genuinely new phase of testing. Setup mechanics change, so treat Valve's documentation as the source of truth rather than any walkthrough.

Find the right testers

If you have one, use your own community for depth and repeat testing, and outsiders or public steam playtests for the cold-start problems your fans no longer notice. Write down who the test needs in terms you could screen for before you post playtest invites anywhere.

Your own community

Your Discord server and mailing list are the fastest route to committed testers, and they come back for the next build. Use them for depth: long sessions and progression testing, where you need a player invested enough to keep going for three hours.

Set up a dedicated channel per test rather than letting feedback land in general chat, with a pinned post covering what you're testing, what you're not, and where/how to report.

Reddit

Reddit works if you respect that each community has its own rules and its own tolerance for developers. Read them before you post.

• r/playmygame requires something playable for free right now: a build, a demo, or at least ten keys given to commenters. You have to be on the development team, it's one post per month, and games behind an NDA aren't allowed.
• r/DestroyMyGame offers blunt feedback by design, but every submission must be a video, so it suits first impressions rather than recruitment.
• r/playtesters exists specifically for designers looking for playtesters.

Genre subreddits are often the better fit, because the people there already have the taste you're building for.

Listing Sites

Listing sites like Alpha Beta Gamer or itch.io are also great places to reach players who enjoy testing unfinished games.

Recruited panels

When you need players matching a player profile your current channels like Discord can't supply, or if you just want completely fresh eyes on your game, recruiting from an external pool is how you get them. We've written separately about why general recruitment often produces the sharpest insight.

Your Playtest invite

What you write in your playtest invite is an announcement people read once, if at all, before they click Play, and it does most of its work when you're actively pointing a Discord post or a subreddit thread at the playtest. Keep the ask narrow and clear.

Steam emails players when you admit them, but sends nothing when a build becomes playable, so an announcement is what actually tells people the test is live.

Say what to play, roughly how long for, what you'd like feedback on, where to send it, and what happens next. Don't over explain the thing you're testing so you get unbiased perspectives but be clear on what known issues there are if it would negatively affect any feedback or play. Ideally remove obstructions from the playtest build.

Our guide to creating effective test briefs and tasks goes further on when a short brief beats step-by-step tasks.

Then close the test properly. Set the build to Not Playable while you patch, say clearly when feedback closes, and post what you changed as a result. That last one is what makes the same people turn up for future playtests knowing they may have had an impact on the game.

Capture what happens

Steam records nothing. The playtest gives you a build and a player, and whatever you don't capture yourself is lost.

Community channels capture reaction while it's fresh and cheaply, including things you'd never have thought to ask about. They're self-selected though, so you hear from the players who like posting, and the first opinion posted tends to anchor the rest.

Surveys give you structure and comparability: the same five-ten questions across twenty players let you count, rank and spot the outlier. Their weakness is memory, so keep the survey short, send it while the session is fresh, and always ask where they stopped and why.

In-app feedback closes some of that gap at the cost of engineering time, catching things as they happen and tagging where the player was.

Turn feedback into design decisions

Everything a Steam playtest gives you is self-reported, so read it as evidence of how the game felt, and keep the report separate from what you think it means. Seven of twenty players wrote that they couldn't find the quest-giver in the village is a report. The quest-giver isn't visible enough is an interpretation, and add a marker is a solution. The report is reliable where the other two are arguments.

Then count frequency and judge severity separately. A confusion that eight of twenty players mention in passing is a polish item. A confusion that two players say ended their session is a blocker.

Requests are usually symptoms. When a player asks for a fast-travel system, the useful information is that traversal became tedious somewhere specific. Shipping the request leaves the tedium in place.

Every finding then gets an outcome: fix it now, watch it next test, or accept it deliberately. Write the reasoning down either way, so the same argument doesn't come back in three months.

Before you open sign-ups

• Two or three written objectives, plus a written list of what you're not testing
• Route in chosen deliberately: limited signup for most tests, keys when you need named testers
• Nothing in the build you can't afford to have seen publicly
• Review lead time accounted for in the schedule
• A survey link and a feedback channel live before the first player is admitted
• One named person who reads the feedback

How to get more actionable insight from your Steam playtests

Think of the player who spends ninety seconds hunting for the map, then writes "navigation was fine" because they eventually found it.

Go Testify records the play. Players run a recorder and play at home on their own hardware, and you get back:

• Speak-aloud audio, so you hear the reasoning at the moment of confusion, not a summary written an hour later.
• Full gameplay capture, so you can watch those ninety seconds and see what they tried first.
• Automated analysis across every recording, transcript and survey answer, surfacing the themes without someone watching every session end to end.
• A setup that's easy on testers: nothing to schedule, no call to join, no cameras.

You can record sessions with your own community, including players admitted from your Steam Playtest, for free.

For the step-by-step of wiring a Go Testify test into a Steam Playtest, including the setup order and how to close the test down cleanly afterwards, see Steam Playtest: how to use it with Go Testify.