From raw reviews to structured incidents
ReviewBomb does not label every negative review period as an incident. The classification pipeline moves from raw Steam data through baseline comparison, velocity detection, severity scoring, cause tagging, and recovery tracking. This guide explains each stage.
Stage 1: baseline and velocity detection
The first step is establishing what "normal" looks like for each game. ReviewBomb calculates a per-game baseline from historical review velocity, score stability, and catalog position. When current movement exceeds that baseline by a meaningful margin, the system flags the game for investigation.
This stage is explained in detail in How ReviewBomb Detects Steam Review Surges. You can see the pipeline in action on live game pages such as Slay the Spire 2. The short version is: abnormal movement, not just large movement, triggers the pipeline.
Stage 2: severity tier assignment
Once abnormal movement is confirmed, the system assigns a severity tier:
- WARNING: statistically-anomalous velocity detected. Early-stage surges where the rate exceeds baseline by a meaningful margin.
- CRITICAL: sustained or high-magnitude surge. The incident has exceeded thresholds associated with actual community backlash or significant positive events.
- NUCLEAR: extreme review velocity characteristic of coordinated campaigns, major controversies, or viral community responses.
These tiers describe intensity relative to the game's baseline, not moral judgment. A nuclear-tier positive surge is possible when a delayed or troubled game finally ships a transformative patch.
Stage 3: direction and cause classification
Each incident receives a direction label: positive, negative, or mixed. Negative incidents are then classified by likely cause using a six-category system:
- Performance: low FPS, stuttering, crashes, hardware incompatibility
- Balance: nerfs, buffs, difficulty spikes, meta shifts
- Monetization: DLC timing, pay-to-win, price changes, microtransactions
- Technical: bugs, server downtime, save corruption, login issues
- Progression: grind increases, reward reductions, unlock gating
- Trust / Communication: broken promises, silence, misleading marketing, DRM disputes
The cause classification is based on patch timing, review language patterns, and external context. It is a confidence estimate, not a definitive label.
Stage 4: timeline construction
The incident page assembles a timeline from the first anomalous signal through peak velocity, score movement, and resolution or continuation. Timeline events include patch notes, developer posts, and related incidents that may have spilled over from connected titles.
Stage 5: recovery tracking
If the incident resolves, the system records resolution time, final score, and whether the recovery pattern matches known models. Unresolved incidents remain active and continue to accumulate timeline events.
For the recovery models, see Recovery Patterns Explained. For the methodology topic cluster, see Steam Review Analytics.
What happens next
Classification is not verdict. The pipeline surfaces abnormal events and organizes them into interpretable structures. The final interpretation still requires human judgment, context, and comparison against similar cases.
ReviewBomb verdict
ReviewBomb classifies incidents through baseline comparison, severity tiering, directional cause classification, timeline construction, and recovery tracking. Each stage adds structure to raw Steam data without replacing the need for interpretation.