Contente
Mantenha-se atualizado sobre os últimos acontecimentos em marketing digital
Resumo
-
Adote novos modelos de pagamento : Com a legalização dos pagamentos internos no iOS, os profissionais de marketing devem explorar três opções de pagamento: pagamentos pela App Store (gerenciados pela Apple), pagamentos pela loja virtual (via processadores terceirizados) e pagamentos via webview (navegador integrado ao aplicativo). O modelo da loja virtual oferece benefícios como autenticação de usuário e processamento de pagamento mais fáceis, enquanto o webview mantém os usuários dentro do contexto do aplicativo, embora possa apresentar atritos devido às restrições de cookies.
-
Manter o rastreamento de canais limpo : É crucial que os profissionais de marketing visualizem todos os pagamentos do iOS — sejam eles feitos no aplicativo ou por meio de uma interface da web — como compras no aplicativo para evitar confusão de canais. Essa abordagem garante cálculos precisos de ROI e LTV, vinculando a receita aos esforços de aquisição de usuários e permitindo uma melhor otimização das campanhas de marketing.
-
Prepare-se para as mudanças no Android : À medida que o Android passa por mudanças nas políticas de faturamento, semelhantes às do iOS, os profissionais de marketing devem se manter informados sobre os desdobramentos legais e participar de programas como o User Choice Billing do Google. Compreender essas mudanças pode ajudar no planejamento estratégico de aquisição de usuários e processamento de pagamentos.
Planeja receber pagamentos do iOS internamente? Ótimo, mas agora você também precisa saber como mensurar pagamentos fora da App Store com sua plataforma de gestão de pagamentos (MMP).
Eis como…
Pagar por compras dentro do aplicativo por meio de soluções de e-commerce próprias ou de terceiros agora é totalmente legal para aplicativos iOS nos Estados Unidos , graças ao processo da Epic Games contra a Apple. (Se você está pensando em fazer isso, aqui está uma estrutura para te ajudar a decidir .) Mas os profissionais de marketing experientes sabem que, antes de comemorarem com uma parada triunfal na rua principal de Cupertino, precisam garantir que a receita gerada pelos usuários esteja atrelada aos seus custos, para que possam continuar executando campanhas inteligentes de aquisição de usuários.
Caso contrário, você estará navegando às cegas. Você terá interrompido o ciclo de feedback da otimização da sua campanha publicitária porque não consegue conectar custos e resultados comerciais.
Então, veja como conectar a mensuração de MMP ao processamento de pagamentos iOS internamente.
Agora você tem 3 opções de pagamento para iOS
Existem basicamente três maneiras de aceitar pagamentos no iOS atualmente, incluindo o método tradicional de deixar a Apple gerenciar tudo para você.
- Pagamentos na App Store para iOS:
Tudo como antes… compras dentro do aplicativo intermediadas pela Apple. Simples, sem complicações e com uma comissão de 15 a 30%. - Pagamentos em lojas virtuais para iOS.
Geralmente usados em fluxos de aquisição web-to-app ou para redirecionamento rápido do usuário para fora do aplicativo, levando-o para uma loja virtual, onde a compra é concluída e, em seguida, o usuário é redirecionado de volta para o aplicativo por meio de um link direto. Isso também pode ser feito antes da instalação do aplicativo, o que é comum em muitos fluxos de aplicativos de assinatura web-to-app, e de forma completamente independente de qualquer sessão do aplicativo. - Pagamentos com WebView no iOS.
Embora tecnicamente seja semelhante ao item nº 2 acima, não é exatamente equivalente. O WebView abre uma instância do navegador dentro do aplicativo, mantendo assim os usuários no contexto o máximo possível.
No modelo da App Store, a Apple recebe o pagamento, mas também faz algo muito importante: notifica o aplicativo de que sim, um usuário pagou por X, então agora você pode liberar X para ele no aplicativo.
No modelo de loja virtual, um processador de pagamentos como o Stripe ou o PayPal, ou um serviço como o RevenueCat (que agora oferece paywalls), recebe o pagamento e, em seguida, envia uma solicitação de retorno, geralmente por meio de um SDK , para que seu aplicativo saiba que deve liberar o produto. A grande vantagem do modelo de loja virtual é que ele oferece uma experiência completa no navegador, com acesso total aos cookies e logins existentes. Assim, se um usuário paga por algo uma vez, criando uma conta, suas informações de pagamento podem ser armazenadas e reutilizadas sem a necessidade de digitá-las novamente em compras subsequentes. Além disso, pelo menos teoricamente, os usuários poderiam usar um dispositivo diferente — como um laptop — para concluir uma compra e, em seguida, ver o benefício em seu aplicativo.
O modelo WebView é o melhor em termos de manter os usuários no contexto do seu aplicativo, mas apresenta uma possível desvantagem. Os WebViews, tanto no iOS (WKWebView) quanto no Android (WebView), são executados em sandbox. Isso significa que o conteúdo da web fica isolado dos dados internos do aplicativo nativo e de outros recursos do sistema, mas também que, em alguns casos, você não pode acessar os cookies e logins existentes do usuário.
(Exceção: quando você realmente inclui um navegador no aplicativo, como o SFSafariViewController, que é essencialmente uma instância completa do Safari dentro do seu aplicativo.)
Isso significa que, mesmo que os usuários já possuam contas no Stripe, PayPal ou RevenueCat, elas podem não estar acessíveis sem um processo de login, o que aumenta a dificuldade de acesso. E, se os usuários não tiverem contas com processadores de pagamento, talvez precisem dar aquele passo temido de pegar a carteira, encontrar um cartão de crédito e inserir todos os seus dados manualmente.
(Sem falar na possibilidade de ter que usar a autenticação de dois fatores em uma transação com uma emissora de cartão suspeita que vê uma loja desconhecida tentando cobrar no cartão.)
É aí que podem surgir atritos sérios.
Importante: mantenha seus canais limpos
Antigamente, a confusão entre canais era uma preocupação exclusiva dos fornecedores de bens de consumo embalados. Será que foi um anúncio de TV, um folheto da loja, um influenciador ou algum outro canal de distribuição ou marketing que influenciou a venda?
Chega: agora os desenvolvedores de aplicativos também precisam pensar nisso.
Se generalizarmos o conceito de "canais" para os locais onde um produto é vendido, no caso de pagamentos por aplicativos mobile , teríamos claramente 3 possibilidades específicas de canais: as mencionadas acima.
Mas será que são mesmo 3? Não seriam apenas 2, já que a Web Store e a WebView usam essencialmente a mesma funcionalidade nos bastidores em termos de processamento de pagamentos e compartilhamento de dados com o seu aplicativo? De certa forma, sim, mas pode ser confuso.
Ainda é cedo, mas na Singular , defendemos que as compras dentro do aplicativo devem ser consideradas compras dentro do aplicativo, independentemente de onde ocorram. Essa é uma maneira centrada no aplicativo de analisar sua receita, porque seus principais resultados estão dentro do aplicativo.
Isso significa que, no fim das contas, qualquer pagamento ou compra "fora do aplicativo" em um dispositivo iOS deve ser registrado e vinculado ao próprio usuário/dispositivo mobile . Isso é essencial, pois você precisa entregar o item ou serviço adquirido ao seu usuário, cliente ou assinante. Além disso, garante que a receita permaneça atrelada à aquisição de usuários, o que mantém os cálculos de ROI/ROAS/LTV transparentes.
(A outra opção, claro, é rastrear esses pagamentos fora da loja de aplicativos como eventos da web ou receita entre dispositivos... o que seria um desafio de qualquer forma, porque os portais de pagamento provavelmente pertencem ao seu provedor de pagamento e não a você, o editor e profissional de marketing do aplicativo.)
Conectando pagamentos do iOS às pessoas
Existem diversas maneiras técnicas de associar o pagamento online ao usuário/dispositivo mobile , e cada uma delas apresenta vantagens e desvantagens em termos de integração no aplicativo e desafios no processo de pagamento.
- Integração direta com cada fornecedor de pagamento e o evento com o ID do dispositivo e/ou ID do fornecedor personalizado por meio de comunicação servidor a servidor
- O retorno de chamada de "pagamento bem-sucedido" do SDK/API do fornecedor de pagamentos, seja no servidor ou no cliente, encaminha o evento de receita de volta para Singular no SDK Singular
Eventualmente, haverá opções super claras e simples, mas a opção nº 2 é extremamente viável no momento.
A grande questão será como as principais plataformas de pagamento irão lidar com isso. Em última análise, os profissionais de marketing precisam mensurar as compras internas como compras dentro do aplicativo, e não na web, para evitar confusão entre canais e tornar o ROI/ROAS mensurável, e Singular dará suporte a isso.
E quanto ao Android e aos pagamentos internos?
O interessante é que, com tudo isso acontecendo nos pagamentos do iOS, é fácil esquecer do Android.
Nos últimos anos, o Android passou por mudanças significativas em relação às opções de faturamento de terceiros, tanto por meio de iniciativas do Google quanto por exigências legais. Por exemplo, o programa piloto "User Choice Billing" do Google permite que desenvolvedores qualificados ofereçam um sistema de faturamento alternativo juntamente com o sistema de faturamento do Google Play. Esse programa está atualmente ativo em mais de 35 países, incluindo EUA, Reino Unido, Canadá, Austrália, Brasil, Japão e Espaço Econômico Europeu (EEE).
O problema é muito semelhante ao que levou a juíza Yvonne Gonzalez Rogers a ordenar que a Apple eliminasse quaisquer comissões ou taxas sobre pagamentos fora do aplicativo.
As comissões do Google não desaparecem... apenas diminuem um pouco. Muito pouco: os desenvolvedores recebem uma redução de 4% nas taxas de serviço para transações processadas por meio de sistemas de faturamento alternativos. E, para participar, você precisa usar as APIs de faturamento alternativo do Google, então o Google fica com toda a sua receita.
Isso pode mudar, no entanto, e pela mesma razão que a Apple mudou.
A Epic não processou apenas a Apple, mas também o Google.
Em outubro de 2024, um juiz federal dos EUA decidiu a favor da Epic Games em um processo antitruste contra o Google, declarando que a loja de aplicativos Android do Google detém um monopólio ilegal. O tribunal ordenou que o Google fizesse mudanças significativas em suas operações na Play Store para fomentar a concorrência.
Essas alterações obrigatórias incluem:
- Permitir que lojas de aplicativos de terceiros sejam distribuídas dentro do Google Play
- Permitir que os desenvolvedores informem os usuários sobre métodos de pagamento alternativos e opções de download fora do Google Play
- Proibir o Google de exigir o uso do Google Play Billing para aplicativos distribuídos na Play Store
- Impedir que o Google ofereça incentivos a desenvolvedores ou fabricantes de dispositivos para favorecer o Google Play em detrimento de lojas concorrentes
Essas mudanças deveriam ter entrado em vigor em novembro de 2024… mas o Google entrou com um recurso e solicitou a suspensão da aplicação da liminar.
Então, por enquanto, está assim.
Fale conosco... podemos ajudar
Se você está pensando em internalizar as compras dentro do aplicativo, fale conosco. Podemos ajudá-lo(a) a realizar esse processo, mantendo intactas suas métricas, análises e otimização de campanhas.
Reserve um horário hoje mesmo.
