Avaliação da performance dos serviços de autenticação biométrica facial de entregadores, com foco em prevenção à fraude, confiabilidade dos provedores e impacto operacional.

Este case foi desenvolvido para o time de Prevenção à Fraude do iFood, utilizando BigQuery (SQL) para modelagem e análises, e Looker Studio para visualização.

---

Visão geral do case

• Objetivo: avaliar o desempenho dos serviços de biometria (A, B e C), identificar padrões de falha, possíveis comportamentos suspeitos (como empréstimo de conta) e oportunidades de melhoria.
• Cenário:
  • Cada sessão de biometria pode passar por até 3 serviços (A, B, C) em fallback.
  • Uma sessão é considerada MATCH quando a similaridade ≥ 0.80.
• Perguntas centrais do case:
  1. Qual dos serviços mais falha? (status = PROVIDER_FAILED)
  2. Qual categoria de entregador possui maior índice de falha biométrica? (status = NOT_MATCH)
  3. O que acontece com o índice geral de MATCH se elevarmos o limiar para 0.90?
  4. Existe relação entre cancelamentos de pedidos e o status biométrico?
  5. Em quais dias há maior suspeita de “empréstimo de conta”?

---

Materiais principais

• Apresentação da análise (PDF)
  case_biometria_ifood_silvania_correia.pdf

• Enunciado do case (PDF)
  enunciado.pdf

---

Dados brutos (raw_data/)

Os dados originais utilizados na análise estão em:

• raw_data/biometry.csv – sessões de biometria (1 linha por sessão, status final).
• raw_data/biometry_execution.csv – até 3 execuções por sessão (Serviços A, B, C).
• raw_data/drivers.csv – cadastro e perfil dos entregadores (categoria, modal, data de registro, device).
• raw_data/orders.csv – pedidos associados aos entregadores, incluindo status (CANCELLED) e valor.

---

Modelagem e consultas SQL (queries/)

Toda a solução foi construída em cima de views analíticas e consultas temáticas, organizadas em pastas.

Checks de qualidade de dados (queries/checks/)

Validações de consistência antes da modelagem:

• queries/checks/duplicidades.sql – detecção de linhas duplicadas.
• queries/checks/integridade_referencial.sql – checagem de chaves entre tabelas.
• queries/checks/nulos.sql – análise de campos nulos.
• queries/checks/perfil_tabelas.sql – perfil estatístico das tabelas.
• queries/checks/verificacao_driver_id.sql – consistência de Driver_ID entre fontes.

Views analíticas (queries/views/)

Views em BigQuery que estruturam a base de análise:

• queries/views/views_typed.sql – padronização de tipos (*_typed).
• queries/views/vw_biometry_base.sql – une sessões finais à execução por serviço, consolidando status e similaridades.
• queries/views/vw_biometry_enriched.sql – enriquece a biometria com atributos do entregador (categoria, modal, register date, device).
• queries/views/vw_orders_daily.sql – agregação diária de pedidos, cancelamentos e taxa de cancelamento por entregador.

Essas views servem como camada “gold” analítica, sobre a qual cada questão de negócio é respondida.

Consultas por questão de negócio (queries/questoes/)

Cada arquivo responde diretamente uma pergunta do enunciado:

• A. Falhas por serviço (PROVIDER_FAILED)
  • queries/questoes/a_falhas.sql
    Calcula taxa de falha por provedor, taxa total de falha do sistema e séries diárias por serviço.
• B. Categoria de entregador com maior falha (NOT_MATCH)
  • queries/questoes/b_not_match_categoria_driver.sql
    Relaciona taxa de NOT_MATCH com categoria, cancelamentos, devices e tempo de plataforma.
• C. Impacto de elevar o limiar de similaridade para 0.90
  • queries/questoes/c_match_threshold.sql
    Simula o novo índice de MATCH com threshold 0.90 e compara com o cenário atual (0.80).
• D. Relação entre cancelamentos e status biométrico
  • queries/questoes/d1_visao_por_driver.sql – visão detalhada por entregador (biometria + pedidos).
  • queries/questoes/d2_medida_correlacao.sql – correlação, médias por grupo (MATCH vs NOT_MATCH) e teste t.
• E. Suspeita de “empréstimo de conta”
  • queries/questoes/e1_indice_emprestimo_conta.sql – índice diário de suspeita combinando falhas biométricas, cobertura de biometria e produtividade acima de P95.
  • queries/questoes/e2_correlacao_dia_not_match.sql – correlação entre dia da semana e taxa de NOT_MATCH.

---

Abordagem analítica (resumo)

A análise foi estruturada em quatro pilares:

1. Confiabilidade dos serviços de biometria
   • Medição da taxa de falha (PROVIDER_FAILED) por serviço e ao longo do tempo.
   • Avaliação da resiliência do sistema frente a indisponibilidade dos fallbacks (B, C).
2. Perfis de risco entre entregadores
   • Cruzamento de falhas biométricas (NOT_MATCH) com categoria, cancelamentos, devices e tempo de plataforma.
   • Identificação de categorias mais críticas (p. ex. Bronze, Prata e Iniciantes).
3. Simulação de cenários de segurança
   • Teste de um limiar mais rigoroso (similaridade 0.90) e impacto no índice de MATCH e operação.
4. Indícios de fraude e empréstimo de conta
   • Criação de um Índice de Suspeita de Empréstimo de Conta combinando biometria, cobertura de auditoria e produtividade fora do padrão.
   • Análise de correlações com dia da semana e identificação de dias mais prováveis de comportamento indevido.

---

Principais insights & recomendações

• Alta disponibilidade geral, mas fragilidade nos fallbacks:
  O sistema é bastante resiliente, porém a taxa de falha é concentrada nos serviços B e C, exigindo ações de engenharia para estabilizá-los.

• Categorias Bronze, Prata e Iniciantes são mais críticas:
  Maior proporção de falhas biométricas e cancelamentos, sugerindo combinação de fatores operacionais e possíveis usos indevidos de conta.

• Elevar o threshold para 0.90 aumenta a segurança, mas reduz eficiência em ~1/3:
  Recomenda-se abordagem segmentada por risco, em vez de um único limiar fixo.

• Cancelamentos e falhas biométricas têm correlação baixa:
  Cancelamentos parecem estar mais relacionados a problemas operacionais do que diretamente à fraude, reforçando a necessidade de análises complementares.

• Suspeita de empréstimo de conta mais forte em dias úteis:
  O índice de suspeita aponta para picos em dias como 17/08, principalmente em segundas e terças, sugerindo foco de monitoramento nesses períodos.

---

Contato

Caso queira discutir este case ou a análise:

• GitHub: @silvaniacorreia
• LinkedIn: Silvania Correia
• E-mail: silvania.goularte@gmail.com