Identity match monitor for athlete and fan records across systems
Problem
The same athlete carries three different identifiers: one from the athlete management system, a different one in the medical record, and a third from the registration database. Joining them for a report depends on a lookup table one analyst maintains by hand in a spreadsheet tab nobody else has edit access to. When a player joins mid-season, or the registration system reissues an identifier after a data cleanup, the spreadsheet falls behind and nobody notices until a coaching report and a medical clearance report disagree about which sessions an athlete attended. The analyst who built the mapping is the only person who can explain a given join, and when they are on leave the mismatch sits unresolved.
Product idea
A monitor that sits on top of the identity mapping already produced by the warehouse or ELT layer, not a replacement for the matching logic itself. One screen shows, per source system, how many records are confidently matched, how many are new and unmatched, and how many conflict with a previous match, refreshed on the same schedule as the pipelines that feed it. A single threshold rule, for example more than a stated number of unmatched records in a source, sends an alert to the named data owner before the next scheduled report pulls from a still-inconsistent mapping. Each flagged record links through to the source rows so the owner can see why the match failed. It does not attempt automatic resolution: a low-confidence match stays flagged until a person confirms or rejects it.
Who it is for
Data engineers and CRM or CDP managers who currently maintain identity mappings by hand, sponsored by the head of data who is accountable when two reports disagree about the same athlete or fan.
Possible first version
A single dashboard reading from a CSV or table export of the existing identity mapping, showing per-system counts of matched, new-unmatched and conflicting records, with row-level drill-through to the source identifiers. One configurable threshold rule triggers an email alert to a named owner. Confirming or rejecting a flagged record updates a status column but does not write back to any source system. Out of scope for version one: automatic matching logic, direct connections to the warehouse or vendor systems, and any write-back into the CRM, AMS or registration database.
- Build classification
- Micro-tool
- Rough effort
- 10-day prototype
- Roles involved
- Data engineer, Head of data, CRM and CDP manager
- Relevant to
- Professional club, League office, Federation / governing body, Collegiate athletics
- Systems in play
- Data warehouse and BI tool, Athlete management system, Registration and membership database, Spreadsheets
- Product framing
- Monitor
Questions we get asked
What do we need to have in place before this shows anything useful?
It needs an existing identity mapping to read, even a rough one: source-system identifiers with a proposed match, whether that comes from a transformation model, a vendor's own matching feature, or the spreadsheet currently in use. Version one reads a CSV or table export of that mapping. If no mapping exists at all yet, there is nothing for this to watch, and the matching logic itself needs building first.
Does this replace our identity resolution logic, or sit alongside it?
It sits on top of whatever already produces the mapping, whether that is a transformation model, a vendor feature, or a maintained spreadsheet. It does not do the matching itself. Version one is deliberately a read-only status layer, so if the resolution logic changes later, the monitor keeps working as long as it can still read the output table.
We already have a spreadsheet mapping that works fine. Why add this?
It probably does work, until the person who maintains it is away, or the registration system reissues an identifier they had no reason to check for. This is not proposing to replace a spreadsheet that is trusted. It is proposing to watch it, or whatever succeeds it, for the moment it falls behind, and say so before a report gets built on the gap.
Who owns this day to day, and what does it cost them?
Usually the data engineer or CRM and CDP manager who already maintains the mapping owns the threshold and reviews flagged records. The time cost is the minutes it takes to confirm or reject each flag, not a new full-time role. If nobody is willing to act on an alert, the threshold should be turned off rather than left generating alerts nobody reads.
Is this your workflow?
Tell us one sports workflow that still runs on paper, spreadsheets, WhatsApp or an outdated system. We will map it and show you what a simpler product looks like.
Tell us about itMore in Data platform & engineering
- Access permission drift monitor for warehouse and reporting toolsA monitor that compares entity access rules across the identity provider, warehouse and reporting tool, and alerts a named owner when they drift out of sync.
- Attendance reconciliation report across ticketing and till systemsA reconciliation report that turns a ticketing export and a till export for the same fixtures into one defensible attendance and spend figure, with the variance between them shown and explained.
- Chat intake assistant that triages ad hoc data requestsA chat assistant that answers a data request instantly when the metric already exists, and turns anything new into a structured, tracked ticket instead of a message lost in a chat thread.