Construiu um pacote limitado forte. A arte era boa, o preço estava certo, o desconto era real. Durou 48 horas e converteu uma fração do que modelou. O pós-mortem culpa a oferta, então o próximo sprint foca em redesenhar a loja e redefinir o preço do pacote. Essa é geralmente a solução errada. A maioria dos estúdios que tentam aumentar as compras no jogo estão a ajustar a oferta quando a falha real é a entrega: o jogador certo nunca a viu no momento em que importava, ou viu-a a meio do nível e descartou-a. A oferta estava boa. Simplesmente não chegou a ninguém a tempo.
Os dados suportam a oferta. Ofertas por tempo limitado podem aumentar a receita em 20-30% durante a janela da oferta, pacotes por tempo limitado superam itens individuais em cerca de 8%, e o Pacote Baú Lendário do Clash Royale supostamente converteu cerca de 50% melhor do que ofertas equivalentes individuais. As ofertas funcionam. O problema não resolvido é o alcance e o timing, e isso é um problema de notificação, não um problema de preço.
Este artigo é sobre fechar essa lacuna: tratar a notificação da oferta como a alavanca de monetização, emprestando o manual de gatilhos do eCommerce para compras dentro da aplicação, segmentando por gastos e entregando por canal, atribuindo receita à notificação, e fazendo tudo isso sem se tornar a razão pela qual um jogador o silencia.
- A sua oferta não é o problema; o timing é
- Notificações de compras no jogo: o gatilho é a alavanca de monetização
- Empreste o manual do eCommerce: gatilhos criados para compras dentro da aplicação
- Segmentar por gastos, entregar por canal
- Ligar cada notificação de oferta ao ARPPU, não às aberturas
- A linha que não cruza: limites de frequência e ofertas baseadas em valor
- O que custa, e porque as ofertas de canais próprios se compõem
A sua oferta não é o problema; o timing é
O timing da oferta decide a conversão mais do que o design da oferta. O Candy Crush espera famosamente até por volta do nível 20 para apresentar o seu primeiro pedido de compra, porque um jogador que ainda não atingiu um obstáculo não tem razão para comprar uma forma de o ultrapassar. A mesma oferta que converte num momento de frustração converte quase zero quando interrompe um jogador a meio do fluxo. Um redesenho da loja não pode corrigir um timing incorreto. Uma notificação acionada pode, porque dispara com base no comportamento do jogador em vez do seu calendário de campanha.
Portanto, a questão muda. Não "qual deve ser o pacote", mas "que momento torna este pacote relevante, e como chego ao jogador exatamente nesse momento". Responda a isso e a oferta que já tem começa a converter como os benchmarks dizem que deveria.
Um timing incorreto não é um imposto pequeno, também. Uma oferta disparada a meio do nível é uma interrupção que um jogador ressentem, e o ressentimento é o oposto da intenção de compra. Uma oferta disparada após o fecho da janela envia um toque para uma página da loja que já não tem o acordo, o que treina o jogador a ignorar a sua próxima mensagem. Erros de timing não falham apenas em converter; eles gastam a atenção de que precisará para a oferta que teria funcionado.
Notificações de compras no jogo: o gatilho é a alavanca de monetização
Pare de pensar no push como uma transmissão sobre uma promoção. A versão que move receita é uma oferta acionada por comportamento que dispara no momento em que a relevância atinge o pico. As notificações de compra no jogo ganham sua conversão quando o gatilho está ligado ao que o jogador acabou de fazer, não ao relógio.
Alguns gatilhos que valem a pena construir primeiro:
- Acabou de bater numa parede. Um jogador falha o mesmo nível difícil três vezes, depois vê uma oferta para o impulsionador que o limpa. Este é o momento Candy Crush, automatizado.
- Com pouca moeda ou energia. O jogador fica sem no meio da sessão e recebe uma oferta de recarga de um toque enquanto a intenção de continuar a jogar ainda está quente.
- Viu um pacote, não comprou. O jogador abriu a loja, olhou para um pacote e saiu. Esta é a versão de jogo de um carrinho abandonado, e merece um acompanhamento.
- Ganhou status. O jogador completou uma missão de alto nível e recebe uma oferta para o equipamento que corresponde ao seu novo nível.
Cada um destes é uma regra que define uma vez, não uma campanha que executa manualmente. O gatilho é a alavanca, porque coloca a oferta na frente do único jogador, no único momento, quando converte.
Empreste o manual do eCommerce: gatilhos criados para compras dentro da aplicação
Aqui está o atalho que a maioria dos estúdios perde: as campanhas de gatilho que recuperam receita no eCommerce mapeiam quase um para um para compras in-app. O PushEngage já envia estes como modelos para lojas; apontá-los para uma loja de jogos é a mesma máquina com rótulos diferentes.
| Gatilho de eCommerce | Análogo de jogo IAP | Notificação de exemplo |
|---|---|---|
| Carrinho abandonado | Abriu a loja no jogo, não comprou | “O seu pacote inicial ainda está na loja. Expira esta noite.” |
| Alerta de queda de preço | Um pacote que um jogador viu tem uma queda de preço | “O pacote de gemas que você viu está com 30% de desconto neste fim de semana.” |
| Alerta de reposição de stock | Um pacote limitado fica ativo ou retorna | “O pacote Lendário está de volta por 24 horas.” |
| Abandono de navegação | Navegou por um conjunto cosmético, não comprou | “Complete o visual. O conjunto completo de skins está ativo agora.” |
Pode modelar o incentivo de loja abandonada num fluxo comprovado de recuperação de carrinho abandonado, executar descontos de pacotes como alertas de queda de preço e anunciar pacotes que retornam com alertas de reposição de stock. Nada disso requer a invenção de um novo sistema.
O que torna isto prático é que o sinal comportamental já existe no seu jogo. Não está a construir nova instrumentação; está a disparar uma notificação num evento que já rastreia. Um jogador a abrir a loja e a sair é um evento registado. Uma alteração de preço de um pacote é um evento registado. Um pacote a retornar à loja é um evento registado. O gatilho é simplesmente a regra que transforma cada um desses eventos numa oferta oportuna e relevante em vez de um momento que passa sem monetização.
Ofertas por tempo limitado que realmente chegam ao jogador a tempo
Ofertas por tempo limitado vivem ou morrem pelo alcance dentro do prazo. Um pacote de 48 horas sobre o qual um jogador descobre na 50ª hora não converteu nada, não importava quão bom fosse. A notificação acionada é o que comprime a lacuna entre “oferta está ativa” e “o jogador certo sabe”, e é o que permite enviar um lembrete final nas últimas horas para jogadores que visualizaram, mas não compraram. Construa toda a sequência uma vez no construtor de fluxo de ofertas, defina o prazo e deixe-o funcionar.
Segmentar por gastos, entregar por canal
Disparar uma oferta para toda a sua base é como descontar receitas que você teria obtido de qualquer forma e incomodar os jogadores que nunca a comprariam. O nível de gasto decide a oferta; o canal decide se ela chega.
| Nível de gasto | A oferta certa | Melhor canal |
|---|---|---|
| Não-gastador | Um pequeno incentivo de primeira compra, com baixa fricção, após um momento de valor | Push app |
| Gastador médio | Um pacote que corresponde ao ponto em que se encontram na progressão | Notificação push do aplicativo ou da web (loja complementar) |
| Alto valor | Acesso antecipado, um pacote VIP, um item genuinamente exclusivo | WhatsApp ou notificação push do aplicativo, criado manualmente |
O jogador de alto valor merece um canal pessoal, e é por isso que alcançá-lo no WhatsApp para uma oferta individual supera uma transmissão genérica, enquanto a base ampla funciona com notificações push de aplicativos. O objetivo é adequar o esforço ao valor, não extrair o máximo de gastos de todos.
O nível que é mais ignorado é o de não-gastador, e é o que tem mais potencial de crescimento. A maioria de uma base free-to-play nunca faz uma primeira compra, então um único incentivo de primeira compra, bem-sucedido, com baixa fricção, disparado após um momento de valor genuíno em vez de no primeiro dia, muitas vezes vale mais no agregado do que outro pacote direcionado a jogadores que já estão gastando. Mover até 2% de não-gastadores para uma primeira compra e você terá feito mais pela receita total do que apertando mais seus pagadores existentes, e terá feito isso sem tocar nas ofertas que seus jogadores leais já aceitam.
Monetização de jogos multicanal sem spam
A monetização de jogos multicanal só funciona se os canais compartilharem uma única identidade de assinante e um único limite de frequência, para que um jogador que esteja no meio de uma compra no push do aplicativo não receba a mesma oferta no push da web. Uma identidade, um limite, a oferta roteada para a superfície que o jogador realmente verifica. Essa orquestração entre canais é a diferença entre uma oferta coordenada e uma pilha de notificações que um jogador aprende a ignorar.
Ligar cada notificação de oferta ao ARPPU, não às aberturas
Uma notificação de oferta que obtém uma taxa de cliques de 23%, mas nenhuma compra incremental, é um custo, não uma vitória. As notificações de compra no jogo que valem a pena manter são aquelas que você pode rastrear até uma compra real. A métrica que importa para a monetização não são as aberturas; é a receita média por usuário pagante e a taxa com que você converte jogadores em pagadores. Para defender o canal, você tem que atribuir receita à notificação específica que a produziu.
Da notificação à receita: provar que converte jogadores em pagadores
A cadeia a ser instrumentada corre: notificação de oferta entregue → visita à loja → compra → aumento do ARPPU. O rastreamento de objetivos ao nível da notificação fecha esse ciclo, para que possa dizer, por exemplo, “a oferta de recarga de baixa moeda gerou 9.300 $ em compras no mês passado com uma conversão de 6%”, e não “enviámos um push de vendas”.
É assim que se prova que o canal converte jogadores em pagadores e se decide quais gatilhos escalar. Os comerciantes do PushEngage fora do setor de jogos já veem este tipo de aumento atribuível: a SuperJeweler gerou um aumento de receita de 8,2% apenas com o push de recuperação de carrinho, e o gatilho de loja abandonada acima é a mesma mecânica. Assim que a receita é atribuída por notificação, os gatilhos que convertem jogadores em pagadores recebem mais orçamento e os que apenas movem toques são cortados.
A linha que não se deve cruzar: limites de frequência e ofertas baseadas em valor
O push de monetização tem um modo de falha que os outros casos de uso não têm: faz push demais e não perde apenas uma venda, perde o jogador. Mensagens excessivas de ofertas são uma das rotas mais rápidas para um desinstalar, e um jogador desinstalado não compra nada. As salvaguardas não são opcionais.
Três regras mantêm um programa de ofertas no lado certo da linha. Limite as notificações de ofertas rigorosamente, não mais do que um par por semana, separadas dos seus envios de jogabilidade e retenção. Faça de cada oferta um valor genuíno pelo qual o jogador o agradeceria, não um pânico fabricado. E saia da campanha no momento em que o jogador compra, para que um cliente pagador nunca seja incomodado sobre o que acabou de comprar. Esta é a diferença entre a abordagem amigável e baseada em valor do PushEngage e a monetização de padrões sombrios pela qual a indústria é corretamente criticada. Também acontece que protege a entregabilidade e a confiança das quais cada oferta futura depende.
Há um argumento de receita para as salvaguardas, não apenas um ético. Um jogador que se mantém é um jogador que pode comprar novamente no próximo mês; um jogador que o silencia ou desinstala por spam de ofertas é um cliente que converteu uma vez e depois destruiu. Limites de frequência e ofertas baseadas em valor são como protege o valor vitalício que torna todo o programa digno de execução. Os estúdios que melhor monetizam ao longo dos anos não são aqueles que fazem mais push numa determinada semana.
O que custa, e porque as ofertas de canais próprios se compõem
O último argumento é o custo. Comprar um espaço de oferta, um anúncio, um intersticial, uma promoção cruzada, custa dinheiro cada vez que é executado. Entregar a mesma oferta num canal que possui custa quase nada por envio, e o PushEngage cobra apenas por assinantes ativos, para que a sua fatura acompanhe o público realmente capaz de comprar, e não o tamanho da lista de vaidade. É o modelo de pagar apenas por assinantes ativos, para que o motor de ofertas permaneça barato à medida que escala.
E isso acumula. Cada novo assinante é outro jogador que pode alcançar com uma oferta acionada e bem programada, enquanto jogar, sem custo incremental. Promoções pagas reiniciam a cada campanha; a monetização de jogos em canais próprios continua a converter a base que já construiu.
A conclusão é uma só: para aumentar as compras no jogo, pare de redesenhar a loja e comece a corrigir a entrega. Ative a oferta com base no comportamento do jogador, inspire-se no manual do comércio eletrónico, segmente por gastos, entregue por canal, atribua a receita e limite a frequência. A oferta provavelmente nunca foi o problema. Alcançar o jogador certo no momento certo foi, e isso é a única coisa que um canal de notificações próprio faz melhor do que qualquer outra coisa.
Pronto para transformar a sua próxima oferta por tempo limitado em receita atribuível? Comece com o plano de pague apenas por assinantes ativos e crie a sua primeira oferta acionada esta semana.
