Un cliente se registra un martes después de haber entrado y salido de la página de precios durante una semana. En el CDP, esa semana vive bajo un perfil, el registro vive bajo otro, y nada los conecta. La persona es la misma; el registro quedó partido en dos.
Por qué se rompe el pase de anónimo a identificado
Todo CDP trackea la actividad de alguien que todavía no tiene cuenta bajo un ID anónimo temporal, atado al navegador o al dispositivo. Cuando esa persona se registra o deja un email, la herramienta tiene que unir ese historial anónimo con el perfil real. Esa unión no pasa sola porque la persona exista en los dos registros: hay que decirle explícitamente al sistema que el ID anónimo y el nuevo ID identificado son la misma persona. Si el llamado de registro manda el ID de usuario nuevo pero nunca lleva el ID anónimo que venía siguiendo a ese visitante un segundo antes, el CDP no tiene forma de saberlo. Abre un segundo perfil, nuevo de cero, en vez de completar el primero.
Dónde se suele filtrar el error
El lugar más común donde esto se rompe es un flujo de registro armado por un equipo que nunca leyó la especificación de resolución de identidad de la que depende el stack de marketing. Alguien conecta el llamado de creación de cuenta, funciona, y nadie revisa si el ID anónimo previo viajó con él. El funnel se ve bien; la separación solo aparece después, adentro del CDP, como “perfil duplicado”.
Lo que cuesta un perfil partido
El perfil anónimo guarda cada vista de página, click de email e interacción con un anuncio de antes del registro. El identificado arranca con historial cero, aunque haya sido una campaña puntual la razón por la que esa persona se registró. Cualquier journey que dispare por “tiempo desde el primer contacto” o “páginas vistas antes de comprar” lee a ese cliente como nuevo, así que una bienvenida pensada para un lead frío corre sobre alguien que ya conocía el producto, y la atribución le reconoce el registro a un canal de adquisición que no tuvo nada que ver.
Tres lugares para revisar si sospechas que esto te está pasando:
- Abre el perfil de un registro reciente y busca un campo de ID anónimo. Si está vacío, la unión nunca corrió.
- Compara la fecha de alta de la cuenta en tu base de producto contra el “first seen” del CDP. Si coinciden, ningún historial previo al registro quedó pegado.
- Revisa qué manda realmente el llamado identify: solo el ID de usuario nuevo, o ese ID junto con el anónimo que tenía un segundo antes.
Es el mismo mecanismo detrás de qué hace un CDP de verdad con la identidad: la herramienta vale lo que logra reconciliar en un solo registro. La solución casi nunca es una herramienta nueva, es asegurarse de que cada punto de entrada a un funnel en Estados Unidos, registro, checkout, login de la app, lleve el ID anónimo existente del visitante en vez de arrancar de cero. La misma falla, un dato que nunca vuelve al registro que lo necesitaba, es la que rompe un envío en una entrega fallida sin actualización de dirección.