Snapshots versus fluxos de eventos

Os dados se enquadram em uma de duas categorias fundamentais: snapshots (estado) e fluxos de eventos (o que aconteceu). Entender essa distinção e aplicá-la corretamente é uma das coisas mais importantes que você pode fazer para garantir que seu agente do Decisioning Studio Pro aprenda de forma eficaz.

Dados de snapshot (estado)

Um snapshot representa o estado de um cliente em um momento específico. Ele responde à pergunta: “Como está este cliente agora?”

Um snapshot é estático e agregado. Ele reflete o resultado cumulativo de todas as mudanças até aquele momento. É ideal para perfis de clientes e recursos calculados (por exemplo, “dias desde a última compra”, “nível de fidelidade”, “pontuação de churn”).

Campos obrigatórios

Como os snapshots devem ser atualizados

• Disparo: Baseado em tempo. Gere snapshots em um cronograma fixo (por exemplo, diariamente), incluindo clientes sem atividade naquele dia.
• Escopo: Toda atualização deve incluir todos os clientes relevantes, inclusive aqueles que não tiveram nenhum evento.
• Método: Acrescente novos registros de snapshot ao conjunto de dados em vez de sobrescrever os valores anteriores. Assim, você preserva o estado histórico para o treinamento do modelo.

Consultar dados de snapshot para entrega diária

O Decisioning Studio Pro executa seu pipeline de recomendação uma vez por dia. Ao entregar dados de snapshot, exporte o snapshot do dia anterior a cada execução do pipeline:

1
2
3

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

Dados de fluxo de eventos (fluxo)

Um fluxo de eventos registra ações individuais à medida que elas acontecem. Ele responde à pergunta: “O que este cliente fez e quando?” Um fluxo de eventos é ideal para dados brutos, imutáveis, incrementais e cronológicos. Cada registro representa algo que aconteceu em um momento específico. Por exemplo, use esse fluxo de dados para registros de ativação, logs de engajamento (aberturas, cliques), eventos de conversão ou resgates de cupons.

Campos obrigatórios

Importante

O carimbo de data/hora do evento e o carimbo de data/hora de criação são campos diferentes, e ambos são obrigatórios. O carimbo de data/hora do evento registra quando a ação realmente aconteceu. O carimbo de data/hora de criação registra quando a entrada de dados foi gravada no seu sistema, o que pode acontecer depois por causa de atrasos no processamento. Não confunda os dois.

Como os fluxos de eventos devem ser atualizados

• Disparo: Orientado por eventos. Novos registros são adicionados quando ocorrem novos eventos.
• Escopo: Apenas clientes que tiveram um evento recebem novos registros.
• Método: Os registros existentes são imutáveis. As atualizações são sempre inserções de novos registros.

Consultar dados de eventos para entrega diária

Divida as exportações diárias com base em create_timestamp. Às vezes, os eventos são gravados no seu sistema depois de ocorrerem (chegadas tardias). Se você dividir com base em event_timestamp, esses registros que chegam com atraso serão perdidos permanentemente.

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 exemplo: se um evento ocorreu em 1º de janeiro, mas só foi gravado no seu sistema em 2 de janeiro, a divisão por event_timestamp em 2 de janeiro o perderia completamente. Já a divisão por create_timestamp o captura corretamente.

Para integrações nativas da Braze

A Braze oferece dois mecanismos integrados que correspondem diretamente a esses dois tipos de dados.

Atributos personalizados: dados de snapshot

Os atributos personalizados armazenam o estado do usuário em um determinado momento. Use-os para perfis de usuário e recursos calculados (por exemplo, churn_score, total_purchases_last_30d). Cada atualização substitui o valor anterior. Portanto, o atributo guarda o estado mais recente, e os eventos anteriores são perdidos.

Braze Currents: dados de fluxo de eventos

O Braze Currents fornece dados brutos e imutáveis de fluxo de eventos. A tabela USER_BEHAVIOR_CUSTOM_EVENTS captura cada ocorrência de um evento personalizado no momento em que acontece. Por isso, ela é a fonte correta para eventos de ativação, engajamento e conversão.

Dica

Trate os atributos personalizados como a fonte do estado do cliente e o Braze Currents como a fonte dos eventos de comportamento do cliente. Não use atributos personalizados para enviar dados brutos de eventos ao Decisioning Studio Pro.

Problemas comuns

Enviar dados de eventos como snapshot

Agregar dados de eventos em campos de snapshot antes de enviá-los ao Decisioning Studio Pro causa vários problemas:

• Perda de granularidade: Depois que os dados são agregados em um resumo diário por cliente, os registros individuais de eventos deixam de existir. O Decisioning Studio Pro não consegue reconstruí-los.
• Registros de data e hora imprecisos: Um campo como “last_email_sent” informa a ocorrência mais recente, mas perde o histórico completo de eventos e torna impossível uma atribuição precisa.
• Atualizações fantasmas: Mesmo em dias sem nenhum evento, o registro do snapshot é atualizado. Isso cria entradas duplicadas difíceis de deduplicar.

Se você usa a Braze, entregue os dados brutos de eventos ao Decisioning Studio Pro com exportações do Currents.

Atualizar dados de snapshot com base em um evento

Algumas implementações atualizam os dados de snapshot apenas quando um evento ocorre, por exemplo, recalculando um recurso somente quando um cliente faz uma compra. Com isso, recursos que dependem da passagem do tempo ficam desatualizados para clientes que não tiveram um evento recente.

Por exemplo, um recurso como days_since_last_purchase tem um valor correto diferente a cada dia. Se ele for recalculado apenas quando ocorre uma compra, ficará congelado em um valor incorreto para todos os clientes que não compraram recentemente. Sempre atualize os dados de snapshot com um cronograma baseado em tempo que abranja todos os clientes, todos os dias.