A maioria dos times de produto trata número de telefone como um dado binário: ou o app aceita, ou rejeita. Na prática, existe uma decisão de arquitetura escondida nesse meio-termo que afeta diretamente quantos usuários completam seu cadastro — e que a maioria dos apps erra sem perceber: como o sistema reage quando o usuário informa um número virtual ou temporário.
Este artigo argumenta por que suportar números temporários como cidadãos de primeira classe — em vez de bloqueá-los — é uma decisão de privacy-by-design que a maioria da documentação de "boas práticas de verificação" simplesmente ignora.
O bloqueio automático de números VoIP é mais comum do que parece
Muitos provedores de verificação por SMS oferecem, como feature de "segurança", a opção de rejeitar automaticamente números identificados como VoIP ou virtuais — a lógica por trás é que esse tipo de número está associado a fraude e criação de contas falsas em massa.
O problema é que essa heurística pune igualmente o usuário legítimo que, de forma consciente, optou por separar o número pessoal do número usado para cadastros públicos — exatamente o tipo de comportamento que qualquer discurso de privacidade digital deveria incentivar, não bloquear.
O trade-off real: fraude vs. fricção para usuário legítimo
Não existe decisão livre de trade-off aqui. Bloquear número virtual reduz uma fatia de contas fraudulentas criadas em massa — mas também bloqueia:
Usuários preocupados com privacidade que usam número dedicado para cadastros (um público que só cresce).
Usuários internacionais cujo plano de telefonia local aparece como VoIP para o provedor de verificação.
Times de QA e parceiros de negócio testando o produto com números isolados de teste.
Tratar todo número virtual como sinal de fraude é uma heurística preguiçosa que resolve o problema errado — o sinal de fraude real está no padrão de comportamento (múltiplas contas do mesmo IP, velocidade de criação anormal), não na natureza técnica do número em si.
O que uma arquitetura privacy-friendly faz diferente
Separa a decisão de "aceitar o número" da decisão de "confiar na conta". Aceitar um número virtual não deveria significar confiança total automática — mas também não deveria significar rejeição automática. O sinal de risco real vem de comportamento pós-cadastro (velocity checks, padrão de uso), não da classificação do número no momento do cadastro.
Permite verificação alternativa quando o canal padrão falha. Se o número informado não recebe SMS de verificação (comum em algumas linhas VoIP dependendo do provedor), oferecer verificação por chamada de voz ou e-mail como caminho alternativo evita perder o usuário no meio do funil só porque um canal específico não funcionou.
Não exige o número mais cedo do que necessário. Adiar a coleta de número de telefone para o momento em que ele é realmente necessário — em vez de exigir no primeiro passo do onboarding — reduz a chance de o usuário abandonar o cadastro só por hesitação em relação a esse campo específico.
Testando esse cenário sem gambiarra
Um efeito prático dessa discussão: se você quer testar como seu fluxo se comporta com número virtual — não só validar que funciona, mas realmente sentir a experiência que um usuário cuidadoso com privacidade teria — vale usar um número desse tipo no ambiente de teste, não simular com mock. Usamos o NumeroVirtual exatamente pra isso: dá pra passar pelo fluxo de verificação completo com uma linha real, virtual, sem precisar decidir arbitrariamente se "número virtual" é sinônimo de conta suspeita no seu produto.
Conclusão
Privacidade não é só sobre o que a aplicação faz com o dado depois de coletado — também é sobre não punir, de forma automática e indiscriminada, o usuário que já está tentando se proteger antes mesmo de interagir com seu produto. Tratar número virtual como sinal de risco isolado, em vez de um entre vários fatores comportamentais, é uma escolha de arquitetura que vale reconsiderar — especialmente se o seu funil de cadastro já perde gente exatamente nesse campo.
Top comments (0)