Como comparar fornecedores de SMS A2P com um modelo de evidências

Porque o preço e um DLR declarado não são suficientes

Comparar fornecedores de SMS A2P apenas pelo preço, pela cobertura declarada ou por uma percentagem agregada de entrega introduz risco operacional. Estes indicadores podem ocultar diferenças entre países, redes móveis, identidades de origem, tipos de tráfego e condições de operação.

Uma rota pode aceitar um envio na API e devolver uma resposta inicial correta sem que isso descreva o resultado final comunicado pela rede. Da mesma forma, um estado final de entrega comunicado por um fornecedor não deve ser apresentado como uma verificação independente de que o destinatário viu a mensagem no seu terminal.

A decisão de sourcing deve separar o custo da evidência. Uma oferta só é comparável quando se sabe quais os destinos que realmente cobre, que tráfego aceita, que identidade de origem admite, como comunica os seus estados e que restrições aplica.

• Não trate a aceitação inicial de uma API como prova de entrega.
• Não consolide resultados de países ou redes diferentes numa única percentagem.
• Não presuma que um Sender ID é compatível ou visível em todos os destinos.
• Não aceite uma alegação de cobertura sem condições operacionais associadas.

O modelo de avaliação: declaração, documentação e observação

Um modelo útil distingue três níveis de informação. O primeiro é a declaração do fornecedor: cobertura, tipos de mensagem, capacidade, identidade de origem e estados disponíveis. Serve para a pré-qualificação, mas não é evidência suficiente para produção.

O segundo nível é a evidência documental: condições de serviço, restrições por destino, especificação de API ou SMPP, catálogo de estados, política de Sender ID, limites aplicáveis e mapeamento de erros. Esta documentação permite transformar uma promessa comercial em requisitos verificáveis.

O terceiro nível é a observação independente. Inclui testes controlados, registos próprios de envio e, quando viável e autorizado, observação de receção ou visualização em terminais de teste. Esta observação não prova que um destinatário leu a mensagem; apenas regista o que foi observado no dispositivo de teste sob essas condições. Deve estar associada a um destino, uma rede, um conteúdo, uma identidade de origem e uma janela temporal específicos.

• Declaração: o que o fornecedor afirma conseguir fazer.
• Documentação: como define, limita e comunica esse serviço.
• Observação: o que ocorreu num teste identificável e reproduzível.
• Decisão: que utilização fica autorizada, com que limites e até que data a evidência se mantém válida.

Quatro dimensões que devem ser avaliadas separadamente

A comparação torna-se mais fiável quando é dividida em quatro dimensões. Cada uma responde a uma pergunta diferente e exige uma evidência diferente.

Primeiro, legalidade e restrições: determine que tráfego legítimo a rota aceita, que requisitos existem para remetentes, modelos, pré-registos ou registos locais e que condições se aplicam ao país de destino. O suporte de Sender ID e os respetivos requisitos não são universais; alguns mercados exigem pré-registo e outros não apresentam o Sender ID ao destinatário. Os requisitos aplicáveis também podem variar consoante o tipo de remetente, a entidade que envia, o conteúdo, o registo e a relação contratual. Confirme as condições locais com fontes regulatórias, operadores ou aconselhamento competente.

Segundo, conectividade e operação: valide o método de ligação disponível, os campos obrigatórios, a gestão de identificadores, os estados assíncronos, a consulta de mensagens e a documentação de erros. Em SMPP, os erros de rede ou de SMSC podem ser específicos de cada rede ou implementação, pelo que o fornecedor deve explicar o seu mapeamento.

Terceiro, capacidade e continuidade: diferencie a aceitação do envio, o tempo de permanência em fila e o resultado final. Uma plataforma pode registar estas dimensões separadamente; nenhuma delas, isoladamente, demonstra que a capacidade será representativa para todos os destinos ou cenários de produção.

Quarto, qualidade observável: meça resultados segmentados, sequência de estados, latência e comportamento do conteúdo e do remetente. Como metodologia de avaliação, segmente por país, rede de destino quando disponível e identidade de origem quando pertinente. A avaliação deve refletir o que foi observado, e não estender uma amostra limitada a uma garantia geral.

• Legalidade e restrições: caso de utilização, consentimento ou base autorizadora aplicável, origem e requisitos locais.
• Conectividade e operação: HTTP ou SMPP, callbacks, consulta de estados, correlação e erros.
• Capacidade e continuidade: aceitação, fila, disponibilidade e incidentes.
• Qualidade observável: estados, tempos, segmentos, comportamento por rede e observação independente quando realizada.

Informação mínima a solicitar antes de testar uma rota

Antes de iniciar os testes, solicite uma ficha de pré-qualificação por destino. Como prática de normalização interna, registe o destino no formato E.164 e associe-o, quando possível, ao país e à rede móvel indicados pela plataforma, pela rede ou pela instrumentação de teste. Esse dado nem sempre está disponível e pode não representar o operador efetivo em cenários de portabilidade. A interface ou o fluxo do fornecedor pode exigir transformações ou um formato diferente, pelo que o respetivo requisito técnico deve ser confirmado. Esta normalização evita misturar resultados que não são comparáveis.

Peça ao fornecedor que descreva que tipos de tráfego legítimo admite: por exemplo, OTP, transacional ou marketing com consentimento. Deve também indicar as identidades de origem permitidas, as restrições de Sender ID, os requisitos de pré-registo, os modelos aplicáveis e quaisquer condições específicas do mercado.

Solicite o catálogo de estados de mensagem, o significado de cada estado, o canal de entrega de eventos assíncronos ou mecanismo de consulta, os identificadores disponíveis e o mapeamento de códigos de erro. Se o fornecedor comunicar limites operacionais, estes devem ficar associados ao destino e ao tipo de tráfego a que se aplicam.

• País de destino e números de teste normalizados internamente em E.164.
• Tipo de tráfego aceite e casos de utilização excluídos.
• Identidade de origem permitida e condições de Sender ID.
• Requisitos regulatórios, registos ou modelos aplicáveis.
• Estados DLR, semântica de cada estado e método de consulta ou callback.
• Identificador do fornecedor, identificador de correlação e mapeamento de erros.
• Condições operacionais e data de validade da informação.

Como conceber testes controlados sem transformar uma amostra numa garantia

Um teste deve responder a uma pergunta delimitada. Por exemplo: se um remetente específico é aceite para tráfego OTP legítimo para uma determinada rede, se são recebidos estados finais correlacionáveis ou se uma mensagem multipartes mantém o comportamento esperado. Não tente demonstrar a qualidade global de uma rota com uma única campanha de teste.

Defina previamente o conjunto de destinos, o período de observação, os casos de utilização, as identidades de origem, os conteúdos autorizados e os terminais de teste. Mantenha constantes os elementos que não está a avaliar. Se alterar o conteúdo, o remetente e o destino ao mesmo tempo, não conseguirá atribuir o resultado.

Inclua mensagens de uma e várias partes e registe a codificação utilizada. Em SMPP, data_coding identifica o esquema de codificação. A segmentação e os limites efetivos também dependem de elementos como UDH ou SAR, do alfabeto utilizado, da interface do fornecedor, da implementação do SMSC e da rede. Por isso, um teste de conteúdo curto não valida, por si só, mensagens segmentadas ou com outra codificação.

Para OTP, estabeleça uma janela temporal de avaliação explícita e prepare uma contingência operacional. Os recibos de entrega são assíncronos e a entrega pode ser atrasada se o terminal não estiver disponível. Um DLR tardio não deve ser interpretado automaticamente como um sinal suficiente para um caso de utilização sensível ao tempo.

• Formule uma hipótese concreta por teste.
• Segmente por país, rede, caso de utilização e identidade de origem.
• Teste uma e várias partes, com a codificação registada.
• Utilize conteúdo legítimo, autorizado e representativo do caso de utilização.
• Defina uma janela de observação antes de enviar.
• Não extrapole a amostra para destinos, redes ou volumes não testados.

O que registar em cada teste

A rastreabilidade depende da capacidade de reconstruir o histórico de cada mensagem. Conserve tanto o identificador atribuído pelo fornecedor como um identificador interno de correlação. Em SMPP, pode ser utilizada uma referência atribuída pelo ESME e o recibo de entrega pode incluir o identificador que o SMSC atribuiu à mensagem original. A utilização e a devolução efetiva destas referências ou campos dependem da implementação do SMSC ou do fornecedor.

Registe as marcas temporais da aceitação do envio, das alterações de estado, do estado final e da receção observada quando esta tiver sido realizada. O formato de recibo de entrega descrito em SMPP inclui submit date e done date, embora o formato concreto possa variar consoante o SMSC ou fornecedor. Done date indica quando a mensagem atingiu um estado final. Estes tempos permitem separar a aceitação técnica, a evolução da mensagem e a evidência independente disponível.

O registo deve preservar o contexto. Sem o destino, a rede indicada pela plataforma, pela rede ou pela instrumentação de teste quando disponível, o remetente, o conteúdo ou impressão digital do conteúdo, a codificação, o número de segmentos e o caso de utilização, não é possível interpretar corretamente um estado nem comparar testes posteriores. A evidência de consentimento ou de outra base autorizadora deve ser conservada em conformidade com a regulamentação, a finalidade e a jurisdição aplicáveis.

• ID interno de correlação.
• ID de mensagem do fornecedor ou SMSC.
• Número de destino normalizado internamente em E.164.
• País e rede de destino indicados pela plataforma, pela rede ou pela instrumentação de teste quando disponíveis.
• Caso de utilização e evidência de consentimento ou base autorizadora aplicável, conservada de acordo com a regulamentação, finalidade e jurisdição aplicáveis.
• Conteúdo testado ou impressão digital que permita identificá-lo sem expor dados desnecessários.
• Sender ID ou identidade de origem.
• Codificação e número de segmentos enviados e observados quando esse dado for apresentado, se corresponder ao teste realizado; não transforme um teste de uma parte em evidência de mensagens segmentadas ou com outra codificação. (A especificação SMPP torna explícita a relação entre data_coding, limites de payload e comportamento dependente de rede/SMSC.)

Como interpretar DLR, latência e disponibilidade

Os DLR são sinais operacionais valiosos, mas o seu significado depende da interface e do fornecedor. O SMPP define, entre outros, estados finais como DELIVRD, EXPIRED, UNDELIV e REJECTD, e contempla também DELETED e UNKNOWN. O formato concreto do recibo pode ser específico do fornecedor de SMSC. A ficha de avaliação deve documentar como cada estado e cada código são traduzidos para uma causa operacional.

Não confunda estados distintos. Por exemplo, numa nomenclatura específica de fornecedor, um estado de aceitação pode representar a aceitação por um fornecedor a montante, enquanto um estado de entrega pode depender da confirmação disponível por parte da operadora e, quando existir, do terminal de destino. Esta não é uma definição universal de SMPP nem de todos os DLR: a nomenclatura e a respetiva semântica são específicas de cada fornecedor e devem ser verificadas na sua documentação. Mesmo quando for documentada uma confirmação da operadora ou do terminal, esta não equivale a uma observação independente do dispositivo realizada pela equipa de avaliação, nem prova que o destinatário leu a mensagem. Nenhum estado deve substituir a observação independente quando esta for necessária para validar uma hipótese de teste.

Meça a latência por etapas: momento de envio, aceitação, último estado recebido, estado final e receção observada, se aplicável. Reportar uma única média pode ocultar atrasos relevantes para um fluxo OTP. Para marketing com consentimento, os critérios temporais podem ser diferentes, mas também devem ficar definidos antes do teste.

A disponibilidade deve ser observada juntamente com os incidentes e a recuperação. Registe rejeições, falhas de ligação, perdas ou atrasos de eventos, alterações de semântica e diferenças entre consulta e callback. Uma rota que parece disponível, mas não oferece rastreabilidade suficiente, pode não ser adequada para um caso de utilização que exija auditoria.

• Classifique cada métrica por etapa do ciclo da mensagem.
• Conserve a sequência de alterações de estado, não apenas o último estado.
• Solicite o mapeamento documentado de erros e estados específicos do fornecedor.
• Analise os resultados por segmento de destino, não apenas de forma agregada.
• Diferencie evidência de estado comunicado e receção observada.

Ficha de avaliação de fornecedor e critérios de decisão

A ficha de avaliação deve transformar a comparação numa decisão passível de revisão. Para cada pergunta, indique que evidência é aceite, quem a valida internamente, quando foi obtida e quando expira. Uma alegação não verificada deve continuar assinalada como declaração, e não como capacidade aprovada.

Defina um resultado por caso de utilização e destino: aprovado, aprovado com restrições, pendente de evidência ou rejeitado. Evite um “aprovado” genérico para todo o fornecedor. Uma mesma contraparte pode ser adequada para um fluxo transacional num destino e não estar validada para Sender ID, marketing com consentimento ou tráfego OTP noutro.

A evidência deve ser revista periodicamente. Os parâmetros de callback e os conjuntos de propriedades de eventos podem evoluir, e as restrições operacionais também podem mudar. Conceba integrações tolerantes a parâmetros adicionais e mantenha uma data de expiração para a documentação e os testes.

• Pergunta: que destino, tipo de tráfego e identidade de origem foram avaliados?
• Evidência aceitável: documentação válida, registos de teste e estados correlacionados.
• Resultado: aprovado, restringido, pendente ou rejeitado.
• Condições: limites de utilização, requisitos de remetente, conteúdo ou registo.
• Controlo: data de revisão e responsável interno.
• Acompanhamento: incidentes abertos, alterações detetadas e testes de regressão necessários.