Libro de ingresos

El SDK de compra 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, facturación de tienda confiable y una puerta de pago que enseña a las personas qué están dispuestas a comprar.

Utilice este planificador de ingresos 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 la tienda, 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

1. Elige un caso de uso doloroso

   Construye alrededor de un resultado que los usuarios ya buscan. Ejemplos: un plan de entrenamiento 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. Verifica la demanda en las tiendas

   Busca en la App Store 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 en la interfaz de usuario.

3. 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.

4. 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 canal antes de optimizar

Registre 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	Recuperación y revisión de compras
subscription_status_checked	Fiabilidad de la concesión
cancel_feedback_submitted	Motivo de abandono

Si muchos usuarios no ven la pared de pago, resuelve 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 adaptación	Primera versión
Freemium	Utilidades diarias, rastreadores, herramientas con uso repetido	Acción gratuita, límites pagados o características premium
Pagar con prueba gratuita	Aplicaciones que ofrecen valor rápido después de la incorporación	Pago tras el registro con una prueba de 3 a 14 días
Desbloqueo único	Herramientas pequeñas con valor recurrente limitado	Producto de por vida más suscripción opcional posteriormente

Evita enviar tres niveles, muchos paquetes y rutas de actualización complejas desde el primer día. Utiliza un plan mensual y un plan anual cuando necesites suscripciones. Agrega precios localizados después de ver un tráfico significativo de un país.

Configura productos para el aprendizaje de ingresos

Mantén identificadores de producto estables y legibles:

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

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

Cargar datos de productos desde las tiendas para que los precios, monedas y 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 precios de tiendas en la interfaz de usuario. Render product.priceString, título de producto localizado, período de facturación y términos de prueba desde los datos de la tienda siempre que sea posible.

Construya una primera pantalla de pago

Una primera pantalla 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: exacta duración 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.

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, 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 valide las compras en su servidor antes de otorgar derechos duraderos. Mantenga una caché de derechos locales para una interfaz rápida, pero trate la tienda y su servidor como la fuente de verdad.

Traiga los primeros usuarios

La rentabilidad 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: unase a la conversación primero, luego comparte 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 puedas comparar la retención, las vistas de la paywall, las pruebas y las compras.

Lee la rotura de flujo correctamente

Algunos usuarios abandonan la aplicación después de probarla y decidir que no les gusta. 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 suficiente valor repetido o bucle de hábito débil.
• Devoluciones: desacuerdo de precios, riesgo de compra accidental, o términos poco claros.
• No restauraciones: manejo de derechos rotos o interfaz de restauración faltante.

Agregar una encuesta de cancelación de una pregunta cuando sea posible. Utilizar las respuestas para mejorar la onboarding, el alcance de características, capturas de pantalla de la tienda y el texto de la paywall.

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.
• Muestra precios y términos cargados desde la tienda.
• Implementación de 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.
• App store metadata explains the value in the first screenshots.
• Al menos un canal de adquisición está activo antes del lanzamiento.
• Se recopila retroalimentación de abandono de la primera suscripción.

Guías relacionadas

• Getting started
• Crear suscripciones de iOS
• Crear suscripciones de Android
• Pruebas de sandbox de iOS
• Pruebas de sandbox de Android

Continúa desde Revenue Playbook

Si estás utilizando Libro de Recaudación de Ingresos para planificar pagos y compras, conecta 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 Getting Started para el detalle de implementación en Empezar.