About cEDH Analytics
Methodology, statistics, and technical details.
See data limitations for known caveats.
Elo details: cEDH Skill Rating methodology
Data model: Supabase schema + curated views
All findings are based on games played on the Topdeck platform.
- Tournament and League data sourced from TopDeck.gg API
- Only completed tournaments/leagues with published standings are included
- Decklist data parsed and normalized for card frequency analysis
- Partner commanders are tracked as a single combined commander identity
Win Rate
Win Rate = Wins / Total GamesThe percentage of games won by a commander. In a 4-player pod, the expected (baseline) win rate is 25% - anything above this indicates above-average performance.
Example: A commander with 150 wins in 500 games has a 30% win rate (150/500 = 0.30), which is 5 percentage points above expected.
Conversion Rate (Top 16 / Top 10 / Top 4)
Conversion Rate = Top Bracket Finishes / Total EntriesThe percentage of tournament entries that result in a top-bracket finish. Under 64 players, some events use a Top 10 cutoff, and for 34 players or fewer we only count Top 4 finishes.
Example: A commander with 25 top-bracket finishes from 100 entries has a 25% conversion rate.
Top Cut Conversion
Top Cut Conversion = Top Cut Finishes / Total EntriesThe percentage of tournament entries that make the event's top cut bracket.
Example: A commander with 12 top cuts from 80 entries has a 15% top cut conversion rate.
Points per Game
Points per Game = (Wins * 5 + Draws) / Total GamesWeighted scoring that values wins at 5 points, draws at 1 point, and losses at 0 points.
Example: A commander with 10 wins, 5 draws, 25 losses across 40 games scores 1.375 points per game.
Resiliency
Resiliency = (Wins + Draws) / Total GamesThe share of games that are not losses. Higher resiliency indicates a stronger ability to avoid losing.
Example: A commander with 20 wins and 10 draws across 50 games has 60% resiliency.
Inclusion Rate
Inclusion Rate = Decks with Card / Total DecksFor card analysis, this measures how often a card appears across all decklists for a given commander (or globally). Cards are tiered based on their inclusion rates.
Example: If Sol Ring appears in 95 of 100 decks, its inclusion rate is 95%.
Card Tiers
80%+ inclusion
60-79%
30-59%
10-29%
<10%
Not all observed differences are meaningful. Statistical significance helps us determine whether an observed effect (like a commander's win rate being above 25%) is likely real or just due to random chance.
Sample Size Requirements
We require minimum sample sizes before drawing conclusions. A commander with 5 entries and a 60% win rate is far less reliable than one with 500 entries and a 28% win rate.
Confidence Levels
P-Value
p < 0.05 indicates statistical significanceThe p-value represents the probability of observing results at least as extreme as the actual results, assuming the null hypothesis is true. In our context, if a commander's win rate appears higher than 25%, the p-value tells us how likely we'd see this by random chance.
Trap Score
Trap Score = Inclusion Rate × |Baseline WR - Card WR|Identifies popular cards that underperform. Cards with high inclusion rates but below-baseline win rates are 'traps' - widely played despite hurting your chances. The trap score weights by inclusion rate so commonly-played underperformers rank higher.
Spice Identification
Spice = Low Inclusion Rate + High Win Rate DeltaHidden gems are cards with <10% inclusion but significantly above-baseline win rates. These rarely-played cards may offer competitive advantages that the meta hasn't discovered yet.
Important Caveats
- Correlation ≠ Causation:A card's correlation with win rate doesn't mean it causes wins
- Confounding factors: Better players may play certain cards, skewing results
- Meta context:A card's effectiveness depends on the current meta
- Sample size: Low-inclusion cards have high variance in their statistics
Frontend
- Next.js 16 - React framework with App Router
- TypeScript - Type-safe development
- Tailwind CSS - Utility-first styling
- Recharts - Data visualization
- Radix UI - Accessible component primitives
Backend
- Supabase - PostgreSQL database + API
- Materialized Views - Pre-computed statistics
- RPC Functions - Complex queries in PL/pgSQL
- Edge Functions - Serverless compute
Data Pipeline
- TopDeck.gg API - Tournament data source
- Python ETL - Data extraction and loading
- Scheduled Jobs - Regular data refreshes
Infrastructure
- Vercel - Frontend hosting + CDN
- Supabase Cloud - Managed PostgreSQL
- GitHub Actions - CI/CD pipeline
Have questions about the methodology or found an issue with the data? We welcome feedback and contributions.