Methodology

Patch Ledger

How big is this game, how big was the patch, and how much of the game does every update make me download again?

The ledger reads the depot manifests the SteamPeaks account can see. For every build on a game’s public branch, the depot worker writes one row to the size history: install bytes as the default install, the uncompressed size of what a Windows player who owns the base game downloads in English (the larger of macOS and Linux when a game has no Windows depot); fresh-download bytes as the compressed chunk lengths of those depots; the change against the previous row; and a split beside it with each system’s default install, every depot together, and the depots summed apart from the default because they sit behind a DLC app or a key the account is refused, carry another language, or are low-violence variants.

A patch’s download is not the change in install size. For each depot that changed, the worker diffs the old and new manifests: files added, removed and changed (same path, different hash or size); download bytes as the compressed length of the chunks the new manifest has and the old one does not, which is what Steam sends a player who already has the game; and rewritten bytes as the uncompressed size of the added and changed files, what the patcher writes to disk. Efficiency is download divided by rewritten, worded “downloaded X to change Y”.

Largest installs ranks each game’s newest row by install bytes. Growing fastest compares that row with the newest row at least 90 days old; a game measured for less than 90 days is compared with its first row and the row says so. Biggest patches this week sums download bytes over the depots of every build from the last seven days that had an old manifest to diff against. Worst updaters takes a game’s last ten public builds that have both a patch download and a fresh-download figure, divides each patch’s download by that build’s fresh download (both compressed bytes), and reports the median; three builds are the minimum.

Only games the account owns can be measured, so a game’s history starts on the day the account gained it and the block says so. Rows whose depots are not all on file are kept and marked incomplete with the missing depots named. Install bytes are uncompressed file sizes and download bytes are compressed chunk lengths; the two are labelled and never added together.

The Silent Patch

What changed in the updates nobody wrote a note for?

A build is silent when it sits on a branch that needs no password, is at least 24 hours old, and has neither a patch note (the build’s own patchnote_id or a note that names the build) nor an app event of kind update, major update or release within 24 hours either side of the build time. Until the 24 hours are up the build is pending, not silent, and a note that arrives later moves it to noted; nothing is ever moved the other way.

What a silent build changed is read from the depot manifests the SteamPeaks account can see: for every depot the build touched, the old and new manifests are diffed into files added, removed and changed, the bytes in each class, the compressed bytes a player downloads and the uncompressed bytes the patcher rewrites. A build whose manifests are not on file is still listed as silent, with the diff marked pending and no signals.

Signals are path rules applied to the added and the removed file sets, so a technology counts as added only when the new manifest matches and the old one does not: anti-cheat, launcher, online-service and telemetry markers name a technology through its slug; language rules fire when a whole language folder or file set appears or disappears; an engine change compares the detector’s verdict on both sides; and an executable that grew or shrank by more than 40 percent with nothing else changing is reported as a size change, never as a DRM product by name.

The feed shows the public branch by default and every unprotected branch on request. The file list on a build’s page is the top 200 changes by absolute size difference across its depots, capped at 5,000 rows per depot in storage; the CSV carries every stored row. Only games the account owns can be diffed, and the pages say so.

Shared DNA

Which games ship the same files?

Every file of every manifest the SteamPeaks account has read is indexed by its SHA-1 and size. Two games share a file when the latest public manifest of a depot of each holds a file with the same hash and the same size, after dropping engine and runtime files by path (engine binaries, redistributables, steam_api libraries, UnityPlayer, .NET and Mono runtimes, common SDK libraries) and every file under 64 KB, so that a shared engine never reads as shared content.

A pair is kept when it shares at least 20 files or 50 MB. Each side’s share is the shared bytes as a fraction of that game’s content bytes after the same stoplist. The verdict names the overlap: near-identical when both shares are at or above 80 percent, contains when one is, shared assets otherwise. A pair whose games are parent and child, demo, DLC or tool of one another is marked related and kept apart from the rest.

The catalogue groups the pairs into clusters (two games belong together when a kept pair links them, directly or through a third game) and ranks the clusters by the largest shared byte count inside them. Publishers come from the store page of each game; the “different publishers only” filter keeps the pairs whose two games list no publisher in common.

Only games the account owns are in the index, and the page says how many. The verdict describes the files, not the reason they are shared: asset packs, shared engines with custom names, ports, re-releases and template games all look alike here, and none of this wording implies wrongdoing.

Requirements Sheet

What does this game require beyond Steam: anti-cheat, DRM, accounts, launchers, online services, and since when?

The sheet lists what a game asks of the player beyond Steam itself: an anti-cheat product, a DRM product, a third-party account, a launcher, and online services. Anti-cheat, launchers and online services come from the technologies the depot worker recognises in a game's files (app_technologies); DRM and account rows come from the two notices Steam prints on the store page (drm_notice and ext_user_account_notice), parsed into a product or service name, an activation limit where the notice states one, and whether the notice says linking to the Steam account is supported. The store's own facts (Single-player, Online PvP, Online Co-op and the like) are listed from the store categories so the sheet is read in context.

Kernel-level is a property of the product, never a judgement about the game. The table in lib/signals/requirements.ts records, for each anti-cheat product, whether it installs a kernel-mode driver on Windows, with a link to the vendor's own documentation or to PC Gaming Wiki as the source: Easy Anti-Cheat, BattlEye, Vanguard, nProtect GameGuard, XIGNCODE3, EA Javelin, PunkBuster, Denuvo Anti-Cheat, Anti-Cheat Expert and RICOCHET are kernel-level; Valve Anti-Cheat runs in user mode. A product not in the table is shown by name with no kernel claim.

Dates come from three ledgers. A store notice is dated by the catalogue event or the store-history row that first recorded it, and a later event or row is shown as a change; a technology found in the files is dated by the build in which the build-diff engine first saw it, or by the day the depot worker read the manifest when no build history exists. A notice with no dated change was already on the page when store polling began on 3 September 2026, and the sheet says so rather than inventing an earlier date.

Absence of a row means not detected, never none. The depot worker can only read the files of games the account owns, so a game without a technology row may simply not have been read yet; the block says whether its manifests have been fetched. Store notices are Steam's own text: a store page that carries no DRM or account notice is reported as having no notice, and a notice that says there is no third-party DRM is repeated in those words rather than turned into a DRM row.

Can the Audience Run It

What share of Steam machines meet the minimum and recommended specs?

The store page's minimum and recommended requirements are parsed into an operating system, a processor, one or more graphics cards, RAM, video memory, storage and a DirectX version. Each graphics card named is matched to the GPU tier table (gpu_tiers), first by an exact alias and then by its normalised name; when the store lists alternatives ("GTX 1060 or RX 580") the lowest-scoring match is the bar, since either card is enough.

The share of machines that meet a bar is the sum of the survey shares of every graphics card whose tier score is at or above the matched card's score, taken from Valve's Steam Hardware & Software Survey for the month shown. RAM is compared the same way against the survey's System RAM category. Coverage is the share of the survey's own graphics-card list that the tier table maps, so an unmapped tail is visible rather than silently counted as failing.

The tier table is the only judgement in the signal: a relative performance score per card (100 = GeForce GTX 1060 6 GB) with its video memory, launch year and alias spellings, kept by hand and published so anyone can check a match. Everything else is arithmetic over the survey. A card the table does not know is reported as not recognised, with the store's own text, and the game gets no share for that side.

The survey is opt-in and skews toward recent hardware and toward players who accept the prompt, so every share is an estimate of the surveyed population, not of Steam's users, and the month is stated beside every figure. Valve publishes only the current month; SteamPeaks keeps every month from September 2026 on, so a game's share can be read against the survey that was current when it launched.

Deck verdict changes

What gained or lost Steam Deck Verified, and which build shipped just before?

Steam Deck compatibility has four categories, and the feed uses Valve's own words for them: Unknown, Unsupported, Playable and Verified. A change is recorded when the category in the PICS field common.steam_deck_compatibility.category or in the store's compatibility report differs from the last one seen; the ledger job writes it as a catalogue event with the old and new category, the time, and which of the two sources reported it.

Each change is joined to the newest build on the public branch in the seven days before it, because a verdict usually follows a submission after an update. The build is shown with its patch note when one is linked to it; a change with no build in that window shows none, and no build is ever inferred.

The ledger begins on 3 September 2026, when store and PICS polling began; verdicts from before that date are not claimed. While the ledger job has not yet written deck rows, the page reads the store poller's own change history for the same field and says so in its stamp.

Last Chance

What is leaving Steam, what has left, and will it still work?

Announced closures are entered by hand and always carry a link to the announcement. A job used to read them out of each game's own Steam news posts by matching sentences; an audit of every row it had produced found four of thirty were real closures, the rest being maintenance windows, single regions or clusters closing, server merges, and patch notes that happened to contain the words. It was retired rather than tuned, because a page that says a game is ending has to be right.

A store page counts as removed only after two polls 24 hours apart both fail, and a game counts as unavailable everywhere only when every storefront we poll has answered that it is not sold for a full day; both are written to the catalogue ledger by the analytics job, so nothing here is called removed on a single failed request.

The last known price is the last amount recorded in price history before the removal, in the visitor's currency where that sheet has one and in US dollars otherwise, labelled with its currency either way.

Playable after is read from the store's own categories: yes when Single-player is listed and no online mode is, no when only online modes are listed, partly when both are, unknown when neither is; a detected online service SDK is named beside the verdict. It is a reading of the store page, not a promise about the game.

Sold Where

Where can this game not be bought?

Every app with a price is polled on forty storefronts, one per currency Steam sells in, through the country the currency table names. A storefront that answers that the app is not for sale marks the pair as not sold; the answer is Steam's own, and nothing is inferred from a missing price or a slow response.

The date a pair became unavailable is the moment the answer flipped between two polls. Pairs that were already unavailable when polling began are dated to that first poll and say so, because no earlier claim can be made.

The overview counts, per currency, the games with a US price that the storefront withholds, and the share of the 1,000 most reviewed games it withholds; the publishers board counts game-and-region pairs, so a publisher withholding one game from thirty regions ranks beside one withholding thirty games from one.

A row older than eight days is shown with its last checked date rather than as a current fact, and the regional US-dollar sheets (CIS, Latin America and Türkiye, South Asia) are storefronts like any other here even though no visitor holds them as a currency.

Delay Ledger

Which release dates moved, by how much, and how quietly?

Every store poll records the release text Steam prints for an app, and a change to that text becomes one row of the ledger with the old wording and the new wording exactly as the store printed them. Each side is read for its precision: a day, a month, a quarter or a season, a bare year, a placeholder such as "Coming soon" or "To be announced", or nothing we could read.

When both sides are days the slip is the difference in days, signed: positive is a delay, negative a pull-in. When both sides are windows (months, quarters, years) and the new window sits inside the old one the change is called narrowed, the reverse is loosened, and otherwise the slip is the distance between the middles of the two windows in months. A date replaced by a placeholder is a date withdrawn; a placeholder replaced by a date is a date set.

A change is marked announced when the app's own Steam news feed carries an event within seven days on either side whose title or excerpt mentions a delay, a postponement, a new release date or a move; quiet changes carry no such mark, which is the point of the ledger.

The ledger starts on 3 September 2026, the day store polling began, so no earlier change is shown or counted. Rows come from the catalogue_events ledger where the analytics job has processed them and from the store history directly where it has not, so nothing waits on the job.

Early Access Promise Clock

How long did they say Early Access would take, and how long has it been?

A game is in Early Access when the Steam store lists Early Access among its genres; a game that lists it but still says coming soon has not started its clock and is counted separately. The clock starts on the day the ledger recorded the game entering Early Access, or, for a game that launched straight into it, on the release date the store prints.

The promise is the developer's own answer to the store's question "Approximately how long will this game be in Early Access?", kept word for word and read into a range of months: "6 to 12 months" is a range, "about a year" a single figure, "until Q3 2026" a deadline counted from the start of Early Access, and "as long as it takes" is open. Only ranges and single figures are compared with the clock; open answers are listed as open, and answers the parser could not read are shown verbatim with a note saying so.

A game is overdue when the months elapsed exceed the high end of its promise, and on the clock otherwise; the ratio shown is elapsed time over the promised maximum. A graduated game is one the ledger saw leave Early Access, and its promise is called kept when it left within the promised maximum.

The statistics by launch year count the games whose clock started in that year: how many are still in Early Access, how many graduated, the median time in Early Access so far, the share whose promise has been read, and the share of parsed promises that are overdue. Graduations are recorded from 3 September 2026, when store polling began, so the graduation share is honest only for games that entered after that date.

Localization Watch

Which games gained or lost my language, and where are players reviewing in a language the game does not speak?

Each game's language list comes from its store page and from the PICS supported_languages block: for every language, whether the interface, full audio and subtitles are supported. The poller keeps the parsed list; where it has not reached a game yet the store's own string is read instead.

Coverage is the share of the 1,000 most reviewed games on Steam (games only, ranked by their total review count) whose list includes the language. Games with no language list on file are left out of the denominator, and the page says how many.

Untranslated demand uses Steam's own per-language review totals. A game counts for a language when at least 200 of its reviews were written in that language and its list carries no interface for it. The figure is a count of reviews, never of players.

Additions and removals are rows of the store-field ledger, which records a change the first time a store page lists a language it did not list before, or stops listing one. The ledger began on 3 September 2026; nothing earlier is claimed.

The audio filter counts only full audio as support, in every tab. The tag filter keeps the games that carry the Steam tag.

Complete Edition

What does it cost to own everything, in my currency, and how fast is that growing?

A game's complete price is its own current price plus the current price of every DLC its store page lists, on one currency sheet, exactly as Steam quotes them today. Nothing is converted: a visitor in Poland sees the złoty sheet, and a game Steam does not price there is left off the list rather than shown in dollars under a złoty sign.

The DLC count is every app the store lists under the game's DLC section whose type is DLC (or is not known yet); the priced count is how many of those have a price on the sheet. A DLC that is free, not sold in the region or not polled yet is still counted, and the total says "of N priced" so a low figure is never read as a cheap edition. A game none of whose DLC is priced on the sheet has no complete price yet and is left off the list, and the page says how many games that is. The DLC share is the DLC total over the complete price.

"DLC added in the last year" counts the DLC apps whose Steam release date falls in the last 365 days, read from the catalogue's parent link. Discounts are included on both sides, so a complete price moves with every sale; the daily row the job writes to ClickHouse keeps that history and draws the chart on each game's page.

"Cheapest way to own" lists the Steam packages that contain the game together with some of its DLC, from the package catalogue, so a buyer can see whether a bundle covers the set; packages are not priced here, because Steam quotes package prices per region on the package page and nowhere the poller reads.

Fairness Ladder

How is my region priced against the dollar across the catalogue, and who moved this month?

For every game with a list price on the US sheet and on a region's sheet, the ratio is the local list price divided by the currency's units per dollar, divided by the US list price: 1.00 means the region pays the dollar price at today's rate, 1.24 a quarter more, 0.58 a little over half. List prices are used, before any discount, so a sale that runs everywhere at the same percentage moves nothing and a poll that caught one sheet mid-sale cannot invent a gap.

A region's rung is the median ratio over its 2,000 most reviewed games with both prices, with the quartiles beside it; the ladder is those medians sorted, dearest first. The regional US-dollar sheets Steam keeps for the CIS, Latin America and South Asia are rungs like any other, converted at one.

Rates come from the ECB reference list where it covers the currency and from an open daily dataset for the rest; every page names the source and the date. The dollar figure beside a local price is a comparison figure at that rate, marked ≈ as everywhere on the site, and never a price Steam charges.

Publisher rows are the median over a publisher's games in the universe and need at least 5 of them. "Moved this month" lists list-price changes in the currency over the last 30 days that moved a game's ratio by more than 10 points, measured against the US list price of today.

Valve publishes suggested regional prices; they are not used, shown or compared with here. Every figure on these pages is a price a storefront quoted, or a ratio of two of them.

The Count

How many people own this game, and how wrong is that answer?

Steam does not publish how many people own a game, so the figure is modelled: owners ≈ total reviews × k. The multiplier k is not one number; it is learned per cell of release-year band (2013 and earlier, 2014 to 2017, 2018 to 2020, 2021 and later) and US launch price tier (under $10, $10 to $30, $30 to $60, $60 and up), because a $5 game from 2015 and a $60 game from 2025 collect reviews at very different rates per copy sold.

The calibration source is the ledger of units publishers announced themselves: sentences such as "sold 2 million copies" read daily from each game's own Steam events, with the sentence and the link kept as evidence, plus hand-entered rows with a source URL. Each announcement gives one observation of k: the announced units divided by the reviews the game had on that date (from the review histogram, or today's total when the announcement is under 90 days old). Announcements that count every platform are kept in the ledger but left out of the fit; so are free games, whose reviews count players rather than sales, and observations under ×3 or over ×300 reviews per unit, which are misread sentences (an in-game currency, a DLC's copies, another product).

A cell with at least five observations uses its median k; a thinner cell falls back to its year band's median when the band has five; a band with fewer uses a prior written in the job in plain sight: 30 for games released from 2021, 40 for 2018 to 2020, 50 for 2014 to 2017 and 60 for 2013 and earlier, since older games gathered fewer reviews per owner. Confidence records which of the three was used: high when the cell or band holds twenty observations or more, medium from five, low when the prior stands in.

The band comes from the residuals of the ledger itself, log10 of announced ÷ estimated across every observation: low and high are the 10th and 90th percentiles applied to the mid, never wider than ×5 either way, so eight in ten calibration milestones fall inside a band drawn this way. Until ten observations exist the band is an allowance of ×2.5 each way.

Read the band, not the mid. "Between 1,200,000 and 3,400,000 owners" means the ledger cannot tell those apart; the mid is only the centre of the band. A game with fewer than 50 reviews is not estimated at all, a free game is not estimated because its reviews are not sales, and a game whose publisher has announced a figure shows that figure first and the estimate second. The calibration page shows the whole ledger, the residual histogram, the median absolute log error expressed as "typically within ×N", the share of milestones inside the band and the k of every cell, so the method can be checked rather than trusted.

Momentum

What is gaining followers fastest, and which Next Fest demos are actually being played?

Steam publishes one public interest figure for an unreleased game: the member count of its community hub, shown on the store page as followers. SteamPeaks samples it for every game whose store page says coming soon and for the most played games, and keeps every sample. Sampling began on 3 September 2026; nothing before that date is claimed.

For each game the hourly momentum job takes the newest sample and the samples nearest one, seven, fourteen and thirty days before it (within twelve hours for the one-day figure, within a day otherwise). The 1-day, 7-day and 30-day gains are the newest count minus those; velocity is the 7-day gain divided by seven; acceleration is the 7-day gain minus the gain over the seven days before it, so a game still climbing but more slowly reads as negative. Where the older sample does not exist the gain is missing, never zero, so a gap in the source shows as a gap.

The boards rank on the widest window the samples cover: the 7-day gain once a week of samples exists, the 1-day gain until then, and every board says which window it ranks on and the time of the newest sample each figure used. Climbing lists unreleased games by that gain; Accelerating needs two full weeks of samples and stays empty, saying so, until they exist; Most followed upcoming is a plain fact, the count on the store page today, with the gain beside it where one exists.

The Next Fest board ranks demos by their peak concurrent players over the fest window. A demo is an app of type demo whose parent is the game on the board; its players are sampled in the hourly ring. Between fests the last fest's board stays up, named and dated; when no fest has run since sampling began, the board shows the demos being played over the last 24 hours instead and says so.

Followers are not wishlists. Valve does not publish wishlist counts, and no follower-to-wishlist ratio is applied here; a follower count is shown as the fact it is, and a gain is a difference of two samples with their dates.

Hours, Honestly

How long do people actually play, how many quit inside the refund window, and how many reach the end?

Every review Steam shows carries two playtime figures: the hours the reviewer had when they wrote it, and their total hours at the moment the review was read. SteamPeaks keeps both for the reviews it samples per game, and the daily funnel job turns each game's sample into the median, the quartiles and the 90th percentile of total hours, the share of reviews written inside the first two hours (Steam's refund window), the share past a hundred hours, and eight buckets for the distribution chart. Statistics are written only from thirty sampled reviews; the sample count is written regardless, so a thin sample says how thin it is.

These are hours of people who reviewed, not of everyone who owns the game. Reviewers have usually played more than owners who never wrote a word, and the sample is of reviews, so a median of 40 hours means the median reviewer had 40 hours, not the median owner. The refund-window share is the most robust of the figures: a review written under two hours in is a decision made inside the window Steam gives for a refund, whatever happened after.

The finish funnel orders a game's achievements by their global unlock share, read daily from Steam's own achievement percentages, most common first. The finish step is the achievement whose name or description reads like the end of the game (beat the game, completed the story, final boss, credits, epilogue and their variants) with the lowest share among the matches; a game where nothing matches has a funnel but no finish step, and says so rather than guessing. The lowest share of all is "everything", the players who unlocked the rarest achievement.

Best value divides today's price on the visitor's own currency sheet, discounts included, by the median hours: the cost of an hour for the median reviewer. A game the visitor's sheet does not price is left off that tab rather than ranked in dollars, and free games are not ranked because there is nothing to divide.

The samples and the funnels are recomputed daily. Every figure on the page names its sample size and the day of the unlock shares it used.

Lifespan

How long do games like this hold their players, and where is this one on that curve?

For every game with at least six months of monthly average player counts (our own daily rollups plus the imported monthly archive, which reaches back to 2012), the launch level is the best of its first three months, and every later month is expressed as a share of that level.

Games are grouped into cohorts by their top Steam tag, price tier and launch-size band; a cohort needs at least 20 games, otherwise the game falls back to its tag alone, and then to all games. For each cohort and each month since launch the job keeps the 25th, 50th and 75th percentile share, which is the band drawn under a game's own line.

Months are counted from the launch month as month 0, and the launch month usually holds the launch spike, so most games are under half by month 1 or 2. Half-life is the first month a game spends under 50 percent of its launch level, counting from the month that set the level. The percentile says where a game sits among cohort games at the same age: holding better than 71 percent of survival games at month 18 means its share is above that of 71 percent of them; it is left blank where fewer than twenty cohort games have reached that age.

The projection takes the cohort's band for the next twelve months and scales it to the game's current share, so it is an estimate of what games like this usually do next, not a forecast of this game's decisions. It is drawn beyond the present as a band and labelled as an estimate; a game whose cohort has no curve twelve months past its age has none.

A revival is a month after the first year at more than 150 percent of the previous six-month median, at least a fifth of the launch level and never under a hundred players. The revivals board keeps games that launched at a hundred average players or more, so a multiple is a multiple of something. The curves are recomputed weekly.

Streamer Effect

Do streams move players here, and by how much?

For every game SteamPeaks samples on Twitch (the hundred most played games and every watched game, viewers and live channels every ten minutes), the viewer series and the player series over the last thirty days are put on the same ten-minute bins. Both are SteamPeaks' own samples; the viewer counts are Twitch's, credited on every block that shows them.

The correlation between viewers and players is measured at every lag from six hours before to six hours after, in ten-minute steps; a positive lag means players follow viewers. The lag with the strongest correlation is kept, with that correlation. At least a day of shared bins is needed for a correlation to be measured at all.

A viewer spike is a run of at least three bins (thirty minutes) above three times the trailing 24-hour median of viewers; spikes within two hours of each other count as one. Its lift is the mean players in the six hours after the spike began against the same six hours one week earlier, which removes the daily cycle; where no week-earlier data exists yet, the six hours before the spike stand in and the row says so. The lift is a modelled figure and is labelled an estimate; the baseline it was measured against is shown beside every lift.

The verdict is streamer-driven when the median lift over the spikes is above 15 percent and the correlation is above 0.5 at a positive lag; self-driven when the correlation is under 0.2; mixed otherwise; and insufficient with fewer than seven days of both series, which is where every game stands until the Twitch sampling is a week old. Viewers per player is the mean viewers divided by the mean players over the shared bins.

Correlation is not causation: a stream can follow a patch or a sale as easily as cause a crowd, and the numbers here say only how closely the two series move together. Recomputed daily.

Review Weather

What is under a review wave right now, who is writing it, and does it recover?

Valve's review histogram gives exact positive and negative counts per month across a game's life (per week for young games) and per day for the last thirty days. A bucket counts as a review wave when its positive share breaks from the game's own median bucket, judged against the median rather than the lifetime average so one bad month cannot hide the next, on unusual volume: at least 1.6 times the median bucket and a floor of reviews (25 for the daily series, 40 for the weekly or monthly one).

A negative wave is a bucket 15 points or more below the median share; a positive wave is 12 points or more above it on at least 2.5 times the usual volume. Neighbouring buckets of the same kind merge into one wave, and the six strongest per series are kept per game. This is the same detector the Reviews section of every game page runs; the daily job runs it over every game with a histogram.

For each wave the job adds what SteamPeaks' own review samples know about the people writing it: the language most of the wave's sampled reviews were written in and its share of the sample, and the median hours the writers had played when they wrote. Where the sampler has not reached the game those columns are empty and say so.

Recovery is the positive share returning within 5 points of the game's median within 60 days of the wave's first bucket; the job also records the first later bucket that was back within 5 points, so the page can say how many days it took, and whether any later bucket exists at all (a wave in the newest bucket is still open, not unrecovered). Recovery statistics are given by wave size, in reviews.

The detection is SteamPeaks' own. Valve marks some review periods as off-topic on the store and excludes them from the score, but exposes no such marker through any endpoint, so no wave here is called off-topic by Valve and the store's own summary may differ. Recomputed daily.

Best Time to Play

When is this game busiest, in my time zone?

For every game with hourly player rollups across at least 4 distinct weeks of the last 8, the weekly activity job writes the mean players per weekday and hour in UTC, Monday first, with the peak and the trough cells and their ratio. The rollups are SteamPeaks' own samples (a minute apart for the most played games, hourly for the rest), so the grid exists only for games in the sampling ring and only once four weeks have passed.

The grid is rendered on the server in UTC and never moves. In the browser, a small component reads the visitor's time zone and relabels the hour axis, the cell tooltips and the sentence above the grid; no value is shifted or interpolated, so a row is still a UTC day and the caption says where the visitor's day boundary falls in it. For a game with an online multiplayer category the sentence adds the typical count in the cell the visitor's clock is in.

A game without a profile says how many weeks of hourly rows it has and when the fourth week begins. Recomputed weekly.