Instantáneas frente a transmisiones de eventos

Los datos se clasifican en una de dos categorías fundamentales: instantáneas (estado) y transmisiones de eventos (lo que sucedió). Comprender esta distinción y aplicarla correctamente es una de las cosas más importantes que puedes hacer para asegurarte de que tu agente de Decisioning Studio Pro aprenda de manera efectiva.

Datos de instantánea (estado)

Una instantánea representa el estado de un cliente en un momento concreto. Responde a la pregunta: “¿Cómo es este cliente en este momento?”

Una instantánea es estática y agregada. Refleja el resultado acumulado de todos los cambios hasta ese momento. Es ideal para perfiles de usuario y características calculadas (por ejemplo, “días desde la última compra”, “nivel de fidelización”, “puntuación de cancelación”).

Campos obligatorios

Cómo deben actualizarse las instantáneas

• Desencadenante: Basado en el tiempo. Genera instantáneas según un calendario fijo (por ejemplo, a diario), incluidos los clientes sin actividad ese día.
• Alcance: Cada actualización debe incluir a todos los clientes relevantes, incluidos los que no tuvieron ningún evento.
• Método: Añade nuevos registros de instantánea al conjunto de datos en lugar de sobrescribir los valores anteriores. Así se conserva el estado histórico para el entrenamiento del modelo.

Consultar datos de instantánea para la entrega diaria

Decisioning Studio Pro ejecuta su canalización de recomendaciones una vez al día. Cuando entregues datos de instantánea, exporta la instantánea del día anterior en cada ejecución de la canalización:

1
2
3

SELECT *
FROM snapshot_data
WHERE snapshot_date = {t-1} -- on pipeline run date t, export the snapshot from t-1

Datos de transmisión de eventos (flujo)

Una transmisión de eventos registra acciones concretas a medida que ocurren. Responde a la pregunta: «¿Qué hizo este cliente y cuándo?». Una transmisión de eventos es ideal para datos sin procesar, inmutables, incrementales y cronológicos. Cada registro representa algo que ocurrió en un momento concreto. Por ejemplo, usa esta transmisión de datos para registros de activación, registros de participación (aperturas, clics), eventos de conversión o canjes de cupones.

Campos obligatorios

Importante

La marca de tiempo del evento y la marca de tiempo de creación son campos distintos y ambos son obligatorios. La marca de tiempo del evento registra cuándo ocurrió realmente la acción. La marca de tiempo de creación registra cuándo se escribió la entrada de datos en tu sistema, lo que puede ser más tarde debido a retrasos en el procesamiento. No confundas ambas.

Cómo deben actualizarse las transmisiones de eventos

• Desencadenante: Basado en eventos. Se añaden nuevos registros cuando ocurren nuevos eventos.
• Alcance: Solo los clientes que tuvieron un evento obtienen nuevos registros.
• Método: Los registros existentes son inmutables. Las actualizaciones siempre consisten en insertar nuevos registros.

Consultar los datos de eventos para la entrega diaria

Divide las exportaciones diarias según create_timestamp. A veces, los eventos se escriben en tu sistema después de que ocurran (llegadas tardías). Si divides según event_timestamp, esos registros que llegan tarde se perderán de forma permanente.

1
2
3
4

-- Correct: use create_timestamp to ensure late-arriving events are captured
SELECT *
FROM events_data
WHERE DATE(create_timestamp) = {t-1} -- on run date t, export all records created yesterday

1
2
3
4

-- Incorrect: slicing on event_timestamp will permanently lose late-arriving events
SELECT *
FROM events_data
WHERE DATE(event_timestamp) = {t-1}

Por ejemplo: si un evento ocurrió el 1 de enero pero no se escribió en tu sistema hasta el 2 de enero, dividir por event_timestamp el 2 de enero lo omitiría por completo. Dividir por create_timestamp lo captura correctamente.

Para integraciones nativas de Braze

Braze ofrece dos mecanismos integrados que se corresponden directamente con estos dos tipos de datos.

Atributos personalizados: datos instantáneos

Los atributos personalizados almacenan el estado a nivel de usuario en un momento determinado. Úsalos para perfiles de usuario y características calculadas (por ejemplo, churn_score, total_purchases_last_30d). Cada actualización sobrescribe el valor anterior, por lo que el atributo conserva el estado más reciente y los eventos anteriores desaparecen.

Braze Currents: datos de transmisión de eventos

Braze Currents proporciona datos de flujo de eventos sin procesar e inmutables. La tabla USER_BEHAVIOR_CUSTOM_EVENTS captura cada instancia de un evento personalizado en el momento en que ocurre, lo que la convierte en la fuente correcta para los eventos de activación, participación y conversión.

Consejo

Trata los atributos personalizados como la fuente del estado del cliente y Braze Currents como la fuente de los eventos de comportamiento del cliente. No uses atributos personalizados para enviar datos de eventos sin procesar a Decisioning Studio Pro.

Problemas comunes

Pasar datos de eventos como una instantánea

Agregar datos de eventos en campos de instantánea antes de enviarlos a Decisioning Studio Pro provoca varios problemas:

• Pérdida de granularidad: Después de agregar los datos en un resumen diario a nivel de cliente, los registros de eventos individuales desaparecen. Decisioning Studio Pro no puede reconstruirlos.
• Marcas de tiempo imprecisas: Un campo como “last_email_sent” te indica la ocurrencia más reciente, pero pierde el historial completo de eventos e imposibilita una atribución precisa.
• Actualizaciones fantasma: Incluso los días en que no se produjeron eventos, el registro de la instantánea se actualiza, lo que crea entradas duplicadas que son difíciles de deduplicar.

Si utilizas Braze, entrega los datos de eventos sin procesar a Decisioning Studio Pro con exportaciones de Currents.

Actualizar datos de instantánea con un desencadenante de evento

Algunas implementaciones actualizan los datos de instantánea solo cuando se produce un evento; por ejemplo, recalculan una característica solo cuando un cliente realiza una compra. Esto hace que las características que dependen del paso del tiempo queden desactualizadas para los clientes que no han tenido un evento reciente.

Por ejemplo, una característica como days_since_last_purchase tiene un valor correcto diferente cada día. Si solo se recalcula cuando se produce una compra, quedará congelada en un valor incorrecto para todos los clientes que no hayan comprado recientemente. Actualiza siempre los datos de instantánea según una programación basada en el tiempo que abarque a todos los clientes, todos los días.