Integracje

LDE — powiązanie z zewnętrznym systemem lojalnościowym

LDE (Loyalty Drive Enterprise) to zewnętrzny system lojalnościowy z własną bazą klientów. Po deduplikacji Deduplikator próbuje powiązać każdego klienta z jego kontem w LDE. Ma to duże znaczenie dla jakości deduplikacji: gdy dwa profile wskazują to samo konto LDE, system wie z pewnością absolutną, że to ta sama osoba.

Dopasowanie klientów po identyfikatorze LDE

Klient powiązany z systemem lojalnościowym LDE ma przypisany identyfikator LDE — globalny, unikalny numer. Gdy dwa profile klientów mają ten sam identyfikator LDE, to na pewno ta sama osoba. System pomija wtedy porównywanie pozostałych danych i scala profile z pewnością absolutną, nawet gdy inne pola (imię, nazwisko, płeć) się nie zgadzają.

Powiązanie z LDE to pewność absolutna — ma pierwszeństwo przed porównaniem danych

Identyfikator LDE pochodzi z systemu lojalnościowego, nie z zamówień — jest nadawany przez LDE po ręcznej weryfikacji tożsamości przy rejestracji. To silniejszy sygnał niż jakiekolwiek dopasowanie szacunkowe. Para z tym samym identyfikatorem LDE jest scalana bez wątpliwości, z pewnością absolutną. Nawet niezgodna płeć (błąd w jednym z profili) nie blokuje scalenia.

Scenariusz: Klienci z tym samym LDE ID są automatycznie mergowani

Zakładając że mam klienta "A" z LDE ID 12345:

Pole	Wartość
FirstName	Jan
LastName	Kowalski
BirthDate	1985-05-15
Gender	M

I mam klienta "B" z LDE ID 12345:

Pole	Wartość
FirstName	Anna
LastName	Nowak
BirthDate	1990-01-01
Gender	K

Kiedy system szuka duplikatów dla klienta "B"
Wtedy decyzja to AutoMerge
I pewność wynosi Certain

Scenariusz: Klient bez LDE ID przechodzi do fuzzy matchingu

Zakładając że mam klienta "A" bez LDE ID:

Pole	Wartość
FirstName	Jan
LastName	Kowalski
BirthDate	1985-05-15
Gender	M

I mam klienta "B" bez LDE ID:

Pole	Wartość
FirstName	Jan
LastName	Kowlaski
BirthDate	1985-05-15
Gender	M

Kiedy system szuka duplikatów dla klienta "B"
Wtedy wykonywany jest fuzzy matching

Scenariusz: LDE ID match nadpisuje niezgodność płci

Zakładając że mam klienta "A" z LDE ID 99999:

Pole	Wartość
FirstName	Jan
LastName	Kowalski
BirthDate	1985-05-15
Gender	M

I mam klienta "B" z LDE ID 99999:

Pole	Wartość
FirstName	Jan
LastName	Kowalski
BirthDate	1985-05-15
Gender	K

Kiedy system szuka duplikatów dla klienta "B"
Wtedy decyzja to AutoMerge
I pewność wynosi Certain

Wiązanie profili z LDE

Po deduplikacji każdy klient ma jeden profil w bazie Deduplikatora. System próbuje powiązać ten profil z kontem w systemie lojalnościowym LDE na podstawie e-maila i daty urodzenia. Gdy znajdzie dopasowanie, zapisuje identyfikator LDE — od tej chwili każde przyszłe scalenie profili z tym samym identyfikatorem LDE jest traktowane jako pewne. Gdy profil ma e-maile pasujące do różnych kont LDE, trafia do kolejki weryfikacji zamiast być powiązany z przypadkowym kontem.

Powiązanie z LDE wymaga dokładnego dopasowania e-maila i daty urodzenia

Do wiązania z LDE nie stosuje się przybliżonego porównywania danych — wymagana jest dokładna zgodność e-maila (bez rozróżniania wielkości liter) oraz dokładna data urodzenia. E-mail jest kluczem identyfikującym konto w systemie LDE. Profil bez e-maila lub bez daty urodzenia nie może być powiązany. Gdy identyfikator LDE jest już przypisany do innego profilu, nie można go przypisać po raz drugi — oznaczałoby to kolizję identyfikatorów.

Kontekst: Zakładając że baza LDE jest dostępna

Scenariusz: Klient z pasującym emailem i datą urodzenia zostaje powiązany z LDE

Zakładając że w bazie LDE istnieje konto:

CustomerId	Email	DOB
12345	jan@example.com	1990-05-15

I że w systemie jest klient:

Id	FirstName	LastName	Email	BirthDate	Status
1	Jan	Kowalski	jan@example.com	1990-05-15	Active

Kiedy uruchamiam proces wiązania dla klienta o ID 1
Wtedy klient o ID 1 powinien być powiązany z kontem LDE o ID 12345

Scenariusz: Klient z wieloma emailami zostaje powiązany gdy jeden pasuje

Zakładając że w bazie LDE istnieje konto:

CustomerId	Email	DOB
99999	janek@work.com	1990-05-15

I że w systemie jest klient:

Id	FirstName	LastName	Emails	BirthDate	Status
2	Jan	Kowalski	jan@example.com, janek@work.com	1990-05-15	Active

Kiedy uruchamiam proces wiązania dla klienta o ID 2
Wtedy klient o ID 2 powinien być powiązany z kontem LDE o ID 99999

Scenariusz: Klient NIE zostaje powiązany gdy email pasuje ale data urodzenia nie

Zakładając że w bazie LDE istnieje konto:

CustomerId	Email	DOB
11111	jan@example.com	1985-03-20

I że w systemie jest klient:

Id	FirstName	LastName	Email	BirthDate	Status
3	Jan	Kowalski	jan@example.com	1990-05-15	Active

Kiedy uruchamiam proces wiązania dla klienta o ID 3
Wtedy klient o ID 3 NIE powinien być powiązany z LDE

Scenariusz: Klient NIE zostaje powiązany gdy brak dopasowania w LDE

Zakładając że baza LDE jest pusta
I że w systemie jest klient:

Id	FirstName	LastName	Email	BirthDate	Status
4	Anna	Nowak	anna@example.com	1988-07-22	Active

Kiedy uruchamiam proces wiązania dla klienta o ID 4
Wtedy klient o ID 4 NIE powinien być powiązany z LDE

Scenariusz: Klient bez daty urodzenia NIE jest wiązany

Zakładając że w bazie LDE istnieje konto:

CustomerId	Email	DOB
44444	nodate@example.com	1990-05-15

I że w systemie jest klient:

Id	FirstName	LastName	Email	BirthDate	Status
7	Jan	Kowalski	nodate@example.com	null	Active

Kiedy uruchamiam proces wiązania dla klienta o ID 7
Wtedy klient o ID 7 NIE powinien być powiązany z LDE

Scenariusz: Klient bez emaila NIE jest wiązany

Zakładając że w bazie LDE istnieje konto:

CustomerId	Email	DOB
55555	any@example.com	1990-05-15

I że w systemie jest klient:

Id	FirstName	LastName	Emails	BirthDate	Status
8	Jan	Kowalski		1990-05-15	Active

Kiedy uruchamiam proces wiązania dla klienta o ID 8
Wtedy klient o ID 8 NIE powinien być powiązany z LDE

Scenariusz: Klient z emailami pasującymi do różnych kont LDE trafia do kolejki review

Zakładając że w bazie LDE istnieje konto:

CustomerId	Email	DOB
11111	prywatny@gmail.com	1990-05-15

I że w bazie LDE istnieje konto:

CustomerId	Email	DOB
22222	sluzbowy@work.com	1990-05-15

I że w systemie jest klient:

Id	FirstName	LastName	Emails	BirthDate	Status
9	Jan	Kowalski	prywatny@gmail.com, sluzbowy@work.com	1990-05-15	Active

Kiedy uruchamiam proces wiązania dla klienta o ID 9
Wtedy klient o ID 9 NIE powinien być powiązany z LDE
I w kolejce review powinien być wpis typu LdeConflict dla klienta o ID 9
I wpis w kolejce powinien zawierać alternatywne ID LDE: 11111, 22222

Scenariusz: Klient już powiązany NIE jest ponownie matchowany

Zakładając że w bazie LDE istnieje konto:

CustomerId	Email	DOB
66666	jan@example.com	1990-05-15

I że w systemie jest klient:

Id	FirstName	LastName	Email	BirthDate	Status	LdeCustomerId
10	Jan	Kowalski	jan@example.com	1990-05-15	Active	77777

Kiedy uruchamiam proces wiązania dla klienta o ID 10
Wtedy klient o ID 10 powinien pozostać powiązany z kontem LDE o ID 77777

Scenariusz: Batch job wiąże wielu niepowiązanych klientów

Zakładając że w bazie LDE istnieje konto:

CustomerId	Email	DOB
10001	batch1@example.com	1990-01-01

I że w bazie LDE istnieje konto:

CustomerId	Email	DOB
10002	batch2@example.com	1991-02-02

I że w systemie są niepowiązani klienci:

Id	Email	BirthDate
100	batch1@example.com	1990-01-01
101	batch2@example.com	1991-02-02
102	nolink@example.com	1992-03-03

Kiedy uruchamiam batch job wiązania LDE
Wtedy klient o ID 100 powinien być powiązany z kontem LDE o ID 10001
I klient o ID 101 powinien być powiązany z kontem LDE o ID 10002
I klient o ID 102 NIE powinien być powiązany z LDE

Scenariusz: Klient NIE jest wiązany gdy LdeCustomerId już jest przypisane do innego klienta

Zakładając że w bazie LDE istnieje konto:

CustomerId	Email	DOB
12345	kasia@example.com	1990-05-15

I że w systemie jest klient:

Id	FirstName	LastName	Email	BirthDate	Status	LdeCustomerId
50	Katarzyna	Krupa	kasia@example.com	1990-05-15	Active	12345

I że w systemie jest klient:

Id	FirstName	LastName	Email	BirthDate	Status
51	Kasia	Krupa	kasia@example.com	1990-05-15	Active

Kiedy uruchamiam proces wiązania dla klienta o ID 51
Wtedy klient o ID 51 NIE powinien być powiązany z LDE
I klient o ID 50 powinien pozostać powiązany z kontem LDE o ID 12345

Scenariusz: Klient może być wiązany gdy LdeCustomerId nie jest przypisane do żadnego innego klienta

Zakładając że w bazie LDE istnieje konto:

CustomerId	Email	DOB
99999	unique@example.com	1990-05-15

I że w systemie jest klient:

Id	FirstName	LastName	Email	BirthDate	Status
61	Jan	Kowalski	unique@example.com	1990-05-15	Active

Kiedy uruchamiam proces wiązania dla klienta o ID 61
Wtedy klient o ID 61 powinien być powiązany z kontem LDE o ID 99999

Scenariusz: Email jest matchowany case-insensitive

Zakładając że w bazie LDE istnieje konto:

CustomerId	Email	DOB
88888	JAN.KOWALSKI@EXAMPLE.COM	1990-05-15

I że w systemie jest klient:

Id	FirstName	LastName	Email	BirthDate	Status
11	Jan	Kowalski	jan.kowalski@example.com	1990-05-15	Active

Kiedy uruchamiam proces wiązania dla klienta o ID 11
Wtedy klient o ID 11 powinien być powiązany z kontem LDE o ID 88888

Blacklista e-maili i telefonów

Blacklista pozwala wykluczyć wybrane kontakty (np. testowe, śmieciowe lub takie, dla których klient zażądał wykreślenia), zanim trafią na profile klientów.

Każdy wpis na blackliście to jeden adres e-mail lub jeden numer telefonu, wraz z informacją, skąd pochodzi, kto go dodał i kiedy. Wartości na blackliście są zapisywane w uporządkowanej formie, tak samo jak dane w zamówieniach — dzięki temu porównanie jest niezawodne niezależnie od formatu zapisu.

Blacklistą zarządza się w panelu operatora: wpisy można dodawać pojedynczo lub importować zbiorczo z pliku CSV (system pomija duplikaty i zgłasza wartości nieprawidłowe), przeglądać oraz usuwać. Przy przetwarzaniu każdego zamówienia system odfiltrowuje kontakty znajdujące się na blackliście — na profilu klienta zapisywane są tylko pozostałe.

Logowanie przez OpenID Connect

Panel operatora Deduplikatora jest chroniony logowaniem przez Authentik — centralnego dostawcę tożsamości Loyalty Point. Operatorzy nie mają oddzielnych kont w Deduplikatorze: logują się tymi samymi danymi co do innych systemów Loyalty Point. Niezalogowany użytkownik jest przekierowywany do Authentik, a po zalogowaniu wraca do panelu z aktywną sesją.

Dostęp do panelu wymaga aktywnej sesji logowania

Wszystkie strony panelu są chronione. Wygaśnięcie sesji (lub jej odwołanie w Authentik) wymusza ponowne logowanie — bez możliwości obejścia przez bezpośredni adres strony. Dane użytkownika (imię, e-mail) pochodzą z konta i są wyświetlane w nagłówku panelu.

Scenariusz: Niezalogowany użytkownik jest przekierowany do logowania

Zakładając że użytkownik nie jest zalogowany
Kiedy użytkownik próbuje otworzyć stronę główną
Wtedy użytkownik powinien zostać przekierowany do strony logowania

Scenariusz: Zalogowany użytkownik ma dostęp do panelu

Zakładając że użytkownik jest zalogowany jako "Jan Kowalski" z emailem "jan@example.com"
Kiedy użytkownik otwiera stronę główną
Wtedy użytkownik powinien mieć dostęp do panelu

Scenariusz: Wygaśnięcie sesji wymusza ponowne logowanie

Zakładając że użytkownik ma wygasłą sesję
Kiedy użytkownik próbuje otworzyć stronę główną
Wtedy użytkownik powinien zostać przekierowany do strony logowania

Scenariusz: Zalogowany użytkownik klika Wyloguj i traci dostęp

Zakładając że użytkownik jest zalogowany jako "Jan Kowalski" z emailem "jan@example.com"
Kiedy użytkownik klika przycisk wylogowania
Wtedy sesja użytkownika powinna zostać zakończona
I użytkownik powinien zostać przekierowany do strony logowania

Scenariusz: Wylogowany użytkownik nie może wrócić przyciskiem Wstecz

Zakładając że użytkownik się wylogował
Kiedy użytkownik próbuje otworzyć stronę główną
Wtedy użytkownik powinien zostać przekierowany do strony logowania

Scenariusz: Zalogowany użytkownik widzi swoje imię w nagłówku

Zakładając że użytkownik jest zalogowany jako "Jan Kowalski" z emailem "jan@example.com"
Kiedy użytkownik sprawdza dane wyświetlane w nagłówku
Wtedy nagłówek powinien zawierać "Jan Kowalski"

Scenariusz: Użytkownik bez claima name widzi email

Zakładając że użytkownik jest zalogowany tylko z emailem "jan@example.com"
Kiedy użytkownik sprawdza dane wyświetlane w nagłówku
Wtedy nagłówek powinien zawierać "jan@example.com"

Synchronizacja z serwerem analitycznym

Po zakończonej deduplikacji zamówienia — wraz z informacją, który klient je złożył — są synchronizowane na serwer analityczny, gdzie służą do raportowania.