Fraude mobile no dado bruto

1. Dois tipos de fraude, dois rastros

Quase toda fraude de mídia mobile cai em um de dois grupos. Separar os dois muda onde você procura.

O roubo de crédito desvia verba de um canal para outro. O usuário falso queima verba sem trazer nada. O segundo é o mais caro quando o parceiro é pago por CPA, porque a empresa paga por uma compra que nunca aconteceu.

2. O dado que você precisa

As consultas abaixo assumem as tabelas appsflyer.installs, appsflyer.inapp_events, app.sessoes e backend.pedidos no BigQuery. Ajuste nomes de tabela e coluna ao seu export.

3. Sinal 1: instalação que não vira uso

Foi o sinal que abriu o caso dos R$ 100 mil. Em canal saudável, quase toda instalação vira uso real, e quase na hora. No parceiro suspeito, só 38% viravam. Nos outros parceiros, 92%.

O ponto fino: "uso real" tem que vir do seu sistema, não do SDK do MMP. Fraude por SDK spoofing consegue fabricar a instalação e até eventos dentro do app. O que ela não fabrica é uma sessão no seu backend.

-- Sinal 1: % de instalações com uso real em até 24h, por parceiro e site_id
WITH inst AS (
  SELECT appsflyer_id, customer_user_id, media_source, af_siteid, install_time
  FROM `projeto.appsflyer.installs`
  WHERE DATE(install_time) BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 32 DAY)
                               AND DATE_SUB(CURRENT_DATE(), INTERVAL 2 DAY)
),
uso AS (  -- primeira sessão registrada pelo SEU sistema
  SELECT appsflyer_id, MIN(inicio_sessao) AS primeira_sessao
  FROM `projeto.app.sessoes`
  GROUP BY 1
)
SELECT
  i.media_source,
  i.af_siteid,
  COUNT(*) AS instalacoes,
  ROUND(100 * COUNTIF(u.primeira_sessao BETWEEN i.install_time
        AND TIMESTAMP_ADD(i.install_time, INTERVAL 24 HOUR)) / COUNT(*), 1) AS pct_uso_real_24h
FROM inst i
LEFT JOIN uso u USING (appsflyer_id)
GROUP BY ALL
HAVING instalacoes >= 200
ORDER BY pct_uso_real_24h;

Sem dado de sessão própria, use como aproximação o percentual de instalações com qualquer evento in-app em 24 horas. É mais fraco, porque o evento também pode ser fabricado, mas já separa os parceiros fora da curva.

4. Sinal 2: IP e aparelho repetidos

Usuário real é disperso: muitos IPs, muitos modelos, versões de sistema variadas. Fazenda de aparelhos e emulador deixam concentração. No caso dos R$ 100 mil, apareceram instalações saindo dos mesmos blocos de IP e o mesmo device ID em "usuários" diferentes.

-- Sinal 2: concentração de IP, device ID e modelo por parceiro
SELECT
  media_source,
  af_siteid,
  COUNT(*) AS instalacoes,
  ROUND(COUNT(*) / COUNT(DISTINCT ip), 2) AS instalacoes_por_ip,
  ROUND(COUNT(*) / NULLIF(COUNT(DISTINCT REGEXP_EXTRACT(ip, r'^(\d+\.\d+\.\d+)\.')), 0), 2) AS instalacoes_por_bloco_24,
  ROUND(COUNT(*) / NULLIF(COUNT(DISTINCT advertising_id), 0), 2) AS instalacoes_por_device_id,
  ROUND(100 * APPROX_TOP_COUNT(device_model, 1)[OFFSET(0)].count / COUNT(*), 1) AS pct_modelo_mais_comum,
  ROUND(100 * APPROX_TOP_COUNT(os_version, 1)[OFFSET(0)].count / COUNT(*), 1) AS pct_versao_so_mais_comum
FROM `projeto.appsflyer.installs`
WHERE DATE(install_time) >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
GROUP BY ALL
HAVING instalacoes >= 200
ORDER BY instalacoes_por_bloco_24 DESC;

Leia sempre contra a média dos outros parceiros, nunca em número absoluto. Rede de operadora e Wi-Fi corporativo concentram IP de forma legítima. O que denuncia é um parceiro muito acima dos outros, na mesma campanha e no mesmo período.

5. Sinal 3: receita que o backend não confirma

É o sinal que fecha a conta, e o que mais pesa na negociação. No caso dos R$ 100 mil, praticamente nenhuma instalação suspeita virou compra, mesmo com o parceiro sendo pago por CPA em cima da compra.

-- Sinal 3: compra e receita confirmadas no backend em 30 dias, por parceiro
WITH inst AS (
  SELECT appsflyer_id, customer_user_id, media_source, af_siteid, install_time
  FROM `projeto.appsflyer.installs`
  WHERE DATE(install_time) BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 60 DAY)
                               AND DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
)
SELECT
  i.media_source,
  i.af_siteid,
  COUNT(DISTINCT i.appsflyer_id) AS instalacoes,
  ROUND(100 * COUNT(DISTINCT IF(p.pedido_id IS NOT NULL, i.appsflyer_id, NULL))
        / COUNT(DISTINCT i.appsflyer_id), 2) AS pct_com_compra,
  ROUND(SUM(p.valor) / COUNT(DISTINCT i.appsflyer_id), 2) AS receita_por_instalacao
FROM inst i
LEFT JOIN `projeto.backend.pedidos` p
  ON p.customer_user_id = i.customer_user_id
 AND p.status = 'pago'
 AND p.criado_em BETWEEN i.install_time AND TIMESTAMP_ADD(i.install_time, INTERVAL 30 DAY)
GROUP BY ALL
HAVING instalacoes >= 200
ORDER BY pct_com_compra;

Para parceiros pagos por CPA, compare também o que o MMP atribui com o que o backend confirma:

-- Compras que o parceiro cobra x compras que o backend confirma
SELECT
  e.media_source,
  COUNT(*) AS compras_atribuidas_mmp,
  COUNTIF(p.pedido_id IS NOT NULL) AS compras_confirmadas_backend,
  ROUND(100 * COUNTIF(p.pedido_id IS NOT NULL) / COUNT(*), 1) AS pct_confirmado
FROM `projeto.appsflyer.inapp_events` e
LEFT JOIN `projeto.backend.pedidos` p
  ON p.customer_user_id = e.customer_user_id
 AND p.status = 'pago'
 AND p.criado_em BETWEEN TIMESTAMP_SUB(e.event_time, INTERVAL 1 HOUR) AND TIMESTAMP_ADD(e.event_time, INTERVAL 1 HOUR)
WHERE e.event_name = 'af_purchase'
  AND DATE(e.event_time) >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
GROUP BY 1
ORDER BY pct_confirmado;

6. Sinais complementares

Não entraram no caso dos R$ 100 mil, mas pegam o roubo de crédito, que os três sinais principais deixam passar.

Tempo entre clique e instalação

Instalação poucos segundos depois do clique é rápida demais para alguém baixar um app: é o padrão de click injection. Uma cauda longa de horas e dias, com muitos cliques por instalação, é o padrão de click flooding.

SELECT
  media_source,
  af_siteid,
  COUNT(*) AS instalacoes,
  ROUND(100 * COUNTIF(TIMESTAMP_DIFF(install_time, attributed_touch_time, SECOND) < 10) / COUNT(*), 1) AS pct_menos_10s,
  ROUND(100 * COUNTIF(TIMESTAMP_DIFF(install_time, attributed_touch_time, HOUR) >= 24) / COUNT(*), 1) AS pct_mais_24h,
  APPROX_QUANTILES(TIMESTAMP_DIFF(install_time, attributed_touch_time, SECOND), 100)[OFFSET(50)] AS mediana_segundos
FROM `projeto.appsflyer.installs`
WHERE attributed_touch_type = 'click'
  AND DATE(install_time) >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
GROUP BY ALL
HAVING instalacoes >= 200
ORDER BY pct_mais_24h DESC;

Cliques por instalação

No relatório agregado por parceiro, divida cliques por instalações. Milhares de cliques para cada instalação é sinal de flooding, ainda mais se a taxa de conversão do clique for muito menor que a dos outros parceiros.

Horário e geografia

Picos de instalação de madrugada sem pico de uso, e país do IP diferente do idioma do aparelho em volume alto, completam o quadro.

7. A régua: juntando os sinais

Cada sinal vira uma razão contra a mediana dos parceiros. Um parceiro é marcado quando dois ou mais sinais estão fora da curva no mesmo período.

-- Régua: cada sinal como razão contra a mediana, e quantos estão fora da curva
WITH s AS (
  SELECT media_source, af_siteid, pct_uso_real_24h, instalacoes_por_bloco_24, pct_com_compra
  FROM `projeto.auditoria.sinais_parceiro`   -- junte aqui o resultado dos sinais 1, 2 e 3
),
r AS (
  SELECT *,
    pct_uso_real_24h / PERCENTILE_CONT(pct_uso_real_24h, 0.5) OVER () AS r_uso,
    instalacoes_por_bloco_24 / PERCENTILE_CONT(instalacoes_por_bloco_24, 0.5) OVER () AS r_ip,
    pct_com_compra / NULLIF(PERCENTILE_CONT(pct_com_compra, 0.5) OVER (), 0) AS r_receita
  FROM s
)
SELECT *,
  IF(r_uso < 0.6, 1, 0) + IF(r_ip > 2, 1, 0) + IF(r_receita < 0.3, 1, 0) AS sinais_fora
FROM r
ORDER BY sinais_fora DESC, r_receita;

Agende essa consulta para rodar todo mês e mande o resultado para um painel ou alerta. Foi assim que a auditoria do caso virou rotina: uma consulta mensal que avisa quando um parceiro foge do padrão.

8. Do achado ao retroativo

Fraude se resolve em negociação, e negociação se ganha com dossiê. O que levar ao parceiro:

• Período analisado e volume do parceiro no período
• Os três sinais lado a lado, comparados com a mediana dos outros parceiros na mesma campanha
• Amostra de IPs e device IDs repetidos, sem dado pessoal além do necessário
• Compras cobradas contra compras confirmadas pelo backend
• O valor pago pelas ações que não aconteceram

No caso dos R$ 100 mil, o desfecho teve três partes: o parceiro foi bloqueado, os valores futuros foram renegociados e a empresa recebeu retroativo do histórico de cobrança. O retroativo só foi possível porque o pagamento era por uma ação de compra que, comprovadamente, não tinha acontecido.

9. O que a régua não pega

• Fraude com aparelho real por trás. Emulação refinada e fazendas que imitam comportamento humano passam pelos três sinais. É o tipo de caso que ferramenta dedicada cobre melhor.
• iOS sem consentimento do ATT. Boa parte da atribuição chega agregada (SKAdNetwork e AdAttributionKit), sem dado por aparelho. A régua funciona bem no Android e na parte do iOS com atribuição determinística.
• Fraude no orgânico. O relatório de fraude da AppsFlyer de 2026 aponta o tráfego orgânico como o maior canal de instalações fraudulentas. A régua por parceiro não olha para lá.

Quando vale pagar a ferramenta: quando a verba em parceiros de risco multiplicada pela taxa de fraude que você encontrou passa do custo mensal dela. No caso deste guia, a cotação do Protect360 passava de US$ 5 mil por mês e a verba não justificava. Com o volume crescendo, a conta muda.

10. Checklist

• appsflyer_id e customer_user_id gravados no seu backend desde a primeira abertura
• Dado bruto de instalações e eventos chegando no BigQuery todo dia
• Sinal 1 (uso real em 24h) por parceiro e site_id
• Sinal 2 (IP, device ID, modelo) por parceiro e site_id
• Sinal 3 (compra confirmada no backend) por parceiro e site_id
• Tempo entre clique e instalação e cliques por instalação para pegar roubo de crédito
• Régua calibrada com três meses de histórico
• Consulta mensal agendada, com alerta
• Cláusula de conversão válida no contrato com parceiros de CPA
• Dossiê padrão pronto para a primeira negociação