Identify y traits

Cuando alguien inicia sesión o te da sus datos, dilo. Todo lo que ese visitante hizo antes se le adjunta, y todo lo que haga después también.

identify por sí solo no envía una petición de red. Guarda el id de usuario y los datos de contacto en la etiqueta; el siguiente track (normalmente sign_up o login) los transporta. Llama primero a identify y luego al evento. Sin el consentimiento de publicidad, los datos de contacto no se envían, aunque los proporciones; los atributos se envían de todas formas.

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

Esto cierra la brecha entre navegar y comprar. Alguien navega de forma anónima una semana, inicia sesión una vez y compra un mes después. El inicio de sesión es el único momento en el que dice quién es, y rara vez es el momento que más importa comercialmente.

Dónde llamarlo

identify vive en memoria para la página en la que se ejecuta. No se recuerda nada para la siguiente carga de página, así que llamarlo solo en el handler de login nombra a una persona una vez y nunca más: un usuario recurrente con una sesión activa nunca pasa por esa pantalla.

Llámalo dondequiera que tu app LEA la sesión — el layout, el proveedor de auth, el efecto que restaura una sesión — y de nuevo, en el mismo handler, justo antes de los eventos que se convierten en registros:

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

Dos detalles que determinan si esto funciona:

• El id de usuario viaja sin consentimiento de publicidad. No es un dato de contacto. Pasarlo siempre le da al registro un identificador en lugar de una fila anónima, y agrupa las visitas de esa persona.
• Identify no sobrevive a un redirect. Una llamada en una página que navega fuera de inmediato no envía nada, porque no se ha trackeado nada desde ella. Llámalo en la página de destino.

Si la compra se confirma desde tu servidor (un webhook de pago), ese informe lleva los mismos identificadores. Un navegador que identificó y un servidor que informó de una venta anónima siguen dejando un registro sin nombre.

Los datos de contacto se acumulan en lugar de reemplazarse. Un login aporta un email, un checkout más tarde añade un teléfono y una dirección, y se conservan ambos.

Cada dato de contacto se guarda dos veces: con hash, que es la forma en que Meta y Google lo usan para hacer matching, y legible, que es lo que te permite responder quién se registró en lugar de solo cuántos. Ambos provienen del mismo valor normalizado, así que nunca pueden discrepar. Desde el navegador, no se almacena ningún dato de contacto sin consentimiento de publicidad; un formulario informado desde tu servidor guarda los datos legibles para tu CRM (ver consentimiento).

Atributos

Pasa cualquier otra cosa que sepas sobre alguien en la misma llamada. Las respuestas de onboarding son el caso habitual, y el más útil: son de primera parte, estructuradas y dadas deliberadamente por la persona que responde.

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 solo paquete en la red, dividido para ti. Los nombres de traits son tuyos: no hay una lista de la que elegir. Las claves se normalizan primero, así que businessType, business_type y Business Type son un solo trait en lugar de tres filas que contienen cada una parte de la respuesta.

Un dato de contacto se reconoce por su clave: email, phone, first_name, last_name, city, region, postal_code, country, gender, date_of_birth y external_id. Cualquier otra clave es un trait, y los traits no esperan al consentimiento de publicidad: se quedan en Vibiz y nunca llegan a una plataforma de anuncios. Eso hace que la clave importe. Un dato de contacto bajo un nombre propio tuyo, como work_email, se envía y se guarda como trait haya o no consentimiento del visitante, así que pon los datos de contacto bajo sus propias claves.

Con el paquete de npm, los traits tienen type checking desde @vibiz/analytics 0.5.0.

Los traits viven en la persona, así que una respuesta dada en el signup sigue ahí en una compra un mes después. Se acumulan, y un valor más reciente reemplaza a uno anterior:

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

Una incorporación en varios pasos

Envía cada paso según se vaya respondiendo en lugar de recopilar todo y enviarlo al final. La gente abandona el onboarding a mitad, y las respuestas que sí dieron son las que explican por qué.

// 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 llamada suma al perfil. No hace falta reenviar nada, y un visitante que se queda en el paso dos sigue llevando las dos respuestas que dio.

Esto es lo que permite responder una pregunta que ni la analítica ni una plataforma de anuncios pueden responder solas: qué creatividad trae a los clientes que dicen ser una agencia, y si son ellos los que mejoran de plan.