Como investigar discrepâncias de DLR em SMS A2P sem confundir entrega com receção humana

A pergunta certa: o que cada evidência realmente demonstra?

Uma investigação de discrepâncias de DLR em SMS A2P começa por separar factos que frequentemente surgem reunidos num único campo de estado. A aceitação do envio, o progresso na cadeia, o estado comunicado por um SMSC e a observação num terminal não são equivalentes.

Em SMPP, uma resposta submit_sm_resp bem-sucedida indica que o SMSC aceitou com êxito o pedido de submissão e atribuiu um message_id. Numa API HTTP, pode ocorrer algo comparável quando, segundo o contrato e a semântica documentada dessa API, o recurso é criado ou aceite e é devolvido um identificador. Isto comprova a aceitação técnica nesse ponto da cadeia, não a entrega no destino.

Os estados posteriores chegam de forma assíncrona. Em SMPP, um recibo do SMSC pode ser recebido através de deliver_sm ou data_sm. Esse DLR expressa o estado mantido ou comunicado pelo SMSC. Não deve ser automaticamente atribuído ao terminal, ao utilizador ou a todos os segmentos anteriores.

Uma observação independente — por exemplo, a receção registada por um dispositivo de teste controlado — é uma evidência distinta. Pode reforçar ou contradizer o DLR, mas também não comprova, por si só, a identidade da pessoa que utiliza o dispositivo nem permite generalizar o resultado a toda uma rota.

• Aceitação por API ou submit_sm_resp: o ponto recetor aceitou o pedido de submissão e devolveu um identificador.
• Estado temporário: informa sobre progresso, fila ou trânsito; não encerra necessariamente o ciclo.
• DLR final: declaração técnica da cadeia segundo a semântica documentada pela ligação.
• Observação independente: sinal separado obtido fora do fluxo de DLR; o respetivo método e alcance devem ser documentados.
• Leitura humana: não pode ser universalmente inferida a partir de um DLR de SMS.

Porque DELIVRD não comprova leitura nem identidade

A especificação SMPP usa o valor de estado DELIVERED, enquanto muitos DLRs textuais usam valores como DELIVRD. Um DLR tradicional pode também utilizar texto num formato específico do fornecedor do SMSC. Por isso, devem ser consultadas a especificação aplicável e a documentação oficial de cada ligação antes de mapear valores como DELIVRD.

A 3GPP distingue explicitamente a receção pela estação móvel da entrega ao utilizador. Mesmo quando existe confirmação da estação móvel, não fica demonstrado que uma pessoa tenha visto, aberto ou compreendido a mensagem. O SMS também não disponibiliza universalmente um recibo de leitura.

O estado comunicado como delivered pode resultar da confirmação de um operador a montante e só incorporar confirmação do terminal quando esta estiver disponível. A origem exata deve ser preservada em cada evento, em vez de ser transformada numa alegação mais forte.

Também não se comprova a identidade humana do destinatário. Um destino técnico ou dispositivo pode receber a mensagem sem demonstrar quem controla o número, quem tem o terminal ou quem visualiza o conteúdo. Um OTP deve ser tratado segundo o desenho de segurança completo do serviço, não como prova de identidade baseada apenas no DLR.

Também convém evitar uma confusão terminológica: o estado SMPP ACCEPTED não significa leitura normal nem aceitação inicial de transporte. A especificação descreve-o como leitura manual em nome do assinante pelo atendimento ao cliente. A aceitação inicial do envio é registada separadamente.

• Escrever «DLR comunicado como DELIVRD» em vez de «utilizador alcançado» quando não existir evidência adicional.
• Preservar o fornecedor, a ligação e a versão do mapeamento que converteu o valor original num estado interno.
• Não apresentar DELIVRD como leitura, identidade, consentimento ou garantia universal de receção no terminal.
• Manter separados delivered, observação no dispositivo e read quando um canal permitir eventos de leitura.

Modelo mínimo de rastreabilidade ponta a ponta

Uma correlação fiável exige um registo por mensagem lógica, por segmento quando existir concatenação e por evento recebido. Deve preservar-se o identificador interno juntamente com o message_id ou identificador atribuído por cada SMSC, API ou parceiro. O campo id do DLR SMPP refere-se ao identificador que o SMSC atribuiu ao envio original.

Não é aconselhável correlacionar exclusivamente pelo endereço do SMSC. A 3GPP alerta que arquiteturas de resiliência e balanceamento podem fazer com que um relatório seja emitido a partir de um endereço diferente daquele usado no envio original.

Normalizar os registos num esquema comum, mas preservar o evento original e a sua fonte. A normalização facilita consultas; os dados brutos permitem auditar erros de parsing e alterações de formato. O destino pode ser preservado numa representação normalizada baseada em E.164, juntamente com o valor original recebido.

Cada timestamp deve incluir a sua semântica, fonte e relação explícita com UTC através de Z ou offset. Não substitua a hora declarada pelo fornecedor pela hora de chegada do callback. Mantenha também a observação independente como um terceiro instante. Antes de interpretar uma sequência impossível, exclua relógios desalinhados.

• Identificador interno da mensagem lógica e identificador de cada segmento.
• Identificador do pedido, message_id do SMSC ou fornecedor e identificador do evento ou callback, quando existir.
• Timestamp de envio local, timestamp declarado pela fonte, receção do callback e observação independente.
• Fuso horário ou offset, precisão disponível, sistema de origem e relógio que produziu cada timestamp.
• Fornecedor, ligação, rota declarada, destino original e normalizado, operador observado ou declarado e remetente.
• Conteúdo normalizado ou impressão digital controlada, codificação, comprimento e número de segmentos, segundo a política de retenção aplicável.
• Estado e erro originais, estado interno normalizado e versão do mapeamento aplicado.
• Número da tentativa, motivo da nova tentativa, ambiente de teste ou produção e exclusões analíticas.

Taxonomia reproduzível de discrepâncias

Uma etiqueta precisa evita que problemas de observabilidade sejam prematuramente atribuídos à rota. Cada caso deve admitir uma regra verificável, uma janela temporal documentada e um estado de investigação.

A taxonomia interna deve distinguir estados temporários, finais e inconclusivos. A especificação SMPP define, entre outros, ENROUTE, DELIVERED, EXPIRED, DELETED, UNDELIVERABLE, ACCEPTED, UNKNOWN e REJECTED, mas a semântica efetiva deve ser verificada na documentação da ligação.

• Ausência: não existe DLR correlacionável dentro da janela observada. Não equivale automaticamente a falha de entrega.
• Duplicação: é recebida mais de uma cópia do mesmo evento ou estado. Deduplicar por identificador e janela temporal antes de agregar.
• Atraso: o DLR chega após o prazo esperado para esse segmento operacional, sem que isso altere o significado do estado.
• Contradição: duas fontes ou eventos finais atribuem resultados incompatíveis à mesma mensagem ou segmento.
• Não correlacionável: existe um DLR, mas o seu identificador não liga de forma segura ao envio original.
• Sequência inválida: uma transição viola a máquina de estados documentada ou as horas parecem impossíveis.
• Resultado parcial: uma mensagem concatenada contém segmentos bem-sucedidos e falhados; isto não deve ser ocultado sob um único resultado simples.
• Taxonomia desconhecida: surge um estado ou código não previsto na versão ativa do mapeamento.

Procedimento de investigação passo a passo

Primeiro, delimite o incidente sem misturar populações diferentes. Defina início e fim, caso de uso, destino, operador, remetente, fornecedor, ligação, rota declarada, tipo de tráfego, codificação e condição exata de inclusão. Registe também o tamanho da amostra e possíveis enviesamentos.

Em seguida, valide a observabilidade. Verifique se o endpoint de callbacks estava acessível, persistia o pedido antes de responder, aceitava o esquema recebido e devolvia uma resposta HTTP válida. Um validador excessivamente rígido pode rejeitar campos novos. Reveja filas, erros de ingestão, armazenamento, novas tentativas, deduplicação e sincronização de relógios.

Depois, reconstrua a cronologia por mensagem e por segmento: pedido, resposta inicial, estados temporários, DLR final, novas tentativas técnicas e observação independente. Compare valores originais e transformados, sem ordenar cegamente eventos produzidos por relógios diferentes.

Por fim, atribua o domínio mais provável: integração própria, observabilidade, mapeamento de estados, ligação do fornecedor, rota declarada, rede ou destino. Se a evidência não permitir isolá-lo, mantenha a classificação como indeterminada em vez de forçar uma causa.

• 1. Congelar o âmbito, a consulta e as exclusões para tornar a análise reproduzível.
• 2. Selecionar exemplos representativos e preservar os respetivos registos originais.
• 3. Verificar a receção, resposta e persistência dos callbacks.
• 4. Reconciliar mensagens pendentes através do mecanismo oficial de consulta, caso a ligação o disponibilize.
• 5. Correlacionar todos os identificadores sem depender apenas do destino ou do endereço do SMSC.
• 6. Rever timestamps, offsets, desfasamentos de relógio e a semântica de cada hora.
• 7. Aplicar a versão correta do mapeamento e verificar transições.
• 8. Separar integração, rota e destino; documentar incerteza e evidência em falta.

Timeouts, estados temporários e fecho operacional

Um timeout de API, ligação ou callback não demonstra que o SMS não foi entregue. A operação pode ter continuado após a perda da resposta. Procure o recibo posterior e, quando existir suporte oficial, reconcilie através de uma consulta de estado.

Erros temporários e estados em trânsito não devem ser convertidos em falhas finais enquanto as tentativas do centro de serviço continuarem ou a validade aplicável permanecer aberta. Da mesma forma, um pendente não deve ser transformado em delivered para completar um relatório.

Defina uma janela de fecho ligada ao caso de uso e à validade configurada. Num OTP, a utilidade pode terminar rapidamente, embora o estado técnico chegue mais tarde. Uma notificação não urgente pode admitir outra janela. A expiração funcional, o fecho analítico e o estado técnico são campos diferentes.

O TP-Discharge-Time também não deve ser sempre interpretado como hora de entrega bem-sucedida: consoante o estado, pode representar a entrega, a última tentativa ou a disposição da mensagem pelo centro de serviço.

• Preservar o estado técnico original após o fecho operacional.
• Etiquetar «sem DLR no fecho» em vez de reclassificar automaticamente como failed.
• Permitir reconciliações tardias sem reescrever silenciosamente relatórios já emitidos.
• Versionar a lógica de fecho e explicar a sua relação com a validade e o caso de uso.

Testes sintéticos e tráfego de produção

Os testes sintéticos permitem controlar o dispositivo, a hora, o conteúdo, o remetente e o método de observação. São úteis para reproduzir problemas e comparar DLR com receção observada. Contudo, uma amostra controlada não reproduz necessariamente a distribuição de destinos, terminais, disponibilidade, filtros e perfis do tráfego real.

O tráfego de produção oferece escala e diversidade, mas geralmente proporciona menos controlo sobre o terminal e não deve ser utilizado para inferir leitura ou identidade. Além disso, deve ser tratado de acordo com as regras aplicáveis de consentimento, finalidade e retenção de registos.

As observações de testes podem servir como sinais de qualidade, não como garantia universal de receção ou leitura. As métricas de teste não devem ser interpretadas como garantia, SLA ou condição comercial sem confirmação contratual.

Não misture testes e produção numa única taxa. Identifique separadamente o tráfego sintético, as novas tentativas técnicas e as mensagens concatenadas. Se comparar fontes, documente as diferenças de seleção, volume e método.

• Sintético: maior controlo e melhor reprodutibilidade; menor representatividade universal.
• Produção: maior diversidade; menor certeza sobre o que aconteceu no terminal.
• Utilizar mensagens legítimas, consentidas e em conformidade com a regulamentação aplicável.
• Não extrapolar um dispositivo de teste para uma rota inteira sem evidência suficiente.

Métricas úteis sem criar uma falsa certeza

Não reduza aceitação, cobertura de DLR, latência e resultado a uma única pontuação. São dimensões diferentes. A cobertura de DLR pode ser definida como a proporção de mensagens elegíveis com pelo menos um evento correlacionável; deve ser mantida separada da proporção comunicada como delivered.

Calcule a latência por percentis e por marcos claramente definidos. Por exemplo, aceitação até à receção do callback não é o mesmo que submit date até done date. Indique a fonte de ambos os extremos, o offset e o tratamento de valores em falta.

Antes de agregar, deduplique por identificador de mensagem ou evento e janela temporal. Exclua ou assinale separadamente testes, novas tentativas e mensagens concatenadas para evitar contagens duplicadas. Em mensagens concatenadas, meça também segmentos bem-sucedidos e falhados.

Crie linhas de base segmentadas por destino, operador, remetente, tipo de tráfego, rota declarada, faixa temporal comparável e versão de integração. Analise alterações sustentadas face a variações pontuais. Com pouco volume, apresente o tamanho da amostra e a incerteza em vez de rankings aparentemente precisos.

Reveja periodicamente a qualidade dos próprios dados: callbacks perdidos, relógios desalinhados, campos incompletos, identificadores reutilizados, timestamps futuros, erros de ingestão, saltos impossíveis e alterações abruptas de taxonomia.

• Cobertura de DLR: mensagens elegíveis com algum DLR correlacionável divididas por mensagens elegíveis.
• Consistência: proporção de eventos que respeitam a correlação, taxonomia e sequência definidas.
• Latência: percentis por par de marcos e segmento comparável, não apenas uma média.
• Antiguidade de pendentes: distribuição por intervalos desde o marco escolhido.
• Não correlacionados: proporção e volume de DLRs sem ligação segura ao envio.
• Contradições e duplicados: volume antes e depois da deduplicação.
• Painel recomendado: distribuição de estados, evolução de percentis, backlog por antiguidade, cobertura e qualidade de dados.
• Nota metodológica visível: fonte, âmbito, exclusões, janela, amostra, versão do mapeamento e limitações.