A Steam Playtest is free, runs on a separate child appID attached to your main game, and needs only a live store page plus a set of capsule assets to pass Valve’s lightweight review. Playtest activity touches nothing that matters commercially: testers cannot review your game, their hours do not count against refund eligibility, and joining or leaving the playtest leaves wishlists untouched.
That is the short answer to “should I use it.” The rest of this post is the operational half: the Steamworks setup flow (checked against the official Playtest documentation on July 2), invite waves versus open signup, what to instrument before wave one, and the rules on what you may ask testers to do. At the end: how to tell the playtest has done its job and a demo should replace it.
What a Steam Playtest is and what it does not touch
Mechanically, a playtest is a second application that Steam links to your main game. It has its own appID, its own builds and depots, and access to the same Steamworks features as the main game, but no store page of its own. The signup widget lives on your main game’s page, so every visitor the playtest attracts lands somewhere they can wishlist and follow the real product.
The separation is the whole point. Here is what stays clean:
| Concern | Effect of the playtest |
|---|---|
| Steam reviews | Testers cannot review the main game; the playtest app itself has no reviews |
| Wishlists | Unaffected by joining or leaving the playtest |
| Refund eligibility | Playtest hours never count against the 2-hour refund window on the later purchase |
| Achievements and trading cards | Not connected to the main game’s |
| Cost | Free for you and for testers; no additional app fee |
Two limits to know before you commit. First, a playtest is not confidential. Testers sign no NDA, and Valve says so plainly in the docs. Treat everything in the build as public the moment wave one goes out. If you need genuinely private testing, Steamworks offers up to 2,500 Release State Override keys on the base app instead (covered in the Testing on Steam documentation). Second, you cannot monetize it in any form: no charging for access, and no selling playtest keys or putting them in paid bundles. Valve enforces this one.
Enabling a playtest in Steamworks, step by step
The prerequisite is a main game store page. A Coming Soon page is enough; the signup button renders on it the same way it does on a released game’s page. (If you want to test before any public page exists, you can still distribute playtest access through Steam keys, but the on-page signup flow needs the page.)
From there the flow is:
- Create the playtest app. In your main game’s Steamworks page, go to the “Associated Packages, DLC & Demos” section and create the playtest. It inherits the link to your base game automatically. Pick the name carefully: the playtest name cannot be changed after release.
- Upload the required assets. The store review for a playtest is deliberately thin. Valve checks capsule images and icons, and that is roughly it. You still have to provide them, plus localized names if your main page is localized. Reuse your main game’s capsules with a “Playtest” tag baked in; our capsule size reference has the exact dimensions.
- Run the release process. Same buttons as a normal app, much faster review since there is no store page or pricing to check.
- Upload a build. Depots and builds work exactly like the main game: upload via SteamPipe, set the default branch live. Integrate whatever Steamworks features you need tested (cloud saves, Steam Input, multiplayer).
- Turn on signups. Under the main game’s Store Page > Special Settings, enable the playtest signup. The “Request Access” button now appears on your public page.
- Admit players. From the playtest app’s settings, follow “Manage Your Playtest” to grant access to groups from the signup pool, in batches you control.
- Deactivate when done. You can pause access, and you can restart a playtest later. A full reset of the signup pool, though, is irreversible, so do not clear it casually.
Budget a day for the whole thing if your Steamworks account is in good standing, most of it spent on asset exports and build upload rather than the forms.
Set the playtest live but leave signups off until your announcement is ready. The moment the button appears, people start clicking it, and you want the signup spike to coincide with something you can measure.
Invite waves vs open signup
Steam gives you four ways to move people from “interested” to “playing,” and they solve different problems:
| Access method | How it works | Best for |
|---|---|---|
| Limited signup (default) | Players request access; you admit batches, selected randomly by Steam | Controlled waves, capacity-limited multiplayer tests |
| Open signup | Everyone who requests access gets it instantly | Stress tests, pre-Next-Fest buzz, late-stage polish feedback |
| Steam keys | Request playtest keys (the docs allow up to 50,000) and distribute them yourself | Targeted testers, press, communities off Steam, pages not yet public |
| Friend invites | Each admitted tester can invite 1-3 friends who have been on their friends list for 30+ days | Organic growth of a trusted pool, co-op games |
The wave pattern I would actually run: admit a first wave of 25-50 players, not thousands. The first wave’s job is to find the problems that embarrass you: the crash on AMD cards, the save file that never writes. Small waves mean you can hotfix before most of your signup pool has formed a first impression. Wave two at a few hundred validates the fixes and starts producing real funnel data. Only then open the gates if you want volume. That sizing is practitioner convention, not a Valve rule - the platform is happy to let you admit 10,000 people on day one.
Open signup earns its keep in one specific window: the weeks before a big visibility moment. Running an open playtest ahead of Steam Next Fest lets you battle-test the exact build that will become your demo, while the signup button itself gives your Coming Soon page a call to action stronger than “wishlist and wait.”
What to instrument in the build before wave one
A playtest without telemetry is a rumor mill. Before the first invite goes out, make sure the build reports:
- Session length and session count per tester. The single most honest signal. Testers who say “loved it” but played 11 minutes once are telling you something with their feet.
- Quit points. Log the level, menu, or encounter active when the process exits. Clusters are your churn map.
- Tutorial and first-hour funnel. Percentage of testers reaching each early milestone. If 40% never finish the tutorial, no later feedback matters yet.
- Crash and error reporting. Automated, with hardware info attached. Testers report maybe a tenth of the crashes they hit.
- A survey trigger. An in-game button or end-of-session prompt that opens your feedback form with the tester’s anonymous ID pre-filled, so you can join survey answers to behavior.
You do not need a custom analytics stack; a spreadsheet-backed endpoint is fine at playtest scale. What you need is the joins: this tester, this hardware, this much playtime, this survey answer. Feedback without the playtime column attached gets misread constantly, because the loudest voices in any playtest are the 20-hour superfans, and they are the least representative people in your pool.
Collecting feedback: in-game surveys vs Discord
Run both, but know what each is for.
| Channel | Strength | Weakness |
|---|---|---|
| In-game survey | High response rate at the moment of play; joins to telemetry; reaches quiet testers | Shallow; nobody types paragraphs into a game overlay |
| Discord | Depth, follow-up questions, clips and screenshots, repro steps for bugs | Loud minority; survivorship bias; the testers who bounced in 15 minutes are not there |
| Steam community hub (playtest apps get one) | Zero-friction for testers already on Steam | Low traffic at playtest scale; still worth watching |
The survey question that earns its slot is Chris Zukowski’s favorite: “On a scale of 0-10, how likely are you to recommend this game to a friend?” followed by a free-text “why.” As he lays out in his playtest survey writeup, people are polite when you ask if they liked something, and much more honest about whether they would stake their own reputation on it. Score it NPS-style: promoters (9-10) minus detractors (0-6), ignore the 7s and 8s. Word of mouth comes from 9s and 10s only.
A negative score on your first wave is normal and useful. The number itself matters less than the trajectory across waves: if wave three scores below wave one after two rounds of fixes, your changes are not landing, and that is worth knowing before you spend a Next Fest slot on it.
For Discord, one structural tip: make a private channel per wave, or at least a pinned template (“what did you play, how long, what made you stop”). Unstructured feedback channels converge on feature requests within 48 hours, and feature requests are the least useful playtest output there is.
What you may and may not ask playtesters
This section exists because the rules are asymmetric and people get them backwards.
Wishlist asks: allowed, and you should. The playtest signup lives on your store page precisely so that traffic converts. An end-of-session screen saying “enjoyed the test? Wishlist the full game” is standard practice and violates nothing. Playtests are, among other things, a wishlist generation tool, and Valve built the feature so that the funnel points at your real page.
Review asks: mostly moot, with one trap. Playtesters cannot review your main game at all. They do not own it, and the playtest app has no review section. So there is nothing to ask for during the test. The trap comes later: when those same testers buy the game at launch, you may remind players generally that reviews help, but you may not offer rewards for reviews, gate content behind them, or ask specifically for positive ones. The Steamworks review documentation treats all of those as manipulation, and the penalty is a warning banner on your store page or worse.
Money: never. You cannot charge for access, and you cannot sell playtest keys or put them in paid bundles. This is the brightest line in the playtest rules.
NDAs: not enforceable through Steam. You can ask testers to keep things quiet as a courtesy. Steam gives you no mechanism to require it, so assume screenshots and clips will leak, and only ship content you can live with in public.
Graduating from playtest to demo
A playtest is scaffolding. The decision of when to take it down comes down to what question you are still answering. If you are still fixing “is this fun and does it run,” stay in playtest: gated access, no review risk, cheap iteration. Once the build is stable and the first hour reliably lands, the question becomes “does this convert strangers,” and that is a demo’s job: public, and a prerequisite for Next Fest. The full decision framework is in our playtest vs demo comparison, but the one-line version: playtests answer development questions, demos answer marketing questions.
Practical handoff sequence:
- Freeze the playtest build that scored best and cut the demo from it, trimmed to a strong 30-90 minutes. Content sizing is covered in the demo best practices guide.
- Deactivate playtest signups before the demo goes live, so your page presents one call to action instead of two competing buttons.
- Keep the playtest app dormant rather than deleting it. You can reactivate it later for a beta branch of post-launch content, and reusing the appID beats rebuilding.
- Message your tester pool. They opted in to your game once already; they are the warmest launch audience you will ever have. Tell them the demo is out and where the release date announcement will happen.
Playtest run checklist
Print this, run it top to bottom:
- Store page live (Coming Soon is fine) and reviewed against the store page checklist tool
- Playtest app created under Associated Packages, name final, capsules and icons uploaded
- Build uploaded, default branch set, crash reporting and session telemetry confirmed working in a clean install
- Survey wired into the build, NPS question plus free-text “why,” tester ID attached
- Signups enabled; announcement posted the same day
- Wave 1: 25-50 testers, watch crashes and quit points for 3-5 days, hotfix
- Wave 2: a few hundred, validate fixes, read the funnel
- Wave 3 or open signup: volume, stress testing, wishlist call to action on session end
- NPS trending up across waves before you cut the demo build
- Signups deactivated at demo launch; tester pool emailed or pinged on Discord
Before you flip signups on, run your page through the free Steam Page Analyzer. The playtest button inherits whatever traffic your page earns, and a weak capsule or tag set caps your signup pool before the first wave ever goes out.