Skip to main content

Middleware

O middleware processa dados do visitante e campanhas de personalização para decidir qual página será exibida ao usuário. Ele utiliza informações de cookies, conexão com serviços externos (Mantis), e regras de público-alvo configuradas para personalizar o conteúdo. Aqui está uma explicação detalhada:


Etapas do Processamento

  • O cookie ledger é recuperado e convertido em um objeto JSON.

  • Verifica-se se o objeto contém um e-mail válido.

    • Sem e-mail válido: O fluxo segue normalmente sem levar em consideração personalizações.

    Saiba mais sobre o Ledger aqui.


2. Integração com Serviços Externos

Conexão com o Mantis para recuperar informações do usuário através do seu email. Saiba mais sobre o Mantis aqui.

2.1 Serviço RDSM

  • Busca de Dados: Recupera informações do usuário cadastradas na RD Station.
  • Formatação de Dados: Os dados brutos são transformados em uma estrutura padronizada.

2.2 Serviço de Billing

  • Busca de Assinaturas: Recupera informações de assinaturas associadas ao e-mail.
  • Formatação de Dados: Os dados são formatados em uma estrutura padronizada.

2.3 Consolidação dos Dados do Usuário

Os dados de ambos os serviços são combinados em um único objeto userDataObject:

  • score: Pontuação atribuída pelo serviço RDSM.
  • tags: Tags associadas à area de atuação da empresa do usuário.
  • subscriptions: Informações sobre assinaturas recuperadas do serviço Billing.

3. Iteração sobre Personalizações

O middleware percorre as personalizações da campanha e aplica regras para determinar se alguma deve ser exibida ao usuário.

3.1 Verificação de Ativação

  • Personalizações inativas são ignoradas.

3.2 Validade Temporal

  • Personalizações temporárias possuem intervalo de validade:
    • Datas de início (startDate) e fim (endDate) são comparadas com a data atual.
    • Se a data atual estiver fora do intervalo, a personalização é ignorada.

3.3 Público Geral

  • Se a personalização é direcionada ao público geral (audience === 'general'), o caminho da URL é atualizado para a slug da personalização: rota padrão.

4. Correspondência com Público-Alvo

  • Para personalizações específicas, o middleware usa a biblioteca Web Personalization Lib para verificar se o perfil do usuário corresponde ao público-alvo (target).

  • A correspondência é feita com base nos dados do userDataObject (score, tags, subscriptions).

    Saiba mais sobre a Web Personalization Lib aqui.

4.1 Correspondência Sucedida

  • Se o perfil do usuário satisfaz os critérios, o caminho da URL é atualizado para a slug da personalização: rota personalizada.

4.2 Correspondência Não Sucedida

  • Caso nenhuma correspondência seja encontrada, o middleware continua verificando as personalizações restantes.

5. Tratamento de Erros

  • Qualquer erro durante a execução é capturado e tratado para evitar interrupções no fluxo.

6. Finalização

  • Se nenhuma personalização for aplicada, o middleware segue normalmente sem levar em consideração personalizações.

Resumo do Fluxo de Lógica

  1. O cookie ledger é decodificado, e o e-mail do usuário é validado.
  2. Dados do usuário são obtidos de serviços externos (RDSM e Billing).
  3. Um objeto consolidado com as informações do usuário é criado.
  4. O middleware verifica se alguma personalização se aplica:
    • Público Geral: Aplica imediatamente.
    • Público Alvo Específico: Verifica correspondência com o perfil do usuário.
  5. Se uma personalização correspondente for encontrada, a URL é atualizada.
  6. Se nenhuma regra se aplicar, a página padrão da campanha é exibida.
  7. O fluxo continua com o próximo middleware.

Leituras Relacionadas