Stat Legend
Field Reference
Curated scorer's-table guide to the most important column patterns across the warehouse
Field Reference
This page is the scorer's-table cheat sheet for the warehouse: not every single field in every generated schema block, but the recurring column patterns that make dense reference pages faster to scan and much harder to misread.
Use it when the column name is technically familiar but context is still fuzzy: is this an identity key or a history key, a side-of-ball label or a duplicate-looking participant slot, a rate or a total, or a discriminator that changes the row's meaning entirely?
Quick routes on this page
Use this page like a scan aid, not like a linear essay.
Find the join anchors first
Jump to Identity and grain columns when you need to decide whether a row is keyed by player, team, game, season, date, or lineup/group context.
Decode who the row is talking about
Use Role and context columns for home vs visitor, offense vs defense, participant-slot fields, and shot-zone labels.
Read the stat name by sight
Open Metric naming quick read when the question is
really about suffixes like _pct, _rank,
total_, or rolling windows.
Explain the duplicate-looking rows
Go to Discriminator columns when repeated keys might actually be different slices, summaries, or tracking cuts rather than bad duplication.
Start here by question
| If the question is... | Read this section | Why |
|---|---|---|
| "Which columns identify the row and define its grain?" | Identity and grain columns | These are the keys and season/game anchors that keep joins honest |
| "What do these home/visitor/offense/defense columns mean?" | Role and context columns | These fields tell you which side of the possession a row is describing |
"How should I interpret _pct, avg_, total_, or rolling fields?" | Metric naming quick read | This is the fastest way to decode a stat column by sight |
| "Why do multiple rows exist for what looks like the same entity?" | Discriminator columns | Dashboard-style surfaces often encode row meaning in type/context fields |
Identity and grain columns
Primary join anchors
| Pattern | Where you will see it | How to read it |
|---|---|---|
player_id | dim_player, player facts, matchup and shot tables | Default natural key for player joins across the analytical surface |
team_id | dim_team, team facts, many player/team mixed facts | Default team join key for both team-level and roster-context analysis |
game_id | dim_game, game facts, player-game and team-game facts | The main possession/game anchor for event and box-score style analysis |
group_id | lineup-oriented facts and bridges | Identifier for lineup/group analysis rather than a single player or team |
Grain-scoping helpers
| Pattern | Where you will see it | How to read it |
|---|---|---|
season_year | dim_game, season-level facts, aggregates, analytics views | Common season-scoping field; use it early to narrow wide scans |
season_type | game or season summary surfaces | Distinguishes regular season, playoffs, and other competition phases |
date_key / full_date | dim_date and date-aware reporting | Calendar helpers for reporting windows, weekday analysis, and date joins |
History-aware keys
| Pattern | Where you will see it | How to read it |
|---|---|---|
<entity>_sk | history-aware dimensions such as dim_player | Surrogate/history key used when row state over time matters |
If a table exposes both <entity>_id and <entity>_sk, read them as different jobs, not duplicate columns. The natural key answers who; the surrogate/history key answers which versioned row.
Role and context columns
Side-of-game context
| Column or pattern | What it usually signals | Scouting note |
|---|---|---|
home_team_id / visitor_team_id | Both clubs attached to one game row | The main game dimension uses visitor, not away, for the second team |
side | Home/away designation on a row | Important in stint and bridge-style tables where one surface carries both sides |
def_player_id / def_team_id | Defensive-side participant in matchup or defense tables | Keep offense and defense in separate lanes when joining |
Participant-slot columns
| Column or pattern | What it usually signals | Scouting note |
|---|---|---|
player1_id / player2_id / player3_id | Event participants embedded directly on an action row | Common on play-by-play style data before participant rows are fanned out |
Human-readable labels and geography
| Column or pattern | What it usually signals | Scouting note |
|---|---|---|
matchup, conference, division | Human-readable context labels | Useful for output and grouping, but not substitutes for business keys |
zone_basic, zone_area, zone_range | Shot geography | Read these together to describe where a shot came from on the floor |
Metric naming quick read
Percentages, ratings, and ranks
| Pattern | Meaning | Example interpretation |
|---|---|---|
_pct | Decimal percentage or rate | fg_pct, ts_pct, score_pct are typically stored as 0.0-1.0 |
_rating | Per-possession rating metric | off_rating, def_rating, and net_rating describe scoring efficiency context |
_rank | Ordering within a category | pts_rank or conference_rank is only meaningful with the matching leaderboard or standings context |
Totals, averages, and windows
| Pattern | Meaning | Example interpretation |
|---|---|---|
total_ | Aggregate count or sum | total_pts means season total points, not per-game output |
avg_ | Average over the row's grain | avg_pts on a season rollup means points per game at that summary grain |
_rollN | Rolling window metric | pts_roll5 means a five-game rolling average, not a season mean |
Flags and shorthand
| Pattern | Meaning | Example interpretation |
|---|---|---|
is_ | Boolean flag | is_current and is_weekend are yes/no state markers |
| shorthand metrics | Established basketball abbreviations | pie, pace, ppp, tchs, and spd are compact stat names rather than suffix-based patterns |
Discriminator columns
Some surfaces look denormalized because they intentionally stack multiple related feeds or analytical cuts into one table. In those cases, the discriminator column is part of the row's meaning.
| Pattern | What it tells you | Common examples |
|---|---|---|
*_type | Which slice or variant produced the row | detail_type, summary_type, tracking_type, leader_type |
*_source | Which upstream context or feed produced the row | context_source |
split_* | Which analytical split the row belongs to | split_type |
entity_* | Which entity level is represented | entity_type, entity_id |
| chart/shot labels | Which shot or chart cut is present | shot_type, chart_type |
If two rows share the same player_id or team_id but differ on one of these fields, they are usually not duplicates. They are different possessions in the same set.
Stop here before calling it a duplicate
- If the repeated row differs by
detail_type,summary_type,tracking_type, orsplit_type, it is usually a different analytical cut. - If the repeated row differs by
entity_type, it may represent a different level of analysis on the same surface. - If the repeated row differs by shot/chart labels, you are often looking at parallel geography buckets, not bad dedupe.
Practical reading order for dense tables
- Find the grain first: look for
game_id,season_year,player_id,team_id, or lineup/group keys. - Check the discriminator fields: a
detail_typeorsplit_typecan change the entire meaning of the row. - Read role columns next: home vs visitor, offense vs defense, or participant slot fields tell you which side of the ball you are looking at.
- Only then scan the measures: percentages, ratings, counts, and ranks make sense once the row's role is clear.
Common misread traps
Natural key vs history key
Do not treat <entity>_id and <entity>_sk as interchangeable.
The natural key answers who; the surrogate/history key answers which row version.
Home/visitor labels are not noise
On game-centered surfaces, home_team_id and visitor_team_id define
the matchup context. They are part of the row's story, not decorative lookup columns.
Totals and averages should not be mixed casually
total_pts and avg_pts can sit near each other on season surfaces but
answer different questions. Check the grain before comparing them to player-game rows.
Repeated IDs are often intentional
If repeated keys differ on detail_type, summary_type,
tracking_type, or split_type, you are probably looking at parallel
analytical cuts rather than a broken dedupe.
When the table is still too dense, switch to the schema page first: Dimensions, Facts, Derived Aggregations, or Analytics Views. Use the curated page to understand the table family, then come back to the generated field inventory for exact columns.
Keep moving
Stay in the same possession
Keep the mental model warm with adjacent pages, section hubs, and search-friendly routes into the same topic cluster.