Notificar consumidores sobre atualizações de pedidos com Content Cards

Mantenha um feed personalizado de Content Cards sempre atualizado com o status mais recente de cada pedido. Para isso, registre as atualizações de pedidos do seu sistema de gerenciamento de pedidos (OMS), envie Content Cards para atualizações como enviado ou cancelado e descarte cartões desatualizados no app com pares de chave-valor.

Sobre este exemplo

A Flash & Thread, uma varejista fictícia de roupas e beleza, quer um feed horizontal de Content Cards em seus apps móveis. Nele, cada cartão mostra o status de uma compra, por exemplo, quando um pedido passa de picked para dispatched (enviado) ou quando é cancelled.

O sistema de gerenciamento de pedidos armazena o e-mail do consumidor, o número do pedido, o status do pedido e a URL de rastreamento, e pode chamar a Braze quando esses valores são atualizados. O time de marketing quer textos de cartão específicos para cada status (por exemplo, “Seu pedido está a caminho” para dispatched e “Estamos preparando seu pedido” para picked). Os cartões mais antigos do mesmo pedido (como um cartão picked depois que um cartão dispatched chegou) devem ser descartados, para que os consumidores vejam apenas o status mais recente.

Este exemplo mostra como:

1. Registrar um evento personalizado (por exemplo, order_update) em /users/track quando o sistema de gerenciamento de pedidos registra uma mudança de status, como pendente, retido, separado, enviado ou cancelado
2. Disparar uma Campaign de Content Card baseada em ação separada para cada um desses status, com personalização em Liquid a partir das propriedades do evento
3. Definir pares de chave-valor (extras), como order_number e order_hierarchy, em cada cartão
4. Em um feed personalizado de Content Cards, manter apenas o cartão com o maior order_hierarchy para cada order_number e descartar os demais

Use essa abordagem quando os eventos de remoção do dashboard, por si só, não conseguirem atingir o cartão de um único pedido entre vários cartões da mesma jornada.

Considerações

• Os Content Cards expiram e são removidos no máximo 30 dias após o envio. Defina uma expiração mais curta para status finais (por exemplo, cancelado) quando quiser que eles saiam do feed mais cedo. Consulte Criar um Content Card.
• Se o sistema de gerenciamento de pedidos tiver apenas o e-mail, identifique o usuário em /users/track com o identificador secundário email. Prefira external_id quando o sistema de gerenciamento de pedidos tiver essa informação. Os aliases de usuário continuam sendo uma opção quando você precisa de um tipo de identificador personalizado: defina alias_name como o valor do identificador e alias_label como o tipo (por exemplo, email). Consulte Resolução de identificadores e Objeto de alias de usuário.
• As propriedades de eventos personalizados ficam disponíveis para personalização em Liquid e para segmentação por propriedade de evento quando você usa a jornada disparada por evento. Elas não ficam salvas no perfil como atributos, a menos que você também as grave como atributos.
• Campaigns de Content Card disparadas por API são uma alternativa que evita registrar um evento personalizado (e os pontos de dados correspondentes). Porém, cada Campaign precisa de um envio de disparo próprio, e você perde a segmentação por propriedade de evento para esse sinal.
• Feeds personalizados não são atualizados no meio da sessão até o início da próxima sessão ou até uma chamada manual de requestContentCardsRefresh. Chame a atualização quando o consumidor abrir o feed de pedidos ou puxar a tela para atualizá-lo.
• Interfaces de Content Cards totalmente personalizadas exigem o registro manual de análise de dados (impressões, cliques e descartes). Criar uma subclasse do feed padrão dá menos trabalho, mas não oferece suporte a um carrossel horizontal.
• Essa lógica de hierarquia pressupõe um status ativo por número de pedido de cada vez. Se um pedido puder ter vários status simultâneos (por exemplo, atendimentos divididos entre armazéns), adicione outra chave (como um ID de atendimento) e inclua-a nas suas regras de manter ou descartar.
• A lógica de descarte no app exige uma nova versão do app. Teste em um espaço de trabalho de desenvolvimento antes de ir para produção.

Configuração

Etapa 1: Registrar atualizações de pedidos a partir do sistema de gerenciamento de pedidos

Quando o sistema de gerenciamento de pedidos registrar uma mudança de status, envie um evento personalizado para /users/track. Inclua as propriedades de evento que o Content Card usa na personalização e que o app lê em extras.

A tabela a seguir mostra exemplos de propriedades:

Veja um exemplo de solicitação que identifica o usuário pelo e-mail:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

POST https://rest.iad-01.braze.com/users/track
Content-Type: application/json
Authorization: Bearer {YOUR_REST_API_KEY}

{
  "events": [
    {
      "email": "[email protected]",
      "name": "order_update",
      "time": "2026-09-28T16:02:05Z",
      "properties": {
        "order_number": "12345",
        "order_status": "picked",
        "tracking_url": "https://www.flashandthread.example/track/12345"
      }
    }
  ]
}

Use o endpoint REST do seu espaço de trabalho e uma chave de API com a permissão users.track. Substitua o e-mail e os valores de pedido de exemplo pela carga útil do seu sistema de gerenciamento de pedidos.

Etapa 2: Criar uma Campaign de Content Card para cada status de pedido

Crie uma Campaign de Content Card baseada em ação para cada status que você envia (por exemplo, pending, held, picked, dispatched, cancelled).

1. Acesse Envio de mensagens > Campaigns, selecione Criar campanha e, em seguida, selecione Content Cards.
2. Configure a entrega baseada em ação no evento personalizado order_update. Filtre pela propriedade de evento order_status correspondente para que apenas esse status entre nesta Campaign.
3. Use propriedades de evento em Liquid para personalizar o título ou o corpo do cartão:

1

Order {{event_properties.${order_number}}} is {{event_properties.${order_status}}}.

4. Na guia Configurações, selecione Adicionar novo par e adicione os pares de chave-valor usados pelo app:

A tabela a seguir mostra um exemplo de hierarquia. O app mantém o cartão com o maior valor para cada pedido:

5. Defina a expiração do cartão (até 30 dias). Prefira uma duração mais curta para status finais.

Os eventos de remoção do dashboard se aplicam no nível da Campaign e não conseguem remover apenas o cartão de um pedido, mantendo os outros da mesma Campaign. Por isso, o app descarta os cartões desatualizados usando extras.

Etapa 3: Manter o cartão mais recente de cada pedido no feed personalizado

Assine as atualizações de Content Cards no seu feed personalizado, leia extras e, para cada order_number, mantenha o cartão com o maior order_hierarchy. Descarte os demais com a API de descarte da sua plataforma para manter a análise de dados precisa.

Para cada cartão no feed:

1. Leia order_number e order_hierarchy em extras.
2. Encontre o maior order_hierarchy entre os cartões que compartilham esse order_number.
3. Se a hierarquia do cartão for igual ao maior valor, exiba-o (mapeie os campos do cartão para o seu objeto de interface personalizado).
4. Caso contrário, descarte o cartão.

Implemente as chamadas de assinatura e descarte com o SDK atual da sua plataforma. Comece por:

• Criação de cartões
• Personalização do feed
• Registro de análise de dados

Quando o consumidor já estiver no app, chame requestContentCardsRefresh para que os novos cartões de pedidos apareçam sem esperar pela próxima sessão.

Etapa 4: Testar a jornada de ponta a ponta

1. Envie uma sequência de eventos order_update para o mesmo pedido com valores de order_status crescentes.
2. Confirme se cada Campaign de status envia o cartão esperado e se o Liquid é resolvido corretamente.
3. Confirme se o feed mostra um cartão por pedido e se os cartões de hierarquia inferior são descartados.
4. Confirme se as impressões, os cliques e os descartes aparecem na análise de dados da Campaign para a sua interface personalizada.

Artigos relacionados

• Criar um Content Card
• Pares de chave-valor e comportamento de Content Cards
• Criação de Content Cards personalizados
• Personalização do feed de Content Cards
• Registro de análise de dados de Content Cards
• POST: Criar e atualizar usuários