Rastrear redepósito no iGaming: por que ele não é FTD

Se sua operação já fechou o ciclo até o FTD via postback, existe um erro seguinte que é fácil não perceber: tratar redepósito — o depósito de alguém que já converteu antes — como se fosse o mesmo evento. A diferença parece pequena, mas distorce CPA, ROAS e a leitura de quais campanhas realmente valem escalar. Este guia mostra por que isso acontece e como rastrear cada tipo de depósito separado.

O que é redepósito (e por que ele não é FTD)

FTD é o primeiro depósito de um cliente novo — o evento que marca a virada de lead pra cliente. Redepósito é qualquer depósito depois desse primeiro: a mesma pessoa voltando a colocar dinheiro na conta, dias, semanas ou meses depois. São dois eventos com significados completamente diferentes: um marca aquisição, o outro marca retenção de alguém que já foi adquirido.

A maioria das casas de apostas e plataformas de afiliados notifica os dois por postback, como já detalhado no guia de postback e S2S pra iGaming, normalmente com uma configuração de postback por evento (registro, FTD, depósito) no painel de afiliados. O problema não é a casa não avisar a diferença — é o rastreamento do outro lado receber tudo pela mesma URL, ou com o mesmo nome de evento, e tratar toda chamada de postback como se fosse a mesma coisa.

O erro de mandar redepósito pro Meta como aquisição

Quando redepósito é enviado ao Meta Ads como o mesmo evento de conversão que o FTD, duas distorções acontecem ao mesmo tempo. A primeira é no número: o total de “primeiras conversões” reportado fica artificialmente inflado, porque uma parte dele é gente que já era cliente, não lead novo. A segunda é na otimização: o algoritmo passa a aprender com um público que mistura quem está entrando agora com quem já converteu antes — e público que já é cliente tende a ter um perfil de comportamento bem diferente de quem ainda não converteu nenhuma vez.

Na prática, o sintoma mais comum não costuma ser um ROAS visivelmente exagerado — é a campanha convergir devagar demais, ou escalar pro público errado, sem uma causa óbvia no relatório. O motivo é sutil: o Meta está sendo alimentado com sinal de recorrência misturado a sinal de aquisição, e não tem como separar os dois sozinho. Já cobrimos esse erro de forma resumida no guia de erros comuns ao rastrear conversões em iGaming — aqui o foco é como corrigir a causa, não só reconhecer o sintoma.

Como diferenciar FTD de redepósito no rastreamento

Corrigir isso não exige renegociar nada com a casa de apostas — ela já separa os eventos. O ajuste é em como cada um é recebido e enviado ao Meta. Na Track4you, a separação vem da própria estrutura das Integrações:

1. Uma integração por tipo de evento: uma de FTD e, se você quiser o valor dos depósitos no pixel, outra do tipo Depósito — cada uma com a sua URL de postback, com o event= já preenchido.
2. Cada URL no evento certo da casa: a URL da integração de FTD vai no postback de primeiro depósito; a de Depósito, no postback de depósitos. Colar a mesma URL nos dois é o que mistura os eventos.
3. Nomes diferentes no pixel: o FTD chega como o evento personalizado FTD e o Depósito chega como Purchase, com o valor (tabela de tipos de evento na central de ajuda). A campanha de aquisição otimiza pelo FTD, confirmado no Gerenciador de Eventos, e o redepósito não entra na contagem de “primeiras conversões”. Se você não quer depósito nenhum no pixel, basta não criar a integração de Depósito — a recorrência continua no relatório da casa.
4. Validar com um caso de teste: faça um depósito de teste a partir do link de divulgação e confira no “Histórico de Eventos” das Integrações (colunas “Tipo do Evento” e “Evento no Pixel”) se ele chegou como FTD; depois faça um segundo e confira que ele chegou como Purchase, nunca como um segundo FTD. O histórico mostra o evento mais recente de cada lead, então confira depois de cada depósito.

Onde o redepósito realmente importa: revshare, LTV e recorrência

Redepósito não deveria alimentar otimização de aquisição — mas está longe de ser um dado descartável. É exatamente o número que decide se um modelo de pagamento por revshare vale mais que CPA pra uma campanha específica: quem recebe CPA já foi pago no FTD e redepósito não muda o repasse recebido; quem recebe revshare depende diretamente da recorrência do jogador pra sustentar o repasse ao longo do tempo, porque revshare é calculado sobre GGR ou NGR — receita que só existe se o jogador continuar depositando e apostando depois do primeiro depósito.

Isso muda o que vale olhar dependendo do modelo de remuneração da campanha. Em CPA, o KPI que decide se vale escalar é FTD sobre CPL — redepósito é informação de fundo, útil pra entender qualidade do público, mas não move o repasse. Em revshare, redepósito (e a frequência dele) é o KPI que efetivamente decide se aquela campanha continua valendo a pena meses depois da aquisição — um criativo com CPL mais alto, mas que traz jogador que redeposita com frequência, pode superar um criativo mais barato que traz jogador que deposita uma vez e some.

Erros comuns

• Colar a URL de postback do FTD também no evento de depósito da casa: todo redepósito chega como FTD e é contado como aquisição nova.
• Descartar o dado de redepósito completamente: mesmo não indo pro Meta como evento de otimização, ele ainda deve ser registrado — é o dado que sustenta decisão de campanha em operação de revshare.
• Comparar campanhas só por FTD quando o pagamento é revshare: ignora o número que realmente decide o repasse ao longo do tempo.
• Não validar a diferenciação com um teste real: configurar a lógica e assumir que funciona é a forma mais comum de só descobrir a mistura semanas depois, quando os números de aquisição não fecham com o que a casa de apostas reporta.

Como a Track4you ajuda nesse fluxo

Na Track4you, FTD e depósito são integrações separadas (planos Pro e Enterprise), cada uma com a sua URL de postback: o FTD chega no pixel como o evento personalizado FTD, e os depósitos chegam como Purchase, com o valor — então a campanha de aquisição otimiza pelo FTD sem que redepósito entre nessa conta. No painel, os cards “FTDs” e “Depósitos” ficam separados, e o “Histórico de Eventos” mostra o tipo de cada conversão e o nome com que ela chegou no pixel. Não há prazo do lado da Track4you: o redepósito que chega pelo postback meses depois do FTD vai pro pixel como Purchase do mesmo jeito e vira sinal de valor pro algoritmo; se ele é creditado a alguma campanha no Gerenciador de Anúncios, quem decide é a janela de atribuição da Meta (padrão: 7 dias depois do clique ou 1 dia depois da visualização) — por isso a leitura de recorrência por campanha não sai do gerenciador. A recorrência de longo prazo por jogador, e o revshare que ela gera, continua sendo apurada no relatório da casa.

Perguntas frequentes

Termos como FTD, postback, GGR e NGR têm definição rápida no glossário; o guia de CPA em afiliados/iGaming detalha a diferença entre CPA e revshare com mais profundidade.

Conclusão

FTD e redepósito são dois eventos com significados opostos — um marca aquisição, o outro marca recorrência — mesmo chegando pela mesma via de postback na maioria das integrações. Misturar os dois na hora de mandar dado pro Meta Ads infla o número de conversões reportado e alimenta o algoritmo com sinal misturado, sem que isso apareça como erro óbvio no relatório. Separar os dois desde a configuração do postback é o que garante que o CPA seja calculado sobre aquisição real e que o redepósito continue disponível pra decidir se uma campanha de revshare vale escalar.