Respuesta rápida
Para invitar testers a la prueba cerrada de Google Play (closed testing): abre Testing > Closed testing en Play Console, elige Email list (para grupos fijos) o Google Groups (para grupos flexibles), agrega al menos 12 cuentas de Google y luego copia el enlace de la prueba y compártelo con cada tester. El error más grande: asumir que "correos agregados = testers que califican". Solo cuentan quienes hacen clic en el enlace y Become a tester. Para evitar el reclutamiento y completar con más fiabilidad el ciclo de 14 días, muchos desarrolladores usan un servicio profesional como PrimeTestLab, que aporta 12-25 testers verificados desde $19.99, con la prueba en línea en 4-6 horas.
Si publicas con una cuenta personal de desarrollador nueva, Google Play te exige completar la prueba cerrada antes del acceso a producción. Aquí es donde la mayoría se atasca. Agregan correos. Comparten enlaces. Creen que los testers ya están dentro. Diez días después, el reloj de 14 días se reinicia y no saben qué lo disparó. Esta guía recorre todo el proceso de invitación paso a paso, explica la escalera Invitado vs Aceptó participar vs Instalado vs Activo y lista los cinco disparadores de reinicio que le cuestan semanas a los desarrolladores. Si necesitas testers rápido, PrimeTestLab aporta de 12 a 25 testers verificados desde $19.99, con la prueba que suele arrancar en 4-6 horas.
Tabla de contenidos
Mira el recorrido de configuración de la prueba cerrada
Tour paso a paso de Play Console: canales, listas de testers, enlaces de la prueba y qué enviar a revisión
El embudo de invitación: por qué "12 agregados" casi nunca son "12 que califican"
Esto es lo que realmente pasa entre el momento en que pegas un Gmail en Play Console y el momento en que ese tester cuenta para tu ciclo de 14 días. La mayoría de los que publican por primera vez se detienen en el paso 1, y luego se preguntan por qué Google sigue mostrando "not enough testers".
La cuenta que nadie te da: si quieres 12 testers activos 14 días con outreach aleatorio, normalmente necesitas invitar a 25-30 personas solo para que 12 sobrevivan el ciclo completo. Es la razón principal por la que los desarrolladores se atascan semanas.
El costo real de un reinicio
+14 días
Cada reinicio significa empezar el reloj de 14 días desde el día cero. No hay "crédito" por el tiempo ya cumplido.
Cómo prepararte para la prueba cerrada de Google Play
Esta es la parte que la mayoría de guías se salta. Antes de empezar a hacer clic en Play Console, ten listos estos cinco puntos. Saltar la preparación es la razón más común de que los ciclos se alarguen semanas en vez de cerrar limpios. Incorporamos 7,400+ apps con una secuencia de preparación de cinco pasos, y el orden importa: cada ítem depende del anterior.
Un Android App Bundle (AAB) firmado listo para subir
La prueba cerrada exige un AAB, no un APK. Genéralo en Android Studio con Build > Generate Signed Bundle / APK > Android App Bundle. Si es tu primera subida, acepta Play App Signing cuando Play Console lo pida.
Tip: sube el versionCode al menos 1 por encima de cualquier build de prueba anterior antes de generar el AAB. Reutilizar un versionCode es el error de subida más común.
Tu pool de testers: correos O la dirección de un Google Group
Decide de antemano: ¿subes una lista de Gmails individuales o apuntas Play Console a un Google Group? Si usas un servicio como PrimeTestLab, normalmente solo pegas su dirección oficial de Google Group (p. ej. khadem-testers-service@googlegroups.com) y te saltas la gestión de CSV.
Tip: agrega el pool completo de testers al que tengas acceso, no solo 12. Explicamos por qué en el Paso 2.
La lista completa de países lista para seleccionar (idealmente los 177)
Los países de la prueba cerrada son independientes del lanzamiento en producción. Aunque solo pienses lanzar en un país, selecciona todas las regiones disponibles para que testers de cualquier lugar puedan instalar. Restringir países aquí es una de las causas más comunes de "app not available".
Lo esencial del store listing completado
Antes de que Google apruebe tu versión de prueba cerrada, suele hacer falta: una URL de política de privacidad, un formulario Data safety completo, un cuestionario de content rating y una declaración de público objetivo. Abre Publishing overview y Google te listará lo que aún falta.
Un calendario de recordatorios para los días 2, 7 y 11
Si invitas a amigos, familia o gente que encontraste online, el ciclo muere sin empujones. Programa recordatorios antes de mandar la primera invitación: abajo hay plantillas listas para copiar para cada uno. Si te lo saltas, el conteo activo del día 12 caerá por debajo de 12 sin que lo notes.
El flujo de preparación en 5 pasos
Estos cinco puntos reflejan el onboarding real que hacemos con cada cliente de PrimeTestLab: (1) añadir testers, (2) configurar todos los países, (3) enviar cambios a revisión de Google, (4) compartir el enlace de la prueba en vivo, (5) monitorear y empezar a probar. El orden no es arbitrario. Si te saltas el paso 4 (el enlace en vivo), nuestro equipo no tiene qué verificar. Si te saltas el 2 (países), el 3 falla en revisión.
Paso 1: Configura tu canal de prueba cerrada en Play Console
Antes de invitar a nadie, necesitas un canal de pruebas (también llamado segmento de pruebas en la documentación de LatAm) al que invitarlos. Si ya tienes un canal y una versión activa, salta al Paso 2.
Abre Play Console y selecciona tu app
Ve a play.google.com/console. En la lista de apps, entra a la que quieras poner en prueba cerrada.
Ve a Testing > Closed testing
En la barra lateral izquierda, expande Testing y haz clic en Closed testing. Verás uno o más canales (por defecto "Alpha"). Elige uno o haz clic en Create track para nombrar el tuyo.
Haz clic en "Create new release"
Dentro de tu canal, haz clic en Create new release. Sube tu AAB, escribe notas de la versión (una frase basta) y haz clic en Save.
Tip: si aún no firmaste una upload key, Play Console te guiará por Play App Signing la primera vez que subas. Acepta los valores por defecto salvo que tengas una razón fuerte para gestionar tus propias claves.
Revisa y lanza el rollout
Haz clic en Review release, corrige cualquier advertencia y luego Start rollout to closed testing. La versión quedará en "Pending review" con Google unos 20-30 minutos antes de activarse.
Tip pro
Si tu versión se queda en "Pending review" más de unas horas, casi siempre es porque no terminaste un ítem del store listing (política de privacidad, content rating, público objetivo, data safety). Abre Publishing overview en la barra lateral y Google te mostrará exactamente qué falta.
Si tu canal de prueba cerrada está configurado pero los testers dicen que no ven la app, es un problema aparte (y muy común). Lo cubrimos en detalle en nuestra guía de prueba cerrada que no arranca.
Paso 2: Elige cómo añadir testers: lista de correos vs Google Groups
Google Play te da dos formas de añadir testers a un canal de prueba cerrada. En la práctica se comportan muy distinto. Si eliges mal, vas a gastar una hora extra cada vez que necesites añadir o quitar un tester.
Lista de correos individuales
Mejor para: grupos pequeños y fijos (menos de 20 testers).
- Rápido de montar: pega correos o sube un CSV
- Vive por completo dentro de Play Console
- Editar la lista = volver a subir + guardar de nuevo
- Difícil de gestionar cuando entran y salen testers
- Fácil olvidar el paso de "marcar el checkbox"
Google Groups
Mejor para: testing continuo, grupos más grandes, organizaciones.
- Añade o quita testers en el Group, sin editar Play Console
- Un solo enlace de la prueba sirve para siempre
- Mejor historial: ves quién se unió y cuándo
- Hay que crear un Group en groups.google.com primero
- Los miembros deben poder ver contenido + miembros externos
Método 1: lista de correos individuales, paso a paso
- Dentro de tu canal de prueba cerrada, haz clic en Testers.
- Elige Create email list, dale un nombre (p. ej. "Beta Cohort 1").
- Pega correos uno por línea, o sube un CSV.
- Haz clic en Save changes.
- Marca el checkbox junto a tu lista en la página Testers. Es el paso que todos se saltan.
- Haz clic en Save otra vez al final de la página.
Crítico
Subir un CSV crea la lista. Marcar el checkbox la vincula al canal. Son dos operaciones distintas. Si te saltas la segunda, tu lista es invisible para la versión.
No agregues solo 12
Si tienes un pool más grande de correos de testers (por ejemplo, el CSV completo de un servicio de testing), súbelos todos, no solo los 12 que crees necesitar. Solo una fracción de cualquier pool acepta participar y se queda activa 14 días. Si subes exactamente 12 y uno se cae el día 6, tu conteo activo baja del umbral y el ciclo puede reiniciarse. Importa siempre la lista completa y deja que la tasa natural de aceptación te deje por encima de 12.
Método 2: Google Groups, paso a paso
- Ve a groups.google.com y haz clic en Create group.
- Pon el tipo de grupo en Email list. Nómbralo (p. ej. "myapp-closed-testers").
- En Group settings > Member privacy, permite External members.
- En Posting policies, permite a los miembros view conversations (o la visibilidad que necesite tu equipo).
- Agrega tus testers iniciales con Members > Add members directly.
- De vuelta en Play Console > Closed testing > Testers, elige Google Groups, pega el correo del grupo y guarda.
Por qué los Groups ganan a largo plazo
Cuando un Google Group está conectado a Play Console, no vuelves a tocar Play Console para gestionar testers. ¿Necesitas cambiar uno? Agrégalo al grupo y quita el anterior. El enlace de la prueba se mantiene, el canal se mantiene y el reloj de 14 días sigue corriendo, siempre que no bajes de 12 testers activos.
Paso 3: Genera y comparte el enlace de la prueba
Este es el paso que la mayoría malinterpreta. Agregar el correo de alguien no basta. Cada tester debe abrir el enlace de la prueba (enlace de invitación), iniciar sesión con su cuenta de Google y hacer clic en "Become a tester". Sin ese clic, está invitado pero no aceptó participar, y no cuenta.
Anatomía de la URL del enlace de la prueba cerrada
Estructura de la URL del enlace de la prueba cerrada
internaltest.
Trampa común
Si tu URL contiene internaltest, copiaste el enlace de la pestaña Internal testing. El tiempo de pruebas internas no cuenta para el requisito de 14 días de acceso a producción. Solo cuentan los enlaces con /apps/testing/.
Estos dos formatos de enlace de prueba cerrada son válidos:
https://play.google.com/apps/testing/com.yourapp.name
https://play.google.com/store/apps/details?id=com.yourapp.name
La URL /apps/testing/ es la landing dedicada para aceptar participar. La de /store/apps/details?id= manda al tester a la Play Store de forma directa, y funciona una vez que ya aceptó con el primer enlace. Al compartir con un servicio de testing, se prefiere el enlace /apps/testing/.
Cómo aceptan participar los testers de verdad
El tester abre el enlace en el teléfono o en el escritorio
La landing del enlace de la prueba debe abrirse en el navegador, no dentro de la app de Play Store. El navegador del móvil está bien.
Inicia sesión con la cuenta de Google con la que lo invitaste
La cuenta con la que entra debe coincidir con el correo de tu lista de testers (o estar en tu Google Group). Cuentas distintas no pueden aceptar participar.
Hace clic en "Become a tester"
Este es el paso que lo pasa de invitado a aceptó participar. Luego la página muestra un enlace de instalación de Play Store.
Instala la app desde el enlace de Play Store
El enlace de Play Store está ligado a la cuenta. Si lo abre en un teléfono con otra cuenta de Google, verá "App not available". Debe abrir Play Store con la misma cuenta con la que aceptó participar.
¿Testers reportan "App not available"?
Si varios testers dicen que la app no está disponible aunque abran el enlace con la cuenta correcta, el problema casi nunca son ellos: es una configuración de Play Console. Las cinco causas más comunes (canal incorrecto, lista sin checkbox, enlace equivocado, restricciones de país, pending review) están en nuestra guía: Por qué tus testers no ven la app de prueba cerrada (5 arreglos).
Cuenta demo y License testing: los dos ajustes que la mayoría de indies se saltan
Aunque tus testers hayan aceptado participar y tengan la app instalada, el ciclo aún puede morirse en silencio. Los dos asesinos silenciosos más comunes: tu app tiene un muro de login y los testers no pasan, o tu app tiene compras in-app y no pueden probar flujos de pago sin que les cobren de verdad. Ambos tienen ajustes dedicados en Play Console que casi nadie completa bien a la primera.
Cuenta demo / App access
Obligatorio si: tu app tiene pantalla de inicio de sesión, contenido restringido o funciones bloqueadas.
- Da al revisor de Google credenciales que funcionan
- Ayuda a los testers a saltar muros solo por invitación o de pago
- Las credenciales DEBEN seguir funcionando los 14 días
- Saltarlas en una app con auth = rechazo casi seguro de Google
License testing
Obligatorio si: tu app tiene compras in-app, suscripciones o funciones de pago.
- Permite a Gmails concretos probar compras sin cobro real
- Devuelve respuestas simuladas de éxito o rechazo
- Solo las cuentas de esta lista entran en modo test: el resto paga de verdad
- Si lo olvidas, los testers se negarán a probar funciones de pago
Ajuste 1: cuenta demo (App content > App access)
Si un revisor de Google o uno de tus testers abre la app y se topa con un login, necesita credenciales. Play Console tiene un campo dedicado llamado App access. Completarlo no es negociable en apps con muro de auth.
Abre App content > App access
En la barra lateral de Play Console, ve a Policy > App content y haz clic en App access.
Elige "All or some functionality is restricted"
Si tu app tiene contenido bloqueado, elige esa opción. Si no, el formulario se queda en "All functionality is available without restrictions" y no puedes agregar credenciales.
Haz clic en "Add new instructions"
Completa: Name (p. ej. "Demo login"), Username, Password e Instructions explicando cómo usar la cuenta demo. Indica qué funciones desbloquea.
Guarda y envía a revisión
Este cambio debe pasar por Publishing overview > Send changes for review, como cualquier otro cambio de Play Console.
Plantilla de instrucciones de cuenta demo (pegar en App access)
Los errores más comunes de cuenta demo
(1) Poner un placeholder tipo "test/test" que no inicia sesión de verdad. (2) Activar 2FA en la cuenta demo y bloquear al revisor en el OTP. (3) Dejar que la cuenta demo caduque a mitad del ciclo. (4) No especificar qué funciones desbloquea la demo: el revisor no adivina. Los cuatro llevan al rechazo de la prueba cerrada.
Ajuste 2: License testing (Settings > License testing)
Si tu app tiene algún producto de pago (IAP de un solo pago, suscripciones, consumibles, cualquier cosa que toque Google Play Billing), tus testers no van a probar esos flujos sin protección frente a cobros reales. La solución de Google es License testing: una lista de Gmails que reciben respuestas de sandbox en las llamadas de billing en vez de transacciones reales.
Abre Setup > License testing
En la barra lateral de Play Console (no dentro de la app: es a nivel de cuenta), ve a Setup > License testing.
Agrega los Gmail de cada tester
Pega las mismas cuentas de Gmail que añadiste al canal de prueba cerrada. Cada una debe estar aquí por separado: estar solo en la lista de testers no basta.
Tip: si usas un servicio como PrimeTestLab, tu panel te da la misma lista de correos de testers para ambos usos: puedes reutilizar el CSV para License testing.
Elige la respuesta de licencia
Elige RESPOND_NORMALLY para un testing realista. Otras opciones como LICENSED o NOT_LICENSED fuerzan una respuesta concreta y sirven para verificar rutas de error.
Guarda: no hace falta revisión de Google
Los cambios de License testing aplican de inmediato. A diferencia de la mayoría de ajustes de Play Console, NO necesitas enviarlos por Publishing overview.
Cuándo necesitas cada ajuste
| Tu app tiene... | Cuenta demo | License testing |
|---|---|---|
| Muro de login / registro | Obligatorio | No hace falta |
| Compras in-app | Si hay muro | Obligatorio |
| Suscripciones | Si hay muro | Obligatorio |
| Gratis, abierta, sin IAP | No hace falta | No hace falta |
| Login + IAP juntos | Obligatorio | Obligatorio |
Por qué esto se conecta con el riesgo de reinicio
Los testers bloqueados en un login abren la app cada vez menos, luego se olvidan y desinstalan. A los que les pides pagar de verdad por probar una suscripción no la prueban, y a veces dejan de participar del todo. Ambas situaciones erosionan en silencio tu conteo de testers activos durante los 14 días. La mayoría de historias de "el ciclo se reinició y no sé por qué" terminan en credenciales demo faltantes o cuentas de License testing ausentes.
Para un análisis más profundo de por qué los testers se van a mitad del ciclo y cómo mantenerlos, ve nuestra guía sobre por qué necesitas más de 12 testers.
La escalera de estados: invitado vs aceptó participar vs instalado vs activo
Este es el modelo mental más importante de toda la guía. El requisito de 12 testers de Google no es "12 invitados" ni siquiera "12 instalados". Es "12 testers que hayan aceptado participar y mantengan la app activa 14 días de forma continua". Cada peldaño es un filtro aparte que baja tu conteo real.
-
Invitado
1. Invitado
Agregaste el correo a tu lista de testers (o Google Group). El tester todavía no se enteró.
¿Cuenta para los 12 de Google? No
-
Aceptó
2. Aceptó participar
El tester abrió el enlace, inició sesión y pulsó "Become a tester". Ahora es un tester confirmado en los registros de Google.
¿Cuenta para los 12 de Google? Sí, desde el momento en que acepta participar
-
Instalado
3. Instalado
La app está descargada y presente en un dispositivo real bajo esa cuenta de Google. Hace falta para cualquier señal de tester que Google vea.
¿Cuenta para los 12 de Google? Sí, y Google empieza a registrar actividad
-
Activo 14d
4. Activo 14 días de forma continua
El tester mantuvo la app instalada y la cuenta con participación aceptada los 14 días consecutivos sin interrupción. Es el único estado que completa el requisito.
¿Cuenta para el acceso a producción? Sí: esta es la meta final
El ciclo empieza cuando
Tu ciclo de 14 días empieza en el momento en que tienes al menos 12 testers que hayan aceptado participar por completo Y la app está disponible en el canal cerrado. Si un tester se cae y tu conteo activo baja de 12 aunque sea un instante, Google puede reiniciar el ciclo. Por eso un colchón de 20-25 testers es la recomendación estándar.
Los 5 errores que reinician tu reloj de 14 días
Ahora la parte dolorosa. Abajo están los cinco disparadores de reinicio que vemos cada semana. Cada uno le ha costado a algún desarrollador dos semanas limpias de progreso. Memorízalos y luego corre el checklist previo al envío antes de decirle a nadie que la prueba ya empezó.
Antes de asumir un reinicio: una parte de los reportes de "mi ciclo de 14 días se reinició" en realidad son "el ciclo nunca arrancó", porque la configuración de Play Console nunca estuvo del todo bien. Si sospechas eso, pasa primero por nuestra guía de prueba cerrada que no arranca para confirmar que el ciclo estaba vivo antes de buscar causas de reinicio.
Quitar y volver a añadir testers a mitad del ciclo
Aunque el número de testers se mantenga, quitar a cualquiera se trata como un cambio de lista. Google puede reiniciar la ventana de 14 días de forma continua.
Arreglo: cierra tu lista de testers antes del día 1. Bloquéala.
Testers que dejan de participar o desinstalan
Si un tester hace clic en "Leave testing program", desinstala la app o cambia a otra cuenta de Google, tu conteo activo baja. Si caes por debajo de 12, el reloj puede reiniciarse.
Arreglo: comunícalo claro desde el inicio: "no desinstales durante 14 días". Y mantén un colchón por encima de 12.
Cambiar o borrar el canal de prueba cerrada
Mover la versión entre Internal, Closed y Open, o borrar el canal cerrado y crearlo de nuevo, reinicia todo el progreso.
Arreglo: crea un canal cerrado y déjalo quieto 14 días. Internal puede correr en paralelo; solo no reemplaces closed.
Reemplazar correos de testers a mitad del ciclo
Agregar testers nuevos en general está bien. Reemplazar correos existentes (borrar + agregar) a menudo cuenta como edición de lista y puede reiniciar la ventana de cumplimiento.
Arreglo: solo agrega, nunca borres, entre el día 1 y el 14.
Tratar "12 agregados" como "12 que califican"
Google exige 12 testers que hayan aceptado participar, instalados y activos durante los 14 días completos. Doce nombres en una lista no hacen nada. Es el asesino silencioso que manda a la mayoría al segundo ciclo sin darse cuenta de que el primero nunca arrancó.
Arreglo: verifica a diario el conteo de quienes aceptaron participar dentro de Play Console. Si está por debajo de 12, no estás en el reloj.
El mapa de riesgo de 14 días: cuándo pega cada disparador de reinicio
Los reinicios no se reparten igual en los 14 días. El riesgo de abandono tiene dos picos: temprano (días 2-4, cuando se va la curiosidad) y tarde (días 11-13, cuando los testers piensan "esto ya está casi listo"). Saberlo cambia cuándo les recuerdas que dejen la app instalada.
Riesgo de abandono por día
Cuándo enviar recordatorios a los testers
- Recordatorio día 2: "Chequeo rápido: ¿la app sigue instalada? No te preocupes, no tienes que usarla: solo déjala en el dispositivo."
- Recordatorio día 7: "Vamos a la mitad. La ventana de 14 días termina el [fecha exacta]."
- Recordatorio día 11: "Casi listo: quedan 3 días. Este es el tramo más crítico. Por favor no desinstales todavía."
- Día 14: mensaje de espera: "Ciclo completo, pero Google aún debe aprobar el acceso a producción. Por favor mantén la app instalada hasta que te confirme."
- Después de la aprobación de producción: "Google aprobó la app. Ya puedes desinstalar con tranquilidad. ¡Gracias!"
Cómo seguir el progreso en Play Console
Play Console te da una vista en vivo del conteo de testers que aceptaron participar y del engagement en tu canal cerrado. Revísala a diario durante la ventana de 14 días para detectar abandonos antes de que hundan el ciclo.
Plantillas listas para copiar de invitación a testers
El predictor más fuerte de la tasa de aceptación es la calidad del mensaje que envías. Un mensaje de dos líneas tipo "por favor haz clic e instala" convierte tal vez al 30%. Las plantillas de abajo se acercan al 70-80% porque explican qué debe hacer el tester, por qué te importa y exactamente cuánto tiempo debe dejar la app instalada.
Mensaje de invitación inicial
Recordatorio día 2 (evitar abandono temprano)
Recordatorio día 11 (recta final)
Crítico: no mandes todavía el mensaje de "ya puedes desinstalar"
Llegar al día 14 de la prueba cerrada no significa que ya tengas acceso a producción. Google todavía debe aprobar tu solicitud de acceso a producción después de que completes el cuestionario. Si les dices a los testers que desinstalen el día 14 y Google revisa tu conteo activo durante su revisión (cosa que hace a menudo), tu app puede ser rechazada por "not enough active testers" y empiezas un ciclo nuevo de 14 días. Mantén a tus testers instalados hasta que Google otorgue el acceso a producción de forma explícita, normalmente 1 a 7 días después de enviar el cuestionario. Usa la plantilla del día 14 de abajo para pedirles que esperen; usa la de producción aprobada solo DESPUÉS de la luz verde de Google.
Día 14: mensaje de espera (ciclo completo, esperando a Google)
Después de la aprobación de producción: ya se puede desinstalar
Calculadora de preparación de testers: puntúa tu setup en 60 segundos
Ahora que leíste la preparación, los métodos y los errores de reinicio, contrasta tu propio setup. Responde las cinco preguntas de abajo y obtendrás un puntaje real de riesgo que te dice si tu prueba cerrada está lista de verdad, o si un ajuste que te faltó te va a costar 14 días.
Calculadora de preparación de testers
5 preguntas, ~60 segundos. Devuelve tu puntaje real de riesgo de reinicio.
Riesgo bajo
Puntaje: 0 / 130
Problemas a corregir antes de invitar testers
Checklist previo al envío antes de pulsar Send
Recorre este checklist antes de mandar invitaciones. Cada ítem mapea a un modo de fallo de arriba. Si los ocho se marcan, hiciste todo lo que está en tu mano para que el ciclo sobreviva.
Checklist de lanzamiento de 8 puntos
0 de 8 confirmados
Caza DIY de testers vs prueba cerrada estructurada
La mayoría de desarrolladores prueba primero la ruta DIY: hilos de Reddit, grupos de Discord, apps de intercambio de testers, amigos y familia, freelancers al azar. Es gratis o barato, pero el costo oculto es el tiempo. Abajo se comparan los dos enfoques en las métricas que de verdad importan para completar el ciclo de un tirón.
| Lo que te importa | DIY (Reddit, amigos) | Servicio estructurado |
|---|---|---|
| Tiempo hasta 12 con participación aceptada | 1-3 semanas | 4-6 horas |
| Supervivencia del ciclo al primer intento | ~30% | ~99% |
| Abandono de testers a mitad del ciclo | Común (basado en curiosidad) | Gestionado y monitoreado a diario |
| Calidad de cuentas | Mixta: cuentas dormidas, desajustes | Cuentas de Google verificadas |
| Tiempo total hasta el acceso a producción | A menudo 4-6 semanas | 14-15 días |
| Costo total (incl. tiempo perdido) | Gratis al inicio, caro en retrasos | Desde $19.99, predecible |
Cómo PrimeTestLab gestiona la invitación de testers de punta a punta
Si tu reto real es "no conozco 12+ testers Android dispuestos a dejar una app instalada 14 días", eso es exactamente lo que resuelve PrimeTestLab. Tú compartes el enlace de la prueba cerrada. Nosotros nos encargamos del resto: invitación, verificación de que aceptaron participar, monitoreo diario de engagement, retención de 14 días y seguimiento de finalización. 7,400+ apps y contando.
Qué recibes de verdad después de pedir el servicio
Cuando haces un pedido, tu panel te guía por cinco pasos alineados con la estructura de este artículo. Te damos todo lo necesario para saltarte la fase de "buscar testers":
Una dirección de Google Group lista para pegar
Sáltate la gestión de CSV. Agrega nuestro Google Group oficial a tu canal de prueba cerrada y cada tester queda incluido de forma automática:
khadem-testers-service@googlegroups.com
Importante: agrega nuestro Google Group a tu canal de prueba cerrada. No pegues correos individuales de testers en tu propio Google Group: eso no se conecta a nuestro pool.
O un CSV descargable con el pool completo de testers
Si prefieres el método de lista de correos, tu panel tiene descarga en un clic de un CSV con todo el pool de testers (no solo 12). Súbelo a Closed testing > Testers > Create email list, marca el checkbox y guarda.
Monitoreo horario de estado + arranque típico en 1-2 horas
Cuando tu canal de prueba cerrada está en vivo y aprobado por Google, nuestro equipo revisa la disponibilidad de la app cada hora. En el momento en que la app es descargable, nuestros testers empiezan a aceptar participar, normalmente en 1 a 2 horas tras la aprobación de Google. No tienes que avisarnos, refrescar nada ni perseguir el estado. En el flujo general, la prueba suele estar en línea en 4-6 horas desde que el canal está listo.
Retención día a día + prevención de abandono
Nuestros testers no solo aceptan participar y desaparecen. Monitoreamos los conteos activos a diario para que te mantengas por encima del umbral de 12 testers los 14 días completos, aunque haya abandono natural. Por eso nuestra tasa de éxito es 99.9% en el primer intento frente a ~30% en la caza DIY típica de testers.
Paquetes actuales
Starter
12 testers
$19.99
Enterprise
25 testers
$27.99
Professional
20 testers
$29.99
Enlaces útiles
Preguntas frecuentes
¿Necesito 12 testers para la prueba cerrada de Google Play?
Sí. Para cuentas personales de desarrollador nuevas, Google exige al menos 12 testers que completen un ciclo de prueba cerrada de 14 días de forma continua antes de solicitar acceso a producción. Los 12 deben haber aceptado participar, instalado la app y permanecer activos los 14 días completos, no solo estar en tu lista de correos. En la documentación oficial de Google en español, a los testers también se les llama verificadores.
¿Puedo invitar testers sin cuentas de Gmail?
No. La prueba cerrada requiere cuentas de Google. Cualquier correo usado para testing debe ser una cuenta de Google (Gmail o Google Workspace). Los correos que no son de Google no podrán aceptar participar ni instalar tu app desde el canal de prueba cerrada.
¿Cuál es la diferencia entre testers invitados y los que aceptaron participar?
Invitado significa que el correo se agregó a tu lista de testers en Play Console. Aceptó participar significa que el tester abrió el enlace de la prueba, inició sesión y hizo clic en Become a tester. Solo quienes aceptaron participar cuentan para el requisito de 12 testers de Google. Un invitado que no aceptó no aporta nada.
¿Qué reinicia el reloj de 14 días de la prueba cerrada?
Cinco cosas suelen reiniciar o invalidar el ciclo: quitar testers a mitad del ciclo, que los testers dejen de participar o desinstalen, reemplazar correos en tu lista, cambiar o borrar el canal de prueba cerrada, y bajar de 12 testers activos que hayan aceptado participar en cualquier momento de los 14 días.
¿Debo usar una lista de correos o un Google Group para la prueba cerrada?
Usa una lista de correos para grupos pequeños y fijos (menos de 20 testers). Usa un Google Group cuando necesites gestionar testers en un solo lugar sin volver a subir la lista a Play Console: solo agregas o quitas personas dentro del grupo. Google Groups se recomienda para programas de testing continuos.
¿Puedo ejecutar pruebas internas junto con la prueba cerrada?
Sí: las pruebas internas y la prueba cerrada pueden correr en paralelo sin afectarse. Pero el tiempo de pruebas internas NO cuenta para el requisito de 14 días de forma continua hacia el acceso a producción en cuentas personales. Solo cuenta el tiempo en la prueba cerrada.
¿Necesito una cuenta demo para la prueba cerrada?
Sí, si tu app tiene pantalla de inicio de sesión o funciones restringidas. Agrega credenciales demo en Play Console en Policy > App content > App access. Da un usuario y contraseña que funcionen, más instrucciones sobre qué desbloquea la cuenta demo. Sin eso, tanto el revisor de Google como tus testers pueden quedar bloqueados y el ciclo se cae en silencio.
¿Cómo dejo que los testers prueben compras in-app sin que les cobren?
Agrega sus correos de Gmail en Play Console en Setup > License testing. Las cuentas de esa lista reciben respuestas de sandbox para las llamadas de Google Play Billing en lugar de cobros reales. El cambio aplica de inmediato, sin revisión de Google. Si lo olvidas, los testers se negarán a probar funciones de pago (con razón).
¿Puedo saltarme la prueba cerrada en una cuenta personal?
No. Las cuentas personales de desarrollador (creadas después del cambio de política de Google de 2023) deben completar el ciclo de prueba cerrada de 14 días con al menos 12 testers activos antes de solicitar acceso a producción. Las cuentas de organización tienen reglas distintas y a veces pueden omitir el requisito.
¿Qué tan rápido puede PrimeTestLab aportar testers?
Cuando tu canal de prueba cerrada está activo y accesible, los testers de PrimeTestLab suelen empezar a aceptar participar en 4-6 horas. Los precios empiezan en $19.99 por 12 testers. Ofrecemos repetición gratis o reembolso completo si no se aprueba.
Conclusión
Resumen
La prueba cerrada no es técnicamente difícil, pero es sensible en lo operativo. Invitar testers significa: (1) crear un canal cerrado con una versión activa, (2) añadir testers con lista de correos o Google Groups, (3) compartir el enlace de la prueba y verificar que cada uno acepte participar, y (4) proteger el ciclo de 14 días de los 5 disparadores de reinicio, sobre todo cambios a mitad del ciclo y bajar de 12 testers activos. La diferencia entre invitado, aceptó participar, instalado y activo 14 días es lo que decide si pasas a producción o reinicias el reloj. Si prefieres no perseguir testers a mano, PrimeTestLab aporta de 12 a 25 testers verificados desde $19.99, con la prueba que suele arrancar en 4-6 horas. Ver planes de precios →