Deduplikering på netværksskala: sådan undgår vi at samme ansøger sælges to gange
Cross-netværks-deduplikering lyder ligetil, indtil du har hundrede købere og syv jurisdiktioner. Sådan fungerer systemet i praksis.
Deduplikering er det kedelige problem alle spørger om, og som ingen publicerer arkitekturen for. Her er vores.
Den naive version
Hver gang et lead kommer ind, søges databasen for en matchende e-mail eller telefon de seneste 30 dage. Er der hit, afvises leadet.
Det knækker hurtigt. Ansøgere skifter telefonformat midt i formularen. De genindsender med "Hr." foran navnet. Nogle netværk accepterer landekode med +, andre uden. Nogle normaliserer mellemrum, andre ikke. Efter et år med "hvorfor matchede det her ikke?"-tickets giver du op og tilføjer en fuzzy-matcher.
Hvad vi reelt gør
Vi beregner tre uafhængige identitets-hashes per ansøger ved indsendelse:
- Stærk identitet — normaliseret nationalt ID + fødselsdato. Deler to ansøgere denne, er de samme person, punktum.
- Kontakt-identitet — normaliseret telefon (E.164) + e-mail (lower- cased, plus-strippet). Høj tillid; nogle gange delt (ægtepar, bofæller).
- Profil-identitet — fornavn + efternavn + fødselsår + postnummer. Lavere tillid; nyttig til at fange ansøgere der ændrer kontaktdata mellem indsendelser.
Hvert hash beregnes én gang og gemmes ved siden af leadet. Ved hver ny indsendelse slår vi alle tre hashes op mod de seneste 30 dage.
Hvad vi gør med matches
Et match på stærk identitet inden for 30 dage = automatisk blokering. Långiveren får én notifikation om matchet; de ser ikke leadet to gange.
Et match på kontakt-identitet inden for 7 dage = sendes igennem med et "contact-recently-seen"-flag. Långiveren afgør selv, om de vil underwrite.
Et match på profil-identitet inden for 30 dage = sendes igennem med et blødere flag og det forrige submission-ID, så långiveren kan krydsreferere.
Hvorfor tre hashes, ikke ét
Fordi ansøgere er rodede. Faktisk eksempel fra en kundeservice-ticket: samme person, tre indsendelser hos to mæglere; to af de tre matchede kun på profil-identitet (de var flyttet og havde skiftet telefon). Ét hash ville have misset to ud af tre.
Hvad vi publicerer
Audit-loggen viser: hvilket hash matchede, hvornår, hvad vi gjorde. Både den indkommende mægler og den oprindelige modtagende långiver kan forespørge deres egen del af det. Tilsynsmyndigheder ser det fulde billede ved forespørgsel. Vi eksponerer aldrig selve hashene til partnere — de er interne — men vi eksponerer de matchede submission-ID'er.
Hvad der er svært
Det reelt svære er ikke at beregne hashes. Det er at normalisere input: telefonnummer-landedetektion, navne-kanonisering på tværs af nordiske sprog, postnummer-formater per land. Vi vedligeholder den normaliserings-pipeline som et førsterangs-system, adskilt fra routing, adskilt fra storage. Den unit-testes med millioner af historiske records og en ugentlig canary mod et kendt-dårligt input-sæt.
Hvor vi er på vej hen
Vi vil gerne publicere hash-skemaerne åbent, så andre netværk kan interoperere på dedup-laget. Samtalerne er i gang. Største blocker er enighed om normalisering — når først alle er enige om hvordan man kanoniserer et dansk telefonnummer, er resten mekanisk.