Campanhas de ROAS no Unity Ads agora exigem eventos de receita: o que os times de iGaming precisam corrigir

No início de outubro, a Unity mudou as regras para lançar campanhas de ROAS. Uma nova campanha não começa até que a fonte receba eventos de compra com o valor da receita anexado. Para o dono de um app, isso é uma caixinha no MMP. Para um media buyer que roda tráfego para um app alugado, é uma conversa com quem controla os dados, mais alguns dias de espera.

O que mudou e por quê

Antes, uma campanha de ROAS podia entrar no ar mesmo com os dados de valor incompletos ou totalmente ausentes. Agora a Unity primeiro verifica se os eventos de compra com receita estão chegando e só então deixa a campanha entrar no leilão. O raciocínio da plataforma é simples: um algoritmo que vê dinheiro real fica melhor em encontrar pessoas que pagam.

Por que isso importa mais em apostas do que parece

Em iGaming, uma “compra” é um depósito, e os depósitos variam muito. Um jogador recarrega $10, outro $150, e, para um modelo de ROAS, esses são dois públicos diferentes. Sem o valor, o algoritmo só vê que um pagamento aconteceu e não consegue privilegiar as pessoas que pagam mais.

Daí saem duas conclusões:

• O cadastro não funciona mais como sinal de ROAS. Ele serve para testes iniciais, mas uma campanha que otimiza para retorno simplesmente não sobe sem um depósito que traga o valor.
• Em iGaming, a fonte de receita é sempre IAP. Um app de cassino ganha com depósitos, e não com anúncios exibidos dentro dele. Os modos Ad Revenue e Hybrid foram feitos para jogos, não para apostas, por mais que a plataforma os promova.

Se o app é alugado, o sinal não é seu

A maioria dos times de afiliados em in-app não tem apps próprios. O desenvolvimento é caro, e uma loja pode banir um app a qualquer dia. Por isso, os times alugam apps e recebem, como parte do acordo, um SDK de MMP pronto com os postbacks já configurados. Explicamos como esse setup se encaixa num lançamento na Unity no nosso guia do Unity Ads para iGaming.

O lado ruim do aluguel é que o media buyer não tem acesso ao painel do AppsFlyer ou do Adjust. A configuração dos eventos, os valores, a moeda e quais parceiros recebem os dados ficam todos com o fornecedor. O fornecedor configura tudo isso, mas só mediante pedido. A responsabilidade de verificar continua sendo do media buyer: “o fornecedor disse que está tudo funcionando” não prova nada. Só os eventos aparecendo num relatório provam.

A verificação do sinal de receita: cinco perguntas para o seu fornecedor de app

Faça estas perguntas antes de a campanha entrar na fila de lançamento. Cada resposta deve ser específica, e não “está tudo configurado”.

1. Qual evento vai para a Unity como compra? O primeiro depósito ou todo depósito? Isso decide para o que o algoritmo realmente otimiza e como você deve ler o ROAS.
2. O valor é enviado, e em qual moeda? Se o fornecedor não consegue enviar o valor exato do depósito, a Unity aceita um valor estático. Nesse caso, você precisa saber o número, ou o ROAS na sua conta não significa nada.
3. Os eventos in-app estão ativados especificamente para o parceiro Unity? Acontece de as instalações serem compartilhadas, mas os eventos não, e a campanha trava na verificação sem motivo aparente.
4. Como os depósitos de teste são mantidos de fora? Um pagamento de teste com valor que escapa para o fluxo ensina o algoritmo a procurar um jogador que não existe.
5. Dá para ver uma prova? Peça uma exportação de eventos do primeiro dia ou um print das configurações do parceiro. Adicione os seus próprios cadastros de teste e um depósito de teste pelo seu tracker.

Três relógios para incluir no seu plano de lançamento

Os lançamentos falham mais por causa do timing do que por configurações erradas. Entre “estamos lançando” e “podemos tirar conclusões”, três relógios correm em paralelo:

• O relógio do fornecedor. Toda mudança do lado do app (um evento, um valor, uma exportação) leva de um a dois dias de vai e volta. Tudo o que depende do fornecedor deve ser feito antes do prazo, e não no dia do lançamento.
• O relógio da Unity. A plataforma verifica a integração mais ou menos uma vez por dia. Ative o compartilhamento de eventos hoje e a campanha começa amanhã, no mínimo. Mais um detalhe fácil de deixar passar: a campanha precisa de pelo menos um pacote de criativos aprovado e ativo. Remover um pacote reprovado não basta se todos os outros estiverem pausados.
• O relógio dos postbacks. Os depósitos chegam à fonte com um atraso de até três dias. Julgar uma campanha no segundo dia é prematuro, porque os números ainda não maturaram. Para decisões rápidas, olhe a exportação do fornecedor ou o seu próprio tracker, e não o painel da Unity.

Somando os três relógios, um veredito honesto sobre uma campanha só é possível de três a quatro dias depois do lançamento, no mínimo. Um time que planeja isso com antecedência não mata um setup que funciona porque o primeiro dia pareceu vazio.

Conclusão

A nova regra da Unity leva o controle para onde quer que os dados de receita estejam. Alugar um app te compra um início rápido, e o preço é parte do seu controle sobre o sinal. Você recupera esse controle com as perguntas certas ao fornecedor e um cronograma realista. Times que verificam o sinal antes do lançamento têm um algoritmo caçando pagantes desde o primeiro dia. Times que não verificam perdem uma semana numa campanha que nunca começou, ou em conclusões tiradas de números que não estavam prontos.

Lançamos campanhas na Unity em apps alugados todos os dias e ensinamos o fluxo in-app completo, das primeiras perguntas ao fornecedor à leitura da primeira semana de dados. Se você está indo para o in-app, fale com a gente e vamos olhar o seu setup.

Você também pode gostar

• Lançamento no Unity Ads: $87 por depositante em $48K
• Por que o in-app não bane as apostas que o Facebook bane
• Playable ads: por que criativos interativos vencem e pertencem ao InApp