Números-semente em SMS A2P: testes controlados para avaliar rotas com prudência
Como criar um programa de números-semente para observar aceitação, DLR, latência e comportamento de rotas de SMS A2P sem confundir um teste sintético com uma garantia de entregabilidade.
O que é um número-semente e o que representa
Um número-semente é um número de destino controlado ou utilizado com autorização comprovável para realizar testes de mensagens em condições definidas. Num programa de SMS A2P, é atribuído a uma combinação específica de país, rede móvel, dispositivo, tipo de remetente e caso de utilização legítimo.
É recomendável armazenar ou normalizar o número no formato E.164, para dispor de uma referência internacional consistente do destino. Deve também ser mantido um inventário que identifique a rede prevista, o estado operacional do número, a titularidade ou autorização, o estado do consentimento quando aplicável e o histórico de alterações.
Uma semente não equivale a uma amostra representativa de utilizadores finais. Permite observar uma combinação controlada de variáveis, não demonstrar como irão responder todos os terminais, todos os assinantes ou todas as condições de rede. O seu principal valor é a repetibilidade: detetar alterações, inconsistências e degradações nas condições definidas pela equipa.
- Utilize-o como instrumento de observabilidade de uma rota específica.
- Não o apresente como uma garantia comercial de entrega.
- Mantenha separadamente o resultado da API, o DLR e a observação no dispositivo.
- Documente qualquer alteração de SIM, dispositivo, operador, localização operacional ou política de testes.
Questões operacionais a que um teste controlado pode responder
Um teste bem instrumentado pode verificar se a plataforma aceita um pedido de envio, se atribui um identificador rastreável, se recebe atualizações de estado e se existe consistência entre os eventos disponíveis. Pode também medir os intervalos observados entre a criação do teste, a aceitação do envio, as alterações de estado e a evidência independente registada no dispositivo.
A terminologia de estado deve ser interpretada com precisão. As plataformas de mensagens distinguem normalmente fases como colocação em fila, envio, aceitação por uma operadora upstream, entrega confirmada e não entrega. A aceitação de um pedido por uma API, ou a atribuição de um identificador de mensagem, não demonstra por si só que o terminal de destino recebeu o SMS.
Quando a equipa tem acesso ao dispositivo-semente, pode registar uma observação independente da receção. Em certos casos, um sinal posterior verificável e associado à mensagem, como a utilização de um código OTP num ambiente de teste controlado, também pode fornecer evidência adicional. Esta evidência deve ser identificada como distinta do DLR.
- O pedido foi aceite e associado a um identificador único?
- Foram recebidos eventos de estado e são consistentes com o fluxo esperado?
- Quanto tempo decorreu entre os eventos observados?
- A mensagem apareceu no dispositivo controlado?
- O remetente e o conteúdo comportaram-se como esperado nessa combinação específica?
- O teste esteve disponível durante o período programado?
O que as sementes não conseguem demonstrar por si só
Um resultado positivo numa semente não comprova a entregabilidade global de uma rota. As condições de entrega podem variar devido à filtragem pela operadora, à disponibilidade do terminal, ao comportamento do dispositivo, ao tipo de remetente, ao conteúdo, ao momento do envio e a condições de tráfego que não estejam presentes no teste.
Um DLR de não entrega também não deve ser automaticamente atribuído a um problema de rota. Pode resultar, entre outros fatores, da filtragem de conteúdo pela operadora ou da indisponibilidade do terminal de destino. A investigação deve partir das evidências disponíveis e evitar conclusões causais que o teste não permite sustentar.
A chegada tardia de um DLR exige um tratamento especialmente prudente. Como exemplo de uma janela documentada por um fornecedor, a AWS alerta que os DLR gerados por operadoras podem ser recebidos até 72 horas depois. Por isso, o momento de receção do DLR pela plataforma não deve ser usado como prova de que o envio de saída sofreu atraso durante o mesmo intervalo. Se não chegar um evento final, o resultado deve permanecer como desconhecido ou pendente, de acordo com a política documentada do programa.
- Não deduza a receção no terminal apenas a partir da aceitação pela API.
- Não equipare um DLR a uma observação independente quando esta não existe.
- Não transforme um teste isolado numa conclusão sobre toda uma rede ou país.
- Não interprete o atraso na chegada de um DLR como atraso de entrega sem evidência adicional.
- Não atribua todas as falhas à rota sem analisar o conteúdo, o terminal e o contexto do teste.
Crie uma matriz mínima e explícita de números-semente
A matriz deve ser construída com base nas decisões que a equipa precisa de tomar. Em vez de acumular números sem estrutura, defina cada célula como uma combinação de destino, rede móvel prevista, tipo de remetente, perfil de conteúdo e caso de utilização legítimo. Adicione um identificador de versão para saber qual a configuração em vigor em cada teste.
Comece com uma cobertura que seja operacionalmente sustentável. Expanda a matriz quando existir uma hipótese concreta: uma diferença entre remetentes, uma dúvida sobre uma operadora, uma alteração de comportamento devido à codificação ou um incidente que exija comparação. A expansão deve aumentar a capacidade de distinção do teste, e não apenas o volume de mensagens.
A rede prevista no inventário deve ser tratada como um atributo verificável e sujeito a revisão, e não como uma propriedade permanente deduzida apenas do prefixo.
- País ou destino normalizado no formato E.164.
- Rede móvel prevista e data da última verificação.
- Número-semente e estado operacional.
- Tipo de remetente utilizado no teste.
- Perfil de conteúdo e codificação prevista.
- Caso de utilização legítimo: OTP de teste, aviso transacional de teste ou outro fluxo autorizado.
- Dispositivo e método de observação independente, quando existente.
- Versão da matriz e responsável pela sua manutenção.
Selecione e mantenha sementes com controlo de autorização
Inclua apenas números que pertençam à equipa ou para os quais exista autorização comprovável para participar no programa. Se as mensagens tiverem natureza comercial ou estiverem sujeitas a requisitos locais de consentimento, identificação e cancelamento, o programa deve conservar as evidências aplicáveis. A responsabilidade de demonstrar o consentimento pode recair sobre o remetente, consoante a jurisdição.
O inventário deve registar, no mínimo, o identificador do número, a base da autorização, a data e o método de obtenção quando aplicável, o estado do consentimento, a data de inclusão, o responsável interno, o estado do dispositivo e a data da última verificação. Mantenha também um histórico de alterações e desativações.
Defina regras de substituição. Um número deve ser revisto ou substituído se se perder o acesso ao dispositivo, deixar de estar autorizado, alterar o estado operacional, apresentar observações recorrentes impossíveis de interpretar ou deixar de representar a célula da matriz para a qual foi incluído. A substituição não deve eliminar o histórico do número anterior.
- Restrinja o acesso ao inventário e aos dispositivos-semente.
- Separe a autorização de utilização, o estado técnico e o resultado dos testes.
- Registe desativações, revogações e ações resultantes.
- Reveja periodicamente a disponibilidade do dispositivo e a validade da autorização.
- Mantenha a rastreabilidade entre um teste histórico e a versão do inventário utilizada.
Crie mensagens de teste que permitam interpretar o resultado
A mensagem de teste deve ser reconhecível, legítima e suficientemente estável para permitir a comparação entre execuções. Inclua um identificador de teste não sensível quando necessário para correlacionar a observação no dispositivo com o registo de envio. Evite conteúdo com dados pessoais desnecessários, credenciais reais ou informações que não sejam indispensáveis para o objetivo técnico.
Registe a codificação e o comprimento do corpo da mensagem. São variáveis relevantes porque o número de segmentos transportados depende da codificação e do comprimento. Como referência técnica habitual, textos GSM-7 com mais de 160 caracteres e textos UCS-2 com mais de 70 caracteres são segmentados para tentar o seu reagrupamento. A documentação do fornecedor alerta que nem todas as operadoras e terminais suportam esse reagrupamento de forma uniforme.
Teste separadamente os perfis que precisa de comparar. Por exemplo, uma mensagem de um segmento em GSM-7, um caso UCS-2 autorizado e um caso multipartes se for relevante para o tráfego legítimo operado pela equipa. Não altere remetente, conteúdo, codificação e rota ao mesmo tempo se o objetivo for identificar a causa de uma diferença.
- Identificador interno de teste sem dados pessoais.
- Texto estável e fácil de reconhecer no dispositivo.
- Codificação prevista e comprimento da mensagem.
- Número de segmentos esperado e observado, quando disponível.
- Tipo e valor de remetente autorizado.
- Objetivo técnico do teste e variáveis mantidas constantes.
- Proibição de utilizar segredos, OTP reais ou dados sensíveis no conteúdo de teste.
Registe eventos, evidências e tempos por mensagem
Cada envio deve poder ser reconstruído de ponta a ponta. Conserve um identificador interno de execução e o identificador devolvido pela plataforma ou fornecedor, quando existir. Registe as marcas temporais de criação, envio, atualizações de estado, receção de DLR e observação independente no dispositivo.
Diferencie o tempo medido em cada etapa. O intervalo entre a criação e o evento de aceitação ou envio descreve uma parte da cadeia. O momento recebido num DLR pode refletir uma data incluída pela operadora, enquanto a receção do DLR pela plataforma reflete outro instante. Não una estes campos numa única métrica de latência sem preservar a respetiva origem.
Guarde os códigos de erro, o estado bruto quando disponível, as alterações de estado e as evidências de observação. Se o dispositivo apresentar a mensagem, anote o método de verificação e o momento da observação. Se for utilizado um sinal posterior verificável, registe qual foi o sinal, como foi associado à mensagem e quais são as suas limitações.
- ID interno do teste e ID externo da mensagem.
- Versão da rota ou configuração, se estiver disponível internamente.
- Destino-semente, célula da matriz e versão do inventário.
- Conteúdo ou impressão digital do conteúdo permitida pela política de privacidade.
- Codificação, comprimento e segmentos.
- Remetente e caso de utilização.
- Estados recebidos, códigos de erro e DLR bruto, quando aplicável.
- Marcas temporais com fuso horário e fonte de cada marca claramente diferenciados. A observação no dispositivo pode ser classificada como sim, não, não disponível ou não verificável. Registe também o resultado final classificado e o nível de evidência.
Trate DLR tardios, duplicados e contradições sem exagerar as evidências
Defina uma máquina de estados interna antes de executar testes em escala. Deve permitir eventos tardios, eventos repetidos e alterações de estado que cheguem numa ordem diferente da esperada. Conserve o histórico completo; não substitua um evento anterior sem deixar registo da sequência recebida.
Se chegar um DLR final depois do período operacional de observação, registe-o como evento tardio e atualize a classificação de acordo com a política, mas preserve a avaliação inicial e as suas marcas temporais. Se surgirem DLR duplicados, mantenha-os para auditoria e elimine duplicados apenas na camada analítica, através de regras explícitas.
Quando um DLR e a observação do dispositivo não coincidirem, não force uma explicação. Classifique o caso como inconsistente, reveja a correlação dos identificadores, o relógio do dispositivo, o conteúdo e o método de observação. Se não for possível estabelecer uma correspondência fiável, não afirme receção independente nem falha de rota.
- Pendente: ainda não existe um evento final de acordo com a janela definida.
- Final comunicado: existe um DLR ou estado final recebido.
- Observado no dispositivo: existe evidência independente documentada.
- Inconsistente: as fontes disponíveis não permitem uma interpretação única.
- Desconhecido: não existe evidência final suficiente após a janela aplicável.
- Tardio: o evento chegou depois da janela operacional e deve ser mantido em separado.
Perguntas frequentes
Um DLR delivered prova que o SMS foi visto pelo utilizador?
Não necessariamente. Um DLR é um sinal de estado recebido através da cadeia de mensagens. Deve ser distinguido de uma observação independente no dispositivo ou de outro sinal posterior verificável associado à mensagem. As evidências disponíveis e a sua origem devem ser registadas separadamente.
Quantos números-semente são necessários por operadora?
Não existe um número universal verificável. Defina a quantidade de acordo com as combinações que precisa de observar: destino, rede móvel prevista, remetente, conteúdo e caso de utilização legítimo. Comece com uma matriz sustentável e expanda-a quando uma hipótese operacional exigir maior capacidade de distinção.
Um teste com sementes consegue medir a latência de entrega real?
Pode medir intervalos observados entre eventos, mas deve identificar a fonte de cada marca temporal. A chegada de um DLR à plataforma não prova, por si só, o momento de entrega no terminal nem um atraso na entrega de saída.
Porque devo registar a codificação e os segmentos?
Porque GSM-7 e UCS-2 têm limites de segmentação diferentes, e as mensagens longas podem exigir reagrupamento. A documentação do fornecedor alerta que este comportamento não é suportado de forma uniforme por todas as operadoras e terminais.
Um HLR Lookup confirma que um número consegue receber um SMS?
Não. Um HLR Lookup não demonstra consentimento, identidade, titularidade nem entrega garantida. Deve ser tratado como uma fonte de informação distinta da autorização de utilização, dos eventos de envio e da observação da receção.
O que deve desencadear uma investigação de rota?
Uma discrepância repetida face a uma referência definida, uma perda de consistência entre DLR e observação independente, alterações persistentes por célula da matriz ou uma degradação que não possa ser explicada pela disponibilidade do dispositivo, pelo conteúdo ou por uma alteração documentada da configuração. Antes de atribuir a causa à rota, repita testes controlados e amplie a amostra de forma direcionada.
Fontes consultadas
- E.164: The international public telecommunication numbering planInternational Telecommunication Union (ITU)
- AWS End User Messaging SMS User GuideAmazon Web Services
- Messages resourceTwilio
- Frequently Asked Questions about Canada's Anti-Spam LegislationCanadian Radio-television and Telecommunications Commission (CRTC)
- From Canada’s Anti-Spam Legislation (CASL) Guidance on Implied ConsentCanadian Radio-television and Telecommunications Commission (CRTC)