Quando é hora de migrar sua plataforma de mediação?
A troca de plataformas de mediação de anúncios é uma das decisões mais consequentes que um publisher mobile pode tomar. A camada de mediação controla quais anúncios seus usuários veem, quanto você ganha por impressão e quão suavemente a experiência publicitária funciona. A migração carrega riscos reais, mas permanecer em uma plataforma subótima tem um custo composto que cresce a cada dia.
Sinais claros de que é hora de avaliar uma mudança:
- eCPM em declínio sem explicação de mercado: Se o seu eCPM está caindo enquanto os benchmarks do setor permanecem estáveis, sua plataforma atual pode ter lacunas de demanda ou problemas de otimização que novos entrantes já resolveram.
- Melhor suporte de lances em outro lugar: Se sua plataforma atual suporta 3 parceiros de licitação, mas um concorrente suporta 8, você está deixando densidade de leilão (e receita) na mesa.
- Descontinuação ou depreciação do SDK: Quando sua plataforma de mediação anuncia o fim da vida útil do SDK ou para de desenvolver ativamente recursos, a migração não é opcional. É uma questão de quando, não se.
- Formatos de anúncio ausentes: Se sua plataforma não suporta app open ads, rewarded interstitials ou native bidding enquanto os concorrentes suportam, cada formato ausente representa receita perdida.
- Limitações de relatórios: Se você não consegue obter dados detalhados de eCPM por rede, geo, unidade de anúncio e formato, você está voando às cegas. Plataformas modernas fornecem isso como padrão.
Planejamento de migração: Abordagem de testes paralelos
A regra cardinal da migração de mediação é nunca fazer uma transição abrupta. Uma abordagem de testes paralelos protege o piso de receita enquanto valida o desempenho da nova plataforma com tráfego real.
A estratégia paralela funciona da seguinte forma:
- Fase 1 (Configuração): Integre o novo SDK de mediação junto ao existente. Configure unidades de anúncio, fontes de demanda e preços mínimos idênticos em ambas as plataformas.
- Fase 2 (Divisão de tráfego): Direcione 10–20% do tráfego para a nova plataforma, mantendo 80–90% na existente. Use uma flag de remote config ou framework de teste A/B para controlar a divisão.
- Fase 3 (Monitoramento): Execute ambas as plataformas simultaneamente por pelo menos 2 semanas, comparando eCPM, taxa de preenchimento, latência e taxa de falhas na divisão.
- Fase 4 (Escalonamento): Se a nova plataforma atender ou superar a antiga, aumente gradualmente sua participação de tráfego: 20% para 50% para 80% para 100%.
- Fase 5 (Limpeza): Remova o SDK antigo e configurações associadas quando 100% do tráfego estiver na nova plataforma por pelo menos uma semana com desempenho estável.
Dados necessários antes da mudança
Antes de iniciar qualquer migração, exporte e documente dados abrangentes de linha de base de sua plataforma atual. Esses dados servem a dois propósitos: fornecem benchmarks de comparação para avaliar a nova plataforma e informam a configuração inicial do seu novo waterfall ou configuração de lances.
Pontos de dados essenciais
- eCPM histórico por rede e geografia: No mínimo, os últimos 90 dias de eCPM diário para cada fonte de demanda, divididos por país ou grupo de países. Isso indica quais redes estão performando bem em quais mercados e informa a nova ordem do waterfall.
- Taxa de preenchimento por rede e formato de anúncio: Uma rede com alto eCPM, mas 5% de taxa de preenchimento, contribui de forma diferente de uma com eCPM moderado e 90% de taxa de preenchimento. Ambas as métricas são necessárias para uma configuração precisa.
- Volume de impressões por unidade de anúncio: Entenda quais posicionamentos de anúncio geram mais impressões. Estas são suas unidades de maior impacto e devem ser migradas por último para minimizar o risco.
- Dados de latência: Se disponíveis, documente o tempo médio de carregamento de anúncios e taxas de timeout por rede. Isso ajuda a definir valores de timeout adequados na nova plataforma.
- Receita por dia da semana e hora do dia: Os mercados de anúncios têm ciclos semanais e diários. Ter esse padrão documentado garante que você não confunda variação cíclica normal com mudanças relacionadas à migração.
Dados desejáveis
- ARPDAU no nível do usuário por coorte
- Dados de frequência de anúncios no nível da sessão
- Taxas de falhas e ANR correlacionadas com atividade de SDK de anúncios
- Logs detalhados no nível de lance, se sua plataforma atual os fornecer
Processo de migração passo a passo
Passo 1: Instale o novo SDK de mediação
Adicione o novo SDK de mediação e todos os SDKs de adaptadores necessários ao seu projeto. Não remova ainda o SDK antigo. Ambos coexistirão durante a fase de testes paralelos. Ações principais:
- Adicione a dependência do SDK principal de mediação
- Adicione SDKs de adaptadores para cada fonte de demanda que você planeja usar
- Inicialize o novo SDK na sua classe Application ou AppDelegate, bloqueado atrás de uma flag de remote config
- Verifique se a build compila sem conflitos entre SDKs antigos e novos
Passo 2: Configure unidades de anúncio e fontes de demanda
No dashboard da nova plataforma, recrie a configuração de unidades de anúncio:
- Crie unidades de anúncio correspondendo aos seus posicionamentos existentes (mesmo formato, mesmo intervalo de atualização para banners)
- Adicione todas as fontes de demanda com seus respectivos IDs de aplicativo e IDs de posicionamento
- Defina preços mínimos iniciais com base nos dados históricos de eCPM da plataforma antiga
- Habilite lances para todas as fontes que o suportam; configure entradas de waterfall para o restante
Passo 3: Implemente a divisão de tráfego
Use um sistema de configuração remota (Firebase Remote Config, seu próprio sistema de flags de feature ou um simples toggle server-side) para controlar qual SDK de mediação lida com cada sessão:
- Na inicialização do app, verifique o flag remoto para determinar qual SDK está ativo para esta sessão
- Solicite anúncios apenas através do SDK ativo para toda a sessão. Não misture SDKs dentro de uma sessão.
- Registre qual SDK está ativo em sua análise para que você possa segmentar dados de desempenho de forma limpa
Passo 4: Execute em paralelo por pelo menos duas semanas
Duas semanas é o período mínimo de avaliação. Esta duração captura padrões de dias úteis e finais de semana, leva em conta flutuações de demanda e dá aos algoritmos de lances tempo para aprender seu inventário. Durante este período:
- Monitore eCPM, taxa de preenchimento e receita total diariamente para ambos os grupos
- Acompanhe métricas de estabilidade do app (taxa de falhas, taxa de ANR) em ambos os grupos
- Fique atento a problemas de experiência do usuário (carregamentos lentos de anúncios, frames de anúncio em branco, anúncios de tela cheia inesperados)
- Não faça alterações de configuração em nenhuma plataforma durante este período, a menos que algo esteja claramente quebrado
Passo 5: Compare e decida
Após o período paralelo, compare as duas plataformas nessas dimensões:
- Receita por DAU: A métrica principal. Se a nova plataforma gera receita igual ou maior por usuário ativo diário, ela passa no teste central.
- Taxa de preenchimento: Taxa de preenchimento mais alta significa mais impressões monetizadas. Uma nova plataforma com 5% maior taxa de preenchimento e eCPM similar é um claro vencedor.
- Latência: Carregamento mais rápido de anúncios significa melhor viewability e experiência do usuário.
- Estabilidade: Se o novo SDK aumentar a taxa de falhas, o ganho de receita pode não valer a pena.
Passo 6: Transição e limpeza
Após se comprometer com a nova plataforma, aumente o tráfego para 100%, monitore por mais 5–7 dias e então remova completamente o SDK antigo. Atualize sua lista de dependências, remova o código de inicialização antigo e limpe qualquer lógica condicional relacionada à divisão de tráfego.
Erros comuns na migração de mediação
Mesmo migrações bem planejadas encontram problemas. Estar ciente dos erros comuns ajuda a evitá-los ou se recuperar deles rapidamente:
- Perda de dados históricos de otimização: Os algoritmos de lances na plataforma antiga têm meses de dados sobre seu inventário. A nova plataforma começa do zero. Espere 1–2 semanas de desempenho subótimo enquanto os algoritmos aprendem.
- Conflitos de SDK: Executar dois SDKs de mediação simultaneamente pode causar conflitos de dependência, especialmente se ambos incluírem os mesmos SDKs de fontes de demanda em versões diferentes. Teste minuciosamente em uma build de staging antes de implantar em produção.
- Preços mínimos incompatíveis: Definir floors muito altos na nova plataforma mata a taxa de preenchimento. Defini-los muito baixos deixa dinheiro na mesa. Use seus dados históricos como ponto de partida e ajuste após a primeira semana.
- Comparação de períodos desiguais: Os mercados de anúncios flutuam. Comparar a semana 1 da nova plataforma com a semana 1 da plataforma antiga de três meses atrás não é uma comparação válida. Os testes paralelos eliminam esse problema.
- Pressa no cronograma: A pressão para mostrar resultados rápidos leva a conclusões prematuras. Duas semanas de dados paralelos é o mínimo. Quatro semanas é melhor para publishers com tráfego significativo.
Migrando do AdMob Mediation para o Google Ad Manager
Um dos caminhos de migração mais comuns é a mudança da mediação AdMob para a plataforma completa do Google Ad Manager. Esta atualização é impulsionada pelos recursos superiores do GAM para publishers em escala:
- Suporte a acordos diretos: GAM permite que campanhas vendidas diretamente concorram junto à demanda programática, o que a mediação AdMob não suporta
- Relatórios avançados: GAM fornece relatórios detalhados por item de linha, anunciante, criativo e dimensões personalizadas
- Open Bidding: O lance server-side do GAM suporta uma gama mais ampla de parceiros de exchange do que a mediação client-side da AdMob
- Regras de preços unificadas: Defina preços mínimos com granularidade de geo, dispositivo e formato em todas as fontes de demanda a partir de uma única interface
Esta migração específica é algo que a RevenueFlex lida com frequência. A transição da mediação AdMob para uma configuração GAM totalmente gerenciada envolve recriar toda a configuração de anúncios no GAM, mapear fontes de demanda, estabelecer novos preços mínimos com base no desempenho histórico e executar uma avaliação paralela para confirmar neutralidade de receita ou melhoria. Publishers que fazem essa transição com planejamento adequado normalmente veem um aumento de receita de 10–25% após a otimização completa do waterfall do GAM.
A migração de mediação não é um projeto de fim de semana. É um processo de várias semanas que requer planejamento cuidadoso, testes paralelos disciplinados e paciência enquanto novos algoritmos aprendem seu inventário. Mas para publishers em uma plataforma com desempenho inferior, o impacto de longo prazo na receita torna o esforço de curto prazo válido.