Campaign Standard: incompatibilidade de logs de envio no perfil
Em casos raros, o Campaign Standard pode exibir entradas de log de envio em um perfil que não pertence realmente a esse perfil. Isso pode criar a impressão de que os deliveries ou eventos de email foram associados incorretamente a um recipient, mesmo que os registros do banco de dados subjacente não estejam corrompidos. Normalmente, o problema é limitado ao comportamento de interface do usuário/consulta quando um perfil de recipient e um perfil de teste compartilham o mesmo valor de identificador interno em suas respectivas tabelas de origem.
Descrição description
Um cliente relatou que a visualização Enviar logs para um perfil de destinatário real mostrava eventos de email que pertenciam a um perfil de teste separado. Alguns dos eventos exibidos antecederam a criação do perfil real, o que deixou claro que os registros não podiam pertencer legitimamente a esse recipient.
O inquérito revelou que:
- O perfil real e o perfil de teste eram entidades separadas e não estavam funcionalmente vinculados.
- O recipient real não era realmente direcionado nas entregas afetadas em que as entradas de log inesperadas apareciam.
- Os dados de rastreamento permaneceram consistentes para o recipient real.
- O comportamento inesperado foi observado principalmente na exibição de logs de envio e no comportamento de pré-visualização da consulta, não como evidência de ampla contaminação do banco de dados.
- Isso gerou confusão para o cliente, pois a interface do usuário sugeriu um histórico de entrega impreciso e levantou a preocupação de que a geração de relatórios e a análise de público-alvo pudessem ser afetadas.
Resolução resolution
Causa raiz
O problema foi causado por uma rara colisão de ID interna entre:
- um perfil de recipient armazenado no conjunto de dados de perfis/recipients e
- um perfil de teste armazenado no conjunto de dados do seed-member.
Ambos os tipos de perfil gravam dados de log na tabela broadLogRcp, que armazena o perfil relacionado ou o identificador do perfil de teste na mesma coluna profileId. Quando o recipient e o perfil de teste tinham o mesmo valor de ID interno, as consultas contra o envio de logs retornavam entradas para ambas as entidades.
Por que isso aconteceu:
- Os novos perfis de recipient obtêm IDs da sequência nmsRecipientId.
- Os perfis de teste obtêm IDs da sequência xtkNewId.
- Nesse caso, o recipient foi criado em um momento em que sua ID gerada correspondia a uma ID de perfil de teste já existente.
- Como resultado, a interface do usuário e os caminhos de consulta relacionados recuperaram todas as linhas do log de envio correspondentes a essa ID interna. Como o endereço de email exibido na interface do usuário é retirado do campo de endereço do log de envio, os usuários podem ver o email do perfil de teste no histórico do log de envio do recipient, mesmo que os dados subjacentes do recipient não tenham sido misturados ou corrompidos.
Os engenheiros avaliaram isso como um caso de borda de baixa probabilidade, em vez de um problema que provavelmente ocorrerá de maneira ampla.
Resolução
As opções de resolução recomendadas eram:
- Exclua e recrie o perfil de teste afetado. Essa é considerada a ação corretiva mais limpa porque o perfil de teste recriado recebe uma nova ID interna. Os deliveries futuros para esse perfil de teste não aparecerão mais nos logs de envio do recipient real.
- Limpe manualmente as linhas históricas de log de envio, se necessário. Se a visibilidade do log histórico for uma preocupação, as linhas antigas vinculadas ao endereço obsoleto do perfil de teste podem ser removidas manualmente. Isso só será necessário se você quiser eliminar o histórico de incompatibilidade já gravado antes que a retenção normal o remova.