Root-cause assistant for repeat athlete and fan identity mismatches
Problem
When an athlete or fan record fails to match across the registration database, the CRM and the medical record, the unmatched list lands in a spreadsheet tab that an analytics engineer works through by hand: open each source system, compare fields, guess at the cause. The same causes recur. A vendor's export switched date format last March. A name field gets truncated above forty characters. A re-issued membership number breaks the join. Nobody records which fix applied to which failure, so the next person re-derives the same answer from scratch. The manual lookup table patched together to cover the gap grows every season and explains nothing about why it exists.
Product idea
A tool that reads the identity resolution log of unmatched and low-confidence records, pulls the field history for each one from the systems involved, and compares the current failure against a library of past resolved cases. It surfaces the likely cause, for example a date of birth format that changed in the same week as a particular export, with the before and after field values as evidence, rather than a bare mismatch flag. A reviewer confirms or corrects the proposed cause, and confirmed cases feed back into the library so the next occurrence is diagnosed faster instead of solved from scratch. It does not attempt to fix the mismatch or merge records itself; it produces a case a person acts on.
Who it is for
Data engineers and analytics engineers who currently investigate unmatched identity records by hand, and the Head of data who would sponsor it to stop the same root cause being rediscovered every season.
Possible first version
A first version reads an exported identity resolution log plus manually uploaded field snapshots from the systems involved, not a live connection, and matches each new failure against a small starting library of past confirmed causes using field-pattern comparison. It shows one case screen: the failure, the closest matching precedent, and the evidence behind it. A reviewer confirms or corrects the proposed cause, which is added to the library. Live integration with source systems and any automatic write-back are explicitly out of scope until the library holds enough confirmed cases to be worth connecting.
- Build classification
- Micro-tool
- Rough effort
- 12-day prototype build
- Roles involved
- Analytics engineer, Data engineer, Head of data
- Relevant to
- Professional club, League office, Federation / governing body, Collegiate athletics
- Systems in play
- Athlete management systems, CRM, Registration and membership database, Data catalogues and quality monitoring
- Product framing
- Diagnose
Questions we get asked
What do we need to feed it before it's actually useful?
An identity resolution log of unmatched or low-confidence records, and ideally a few dozen past failures where someone already worked out the cause, even if that knowledge only exists in an analyst's head today. Without any confirmed precedents to compare against, early proposals will be weaker guesses. The library gets more useful the more cases run through it, which is why it is built to grow rather than ship pre-loaded.
Does this do the identity matching itself?
No. It sits downstream of whatever already produces the unmatched or low-confidence list, whether that is a matching pipeline or a manual join someone runs in a spreadsheet. It does not attempt to match records or resolve the mismatch. Its job starts once a failure has already been flagged, and ends with a proposed cause and the evidence for it.
We already keep a lookup table that patches these by hand. Why add another tool?
The lookup table usually records the fix applied, not the reason the record failed, so the next time a different record trips the same underlying cause, someone investigates it again from nothing. That gap is what this closes. If the team is genuinely fine re-deriving the cause each time, the case for this is thin, and it should not be built.
Who confirms the proposed cause, and does it fix the record?
It never writes back to a source system or merges records on its own. A named reviewer confirms or corrects each proposed cause, and that confirmation is what makes the library trustworthy over time. Someone has to own reviewing new cases regularly, likely weekly, or the library stops improving and the tool quietly reverts to a mismatch list with extra steps.
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.