Nombra el hecho que prueba cada evento
Se mostró un paywall. Alguien pidió una prueba. El store devolvió una transacción. El servidor la validó. Un derecho se activó. Un embudo no debe agrupar estos hechos bajo un solo evento llamado ingresos.
Documenta fuente de verdad y fallos por etapa. La analítica describe intención o interfaz; compras y acceso requieren integración real con store y servidor. El nombre de una pantalla no sustituye esa validación.
Elige el denominador del paywall
Cuenta instalaciones únicas que lo vieron dentro de la cohorte elegida. Para conversión de compra usa el resultado verificado y una ventana definida. Separa la métrica de intento de ambas.
Ejemplo ficticio: 1.000 elegibles, 600 vistas, 120 toques de prueba y 80 pruebas verificadas. El toque entre vistas es 20 %; la conversión verificada, aproximadamente 13,3 %. Ninguna mide renovación futura ni ingresos netos.
Intención y verificación son etapas distintas
Ejemplo inventado con una cohorte elegible.
Incluye cancelación, espera y restauración
Una compra puede cancelarse, aplazarse o fallar; después puede renovarse, expirar o reembolsarse. El acceso necesita estados relevantes, procesamiento idempotente y conciliación con el store. El toque inicial no basta.
Prueba restauraciones y cambios de cuenta. Alinea productos, configuración y aplicación. Nunca aceptes un payload arbitrario del cliente como prueba de acceso pagado. Los secretos siguen en el entorno seguro adecuado.
No optimices el indicador equivocado
Más toques pueden acompañar menos compras si el paso siguiente es confuso o falla. Compara el objetivo verificado cuando exista y mantén guardarraíles de uso y fiabilidad.
Si faltan datos de facturación verificados, indícalo. Un test de señal de recorrido responde a una pregunta de interfaz, no demuestra una mejora de ingresos. Mantén nombre y fuente visibles en el informe.
Aplica esta frontera en Aplyna
El inicio de prueba documentado del SDK no es una compra verificada. Una vista previa de paywall muestra diseño, no facturación completada. Test Store prueba catálogo sin validar compras ni conceder derechos sandbox.
Antes de producción, verifica proveedor, rutas compatibles y ciclo completo de la app destino. Un diseño o una clave SDK no prueban preparación de compras. Ajusta las afirmaciones a la evidencia real.
Fuentes y lecturas
Las referencias técnicas pueden estar en inglés. Los ejemplos son educativos; el producto sigue los SDK fuente y las capacidades documentadas actuales. No se atribuyen resultados de clientes.
Publicado por Aplyna. Las ilustraciones editoriales se generaron con IA; no son capturas del producto. Los gráficos muestran ejemplos educativos o diagramas expresamente identificados.