Entity resolution

Wat is entity resolution?

Entity resolution is het uitzoeken welke records naar dezelfde entiteit uit de echte wereld verwijzen: dezelfde persoon, hetzelfde bedrijf, hetzelfde product. Records die bij elkaar horen koppel je aan elkaar, en wat toevallig op elkaar lijkt maar niet hetzelfde is, hou je gescheiden.

Het probleem ontstaat omdat echte data zelden een betrouwbaar gedeeld identiteitsnummer heeft. Dezelfde klant staat in je CRM als "Jan Peeters", in de webshop als "J. Peeters" en in het boekhoudpakket met een tikfout in de straatnaam. Geen enkel systeem draagt een sleutel die je zomaar kan koppelen. Entity resolution beslist op basis van de velden die je wel hebt (naam, adres, e-mail, telefoon, ondernemingsnummer) of het over een en dezelfde persoon gaat.

Vergelijk het met een receptioniste die twee inschrijvingsformulieren naast elkaar legt. De namen verschillen licht en het ene adres is verouderd, maar het telefoonnummer en de geboortedatum kloppen. Zij besluit dat het dezelfde bezoeker is. Entity resolution maakt die afweging automatisch, over miljoenen records, met een score in plaats van een onderbuikgevoel.

Entity resolution versus deduplicatie

De twee worden vaak door elkaar gehaald. Deduplicatie ruimt dubbele records op binnen een lijst: dezelfde klant die drie keer in het CRM staat, samengevoegd tot een. Entity resolution is de bredere vraag. Die koppelt identiteiten ook over meerdere bronnen heen: het CRM, de webshop, het boekhoudpakket, een aangekochte adressenlijst.

Deduplicatie is met andere woorden een deelgeval van entity resolution: het geval waar alle records toevallig in dezelfde tabel zitten. Zodra je bronnen wil samenbrengen die elk hun eigen sleutels en schrijfwijzen hanteren, heb je de volledige entity resolution nodig.

Hoe werkt de pipeline?

Entity resolution verloopt in een vast aantal stappen. Elke stap knijpt het probleem verder dicht.

Normaliseren
Eerst maak je de velden vergelijkbaar. E-mailadressen in kleine letters, telefoonnummers in +32-formaat, "N.V." en "nv" gelijkgetrokken, adressen gestandaardiseerd. Zonder die opkuis vergelijk je appelen met peren en mis je matches die voor het oog nochtans voor de hand liggen. Deze stap hangt vast aan je datakwaliteit: hoe properder de bron, hoe minder werk hier.

Blocking
Alle records met alle andere vergelijken is niet haalbaar. Het aantal paren groeit met het kwadraat van het aantal records: een miljoen records geeft al zowat 500 miljard paren. Blocking lost dat op door enkel records te vergelijken die een grove eigenschap delen, bijvoorbeeld dezelfde postcode of dezelfde eerste drie letters van de naam. Zo daalt het aantal vergelijkingen tot iets werkbaars, zonder de echte matches te verliezen.

Paarsgewijs matchen
Binnen elk blok vergelijk je records twee aan twee. Dat gebeurt met deterministische regels (exact hetzelfde ondernemingsnummer, dus zeker dezelfde firma) en met een probabilistische score voor de gevallen waar niks exact gelijk is. De klassieke methode voor dat scoren heet Fellegi-Sunter record linkage. Per veld reken je met twee kansen: hoe waarschijnlijk een overeenkomst is als het echt dezelfde entiteit is (de m-kans), en hoe waarschijnlijk diezelfde overeenkomst puur toeval is bij twee verschillende entiteiten (de u-kans). Een zeldzame achternaam die overeenkomt weegt zwaar, een veelvoorkomende veel minder. Die gewichten tel je op tot een score; ligt die boven een drempel, dan behandel je het paar als een match.

Clusteren
Losse paren zijn nog geen entiteiten. Als record A matcht met B, en B met C, horen A, B en C in dezelfde groep, ook al vergeleek je A en C nooit rechtstreeks. Deze stap bundelt alle gekoppelde records per echte entiteit.

Canoniek record bouwen
Van elke groep maak je een samenvattend record: het meest recente adres, het geldige e-mailadres, de correcte bedrijfsnaam. Dat is het gouden record dat je systemen verder gebruiken.

Een voorbeeld: CRM en webshop koppelen

Stel, je wil weten hoeveel van je webshopkopers ook als contact in het CRM staan. Er is geen gedeeld klantnummer tussen de twee.

In het CRM staat "Jan Peeters" van Acme N.V., met jan.peeters@acme.be en een kantooradres in Antwerpen. In de webshop plaatste "J. Peeters" een bestelling met datzelfde e-mailadres, maar met een leveringsadres in Berchem.

Na het normaliseren staan beide e-mailadressen identiek. Blocking op het e-maildomein zet allebei de records in hetzelfde blok. De paarsgewijze vergelijking ziet een exact gelijk e-mailadres (zwaar gewicht), een gedeeltelijke naamovereenkomst en een verschillend adres (licht negatief). De opgetelde score ligt ruim boven de drempel, dus entity resolution besluit: dezelfde persoon. Het canonieke record koppelt de webshopbestelling aan het CRM-contact, houdt zowel het kantooradres als het leveringsadres bij, en jij hebt eindelijk een sluitend antwoord op je vraag.

Waarvoor gebruik je entity resolution?

Overal waar dezelfde entiteit onder verschillende gedaanten in je systemen zit, en waar dat verschil geld of risico kost.

1. Klant-360
   Een volledig beeld per klant over sales, support, facturatie en webshop heen. Entity resolution levert de koppeling, master data management houdt het gouden record daarna operationeel bij. Zo krijg je een echte single source of truth voor je klantgegevens in plaats van vier half-kloppende lijsten.

2. Fraude en witwasbestrijding
   Banken en verzekeraars leggen met entity resolution verborgen verbanden bloot: drie ogenschijnlijk losse aanvragers die hetzelfde telefoonnummer en adres delen, of een persoon achter meerdere valse identiteiten. In anti-witwas (AML) is dat net de kernvraag: wie is deze persoon echt, en met wie hangt hij samen?

3. Data samenbrengen na een overname
   Twee bedrijven fuseren en elk heeft zijn eigen klanten- en leveranciersbestand. Entity resolution zoekt uit welke relaties in beide bestanden zaten, zodat je niet dezelfde klant twee keer factureert of twee keer benadert.

Waar moet je op letten bij entity resolution?

De drempel is een keuze, geen natuurwet
Leg je de matchdrempel te laag, dan voeg je records samen die niet bij elkaar horen (twee verschillende Jan Peeters worden een). Leg je ze te hoog, dan mis je echte koppelingen. Waar je de grens legt, hangt af van wat een fout kost: een verkeerde samenvoeging in een witwasonderzoek weegt zwaarder dan in een marketingsegment.

Twijfelgevallen blijven mensenwerk
Scores rond de drempel zijn geen zekerheid. Voor die grijze zone heb je een data steward nodig die de match bevestigt of afkeurt en die beslissing bijhoudt, net zoals bij master data management.

Van entiteiten naar verbanden
Zodra je entiteiten sluitend zijn, wordt de volgende vraag interessant: hoe hangen ze samen? Wie is bestuurder van welke firma, welke adressen delen ze? Die gekoppelde entiteiten vormen de bouwstenen van een knowledge graph, waar fraude- en risicoanalyse vaak op verdergaat.