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

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.
Utiliza este plan cuando estés agregando suscripciones o desbloqueos premium con @capgo/native-purchases.
Comienza con un objetivo de ingresos simple
Comienza con un objetivo de ingresos concreto. Por ejemplo:Precio mensual
| 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 tarifas de 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
Sección titulada “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 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.
-
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 aplicaciones competidoras para encontrar características faltantes, onboarding confuso, quejas de precios y fricción de interfaz de usuario.
-
Envía un MVP estrecho
La primera versión debe incluir onboarding, una acción útil básica, manejo de errores básico y suficientes análisis para ver si los usuarios alcanzan el momento de valor.
-
Añada compras tempranas
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 funil antes de optimizar
Instrumente el funil antes de optimizarRegistre estos eventos antes de empezar a cambiar precios o pantallas:
| Evento | Por qué importa |
|---|---|
install o primero abrir | 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 | Cumplimiento de la compra y la revisión de la conformidad |
subscription_status_checked | Fiable la titularidad |
cancel_feedback_submitted | Razón de abandono |
Si muchos usuarios no ven la pared de pago, arregle la incorporación antes de cambiar la pared de pago. Si los usuarios ven la pared de pago pero no comienzan una prueba, mejore la oferta, la prueba o la presentación del precio.
Elegir un modelo de monetización
Sección titulada “Elegir un modelo de monetización”Comience con un modelo para que los datos sean legibles.
| Modelo | Buena adaptación | Primera versión |
|---|---|---|
| Freemium | Herramientas, 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 onboarding | Paywall después de la onboarding con 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 en el futuro |
Evita enviar tres niveles, muchos paquetes y rutas de actualización complejas desde el día uno. Utiliza un plan mensual y un plan anual cuando necesites suscripciones. Agrega precios localizados después de ver tráfico significativo de un país.
Configura productos para el aprendizaje de ingresos
Sección titulada “Configure productos para el aprendizaje de ingresos”Mantén identificadores de producto establecidos y legibles:
com.example.app.premium.monthlycom.example.app.premium.yearlycom.example.app.premium.lifetimeUtiliza nombres de productos en 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 metadatos y las compras en la aplicación pueden ayudar a la descubierta y la claridad.
Carga 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'));Nunca codifiques precios de la tienda en la interfaz de usuario. Rendere 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.
Construye un primer muro de pago
Sección titulada “Construye 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”.
- Ventajas: 3 a 5 mejoras concretas, no una lista de características larga.
- 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 “Mejorar ahora”.
- Enlaces: términos, política de privacidad, restaurar compras y administrar suscripciones.
Coloque el primer muro 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 acción principal completadas.
Flujo de compra y restauración
Sección titulada “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 backend antes de otorgar derechos duraderos. Mantenga una caché de derechos locales para una UI rápida, pero trate la tienda y su backend como la fuente de verdad.
Traiga a los primeros usuarios
Sección titulada “Traiga a los primeros usuarios”La rentabilidad 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.
Lee la rotura correctamente
Sección titulada “Lee la rotura correctamente”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 repetido o bucle de hábito débil.
- Reembolsos: incompatibilidad de 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 el texto de la paywall.
Lista de verificación de lanzamiento
Sección titulada “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 paywall muestra precios y términos cargados en la tienda.
- Se implementan la compra, restauración, gestión de suscripción y validación de backend.
- Se rastrean eventos de funil 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 del lanzamiento.
- Se recopila retroalimentación de abandono desde los primeros suscriptores.