🎯 Goal: define indicators of a successful game, test whether game features go with them, and build a model that predicts success from what is known at launch. 📄 Data: Steam Games Dataset (Kaggle)

⭐ Summary

Numbers are from the run with default parameters. Section 8 and the appendix findings recompute them.

🛠️ How the notebook is built

📄 games.csv → 🐼 pandas (fix and clean) → 🗄️ DuckDB tables → 🧮 SQL (join, group, window) → 🐍 Python (statistics, models, charts) → 🖼️ PNG figures

Each tool does what it is best at. Every chart is also saved as a PNG in figures/ (on Kaggle: the Output tab, plus figures.zip at the end).

🧭 Contents

How to read it: 🧠 purple boxes explain why a step is done, 💡 blue boxes give the computed insight, ⚠️ orange boxes flag caveats. Cells starting with # Parameters hold the numbers you are most likely to change. SQL cells start with %%sql.

📦 1. Setup and loading

🧹 2. Cleaning and feature engineering

🧽 Cleaning steps

🗄️ 3. Data model and storage (DuckDB)

The cleaned data is stored as a small relational model in a DuckDB file (steam.duckdb). DuckDB runs inside Python, needs no server and reads pandas DataFrames directly.

games          one row per game            app_id (key), name, release_day, release_year, price,
                                           owners_low / high / mid, peak_ccu, total_reviews, positive_ratio,
                                           recommendations, median_playtime, developers, publishers
game_genres    one row per game and genre  app_id -> games, genre
game_tags      one row per game and tag    app_id -> games, tag
labels         one row per game            app_id -> games, success labels, in_study   (added in section 5)

Why separate genre and tag tables: a game has several genres. In pandas that is a list inside a cell; in SQL it is a bridge table, so "success rate per genre" becomes a plain join and GROUP BY. Why release_day: dates are stored as days since 1970, so "released at least a year earlier" is simple arithmetic in a window function (Appendix C).

💾 3.1 Storage optimisation

📦 3.2 Which file format?

🔍 4. Exploratory data analysis

Most Steam games get almost no attention, so every attention metric is extremely right-skewed. The first charts show how skewed, and the later ones check that the candidate success metrics agree with each other.

📈 4.1 Distributions

🏔️ 4.2 How concentrated is attention?

🔗 4.3 Do the candidate success metrics agree?

🏆 5. Defining success

Four definitions, each answering a different question:

Why "within its release year": a game from 2012 has had a decade to gather owners and reviews, a game from 2023 has not. A single global cutoff would label old games as successes and new games as failures regardless of quality.

Note on ties: owners come in wide buckets, so many games sit exactly on a year's cutoff and all of them count. That is why commercial_success_year covers more than 10% of games.

🧪 6. Testing indicators

Each launch-time feature is compared with one target at a time. Change TARGET and rerun the section to compare definitions.

Three tools, each answering a different question: 1. AUC ranks numeric features by how well they separate successful from other games (0.5 = no signal). 2. Success rate with a 95% interval shows the shape of the relationship and how much to trust it. 3. Lift (rate of a group divided by the overall rate) compares genres and tags on one scale: 1.0 = average.

All of these show association, not cause. A high-quality game may add languages because it sells.

🎯 6.1 Indicator scorecard

AUC per numeric launch-time feature for the chosen TARGET. Right of 0.5 = higher in successful games, left = lower. Appendix B compares all four labels.

📉 6.2 Shape of the relationship

Success rate per bucket. The shaded ribbon is the 95% interval: where ribbons of two buckets overlap, the difference between them is not reliable.

🔀 6.3 Yes / no features

A dumbbell chart: orange = games without the feature, blue = with it, the grey bar is the gap. Thin whiskers are 95% intervals.

🏷️ 6.4 Genres and tags

Lift = success rate of games with the label / overall rate. Only labels with at least MIN_GROUP games are shown, because rates from small groups swing wildly. Tags are voted by players after release, so tags describe popular games as much as they predict them. Use them to understand, not to predict.

The query computes lift for every genre and tag under all four success labels in one pass: the four label columns are turned into rows (labels_long), so a single GROUP BY covers them all. Appendix B reuses the result.

Shown as a forest plot on a log scale, so 2x and 0.5x are the same distance from average.

🤖 7. Modelling

Question: using only what is known at (or near) launch, how well can a model separate games that become successful from those that do not?

Rules that keep the result honest: - No outcome columns as features. Owners, Peak CCU, reviews, Positive/Negative, Recommendations, playtime, Metacritic and User score define or follow success. Including them would give a perfect score and teach nothing. - No n_tags. Tags are voted by players after release. - Time-based split. Train on games up to SPLIT_YEAR, test on later ones. A random split would let the model learn from the future. - Only games old enough for outcomes to settle (MIN_YEARS). - Discount is left out because it changes over time. DLC count, Achievements and trading cards can grow after launch, so treat their importance with some caution.

🔬 7.1 Focus model: TARGET

📌 8. Findings and limits

⚠️ Limits to keep in mind

📎 Appendices

Supporting checks and extensions. They reuse variables from the main sections, so run the notebook from the top.

🗂️ A. Data overview in detail

🧷 B. Stability across success definitions

Sections 6 and 7 used one TARGET. A finding is only worth trusting if it survives a change of definition, so this section reruns the indicator tests and the model for all four labels and compares them.

🧬 C. Richer features: store-page text and developer history

Two ideas for signal beyond the basic launch facts:

1. Text of About the game. Words are turned into TF-IDF weights, a linear model learns which words go with success, and its output becomes one numeric feature (text_score) for the main model.
2. Developer and publisher track record. For each game: how many games the developer released before, and how those earlier games did. This is computed in SQL with window functions over each studio's release history.

Leakage controls (the part that is easy to get wrong): - The TF-IDF vocabulary and the text model are fitted on training years only. For training games the score is out-of-fold (each game is scored by a model that never saw it), so the main model does not see an over-optimistic feature. - Track-record features only count earlier games that were released at least a year before the current game, so their outcomes had time to settle. Nothing from the current game or the future is used. - Developer and publisher are matched on the exact text of the field (a studio spelled two ways counts as two).

🪜 D. Ordinal model of owner buckets

So far owners were reduced to "top 10% or not". Steam publishes owners as ordered buckets (0-20k, 20k-50k, 50k-100k, ...). An ordinal model uses all of that information: for every bucket boundary it predicts the chance that a game ends above it (a cumulative-threshold model, Frank and Hall 2001). Adding the probabilities gives an expected bucket for each game.

Why try it: a regression on the owner midpoint treats the bucket edges as evenly spaced measurements, while the ordinal model only assumes the order. Whether that helps is an empirical question, so both are compared below.

Neighbouring rare buckets are merged so every class has enough training games. Newer games have had less time to gather owners, so the within-year rank correlation (do games rank correctly among games released in the same year?) is the fairest single metric.

🧾 Appendix findings

🚀 Next steps

• Match developers more loosely (lowercase, strip "Inc.", "Ltd.") so a studio spelled two ways counts once.
• Add a point-in-time version of history features using review counts at the earlier game's own launch, if a dated review snapshot becomes available.
• Try sentence embeddings of About the game instead of TF-IDF, and compare with the text gain measured here.