Identifikace zákazníků
Čtvrtek, 05 Březen 2009 16:19

Identita zákazníkaVíte, kdo je váš zákazník?Zavolala mi dáma z jedné finanční instituce. Standardní telemarketing, nic neobvyklého. Neobvyklá byla otázka. Po několika úvodních frázích se mě zeptala: „A jaké naše produkty používáte?“
„No, vlastně úplně přesně nevím…,“ zaváhal jsem a snažil se pro začátek zvolit neutrálnější tón. Představil jsem si, že když zná moje jméno i číslo mobilního telefonu, odpověď na tuto otázku snadněji najde sama. Myslel jsem si, že sedí u monitoru, sluchátka na uších, před pusou mikrofon. V levé části obrazovky postupuje skript, podle kterého klade otázky, aby mě bezpečně dovedla k nákupu dalšího produktu. V pravé části obrazovky pak informace – můj behaviorální profil, bydliště, zakoupené produkty, klientský segment, a vůbec co ještě mi nabídnout, jak ze mě vyždímat víc peněz.


Otázku jsem chápal v kategorii „Jak se máte?“ a ani mě nenapadlo, že by mohla být myšlena vážně. Byla.
Paní vyprskla smíchy: „Jak to, že to nevíte?“ To se mi nelíbilo. Jako stávající i budoucí zákazník bych si zasloužil víc úcty. „No, to byste snad mohla vědět vy, ne?“ namítnul jsem. „A jak bych to asi mohla vědět?“ opáčila. „To přece není možné!“ trvala na svém. To na mě bylo moc. Nemohl jsem jinak než jí vysvětlit, jak ten náš software funguje.

Kdo je náš zákazník?

Znalost zákazníka je důležitá. Ideálem je nepochybně staré hokynářství, kde vás prodavač osloví jménem, po zaplacení přibalí pár bonbónů pro děti a řekne: „Tady máte pro manželku čokoládu k svátku.“ A přitom v počítačových systémech o nás firmy vedou daleko podrobnější informace. Ale jejich využití není zcela snadné.
Podívejme se na následující příklad z fiktivního finančního ústavu. Jde o finanční instituci, která kromě svého hlavního zaměření – pojištění bytů, aut, letadel (systém A) – nabízí také investice do fondů (systém B) a penzijní připojištění (systém C). Do datového skladu proudí data ze všech systémů tří systémů a v tabulce zákaznické dimenze se nacházejí záznamy s těmito atributy:
  • ID systému,
  • jméno a příjmení,
  • rodné číslo a datum narození,
  • příznak pohlaví,
  • adresa – v systému B je adresa uložena v pětisložkovém tvaru (ulice, číslo orientační, popisné, PSČ a město) v systému A a C je uložena ve dvousložkovém tvaru, transformace z primárního systému do datového skladu zachovává způsob uložení,
  • datum poslední aktualizace.
 
Obr. 1: Kolik máme zákazníků? Na první pohled vidíme, že těchto sedm záznamů představuje dva klienty. V příkladu jsou fiktivní data ze tří bankovních systémů (A, B, C). Banky o fyzických osobách mají další atributy: tituly, čísla a typy dokladů, kontaktní údaje (telefon, mobilní telefon, e-mail), rodná příjmení, místa narození, více adresních údajů apod. Všimněte si, že žádné dva záznamy nejsou přesně shodné.
kolik zákazníků mame?

Podíváme-li se blíže na sedm záznamů z tabulky na obrázku 1, je jasné, že jde o dvě fyzické osoby. V datovém skladu však máme sedm záznamů a úplný pohled na zákazníka nemůžeme získat, aniž bychom je přiřadili k sobě. Ve zdrojových systémech existují totiž ke každému z těchto záznamů další vazby – informace o tom, jaký konkrétní produkt zákazník využívá, zda je v prodlení s platbou pojistného apod.
Pohled na data nám říká, že jde o dvě fyzické osoby, a to přesto, že se záznamy poměrně hodně liší. Ve sloupci rodné číslo nejsou žádné dvě hodnoty stejné, podobně u adresních údajů žádné dvě adresy nejsou zapsány zcela stejně.
Detailnější analýzou můžeme domýšlet i příběhy, které nám ta data vyprávějí: Slečna Krákorová bydlištěm V Cípu 2 (je to ulice u Václavského náměstí v Praze) se provdala – nyní se jmenuje Marie Novotná a přestěhovala se na Václavské náměstí. Kromě toho dokončila lékařskou fakultu a nyní jí náleží titul MUDr. Tomu by mohla napovídat data poslední aktualizace (poslední sloupec), která jdou v tomto pořadí.
U Pavla Nejedlého je nejasné bydliště – na druhou stranu Thámova ulice je v Karlíně na Praze 8 (Praha 9 tedy bude překlep – v Praze 9 taková ulice není). Dům s orientačním číslem 16 má číslo popisné 137. Číslo 237 se v této ulici nevyskytuje, takže u záznamu s číslem 2 jde patrně o překlep v čísle popisném. U záznamu s číslem 3 je překlep v názvu ulice – poměrně pochopitelný: Támova místo správného Thámova.

Naše data jsou lepší

Zcela jistě ano. Musejí být lepší, protože jinak by vaše firma už asi nefungovala. Příklad z obrázku 1 je vymyšlený. Ale jenom částečně, se všemi případy chyb jsem se už setkal v reálných datech na projektech. Jak jsou časté? To je těžké říci. Hodně to závisí na tom, jak jsou konkrétní údaje pro firmu důležité, jak se o data stará. Například telekomunikační firmy mají výbornou kvalitu dat telefonních čísel. Tam, kde se údaje ověřují (např. vůči dokladu totožnosti při žádostech o hypotéky) lze očekávat větší kvalitu dat, než je tomu u dat zadávaných na internetu.
Naše zkušenosti z projektů ukazují, že zhruba pět až dvacet procent dat vykazuje nedostatky, které brání automatickému sloučení záznamů jejich – byť i sofistikovaným – porovnáním.

Rodné číslo nestačí

Tam, kde máme k dispozici identifikátor osoby nebo firmy (rodné číslo nebo IČO), jsme na tom o něco lépe. Samotné rodné číslo však nestačí. V příkladu 1 můžeme údaj standardizovat (odstraněním lomítek a prefixů typu r.č.), ale ani tehdy neurčíme přesně záznamy 4 a 6. Tedy situace, kdy atribut rodného čísla zcela chybí, nebo je vyplněn chybně, nebo je vyplněn nějakou jinou relevantní hodnotou (např. datem narození). Chyba v rodném čísle pak může vést k chybnému sloučení dvou spolu věcně nesouvisejících záznamů, což je věc, které je třeba se vyhnout.

Potřeba pokročilé technologie

Jak tedy takový problém vyřešit? Jako příklad technologie, která si s tímto problémem umí poradit, použiji Ataccama DQC (Data Quality Center), na jehož vývoji se podílím (obr. 2). Nástroj v českém prostředí známý pod dřívějším názvem Purity je nasazen doma i v zahraničí v řadě bank, pojišťoven a dalších institucí, které spravují milióny klientských záznamů. Ataccama DQC úlohu řeší ve dvou krocích – prvním je vyčištění a standardizace atributů, druhým je unifikace a tvorba reprezentativního záznamu.

Čištění

Ještě před vlastním vyčištěním je potřeba dostat data na „jedno místo“. Tuto úlohu datové integrace zpravidla řeší datový sklad dávkově plněný procesy ETL. Bez dalších postupů datové kvality vypadají data obvykle jako v příkladu 1. Co bylo na vstupu – tj. v primárních systémech – to se objevuje na výstupu, tedy v zákaznické dimenzi datového skladu.
Pravidla pro ETL transformace dat většinou nepřihlížejí k sémantické struktuře dat, ale jsou primárně řízena metadaty. Co to znamená? V příkladu v řádku 2 je prohozené jméno a příjmení, to ostatně každý člověk vidí. Člověk ano, ale ETL proces ne, ten se rozhoduje podle metadat, tedy podle názvu sloupců. Člověk vidí, že „Nejedlý“ není křestní jméno, ale že to má být příjmení. Jak to ale může „uvidět“ počítač? Jedině tak, že mu pomůžeme udělat stejnou úvahu – totiž očekáváme, že jméno fyzické osoby je tvořeno jedním křestním jménem a jedním příjmením. Nějak víme, že „Nejedlý“ je příjmení a „Pavel“ křestní jméno (respektive také příjmení). Toto „nějak“ lze popsat seznamem, číselníkem. Čili potřebujeme kvalitní číselník a seznam vzorů. Vzor Jméno Příjmení vyhoví pro uvedené příklady (Pavel Nejedlý, Marie Krákorová), ale vzorů bude asi více (uvažme Karel Jaromír Erben, Marie Novotná-Krákorová, Marie Novotná roz. Krákorová). Určité případy nerozhodneme vůbec (Petr Pavel, Jana Alex Petrů, Ho Či Min).
Některé atributy (jméno, příjmení, tituly) lze validovat vůči číselníkům a provést i příslušnou opravu (např. doplnění diakritiky), některé atributy mají vlastní „byznys“ pravidla, která musí splňovat (např. rodné číslo musí být dělitelné jedenácti, číslo bankovní karty musí mít správně kontrolní číslici). Někdy existují pravidla mezi jednotlivými atributy – například vazba mezi rodným číslem, datem narození a pohlavím osoby, vazba mezi pohlavím a jménem a příjmením, vazba mezi typem osoby a aktivním produktem (fyzická osoba nemůže mít produkt určený právnickým osobám). Jiný typ vazeb existuje mezi adresními atributy.

Obr. 2: Ukázka uživatelského rozhraní Ataccama Data Quality Center, kde lze nastavit komplexní pravidla pro čištění a unifikaci dat.
Ataccama Data Quality Center

Dobrá adresa?

Abychom zjistili, jestli jsou dva záznamy zápisem stejné adresy, potřebujeme adresu vyčistit a určit obsah jednotlivých komponent (ulice, obec, číslo popisné atd.). V prostředí, kde existuje centrální registr adresních bodů, a takový Česká Republika naštěstí má, je nejvhodnější identifikovat adresu vzhledem k registru a porovnávat pak identifikační číslo. ČR má registr adresních bodů (UIR-ADR) spravovaný Ministerstvem práce a sociálních věcí a aktualizovaný týdně. Automatická identifikace adres však není lehká, jednu a tutéž adresu lze napsat mnoha různými způsoby (obr. 3). Kromě zaměnitelnosti čísla popisného s orientačním a obce s částí obce komplikují identifikaci další věci: rušení pošt, změny názvů ulic či obcí a všudypřítomné zkratky (Benešov n. Plouč., nábř. kpt. Jaroše), ale i samotný etalon (obr. 4). Řešení problému spočívá v přípravě etalonu, v aplikaci oprav nejčastějších překlepů a zkratek a v použití algoritmu, který umí vyhodnocovat vazby mezi dvojicemi a trojicemi komponent (např. existuje toto číslo popisné v dané ulici a dané obci?) – nástroj Ataccama DQC takový algoritmus nabízí.
Identifikovaná adresa je společně s dalšími vyčištěnými atributy vstupem do unifikačního zpracování.

Obr. 3: Zápis stejné adresy. V levém sloupci jsou korektně zapsané adresy sídla společnosti Mediatel v Karlíně. Přesto je každý zápis jiný. V pravém sloupci jsou zápisy s „drobnými chybami“ – zapomenutá mezera mezi slovem Praha a číslem 8, překlep ve jménu ulice (chybějící „h“), překlep v čísle popisném (237 místo 137). Poslední dva příklady jsou automaticky neidentifikovatelné, nicméně i v těchto případech půjde o doručitelnou adresu. Poštovní doručovatel má větší a aktuální znalost lokálního prostředí – do Mediatelu doručuje více poštovních zásilek a ví, která ulice vede od stanice metra k tunelu pod Vítkovem.
Zápis stejné adresy

Unifikace

Unifikační pravidla říkají, že dva záznamy mají patřit k sobě, protože odpovídají té samé fyzické nebo právnické osobě. Technicky se ještě používají tzv. párovací hodnoty, kdy se vyčištěná data ještě převedou do jednotné podoby – velká písmena bez diakritiky a bez mezer.
Pravidla, která určují to, že dva záznamy patří k té samé fyzické (nebo právnické) osobě, bývají zpravidla také velmi komplikovaná.

Zápisy stejné adresyObr. 4: Po slavné spisovatelce bylo pojmenováno hodně ulic. Oficiální název však není v každé obci stejný – číslo v závorce udává počet obcí, ve které se vyskytuje v uvedeném tvaru. Ten, kdo píše adresu, má na mysli autorku Babičky a může použít libovolný z uvedených zápisů. Mezi B.Němcové a Boženy Němcové je však rozdíl 7 znaků, přitom oba zápisy jsou věcně ekvivalentní.

 

 

 

 

Unifikační pravidla obvykle vypadají jinak pro velmi konzervativní přístup, jaký zastává například řízení kreditního rizika (přesná unifikace), a benevolentnější přístup, jaký může představovat marketing.
Největší úskalí unifikační úlohy je výkonnost. Zjištění podobnosti záznamů se děje porovnáním párovacích hodnot, přičemž je třeba eliminovat situaci, že každý záznam se bude porovnávat se všemi ostatními. To se obvykle řeší rozdělením všech vstupních záznamů do menších skupin, ve kterých probíhá detailní porovnávání. Ataccama DQC podporuje několik strategií (simple key, hierarchical, union) pro toto hrubé dělení. K detailnímu porovnávání párovacích hodnot pak slouží řada funkcí pro určení různých vzdálenosti dvou řetězců (Levenstein, Hamming, editační vzdálenost, soundEx, Metaphone a další).

Naše zlato

Posledním krokem je tvorba reprezentativního záznamu – někdy se mu také říká zlatý záznam (golden record). Tento záznam nemusí ve zdrojových datech existovat. Vzniká kombinací nejlepších atributů záznamů z jedné skupiny. Představuje tu nejlepší reprezentaci dat týkajících se konkrétního zákazníka, jakou máme k dispozici. Je to fakticky takové rodinné stříbro, pokud jde o firemní zákaznická data.

Obr. 5:
Reprezentativní/zlatý záznam – každá fyzická osoba je reprezentována jedním záznamem. Jeho atributy jsou sestaveny často podle komplikovaných pravidel z atributů seskupených záznamů. I když jsou data fyzicky uložena v databázi (aby k nim bylo možné rychle přistupovat), jednotlivé atributy se v čase mění podle toho, jak se mění hodnoty ve zdrojových datech.
zlatý záznam

Instantní identifikace

Celou identifikační úlohu jsem zatím popisoval, jako by se prováděla pouze jednou na skupině dat přicházejících z různých systémů do datového skladu. Obvykle se takto začíná – jednorázovým sloučením, které umožní provést jednorázový data assessment a říci, kolik duplicitních záznamů v databázích máme, jaká je jejich datová kvalita, co lze a nelze automaticky opravit. Řešení se většinou dál rozvíjí k opakovanému (inkrementálnímu) zpracování. To umožňuje, aby data v primárních systémech dále žila svým životem, čemuž se beztak nedá zabránit, a aby místo, kde jsou zlaté záznamy, bylo stále aktuální. Odsud se pak mohou brát data pro marketingové kampaně nebo pro zákaznickou dimenzi datového skladu.
Inkrementální unifikační úloha je ještě těžší – každý nově příchozí záznam je nutné porovnat s aktuálním stavem všech ostatních a přitom zajistit časovou stabilitu čísel, která jsou přiřazena jednotlivým skupinám záznamů. Tato čísla se totiž dále využívají například jako primární klíč konsolidované zákaznické dimenze.
Ještě obtížnější je tuto úlohu řešit v reálném čase, tedy on-line. To odpovídá situaci, kdy na pobočku přichází žadatel o úvěr a my chceme určit, zda jej již máme v databázi, a jestli ano, jak vypadá jeho zlatý záznam.
Takhle to funguje
Nevím, jestli to paní z call centra úplně pochopila. Od té doby mi už nezavolala. A tak mám pocit, že už svého zákazníka znají – třeba v mém zlatém záznamu stojí v poznámce: „Nevolat – bude zas říkat, že si máme dát do pořádku data.“


Autor je produktovým ředitelem ve společnosti Ataccama.