Princípios gerais
Dados bem estruturados são a base de um agente eficaz do Decisioning Studio Pro. Antes de entrar nos requisitos específicos de cada ativo, vale a pena entender os quatro princípios fundamentais que se aplicam a todos os dados enviados ao Decisioning Studio Pro. Violações de qualquer um desses princípios estão entre as causas mais comuns de queda no desempenho do modelo.
Um identificador de cliente consistente em todos os ativos
Todos os ativos de dados (perfis de usuário, ativações, engajamentos, conversões) devem fazer referência ao mesmo identificador de cliente. Deve haver exatamente um identificador primário que identifique cada cliente de forma única e consistente em todos os ativos.
| Requisito | Implicação se não for atendido |
|---|---|
| Um identificador de cliente único deve estar presente em todos os ativos | Se ativos diferentes usarem sistemas de ID diferentes (por exemplo, um ID do data warehouse para recursos, mas um ID da plataforma para ativações), o mecanismo do Decisioning Studio Pro não consegue combiná-los de forma confiável. Isso quebra o ciclo de feedback e prejudica tanto o treinamento do modelo quanto a precisão dos relatórios. Se o mapeamento entre os dois sistemas de ID for de muitos para muitos, e não de um para muitos, as falhas de integridade de dados resultantes podem ser graves. |
Consulte Use o ID externo da Braze para saber qual identificador usar.
Dados de eventos devem ser enviados como um fluxo incremental
Eventos, como conversões, engajamentos e ativações, representam coisas distintas que aconteceram em um momento específico. Entregue cada evento ao Decisioning Studio Pro como um registro próprio, em um fluxo incremental (somente adição).
| Requisito | Implicação se violado |
|---|---|
| Dados de eventos devem ser estruturados como registros individuais com timestamp e entregues de forma incremental | Quando dados de eventos são agregados em um snapshot (por exemplo, armazenando um atributo de “hora do último envio” em vez de registros individuais de envio), você perde o momento exato de cada evento. Isso torna impossível atribuir resultados com precisão a decisões específicas e quebra o ciclo de feedback de que o modelo precisa para aprender. Sem timestamps precisos dos eventos, não é possível saber exatamente quando uma conversão aconteceu ou qual recomendação a disparou. |
Consulte Snapshots versus fluxos de eventos para uma explicação completa da distinção e exemplos de padrões corretos e incorretos.
Os dados de snapshot devem ser atualizados em um cronograma regular, baseado no tempo
Os dados de snapshot (como perfis de clientes e recursos) representam o estado atual de um cliente em um determinado momento. Atualize os dados de snapshot em um cronograma regular (por exemplo, diariamente) para todos os clientes, inclusive os que não tiveram novos eventos.
| Requisito | Implicação se não for cumprido |
|---|---|
| Os snapshots devem ser atualizados para todos os clientes em um cronograma regular, independentemente de o cliente ter tido um evento naquele dia | Se as atualizações de snapshot forem disparadas somente quando ocorre um evento, os recursos que dependem da passagem do tempo (como “dias desde a última compra” ou “dias desde a inscrição”) ficarão desatualizados para clientes sem eventos recentes. Então, o modelo será treinado com valores de recursos desatualizados. Isso reduz a capacidade dele de fazer recomendações precisas e oportunas. |
Todos os ativos devem atender aos requisitos mínimos de qualidade e integridade de dados
Além da estrutura, os próprios dados devem ser internamente consistentes e completos o suficiente para serem úteis.
| Requisito | Implicação se não for atendido |
|---|---|
| Cada ativo deve conter os campos necessários para estabelecer uma chave primária e, quando aplicável, chaves de junção com outros ativos. Registros duplicados devem ser removidos ou desduplicados antes da ingestão. | Registros duplicados ou sem correspondência adicionam ruído ao treinamento do modelo e podem causar atribuição incorreta. Chaves ausentes impedem que o mecanismo vincule eventos ao longo da jornada do cliente, da recomendação até a conversão. |
Especificamente para dados de fluxo de eventos, cada registro deve incluir, no mínimo:
Campos obrigatórios:
- Identificador do cliente
- Data e hora em que o evento ocorreu (o momento da própria ação; consulte Snapshots versus fluxos de eventos para entender como isso difere da data e hora de criação do registro)
- Data e hora em que o registro foi criado no seu sistema (usado para segmentar exportações incrementais de forma confiável)
- Tipo de evento
- Campos suficientes para filtrar os eventos específicos que interessam a você
Campos recomendados:
- Metadados adicionais do evento que permitam a correspondência confiável entre tipos de evento (por exemplo, vincular um evento de conversão à ativação específica que o precedeu)