A taxa de entrega responde à pergunta errada
Um recibo de entrega descreve o que a rede reportou sobre uma mensagem. A pergunta do negócio é outra: o usuário completou a verificação enquanto ainda estava no fluxo? Esses dois números podem se mover em direções opostas, e só o segundo é um resultado.
O modelo abaixo é construído em torno de resultados e das distribuições que os explicam. Não contém valores-alvo. Todo limiar que vale a pena alertar vem do histórico recente do próprio programa, por rota e por destino.
As métricas de resultado
Conclusão de verificação. Das sessões de autenticação em que um código foi emitido, a proporção em que a verificação teve sucesso. É o número principal. Segmente antes de tirar qualquer conclusão.
Conclusão na primeira tentativa e comportamento de reenvio. Com que frequência a verificação é concluída sem reenvio, e a distribuição de reenvios por sessão. Uma taxa de reenvio crescente em uma rota costuma aparecer antes da queda na conclusão.
Emissão duplicada. Sessões em que mais de um código foi emitido e permaneceu válido, e sessões em que o usuário digitou um código já substituído. Ambas são falhas autoinfligidas e corrigíveis no código.
Códigos expirados ou fora de ordem. Tentativas de verificação usando um código expirado, ou um código anterior chegando depois de um mais recente. Contagens altas indicam latência, não os usuários.
Loops de nova tentativa do usuário. Sessões em que o usuário solicitou um código repetidamente e nunca concluiu, e onde houve abandono.
As distribuições de latência
Três intervalos, reportados como distribuições em vez de médias:
- Emissão até aceitação — do momento em que seu serviço decide emitir um código até o fornecedor aceitar a submissão.
- Submissão até status final — aceitação até um status final da rota.
- Emissão até verificação — da emissão até uma tentativa de verificação bem-sucedida. Inclui o humano, e é o intervalo que determina se sua expiração é realista.
Compare a terceira distribuição com a expiração configurada e com sua política de segurança, em vez de copiar um valor padrão.
Os detalhamentos que localizam um problema
Toda métrica acima precisa ser fatiável por: fornecedor e rota; país e operadora; identidade de remetente e template; plataforma e versão do app; classe de tráfego e jornada; hora do dia.
Duas comparações merecem observação contínua: a lacuna entre entrega e verificação por rota; e erros de aplicação no endpoint de verificação, separados de erros do usuário.
Motivos canônicos de falha
| Grupo | Exemplos | Responsável |
|---|---|---|
| Aplicação | formato de destino inválido, template ausente, erro de endpoint | Sua engenharia |
| Política | limite de taxa atingido, destino suprimido, remetente não registrado | Sua operação |
| Fornecedor | rota rejeitada, throttled, erro de submissão, sem status final | Gestão de fornecedor |
| Rede de destino | filtrado, remetente bloqueado, rejeição de rede | Fornecedor mais escalonamento com operadora |
| Destinatário | inalcançável, assinante ausente, estado do aparelho | Não acionável por mensagem |
| Desconhecido | status não retornado dentro do prazo | Investigar como problema de qualidade de dados |
Mantenha o status e código brutos do fornecedor junto ao canônico.
Custo e abuso
Custo por verificação bem-sucedida, não por mensagem. Sinais de fraude e abuso: velocidade de solicitação por número, conta e rede; concentrações em destinos incomuns ou caros; solicitações que nunca levam à verificação.
Correlacionando os registros sem registrar o código
Cinco tipos de registro precisam ser unidos: a sessão de autenticação, a emissão do OTP, cada tentativa de mensagem, cada atualização de status e o resultado da verificação. Um identificador de correlação — gerado quando seu serviço decide emitir, carregado por todos os registros subsequentes e armazenado tanto no lado da aplicação quanto no da mensageria — é o que torna essa junção possível.
O código em si nunca faz parte dessa trilha. Armazene apenas o necessário para validar um código submetido.
Esquema de medição
auth_session: session_id, user_ref, journey, started_at, outcome, outcome_at
otp_issuance: issuance_id, session_id, correlation_id, issued_at, expires_at,
attempt_index, superseded_by, channel_policy
message_attempt: attempt_id, correlation_id, issuance_id, provider, route,
sender_id, country, operator, submitted_at, accepted_at,
provider_message_ref, client_reference
message_status: attempt_id, canonical_status, canonical_reason, raw_status,
raw_code, status_at, is_final
verification: verification_id, session_id, issuance_id, attempted_at, result,
failure_kind, device_platform, app_version
Toda métrica deste artigo é derivável dessas cinco tabelas. Nenhuma delas contém um valor de código.
Tabela de diagnóstico
| Observação | Causa provável | Primeira verificação |
|---|---|---|
| Entrega forte, verificação baixa em uma rota | Entrega tardia ou conteúdo não confiável nessa rota | Distribuição de submissão-a-status-final e emissão-a-verificação |
| Reenvios sobem, conclusão estável | Mensagens chegando tarde mas dentro da janela | Cauda de submissão-a-status-final por operadora |
| Reenvios sobem, conclusão cai, um país | Filtragem ou problema de registro nesse mercado | Motivos canônicos do grupo de rede de destino; estado de registro do remetente |
| Tentativas com código expirado aumentando | Expiração menor que o comportamento real do usuário | Distribuição emissão-a-verificação contra a expiração configurada |
| Tentativas com código substituído aumentando | Múltiplos códigos válidos por sessão | Registros de emissão por sessão; deduplicação em nível de sessão |
| Falhas de verificação com códigos válidos e no prazo | Defeito de aplicação ou validação | Tipos de falha no endpoint de verificação, por versão de app |
| Status finais ausentes em uma rota | Lacuna de reporte do fornecedor | Proporção de tentativas sem status final por fornecedor |
| Custo por verificação subindo, volume estável | Crescimento de reenvios ou abuso | Solicitações por verificação concluída; velocidade por número e rede |
Alertas
Alerte sobre desvios em relação à linha de base do próprio programa para aquela rota e destino. Toda métrica precisa de um responsável e uma ação: escalar ao fornecedor, mudar a rota, pausar uma campanha, ou abrir um defeito de aplicação.
A mecânica de entrega relacionada está em Guia prático de entrega de SMS A2P.