Libro de estrategia de ingresos

Copya 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

Haz que el primer objetivo sea concreto. Por ejemplo:

Precio mensual	Se necesitan suscriptores activos por 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 tiendas, 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

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

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

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

Instrumente el funil antes de optimizar

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

Evento	¿Por qué importa?
`install` o primera apertura	Tráfico de línea base
`onboarding_completed`	¿Entienden los usuarios la configuración?
`core_action_completed`	¿Si el producto entrega 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`	Recuperación de compras y cumplimiento de revisiones
`subscription_status_checked`	Fiabilidad de la entrega
`cancel_feedback_submitted`	Razón de rotura

Si muchos usuarios no ven la pantalla de pago, corrija 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

Comienza con un modelo para que los datos sean legibles.

Modelo	Mejor ajuste	Primera versión
Modelo de precios mixto	Herramientas diarias, rastreadores, herramientas con uso repetido	Acción gratuita en el núcleo, límites pagos o características premium
Paywall con prueba gratuita	Aplicaciones que entregan valor rápido después de la onboarding	Paywall después de la onboarding 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 futura opcional más tarde

Avoid enviar tres capas de envío, muchos paquetes y complejos caminos de actualización 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 los nombres de productos de la tienda que refuercen el valor que los usuarios están buscando, como “Planificador de Comidas Pro Mensual” en lugar de solo “Mensual”. Los nombres de los productos de la tienda y los metadatos y las compras en la aplicación pueden ayudar a la descubierta y la claridad.

Cargar datos de productos de las tiendas para que los precios, la moneda y las ofertas iniciales estén siempre 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.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.

Construir un primer muro de pago

A la primera barrera de pago, debe ser clara, no ingeniosa:

Título: el resultado pagado, como “Desbloquear 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: duración exacta de la prueba y qué sucede después de que termina.
CTA: “Iniciar prueba gratuita” o “Actualizar ahora”.
Enlaces: términos, política de privacidad, restaurar compras y administrar suscripciones.

Coloque la primera barrera de pago después de la onboarding, una vez que el usuario entiende qué hace la aplicación. Más tarde, pruebe desencadenantes adicionales como límites de uso, pulsaciones de características premium o acciones de acción central 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 derechos de durabilidad. Mantenga una caché de derechos locales para una UI rápida, pero trate la tienda y su servidor como la fuente de verdad.

[Bring in the first users]

La recaudación necesita tráfico. Comienza con canales que puedan funcionar antes de tener una marca:

ASO: 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 de problema/solución y ejemplos antes/después para el país objetivo.
Reddit y comunidades: únete a la conversación primero, luego comparte lo que construiste 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 funel medido para que puedas comparar la retención, vistas de la paywall, pruebas y compras.

[Read churn correctly]

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.
Cancela después de un ciclo: no hay suficiente valor de repetición o bucle de hábito débil.
Reembolsos: desacuerdo en precios, riesgo de compra accidental o términos no claros.
No restaura: manejo de derechos rotos o interfaz de restauración faltante.

Agregar una encuesta de cancelación de una pregunta cuando sea posible. Utilice las respuestas para mejorar la 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 en la tienda.
Implementado la compra, 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 metadata de la tienda de aplicaciones explica el valor en las primeras capturas de pantalla.
Al menos un canal de adquisición está activo antes de la lanzamiento.
La retroalimentación de abandono se recopila de los primeros suscriptores.

Sigue adelante desde Revenue Playbook

Si estás utilizando Plan de Ingresos para planificar pagos y compras, conectarlo con Usando @capgo/native-purchases para la capacidad nativa en Usando @capgo/native-purchases, Precios de Capgo para el flujo de trabajo del producto en Precios de Capgo, Sistema de pagos para el detalle de implementación en Sistema de pagos, @capgo/native-purchases para el detalle de implementación en @capgo/native-purchases, y Inicio para el detalle de implementación en Inicio.