27 · Estrategia del Piloto — cohortes, invitaciones y análisis de feedback
Objetivo: convertir TestFlight (y luego Play) en un piloto medible que alimente el go-to-market: quién activa mejor, qué mensaje convierte, qué duele en el producto — por segmento, no en bruto.
1 · Cohortes
| Cohorte |
Quién |
Canal |
Tamaño |
founders |
Las 4 fundadoras/equipo |
TestFlight Internal (sin revisión) |
4 |
advisory |
Advisory board y personas de confianza |
TestFlight External grupo "Advisory" |
5–15 |
wave-1 |
Pre-inscritas waitlist: las más antiguas + origen marketing_site |
External grupo "Wave 1" |
20–30 |
wave-2+ |
Resto de waitlist por orden/origen; ampliable |
External grupos "Wave N" |
30–50/ola |
Regla de oro: cada grupo de TestFlight = una cohorte — así el origen queda trazado de punta a punta. Las olas pequeñas (20-30) permiten corregir producto y mensaje entre ola y ola.
2 · Mecánica de invitación (quién hace qué)
- Proponer — en hub → Pilot (sección 1): filtrar la waitlist (origen, antigüedad, con/sin cuenta) → seleccionar → "Proponer → cohorte". (Alternativa rápida: Juanjo exporta el CSV de waitlist y Engineering prepara el lote propuesto.)
- Validar — founders revisan el lote en la sección 2 y pulsan Aprobar (o descartan personas concretas). Nada sale sin este paso.
- Cargar en TestFlight — botón CSV TestFlight → App Store Connect → NutriSync → TestFlight → grupo externo de la cohorte → Add Testers → Import from CSV. Apple envía las invitaciones. Marcar el lote como invitado en el hub.
- Android (cuando abra Play Console) — botón Copiar emails → Play Console → Closed testing → lista de testers. Misma cohorte, mismo análisis.
- Seguimiento automático — "dentro" (joined) se detecta solo: la invitada creó cuenta en Supabase. Sin trabajo manual.
Notas TestFlight: External requiere Beta App Review la primera vez (~24-48 h, ya en marcha con la build 0.17.3); después, los builds nuevos llegan a los grupos sin nueva revisión salvo cambios grandes. Alternativa por enlace público por grupo (con tope de plazas) si preferís no gestionar emails — pero se pierde el matcheo email↔cohorte, así que mejor CSV.
3 · Análisis del feedback por cohorte
- Canal único: la app (Ajustes → Enviar comentarios) → tabla
feedback → hub → Pilot sección 3, etiquetado por cohorte automáticamente (join por email de invitación).
- Métricas por cohorte (semanal, 15 min): embudo invitadas → dentro (activación) · días con registro/usuaria (hábito) · CAS medio · nº y temática de feedback. Las dos primeras salen del propio panel; CAS/uso se añade al panel en fase 2 si el piloto crece.
- Lectura GTM: si
wave-1 (marketing_site) activa mejor que advisory, el mensaje de la web funciona; si nadie pasa del onboarding en una cohorte, el problema es producto, no canal. Cada ola ajusta una sola variable (mensaje de invitación, idioma, timing) para poder atribuir.
- Ritual: revisión semanal founders con el panel → 3 decisiones máximo → se ejecutan antes de la ola siguiente.
4 · Estado técnico
- SQL:
2026-07-30-pilot.sql (tabla pilot_invites + 4 RPCs admin-gated; PII solo tras login de founder). Pendiente de aplicar en Supabase.
- Hub: página Pilot (card en Builders + pestaña 🚀) — po28.
- Privacidad: los emails jamás salen del circuito admin; Engineering no los ve salvo que un admin los exporte deliberadamente.