Tablas de Braze en el lake: qué hay, cómo se unen, qué mirar

Orientación rápida

Cada envío o interacción con una campaña o canvas de Braze cae en el lake como un evento — una fila por persona, por acción. Quién recibió qué, cuándo, si abrió o clickeó. Volumen a nivel de persona, cruzable con el resto del data warehouse (compras, cuentas, etc). Lo que estas tablas no traen es el contenido real del mensaje — el texto del push, el HTML del email — eso vive en Braze mismo, no en el lake.

Volumen y frescura, tabla por tabla

Perfil real de las 26 tablas de Braze en ueno_staging, medido directo con count(*) y max(partition_date). Sirve como primer chequeo antes de escribir cualquier query: si la tabla que se necesita tiene pocas filas o quedó atrás en fecha, mejor saberlo acá que después de media hora armando un join.

El modelo de identidad

Esto es lo primero que hay que entender. Braze usa dos sistemas de ID distintos según la tabla, y no son intercambiables directo.

external_user_id — el que sirve para cruzar con el resto del lake

Es el ID que la mayoría de las tablas de envío/interacción usan. En ueno, external_user_id es directamente cod_persona — mismo valor numérico, sin necesidad de tabla puente.

Para bajar a documento o email, cruzar contra ueno_common.dim_persona (nro_documento, correo_electronico, ~3,1M personas). Evitar ueno_bankitti_ba_personas_nrt — cubre solo ~400K personas y da match rate bajo (~12%) comparado con dim_persona o ba_personas_v2_nrt.

user_id interno — solo en las tablas nativas de Canvas

Dos tablas identifican a la persona únicamente con el ID interno de Braze (hex tipo 69f9396f48f14b62e6d2314a), sin external_user_id en la fila: canvas_entry y canvasstep_progression. Ahí hay que puentear sí o sí. canvas_conversion y canvas_exit_performedevent, en cambio, sí traen external_user_id directo en la columna — no verificado el porcentaje de filas con el campo poblado, pero la columna existe y se puede intentar sin el puente primero.

ueno_braze_users_behaviors_app_sessionstart es la tabla que resuelve esto: trae user_id (interno) y external_user_id en la misma fila. Es prácticamente el único puente confiable — hub_braze_cod_persona, que promete resolver esto directo, está vacía hoy. first_session también sirve pero cubre menos volumen.

-- puente interno -> externo, quedarse con el mas reciente por persona
WITH bridge AS (
  SELECT user_id iid, external_user_id uid,
         row_number() OVER (PARTITION BY user_id ORDER BY formatted_time DESC) rn
  FROM ueno_staging.ueno_braze_users_behaviors_app_sessionstart
)
SELECT iid, uid FROM bridge WHERE rn = 1

Push

El canal con mejor trazabilidad de todos: es el único donde el envío lleva canvas_id propio.

In-App

Para medir el impacto de un paso In-App dentro de un canvas, la única vía hoy es medir el canvas completo (entrada + control, ver sección Canvas) en vez de aislar el canal.

Email

Tablas nativas de Canvas

Miden el canvas como objeto — quién entró, en qué variante, si Braze registró alguna conversión configurada. Usan el ID interno, no external_user_id.

Comportamiento — y el puente de identidad

Estas tablas no son de campañas, son de actividad del usuario en la app. Su valor acá es que varias traen user_id interno y external_user_id juntos.

Fuera de ueno_staging: rollup experimental de Canvas

Vive en otra base, con otro enfoque: en vez de un evento por persona, es un pre-agregado por canvas y día que ya junta push, email e in-app en la misma fila.

Matriz canvas × canal

Resumen de qué se puede medir hoy sin trabajo extra, por canal, cuando el mensaje viene de un Canvas (no de una campaña simple).

Por eso, para reportar performance de un canvas multicanal (Push + In-App + Email en un mismo flujo), lo más robusto es no intentar descomponer por canal y usar canvas_entry como unidad de exposición, comparando variante de test contra in_control_group = true.

Patrones de consulta

WITH snd AS (
  SELECT DISTINCT external_user_id uid, dispatch_id
  FROM ueno_staging.ueno_braze_push_notification_send
  WHERE partition_date BETWEEN '2026-06-01' AND '2026-06-30'
    AND campaign_name = '<nombre exacto de campaña>'
),
opn AS (
  SELECT DISTINCT o.external_user_id uid
  FROM ueno_staging.ueno_braze_users_messages_pushnotification_open o
  JOIN snd d ON d.dispatch_id = o.dispatch_id
)
SELECT count(DISTINCT snd.uid) enviados, count(DISTINCT opn.uid) abiertos
FROM snd LEFT JOIN opn ON opn.uid = snd.uid

SELECT count(*) filas, count(DISTINCT dispatch_id) dispatch_unicos,
       count(DISTINCT external_user_id) usuarios
FROM ueno_staging.ueno_braze_push_notification_send
WHERE canvas_id = '<id>' -- o campaign_name = '...'

WITH bridge AS (
  SELECT user_id iid, external_user_id uid,
         row_number() OVER (PARTITION BY user_id ORDER BY formatted_time DESC) rn
  FROM ueno_staging.ueno_braze_users_behaviors_app_sessionstart
),
bridge1 AS (SELECT iid, uid FROM bridge WHERE rn = 1),
entrada AS (
  SELECT user_id iid,
         min(date_parse(substr(formatted_time,1,19),'%Y-%m-%d %H:%i:%s')) entry_ts,
         max(CASE WHEN lower(CAST(in_control_group AS varchar))='true'
             THEN 1 ELSE 0 END) es_control
  FROM ueno_staging.ueno_braze_users_canvas_entry
  WHERE canvas_id = '<id>'
  GROUP BY 1
)
SELECT e.es_control, count(DISTINCT b.uid) personas
FROM entrada e JOIN bridge1 b ON b.iid = e.iid
GROUP BY 1

SELECT p.nro_documento, p.correo_electronico
FROM ueno_common.dim_persona p
WHERE p.cod_persona = CAST('<external_user_id>' AS bigint)

Trampas conocidas