Libro de Playbook de Rentabilidad

La compra SDK es solo una parte de ganar dinero con una aplicación. Los ingresos provienen de un problema claro, un producto pequeño que los usuarios pueden probar, facturación de tienda confiable y una puerta de pago que enseña qué están dispuestos a comprar los usuarios.

Utilice este playbook cuando esté agregando suscripciones o desbloqueos premium con @capgo/native-purchases.

Inicie con un objetivo de ingresos simple

Haga que el primer objetivo sea concreto. Por ejemplo:

Precio mensual	Suscriptores activos necesarios para unos $1K MRR
$4.99	201
$7.99	126
$9.99	101
$29.99 anual	Alrededor de 400 suscriptores anuales, dependiendo de la fecha

Estos números son antes de las comisiones de la tienda, impuestos, devoluciones y diferencias de moneda. Aún así son útiles porque mantienen el plan de lanzamiento práctico: necesita unos pocos cientos de usuarios motivados, no una gran audiencia.

Construya el producto pagado más pequeño

1. Elige un caso de uso doloroso

   Construya alrededor de un resultado que los usuarios ya buscan. Ejemplos: un plan de ejercicios para nuevos padres, un rastreador de presupuesto para parejas, un escáner de recibos para freelancers, o una aplicación de práctica de idiomas para un examen.

2. Verifique la demanda en las tiendas

   Busque en la Tienda de App y Google Play por la palabra clave principal. Lea las reseñas de baja y media puntuación de aplicaciones competidoras para encontrar características faltantes, onboarding confuso, quejas de precios y fricción en la interfaz de usuario.

3. Envíe un MVP estrecho

   La primera versión debe incluir onboarding, una acción útil principal, manejo básico de errores y suficientes análisis para ver si los usuarios alcanzan el momento de valor.

4. Agregue compras temprano

   No espere hasta que la aplicación se sienta completa. Una paywall básica le ayuda a aprender si los usuarios entienden el valor y si su precio es plausible.

Instrumente el canal antes de optimizar

Registre estos eventos antes de empezar a cambiar precios o pantallas:

Evento	¿Por qué importa?
install o primero abrir	Tráfico base
onboarding_completed	¿Los usuarios entienden la configuración?
core_action_completed	¿El producto ofrece valor?
paywall_viewed	¿Los usuarios alcanzan la monetización?
trial_started	¿La oferta es atractiva?
purchase_completed	Conversión pagada
restore_started y restore_completed	Recuperación de compras y cumplimiento de revisión
subscription_status_checked	Fiabilidad de la autorización
cancel_feedback_submitted	Causa de abandono

Si muchos usuarios no ven la pared de pago, corrija la onboarding antes de cambiar la pared de pago. Si los usuarios ven la pared de pago pero no inician una prueba, mejora la oferta, la prueba o la presentación del precio.

Elige un modelo de monetización

Comienza con un modelo para que los datos sean legibles.

Modelo	Buena opción	Primera versión
Contexto: Página/área: Capgo Builder / página de producto de construcción nativa en la nube. Rol: Etiqueta de UI corta o elemento de navegación. Clave de mensaje `native_build_builder_credit_first` (Crédito del constructor de construcción nativa).	Freemium	Utilidades, rastreadores y herramientas diarias con uso repetido
Acción gratuita en el núcleo, límites pagados o características premium	Paywall con prueba gratuita	Aplicaciones que entregan valor rápido después de la incorporación del usuario final. El pago se realiza después de la incorporación del usuario final con una prueba gratuita de 3 a 14 días.
Desbloqueo único	Herramientas pequeñas con valor recurrente limitado	Producto de por vida más una suscripción opcional posteriormente

No envíe tres niveles de envío, muchos paquetes y rutas de actualización complejas desde el primer día. Utilice un plan mensual y un plan anual cuando necesite suscripciones. Agregue precios localizados después de ver un tráfico significativo de un país.

Configure productos para el aprendizaje de ingresos

Mantenga los identificadores de producto establecidos y legibles:

com.example.app.premium.monthly
com.example.app.premium.yearly
com.example.app.premium.lifetime

Utilice nombres de productos de tienda que refuercen el valor que los usuarios están buscando, como “Meal Planner Pro Mensual” en lugar de solo “Mensual”. Los metadatos y los nombres de compras en la aplicación pueden ayudar a la descubierta y la claridad.

Cargue los datos de productos desde las tiendas para que los precios, la moneda y las ofertas iniciales siempre sean precisos:

import { NativePurchases, PURCHASE_TYPE } from '@capgo/native-purchases';

const { products } = await NativePurchases.getProducts({
  productIdentifiers: [
    'com.example.app.premium.monthly',
    'com.example.app.premium.yearly',
  ],
  productType: PURCHASE_TYPE.SUBS,
});

const monthly = products.find((product) => product.identifier.endsWith('.monthly'));
const yearly = products.find((product) => product.identifier.endsWith('.yearly'));

Jamás codifique los precios de la tienda en la interfaz de usuario. Render product.priceStringutilice siempre los datos de la tienda para obtener el título del producto, el período de facturación y los términos de prueba localizados.

Construya una primera pantalla de pago

Una primera pantalla de pago debe ser clara, no ingeniosa:

• Encabezado: el resultado pagado, como “Desbloquee planes de entrenamiento ilimitados”.
• Beneficios: 3 a 5 mejoras concretas, no una larga lista de características.
• Planes: mensuales y anuales, con ahorros anuales reales si se ofrecen.
• Prueba: la longitud exacta de la prueba y qué sucede después de que termina.
• Llamada a la acción: “Inicie la prueba gratuita” o “Actualice ahora”.
• Enlaces: términos, política de privacidad, restaurar compras y administrar suscripciones.

Coloque la primera pantalla de pago después de la onboarding, una vez que el usuario entienda qué hace la aplicación. Más tarde, pruebe desencadenantes adicionales como límites de uso, toques de características premium o acciones de núcleo completadas.

Flujo de compra y restauración

import { NativePurchases, PURCHASE_TYPE } from '@capgo/native-purchases';

export async function buyYearly(appAccountToken: string) {
  const transaction = await NativePurchases.purchaseProduct({
    productIdentifier: 'com.example.app.premium.yearly',
    planIdentifier: 'yearly-plan',
    productType: PURCHASE_TYPE.SUBS,
    appAccountToken,
  });

  await fetch('/api/purchases/validate', {
    method: 'POST',
    headers: { 'content-type': 'application/json' },
    body: JSON.stringify({
      transactionId: transaction.transactionId,
      receipt: transaction.receipt,
      purchaseToken: transaction.purchaseToken,
      productIdentifier: transaction.productIdentifier,
    }),
  });

  return transaction;
}

export async function restorePurchases() {
  await NativePurchases.restorePurchases();

  return NativePurchases.getPurchases({
    productType: PURCHASE_TYPE.SUBS,
  });
}

Siempre valide las compras en su servidor antes de otorgar permisos duraderos. Mantenga una caché de permisos locales para una interfaz rápida, pero trate la tienda y su servidor como la fuente de verdad.

Traiga a los primeros usuarios

La renta necesita tráfico. Comience con canales que puedan funcionar antes de tener una marca:

• SEO: título, subtítulo, palabras clave, capturas de pantalla, descripción de la aplicación, icono, calificaciones y nombres de compras en la aplicación.
• Video corto: publique demos rápidas, clips de problema/solución y ejemplos antes/después para el país objetivo.
• Reddit y comunidades: unirse a la conversación primero, luego compartir lo que construyó como una historia útil en lugar de un anuncio.
• Grupos de beta: TestFlight, pruebas internas de Google Play, Discord y foros especializados.

Cada canal debe enviar a los usuarios en el mismo funil medido para que pueda comparar la retención, vistas de la pared de pago, pruebas y compras.

Lee la rotura de forma correcta

Algunas roturas significan que los usuarios intentaron la aplicación y decidieron que no era para ellos. Eso es normal. Lo que importa es el patrón:

• Cancelaciones durante la prueba: valor incierto, onboarding deficiente o tráfico incorrecto.
• Cancelaciones después de un ciclo: no hay suficiente valor de repetición o bucle de hábito débil.
• Reembolsos: incompatibilidad de precios, riesgo de compra accidental o términos no claros.
• No se restauran: manejo de derechos rotos o interfaz de restauración faltante.

Agregar una encuesta de cancelación de una sola pregunta cuando sea posible. Utilice las respuestas para mejorar el onboarding, el alcance de características, capturas de pantalla de la tienda y copia de la pared de pago.

Lista de verificación de lanzamiento

• El producto resuelve un problema pagado claro.
• Los productos de la tienda están activos y probados en iOS y Android.
• La pared de pago muestra precios y términos cargados desde la tienda.
• Se implementan compras, restauración, gestión de suscripción y validación de backend.
• Se rastrean eventos de canalización desde la primera apertura hasta la compra.
• La información de metadatos de la tienda de aplicaciones explica el valor en las primeras capturas de pantalla.
• Al menos un canal de adquisición está activo antes del lanzamiento.
• Se recopila retroalimentación de abandono de suscripción desde los primeros suscriptores.

Guías relacionadas

• Empezar
• Crear suscripciones iOS
• Crear suscripciones Android
• Pruebas de sandbox de iOS
• Pruebas de sandbox de Android

Sigue adelante desde el Libro de ingresos

Si estás utilizando Libro de ingresos para planificar pagos y compras, conecta con Usando @capgo/native-purchases para la capacidad nativa en Usando @capgo/native-purchases Capgo Precios para el flujo de trabajo del producto en Capgo Precios Sistema de pago para el detalle de implementación en Sistema de pago @capgo/native-purchases para los detalles de implementación en @capgo/compras nativas, y Inicio para los detalles de implementación en Inicio.