escrito por Facundo Piaggio (Solutions Architect)

Es una situación familiar. Se abre el dashboard y aparecen 10.000 «Usuarios Activos Mensuales», pero la base de datos dice que solo hay 5.000. ¿De dónde salieron estos usuarios fantasma? Por lo general, es porque la estrategia de perfil de usuario en Braze y Amplitude funciona más como una sugerencia que como una regla y el stack entero está pagando las consecuencias.

Definir bien el perfil de usuario entre Braze y Amplitude es una de las decisiones de infraestructura más subestimadas que puede tomar un equipo de crecimiento. Para orquestar ciclos de vida en Braze y hacer análisis de comportamiento en Amplitude, hay que hablar su idioma. Ese idioma está escrito en IDs, y con esta guía explicamos cómo hacerlo bien.

La Regla de Oro: la política del «mismo ID»

Para mantener la cordura, el user_id de Amplitude debe coincidir con el external_id de Braze, exactamente, siempre.

Cuando estos dos valores están alineados, el stack se convierte en un ecosistema unificado. Es posible ver que un usuario abandona un funnel en Amplitude y, de inmediato, disparar una notificación push de «carrito abandonado» en Braze, porque ambas herramientas reconocen a User_123 como la misma persona.

Cómo Amplitude actúa de intermediario

Amplitude no se limita al ID de base de datos; usa un sistema por niveles para asegurarse de que el recorrido de un usuario no quede fragmentado entre dispositivos.

La Trinidad: Amplitude rastrea a cada usuario a través de una combinación de amplitude_id (interno), device_id y el user_id.

La Fusión: Si un usuario navega de forma anónima desde su iPhone (device_A) y luego inicia sesión como user_123, Amplitude vincula ese device_id al user_id. Si ese mismo usuario luego inicia sesión desde un iPad (device_B), Amplitude reconoce a user_123 y unifica toda la actividad en un solo perfil.

Braze: el external_id o nada

Braze funciona de manera similar, pero con más en juego, porque gestiona la comunicación directa con los usuarios. Aunque Braze rastrea muchos identificadores, el external_id es el único que realmente importa para identificar el perfil de usuario en Braze y Amplitude.

Los «otros» identificadores y por qué se quedan cortos

El requisito de changeUser()

El SDK de Braze se «engancha» a un perfil una vez que lo carga. Para pasar de un perfil de invitado anónimo a un perfil de usuario conocido, la aplicación debe llamar a:

changeUser(external_id)

⚠️ El problema: La aplicación debe tener acceso a ese ID antes de poder decirle a Braze quién es el usuario. Si el external_id no está disponible, el cambio no puede ocurrir.

Esto se vuelve aún más crítico en casos como los dispositivos compartidos. Sin el external_id, es imposible forzar al SDK de Braze a cambiar el usuario al que apunta internamente con atributos y eventos, y el SDK queda bloqueado al primer usuario que encontró.

En estos casos, quedan dos opciones poco atractivas: la fusión de perfiles (que arriesga sobrescribir datos críticos) o llamar al método wipeData(). Eso sí, wipeData() suele traer un nuevo conjunto de problemas relacionados con la persistencia de datos y el seguimiento de sesiones.

Por qué la fusión manual es una trampa de mantenimiento

Es posible ignorar changeUser() e intentar arreglar las cosas después usando el endpoint /users/merge. Pero este enfoque tiene sus costos:

La trampa del triple flujo: Hay que gestionar perfectamente la lógica para tres escenarios distintos: Login, Registro e Inicio de la app. Si la lógica falla en uno solo, se generan perfiles duplicados.

Límites de velocidad: A escala, hacer llamadas a una API para fusionar perfiles manualmente disparará rápidamente los rate limits, generando vacíos en los datos.

Retraso de sincronización: Las fusiones manuales no siempre son instantáneas. El email de «Bienvenida» podría enviarse al perfil duplicado antes de que la fusión se complete.

Lo ideal es establecer un mecanismo para identificar a los usuarios anónimos, de modo que cuando un perfil pase por cualquiera de los flujos anteriores, se realice una solicitud al endpoint /users/merge.

Un punto más: este endpoint debe ejecutarse desde un entorno de back-end. Por razones de seguridad, Braze no permite llamadas a la API directamente desde el front-end, por lo que los datos de fusión deben transmitirse a un servicio interno primero. Esto significa que también hay que contemplar la escalabilidad de ese servicio interno, especialmente al manejar un alto volumen de usuarios o sesiones concurrentes.

TL;DR

Intentar arreglar el perfil de usuario cuando los datos ya están desordenados no es la solución.

1. Exponer el ID — Es necesario que la aplicación tenga acceso fácil al ID único de base de datos del usuario, o a un valor hasheado derivado de un campo como el email.
2. Inicializar temprano — Llamar a setUserId en Amplitude y a changeUser en Braze en cuanto el ID esté disponible.
3. Mantener la consistencia — Usar exactamente el mismo string en ambas herramientas. Sin excepciones.

Este es exactamente el tipo de problema en el que vive Minders.

Arquitectura de perfil de usuario en Braze y Amplitude, seguimiento de eventos, orquestación de ciclos de vida: ayudamos a los productos digitales a resolverlo desde el principio, para que los datos reflejen la realidad y las herramientas trabajen juntas en lugar de en contra.

Si el stack está más desordenado de lo que debería, hablemos.