Libro de estrategias de ingresos

Copie un prompt de configuración con los pasos de instalación y la guía de markdown completa para este plugin.

Plan de ingresos para compras en la aplicación

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

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

Comience 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
Precio anual de $29.99	Alrededor de 400 suscriptores anuales, dependiendo del momento

Estos números son antes de las tarifas de almacenamiento, impuestos, devoluciones y diferencias de moneda. Aún así son útiles porque mantienen el plan de lanzamiento práctico: necesitas unos cientos de usuarios motivados, no una audiencia enorme.

Construye el producto pagado más pequeño

Elige un caso de uso doloroso

Construye 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.
Verifica la demanda en las tiendas

Búsqueda en App Store y Google Play para la palabra clave principal. Lee 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.
Envía 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.
Agrega compras temprano

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

Instrumenta el funil antes de optimizar

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

Evento	Por qué importa
`install` o primero abre	Tráfico de referencia
`onboarding_completed`	Si los usuarios entienden la configuración
`core_action_completed`	Si el producto ofrece valor
`paywall_viewed`	Si los usuarios alcanzan la monetización
`trial_started`	Si la oferta es atractiva
`purchase_completed`	Conversión pagada
`restore_started` y `restore_completed`	Comprar recuperación y revisar cumplimiento
`subscription_status_checked`	Reliable de derechos
`cancel_feedback_submitted`	Razón de abandono

Si muchos usuarios no ven la pantalla de pago, arregle la onboarding antes de cambiar la pantalla de pago. Si los usuarios ven la pantalla de pago pero no inician una prueba, mejore la oferta, la prueba o la presentación de precio.

Elige un modelo de monetización

Comience con un modelo para que los datos sean legibles.

Modelo	Buena adaptación	Primera versión
Freemium	Herramientas diarias, rastreadores, herramientas con uso repetido	Acción gratuita, límites pagados o características premium
Pagar por contenido adicional con prueba gratuita	Aplicaciones que brindan valor rápido después de la configuración	Pagar por contenido adicional después de la configuración con prueba gratuita de 3 a 14 días
Desbloqueo único	Herramientas pequeñas con valor recurrente limitado	Producto de por vida más suscripción opcional en un futuro

Evite enviar tres niveles, muchos paquetes y rutas de actualización complejas desde el día uno. 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.

Configurar 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 “Planificador de Comidas Pro Mensual” en lugar de solo “Mensual”.

Cargar datos de productos de 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'));

Never codificar precios de tienda en la interfaz de usuario. Render product.priceStringtítulo de producto localizado, período de facturación y términos de prueba desde los datos de la tienda siempre que sea posible.

Crear un primer muro de pago

Un primer muro de pago debe ser claro, no ingenioso:

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

Coloca la primera barrera de pago después de la onboarding, una vez que el usuario entiende qué hace la aplicación. Más tarde, prueba desencadenantes adicionales como límites de uso, pulsaciones 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 valida las compras en tu backend antes de otorgar derechos duraderos. Mantén una caché de derechos locales para una UI rápida, pero trata la tienda y tu backend como la fuente de verdad.

Trae a los primeros usuarios

Las ganancias necesitan tráfico. Comienza 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: publica demos rápidas, clips problema/solución y ejemplos antes/después para el país objetivo.
Únete a las comunidades de Reddit y participa en la conversación antes de compartir lo que has construido como una historia útil en lugar de un anuncio.
Grupos de beta: TestFlight, pruebas internas de Google Play, Discord y foros especializados.

Debería enviar a los usuarios a la misma canalización medible para que puedas comparar la retención, las vistas de la pantalla de pago, las pruebas y las compras.

Lee correctamente la rotura de la relación.

Algunas roturas de la relación 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.

Añade una encuesta de cancelación de una sola pregunta cuando sea posible. Utiliza las respuestas para mejorar el onboarding, el alcance de las características, las capturas de pantalla de la tienda y el texto de la pantalla de pago.

Lista de verificación de lanzamiento

El producto resuelve un problema pagado claro.
Los productos del almacén están activos y probados en iOS y Android.
La pantalla de pago muestra los precios y términos cargados en el almacén.
Se implementan la compra, restauración, gestión de la suscripción y validación de backend.
Se rastrean eventos de funil 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 desde los primeros suscriptores.

Sigue adelante desde Revenue Playbook

Si estás utilizando Revenue Playbook 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/compras nativas para el detalle de implementación en @capgo/compras nativas, y Inicio rápido para el detalle de implementación en Inicio rápido.