Identify e traits

Quando qualcuno accede o ti lascia i propri dati, dichiaralo. Tutto ciò che quel visitatore ha fatto prima viene collegato a lui, e tutto ciò che farà dopo pure.

identify da solo non invia una richiesta di rete. Memorizza l’id utente e i dettagli di contatto nel tag; la successiva track (di solito sign_up o login) li trasporta. Chiama prima identify, poi l’evento. Senza consenso pubblicitario, i dati di contatto non vengono inviati anche se li fornisci; i attributi vengono inviati in entrambi i casi.

vibiz.setConsent({ advertising: true }); // or from your CMP
vibiz.identify('cust_8842', {
  email: 'mario.rossi@example.com',
  phone: '+39 333 123 4567',
});
vibiz.track('sign_up', { method: 'email' });

Questo chiude il divario tra navigazione e acquisto. Qualcuno naviga in modo anonimo per una settimana, effettua l’accesso una volta e compra un mese dopo. Il login è l’unico momento in cui dice chi è, e raramente è il momento che conta commercialmente.

Dove chiamarlo

identify vive in memoria per la pagina su cui gira. Nulla viene ricordato al successivo caricamento della pagina, quindi chiamarlo solo nell’handler di login dà un nome a una persona una sola volta e mai più: un utente di ritorno con una sessione attiva non passa più da quella schermata.

Chiamalo ovunque la tua app LEGGE la sessione — il layout, il provider di auth, l’effetto che ripristina una sessione — e di nuovo, nello stesso handler, subito prima degli eventi che diventano record:

// wherever the session is read, not only at login
useEffect(() => {
  if (!user) return;
  vibiz.identify(user.id, { email: user.email });
}, [user]);

// and again where it counts, from the order rather than the session:
// a guest checkout has no session, but the form has the details
vibiz.identify(order.userId ?? order.id, {
  email: order.email,
  phone: order.phone,
});
vibiz.track('purchase', { value: order.total, currency: 'EUR' });

Due dettagli che decidono se questo funziona:

• L’id utente viaggia senza consenso pubblicitario. Non è un dettaglio di contatto. Passarlo dà sempre al record un identificatore invece di una riga anonima e unisce le visite di quella persona.
• Identify non sopravvive a un redirect. Una chiamata su una pagina che naviga via immediatamente non invia nulla, perché da quella pagina non è stato tracciato niente. Chiamala sulla pagina di arrivo.

Se l’acquisto viene confermato dal tuo server (un webhook di pagamento), quel report trasporta gli stessi identificatori. Un browser che ha identificato e un server che ha riportato una vendita anonima lasciano comunque un record senza nome.

I dettagli di contatto si accumulano invece di sostituirsi. Un login fornisce un’email, un checkout più tardi aggiunge un telefono e un indirizzo, e vengono mantenuti entrambi.

Ogni dettaglio di contatto viene memorizzato due volte: in forma hashed, che è quella con cui Meta e Google effettuano il match, e in chiaro, che è ciò che ti permette di rispondere chi si è iscritto invece di solo quanti. Entrambi provengono dallo stesso valore normalizzato, quindi i due non possono mai essere in disaccordo. Dal browser, nessun dettaglio di contatto viene memorizzato senza consenso pubblicitario; un form riportato dal tuo server mantiene quelli in chiaro per il tuo CRM (vedi consenso).

Attributi

Passa nella stessa chiamata tutto il resto che sai su qualcuno. Le risposte di onboarding sono il caso tipico, e il più utile: sono di prima parte, strutturate e fornite deliberatamente dalla persona che risponde.

vibiz.identify('cust_8842', {
  email: 'mario@agency.com',   // recognised: hashed for matching, kept readable
  business_type: 'agency',     // anything else becomes a trait
  team_size: 12,
  goals: ['leads', 'sales'],
  plan: 'free',
});

Un unico pacchetto in transito, suddiviso per te. I nomi dei trait sono tuoi: non c’è un elenco da cui scegliere. Le chiavi vengono prima normalizzate, così businessType, business_type e Business Type sono un unico trait invece di tre righe che contengono ciascuna una parte della risposta.

Un dettaglio di contatto viene riconosciuto dalla sua chiave: email, phone, first_name, last_name, city, region, postal_code, country, gender, date_of_birth ed external_id. Ogni altra chiave è un trait, e i trait non aspettano il consenso pubblicitario: restano in Vibiz e non raggiungono mai una piattaforma pubblicitaria. Questo rende la chiave importante. Un dettaglio di contatto sotto un nome scelto da te, come work_email, viene inviato e mantenuto come trait indipendentemente dal fatto che il visitatore abbia fornito il consenso, quindi metti i dettagli di contatto sotto le loro chiavi proprie.

Con il pacchetto npm, i traits vengono type-checkati da @vibiz/analytics 0.5.0.

I traits vivono sulla persona, quindi una risposta data all’iscrizione è ancora presente su un acquisto un mese dopo. Si accumulano, e un valore più recente sostituisce quello precedente:

// at signup
vibiz.identify('cust_8842', { plan: 'free', business_type: 'agency' });

// a month later, on upgrade
vibiz.identify('cust_8842', { plan: 'pro' });

// stored: { plan: 'pro', business_type: 'agency' }

Un onboarding a più step

Invia ogni step man mano che viene compilato, invece di raccogliere tutto e inviare alla fine. Le persone abbandonano l’onboarding a metà, e le risposte che hanno effettivamente dato sono quelle che spiegano il perché.

// step 1, who they are
vibiz.identify(user.id, { email, business_type: businessType });

// step 2, what they want
vibiz.identify(user.id, { goals, team_size: teamSize });

// step 3, budget
vibiz.identify(user.id, { monthly_budget: monthlyBudget });
vibiz.track('sign_up', { method: 'email' });

Ogni chiamata si aggiunge al profilo. Non serve rinviare nulla, e un visitatore che si ferma allo step due porta comunque con sé le due risposte date.

Questo è ciò che permette di rispondere a una domanda a cui né l’analytics né una piattaforma pubblicitaria possono rispondere da sole: quale creatività porta i clienti che dicono di essere un’agenzia, e se sono loro quelli che fanno l’upgrade.