Data-driven business in otto passi 3: corretta validazione

Ah, quindi il telefono non è veramente (012) 345-6789?

Se pensavi che fosse facile uscire dalla fase in cui rappresenti il Creatore di Problemi, hai probabilmente scoperto che le persone sono molto entusiaste quando ti dicono che risultati vogliono ottenere, e leggermente meno entusiaste quando si tratta di fare quanto è necessario per ottenerlo.

Ad ogni modo, andiamo avanti. Diciamo che nel passo 1 abbiamo deciso di raccogliere il numero di telefono dell’utente. Ottimo. Poi, nel passo 2 abbiamo deciso che quel numero doveva essere raccolto nell’unico form della procedura di iscrizione.

Quindi andrà tutto bene, no?

No.

E non perché i tuoi utenti siano particolamente malvagi o che. Molto semplicemente, non hanno la tua stessa preoccupazione per la qualità dei dati che ti forniscono. Non gliene potrebbe fregare di meno, diciamo, non è affar loro.

Fai una prova. Dai un’occhiata ai record del CRM. Ti sembrano a posto? Bene. Adesso guarda che relazione hanno con gli stessi dati in Amministrazione.
…
…

Ok, adesso basta imprecare, visto cosa intendo?

Quindi il tuo form richiede un numero di telefono. Ecco l’input:

qwertyuiop

Che c’è, non va bene?

Ma ovviamente i tuoi programmatori sono svegli, si sono assicurati che il campo contenga dei numeri.

1234567890

Hmmm.

Mi sa che ti serve a poco nella prossima campagna di direct marketing, che dici? Allora assicuriamoci che il valore corrisponda al formato dei numeri di telefono nazionali, ok? Tipo (XX) XXX-XXXX.

(12) 345-6789

Non ci siamo ancora. Dobbiamo essere certi che il prefisso sia davvero un prefisso. Ovviamente, in Italia, i prefissi posso essere di 2, 3 o 4 cifre. Diamine.

(02) 123-4567

(Non fare il gradasso, lo so anche io che per la validazione di questi tipi di dati utente ci sono librerie fatte apposta. E sai anche tu che non sempre si usano, e che anche usarle non ti garantisce che i dati che raccogli siano reali. Stiamo solo facendo degli esempi per capirci. Se il problema non ti riguardava non eri ancora qui a leggere.)

Potremmo continuare. Qual è il punto? Eccolo, il punto: la validazione è difficile.

Difficile perché, dal punto di vista dell’utente, battere tasti a casaccio o saltare un campo o due è molto più economico.

Sappiamo da anni che il solo modo di garantire che un indirizzo email fornito dall’utente sia reale è di verificarlo. Funziona, e infatti ormai non ti puoi registrare a nessun servizio online senza rispondere a una mail che ti viene spedita all’indirizzo che fornisci per registrarti.

Il mio consiglio è questo: se hai modo di verificare un dato di input, verificalo. Santo cielo, in Inghilterra la banca ti dice perfino se il CAP corrisponde o no al tuo indirizzo.

Anche se non sei una banca, il costo di connetterti a un database e verificare i dati inseriti è nulla rispetto al costo di raccogliere eventuali dati mancanti o di ripulire un database sporco.

Purtroppo, non tutti i tipi di valori possono essere verificati. Purtroppo, in questi casi ti devi accontentare di due soluzioni sub-ottimali:

1. programmazione intelligente (ossia controllare per quanto possibile i valori nel momento dell’inserimento, garantendo che siano almeno ben formati)
2. raccolta intelligente (fa’ in modo che sia nell’interesse dell’utente fornire dati corretti).

Lo so, lo so, non avrai mai il budget per validare tutti gli input. Come ti capisco. Ma questa è una buona notizia, perché mi stai dicendo che vuoi raccogliere dati i cui costi di raccolta non sono giustificati: torna indietro di due caselle alla corretta Identificazione!

Siamo così abituati a navigare nei dati da perdere di vista il fatto che ogni singolo dato raccolto ha un costo: pagato dall’utente per fornirlo e da te per raccoglierlo.

Voglio condividere con te qualcosa che imparato nel corso degli anni e che penso abia un certo valore. Sono le due Piccole Grandi Verità della Raccolta Dati:

1. non hai veramente bisogno di tutti i dati che il Marketing ti chiede (vale anche se sei nel Marketing)
2. non hai bisogno di tutti i dati nello stesso momento.

Una volta un grosso cliente mi chiamò per avere un assessment di usabilità sulla sua procedura di registrazione. Si componeva di 12 form a pagina intera, con oltre 60 campi di input obbligatori. Non sto scherzando. La procedura era stata disegnata dal Marketing, e tutti quei dati erano considerati vitali. Non ci fu modo di fargli capire che la maggior parte della raccolta poteva venire spostata a dopo il completamento della registrazione, e diluita nel corso di più sessioni. Quindi se la tennero com’era, e ovviamente furono fuori dal mercato in sei mesi.

Quanto ti ho appena detto vale in tutti i casi in cui ci sia una raccolta dati: registrazione, call centre, supporto tecnico, CRM, ecc.

È molto meglio raccogliere pochi dati validi che molti dati “sporchi”.

Action Items

1. disponi una procedura di validazione da effettuarsi al momento della raccolta per ogni dato che raccogli
2. se non puoi validare, verifica
3. se non puoi validare né verificare, implora (ossia dai un incentivo all’utente per avere dati corretti)
4. se i passi da 1 a 3 sono troppo per il tuo budget, allora sono dati i cui costi non sono giustificati, e sono inutili
5. chiedi solo i dati realmente necessari
6. diluisci la raccolta dati quanto più possibile lungo il processo: raccogliere dati porta errori e rinunce da parte dell’utente
7. incentiva periodicamente gli utenti perché ripuliscano i dati. Qui, in particolare, la gamification funziona a meraviglia.