Last updated
One player ID across every hockey data source
Short answer
Providers use different names, formats and internal IDs for the same player. Matching combines normalized names, birthdates, team/season context and manual review for edge cases — then stores one club player ID with native Elite Prospects, Sportlogiq and internal IDs kept for traceability.
Why sources disagree
"J. Andersson", "Johan Andersson" and "Andersson, J." may be the same person — or not. Transfers, dual-league rosters and call-ups create duplicates. Without a shared ID, every report rebuilds joins by hand.
How matching works
Matching runs on each load so new games and roster moves do not silently drift.
- Normalize names and strip team-specific formatting
- Use birthdate and team/season when available
- Queue ambiguous cases for analyst review
- Keep every native provider ID on the final row
Example row
THB-00142 · Example Player A · EP ep-000001 · Sportlogiq slq-000001 · Scouting grade B+ (Oct 2) — one row, three systems.
Example data. Fictional IDs for format illustration only.
Frequently asked questions
Do we lose Elite Prospects IDs?
No. Native IDs stay on the row so you can trace any metric back to the provider.
Who resolves ambiguous players?
The pipeline flags edge cases; your analytics lead confirms in review during founding-club onboarding.
Is matching live?
The process is how the product is designed to work; connectors are not live until founding-club delivery begins.
Get a free map of your club’s data stack
30 minutes · hello@thehockeybrain.com