Como montar uma rede de sub-afiliados de bet

Quase toda rede de sub-afiliados de bet no Brasil começa do mesmo jeito: alguém com contrato bom na casa abre o link para conhecidos, controla no WhatsApp, fecha o mês numa planilha e paga no Pix. Funciona com três parceiros. Com trinta, vira um segundo emprego — e um emprego em que qualquer erro de digitação custa credibilidade.

O que muda a escala não é contratar alguém para conferir planilha. É trocar o processo manual por três mecanismos: link identificado, atribuição automática e repasse por regra.

O problema real: você é o intermediário de dados

Numa rede, o sub-afiliado traz tráfego, mas quem tem contrato com a casa é você. A casa manda o postback de FTD para a sua URL. O sub não recebe nada de ninguém — depende de você contar o que aconteceu.

Isso cria três atritos previsíveis:

• Atraso. O sub descobre o resultado dias depois, e só consegue otimizar criativo no escuro.
• Desconfiança. Ele não tem como verificar o número que você mandou.
• Exposição. Se para provar o resultado você mostra o painel da casa, entrega seu contrato de bandeja.

O desenho que resolve os três é o mesmo: a conversão que entra precisa sair na hora, com o valor dele, para a ferramenta dele. É o que o repasse automático para sub-afiliados faz.

Passo 1: dar um identificador para cada parceiro

Antes de qualquer automação, cada pessoa da rede precisa existir como um valor rastreável dentro do clique. O formato é:

https://go.seudominio.com.br/r/betano-cpa/joao01
https://go.seudominio.com.br/r/betano-cpa/mariana
https://go.seudominio.com.br/r/betano-cpa/grupo-tel-03

O primeiro segmento (betano-cpa) é a oferta. O segundo é o identificador do sub, gravado como sub1 no clique. Todos apontam para a mesma oferta e o mesmo contrato — o que muda é a etiqueta.

Recomendações práticas:

• Use identificadores curtos e sem acento, porque eles vão parar em URL, em relatório e em postback.
• Não reaproveite identificador de parceiro que saiu. Histórico de conversão fica colado nele.
• Se o mesmo parceiro roda canais diferentes (Telegram, Instagram, tráfego pago), dê identificadores separados. Você vai querer ver qual canal converte.

Cada clique nesse link recebe um click_id único, e o sub1 viaja junto. O mecanismo completo está em tracking e atribuição.

Passo 2: garantir que a conversão chega de verdade

Não existe rede de sub-afiliados sem postback funcionando. Se o FTD não casa com o clique na sua conta, não há o que repassar.

Isso significa ter o merchant configurado corretamente: qual parâmetro leva o click_id na ida, qual campo devolve na volta, qual campo é o evento, qual é o valor e qual é o id da transação. Betano e Superbet, por exemplo, usam parâmetros diferentes apesar de rodarem na mesma plataforma — o passo a passo está em como configurar o postback da Betano e da Superbet, e a referência técnica em postback S2S.

Antes de abrir a rede, valide com um clique de teste e uma chamada manual de postback. Uma rede montada em cima de tracking quebrado destrói reputação rápido.

Passo 3: definir a regra de repasse

Aqui é onde a operação vira produto. A regra é definida por merchant e por evento, em uma de duas formas:

Duas decisões a tomar antes de combinar qualquer número:

Quais eventos pagam. Se o seu contrato tem cadastro e depósito, você decide se o sub recebe pelos dois ou só pelo FTD. Pagar cadastro atrai volume, e volume sem qualidade é como se perde contrato com casa. A distinção entre os eventos está detalhada em CPA, FTD, RevShare e baseline.

Qual a sua margem. A diferença entre o que a casa te paga e o que você repassa é o que sustenta a operação: infraestrutura, negociação, suporte, risco de chargeback e de revisão de conversão. Definir isso como número, e não como sobra, é o que separa rede de favor.

Passo 4: ligar o relay

Com a regra pronta, o repasse deixa de ser tarefa. No instante em que a conversão é registrada, o sistema dispara um postback de saída para a URL que o sub-afiliado cadastrou, preenchendo as macros:

https://tracker-do-sub.example/postback?cid={click_id}&payout={valor}&event={evento}&tx={txid}&s={sub}

Cada macro entrega uma coisa:

• {click_id} — o identificador do clique original, que o sub usa para casar com o tracker dele
• {valor} — o valor que você definiu para ele, não o que a casa pagou
• {evento} — FTD, cadastro, ou o que o mapeamento do merchant definiu
• {txid} — id da transação, para o sub deduplicar do lado dele
• {sub} — o identificador que veio no link, útil quando ele repassa adiante

O ponto central: o valor que sai é o seu valor de repasse. O sub recebe um dado correto e verificável sobre o resultado dele, sem nenhuma informação sobre o seu acordo com a casa.

Passo 5: sub do sub

Quando um parceiro tem a própria estrutura — um gestor de grupos com vários criadores, por exemplo — o sub1 gravado no link é repassado no relay. Ele recebe a conversão já etiquetada e consegue distribuir internamente sem pedir nada para você.

Na prática, isso permite uma rede de três camadas sem que você precise administrar a terceira. Você gerencia seus parceiros diretos; cada um gerencia os dele.

O que a deduplicação protege

Casas de aposta reenviam postback. Acontece por retry de rede, por reprocessamento em lote, por correção de valor. Sem deduplicação, cada reenvio vira uma conversão nova — e, numa rede, vira pagamento a mais, disparado automaticamente, para uma pessoa que já recebeu.

Com dedupe por txid e click_id:

• O evento repetido não vira segunda conversão.
• O relay não dispara de novo.
• Se o reenvio trouxer valor diferente, a conversão original é preservada e a divergência fica no log de postbacks.

Preservar o original em vez de sobrescrever é uma escolha deliberada: o que já foi repassado ao sub continua batendo com o que está no seu relatório. Se o valor novo estiver certo, você trata o ajuste como exceção consciente, e não como um número que mudou sozinho.

Rodando a rede no dia a dia

Com o mecanismo no lugar, a gestão vira leitura de relatório. Os cortes por dia, campanha, fonte e sub respondem o que importa:

• Volume por sub. Quem está trazendo clique e quem parou.
• Taxa de conversão por sub. Muito clique e nenhum FTD é sinal de tráfego incentivado, bot ou público errado.
• Qualidade ao longo do tempo. Um sub que converte bem na primeira semana e despenca na terceira costuma ter esgotado a audiência orgânica e migrado para tráfego de baixa qualidade.
• Divergência com o painel da casa. Diferença pequena é normal por janela de atribuição; diferença grande e crescente é problema de configuração.

O CRM de leads ajuda no contato quando o programa trabalha com cadastro antes do depósito, e o log de postbacks continua sendo a primeira parada em qualquer discussão sobre número.

Erros que matam rede de sub-afiliado

• Prometer valor antes de validar o tracking. Se o postback não casa, você paga do bolso ou quebra a palavra. Nenhuma das duas escala.
• Usar o mesmo identificador para vários parceiros. Atribuição vira chute e a discussão não tem como ser resolvida com dado.
• Pagar por cadastro sem teto. Convite explícito para volume de baixa qualidade, e é isso que faz a casa revisar conversão.
• Repassar o valor bruto da casa. Não é generosidade, é operar sem margem — e é irreversível, porque reduzir depois é sempre lido como quebra de acordo.
• Fechar o mês na planilha. Toda conciliação manual entre painel da casa, seu relatório e o Pix é uma chance de erro que custa confiança.
• Não documentar a regra. Escreva qual evento paga, qual valor, qual prazo e o que acontece quando a casa cancela uma conversão. Combinar depois do problema nunca dá certo.

Como apresentar a proposta para o parceiro

Parceiro bom escolhe com quem trabalhar. A proposta que ganha não é a que promete o maior número, é a que entrega controle. Três coisas resolvem quase toda conversa:

• Transparência de mecanismo. Explique que a conversão dele chega automaticamente no tracker dele, no momento em que acontece, e que ele não depende de você mandar print.
• Regra escrita. Qual evento paga, qual valor, qual a janela de atribuição, o que acontece se a casa cancelar a conversão depois.
• Prazo de pagamento. Fechamento e data fixa. Previsibilidade vale mais que um valor unitário maior pago quando dá.

O que você não precisa entregar é o seu contrato com a casa. O repasse por postback existe justamente para separar as duas camadas: o parceiro recebe o dado que é dele, completo e em tempo real, sem que isso exponha a sua negociação.

Por onde começar

Se você já opera tráfego e quer abrir para parceiros, a ordem é: configurar o merchant e validar o postback, criar identificadores para os três primeiros parceiros, definir a regra de repasse por escrito, ligar o relay e só então escalar. Comece pelo panorama da plataforma e pela página para afiliados; para saber quais casas já estão mapeadas, veja integrações e casas de aposta. Dúvidas de valores estão em preços, termos em glossário e configuração em FAQ.

Uma observação necessária: o mercado brasileiro de apostas tem regras próprias de operação e divulgação, inclusive sobre quem pode promover o quê. Nada aqui é orientação jurídica — verifique a fonte oficial e o contrato do programa antes de montar qualquer estrutura de repasse.