Normalizacja danych¶
Zanim system zacznie szukać duplikatów, dane z zamówień muszą zostać uporządkowane. Rozdział opisuje, jak Deduplikator porządkuje poszczególne typy danych — imiona, telefony, adresy e-mail i adresy. Wszystkie reguły są odporne na dane brakujące i śmieciowe oraz obsługują pola wielokrotne (kilka adresów e-mail, kilka telefonów).
Imiona i nazwiska¶
Imiona i nazwiska są oczyszczane z nadmiarowych spacji i powtórzonych liter, sprowadzane do formy z wielką literą na początku (z wyjątkami dla przedrostków takich jak „von" czy „de") oraz pozbawiane polskich znaków diakrytycznych na potrzeby porównań. Wartości śmieciowe — takie jak „test", „xxx" czy ciągi jednego znaku — są odrzucane. Imiona złożone są dzielone na osobne części (np. „Anna-Maria" → „Anna", „Maria"), a każda część porządkowana niezależnie.
Normalizacja danych osobowych z zamówień¶
Dane z zamówień Rainbow przychodzą w surowym stanie: imię pisane WIELKIMI LITERAMI, pola odwrócone (nazwisko w polu imienia), telefony oddzielone średnikiem, adresy e-mail oddzielone przecinkiem, kody pocztowe z literą O zamiast cyfry 0. Normalizacja jest pierwszym krokiem przetwarzania — zanim system zacznie szukać duplikatów, dane muszą być w ujednoliconej formie.
Płeć jest wywodzona z imienia, nie z pola płci¶
Pole płci w zamówieniu jest często błędne lub puste — formularz pozwala wpisać cokolwiek. Imię i końcówka nazwiska (-ski/-ska) są bardziej wiarygodne. System ustala płeć na podstawie imienia i nazwiska; jeśli wynik jest pewny — nadpisuje wartość z formularza. Jeśli imię jest nieznane — używa płci z zamówienia. Dzięki temu błędna płeć w zamówieniu nie powoduje niesłusznego odrzucenia pary.
Zamienione imię i nazwisko są wykrywane i korygowane¶
Częsty błąd przy wypełnianiu formularza to wpisanie imienia w pole nazwiska i odwrotnie. System wykrywa ten wzorzec: jeśli pole imienia wygląda jak nazwisko (ma typową końcówkę), a pole nazwiska wygląda jak imię — wartości są zamieniane miejscami. Bez tej korekty "Wiśniewski Tomasz" i "Tomasz Wiśniewski" nie zostałyby rozpoznane jako ta sama osoba.
Scenariusz: Normalizacja imienia i nazwiska z wieloma spacjami
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Imię | " JAN " |
| Nazwisko | " KOWALSKI nowak " |
Kiedy normalizuję dane osoby
Wtedy imię powinno być "Jan"
I nazwisko powinno być "Kowalski Nowak"
Scenariusz: Normalizacja nazwiska dwuczłonowego
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Nazwisko | "kowalska-nowak" |
Kiedy normalizuję dane osoby
Wtedy nazwisko powinno być "Kowalska-Nowak"
Scenariusz: Normalizacja wielu emaili
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| "jan@gmail.com, anna@wp.pl" |
Kiedy normalizuję dane osoby
Wtedy lista emaili powinna zawierać 2 pozycje
I główny email powinien być "jan@gmail.com"
Scenariusz: Normalizacja wielu telefonów
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Telefon | "604-701-821; 512-362-770" |
Kiedy normalizuję dane osoby
Wtedy lista telefonów powinna zawierać 2 pozycje
I główny telefon powinien być "+48604701821"
Scenariusz: Parsowanie adresu w formacie polskim
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Adres | "ul. Marszałkowska 10/5" |
Kiedy normalizuję dane osoby
Wtedy ulica powinna być "Marszałkowska"
I numer domu powinien być "10"
I numer mieszkania powinien być "5"
Scenariusz: Normalizacja płci z różnych formatów
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Płeć | "mężczyzna" |
Kiedy normalizuję dane osoby
Wtedy płeć powinna być "Male"
Szablon scenariusza: Normalizacja płci
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Płeć | "" |
Kiedy normalizuję dane osoby
Wtedy płeć powinna być "
| input | expected |
|---|---|
| M | Male |
| m | Male |
| mężczyzna | Male |
| 1 | Male |
| K | Female |
| k | Female |
| kobieta | Female |
| F | Female |
| 2 | Female |
| Unknown | |
| X | Unknown |
Scenariusz: Normalizacja usuwa polskie diakrytyki do porównań
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Nazwisko | "Świętosław Żółw" |
Kiedy normalizuję dane osoby
Wtedy znormalizowane nazwisko do porównań powinno być "swietoslaw zolw"
Scenariusz: Zgadywanie płci na podstawie męskiego imienia
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Imię | "Jan" |
| Nazwisko | "Nowak" |
Kiedy normalizuję dane osoby
Wtedy płeć powinna być "Male"
Scenariusz: Zgadywanie płci na podstawie żeńskiego imienia
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Imię | "Anna" |
| Nazwisko | "Nowak" |
Kiedy normalizuję dane osoby
Wtedy płeć powinna być "Female"
Scenariusz: Zgadywanie płci z końcówki nazwiska -ski
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Imię | "Alex" |
| Nazwisko | "Kowalski" |
Kiedy normalizuję dane osoby
Wtedy płeć powinna być "Male"
Scenariusz: Zgadywanie płci z końcówki nazwiska -ska
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Imię | "Alex" |
| Nazwisko | "Kowalska" |
Kiedy normalizuję dane osoby
Wtedy płeć powinna być "Female"
Scenariusz: GenderGuesser ma priorytet nad płcią z zamówienia
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Imię | "Anna" |
| Nazwisko | "Kowalska" |
| Płeć | "M" |
Kiedy normalizuję dane osoby
Wtedy płeć powinna być "Female"
Scenariusz: Fallback do płci z zamówienia gdy imię nieznane
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Imię | "Xyzzy" |
| Nazwisko | "Nowak" |
| Płeć | "K" |
Kiedy normalizuję dane osoby
Wtedy płeć powinna być "Female"
Scenariusz: Zgadywanie płci dla złożonych imion żeńskich
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Imię | "Anna Agnieszka" |
| Nazwisko | "Nowak" |
Kiedy normalizuję dane osoby
Wtedy płeć powinna być "Female"
Scenariusz: Zgadywanie płci dla imienia z polskimi diakrytykami
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Imię | "Małgorzata" |
| Nazwisko | "Nowak" |
Kiedy normalizuję dane osoby
Wtedy płeć powinna być "Female"
Scenariusz: Zamienione imię i nazwisko powinno być skorygowane
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Imię | "Wiśniewski" |
| Nazwisko | "Tomasz" |
Kiedy normalizuję dane osoby
Wtedy imię powinno być "Tomasz"
I nazwisko powinno być "Wiśniewski"
I płeć powinna być "Male"
Scenariusz: Zamienione imię i nazwisko kobiece powinno być skorygowane
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Imię | "Wiśniewska" |
| Nazwisko | "Katarzyna" |
Kiedy normalizuję dane osoby
Wtedy imię powinno być "Katarzyna"
I nazwisko powinno być "Wiśniewska"
I płeć powinna być "Female"
Scenariusz: Zamienione pola z błędnym RawGender powinny być skorygowane
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Imię | "Wiśniewska" |
| Nazwisko | "Katarzyna" |
| Płeć | "M" |
Kiedy normalizuję dane osoby
Wtedy imię powinno być "Katarzyna"
I nazwisko powinno być "Wiśniewska"
I płeć powinna być "Female"
Szablon scenariusza: Litera O zamiast cyfry 0 w kodzie pocztowym
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Kod pocztowy |
Kiedy normalizuję dane osoby
Wtedy kod pocztowy powinien być "
| wejscie | oczekiwany |
|---|---|
| OO-124 | 00-124 |
| O0-124 | 00-124 |
| oo-124 | 00-124 |
| 12-3O5 | 12-305 |
| 12-345 | 12-345 |
Scenariusz: Kod złożony wyłącznie z liter O normalizuje się do placeholdera null
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Kod pocztowy | OO-OOO |
Kiedy normalizuję dane osoby
Wtedy kod pocztowy powinien być null
Normalizacja zdrobnień polskich imion¶
Polacy bardzo często wpisują zdrobnienie zamiast oficjalnego imienia. "Kasia" zamiast "Katarzyna", "Tomek" zamiast "Tomasz" — te formy są rozpoznawane i zamieniane na pełne imię przed porównaniem profili. Dzięki temu dwa profile tej samej osoby — jeden z imieniem z dowodu, drugi wpisany zdrobniale — zostaną poprawnie rozpoznane. Zamiana dotyczy TYLKO pola imienia.
Zdrobnienia imion są zamieniane przed porównaniem, ale NIGDY w nazwisku¶
Zamiana zdrobnienia na pełne imię działa tylko w polu imienia. Pole nazwiska pozostaje bez zmian — "Jurek" jako nazwisko to "Jurek", nie "Jerzy". To ważne: polskie nazwiska mogą wyglądać jak zdrobnienia imion — istnieją osoby noszące nazwisko Jurek czy Jasiek. Zamiana zdrobnień w nazwisku prowadziłaby do fałszywych korekt, zniekształcając prawdziwe dane identyfikacyjne klienta.
Szablon scenariusza: Zdrobnienie w imieniu jest normalizowane do pełnego imienia
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Imię | " |
Kiedy normalizuję dane osoby
Wtedy imię powinno być "
| zdrobnienie | pelne_imie |
|---|---|
| Kasia | Katarzyna |
| Kaśka | Katarzyna |
| Tomek | Tomasz |
| Ania | Anna |
| Anka | Anna |
| Janek | Jan |
| Jasiek | Jan |
| Staszek | Stanisław |
| Basia | Barbara |
| Piotrek | Piotr |
| Ola | Aleksandra |
| Zbyszek | Zbigniew |
Scenariusz: Pełne imię nie jest zmieniane
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Imię | "Tomasz" |
Kiedy normalizuję dane osoby
Wtedy imię powinno być "Tomasz"
Scenariusz: Nieznane imię nie jest zmieniane
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Imię | "Alessandro" |
Kiedy normalizuję dane osoby
Wtedy imię powinno być "Alessandro"
Scenariusz: Zdrobnienie z polskimi diakrytykami jest normalizowane
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Imię | "Gośka" |
Kiedy normalizuję dane osoby
Wtedy imię powinno być "Małgorzata"
Szablon scenariusza: Zdrobnienie w nazwisku NIE jest normalizowane
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Imię | " |
| Nazwisko | " |
Kiedy normalizuję dane osoby
Wtedy imię powinno być "
I nazwisko powinno być "
| imie | nazwisko | oczekiwane_imie | oczekiwane_nazwisko |
|---|---|---|---|
| Marcin | Jurek | Marcin | Jurek |
| Małgorzata | Mirek | Małgorzata | Mirek |
| Anna | Ola | Anna | Ola |
| Ola | Kasia | Aleksandra | Kasia |
| Kasia | Kowalska | Katarzyna | Kowalska |
Szablon scenariusza: Swap działa gdy nazwisko jest zdrobnieniem a imię nie jest imieniem
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Imię | " |
| Nazwisko | " |
Kiedy normalizuję dane osoby
Wtedy imię powinno być "
I nazwisko powinno być "
| imie | nazwisko | oczekiwane_imie | oczekiwane_nazwisko |
|---|---|---|---|
| Kowalski | Kasia | Katarzyna | Kowalski |
| Kowalski | Jurek | Jerzy | Kowalski |
| Nowak | Tomek | Tomasz | Nowak |
Szablon scenariusza: Swap NIE zachodzi gdy oba pola to imiona lub zdrobnienia
Zakładając że mam surowe dane osoby z zamówienia:
| Pole | Wartość |
|---|---|
| Imię | " |
| Nazwisko | " |
Kiedy normalizuję dane osoby
Wtedy nazwisko powinno być "
| imie | nazwisko | oczekiwane_nazwisko |
|---|---|---|
| Jerzy | Jurek | Jurek |
| Jurek | Jerzy | Jerzy |
| Anna | Aleksander | Aleksander |
| Kasia | Jurek | Jurek |
| Marcin | Jerzy | Jerzy |
Porównywanie imion z wykorzystaniem słownika¶
Sama tolerancja literówek nie rozróżnia „Ada" od „Ida" — różnią się o jedną literę i mieszczą się w progu dla trzyliterowego pola. Ale to dwa różne imiona. Słownik polskich imion zawiera znane imiona i zapobiega błędnym dopasowaniom: gdy oba imiona są w słowniku i są różne, system uznaje je za niezgodne, a nie za drobną literówkę. Gdy jedno z imion nie występuje w słowniku (np. imię obce lub rzadkie), stosowana jest standardowa tolerancja literówek.
Dwa różne znane imiona to różne imiona, nie literówki¶
Słownik chroni przed najpoważniejszymi błędnymi dopasowaniami — dwa różne imiona obecne w słowniku nigdy nie zostaną uznane za literówkę jedno drugiego. Identyczne imiona pasują zawsze. Gdy jedno imię jest w słowniku, a drugiego w nim nie ma, stosowana jest tolerancja literówek — nieznane imię może być rzadkim wariantem, błędem wpisywania lub imieniem zagranicznym.
Scenariusz: Dwa różne imiona słownikowe nie są matchowane
Zakładając że mam klienta "A":
| Pole | Wartość |
|---|---|
| FirstName | Ada |
| LastName | Kowalska |
| BirthDate | 1985-05-15 |
| Gender | K |
I mam klienta "B":
| Pole | Wartość |
|---|---|
| FirstName | Ida |
| LastName | Kowalska |
| BirthDate | 1985-05-15 |
| Gender | K |
Kiedy porównuję imiona klientów "A" i "B"
Wtedy imiona nie pasują do siebie
Scenariusz: Literówka w imieniu niesłownikowym jest tolerowana
Zakładając że mam klienta "A":
| Pole | Wartość |
|---|---|
| FirstName | Krzysztof |
| LastName | Kowalski |
| BirthDate | 1985-05-15 |
| Gender | M |
I mam klienta "B":
| Pole | Wartość |
|---|---|
| FirstName | Krzsytof |
| LastName | Kowalski |
| BirthDate | 1985-05-15 |
| Gender | M |
Kiedy porównuję imiona klientów "A" i "B"
Wtedy imiona pasują do siebie
Scenariusz: Identyczne imiona słownikowe pasują
Zakładając że mam klienta "A":
| Pole | Wartość |
|---|---|
| FirstName | Katarzyna |
| LastName | Kowalska |
| BirthDate | 1990-06-15 |
| Gender | K |
I mam klienta "B":
| Pole | Wartość |
|---|---|
| FirstName | Katarzyna |
| LastName | Kowalska |
| BirthDate | 1990-06-15 |
| Gender | K |
Kiedy porównuję imiona klientów "A" i "B"
Wtedy imiona pasują do siebie
Scenariusz: Jedno imię słownikowe, drugie literówka — tolerancja
Zakładając że mam klienta "A":
| Pole | Wartość |
|---|---|
| FirstName | Katarzyna |
| LastName | Kowalska |
| BirthDate | 1990-06-15 |
| Gender | K |
I mam klienta "B":
| Pole | Wartość |
|---|---|
| FirstName | Katarzna |
| LastName | Kowalska |
| BirthDate | 1990-06-15 |
| Gender | K |
Kiedy porównuję imiona klientów "A" i "B"
Wtedy imiona pasują do siebie
Telefony¶
Numery telefonów są oczyszczane ze znaków innych niż cyfry i sprowadzane do polskiego standardu (numer kierunkowy kraju + dziewięć cyfr). Numery w nieprawidłowym formacie są odrzucane. Pole może zawierać kilka numerów oddzielonych przecinkiem lub średnikiem — każdy jest przetwarzany osobno.
| Format wejściowy | Po uporządkowaniu |
|---|---|
123-456-789 |
48123456789 |
+48 123 456 789 |
48123456789 |
0048123456789 |
48123456789 |
Adresy e-mail¶
Adresy e-mail są zapisywane małymi literami i sprawdzane pod kątem poprawności.
Dla adresów Gmail pomijane są kropki w części przed znakiem @ — Gmail traktuje
jan.kowalski@gmail.com i jankowalski@gmail.com jako ten sam adres. Pole może
zawierać kilka adresów — każdy jest przetwarzany osobno.
Adresy¶
Adres dostawy jest rozkładany na elementy składowe: ulicę, numer domu, numer mieszkania, miasto i kod pocztowy. System rozpoznaje typowe polskie formaty zapisu, m.in. przedrostki nazw ulic („ul.", „al.", „pl.", „os.") oraz różne sposoby zapisu numeru mieszkania („10/5", „10 m. 5", „10 lok. 5").
W kodzie pocztowym częsty błąd — litera „O" zamiast cyfry „0" — jest
automatycznie poprawiany. Pięciocyfrowy kod jest sprowadzany do formatu
XX-XXX. Nazwa miasta jest porządkowana i sprawdzana pod kątem wartości
zastępczych (np. „Brak", „N/A").
Normalizacja kontaktów płatnika¶
W zamówieniu grupowym jeden uczestnik jest płatnikiem — to on podaje swój kontakt. Formularze często kopiują e-mail lub telefon płatnika do pól pozostałych uczestników. To nie są dane kontaktowe tych osób — to dane płatnika. Gdyby te dane trafiły do porównywania profili, „Anna Nowak" z e-mailem płatnika „jan@gmail.com" mogłaby zostać błędnie połączona z „Jan Kowalski" mającym ten sam e-mail. Dlatego kontakty płatnika są usuwane z danych pozostałych uczestników na etapie normalizacji.
Kontakty płatnika są usuwane z danych pozostałych uczestników¶
Dla każdej osoby w zamówieniu system sprawdza, czy jej e-mail lub telefon pojawia się w danych płatnika tego samego zamówienia. Jeśli tak, a osoba nie jest płatnikiem — ten kontakt zostaje usunięty. Wyjątek: gdy uczestnik ma więcej niż jeden e-mail, a tylko jeden pochodzi od płatnika, usuwany jest wyłącznie skopiowany e-mail, a własny e-mail uczestnika pozostaje. Płatnik zawsze zachowuje wszystkie swoje kontakty bez zmian.
Kontekst: Zakładając że baza klientów jest pusta
Scenariusz: Email płatnika jest usuwany z non-payera w tym samym zamówieniu
Zakładając że mam zamówienie "ZAM-001" z płatnikiem:
| Pole | Wartość |
|---|---|
| Imię | Jan |
| Nazwisko | Kowalski |
| Data urodzenia | 1985-05-15 |
| Płeć | M |
| jan@gmail.com |
I zamówienie "ZAM-001" ma osobę nie-płatnika:
| Pole | Wartość |
|---|---|
| Imię | Anna |
| Nazwisko | Nowak |
| Data urodzenia | 1990-03-20 |
| Płeć | K |
| jan@gmail.com |
Kiedy uruchamiam deduplikację z normalizacją płatnika
Wtedy klient "Anna Nowak" nie powinien mieć żadnego emaila
Scenariusz: Telefon płatnika jest usuwany z non-payera
Zakładając że mam zamówienie "ZAM-002" z płatnikiem:
| Pole | Wartość |
|---|---|
| Imię | Jan |
| Nazwisko | Kowalski |
| Data urodzenia | 1985-05-15 |
| Płeć | M |
| Telefon | 123456789 |
I zamówienie "ZAM-002" ma osobę nie-płatnika:
| Pole | Wartość |
|---|---|
| Imię | Anna |
| Nazwisko | Nowak |
| Data urodzenia | 1990-03-20 |
| Płeć | K |
| Telefon | 123456789 |
Kiedy uruchamiam deduplikację z normalizacją płatnika
Wtedy klient "Anna Nowak" nie powinien mieć żadnego telefonu
Scenariusz: Non-payer z własnym emailem i emailem płatnika zachowuje swój email
Zakładając że mam zamówienie "ZAM-003" z płatnikiem:
| Pole | Wartość |
|---|---|
| Imię | Jan |
| Nazwisko | Kowalski |
| Data urodzenia | 1985-05-15 |
| Płeć | M |
| jan@gmail.com |
I zamówienie "ZAM-003" ma osobę nie-płatnika:
| Pole | Wartość |
|---|---|
| Imię | Anna |
| Nazwisko | Nowak |
| Data urodzenia | 1990-03-20 |
| Płeć | K |
| jan@gmail.com, anna@test.pl |
Kiedy uruchamiam deduplikację z normalizacją płatnika
Wtedy klient "Anna Nowak" powinien mieć email "anna@test.pl"
Scenariusz: Brak płatnika — kontakty nie są usuwane
Zakładając że mam zamówienie "ZAM-004" bez płatnika z osobą:
| Pole | Wartość |
|---|---|
| Imię | Jan |
| Nazwisko | Kowalski |
| Data urodzenia | 1985-05-15 |
| Płeć | M |
| jan@gmail.com |
I zamówienie "ZAM-004" ma drugą osobę bez płatnika:
| Pole | Wartość |
|---|---|
| Imię | Anna |
| Nazwisko | Nowak |
| Data urodzenia | 1990-03-20 |
| Płeć | K |
| jan@gmail.com |
Kiedy uruchamiam deduplikację z normalizacją płatnika
Wtedy klient "Anna Nowak" powinien mieć email "jan@gmail.com"
Scenariusz: Płatnik zachowuje wszystkie swoje kontakty
Zakładając że mam zamówienie "ZAM-005" z płatnikiem:
| Pole | Wartość |
|---|---|
| Imię | Jan |
| Nazwisko | Kowalski |
| Data urodzenia | 1985-05-15 |
| Płeć | M |
| jan@gmail.com | |
| Telefon | 123456789 |
I zamówienie "ZAM-005" ma osobę nie-płatnika:
| Pole | Wartość |
|---|---|
| Imię | Anna |
| Nazwisko | Nowak |
| Data urodzenia | 1990-03-20 |
| Płeć | K |
Kiedy uruchamiam deduplikację z normalizacją płatnika
Wtedy klient "Jan Kowalski" powinien mieć email "jan@gmail.com"
I klient "Jan Kowalski" powinien mieć telefon "+48123456789"
Filtrowanie kontaktów z czarnej listy¶
Niektóre e-maile i numery telefonów są nieprawdziwe lub wspólne — należą do biur podróży, pracowników wpisujących własne dane w pole klienta lub do adresów technicznych. Gdyby trafiły do porównywania danych, łączyłyby setki niezwiązanych ze sobą profili przez wspólny "kontakt". Czarna lista pozwala operatorowi zaimportować listę takich kontaktów z pliku CSV; system usuwa je z danych klienta przed porównywaniem danych.
Kontakt z czarnej listy jest usuwany z danych klienta i nie blokuje importu¶
Zamówienie z e-mailem z czarnej listy jest przetwarzane normalnie — usuwany jest tylko ten konkretny e-mail z listy e-maili klienta. Jeśli klient miał tylko jeden e-mail i znajdował się on na czarnej liście, profil trafia do bazy bez żadnego e-maila. Jest to korzystniejsze niż odrzucanie całego zamówienia.
Kontekst: Zakładając że mam pustą blacklistę
Scenariusz: Email na blackliście jest odrzucany
Zakładając że email "spam@example.com" jest na blackliście
Kiedy sprawdzam czy email "spam@example.com" jest zablacklistowany
Wtedy wynik sprawdzenia powinien być pozytywny
Scenariusz: Email spoza blacklisty nie jest odrzucany
Zakładając że email "spam@example.com" jest na blackliście
Kiedy sprawdzam czy email "clean@example.com" jest zablacklistowany
Wtedy wynik sprawdzenia powinien być negatywny
Scenariusz: Telefon na blackliście jest odrzucany
Zakładając że telefon "48123456789" jest na blackliście
Kiedy sprawdzam czy telefon "48123456789" jest zablacklistowany
Wtedy wynik sprawdzenia powinien być pozytywny
Scenariusz: Telefon spoza blacklisty nie jest odrzucany
Zakładając że telefon "48123456789" jest na blackliście
Kiedy sprawdzam czy telefon "48999888777" jest zablacklistowany
Wtedy wynik sprawdzenia powinien być negatywny
Scenariusz: Email jest normalizowany przed sprawdzeniem blacklisty
Zakładając że email "jan.kowalski@gmail.com" jest na blackliście
Kiedy sprawdzam czy email "Jan.Kowalski@GMAIL.COM" jest zablacklistowany
Wtedy wynik sprawdzenia powinien być pozytywny
Scenariusz: Filtrowanie listy emaili usuwa zablacklistowane
Zakładając że email "spam@example.com" jest na blackliście
I że email "bad@example.com" jest na blackliście
Kiedy filtruję listę emaili "good@example.com, spam@example.com, clean@example.com"
Wtedy przefiltrowana lista powinna zawierać 2 emaile
I przefiltrowana lista powinna zawierać "good@example.com"
I przefiltrowana lista powinna zawierać "clean@example.com"
I przefiltrowana lista nie powinna zawierać "spam@example.com"
Scenariusz: Filtrowanie listy telefonów usuwa zablacklistowane
Zakładając że telefon "48111111111" jest na blackliście
Kiedy filtruję listę telefonów "48222222222, 48111111111, 48333333333"
Wtedy przefiltrowana lista powinna zawierać 2 telefony
I przefiltrowana lista nie powinna zawierać "48111111111"
Scenariusz: Import emaili z pliku CSV
Kiedy importuję plik CSV z emailami:
| spam1@example.com |
| spam2@example.com |
| invalid |
Wtedy raport importu powinien pokazać 2 dodane wpisy
I raport importu powinien pokazać 1 nieprawidłowy wpis
I email "spam1@example.com" powinien być na blackliście
Scenariusz: Import telefonów z pliku CSV
Kiedy importuję plik CSV z telefonami:
| telefon |
|---|
| 604701821 |
| +48 512-362-770 |
Wtedy raport importu powinien pokazać 2 dodane wpisy
I telefon "604701821" powinien być na blackliście
I telefon "512362770" powinien być na blackliście
Scenariusz: Import pomija duplikaty
Zakładając że email "existing@example.com" jest na blackliście
Kiedy importuję plik CSV z emailami:
| existing@example.com |
| new@example.com |
Wtedy raport importu powinien pokazać 1 dodany wpis
I raport importu powinien pokazać 1 pominięty duplikat
Scenariusz: Import pomija nagłówek CSV
Kiedy importuję plik CSV z emailami z nagłówkiem:
| real@example.com |
Wtedy raport importu powinien pokazać 1 dodany wpis
Scenariusz: Przeglądanie wpisów na blackliście
Zakładając że email "page1@example.com" jest na blackliście
I że email "page2@example.com" jest na blackliście
I że telefon "604701821" jest na blackliście
Kiedy pobieram listę wpisów blacklisty
Wtedy lista powinna zawierać 3 wpisy
Scenariusz: Filtrowanie wpisów po typie
Zakładając że email "email@example.com" jest na blackliście
I że telefon "604701821" jest na blackliście
Kiedy pobieram listę wpisów blacklisty typu "email"
Wtedy lista powinna zawierać 1 wpis
I wpis powinien być typu "Email"
Scenariusz: Wyszukiwanie wpisów po wartości
Zakładając że email "jan@gmail.com" jest na blackliście
I że email "anna@wp.pl" jest na blackliście
Kiedy wyszukuję wpisy zawierające "gmail"
Wtedy lista powinna zawierać 1 wpis
I wpis powinien zawierać "gmail" w wartości
Scenariusz: Usuwanie wpisu z blacklisty
Zakładając że email "todelete@example.com" jest na blackliście
Kiedy usuwam wpis z emailem "todelete@example.com"
Wtedy email "todelete@example.com" nie powinien być na blackliście
Scenariusz: Statystyki blacklisty
Zakładając że email "stat1@example.com" jest na blackliście
I że email "stat2@example.com" jest na blackliście
I że telefon "48123456789" jest na blackliście
Kiedy pobieram statystyki blacklisty
Wtedy liczba emaili powinna wynosić 2
I liczba telefonów powinna wynosić 1
I łączna liczba wpisów powinna wynosić 3