Atribuição de receita revshare no iGaming: como funciona

Se sua operação é paga por revshare, o depósito que mais importa não é o primeiro — é o repasse que continua chegando meses depois, enquanto aquele jogador continuar apostando. O problema é que esse dinheiro não tem nenhuma relação com a janela de atribuição do Meta Ads, nem com o click_id sobrevivendo só até o primeiro cadastro. Este guia explica como manter a atribuição de receita revshare funcionando ao longo do tempo, não só no dia da entrada.

Por que revshare quebra a lógica de atribuição de curto prazo

Em CPA de afiliado, a operadora paga um valor fixo por FTD gerado — o evento acontece, o repasse é calculado, e a conta fecha ali. Em revshare, o pagamento é uma fatia recorrente do GGR ou NGR daquele jogador específico, sem data pra parar: se ele continuar apostando e depositando em fevereiro, março, abril, o repasse continua chegando nesses meses, atrelado ao mesmo cliente que entrou pela sua campanha em janeiro.

O guia de métricas de iGaming já cobre a diferença entre CPA e revshare como modelo de remuneração. O que esse guia não detalha — e que decide se você consegue medir revshare de campanha em campanha — é como ligar cada repasse, mês após mês, de volta ao clique que originou aquele jogador, sem esse fio se perder no caminho.

A janela de atribuição do Meta Ads não serve pra isso

O guia de janela de atribuição do Meta Ads explica por que o FTD pode acontecer dias depois do clique e ainda assim cair fora da janela configurada — por padrão, 7 dias depois do clique ou 1 dia depois da visualização. (O FTD não se perde por isso: a Track4you envia pro pixel toda conversão que chega pelo postback, sem prazo do lado dela, e ela vira sinal pro algoritmo — só não é creditada à campanha no Gerenciador de Anúncios.) Com revshare, esse problema não é só maior: é de outra natureza. Não existe janela de atribuição de anúncio configurável em meses, e mesmo que existisse, não faria sentido usá-la — o Meta Ads não foi construído pra otimizar campanha em cima de receita que chega semanas ou meses depois do clique. Tentar encaixar revshare nesse mecanismo é forçar uma ferramenta feita pra sinal rápido a responder por um sinal que só se revela devagar.

Isso significa que, pra revshare, o gerenciador de anúncios nunca vai mostrar o retorno real de uma campanha — nem deveria ser cobrado disso. A pergunta certa não é “por que o Meta não mostra esse repasse”, é “onde essa atribuição precisa viver, já que não é ali”.

Onde a atribuição de revshare precisa viver: fora da janela, dentro do click_id

A resposta é a mesma lógica que já sustenta o rastreamento de FTD — só que estendida no tempo. O click_id que identifica o clique de origem precisa sobreviver não só até o cadastro na casa de apostas, mas continuar associado àquele cliente indefinidamente, por todo o tempo em que ele permanecer ativo. Registro, FTD e depósitos costumam voltar por postback, um evento por chamada, como já detalhado no guia de postback e S2S pra iGaming. O repasse de revshare é outra coisa: ele costuma ser apurado pela operadora no fechamento de cada período e aparecer no relatório do painel de afiliados, por jogador ou por sub-id. É o identificador gravado no cadastro do jogador (o sub-id) que permite que o repasse de março ainda seja somado à campanha que trouxe aquele lead em janeiro.

Na prática, isso exige três coisas funcionando juntas ao longo do tempo, não só no momento da entrada:

1. O click_id (ou o ID do cliente derivado dele) precisa ser armazenado de forma persistente — não só no momento do cadastro, mas por meses, associado ao registro daquele jogador na casa de apostas.
2. Cada repasse apurado pela operadora precisa ser somado ao histórico daquele cliente, não tratado como um número isolado do mês e esquecido depois.
3. O relatório de campanha precisa acumular esse valor ao longo do tempo, mostrando quanto revshare uma campanha específica já gerou desde a origem — não só o que ela gerou no dia do FTD.

Sem esses três pontos, o revshare até chega — a casa de apostas continua pagando — mas some da leitura de qual campanha ou criativo realmente valeu a pena escalar.

Por que redepósito não é a mesma métrica que revshare acumulado

Vale separar dois números que parecem próximos, mas respondem perguntas diferentes. O guia de redepósito no iGaming já cobre por que redepósito não deve ser enviado ao Meta como se fosse uma nova aquisição — ele é sinal de recorrência de um cliente que já converteu. Revshare acumulado é um passo além disso: não é só saber que o jogador redepositou, é saber quanto de receita (GGR/NGR) aquele redepósito gerou pra operadora, e qual fatia disso volta pra você via revshare, somado mês a mês, campanha por campanha.

Uma campanha pode ter poucos redepósitos, mas de jogadores com ticket alto, e ainda assim gerar mais revshare acumulado do que uma campanha com muito mais redepósitos de ticket baixo. Olhar só a contagem de redepósitos, sem acumular o valor de revshare por trás de cada um, esconde justamente essa diferença.

Erros comuns

• Tentar usar a janela de atribuição do Meta Ads como referência pra revshare: a janela foi feita pra sinal de curto prazo; revshare se estende por meses e nunca vai caber ali.
• Mandar cada repasse de revshare pro Meta via CAPI como conversão: só adiciona ruído a um algoritmo que otimiza melhor com sinal rápido (enter_channel, FTD) — revshare deve ficar no seu próprio relatório, não competindo pela otimização de campanha.
• Deixar o click_id (ou o ID do cliente) se perder depois do primeiro depósito: sem esse fio persistente, cada repasse futuro chega sem como ser somado a nenhuma campanha de origem — e não tem como reconstruir essa associação depois.
• Comparar campanha de CPA com campanha de revshare só pelo FTD: ignora que o retorno de revshare só aparece de verdade semanas ou meses depois, quando o repasse acumulado é somado.

Como a Track4you ajuda nesse fluxo

A Track4you cobre a ponta de aquisição dessa conta. Pelas Integrações (planos Pro e Enterprise), o link de divulgação gera um click_id por clique e entrega o lead no cadastro da casa com esse valor no parâmetro que ela lê como sub-id — é ele que fica gravado no cadastro do jogador. A partir daí, registro, FTD e depósitos (com valor) voltam por postback e chegam no pixel como CompleteRegistration, FTD e Purchase, somados nos cards “Cadastros”, “FTDs” e “Depósitos” do Dashboard — sem prazo do lado da Track4you: um depósito meses depois do cadastro chega no pixel do mesmo jeito e vira sinal pro algoritmo, embora só seja creditado a uma campanha no Gerenciador de Anúncios se cair dentro da janela de atribuição da Meta. O repasse de revshare em si é calculado pela operadora e aparece no relatório do painel de afiliados dela — é ali que a leitura de longo prazo acontece, cruzando o repasse por jogador com a origem de cada aquisição.

Perguntas frequentes

Termos como GGR, NGR, click_id e postback têm definição rápida no glossário; o guia de métricas de iGaming detalha a diferença entre CPA e revshare como modelo de remuneração.

Conclusão

Revshare recompensa quem mede certo — mas só quem consegue manter o click_id vivo por meses, somando cada repasse de volta à campanha de origem, enxerga de verdade qual criativo continua valendo depois do primeiro depósito. A janela de atribuição do Meta Ads não resolve isso, e não deveria: ela foi construída pra outro tipo de sinal. A atribuição de receita revshare precisa viver num relatório persistente — o da operadora, cruzado com a origem de cada aquisição —, fora de qualquer prazo que o gerenciador de anúncios imponha.