Identify e traits

Quando alguém inicia sessão ou lhe dá os seus dados, diga-o. Tudo o que esse visitante fez antes é associado a essa pessoa, e tudo o que fizer depois também.

identify por si só não envia nenhum pedido de rede. Guarda o ID de utilizador e os dados de contacto na tag; o track seguinte (normalmente sign_up ou login) transporta-os. Chame identify primeiro e só depois o evento. Sem consentimento de publicidade, os dados de contacto não são enviados mesmo quando os passa; os traits são enviados em qualquer dos casos.

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' });

Isto fecha a lacuna entre navegar e comprar. Alguém navega anonimamente durante uma semana, inicia sessão uma vez e compra um mês depois. O login é o único momento em que a pessoa diz quem é, e raramente é o momento que mais importa comercialmente.

Onde o chamar

identify vive em memória para a página em que é executado. Nada é recordado para a próxima navegação, por isso chamá-lo apenas no handler de login identifica a pessoa uma vez e nunca mais: um utilizador recorrente com sessão ativa já não passa por esse ecrã.

Chame-o em todos os sítios onde a sua app LÊ a sessão — o layout, o fornecedor de auth, o effect que restaura uma sessão — e novamente, no mesmo handler, mesmo antes dos eventos que se tornam registos:

// 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' });

Dois detalhes determinam se isto funciona:

• O user id viaja sem consentimento de publicidade. Não é um dado de contacto. Passá-lo dá sempre um identificador ao registo em vez de uma linha anónima, e junta as visitas dessa pessoa.
• Identify não sobrevive a um redirect. Uma chamada numa página que navega para outro URL imediatamente não envia nada, porque nada foi rastreado a partir dela. Chame-o na página de destino.

Se a compra for confirmada pelo seu servidor (um webhook de pagamento), esse relatório transporta os mesmos identificadores. Um browser que identificou e um servidor que reportou uma venda anónima continuam a deixar um registo sem nome.

Os dados de contacto acumulam em vez de substituir. Um login dá um email, um checkout mais tarde acrescenta um telefone e uma morada, e ambos são mantidos.

Cada dado de contacto é guardado duas vezes: com hash, que é a forma usada por Meta e Google para corresponder, e legível, que é o que lhe permite responder quem se inscreveu em vez de apenas quantos. Ambos vêm do mesmo valor normalizado, por isso nunca podem entrar em conflito. A partir do browser, nenhum dado de contacto é guardado sem consentimento de publicidade; um formulário reportado a partir do seu servidor mantém os dados legíveis para o seu CRM (veja consentimento).

Atributos

Passe tudo o resto que souber sobre alguém na mesma chamada. As respostas de onboarding são o caso habitual, e o mais útil: são first party, estruturadas e fornecidas deliberadamente pela própria pessoa.

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',
});

Um único pacote em trânsito, dividido por si. Os nomes dos traits são seus: não há lista para escolher. As keys são niveladas primeiro, por isso businessType, business_type e Business Type são um único trait em vez de três linhas que cada uma guarda parte da resposta.

Um dado de contacto é reconhecido pela sua key: email, phone, first_name, last_name, city, region, postal_code, country, gender, date_of_birth e external_id. Qualquer outra key é um trait, e os traits não esperam por consentimento de publicidade: ficam no Vibiz e nunca chegam a uma plataforma de anúncios. Isso torna a key importante. Um dado de contacto sob um nome seu, como work_email, é enviado e mantido como trait tenha ou não o visitante dado consentimento, por isso coloque os dados de contacto sob as suas próprias keys.

Com o pacote npm, os traits têm type check a partir de @vibiz/analytics 0.5.0.

Os traits vivem na pessoa, por isso uma resposta dada no signup continua lá numa compra um mês depois. Eles acumulam e um valor mais recente substitui um mais antigo:

// 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' }

Um onboarding em vários passos

Envie cada passo assim que for respondido em vez de recolher tudo e enviar no fim. As pessoas abandonam o onboarding a meio, e as respostas que deram são as que explicam porquê.

// 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' });

Cada chamada acrescenta ao perfil. Nada precisa de ser reenviado, e um visitante que pára no passo dois continua a trazer as duas respostas que deu.

É isto que permite responder a uma pergunta que nem a analytics nem uma plataforma de anúncios conseguem responder sozinhas: que creative traz os clientes que dizem que são uma agência, e se são eles que fazem upgrade.