Exploration & Ranking
Game States
Every visible game exists in one of two data-maturity states:
| State | Purpose |
|---|---|
| Exploration | Collecting initial data through controlled exposure |
| Ranked | Ordered by performance metrics in game lists |
A game can be in different states on different platforms (e.g., Ranked on desktop, Exploration on mobile).
Exploration
Purpose
Exploration gives new or experimental games controlled exposure to collect enough data for fair ranking. While in Exploration:
- Games are shown in dedicated exploration slots
- All metrics are collected but not used for ranking
- The goal is data collection, not competitive positioning
Slot Allocation
Game lists use a hybrid layout:
| Portion | Source |
|---|---|
| 90% | Ranked games, ordered by rank |
| 10% | Exploration games, drawn from the rotation queue |
If there are not enough Ranked games to fill the list, Exploration games fill the remaining space.
Exploration slots are available on all list surfaces:
- Home page
- Category pages
- Game detail page (recommended games below the player)
Exception: Author pages do not include exploration slots.
Rotation Queue
Each surface (Home or category) and platform (desktop or mobile) maintains its own exploration queue.
How it works:
- Exploration slots display the first N games from the queue
- When a game receives one new unique player who triggers
gameplay_start, the game moves to the end of the queue - The game stays in the queue and will reappear later
This distributes exposure across different traffic periods and prevents any single game from monopolizing exploration slots.
Exit Threshold
Each game in Exploration has a configurable exit threshold defined as a number of unique players who triggered gameplay_start.
| Use Case | Default Threshold |
|---|---|
| New public game | 1,000 unique players |
| Playtest build | 500 unique players |
| Experimental content | Custom threshold |
A game exits Exploration only when its threshold is reached.
Transition to Ranked
When the threshold is reached:
- The game transitions to Ranked state
- Collected metrics are used to compute its initial rank
- The game appears in normal list ordering
Ranking
How Ranking Works
Ranked games are ordered using platform metrics. Ranking is:
- Data-driven based on collected events and computed KPIs
- Computed separately for:
- Home vs. each category
- Desktop vs. mobile
- Recalculated periodically (not real-time)
Ranking Algorithm
The ranking algorithm takes multiple metrics as input (see Data Model for the full list). The exact formula and weights are tunable and will evolve based on platform data.
Reuse: Generic Exposure System
Exploration is designed as a generic exposure system that supports multiple use cases beyond new game discovery:
| Use Case | Exit Behavior |
|---|---|
| New game discovery | Transitions to Ranked |
| Developer playtests | Archived or removed |
| Experimental builds | Custom lifecycle |
| A/B testing | Custom outcome |
Each use case can define its own threshold, lifecycle, and outcome.
Queue Initialization
When a new surface is created (e.g., a new category), its exploration queue is initialized as follows:
- All games in Exploration state that belong to the surface are added to the queue
- Initial queue order is randomized (not by creation date) to avoid bias
- Each game starts with
uniquePlayers = 0and the default threshold
When a game first enters Exploration (via visibility change to Visible):
- The game is added to the end of every applicable queue (Home + each of its categories)
- Separate queue entries are created for each platform (desktop, mobile)
Demotion from Ranked
Whether a Ranked game can be demoted back to Exploration is an open question — see Decisions → Open Questions.
Currently, once a game reaches Ranked, it stays Ranked. Poor-performing games naturally sink to the bottom of ranked lists through the ranking algorithm.
Why Separate States?
- Prevents ranking instability from low data volume
- Guarantees fair exposure for new content
- Keeps ranked lists stable and data-driven
- Allows future systems (playtests, experiments) without changing core logic