Conteúdo
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.
-
Mantenha o rastreamento de canais limpo: É essencial que os profissionais de marketing vejam todos os pagamentos iOS—seja no app ou via interface web—como compras no app para evitar confusão de canais. Isso garante ROI e LTV precisos ao conectar a receita à aquisição de usuários, otimizando as campanhas de marketing.
-
Prepare-se para as mudanças no Android: À medida que o Android passa por alterações nas políticas de cobrança, semelhantes ao iOS, os profissionais de marketing devem ficar informados sobre desenvolvimentos legais e participar de programas como o User Choice Billing da Google's. Compreender essas mudanças ajuda a planejar 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…
Pagando por compras in‑app via terceiros ou sua própria solução de e‑commerce é agora totalmente legal para apps iOS nos Estados Unidos, graças à ação judicial da Epic Games’ contra a Apple. (Se você’ está pensando em fazer exatamente isso, aqui’s um framework para usar e ajudar a decidir) Mas profissionais de marketing experientes sabem que, antes de comemorar com um desfile de fita em Cupertino, precisam garantir que conseguem relacionar a receita dos usuários aos custos para continuar executando campanhas de aquisição de usuários inteligentes.
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 aqui’s como conectar medição MMP ao assumir 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 iOS na App Store
Mesmo de sempre … compras dentro do app mediadas pela Apple. Simples, sem atritos, e comissão de 15-30%. - Pagamentos iOS via loja web
Normalmente para fluxos de aquisição web2app ou para desvios … retirando usuários do contexto do app, para uma loja web, concluindo a compra e retornando-os ao seu app com um deep link. Isso também pode ser feito antes da instalação do app, prática comum em muitos fluxos de assinatura web2app, e totalmente independente de qualquer sessão do app. - Pagamentos Webview iOS
Embora tecnicamente é próximo ao #2 acima, não é exatamente equivalente. O Webview abre uma instância de navegador dentro do app, mantendo 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 web, um processador de pagamento como Stripe ou PayPal, ou um serviço como RevenueCat (agora com paywalls), recebe o pagamento e gera um callback, geralmente via um SDK, para que seu app libere o produto. O grande ponto positivo do modelo de loja web é que oferece experiência completa de navegador com acesso total a cookies e logins existentes. Assim, se o usuário paga uma vez, cria conta, suas informações de pagamento ficam armazenadas e podem ser reutilizadas sem novo cadastro em compras futuras. Além disso, teoricamente, usuários podem usar outro dispositivo — como o laptop — para concluir a compra e depois ver o benefício no app.
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.
