Steam Playtest: what it's for, and when a demo is the better call

A Steam Playtest is for data. A demo is for wishlists. If you want to know whether your game works, run a Playtest. If you want people to want it, that's a demo, and the two are not interchangeable.

Valve's documentation explains every button. What it doesn't do is tell you which one to press, or warn you about the three or four settings that will eat an afternoon the first time you meet them. That's what this is for.

I've written this from the Steamworks documentation itself, and nothing else. Every quote below is Valve's own wording.

What a Steam Playtest actually is

A Playtest is a separate app: a "child" appID linked to your main game but distinct from it. The game stays unreleased. Nobody buys anything, and it costs neither you nor your customers a thing.

That separation is the whole feature. Valve's own summary of what it buys you is that a Playtest gathers data "without the stress of managing email lists and Steam keys or worrying about user reviews, or wishlists."

Valve built the Steam Playtest feature because developers were already improvising around the problem, in Valve's words with "a demo that was really just an Open Beta" or a free "Prologue" game. Studios wanted to test with live customers without putting their reviews and wishlist numbers at risk.

Here's what actually stays on the other side of that line:

• Reviews. A customer who has only taken part in the Playtest cannot review your real game. Not "their review goes somewhere else" — they can't write one.
• Wishlists. Joining or leaving your Playtest doesn't touch a customer's wishlist for your game.
• Playtime. Playtest hours have no effect on the Steam refund policy or a player's ability to refund the real game later.
• Achievements and trading cards. Playtest time doesn't unlock either on the main game.

Think about what the review line alone is worth. Hand fifty testers keys to your actual game, and three of them review a build that was never meant to be judged. Those reviews sit on your store page. A Playtest makes that impossible rather than unlikely.

A few properties worth having in your head before you start:

• There's no separate store page. The sign up option lives as a section on your game's page. Valve's reason for building it that way: "any search traffic, store recommendations, etc all funnel towards the real product for users to wishlist and follow."
• Access is gated. You let in as many or as few players as you want.
• You can switch it off, and switch it back on later.
• The tech is not reduced. A Playtest appID has the same Steamworks technical features as the main game — depots, builds, Steam Input, cloud saves. What's reduced is the store and community setup, not the toolbox. Some developers keep the Playtest app on afterwards as a testing ground for new tools or features, though Valve notes that probably only makes sense if the game is already free-to-play.

If you're still working out the order of the whole Steam process, the publishing guide puts this step in context.

Playtest, demo, or Next Fest?

The comparison I wanted when I first read about this:

And the rule that catches people out. Valve, in the Next Fest documentation:

Yes, as use of a Steam Playtest does not affect eligibility. However, we do not recommend having a Playtest live during Steam Next Fest, as this splits your players between the two builds instead of concentrating them in one spot. As a demo is required for Next Fest, we would recommend pushing all your users towards your demo during the event.

Two things in there. Running a Playtest doesn't disqualify you. And Next Fest requires a demo anyway, so during the festival the demo is the thing you point people at. If you're planning a Next Fest run, the Playtest goes before or after.

Setting one up

Condensed from Valve's documentation:

Signup type: limited or open

Valve calls this the signup type, and there are two.

Limited is the default: people request access, you grant access in batches as you have capacity. Open adds anyone who requests, automatically.

Two switches, four states, and the one that hides

This is the part I'd want someone to tell me in advance, because none of it looks like a setting when you're reading the documentation front to back.

Playable and signups are independent. Valve lists all four combinations as normal configurations: not playable and not accepting signups (the default, and also the end state), not playable but collecting signups (useful before the build exists, or between rounds), playable and collecting signups, and playable but closed to new people.

Steam emails players when you admit them. It does not email them when the build becomes playable. That gap is yours to fill, and Valve says so: use Steam Events and Announcements to tell people the Playtest is live. A devlog or event post is the obvious place.

The same goes for turning it off. Valve's wording is "Be thoughtful about this action!" — you'll frustrate people if you take the thing away without warning. If you do restart later, everyone who already had access keeps it.

Friend invites, and how fast they compound

This one is newer, experimental, and aimed at multiplayer games. When it's on, players with access can invite their friends, and those friends can invite theirs.

You set how many invites each player gets: one, two or three. You can pause new invites at any time. Two details decide whether this is useful or alarming:

• Players can only invite friends they've been friends with for at least 30 days. That's the built-in brake on invite farming.
• An invite that's already been sent stays active. Pausing stops new invites going out. It doesn't recall the ones in flight.

Valve's own arithmetic makes the shape of it clear: 5,000 players with three invites each, capped to people who had access as of today, is 15,000 potential invites. The documented way to keep it in hand is to watch the dashboard and pause, or to limit invite rights to players who joined by a cut-off date.

Valve's framing is that this is "best for games with robust server capacity", and that if you're worried about growth outrunning you, "this feature may not be for you". That's a recommendation, not a gate. Nothing stops you turning it on.

The keys route, and the number that decides it

You can distribute keys instead of opening signups. No public sign up option, and it works even if your store page isn't live yet. The question is which app those keys point at.

Between those two numbers sits the phrase "generally much larger quantities", which is all Valve will say about Playtest key volumes. There's no number, and I'm not going to invent one.

The 50,000 is worth being precise about, because I've seen it repeated as a hard cap. Valve names it twice, in two different senses. In the key section it's a threshold: once you want to request more than 50,000 keys for your Playtest, "your playtest is effectively an open beta and you should feel comfortable opening signups on your Steam store page". In the section on confidential playtests it reads as a ceiling: running your test through a normal playtest app "will enable you to request up to 50,000 keys". Both sentences are on the same page. So the honest version is neither "the limit is 50,000" nor "there's no limit" — it's the number at which Valve stops asking how many keys you need and starts asking why you aren't just opening signups.

Either way, Valve looks at each key request case by case and reserves the right to say no.

Three rules that aren't optional:

Playtest keys are Standard Release keys only. You cannot request Release State Override (beta) keys for a Playtest app. A key activated before the Playtest is set to Playable simply won't run anything yet.

A redeemed key isn't revoked when you set the Playtest to "Not Playable". Once someone has it, they have it.

You cannot charge for Playtest access. Not directly, not by selling keys, not by bundling them into anything paid, and not through in-game transactions either. If you're ready to take money for a work-in-progress build, that's Early Access.

So when do you use release override keys instead?

Valve answers this directly, and the sentence inverts what most write-ups assume:

While Steam Playtest is the preferred method of enabling closed betas on Steam, release override keys are available if you want to manage your playtest off your main game's App ID and have things like NDAs in place.

Playtest is the default. Keys on the main app are the exception, for when you need NDAs. The Testing On Steam documentation says the same thing from the other direction: requesting keys for the Playtest app is "now the preferred method of running beta testing for your game if you need more than small group of testers".

Most of the advice I've read has this backwards, treating keys as the real way to run a beta and Playtest as the lightweight option.

If you do go the release override keys route on your main app, Valve's recommended process:

You can also give different groups different builds — testers on one branch, press on another — and branches can be password protected.

Confidential playtests, honestly

If your game isn't announced yet, Valve's position is blunt, and I think they're right:

Even when configured properly, a confidential playtest will only ever be as confidential as your "least confidential" playtester.

Leaked screenshots or video, they add, "could potentially spread around the internet in moments". Their actual recommendation is to announce the game first, then test. That's the boring advice and it's the correct advice.

If you're doing a friends-and-family alpha anyway, the things nobody tells you:

• There are two documented routes, not one. The most secure is Release Override keys on the unreleased base app. The other is the Playtest app with keys, set to Playable, with store visibility Hidden. Both need you to build your own registration.
• There's no NDA. Accepting a Steam key binds nobody to anything. If you want one, that's your own system, before the key goes out.
• Third-party apps announce for you. Plenty of testers run tools that surface whatever their Steam client is doing. Valve notes that some of them actively prompt: "We don't recognize this game, can you tell us more about it?"
• Use a codename, and rename before the Coming Soon page goes up.
• The 2,500 cap applies here too, and Valve draws the conclusion for you: past that, "the probability of a leak is increasing to the point where you're likely 'announcing' your product anyway". Their suggested fix is to announce, then run a normal playtest, which opens the door to up to 50,000 keys.

Resetting: the button with no undo

If you want a second round with a completely fresh group, you can reset the Playtest. It removes every participant, and Valve is explicit that it is not reversible.

Six things have to be true before it will let you:

And what a reset actually does, which is more than "clears the list":

• All product keys for the Playtest are disabled, including keys nobody has activated yet.
• Pending friend invites are archived.
• Participants and everyone waiting for access are removed, and players with recent playtime get an email telling them this phase has concluded.

If you've handed out a batch of keys for round two before resetting round one, that's the sentence that costs you the batch.

Two things that will waste an afternoon

Both are in the documentation, both are easy to miss, and both look like your build is broken when it isn't.

Collecting the feedback is your job

Valve builds the room. It doesn't hand you a way to hear what happened in it. Collecting feedback from players is explicitly left to the developer, and that's worth planning before you let anyone in, not after.

The pattern Valve says it sees most often: a big feedback button right on the main menu, pointing wherever you want to collect and manage responses. A Steam forum, your Discord, bug tracking software, your own site. Valve doesn't push one of them.

Two things make the difference between a trickle and something you can act on:

• Tell players what you're actually after. Valve's own suggestion is to engage directly with your audience and let them know what kind of feedback you want and where best to share it. "Let us know what you think" gets you opinions on the main menu. A specific ask gets you the gameplay data you were missing.
• Put the link where they'll see it. You can provide links to your preferred feedback or communication system directly in a community announcement, which is the same channel you're already using to tell people the build is playable.

What a Playtest won't do

A Playtest will not get you wishlists.

It isn't designed to. There's no separate store page to convert on, the audience is capped at whoever you let in, and the whole architecture exists to keep the test away from your game's public numbers. That's the design, not a shortfall.

I can't tell you what a Playtest converts, either, and neither can anyone else honestly: Valve publishes no signup or conversion figures for it. What Valve does say is qualitative — search traffic and store recommendations point at the real product, not the test.

What you get instead is the thing that's genuinely hard to buy: people playing your unfinished game, at home, on their own hardware, with nobody watching. Where they quit. What they misunderstood. Which system nobody touched.

If you want visibility, that's a demo, ideally pointed at Next Fest. If you want to know whether the game works, that's this. Don't run them at the same time, and don't expect either one to do the other's job.

FAQ