8. How do you prove that your player data can join our existing database safely?

Interview objective: Test identity continuity and data maintenance, not merely whether an API returns records.

Put to: Arielle Dror, the club’s data engineer and each supplier’s technical owner.

Why it matters to buyers: Sportradar’s official soccer API documentation includes player-merge mappings for profiles consolidated under a new identifier. This is a concrete example of why a recruitment integration should account for identifier changes rather than assume that every upstream ID remains unchanged. (developer.sportradar.com)

A strong answer should cover:

• Identifier namespaces and the relationship between player, team, competition, season and match IDs.
• Transfers, loans, aliases, diacritics, duplicate profiles and revised biographical fields.
• The distinction between a confirmed match, a probable match and an unresolved record.
• Schema changes, historical corrections, deletions and reproducible reprocessing.
• Ownership of the crosswalk and responsibility for fixing errors after implementation.

Sharp follow-up: If two players share a name and one birth date is wrong, does your process silently merge them, stop for review or preserve both records?

Request this artefact: A Player Data Joinability Check using an adjudicated sample. Report false merges, false splits, unresolved records and correction effort separately, with explicit denominators. Do not describe the proportion of rows automatically matched as identity accuracy unless those matches have been checked.

Also ask for a replay test: process the same sample twice and demonstrate that it does not create duplicate players or appearances.

Proposed expert interview; not yet conducted. No expert quotation is attributed.