Se você já lançou um jogo móvel antes, sabe a tensão: seu editor (ou sua própria linha de custos) quer mais impressões publicitárias, e seus jogadores querem realmente desfrutar do jogo. Se errar o equilíbrio em qualquer direção, perde-se. Poucos anúncios fazem com que suas receitas não cubram os gastos de marketing. Muitos demais, agressivos ou mal-timados, e sua curva de retenção cai no terceiro dia.
Este é um dos problemas que parece simples em uma documentação de design — "adicionar anúncios entre os níveis" — mas se torna um desafio técnico e de design surpreendentemente profundo assim que você começa a implementá-lo. Neste post, quero caminhar através da forma como a monetização realmente é construída em um projeto real do Unity: os formatos de anúncios que importam, a arquitetura técnica que mantém seu código publicitário de se tornar uma bagunça e as armadilhas de retenção que pegam quase todos os desenvolvedores móveis iniciantes.
Os Três Formatos de Anúncios Que Você Realmente Usará
Antes de entrar no código, é útil ser claro sobre o que você está construindo, porque diferentes formatos publicitários têm considerações completamente diferentes de implementação e UX.
Anúncios em faixa ficam na parte superior ou inferior da tela e são majoritariamente passivos. Eles geram baixas receitas por impressão, mas não interrompem o jogo. São mais úteis nas telas de menu ou UI não ação, e honestamente, em 2026, muitos jogos casuais bem-sucedidos pulam completamente em favor de focar em anúncios intersticiais e vídeos recompensados, que desempenham muito melhor por sessão.
Anúncios intersticiais são anúncios em tela cheia que aparecem em pontos naturais — após um nível, na tela de game over, ao retornar ao menu principal. Estes são suas ferramentas de monetização mais frequentes e também a mais provável para prejudicar a retenção se você errar o ritmo.
Vídeos publicitários recompensados são o padrão ouro para equilibrar receita e experiência do jogador, porque o jogador opta por isso. "Assista ao anúncio para uma vida extra", "assista ao anúncio para dobrar suas moedas" — o jogador recebe um valor tangível, e você obtém uma impressão garantida e de alto valor. Jogos que se apoiam fortemente em loops bem projetados de anúncios recompensados consistentemente superam jogos que dependem principalmente de intersticiais impostos.
Configurando uma Arquitetura Limpa de Anúncios
Um erro que vejo constantemente, especialmente em projetos re-skinned ou baseados em modelos, é chamadas SDK de anúncio espalhadas diretamente dentro dos scripts do jogo — um LevelManager chamando AdMob.ShowInterstitial() diretamente, um PlayerController chamando código publicitário quando o jogador morre, e assim por diante. Isso funciona no curto prazo, mas se torna um pesadelo no momento em que você quer adicionar medição de anúncios, ajustar limites de frequência ou trocar redes.
Em vez disso, centralize tudo atrás de uma única classe gerenciadora que o resto do seu jogo fala através de uma interface limpa:
\public class AdManager : MonoBehaviour
\{\n \public static AdManager Instance \{ get; private set;\}
\[SerializeField] \private int interstitialFrequency \= 3; // every N level completions
\private int levelsSinceLastInterstitial \= 0;\n
\private void Awake\(\)
\{\n \if \(Instance \!= null\) \{\n \Destroy\(gameObject\);\n \return;\n \}\n Instance \= this;\n \DontDestroyOnLoad\(gameObject\);\n \InitializeAdSdk\(\);\n \}\n
\public void OnLevelComplete\(\)
\{\n levelsSinceLastInterstitial\++;\n \if \(levelsSinceLastInterstitial \>= interstitialFrequency\)\n \{\n \ShowInterstitial\(\);\n levelsSinceLastInterstitial \= 0;\n \}\n \}\n
\public void RequestRewardedAd\(System.Action onRewardEarned\)
\{\n // load and show rewarded ad, invoke callback only on successful completion\n \}\n
\private void ShowInterstitial\(\) \{\} /* mediation call here */
\private void InitializeAdSdk\(\) \{\} /* SDK init here */
\}Limitação de Frequência Não É Opcional
Isto provavelmente é o maior controle que você tem para proteger a retenção enquanto ainda atinge metas de receita, e é surpreendentemente pouco implementado em muitos projetos independentes.
Limitação de frequência significa colocar limites duros sobre quantas vezes um jogador vê intersticiais, independentemente de quantos "pontos de gatilho" eles atingem. Um jogador que morre cinco vezes em sessenta segundos em um nível difícil não deve ver cinco intersticiais nesse intervalo - isso é uma desinstalação instantânea.
Um padrão simples, mas eficaz, é um cooldown baseado no tempo sobreposto ao seu gatilho baseado em eventos:
private float lastInterstitialTime = -999f;
private float minSecondsBetweenInterstitials = 45f;
public bool CanShowInterstitial()
{
return Time.
Anúncios Reembolsáveis: Projete-os Como uma Funcionalidade, Não como uma Intervenção
A melhor implementação de anúncios reembolsáveis não parece ser um anúncio em absoluto – ela parece ser uma mecânica genuína do jogo. "Dobre seus moedas", "reviva e continue sua corrida", "libere o próximo personagem antes" — esses todos dão ao jogador a capacidade de tomar decisões, e essa capacidade é o que separa um anúncio reembolsável de uma interrupção disfarçada.
Tecnicamente, isso significa que sua estrutura de fluxo de anúncios reembolsáveis precisa ter uma chamada limpa para garantir que você conceda a recompensa apenas em uma conclusão verificada, nunca ao carregar o anúncio ou clicar nele:
public void OferecerMoedasDobradas(int moedasBase)
{
AdManager.Instance.RequestRewardedAd(onRewardEarned: () =>
{
PlayerData.Instance.AddCoins(moedasBase); // concede o bônus, dobrando o total
AnalyticsManager.LogEvent("rewarded_ad_completed", "double_coins");
});
}
Também vale a pena construir desde o primeiro dia: um evento de análise para cada estágio do funil de anúncios reembolsáveis – oferta mostrada, anúncio solicitado, anúncio concluído, recompensa concedida. Sem isso, você estará voando cego em uma das suas ferramentas de monetização mais valiosas e não saberá se a queda está acontecendo na oferta, no carregamento ou na etapa de conclusão.
Mediador: Por Que Você Provavelmente Precisa Dele
Se você está executando apenas uma única rede de anúncios, quase certamente está deixando receita na mesa. Plataformas de medição de anúncios permitem que você execute várias redes em um sistema de cascata ou leilão, então cada solicitação de anúncio vai para a rede atualmente pagando mais por essa impressão.
A contrapartida é uma complexidade adicional – mais SDKs, mais pontos potenciais de falha e mais casos de borda em torno das taxas de preenchimento (o que acontece quando nenhuma rede tem um anúncio para servir?). Sua arquitetura precisa lidar elegantemente com uma situação "sem preenchimento" sem prejudicar a experiência do jogador – geralmente não mostrando a oportunidade de anúncio em vez de mostrar um estado de carregamento quebrado.
Entro muito mais em detalhes técnicos nisso – configuração real da AdMob, configuração de mediador e padrões específicos seguros para retenção para implementação – em uma caminhada totalmente prática separada aqui: Um Guia Prático Para Integrar AdMob no Unity Sem Danificar a Retenção. Se você está prestes a conectar sua primeira rede de anúncios, esse post cobre os passos reais de integração do SDK e configuração de mediador que este artigo intencionalmente ficou acima.
Testando Sua Monetização Sem Chutar
Muitos desenvolvedores lançam sua implementação de anúncios e... esperam. Isso é um erro. No mínimo, você deve estar rastreando:
- eCPM por rede (custo efetivo por mil impressões) para ver qual rede está realmente performando bem
- Taxa de preenchimento para detectar regiões ou unidades de anúncios onde você não está recebendo nenhum anúncio
- Duração da sessão antes e depois da exposição a anúncios, para capturar quedas na retenção associadas a determinados locais de anúncios
- Taxa de conclusão de anúncios remunerados, pois uma taxa baixa de conclusão geralmente sinaliza que sua oferta não é suficientemente atraente, e não que os jogadores em geral odeiam anúncios
A maioria dos painéis de medição fornece eCPM e taxa de preenchimento por padrão. A duração da sessão e correlação com retenção geralmente exigem a integração de seus próprios eventos analíticos junto aos eventos de anúncios, que é exatamente o motivo pelo qual as chamadas AnalyticsManager.LogEvent no código acima são importantes — elas permitem conectar comportamentos de monetização a dados de retenção em vez de chutar.
Colocando Tudo Juntos
A monetização em jogos móveis não é algo que você adiciona no final — é um sistema de design que precisa ser construído com o mesmo cuidado que seu loop principal de jogo. Um gerenciador centralizado de anúncios, limites sensíveis de frequência, respeito pelo estado do fluxo do jogador e anúncios remunerados projetados como recursos genuínos em vez de interrupções disfarçadas irão levá-lo grande parte do caminho para uma configuração de monetização que realmente se sustenta contra dados reais de retenção de jogadores.
Se você está mais cedo no processo e ainda decidindo sobre sua estratégia geral de origem e desenvolvimento — seja construir tudo do zero, montar a partir de componentes individuais da Unity Asset Store ou começar com um código-fonte já testado e pronto para uso — essa decisão fundamental vale a pena acertar antes mesmo que você chegue à camada de monetização. Eu detalhei essa comparação aqui: Unity Asset Store vs. Mercados de Código-fonte Pronto para Uso: Qual é Melhor para Desenvolvedores Independentes?
E se você estiver pronto para realmente integrar o AdMob e a medição da maneira correta, a guia prática de implementação está aqui: Guia Prático para Integrar o AdMob no Unity Sem Destruir a Retenção
Bom monetização não é sobre maximizar impressões de anúncios — é sobre maximizar impressões ao longo da vida por jogador, o que só acontece se eles permanecerem suficientemente tempo para vê-los. Construa para isso, e a receita tende a seguir.