Algorytmy dopasowania¶
Rozdział opisuje, jak Deduplikator rozpoznaje, że dwa profile klientów to ta sama osoba. Znaczenie pojęć — decyzji i poziomów pewności — zebrano w Słowniczku.
System porównuje dwa rodzaje pól:
- pola podstawowe — imię, nazwisko, data urodzenia i płeć; są zawsze obecne,
- dane dodatkowe — e-mail, telefon i adres; nie są wymagane, ale gdy są obecne, potwierdzają lub podważają dopasowanie.
Reguły stosowane są w ustalonej kolejności — wygrywa pierwsza pasująca.
Matching klientów algorytmem boostowym¶
System porównuje dwa profile klientów i podejmuje jedną z trzech decyzji: scala je automatycznie, scala z oznaczeniem do weryfikacji, albo uznaje za różne osoby. Pod uwagę bierze trzy pola podstawowe (imię, nazwisko, data urodzenia), płeć oraz dane dodatkowe (e-mail, telefon, adres). Każde pole oceniane jest osobno — jako zgodne, drobna literówka, niezgodne lub brak danych.
Reguły stosowane są w ustalonej kolejności — wygrywa pierwsza pasująca. Szczegóły poszczególnych reguł opisują dalsze sekcje tego rozdziału.
Wspólne imię to za mało — pozostałe pola podstawowe muszą do siebie pasować¶
Imię jest polem o najniższej rozróżnialności: Anna, Jan, Maria powtarzają się w milionach rekordów. Dlatego samo dopasowanie imienia nie daje żadnej podstawy do scalenia — konieczne jest jednoczesne pasowanie nazwiska i daty urodzenia.
Scenariusz: Osoby o tym samym imieniu ale różnych nazwiskach i datach urodzenia NIE powinny być zmatchowane
Zakładając że mam klienta "Anna Nowak":
| Pole | Wartość |
|---|---|
| FirstName | Anna |
| LastName | Nowak |
| BirthDate | 1982-03-15 |
| Gender | K |
| anna.n82@gmail.com | |
| Phone | +48501234567 |
I mam klienta "Anna Kowalska":
| Pole | Wartość |
|---|---|
| FirstName | Anna |
| LastName | Kowalska |
| BirthDate | 1975-11-22 |
| Gender | K |
| a.kowalska@wp.pl | |
| Phone | +48602345678 |
I mam klienta "Anna Wiśniewska":
| Pole | Wartość |
|---|---|
| FirstName | Anna |
| LastName | Wiśniewska |
| BirthDate | 1990-07-03 |
| Gender | K |
| ania.w90@onet.pl | |
| Phone | +48703456789 |
Kiedy porównuję wszystkie pary klientów
Wtedy żadna para NIE powinna być zmatchowana
Identyczne pola podstawowe dają scalenie automatyczne — literówka bez potwierdzenia już nie¶
Gdy imię, nazwisko i data urodzenia są identyczne i nie ma konfliktu w danych dodatkowych (e-mail, telefon, adres), system scala profile automatycznie. Jedna literówka w nazwisku bez żadnego potwierdzenia kontaktowego jest zbyt ryzykowna — system odrzuca taką parę. Natomiast ten sam e-mail przy drobnej różnicy kieruje parę do kolejki weryfikacji, bo e-mail jest silnym dowodem tożsamości.
Scenariusz: Identyczne dane osobowe powinny dać AutoMerge
Zakładając że mam klienta "Jan Kowalski A":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-05-15 |
| Gender | M |
I mam klienta "Jan Kowalski B":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-05-15 |
| Gender | M |
Kiedy porównuję wszystkie pary klientów
Wtedy każda para powinna być zmatchowana automatycznie
Scenariusz: Literówka w nazwisku bez danych kontaktowych — Different
Zakładając że mam klienta "Jan Kowalski":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-05-15 |
| Gender | M |
I mam klienta "Jan Kowlaski":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowlaski |
| BirthDate | 1985-05-15 |
| Gender | M |
Kiedy porównuję wszystkie pary klientów
Wtedy żadna para NIE powinna być zmatchowana
Scenariusz: Ten sam email i data z drobną różnicą w nazwisku powinny dać AutoMergeWithReview
Zakładając że mam klienta "Anna Nowak":
| Pole | Wartość |
|---|---|
| FirstName | Anna |
| LastName | Nowak |
| BirthDate | 1990-03-20 |
| Gender | K |
| anna@example.com |
I mam klienta "Anna Novak":
| Pole | Wartość |
|---|---|
| FirstName | Anna |
| LastName | Novak |
| BirthDate | 1990-03-20 |
| Gender | K |
| anna@example.com |
Kiedy porównuję wszystkie pary klientów
Wtedy każda para powinna trafić do review
Wyraźne niezgodności w polach podstawowych wykluczają scalenie¶
Jeśli data urodzenia lub imię są wyraźnie różne — nie literówka, lecz inny rok, inny miesiąc, inne imię — system uznaje parę za różne osoby, niezależnie od danych dodatkowych. Zamiana dnia z miesiącem to częsty błąd przy wpisywaniu danych, ale bez dodatkowego potwierdzenia jest zbyt niejednoznaczna, żeby ją zaakceptować.
Scenariusz: Zamieniony dzień i miesiąc w dacie bez danych kontaktowych — Different
Zakładając że mam klienta "Jan Kowalski 0305":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-03-05 |
| Gender | M |
I mam klienta "Jan Kowalski 0503":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-05-03 |
| Gender | M |
Kiedy porównuję wszystkie pary klientów
Wtedy żadna para NIE powinna być zmatchowana
Scenariusz: Literówka w nazwisku przy identycznej dacie bez danych kontaktowych — Different
Zakładając że mam klienta "Piotr Wiśniewski":
| Pole | Wartość |
|---|---|
| FirstName | Piotr |
| LastName | Wiśniewski |
| BirthDate | 1978-08-10 |
| Gender | M |
I mam klienta "Piotr Wiśnieski":
| Pole | Wartość |
|---|---|
| FirstName | Piotr |
| LastName | Wiśnieski |
| BirthDate | 1978-08-10 |
| Gender | M |
Kiedy porównuję wszystkie pary klientów
Wtedy żadna para NIE powinna być zmatchowana
Scenariusz: Podwójne nazwisko po ślubie bez danych kontaktowych — Different
Zakładając że mam klienta "Anna Kowalska panieńskie":
| Pole | Wartość |
|---|---|
| FirstName | Anna |
| LastName | Kowalska |
| BirthDate | 1992-04-10 |
| Gender | K |
I mam klienta "Anna Kowalska-Nowak po ślubie":
| Pole | Wartość |
|---|---|
| FirstName | Anna |
| LastName | Kowalska-Nowak |
| BirthDate | 1992-04-10 |
| Gender | K |
Kiedy porównuję wszystkie pary klientów
Wtedy żadna para NIE powinna być zmatchowana
Różne dane to różne osoby — nawet gdy jedno pole się zgadza¶
Gdy dwa profile różnią się w więcej niż jednym polu podstawowym, nie ma podstaw do scalenia. Wspólne nazwisko przy różnym imieniu i dacie urodzenia to za mało. Niezgodna płeć przy identycznych pozostałych danych wskazuje na błąd w danych źródłowych, a nie na duplikat.
Scenariusz: To samo nazwisko ale różne imię i data NIE powinny być zmatchowane
Zakładając że mam klienta "Jan Kowalski 1985":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-05-15 |
| Gender | M |
I mam klienta "Piotr Kowalski 1960":
| Pole | Wartość |
|---|---|
| FirstName | Piotr |
| LastName | Kowalski |
| BirthDate | 1960-11-30 |
| Gender | M |
Kiedy porównuję wszystkie pary klientów
Wtedy żadna para NIE powinna być zmatchowana
Scenariusz: Niezgodna płeć przy identycznych danych NIE powinna być zmatchowana
Zakładając że mam klienta "Jan Kowalski M":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-05-15 |
| Gender | M |
I mam klienta "Jan Kowalski K":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-05-15 |
| Gender | K |
Kiedy porównuję wszystkie pary klientów
Wtedy żadna para NIE powinna być zmatchowana
Scenariusz: Różne nazwisko z tym samym imieniem i datą NIE powinny być zmatchowane
Zakładając że mam klienta "Anna Mankowska":
| Pole | Wartość |
|---|---|
| FirstName | Anna |
| LastName | Mankowska |
| BirthDate | 1990-06-15 |
| Gender | K |
I mam klienta "Anna Anuszewska":
| Pole | Wartość |
|---|---|
| FirstName | Anna |
| LastName | Anuszewska |
| BirthDate | 1990-06-15 |
| Gender | K |
Kiedy porównuję wszystkie pary klientów
Wtedy żadna para NIE powinna być zmatchowana
Scenariusz: Podobne nazwisko ale zupełnie inna data NIE powinny być zmatchowane
Zakładając że mam klienta "Maria Zielińska 1955":
| Pole | Wartość |
|---|---|
| FirstName | Maria |
| LastName | Zielińska |
| BirthDate | 1955-02-14 |
| Gender | K |
I mam klienta "Maria Zielińska 1988":
| Pole | Wartość |
|---|---|
| FirstName | Maria |
| LastName | Zielińska |
| BirthDate | 1988-09-22 |
| Gender | K |
Kiedy porównuję wszystkie pary klientów
Wtedy żadna para NIE powinna być zmatchowana
Złożone imiona traktowane są jako zbiór — wystarczy część wspólna¶
Polacy często używają tylko jednego z dwóch imion nadanych przy urodzeniu. "Anna Agnieszka" i "Anna" to ta sama osoba — wystarczy że jedno imię z zestawu pasuje. Kolejność imion nie ma znaczenia: "Agnieszka Anna" = "Anna Agnieszka". Jeśli żadne imię z jednego zestawu nie pasuje do żadnego z drugiego, to są to różne osoby — samo wspólne nazwisko i data nie wystarczą.
Scenariusz: Złożone imię vs jedno powinno dać AutoMerge
Zakładając że mam klienta "Anna Agnieszka Kowalska":
| Pole | Wartość |
|---|---|
| FirstName | Anna Agnieszka |
| LastName | Kowalska |
| BirthDate | 1990-06-15 |
| Gender | K |
I mam klienta "Anna Kowalska":
| Pole | Wartość |
|---|---|
| FirstName | Anna |
| LastName | Kowalska |
| BirthDate | 1990-06-15 |
| Gender | K |
Kiedy porównuję wszystkie pary klientów
Wtedy każda para powinna być zmatchowana automatycznie
Scenariusz: Odwrócona kolejność złożonego imienia powinna dać AutoMerge
Zakładając że mam klienta "Agnieszka Anna Kowalska":
| Pole | Wartość |
|---|---|
| FirstName | Agnieszka Anna |
| LastName | Kowalska |
| BirthDate | 1990-06-15 |
| Gender | K |
I mam klienta "Anna Agnieszka Kowalska 2":
| Pole | Wartość |
|---|---|
| FirstName | Anna Agnieszka |
| LastName | Kowalska |
| BirthDate | 1990-06-15 |
| Gender | K |
Kiedy porównuję wszystkie pary klientów
Wtedy każda para powinna być zmatchowana automatycznie
Scenariusz: Tylko drugie imię powinno dać AutoMerge
Zakładając że mam klienta "Anna Agnieszka Kowalska 3":
| Pole | Wartość |
|---|---|
| FirstName | Anna Agnieszka |
| LastName | Kowalska |
| BirthDate | 1990-06-15 |
| Gender | K |
I mam klienta "Agnieszka Kowalska":
| Pole | Wartość |
|---|---|
| FirstName | Agnieszka |
| LastName | Kowalska |
| BirthDate | 1990-06-15 |
| Gender | K |
Kiedy porównuję wszystkie pary klientów
Wtedy każda para powinna być zmatchowana automatycznie
Scenariusz: Literówka w jednym z imion złożonych powinna dać AutoMerge
Zakładając że mam klienta "Anna Agnieszka Kowalska 4":
| Pole | Wartość |
|---|---|
| FirstName | Anna Agnieszka |
| LastName | Kowalska |
| BirthDate | 1990-06-15 |
| Gender | K |
I mam klienta "Anna Agniszka Kowalska":
| Pole | Wartość |
|---|---|
| FirstName | Anna Agniszka |
| LastName | Kowalska |
| BirthDate | 1990-06-15 |
| Gender | K |
Kiedy porównuję wszystkie pary klientów
Wtedy każda para powinna być zmatchowana automatycznie
Scenariusz: Trzy imiona vs jedno powinno dać AutoMerge
Zakładając że mam klienta "Anna Maria Agnieszka Kowalska":
| Pole | Wartość |
|---|---|
| FirstName | Anna Maria Agnieszka |
| LastName | Kowalska |
| BirthDate | 1990-06-15 |
| Gender | K |
I mam klienta "Maria Kowalska":
| Pole | Wartość |
|---|---|
| FirstName | Maria |
| LastName | Kowalska |
| BirthDate | 1990-06-15 |
| Gender | K |
Kiedy porównuję wszystkie pary klientów
Wtedy każda para powinna być zmatchowana automatycznie
Scenariusz: Zupełnie różne złożone imiona z tym samym nazwiskiem i datą NIE powinny być zmatchowane
Zakładając że mam klienta "Anna Agnieszka Kowalska 5":
| Pole | Wartość |
|---|---|
| FirstName | Anna Agnieszka |
| LastName | Kowalska |
| BirthDate | 1990-06-15 |
| Gender | K |
I mam klienta "Katarzyna Maria Kowalska":
| Pole | Wartość |
|---|---|
| FirstName | Katarzyna Maria |
| LastName | Kowalska |
| BirthDate | 1990-06-15 |
| Gender | K |
Kiedy porównuję wszystkie pary klientów
Wtedy żadna para NIE powinna być zmatchowana
Reguła potwierdzenia — niepewne pola podstawowe wymagają dowodu zewnętrznego¶
Gdy imię, nazwisko lub data urodzenia nie są identyczne (choćby drobna literówka), system nie ma pewności, czy to ta sama osoba. Potrzebuje wtedy zewnętrznego dowodu tożsamości — tego samego e-maila lub telefonu. Bez żadnego potwierdzenia kontaktowego para zostaje uznana za różne osoby, nawet gdy pola podstawowe wyglądają "prawie" tak samo: niepewne pola podstawowe bez danych dodatkowych (e-mail, telefon, adres) to za mało, by scalić profile.
Niepewne pola podstawowe bez danych dodatkowych blokują scalenie¶
Literówka w nazwisku, dzień różnicy w dacie urodzenia — każda z tych niedoskonałości może być błędem wpisywania albo inną osobą. Samo "prawie" w polach podstawowych nie wystarczy do scalenia. E-mail lub telefon działają jako niezależny dowód: ta sama skrzynka pocztowa przy drobnej różnicy w nazwisku to silna przesłanka, że to ten sam człowiek. Dlatego para z niepewnymi polami podstawowymi i pasującym e-mailem trafia do kolejki weryfikacji — a nie do kosza.
Scenariusz: Literówki we wszystkich core fields blokują auto-merge
Zakładając że mam klienta "A":
| Pole | Wartość |
|---|---|
| FirstName | Tomasz |
| LastName | Kowalski |
| BirthDate | 1985-03-15 |
| Gender | M |
I mam klienta "B":
| Pole | Wartość |
|---|---|
| FirstName | Toamsz |
| LastName | Kowlaski |
| BirthDate | 1985-03-16 |
| Gender | M |
Kiedy porównuję wszystkie pary klientów
Wtedy decyzja to Different
Scenariusz: Literówka w nazwisku bez danych kontaktowych nie trafia do review
Zakładając że mam klienta "A":
| Pole | Wartość |
|---|---|
| FirstName | Tomasz |
| LastName | Kowalski |
| BirthDate | 1985-03-15 |
| Gender | M |
I mam klienta "B":
| Pole | Wartość |
|---|---|
| FirstName | Tomasz |
| LastName | Kowlaski |
| BirthDate | 1985-03-15 |
| Gender | M |
Kiedy porównuję wszystkie pary klientów
Wtedy decyzja to Different
Scenariusz: Literówka w dacie urodzenia bez danych kontaktowych — Different
Zakładając że mam klienta "A":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-05-15 |
| Gender | M |
I mam klienta "B":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-05-16 |
| Gender | M |
Kiedy porównuję wszystkie pary klientów
Wtedy decyzja to Different
Scenariusz: Literówka w dacie urodzenia ale ten sam email — AutoMergeWithReview
Zakładając że mam klienta "A":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-05-15 |
| Gender | M |
| jan@example.com |
I mam klienta "B":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-05-16 |
| Gender | M |
| jan@example.com |
Kiedy porównuję wszystkie pary klientów
Wtedy decyzja to AutoMergeWithReview
Scenariusz: Literówka w nazwisku ale ten sam telefon — AutoMergeWithReview
Zakładając że mam klienta "A":
| Pole | Wartość |
|---|---|
| FirstName | Tomasz |
| LastName | Kowalski |
| BirthDate | 1985-03-15 |
| Gender | M |
| Phone | 600100200 |
I mam klienta "B":
| Pole | Wartość |
|---|---|
| FirstName | Tomasz |
| LastName | Kowlaski |
| BirthDate | 1985-03-15 |
| Gender | M |
| Phone | 600100200 |
Kiedy porównuję wszystkie pary klientów
Wtedy decyzja to AutoMergeWithReview
Scenariusz: Exact match w dacie urodzenia przy fuzzy imieniu i nazwisku — Different
Zakładając że mam klienta "A":
| Pole | Wartość |
|---|---|
| FirstName | Krzysztof |
| LastName | Kowalski |
| BirthDate | 1985-03-15 |
| Gender | M |
I mam klienta "B":
| Pole | Wartość |
|---|---|
| FirstName | Krzyztof |
| LastName | Kowlaski |
| BirthDate | 1985-03-15 |
| Gender | M |
Kiedy porównuję wszystkie pary klientów
Wtedy decyzja to Different
Reguły porównania oparte na danych dodatkowych (e-mail, telefon, adres)¶
E-mail, telefon i adres to dane dodatkowe — nie są wymagane, ale gdy są obecne, aktywnie wpływają na decyzję systemu. Mogą zarówno podwyższyć pewność pary (ten sam e-mail to silny dowód tożsamości), jak i ją obniżyć (różny e-mail to sygnał, że to inne osoby, nawet przy identycznych danych podstawowych). System stosuje regułę 50%: jeśli co najmniej połowa obecnych danych kontaktowych wskazuje na konflikt, para zostaje uznana za różne osoby niezależnie od stanu danych podstawowych.
Minimum 2 zgodne dane podstawowe — jedno pole to za mało¶
Imię jest najmniej rozróżniającym polem — wiele osób nosi to samo imię. Samo pasujące imię przy niedokładnym nazwisku i dacie urodzenia nie daje żadnej podstawy do scalenia. System wymaga, by co najmniej 2 z danych podstawowych (imię, nazwisko, data urodzenia) były w pełni zgodne. Gdy zgodne jest tylko jedno, para zostaje uznana za różne osoby niezależnie od danych dodatkowych.
Scenariusz: Perfect imię, literówka nazwisko, cyfrówka data, brak dodatkowych — Different
Zakładając że mam klienta "Jan Kowalski 1985-03-15":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-03-15 |
| Gender | M |
I mam klienta "Jan Kowlaski 1985-03-16":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowlaski |
| BirthDate | 1985-03-16 |
| Gender | M |
Kiedy porównuję wszystkie pary klientów
Wtedy decyzja to Different
Reguła 50% — większość obecnych danych kontaktowych musi potwierdzać¶
Gdy dane podstawowe nie są w pełni zgodne (np. drobna literówka w dacie urodzenia), dane kontaktowe stają się kluczowe. Jeśli profil A ma e-mail X i telefon Y, a profil B ma e-mail Z i telefon W — oba pola wskazują na konflikt. Mniej niż połowa zgodnych pól kontaktowych oznacza decyzję „różne osoby". Ta reguła chroni przed efektem „mostu": profilem bez danych kontaktowych, który przez same dane podstawowe mógłby błędnie połączyć dwie różne osoby o tym samym imieniu i nazwisku.
Scenariusz: Perfect imię+nazwisko, cyfrówka data, zupełnie różne dane dodatkowe — Different
Zakładając że mam klienta "Anna Nowak A":
| Pole | Wartość |
|---|---|
| FirstName | Anna |
| LastName | Nowak |
| BirthDate | 1990-05-10 |
| Gender | K |
| anna@gmail.com | |
| Phone | 48501234567 |
| Street | Marszalkowska |
| HouseNumber | 12 |
| City | Warszawa |
| PostalCode | 00-001 |
I mam klienta "Anna Nowak B":
| Pole | Wartość |
|---|---|
| FirstName | Anna |
| LastName | Nowak |
| BirthDate | 1990-05-11 |
| Gender | K |
| xyz@yahoo.com | |
| Phone | 48999887766 |
| Street | Krucza |
| HouseNumber | 99 |
| City | Krakow |
| PostalCode | 30-999 |
Kiedy porównuję wszystkie pary klientów
Wtedy decyzja to Different
Nawet w pełni zgodne dane podstawowe nie chronią przed konfliktem danych kontaktowych¶
Identyczne imię, nazwisko i data urodzenia to mocny sygnał — ale nie niepodważalny. Dwie różne osoby mogą mieć te same dane podstawowe, szczególnie przy popularnych nazwiskach i bliskich datach urodzenia. Jeśli mają różne adresy e-mail, reguła 50% uznaje parę za różne osoby. Bez tej zasady różne osoby o tym samym imieniu, nazwisku i roczniku byłyby błędnie łączone w jeden profil mimo odmiennego e-maila i telefonu.
Scenariusz: Perfect core, różny email — Different
Zakładając że mam klienta "Jan Kowalski email A":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-05-15 |
| Gender | M |
| jan@gmail.com |
I mam klienta "Jan Kowalski email B":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-05-15 |
| Gender | M |
| other@onet.pl |
Kiedy porównuję wszystkie pary klientów
Wtedy decyzja to Different
Scenariusz: Perfect core, różny telefon — Different
Zakładając że mam klienta "Jan Kowalski phone A":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-05-15 |
| Gender | M |
| Phone | 48501234567 |
I mam klienta "Jan Kowalski phone B":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-05-15 |
| Gender | M |
| Phone | 48999887766 |
Kiedy porównuję wszystkie pary klientów
Wtedy decyzja to Different
Scenariusz: Perfect core, identyczny email — AutoMerge
Zakładając że mam klienta "Jan Kowalski email same A":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-05-15 |
| Gender | M |
| jan@kowalski.pl |
I mam klienta "Jan Kowalski email same B":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-05-15 |
| Gender | M |
| jan@kowalski.pl |
Kiedy porównuję wszystkie pary klientów
Wtedy decyzja to AutoMerge
Częściowo zgodny adres przy niepełnej zgodności danych podstawowych kieruje do weryfikacji¶
Adres jest dodatkowym dowodem, ale słabszym niż e-mail czy telefon — ludzie się przeprowadzają, wpisują adresy niedbale, jeden profil ma numer mieszkania a drugi nie. Gdy dane podstawowe nie są w pełni zgodne (np. inna data urodzenia), a adresy są niemal takie same (ta sama ulica, numer domu, miasto), para trafia do kolejki weryfikacji zamiast być automatycznie scalona lub uznana za różne osoby. Prefiks „ul." nie wpływa na wynik — system usuwa go przed porównaniem.
Scenariusz: Większość adresu zgodna, brak nr mieszkania w jednym, literówka w kodzie pocztowym — AutoMergeWithReview
Zakładając że mam klienta "Jan Kowalski adres A":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-05-15 |
| Gender | M |
| Street | Marszalkowska |
| HouseNumber | 12 |
| ApartmentNumber | 5 |
| City | Warszawa |
| PostalCode | 00-001 |
I mam klienta "Jan Kowalski adres B":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-05-16 |
| Gender | M |
| Street | Marszalkowska |
| HouseNumber | 12 |
| City | Warszawa |
| PostalCode | 00-001 |
Kiedy porównuję wszystkie pary klientów
Wtedy decyzja to AutoMergeWithReview
Scenariusz: Adres zgodny, prefiks "ul." w jednym — AutoMergeWithReview
Zakładając że mam klienta "Jan Kowalski ul A":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-05-15 |
| Gender | M |
| Street | Marszalkowska |
| HouseNumber | 12 |
| City | Warszawa |
| PostalCode | 00-001 |
I mam klienta "Jan Kowalski ul B":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-05-16 |
| Gender | M |
| Street | ul. Marszalkowska |
| HouseNumber | 12 |
| City | Warszawa |
| PostalCode | 00-001 |
Kiedy porównuję wszystkie pary klientów
Wtedy decyzja to AutoMergeWithReview
Rozpoznawanie zmiany nazwiska po ślubie¶
Zmiana nazwiska po ślubie to częsty przypadek: ta sama klientka, dwa różne profile z dwoma różnymi nazwiskami. Standardowe reguły uznałyby taką parę za różne osoby z powodu niezgodnego nazwiska. System ma dedykowaną regułę: gdy nazwisko się nie zgadza, ale imię i data urodzenia są identyczne, a ten sam e-mail lub telefon łączy oba profile — para trafia do kolejki weryfikacji. E-mail i telefon są tu kluczem: bez niezależnego dowodu tożsamości nie ma podstaw do scalenia, bo może to być po prostu inna osoba.
Ten sam e-mail lub telefon wystarczy do identyfikacji przy zmianie nazwiska¶
Dwie osoby o tym samym imieniu, tej samej dacie urodzenia, ale innym nazwisku normalnie zostałyby uznane za różne osoby. Jeśli jednak mają ten sam e-mail — to e-mail, a nie nazwisko, jest dowodem tożsamości. Zmiana nazwiska to jedyny przypadek, w którym niezgodne nazwisko nie kończy oceny od razu. Reguła działa tylko przy ściśle określonym zestawie: zgodne imię, zgodna data urodzenia oraz zgodny e-mail lub telefon. Każde odstępstwo (inna data urodzenia, inne imię, brak danych kontaktowych) oznacza decyzję „różne osoby".
Scenariusz: Ta sama osoba z nowym nazwiskiem i tym samym emailem — AutoMergeWithReview
Zakładając że mam klienta "Anna Kowalska":
| Pole | Wartość |
|---|---|
| FirstName | Anna |
| LastName | Kowalska |
| BirthDate | 1990-05-15 |
| Gender | K |
| anna@example.com |
I mam klienta "Anna Nowak":
| Pole | Wartość |
|---|---|
| FirstName | Anna |
| LastName | Nowak |
| BirthDate | 1990-05-15 |
| Gender | K |
| anna@example.com |
Kiedy porównuję wszystkie pary klientów
Wtedy decyzja to AutoMergeWithReview
Scenariusz: Ta sama osoba z nowym nazwiskiem i tym samym telefonem — AutoMergeWithReview
Zakładając że mam klienta "Anna Kowalska telefon":
| Pole | Wartość |
|---|---|
| FirstName | Anna |
| LastName | Kowalska |
| BirthDate | 1990-05-15 |
| Gender | K |
| Phone | 48600100200 |
I mam klienta "Anna Nowak telefon":
| Pole | Wartość |
|---|---|
| FirstName | Anna |
| LastName | Nowak |
| BirthDate | 1990-05-15 |
| Gender | K |
| Phone | 48600100200 |
Kiedy porównuję wszystkie pary klientów
Wtedy decyzja to AutoMergeWithReview
Scenariusz: Różne nazwiska bez danych kontaktowych — Different
Zakładając że mam klienta "Anna Kowalska brak":
| Pole | Wartość |
|---|---|
| FirstName | Anna |
| LastName | Kowalska |
| BirthDate | 1990-05-15 |
| Gender | K |
I mam klienta "Anna Nowak brak":
| Pole | Wartość |
|---|---|
| FirstName | Anna |
| LastName | Nowak |
| BirthDate | 1990-05-15 |
| Gender | K |
Kiedy porównuję wszystkie pary klientów
Wtedy decyzja to Different
Scenariusz: Różne nazwiska i różna data urodzenia — Different
Zakładając że mam klienta "Anna Kowalska data A":
| Pole | Wartość |
|---|---|
| FirstName | Anna |
| LastName | Kowalska |
| BirthDate | 1990-05-15 |
| Gender | K |
| anna@example.com |
I mam klienta "Anna Nowak data B":
| Pole | Wartość |
|---|---|
| FirstName | Anna |
| LastName | Nowak |
| BirthDate | 1985-03-20 |
| Gender | K |
| anna@example.com |
Kiedy porównuję wszystkie pary klientów
Wtedy decyzja to Different
Scenariusz: Różne nazwiska i różne imię — Different
Zakładając że mam klienta "Anna Kowalska imie":
| Pole | Wartość |
|---|---|
| FirstName | Anna |
| LastName | Kowalska |
| BirthDate | 1990-05-15 |
| Gender | K |
| anna@example.com |
I mam klienta "Agata Nowak imie":
| Pole | Wartość |
|---|---|
| FirstName | Agata |
| LastName | Nowak |
| BirthDate | 1990-05-15 |
| Gender | K |
| anna@example.com |
Kiedy porównuję wszystkie pary klientów
Wtedy decyzja to Different
Ocena poszczególnych pól¶
Każde pole obu profili porównywane jest osobno, a wynik to jedna z czterech ocen: zgodne, drobna literówka, niezgodne lub brak danych. Imiona porównywane są dodatkowo z wykorzystaniem słownika imion — opisuje to rozdział Normalizacja.
Tolerancja na literówki zależna od długości pola¶
System porównuje dwa teksty i liczy, ile zmian liter dzieli jeden od drugiego, ale dopuszczalna liczba literówek zależy od długości pola. „Al" i „El" różnią się o połowę — nie może to być akceptowane. „Kowalski" i „Kowlaski" różnią się nieznacznie — jest to akceptowane. Przed porównaniem dane są ujednolicane: polskie znaki diakrytyczne są sprowadzane do podstawowych liter (Wiśniewski = Wisniewski), wielkość liter jest pomijana.
Tolerancja literówek zależy od długości pola — krótkie pola wymagają pełnej zgodności¶
Dopuszczalna liczba różnic: pola o długości 1-2 znaki muszą być identyczne (zero literówek), 3-4 znaki — najwyżej 1 literówka, 5 znaków i więcej — najwyżej 2 literówki. Te progi chronią przed błędnymi dopasowaniami krótkich wartości: imię „Ewa" różniące się 1 literą od „Eva" to akceptowalna literówka (długość 3, jedna różnica), ale „Ewa" i „Ava" różnią się już o dwie litery — zbyt duże ryzyko, że to inne imię. Sprowadzanie polskich znaków do podstawowych liter sprawia, że brak polskich znaków w bazie (częsty przy imporcie z zewnętrznych systemów) nie jest traktowany jako literówka.
Szablon scenariusza: Porównanie nazwisk z literówkami
Zakładając że mam nazwisko "
I mam nazwisko "
Kiedy porównuję nazwiska
Wtedy nazwiska
| nazwisko_a | nazwisko_b | wynik | # komentarz |
|---|---|---|---|
| Kowalski | Kowlaski | pasują | # 8 znaków, distance=2, OK |
| Kowalski | Kamelski | nie pasują | # 8 znaków, distance=3, za dużo |
| Nowak | Novak | pasują | # 5 znaków, distance=1, OK |
| Nowak | Novek | pasują | # 5 znaków, distance=2, OK |
| Nowak | Navek | nie pasują | # 5 znaków, distance=3, za dużo |
| Ewa | Eva | pasują | # 3 znaki, distance=1, OK |
| Ewa | Ava | nie pasują | # 3 znaki, distance=2, za dużo |
| Al | Al | pasują | # 2 znaki, exact match |
| Al | El | nie pasują | # 2 znaki, distance=1, za dużo |
Scenariusz: Brak polskich znaków nie jest literówką
Zakładając że mam nazwisko "Wiśniewski"
I mam nazwisko "Wisniewski"
Kiedy porównuję nazwiska
Wtedy nazwiska pasują
Data urodzenia¶
Daty porównywane są cyfra po cyfrze. Za drobną literówkę uznawana jest jedna pomylona cyfra (w dniu, miesiącu lub roku) albo zamiana dnia z miesiącem miejscami — to częsty błąd przy wpisywaniu. Większe rozbieżności oznaczają różne daty.
E-mail i telefon¶
E-mail porównywany jest w dwóch częściach — przed znakiem @ i po nim. Cały
adres uznawany jest za zgodny z drobną literówką tylko wtedy, gdy obie części
pasują. Numery telefonów porównywane są po samych cyfrach; dopuszczalna jest
najwyżej jedna pomylona cyfra.
Dopasowanie adresu¶
Sprawdzanie zgodności adresu¶
Adres jest sprawdzany na końcu procesu porównywania profili. System ocenia każdy element adresu osobno (miasto i kod pocztowy, ulica, numer domu i mieszkania) i wyznacza poziom zgodności: pełna zgodność, zgodność tylko miejscowości, zgodność tylko miasta przy odmiennej ulicy albo sprzeczność. Wymagany poziom zależy od siły pozostałych danych — im słabsza zgodność imienia, nazwiska i daty urodzenia, tym mocniej adres musi potwierdzać parę.
Wymagany poziom zgodności adresu zależy od siły pozostałych danych¶
Gdy wszystkie dane podstawowe są w pełni zgodne i e-mail się zgadza, wystarczy, że adres nie stoi w sprzeczności — nawet sama zgodność miasta. Gdy pozostałe dane są słabsze, do scalenia potrzebna jest pełna zgodność adresu. Sprzeczność miasta (inne miasto) przy słabej zgodności pozostałych danych zawsze blokuje scalenie. Przy silnej zgodności pozostałych danych sprzeczność adresu nie blokuje, lecz kieruje parę do weryfikacji — ludzie się przeprowadzają, a wpisy mogą pochodzić z różnych lat.
Scenariusz: Identyczny adres kompletny i 3 Perfect core — AutoMerge
Zakładając że mam klienta "Jan Kowalski adres full A":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-03-20 |
| Gender | M |
| City | Warszawa |
| Street | Marszalkowska |
| HouseNumber | 10 |
I mam klienta "Jan Kowalski adres full B":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-03-20 |
| Gender | M |
| City | Warszawa |
| Street | Marszalkowska |
| HouseNumber | 10 |
Kiedy porównuję wszystkie pary klientów
Wtedy decyzja to AutoMerge
Scenariusz: Sprzeczne miasto i 3 Perfect core — Different
Zakładając że mam klienta "Jan Kowalski conflict A":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-03-20 |
| Gender | M |
| City | Warszawa |
I mam klienta "Jan Kowalski conflict B":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-03-20 |
| Gender | M |
| City | Krakow |
Kiedy porównuję wszystkie pary klientów
Wtedy decyzja to Different
Scenariusz: Samo miasto zgodne i 3 Perfect core (score=3) — AutoMergeWithReview
Zakładając że mam klienta "Jan Kowalski location A":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-03-20 |
| Gender | M |
| City | Warszawa |
I mam klienta "Jan Kowalski location B":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-03-20 |
| Gender | M |
| City | Warszawa |
Kiedy porównuję wszystkie pary klientów
Wtedy decyzja to AutoMergeWithReview
Scenariusz: Miasto zgodne, ulice różne i 3 Perfect core (score=3) — AutoMergeWithReview
Zakładając że mam klienta "Jan Kowalski anchor A":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-03-20 |
| Gender | M |
| City | Warszawa |
| Street | Marszalkowska |
I mam klienta "Jan Kowalski anchor B":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-03-20 |
| Gender | M |
| City | Warszawa |
| Street | Krucza |
Kiedy porównuję wszystkie pary klientów
Wtedy decyzja to AutoMergeWithReview
Scenariusz: Miasto zgodne, ulice różne i birthDate z literówką (score=2.5) — Different
Zakładając że mam klienta "Jan Kowalski gate A":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-03-15 |
| Gender | M |
| City | Warszawa |
| Street | Marszalkowska |
I mam klienta "Jan Kowalski gate B":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-03-16 |
| Gender | M |
| City | Warszawa |
| Street | Krucza |
Kiedy porównuję wszystkie pary klientów
Wtedy decyzja to Different
Scenariusz: Sprzeczne miasto ale idealny core, email i telefon — AutoMergeWithReview
Zakładając że mam klienta "Jan Kowalski conflict-strong A":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-03-20 |
| Gender | M |
| jan@kowalski.pl | |
| Phone | +48501234567 |
| City | Warszawa |
I mam klienta "Jan Kowalski conflict-strong B":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-03-20 |
| Gender | M |
| jan@kowalski.pl | |
| Phone | +48501234567 |
| City | Krakow |
Kiedy porównuję wszystkie pary klientów
Wtedy każda para powinna trafić do review
Scenariusz: Brak adresu w obu rekordach i 3 Perfect core z identycznym emailem — AutoMerge
Zakładając że mam klienta "Jan Kowalski noaddr A":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-03-20 |
| Gender | M |
| jan@kowalski.pl |
I mam klienta "Jan Kowalski noaddr B":
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| BirthDate | 1985-03-20 |
| Gender | M |
| jan@kowalski.pl |
Kiedy porównuję wszystkie pary klientów
Wtedy decyzja to AutoMerge
Zawężanie kręgu kandydatów¶
Porównywanie każdego klienta z każdym innym byłoby zbyt kosztowne przy milionach profili. Dlatego system najpierw zawęża poszukiwania: dla danego klienta wybiera osoby o podobnie brzmiącym imieniu i nazwisku, tej samej płci i tym samym roku urodzenia, a następnie bierze pod uwagę do 50 najbardziej podobnych kandydatów. Dopiero ich porównuje szczegółowo według opisanych wyżej reguł. Podobieństwo brzmienia liczone jest na podstawie zapisu fonetycznego — dzięki temu różne, lecz podobnie brzmiące zapisy nazwiska trafiają do tej samej grupy.
Deduplikacja osób z zamówień¶
Każde zamówienie zawiera dane osoby. Ta sama osoba może pojawić się w setkach zamówień — za każdym razem wpisana nieco inaczej. System porównuje nowo przetworzoną osobę z istniejącymi klientami i albo łączy ją z istniejącym profilem, albo tworzy nowy profil. Wynik: jeden unikalny profil klienta ze wszystkimi jego zamówieniami, niezależnie od liczby wariantów wpisywania danych.
Klient bez danych kontaktowych nie może być „mostem" łączącym różne osoby¶
System nie połączy osób, które po porównaniu okazują się różnymi osobami. Wyobraźmy sobie trzech klientów „Jan Kowalski 1985": jeden z e-mailem jan@jan.com, drugi z e-mailem ania@ania.com, trzeci bez e-maila. Trzeci pasuje do obu pozostałych. Ale Jan z e-mailem jan@jan.com to względem Jana z e-mailem ania@ania.com różne osoby. Bez dodatkowej kontroli wszystkie trzy profile trafiłyby do jednego — łącząc dwie różne osoby. Dlatego przed połączeniem wszyscy kandydaci są sprawdzani wzajemnie: jeśli dwa już zaakceptowane profile okazują się różnymi osobami, kandydat zostaje odrzucony.
Kontekst: Zakładając że baza klientów jest pusta
Scenariusz: Identyczne osoby z różnych zamówień powinny być połączone
Zakładając że mam zamówienie "ZAM-001" z osobą:
| Pole | Wartość |
|---|---|
| Imię | Jan |
| Nazwisko | Kowalski |
| Data urodzenia | 1985-05-15 |
| Płeć | M |
I mam zamówienie "ZAM-002" z osobą:
| Pole | Wartość |
|---|---|
| Imię | Jan |
| Nazwisko | Kowalski |
| Data urodzenia | 1985-05-15 |
| Płeć | M |
Kiedy uruchamiam deduplikację
Wtedy powinien istnieć 1 klient
I klient powinien być powiązany z 2 zamówieniami
Scenariusz: Różne osoby powinny utworzyć osobnych klientów
Zakładając że mam zamówienie "ZAM-001" z osobą:
| Pole | Wartość |
|---|---|
| Imię | Jan |
| Nazwisko | Kowalski |
| Data urodzenia | 1985-05-15 |
| Płeć | M |
I mam zamówienie "ZAM-002" z osobą:
| Pole | Wartość |
|---|---|
| Imię | Anna |
| Nazwisko | Nowak |
| Data urodzenia | 1990-12-01 |
| Płeć | K |
Kiedy uruchamiam deduplikację
Wtedy powinno istnieć 2 klientów
I każdy klient powinien być powiązany z 1 zamówieniem
Scenariusz: Osoby z literówką w nazwisku bez danych kontaktowych nie powinny być połączone
Zakładając że mam zamówienie "ZAM-001" z osobą:
| Pole | Wartość |
|---|---|
| Imię | Jan |
| Nazwisko | Kowalski |
| Data urodzenia | 1985-05-15 |
| Płeć | M |
I mam zamówienie "ZAM-002" z osobą:
| Pole | Wartość |
|---|---|
| Imię | Jan |
| Nazwisko | Kowlaski |
| Data urodzenia | 1985-05-15 |
| Płeć | M |
Kiedy uruchamiam deduplikację
Wtedy powinno istnieć 2 klientów
Scenariusz: Osoby z zamienioną datą dzień/miesiąc bez danych kontaktowych nie powinny być połączone
Zakładając że mam zamówienie "ZAM-001" z osobą:
| Pole | Wartość |
|---|---|
| Imię | Jan |
| Nazwisko | Kowalski |
| Data urodzenia | 1985-03-05 |
| Płeć | M |
I mam zamówienie "ZAM-002" z osobą:
| Pole | Wartość |
|---|---|
| Imię | Jan |
| Nazwisko | Kowalski |
| Data urodzenia | 1985-05-03 |
| Płeć | M |
Kiedy uruchamiam deduplikację
Wtedy powinno istnieć 2 klientów
Scenariusz: Osoby z tym samym emailem ale różnym nazwiskiem NIE powinny być połączone
Zakładając że mam zamówienie "ZAM-001" z osobą:
| Pole | Wartość |
|---|---|
| Imię | Jan |
| Nazwisko | Kowalski |
| Data urodzenia | 1985-05-15 |
| Płeć | M |
| jan@gmail.com |
I mam zamówienie "ZAM-002" z osobą:
| Pole | Wartość |
|---|---|
| Imię | Piotr |
| Nazwisko | Nowak |
| Data urodzenia | 1990-03-20 |
| Płeć | M |
| jan@gmail.com |
Kiedy uruchamiam deduplikację
Wtedy powinno istnieć 2 klientów
Scenariusz: Osoby z literówką w nazwisku bez danych kontaktowych tworzą osobnych klientów
Zakładając że mam zamówienie "ZAM-001" z osobą:
| Pole | Wartość |
|---|---|
| Imię | Jan |
| Nazwisko | Kowalski |
| Data urodzenia | 1985-05-15 |
| Płeć | M |
I mam zamówienie "ZAM-002" z osobą:
| Pole | Wartość |
|---|---|
| Imię | Jan |
| Nazwisko | Kowaliski |
| Data urodzenia | 1985-05-15 |
| Płeć | M |
Kiedy uruchamiam deduplikację
Wtedy powinno istnieć 2 klientów
Scenariusz: Osoba z niezgodną płcią nie powinna być połączona
Zakładając że mam zamówienie "ZAM-001" z osobą:
| Pole | Wartość |
|---|---|
| Imię | Jan |
| Nazwisko | Nowak |
| Data urodzenia | 1985-05-15 |
| Płeć | M |
I mam zamówienie "ZAM-002" z osobą:
| Pole | Wartość |
|---|---|
| Imię | Anna |
| Nazwisko | Nowak |
| Data urodzenia | 1985-05-15 |
| Płeć | K |
Kiedy uruchamiam deduplikację
Wtedy powinno istnieć 2 klientów
Scenariusz: Ponowne przetworzenie zamówienia aktualizuje dane klienta
Zakładając że mam zamówienie "ZAM-001" z osobą:
| Pole | Wartość |
|---|---|
| Imię | Jan |
| Nazwisko | Kowalski |
| Data urodzenia | 1985-05-15 |
| Płeć | M |
| Telefon | +48500100200 |
Kiedy uruchamiam deduplikację
Wtedy powinien istnieć 1 klient
I klient powinien mieć telefon "+48500100200"
Kiedy zamówienie "ZAM-001" wpada ponownie z danymi:
| Pole | Wartość |
|---|---|
| Imię | Jan |
| Nazwisko | Kowalski |
| Data urodzenia | 1985-05-15 |
| Płeć | M |
| Telefon | +48600200300 |
I uruchamiam deduplikację ponownie
Wtedy powinien istnieć 1 klient
I klient powinien mieć telefon "+48600200300"
I klient powinien być powiązany z 1 zamówieniem
Scenariusz: Ponowne przetworzenie zamówienia z nowym emailem zastępuje stary email
Zakładając że mam zamówienie "ZAM-001" z osobą:
| Pole | Wartość |
|---|---|
| Imię | Anna |
| Nazwisko | Nowak |
| Data urodzenia | 1990-03-20 |
| Płeć | K |
| anna@example.com |
Kiedy uruchamiam deduplikację
Wtedy powinien istnieć 1 klient
I klient powinien mieć email "anna@example.com"
Kiedy zamówienie "ZAM-001" wpada ponownie z danymi:
| Pole | Wartość |
|---|---|
| Imię | Anna |
| Nazwisko | Nowak |
| Data urodzenia | 1990-03-20 |
| Płeć | K |
| anna.nowak@work.pl |
I uruchamiam deduplikację ponownie
Wtedy powinien istnieć 1 klient
I klient powinien mieć email "anna.nowak@work.pl"
Scenariusz: LdeCustomerId jest propagowane do nowego klienta przy merge
Zakładając że w systemie są klienci z LdeCustomerId:
| Id | FirstName | LastName | BirthDate | Gender | LdeCustomerId |
|---|---|---|---|---|---|
| 1 | Jan | Kowalski | 1985-05-15 | M | 12345 |
| 2 | Jan | Kowalski | 1985-05-15 | M | null |
Kiedy uruchamiam merge klientów 1 i 2
Wtedy nowy merged klient powinien mieć LdeCustomerId 12345
I stary klient o ID 1 powinien być usunięty
I stary klient o ID 2 powinien być usunięty
Scenariusz: LdeCustomerId jest czyszczone ze starych klientów przy merge
Zakładając że w systemie są klienci z LdeCustomerId:
| Id | FirstName | LastName | BirthDate | Gender | LdeCustomerId |
|---|---|---|---|---|---|
| 3 | Anna | Nowak | 1990-03-20 | K | 99999 |
| 4 | Anna | Nowak | 1990-03-20 | K | 99999 |
Kiedy uruchamiam merge klientów 3 i 4
Wtedy nowy merged klient powinien mieć LdeCustomerId 99999
I stary klient o ID 3 powinien być usunięty
I stary klient o ID 4 powinien być usunięty
Scenariusz: Osoba bez emaila nie powinna łączyć dwóch klientów ze sprzecznymi emailami
Zakładając że mam zamówienie "ZAM-001" z osobą:
| Pole | Wartość |
|---|---|
| Imię | Jan |
| Nazwisko | Kowalski |
| Data urodzenia | 1985-05-15 |
| Płeć | M |
| jan@jan.com |
I mam zamówienie "ZAM-002" z osobą:
| Pole | Wartość |
|---|---|
| Imię | Jan |
| Nazwisko | Kowalski |
| Data urodzenia | 1985-05-15 |
| Płeć | M |
| ania@ania.com |
I mam zamówienie "ZAM-003" z osobą:
| Pole | Wartość |
|---|---|
| Imię | Jan |
| Nazwisko | Kowalski |
| Data urodzenia | 1985-05-15 |
| Płeć | M |
Kiedy uruchamiam deduplikację
Wtedy powinno istnieć 2 klientów
I jeden klient powinien być powiązany z 2 zamówieniami
I jeden klient powinien być powiązany z 1 zamówieniem
Scenariusz: Osoba bez emaila powinna scalać się z wieloma klientami gdy mają ten sam email
Zakładając że mam zamówienie "ZAM-001" z osobą:
| Pole | Wartość |
|---|---|
| Imię | Jan |
| Nazwisko | Kowalski |
| Data urodzenia | 1985-05-15 |
| Płeć | M |
| jan@jan.com |
I mam zamówienie "ZAM-002" z osobą:
| Pole | Wartość |
|---|---|
| Imię | Jan |
| Nazwisko | Kowalski |
| Data urodzenia | 1985-05-15 |
| Płeć | M |
| jan@jan.com |
I mam zamówienie "ZAM-003" z osobą:
| Pole | Wartość |
|---|---|
| Imię | Jan |
| Nazwisko | Kowalski |
| Data urodzenia | 1985-05-15 |
| Płeć | M |
Kiedy uruchamiam deduplikację
Wtedy powinien istnieć 1 klient
I klient powinien być powiązany z 3 zamówieniami
Kolejka weryfikacji duplikatów¶
Nie wszystkie scalenia są tak samo pewne — część par system łączy z dodatkowym oznaczeniem do weryfikacji. Operator widzi je w kolejce weryfikacji z pełnym zestawem danych: oryginalne wartości pól, wynik porównania każdego pola oraz poziom pewności. Może oznaczyć scalenie jako prawidłowe lub błędne — ocena jest zapisywana do celów kontroli jakości, ale nie zmienia samego scalenia.
Scalenie z weryfikacją następuje natychmiast — kolejka jest tylko zapisem do kontroli¶
System scala parę oznaczoną do weryfikacji tak samo jak przy scaleniu automatycznym — profile są łączone od razu, nie czekają na decyzję operatora. Różnica polega na dodatkowym wpisie w kolejce weryfikacji. To podejście ostrożnościowe: lepiej scalić i dać operatorowi do sprawdzenia niż zostawić duplikaty. Ocena operatora (prawidłowe / błędne) jest rejestrowana do kontroli jakości, ale nie rozłącza już scalonych profili — kolejka weryfikacji nie ingeruje w proces deduplikacji.
Kontekst: Zakładając że baza klientów jest pusta I kolejka weryfikacji jest pusta
Scenariusz: Merge z RequiresReview trafia do kolejki weryfikacji
Zakładając że mam klienta "Jan Kowalski" urodzony "1985-05-15"
I mam klienta "Jan Kowalski" urodzony "1985-05-15"
Kiedy wykonuję merge z flagą RequiresReview
Wtedy klienci powinni być połączeni
I w kolejce weryfikacji powinna być 1 pozycja ze statusem "Pending"
I wpis powinien mieć MatchConfidence "Medium"
I wpis powinien zawierać SourceCustomerIds
Scenariusz: Merge bez RequiresReview nie trafia do kolejki
Zakładając że mam klienta "Jan Kowalski" urodzony "1985-05-15" z emailem "jan@test.pl"
I mam klienta "Jan Kowalski" urodzony "1985-05-15" z emailem "jan@test.pl"
Kiedy wykonuję merge bez flagi RequiresReview
Wtedy klienci powinni być połączeni
I kolejka weryfikacji powinna być pusta
Scenariusz: Brak dopasowania nie tworzy wpisu w kolejce
Zakładając że mam klienta "Jan Kowalski" urodzony "1985-05-15"
I mam klienta "Anna Nowak" urodzony "1990-03-20"
Kiedy nie ma dopasowania między klientami
Wtedy powinno istnieć 2 aktywnych klientów
I kolejka weryfikacji powinna być pusta
Scenariusz: Wpis w kolejce zawiera szczegóły dopasowania
Zakładając że mam klienta "Piotr Wisniewski" urodzony "1975-08-20" z telefonem "+48500100200"
I mam klienta "Piotr Wisniewski" urodzony "1975-08-20" z telefonem "+48500100200"
Kiedy wykonuję merge z flagą RequiresReview i MatchDetails
Wtedy wpis powinien mieć MatchDetails z LastName = Perfect
I wpis powinien mieć MatchDetails z Phone = Perfect
Dopasowanie po identyfikatorze LDE¶
Jeśli klient jest powiązany z kontem w zewnętrznym systemie lojalnościowym LDE, ma przypisany identyfikator LDE. Zanim system zacznie porównywać dane osobowe, sprawdza, czy istnieje inny klient z tym samym identyfikatorem LDE. Jeśli tak — to na pewno ta sama osoba, więc profile są scalane z pewnością absolutną, nawet gdy pozostałe dane się nie zgadzają. Szczegóły powiązania: Integracje.
Jak powstają dane scalonego profilu¶
Gdy system łączy kilka profili w jeden, dane wspólnego profilu powstają z połączenia danych ze wszystkich łączonych zamówień:
- imię, nazwisko, data urodzenia, płeć — pierwsza niepusta wartość, licząc od najnowszego zamówienia (najnowsze dane mają pierwszeństwo),
- e-maile i telefony — sumowane ze wszystkich zamówień, bez duplikatów,
- adres — budowany stopniowo: zaczyna od najnowszego adresu, a starsze zamówienia uzupełniają brakujące elementy; przy sprzeczności (inne miasto lub kod pocztowy) uzupełnianie zatrzymuje się.
Ten sam sposób obliczania danych stosowany jest przy każdej aktualizacji profilu.