16 Jul 2026 · 8 min read
Steam gives you real numbers on who watched your store page broadcast: maximum concurrent viewers, total viewers, average watch time, total watch time. The catch isn't accuracy, it's timing. If you run a broadcast for months, as most 24/7 setups do, most of that history is gone before you think to go looking for it.
Broadcast statistics sit on your own Steam account, not anywhere public. Log in as the account that owns the broadcast and open your broadcast history page. Valve documents the exact metrics it reports in its Broadcast Viewership Statistics doc: maximum concurrent viewers, total viewers, average watch time, and total watch time. That's the full set. There's no country breakdown, no wishlist correlation, no referrer data attached to it - four numbers, per session.
They split into two pairs. Maximum concurrent viewers and total viewers are both about reach: the first is a peak - how many people were watching at the single busiest moment - the second is cumulative. Total viewers is specifically total unique viewers: Valve counts a person once for the session even if they leave and come back, so it's not a raw count of page loads. That distinction changes how you should read the gap between the two numbers. A total-viewers figure close to your maximum-concurrent figure suggests most people arrived around the same time and stayed together. A total far higher than the peak suggests a steady trickle of different people passing through one at a time rather than a single crowd - the same total can describe two very different audiences. Average watch time and total watch time are about attention rather than headcount: average tells you how long a typical viewer stuck around, total is the sum of every viewer's time on the stream. Neither number tells you what people actually saw on screen or whether they clicked through to your page - Steam doesn't expose that. What you get is reach and duration, enough to tell whether a broadcast is being watched at all, not enough to tell you why.
Here's the limitation that matters most if you're running a broadcast continuously. Valve states it plainly: "We only show your broadcast data from the last 30 days." Anything older simply isn't there anymore. It doesn't archive to a downloadable file and it doesn't degrade into a summary - it disappears from the page.
For a broadcast that runs a week or two around a launch, this is a non-issue: the whole event fits inside the window with room to spare. For a 24/7 broadcast that runs for months, it means your December numbers are gone by February whether you looked at them or not. If a number matters to you - a spike around a sale, a comparison across two trailer cuts - screenshot or note it down the week it happens. Waiting for a quiet month to review a full quarter isn't an option Steam gives you.
This is where the window stops being an abstract inconvenience and turns into a concrete loss. A Next Fest broadcast that runs the standard 7 days is entirely gone from your history about five weeks after it ends. If you want to compare this year's Next Fest numbers against next year's - a genuinely useful comparison for a developer running the same store page through more than one fest - there is no later date at which you can go back and pull last year's figures. Steam doesn't keep them anywhere you can reach, not in an export, not in an account setting, nowhere. You either write down maximum concurrent viewers, total viewers, average watch time and total watch time before the window closes on that event, or you never have a baseline to compare the next one against.
The history page mixes two different row types, and they answer different questions. A Broadcast Session aggregates viewership across every upload session that belongs to it, capturing all unique viewers as long as no gap in the feed runs longer than 5 minutes. An Upload Session is narrower: one specific continuous stream, with its video resolution, start and stop times, duration, and a concurrent-viewer graph over time.
Read Broadcast Sessions when you want the big picture - total reach over a run. Read Upload Sessions when you want to know what happened in one specific window, like the hour a sale went live.
The fields on an Upload Session row are worth using individually rather than glancing past. The video resolution and the start and stop timestamps tell you exactly which broadcast window you're looking at - useful if you've swapped the loop video mid-month and need to know which cut was actually live during a given spike. The concurrent-viewer graph plotted over that same window shows shape, not just a peak number: a graph that sits flat for hours and spikes once looks different from one that climbs steadily, even when the maximum concurrent viewers figure is identical for both. Steam doesn't label that shape for you or explain it - reading it yourself is the one place on the whole stats page where you're doing more than copying down a number.
The 5-minute rule above is doing more work than it looks like. If your feed goes down and comes back within 5 minutes, Steam keeps counting it as the same Broadcast Session. Cross that 5-minute line and the next chunk of viewership starts a new Broadcast Session - your continuous run gets split into pieces in Steam's own numbers, even if to a viewer refreshing the page it looked like one long outage.
That's a real, if narrow, argument for a stream that restarts itself quickly rather than one that sits down for however long it takes someone to notice. It doesn't change how many people actually saw your page; it changes whether Steam's reporting treats it as one session or several. If your feed keeps dropping for longer than 5 minutes at a stretch, that's worth investigating on its own terms - see troubleshooting a Steam broadcast for the common causes.
One more thing shapes what shows up in your stats: Steam automatically turns on transcoding once an Upload Session passes 10 concurrent viewers, generating lower-resolution versions of the stream - 720p, 480p, and 360p - alongside the original. That's Steam distributing load, not something you configure. It's also a useful marker on its own: if a session lists multiple resolutions, you know it cleared 10 concurrent viewers at some point, which the aggregate numbers don't tell you as directly.
This only shows up on the Upload Session view, not on the Broadcast Session rollup, which is one more reason to check both row types rather than skimming the aggregate and moving on. A Broadcast Session that never crossed 10 concurrent viewers in any of its upload sessions never triggered transcoding at all, and that's fine - it just means the viewer-resolution detail won't be there to look at.
Two things are worth knowing before you judge your own numbers against some idea of what they should be, because a broadcast that loops a video isn't the same product as a person streaming live, and the stats can look thin for reasons that have nothing to do with the video itself.
Store broadcast latency is commonly reported by streamers as being in the neighborhood of 30 seconds - Valve doesn't publish an official latency figure for store broadcasts, so treat that as what users have observed, not a spec. In practice it means anyone watching is seeing your loop roughly half a minute behind real time. That's irrelevant for a pre-recorded loop with no chat to react to it, but it's worth knowing if you're ever tempted to treat the broadcast as a live feed responding to the moment - it isn't, and the stats won't behave like it either.
The bigger point is about how viewers arrive at all. A person streaming live builds an audience that shows up at a scheduled time because they were told to. A looping video on a store page has no schedule - every viewer who lands in your stats arrived because they were already on your store page for some other reason, browsing, searching, following a link, and the broadcast happened to be running while they were there. That's a passive audience you inherited from existing store traffic, not one you called together. It means average watch time and total viewers are best read as a byproduct of the traffic your page already gets, not as a channel that pulls in new traffic on its own. If your numbers look modest next to what you'd expect from a scheduled live stream with an announced start time, that's the honest reason why - not a discrepancy worth chasing.
An empty broadcast history is easy to misread as nobody watching. Valve's own FAQ makes a distinction worth knowing before you draw that conclusion: only Public broadcasts appear on the store page at all. A friends-only stream never shows up there in the first place, so it logs zero store viewers - not because nobody watched, but because nobody could have, since the store page never displayed it. If your visibility is set to anything other than Public, your stats will look identical to a broadcast nobody found, and nothing on the history page itself tells you which situation you're actually in.
Two more failure modes produce the same blank result, and per Valve's FAQ they're the most common ones: the broadcasting account isn't whitelisted for the game, or the Broadcast App ID is unset or wrong. Both stop the broadcast from ever appearing on the store page, which means both produce a broadcast history that looks exactly like a broadcast nobody watched - because Steam counted nothing, since nothing was ever shown. If you've just set a broadcast up and the numbers sit flat at zero, check visibility, whitelisting and the App ID before you conclude the loop itself isn't attracting anyone. This matters most right when it's easiest to get wrong: setting up a broadcast on a Coming Soon page before launch, when the account and App ID configuration are new and untested. We cover that setup separately in broadcasting before launch, on a Coming Soon page.
None of this changes what you upload or how you stream - it changes how you use the numbers Steam gives you. Put a recurring reminder on your calendar, roughly every three weeks, to open the broadcast history page and record whatever matters to you: total viewers for the period, average watch time, any Upload Session that had multiple resolutions. That's the whole workaround for a 30-day window - there isn't a more clever one available.
What you record depends on which row type you're looking at. For a Broadcast Session, note total viewers and average watch time for the whole run - that's your reach summary for the period. For any Upload Session that shows more than one video resolution, note the date and the resolution alongside it, since that's the only sign the session cleared the 10-concurrent-viewer transcoding threshold at some point, and it disappears along with everything else once 30 days pass. Neither number substitutes for the other. Skip one and you've halved what you actually have on hand once the window has moved past both.
Curious whether more viewers on your broadcast actually moves the needle on your store page? We looked at what Steam does and doesn't show you in broadcasts and wishlists. And if you'd rather not babysit a stream that might land in that 5-minute gap, see what a supervised broadcast costs.
Upload a video, paste your stream key, hit start. From $0.72/day.
Start streaming · $0.72/day