Contenido
Manténgase al día de los últimos acontecimientos en marketing digital
Resumen
-
Adoptar nuevos modelos de pago: Con la legalidad de los pagos internos en iOS, los profesionales del marketing deberían explorar tres opciones: pagos en la App Store (gestionados por Apple), pagos en la tienda web (a través de procesadores externos) y pagos webview (en el navegador de la aplicación). El modelo de tienda web ofrece ventajas como una autenticación de usuario y un procesamiento de pagos más sencillos, mientras que webview mantiene a los usuarios dentro del contexto de la aplicación, aunque puede generar inconvenientes debido a las restricciones de cookies.
-
Mantener el seguimiento limpio de canales: Es crucial que los mercadólogos vean todos los pagos de iOS—ya sea realizados dentro de la app o a través de una interfaz web—como compras dentro de la app para evitar la confusión de canales. Este enfoque garantiza cálculos precisos de ROI y LTV al vincular los ingresos con los esfuerzos de adquisición de usuarios, permitiendo una mejor optimización de las campañas de marketing.
-
Prepárate para los cambios de Android: A medida que Android experimenta cambios en las políticas de facturación, al igual que iOS, los mercadólogos deben mantenerse informados sobre desarrollos legales y participar en programas como la Facturación de Elección del Usuario de Google's. Entender estos cambios ayuda a planificar la adquisición de usuarios y el procesamiento de pagos
¿Planeas aceptar pagos de iOS internamente? Genial, pero ahora también necesitas saber cómo medir los pagos fuera de la App Store con tu MMP.
Aquí te explicamos cómo…
Pagando por compras dentro de la app a través de terceros o tu propia solución de comercio electrónico es ahora totalmente legal para apps iOS en Estados Unidos, gracias a la demanda de Epic Games’ contra Apple. (Si estás pensando en hacerlo, aquí’s un marco que puedes usar para decidir) Pero los especialistas en marketing saben que antes de celebrar con una gran fiesta en la calle principal de Cupertino, deben asegurarse de vincular los ingresos de los usuarios con sus costos para seguir ejecutando campañas de adquisición de usuarios inteligentes.
De lo contrario, estás actuando a ciegas. Has interrumpido el ciclo de retroalimentación de optimización de tu campaña publicitaria porque no logras conectar los costos con el comercio.
Así es como conectas la medición MMP a la gestión interna de pagos iOS.
3 opciones para pagos iOS ahora
Básicamente, ahora hay tres formas de aceptar pagos iOS, incluida la forma tradicional de dejar que Apple lo administre por usted.
- Pagos iOS en App Store
Lo mismo de siempre … compras dentro de la app mediadas por Apple. Simple, sin fricción, y comisión del 15-30%. - Pagos iOS en tienda web
Normalmente para flujos de adquisición web2app o para salidas rápidas … sacando a los usuarios de su contexto dentro de la app, hacia una tienda web, completando la compra y devolviéndolos a tu app con un enlace profundo. También se puede hacer antes de instalar la app, algo habitual en muchos flujos de suscripción web2app, y totalmente independiente de cualquier sesión de la app. - Pagos iOS con Webview
Aunque técnicamente se parece al #2 anterior, no es idéntico. Webview abre un navegador dentro de la app, manteniendo a los usuarios en contexto al máximo.
En el modelo de App Store, Apple toma el pago pero también hace algo más muy importante: notificar a la aplicación que sí, un usuario pagó por X y ahora puede liberarle X en la aplicación.
En el modelo de tienda web, un procesador de pagos como Stripe o PayPal, o un servicio como RevenueCat (que ahora ofrece muros de pago), recibe el pago y luego envía una devolución de llamada, a menudo a través de un SDK, para que tu app sepa liberar el producto. Lo mejor del modelo de tienda web es que it’s una experiencia completa de navegador con acceso total a cookies y sesiones existentes. Así, si un usuario paga una vez creando una cuenta, su información de pago puede almacenarse y reutilizarse sin volver a ingresarla en compras posteriores. Además, al menos en teoría, los usuarios podrían usar otro dispositivo — como su laptop — para completar la compra allí y luego ver el beneficio en tu app.
El modelo de vista web es el mejor para mantener a los usuarios en el contexto de la aplicación, pero tiene una posible desventaja. Las vistas web, tanto en iOS (WKWebView) como en Android (WebView), están aisladas. Esto significa que el contenido web está aislado de los datos internos de la aplicación nativa y de otros recursos del sistema, pero también que, en algunos casos, no se puede acceder a las cookies ni a los datos de inicio de sesión de un usuario.
(Excepción: cuando realmente envías un navegador dentro de la aplicación, como SFSafariViewController, que es esencialmente una instancia completa de Safari dentro de tu aplicación)
Esto significa que, incluso si los usuarios ya tienen cuentas en Stripe, PayPal o RevenueCat, podrían no ser accesibles sin iniciar sesión, lo que añade fricción. Y, si no tienen cuentas con procesadores de pago, podrían tener que dar el temido siguiente paso de sacar la billetera, buscar una tarjeta de crédito e ingresar todos sus datos, lo cual es un proceso tedioso.
(No importa tener que aplicar 2FA potencialmente en una transacción con un emisor de tarjeta sospechoso que ve una tienda desconocida intentando cobrar una tarjeta)
Ahí es donde pueden surgir fricciones fuertes.
Importante: mantén tus canales limpios
La confusión de canales solía ser algo de lo que solo se preocupaban los vendedores de productos de consumo masivo. ¿Fue un anuncio de televisión, el folleto de la tienda, un influencer o algún otro canal de distribución o marketing lo que influyó en una venta?
Basta: ahora los editores de aplicaciones también deben pensar en ello.
Si generalizamos los “canales” a donde se vende un producto, para pagos mediante aplicaciones móviles, claramente tendrías 3 posibilidades de canales específicos: los mencionados anteriormente.
¿Pero realmente hay tres? ¿No son solo dos, porque Web Store y WebView básicamente usan la misma funcionalidad en segundo plano para procesar pagos e intercambiar datos con tu aplicación? En cierto modo, sí, pero puede ser confuso.
Es pronto, pero en Singular creemos que las compras dentro de la aplicación deberían considerarse compras dentro de la aplicación, dondequiera que se realicen. Esta es una forma de analizar los ingresos centrada en la aplicación, ya que los resultados clave se encuentran en ella.
Esto significa que, en definitiva, cualquier pago o compra en iOS fuera de la aplicación debe reportarse y vincularse al usuario/dispositivo móvil. En definitiva, es obligatorio, ya que se ha entregado el artículo o servicio adquirido al usuario, cliente o suscriptor. Además, esto garantiza que los ingresos se mantengan vinculados a la adquisición de usuarios, lo que facilita los cálculos de ROI/ROAS/LTV.
(La otra opción, por supuesto, es rastrear estos pagos fuera de la tienda de aplicaciones como eventos web o ingresos entre dispositivos… lo que sería un desafío en cualquier caso porque los portales de pago probablemente sean propiedad de su proveedor de pagos y no de usted, el editor y comercializador de la aplicación)
Conectando los pagos de iOS a las personas
Hay una variedad de formas técnicas de asociar el pago web con el usuario/dispositivo móvil, y tendrán diferentes ventajas y desventajas en términos de integración en la aplicación y desafíos desde el lado del proceso de pago.
- Integración directa con cada proveedor de pago y el evento con el ID del dispositivo y/o customVendorID a través de la comunicación de servidor a servidor
- Devolución de llamada de "pago exitoso" desde el SDK/API del proveedor de pagos, ya sea del lado del servidor o en el cliente, y luego reenvía el evento de ingresos a Singular en el SDK Singular
Con el tiempo habrá opciones súper claras y simples, pero la número 2 actualmente es extremadamente factible.
La gran pregunta será cómo las grandes plataformas de pago optimizarán esto. En última instancia, los profesionales del marketing deben medir las compras internas como compras dentro de la aplicación, no como compras web, para evitar la confusión entre canales y hacer que el ROI/ROAS sea monitorizable, y Singular lo respaldará.
¿Qué pasa con Android y los pagos internos?
Lo interesante es que con todo esto sucediendo en los pagos de iOS, es fácil olvidarse de Android.
En los últimos años, Android ha experimentado cambios significativos en cuanto a las opciones de facturación de terceros, tanto por iniciativas de Google como por mandatos legales. Por ejemplo, el programa piloto "Facturación a elección del usuario" de Google permite a los desarrolladores que cumplen los requisitos ofrecer un sistema de facturación alternativo junto con el de Google Play. Este programa está activo actualmente en más de 35 países, entre ellos EE. UU., Reino Unido, Canadá, Australia, Brasil, Japón y el Espacio Económico Europeo (EEE).
El problema es muy parecido al que llevó a la jueza Yvonne Gonzalez Rogers a ordenar a Apple que eliminara cualquier comisión o tarifa sobre los pagos fuera de la aplicación.
Las comisiones de Google no desaparecen... solo bajan un poco. Muy poco: los desarrolladores reciben un 4% de descuento en las comisiones por servicio por las transacciones procesadas a través de sistemas de facturación alternativos. Además, para participar, debes usar las API de facturación alternativa de Google, de modo que Google vea todos tus ingresos.
Sin embargo, esto podría cambiar, y por la misma razón que cambió Apple.
Epic no sólo demandó a Apple, también demandó a Google.
En octubre de 2024, un juez federal estadounidense falló a favor de Epic Games en una demanda antimonopolio contra Google, declarando que la tienda de aplicaciones de Android de Google ostenta un monopolio ilegal. El tribunal ordenó a Google implementar cambios significativos en las operaciones de Play Store para fomentar la competencia.
Estos cambios obligatorios incluyen:
- Permitir que las tiendas de aplicaciones de terceros se distribuyan dentro de Google Play
- Permitir a los desarrolladores informar a los usuarios sobre métodos de pago alternativos y opciones de descarga fuera de Google Play
- Prohibir a Google exigir el uso de la facturación de Google Play para las aplicaciones distribuidas en Play Store
- Restringir que Google ofrezca incentivos a desarrolladores o fabricantes de dispositivos para favorecer a Google Play frente a las tiendas rivales
Esos cambios debían entrar en vigor en noviembre de 2024… pero Google presentó una apelación y solicitó una suspensión de la ejecución de la orden judicial.
Así que ahí está, por ahora.
Hable con nosotros…podemos ayudarle
Si está pensando en implementar compras dentro de la aplicación internamente, contáctenos. Podemos ayudarle a completar el proceso para lograrlo, manteniendo intactas sus mediciones, análisis y optimización de campañas.
