Monitorar a entrega de Content Cards com alertas e Currents

Use ferramentas de depuração, alertas de limite, eventos do Currents e monitoramento de API para detectar quedas na entrega de Content Cards antes que os usuários as relatem.

Sobre este exemplo

A Pyrite Financial, uma marca fictícia de banco digital, exibe um Content Card em um espaço dedicado na tela inicial do app. Espera-se que esse espaço tenha um cartão para a maioria dos usuários. Portanto, um espaço vazio é um sinal que vale a pena investigar.

Este exemplo mostra como:

1. Validar a integração de Content Cards durante os testes com o SDK Debugger, grupos internos e o registro de usuários de eventos
2. Definir alertas de limite de Campaign ou Canvas para o volume esperado de mensagens
3. Acompanhar entradas no Canvas, envios, impressões e interrupções de Content Cards no Currents
4. Monitorar os endpoints da REST API que disparam o envio de mensagens para detectar quedas de volume e respostas diferentes de 200
5. Adicionar verificações complementares do volume de envios no Datadog ou com os endpoints de exportação do Canvas
6. Registrar o comportamento de fallback no app que a Braze não consegue observar

Use este exemplo quando um posicionamento de Content Card for crítico para o negócio e você precisar de um sinal operacional de que a entrega caiu. Cada etapa é opcional, então comece pelas que seu espaço de trabalho já suporta.

Considerações

• Primeiro, decida se todos os usuários direcionados devem sempre ver um cartão no posicionamento ou se um espaço vazio é aceitável para alguns usuários. Os limites de volume e a lógica de fallback dependem dessa resposta.
• A Braze monitora a conectividade do SDK e informa incidentes na página de status da Braze. Este exemplo aborda o que você mesmo monitora: configuração de Campaigns e Canvas, volume de mensagens, tráfego de API e comportamento de fallback no app.
• Nem todo disparo gera uma mensagem. Depois que um disparo chega à Braze, a lógica da jornada, o direcionamento, o limite de frequência e o limite de taxa podem reduzir os envios. Compare o volume de disparos com o volume de envios como uma tendência, não como uma correspondência exata.
• O monitoramento no nível de eventos exige o Currents. Sem o Currents, use a análise de dados de Campaigns e Canvas, os alertas de limite e os endpoints de exportação da REST API.
• As métricas do Datadog informam apenas contagens de envios e podem diferir um pouco do dashboard da Braze e do Currents.
• Atualizações excessivas podem ser limitadas. O SDK aplica limites de taxa por dispositivo às solicitações de atualização de Content Cards. Chame o método de atualização em momentos relevantes do ciclo de vida do usuário, em vez de repetidamente em sequência rápida. Consulte Limite de taxa de Content Cards e Melhorar a latência de Content Cards como banners.
• O Liquid pode suprimir um cartão intencionalmente. Quando o Liquid interrompe uma mensagem, a Braze registra um evento de interrupção de Content Card em vez de um envio. Trate as interrupções como comportamento esperado para conteúdo condicional e considere-as um sinal apenas quando o volume mudar.
• Se o seu app mostra um conteúdo padrão quando não há cartão disponível, acompanhe isso na análise de dados do seu próprio app. A Braze só sabe o que enviou, não se o seu app mostrou um cartão ou um espaço reservado.

Configuração

Etapa 1: Validar a integração antes do lançamento

Confirme o comportamento esperado para que os alertas em produção reflitam problemas reais, e não falhas de integração.

1. Crie uma sessão de depuração no SDK Debugger para acompanhar a atividade do SDK em tempo real e confirmar que as solicitações e impressões de cartões estão sendo registradas.
2. Adicione contas de teste a um grupo interno para testar a Campaign ou o Canvas com usuários teste antes do lançamento.
3. Verifique o registro de usuários de eventos de um usuário específico para confirmar qual Campaign entregou cada cartão ao SDK.

Anote os volumes de envios, impressões e interrupções que você observar durante os testes. Eles servem de base para os limites que você vai definir.

Etapa 2: Definir alertas de limite na Campaign ou no Canvas

Os alertas de limite notificam você por e-mail ou webhook quando o volume de mensagens fica fora do intervalo esperado. Os alertas por webhook podem ser encaminhados para um canal do Slack ou para um sistema de plantão.

• Campaigns: Defina limites superior e inferior na página de análise de dados da Campaign. Para ver as etapas de configuração, consulte Alertas de Campaign.
• Canvas: Configure alertas para entradas de usuários, mensagens enviadas ou ambos na página Gerenciar alertas. Para ver as etapas de configuração, consulte Alertas de limite do Canvas.

Escolha um limite inferior que seja menor que o volume normal e maior que zero. Assim, uma queda parcial dispara uma notificação, em vez de você esperar por uma interrupção completa.

Etapa 3: Acompanhar entradas, envios e impressões no Currents

O Currents transmite eventos de engajamento com mensagem e de comportamento do cliente para sua plataforma de dados quase em tempo real. Isso permite monitorar volume e latência fora do dashboard da Braze.

Para um Content Card enviado a partir de um Canvas, estes eventos cobrem a jornada da entrada até a impressão.

Para uma Campaign de Content Card, monitore os eventos de envio, impressão e interrupção e filtre por campaign_id.

• Monitoramento de volume: Acompanhe envios e impressões por Canvas ou Campaign em uma janela fixa e gere um alerta quando o volume ficar abaixo de um limite baseado em dados históricos.
• Monitoramento de latência: Compare os eventos de entrada com os de envio para medir a latência de criação, e os eventos de envio com os de impressão para medir a latência de exibição. Se os cartões forem criados na primeira impressão, medir da entrada até a impressão mistura o tempo de criação com o de exibição. Nesse caso, use o tempo entre envio e impressão para a latência de exibição.

Comparar os volumes entre as etapas ajuda a identificar modos de falha comuns:

• Menos entradas indicam um problema anterior no disparo ou no público.
• Entradas estáveis com menos envios podem indicar problemas na lógica da jornada, no direcionamento ou interrupções do Liquid. Se os cartões forem criados na primeira impressão, isso também pode significar que os usuários ainda não abriram o app.
• Envios estáveis com menos impressões indicam algo entre a criação e a exibição do cartão, como a atualização do SDK, a renderização do posicionamento ou os limites de taxa do dispositivo.

Para ver as cargas úteis e os campos dos eventos, consulte Eventos de engajamento com mensagem.

Etapa 4: Monitorar o tráfego de API e as respostas de erro

Se os seus disparos vêm dos seus próprios sistemas, monitore a camada de API que os alimenta.

1. Configure alertas de uso da API nos endpoints que disparam o envio de mensagens. Configure condições para quedas de volume e aumentos de respostas diferentes de 200.
2. Revise as respostas diferentes de 200 desses endpoints. Um aumento nas respostas de erro pode indicar que uma versão recente introduziu uma solicitação malformada ou que as chamadas estão atingindo um limite de taxa.

Etapa 5: Adicionar verificações complementares de volume

Use estas opções quando quiser dados de volume de envios em uma ferramenta de observabilidade existente ou em um job agendado.

• Datadog: A integração com o Datadog fornece a métrica braze.messaging.sent, com tags de identificadores de Campaign, Canvas e etapa do Canvas. Use-a para obter contagens de envios de uma etapa de mensagem específica em um determinado período. Essas contagens se aproximam do volume de envios de Content Cards em nível agregado e não incluem identificadores de usuário ou de envio.
• Endpoints de exportação: Consulte periodicamente /canvas/data_series e /canvas/data_summary para obter entradas no Canvas e envios de mensagens. Depois, compare os resultados entre as execuções para identificar tendências e anomalias.

Etapa 6: Registrar o comportamento de fallback no app

A Braze informa o que enviou, não o que seu app renderizou. Adicione registros ou análise de dados no app para os casos que a Braze não consegue observar:

• A atualização do feed foi concluída, mas não havia cartões disponíveis para o posicionamento.
• O app exibiu um conteúdo de fallback em vez de um cartão.
• A solicitação de atualização falhou ou foi limitada.

Envie esses casos como eventos personalizados se quiser vê-los junto com os dados da Braze, ou mantenha-os na sua própria plataforma de análise de dados e compare-os com o volume de impressões no Currents.

Etapa 7: Fazer a triagem quando um alerta for disparado

Siga estas verificações em ordem:

1. Confirme que não há nenhum incidente ativo na página de status da Braze.
2. No Currents (ou na análise de dados de Canvas e Campaigns), compare os volumes de entradas, envios, impressões e interrupções na mesma janela. Se os cartões forem criados na primeira impressão, o volume de entradas pode ser maior que o de envios até que os usuários abram o app. Leve isso em conta ao comparar os volumes.
3. Verifique os alertas de uso da API e as respostas diferentes de 200 nos endpoints que disparam a mensagem.
4. Compare os eventos de fallback ou de posicionamento vazio no app com o volume de impressões no Currents.
5. Reproduza o problema com um usuário de exemplo no SDK Debugger e no registro de usuários de eventos.

Artigos relacionados

• Relatórios de Content Cards
• Criação de cartões
• Alertas de Campaign
• Alertas de limite do Canvas
• Eventos de engajamento com mensagem
• Alertas de uso da API