Aspecte tehnice ale segmentării clienților Partea 2 – Integritatea datelor

Ultimul articol ne-a ajutat să înțelegem cum sincronizarea datelor permite o segmentare eficientă. Dar pentru a deveni un adevărat expert de segmentare, aveți nevoie de încă un lucru - capacitatea de a evalua și menține calitatea datelor, definită colectiv ca integritate a datelor . Deși cel mai bun mod de a învăța despre acest lucru este prin practică, înfășurarea capului în jurul conceptelor critice vă va oferi un avans.

Integritatea datelor este un subiect larg. Adevărul să fie spus, este obiectivul primordial al întregului departament IT. Toți sunt angajați pentru a evita extragerea de perspective bazate pe date incorecte.

Când o limităm la segmentarea clienților, un specialist CRM ar trebui să fie conștient de unicitatea datelor, tipurile de date și constrângerile de date.

Unicitatea datelor

Imaginați-vă că un client primește un mesaj de două ori sau, mai rău, primește un mesaj de două ori de fiecare dată cu o reducere diferită. Un singur caz nu va cauza prea mult rău, dar dacă acest număr crește, campania ar putea fi un eșec instantaneu cu consecințe pe termen lung, inclusiv scăderea loialității.

Acesta este motivul pentru care baza dvs. de clienți trebuie să aibă grijă de unicitatea datelor. Pentru a face acest lucru, trebuie să găsiți un identificator care să vă permită să distingeți între doi clienți. Poate fi un e-mail sau un număr de telefon. Deși sunt unici pentru fiecare Tom, Dick sau Harry, nu sunt buni candidați pentru un identificator. În primul rând, adresele de e-mail și numerele de telefon se pot schimba pentru o persoană. În al doilea rând, este posibil să aveți probleme la asigurarea unicității e-mailurilor, inclusiv „.” și caractere „+” sau non-engleze.

De aceea, CRM-urile folosesc un identificator intern unic. Este inventat ca un identificator unic universal (UUID) sau un identificator unic global (GUID) .

Aceștia sunt algoritmi care preiau atributele unice ale clientului (cum ar fi e-mailul sau numărul de telefon), le criptează și generează un șir de caractere aleatorii - unic pentru fiecare client . Când John devine clientul dvs., CRM va genera un identificator pentru el, cum ar fi 8f14a65f-3032-42c8-a196-1cf66d11b930.

Prin crearea unui identificator atât de lung, reduceți riscul de a genera un ID duplicat la aproape zero.

Tipuri de date

Formatul în care stocați datele poate fi o altă amenințare sau poate ajuta la integritatea datelor. Imaginați-vă că rulați un sondaj și cereți publicului un smartphone preferat - doriți să trimiteți o ofertă fiecărui client care a ales iPhone X în timpul promoției.

Când citiți lista de răspunsuri, vedeți următoarele înregistrări:

• iPhone X
• iPhone X
• i Telefon 10
• iPhone X
• iPhone 10
• Nokia 3310
• Si asa mai departe...

Când se creează un segment pentru clienții „iPhone X”, sistemul va afișa doar un client în loc de cinci. Soluția la această problemă este simplă - trebuie doar să schimbați tipul câmpului de răspuns la o listă predefinită în loc de un text deschis. Dar dacă uiți de asta înainte de lansare, ajungi să ai o mulțime de lucrări manuale în farfurie.

Greșeli simple, dar supărătoare, ca aceasta pot fi evitate prin înțelegerea și verificarea modelului de date pentru fiecare pas în călătoria clientului. Primul pas este să vizitați documentația despre opțiunile oferite de CRM pentru a stoca și procesa date pentru fiecare entitate - se numește o schemă de date.

Să explorăm cum arată o schemă de date și cum îi puteți folosi caracteristicile pentru a asigura integritatea datelor. Tipurile de date merg pe primul loc.

Tipuri de date

Tipurile de date sunt atribute ale datelor care spun CRM cum putem folosi datele sau ce operațiuni putem face cu ele. Iată lista de tipuri pe care le puteți găsi în aproape toate instrumentele CRM.

Primitive – tipuri de bază

• Boolean – reprezintă valori adevărate sau false. De exemplu, imaginați-vă un atribut: is_first_time_customer.
• Integer – reprezintă un număr, pozitiv sau negativ, care nu are virgulă zecimală. De exemplu, în Salesforce CRM, numerele întregi au o valoare minimă de -2.147.483.648 și o valoare maximă de 2.147.483.647.
• Decimală (float) – un număr care include un punct zecimal, de exemplu, 3,14159.
• Caracter – o singură literă sau orice caracter, inclusiv numere (numite în mod colectiv alfanumeric).
• Șir – stochează un șir de caractere alfanumerice, cum ar fi un cuvânt, o frază sau o propoziție.
• Data – o valoare care indică o anumită zi.
• Datetime – o valoare care indică o anumită zi și oră.
• Blob – (din obiectul binar mare) o colecție de date binare stocate ca un singur obiect. Vă puteți gândi la el ca la un singur fișier (imagine, înregistrare vocală, film, PDF etc.) pentru simplitate.

Înainte de a trece la tipurile avansate, să facem o pauză pentru a obține o intuiție despre cum să alegem tipul potrivit. Probabil ați observat deja că fiecare tip de date are două caracteristici:

• ce fel de valori poate reprezenta,
• care sunt valorile minime și maxime pe care le poate stoca.

Există două reguli generale pentru ambele:

1) Când vine vorba de reprezentarea valorii - cu cât aveți mai multă flexibilitate, cu atât este posibilă mai puțină automatizare a datelor sau, mai bine, cu atât este nevoie de mai multă muncă în software pentru procesarea datelor. Un exemplu simplu ar fi codul poștal din SUA. Dacă este un număr, putem folosi intervale pentru a deduce starea (de exemplu, Alabama este de la 35801 la 35816). Asta ar fi imposibil pentru șir.

Un alt exemplu bun ar fi sondajul nostru. Dacă dorim să numărăm variantele iPhone X cu versiunea text deschis, ar trebui să ne modificăm interogarea pentru a include toate valorile. În plus, ar trebui să menținem interogarea – de fiecare dată când găsim o nouă variantă introdusă de un utilizator, interogarea trebuie actualizată.

2) A doua regulă este despre valorile minime și maxime. Cu cât configurați dimensiunea mai mare pentru un atribut, cu atât acesta este mai flexibil. Acum, s-ar putea să vă întrebați de ce nu folosiți întotdeauna cea mai mare opțiune? Pentru că dimensiunea mai mare are nevoie de mai multă memorie de calculator necesară procesării datelor, iar asta costă mai mult. Poate fi neglijabil atunci când aveți sute de înregistrări, dar când ajungeți la milioane, instanța dvs. CRM poate răspunde mai lent sau veți atinge limita și veți fi forțat să faceți upgrade la un plan de preț mai mare.

Compozit – rezultat din combinarea a două sau mai multe primitive

• Array – un grup de primitive de orice dimensiune. Este de obicei reprezentat ca o serie sau primitive între paranteze, de exemplu, [1, 3, 5, 13, 5].
• Set – un grup de primitive de orice dimensiune, dar cu valori unice numai [1, 3, 5, 13].
• Enum – o enumerare (din enumerator) este un tip de date cu valori care iau fiecare exact unul dintr-un set finit de identificatori pe care îl specificați (este unul pe care ar trebui să-l folosim pentru sondajul nostru pentru a evita mizeria!).
• Obiect – Un obiect este o valoare care conține alte valori, de obicei în numere și secvențe fixe și de obicei indexate după nume. Elementele înregistrărilor sunt de obicei numite câmpuri sau membri. Amintiți-vă de exemplele JSON din prima parte, acestea sunt obiecte.

Constrângeri de date

Tipurile de date ne ajută deja să menținem ordinea în datele și să prevenim sarcinile obositoare de curățare a datelor, lucru asupra căruia putem acționa cu ajutorul mașinilor. Dar putem face mai mult decât atât cu constrângeri.

Constrângerile de date definesc proprietăți specifice pe care datele trebuie să le respecte. Un sistem CRM fiabil asigură menținerea constrângerilor în orice moment, adică atunci când creați un obiect nou sau modificați unul existent.

Ați primit vreodată un e-mail cu titlu Dragă {first.name}? Acest lucru ar putea fi rezultatul uitării unei constrângeri NOT NULL asupra atributului prenumelui.

Iată cum funcționează aceasta și alte constrângeri tipice:

• Not null – fiecare valoare nu trebuie să fie „NULL”, ceea ce în limba engleză înseamnă că nu poate fi goală.
• Unic – valoarea (valorile) trebuie să fie unică pentru fiecare obiect dintr-o bază de date. De exemplu, dacă doriți să identificați clienții prin e-mail sau număr de telefon, ar trebui să faceți acest câmp unic pentru a evita mesajele duplicate și probleme mai grave.
• Cheie primară – valoarea (valorile) trebuie să fie unică pentru fiecare obiect și să nu fie NULL. Majoritatea CRM-urilor implementează aceste constrângeri imediat.
• Cheie străină – valoarea (valorile) trebuie să facă referire la o înregistrare existentă într-un alt obiect (prin cheia sa primară sau o altă constrângere unică). Imaginați-vă că găsiți un card cadou în sistemul dvs., dar acesta nu conține informații despre proprietar. Eziți să-l dezactivezi pentru că poate unul dintre clienții tăi l-a primit și va fi dezamăgit dacă eșuează la casă. Adăugarea unei chei străine între un card cadou și obiectele client ar rezolva această problemă deoarece sistemul nu va crea un card fără ca proprietarul să fie atribuit sau să elimine din greșeală un proprietar de pe un card existent.
• Verificare – o expresie care trebuie să fie adevărată pentru ca constrângerea să fie satisfăcută. Aceasta este o constrângere umbrelă pentru condițiile pe care le puteți aplica atributelor unor tipuri de date specifice. Următoarele exemple ar trebui să vă ajute să înțelegeți conceptul:

• E-mailul (șir) ar trebui să respecte un model specific (citește articolul wiki pentru a vedea că este mai complicat decât obligatoriu @ la mijloc).
• Vârsta (întreg) ar trebui să fie mai mare de 13.
• Data nașterii (data) ar trebui să fie în martie.
• Crearea clientului (data) ar trebui să aibă loc înainte de 1 octombrie 2020.
• Ultima comandă (DateTime) nu ar trebui să fie mai devreme de ieri la prânz.
• Numărul de telefon (șir) ar trebui să înceapă cu un prefix de țară.
• Adresa (obiectul) ar trebui să conțină strada, numărul, orașul, țara, codul poștal - care pot avea constrângeri de „verificare” pe cont propriu. ‍

Normalizarea datelor

Există un alt concept de care ar trebui să fii conștient pentru a-ți îmbunătăți înțelegerea integrității datelor, partea de duplicare a datelor pentru a fi mai specifică. Se numește normalizare a datelor .

Ca exemplu, să luăm un program de loialitate. Trebuie să grupăm clienții în niveluri pentru a efectua unele analize mai târziu. Imaginează-ți un tabel care păstrează informații despre momentul în care un client s-a alăturat unui anumit nivel.

În loc să stocăm numele nivelului, care poate fi atât de lung cât Dunder Mifflin Golden Tier pentru fiecare persoană, pur și simplu păstrăm un număr care face referire la un tabel al nivelurilor de program.

Deci, în loc să deținem 20000 Dunder Mifflin Golden Tier, avem 20000 de referințe, cum ar fi #3. Când doriți să schimbați numele nivelului dintr-un anumit motiv, trebuie să îl actualizați doar într-un singur loc, iar integritatea datelor va fi menținută.

Acum, să intrăm mai adânc într-un concept de normalizare mai avansat. Să presupunem că doriți să monitorizați modul în care un client s-a mutat pe diferite niveluri. L-am putea stoca în următorul tabel:

Client | Nivelul | Data introducerii nivelului

Mike Scott | DM Golden Tier | 21.07.2020

Mike Scott | DM Silver Tier | 04.06.2020

Jim Halpert | DM Bronze Tier | 17.06.2020

Dar este mai bine să creați trei obiecte separate pentru a stoca asta, un tabel cu lista de niveluri, un tabel cu lista clienților și altul pentru a le conecta pe amândouă. Acest lucru ne oferă cea mai mare libertate pe care o putem obține atunci când schimbăm informațiile despre clienți sau informațiile de nivel separat și avem mai puține date duplicat, desigur.

Obiectele CRM implicite urmează de obicei concepte de normalizare a datelor. Totuși, dacă doriți să creați niște obiecte personalizate prin extinderea schemei out-of-the-box, ar trebui să păstrați întotdeauna normalizarea datelor în spatele minții.

Concluzii

Când vă treziți să lucrați cu un nou CRM, vizitați documentația acestuia pentru a explora schema de date. Parcurgeți obiectele implicite pentru a vedea ce puteți face din cutie. Aflați tipurile de date și cum puteți acționa asupra lor cu mecanisme încorporate, cum ar fi calcule Hubspot, câmpuri calculate Salesforce cu formule sau cum să le prezentați cu limbaje șablon precum Liquid.

Ca exercițiu, puteți vizita și articolul Fabric despre construirea unei scheme de date de comerț electronic pentru a explora modul în care o teorie a integrității datelor din această postare se aplică unui caz de utilizare real.