Principios generales
Los datos bien estructurados son la base de un agente eficaz de Decisioning Studio Pro. Antes de profundizar en los requisitos específicos de cada activo, conviene comprender los cuatro principios fundamentales que se aplican a todos los datos que envías a Decisioning Studio Pro. El incumplimiento de cualquiera de estos principios es una de las causas más comunes de un rendimiento degradado del modelo.
Un identificador de cliente coherente en todos los activos
Cada activo de datos (perfiles de clientes, activaciones, interacciones, conversiones) debe hacer referencia al mismo identificador de cliente. Debe haber exactamente un identificador principal que identifique a cada cliente de forma única y coherente en todos los activos.
| Requisito | Implicación si no se cumple |
|---|---|
| Un identificador de cliente único debe estar presente en cada activo | Si distintos activos usan sistemas de ID diferentes (por ejemplo, un ID de almacén de datos para las características, pero un ID de plataforma para las activaciones), el motor de Decisioning Studio Pro no puede unirlos de forma fiable. Esto rompe el ciclo de retroalimentación y degrada tanto el entrenamiento del modelo como la precisión de los informes. Si el mapeado entre los dos sistemas de ID resulta ser de muchos a muchos en lugar de uno a muchos, los fallos de integridad de datos resultantes pueden ser graves. |
Consulta Usar el ID externo de Braze para obtener orientación sobre qué identificador utilizar.
Los datos de eventos deben pasarse como un flujo incremental
Los eventos, como conversiones, interacciones y activaciones, representan cosas concretas que ocurrieron en un momento específico. Entrega cada evento a Decisioning Studio Pro como su propio registro en un flujo incremental (solo de adición).
| Requisito | Implicación si se incumple |
|---|---|
| Los datos de eventos deben estructurarse como registros individuales con marca de tiempo y entregarse de forma incremental | Cuando los datos de eventos se agregan en una instantánea (por ejemplo, almacenando un atributo de “hora del último envío” en lugar de registros de envío individuales), pierdes la temporización precisa de cada evento. Esto hace imposible atribuir con precisión los resultados a decisiones específicas, lo que rompe el ciclo de retroalimentación que el modelo necesita para aprender. Sin marcas de tiempo precisas de los eventos, no puedes saber exactamente cuándo ocurrió una conversión ni qué recomendación la desencadenó. |
Consulta Instantáneas frente a flujos de eventos para ver una explicación completa de la distinción y ejemplos de patrones correctos e incorrectos.
Los datos de instantáneas deben actualizarse según un calendario regular basado en el tiempo
Los datos de instantáneas (como los perfiles de usuario y las características) representan el estado actual de un cliente en un momento determinado. Actualiza los datos de instantáneas según un calendario regular (por ejemplo, a diario) para todos los clientes, incluidos aquellos que no tengan eventos nuevos.
| Requisito | Implicación si no se cumple |
|---|---|
| Las instantáneas deben actualizarse para todos los clientes según un calendario regular, independientemente de si un cliente tuvo un evento ese día | Si las actualizaciones de instantáneas solo se desencadenan cuando ocurre un evento, las características que dependen del paso del tiempo (como «días desde la última compra» o «días desde la inscripción») quedarán desactualizadas para los clientes que no hayan tenido un evento reciente. El modelo se entrenará con valores de características obsoletos, lo que reduce su capacidad para hacer recomendaciones precisas y oportunas. |
Todos los activos deben cumplir requisitos mínimos de calidad e integridad de los datos
Más allá de la estructura, los datos en sí deben ser coherentes internamente y lo suficientemente completos como para resultar útiles.
| Requisito | Implicación si no se cumple |
|---|---|
| Cada activo debe contener los campos necesarios para establecer una clave principal y, cuando corresponda, claves de unión con otros activos. Los registros duplicados deben eliminarse o deduplicarse antes de la ingesta. | Los registros duplicados o que no se pueden emparejar añaden ruido al entrenamiento del modelo y pueden provocar una atribución incorrecta. La falta de claves impide que el motor vincule eventos a lo largo del recorrido del cliente, desde la recomendación hasta la conversión. |
En concreto, para los datos de flujos de eventos, cada registro debe incluir como mínimo:
Campos obligatorios:
- Identificador del cliente
- Marca de tiempo de cuándo ocurrió el evento (el momento de la acción en sí; consulta Instantáneas frente a flujos de eventos para saber en qué se diferencia de la marca de tiempo de creación del registro)
- Marca de tiempo de cuándo se creó el registro en tu sistema (se usa para segmentar de forma fiable las exportaciones incrementales)
- Tipo de evento
- Campos suficientes para filtrar hasta los eventos específicos que te interesan
Campos recomendados:
- Metadatos adicionales del evento que permitan un emparejamiento fiable entre tipos de eventos (por ejemplo, vincular un evento de conversión con la activación específica que lo precedió)