Overview
Actividad en vivo
Cuánta gente está usando la app. Cuenta personas distintas que generaron alguna acción en cada ventana de tiempo (alguien con la app abierta pero quieto no se cuenta). Se actualiza cada vez que recargás esta pantalla.
Usuarios recurrentes
Cuánta gente vuelve. WAU/MAU = usuarios distintos en la última semana / último mes. Stickiness mide qué tan "pegajosa" es la app.
Distribución de tiers
Top 10 grupos por actividad (30d)
| Grupo | Tier | Miembros | Partidos 30d | Eventos 30d | Usuarios activos 30d | Último partido |
|---|
Cuándo se usa la app (día × hora, 30d)
Cada celda = usuarios únicos en esa franja. Más oscuro = más actividad.
Grupos
Vista 360 de cada grupo: cómo se usa (miembros, partidos, activos 30d) y su estado comercial (plan, estado de la suscripción, próximo cobro). Miembros = inscriptos al grupo; Activos 30d = personas distintas que realmente usaron el grupo en el último mes (el número que importa para saber si está vivo). Clickeá una fila para ver el plantel del grupo.
| Nombre | País | Plan | Estado sub | Miembros | Activos 30d | Partidos | Último partido | 30d | Vence / cobra | Creado | Wrapped |
|---|
Usuarios
| Nickname | Crack | Grupos | Partidos | Registrado |
|---|
Onboarding
Cracks más elegidos
Ranking de ídolos que los usuarios eligen al crear su cuenta. Útil para mejorar el onboarding: priorizar los más populares, detectar nichos y decidir qué cracks agregar al catálogo.
Ranking completo (top 50)
| # | Foto | Crack | Nombre real | Pos | Elegido por | % del total | Distribución |
|---|
¿De dónde llega la gente?
Canal de origen (UTM del QR de las canchas, IG, SEO, placas) y qué hizo cada canal: visita → sesión de Partido Rápido → registro → grupo creado. GA4 ve las visitas pero no sabe si terminan en un grupo; ese join se hace acá. La columna Pieza (utm_content) distingue material dentro de una misma campaña — por ejemplo qué complejo de canchas trajo grupos. (directo) junta lo que llega sin UTM ni referrer externo e incluye todo lo previo a la instrumentación, así que las primeras semanas está inflado. Se parte en registrados (visita/quick con sesión de una cuenta ya creada; grupo cuyo creador tiene cuenta de más de 30 días) y nuevos (sin sesión o anónimos, todos los registros, y grupos de cuentas recientes). Últimos 30 días.
Click en una fila de la tabla para ver solo ese canal (click de nuevo para volver a todos).
Adopción de Features
¿Se valora el relato IA?
De los relatos en audio generados, cuántos se escuchan dentro de la app (≥15s de reproducción), oyentes únicos y reproducciones (últimos 90 días). No mide el MP3 compartido a WhatsApp. Requiere v604 deployada + ADMIN_API_KEY.
¿Se usa el Partido Rápido?
Modo sin cuenta: sesiones anónimas iniciadas y el embudo hasta generar y confirmar equipos (últimos 90 días). Los anónimos cuentan como usuarios. Requiere la feature + migración 079 deployadas.
¿Funciona el loop viral?
¿Las placas salen del grupo y engendran grupos nuevos? Shares generados (denominador), aperturas de la landing (numerador; incluye crawler de WhatsApp → direccional, puede pasar 100%) y el K que importa: grupos creados con source_ref (atribuidos a una placa). Últimos 30 días. Cobertura tanda 1: alineación, cards, fut-card.
Anuncios
Modal de inicio cargable desde acá. Se crea siempre como borrador: se ve en el preview de la derecha (mismo CSS y mismo render que la app) y recién con Publicar sale a producción. Se muestra una sola vez por usuario salvo que elijas repetirlo cada N días; "Volver a mostrar a todos" bumpea la revisión y reinicia las métricas.
utm_source=fulbito_app,
utm_medium=anuncio y utm_content con la plataforma,
sólo a links de fulbito.futbol. Vacío = usa la key.
Eventos
Resumen de eventos trackeados en el período seleccionado.
| Evento | Eventos | Usuarios únicos | Eventos/usuario |
|---|
Dispositivos
Modo de uso (último ping del frontend)
Reportado por la app en cada visita (throttle de 24h por dispositivo). Distingue browser de PWA instalada.
Push notifications activadas
Deducido de los tokens de push. Un usuario puede tener ambos (instaló la app web y la nativa, o tiene varios browsers).
Usuarios por dispositivo
Detalle por usuario: el "modo" es el último ping reportado por el frontend. "Web" cuenta suscripciones VAPID (browser/PWA con push); "FCM" cuenta tokens nativos de Android.
| Nickname | Modo | Web subs | FCM tokens | Último ping |
|---|
Fusiones & Stickers
Jugadores que han usado o tienen fusiones/stickers con cracks. Podés resetear cada cosa por separado para que vuelvan a tener intentos gratis.
| Jugador | Grupos | Foto activa | Merges | Pagados | Disp. | Stickers | Disp. | Última fusión | Acciones |
|---|
Errores
Errores del servidor y cliente agrupados por patrón. Click en un grupo para ver los detalles individuales.
Agrupados por patrón
| Endpoint | Mensaje | Scope | Count | Usuarios | Última vez |
|---|
Android vitals
Crashes y ANR de la app nativa, desde la Play Developer Reporting API. Son los errores que la vista Errores no ve: cuando la app nativa se cae, el proceso muere antes de poder reportar. Las tasas son por hora y Google sólo las publica cuando la hora junta ~10 usuarios (en la práctica, las horas de partido); llegan con unas horas de demora. Los errores no tienen ese umbral.
Por versión
| versionCode | Horas con datos | Usuarios·hora | Crash rate | Crash percibido | ANR percibido |
|---|
Errores (últimos 7 días)
| Tipo | Método | Excepción | Versiones | Reportes | Usuarios | Último |
|---|
Balance de Equipos
Análisis de qué tan parejos están los partidos generados por el matchmaker.
¿Se usa el matchmaker? — canario M5
Si los grupos arman con la app (vs. dividir a dedo), cuánto editan el armado propuesto (swaps) y el embudo invitado→cuenta. Requiere v579 deployada + ADMIN_API_KEY.
¿Se evalúan entre pares? — insumo del prior
Las evaluaciones de compañeros (peer_ratings, ocultas entre jugadores) alimentan el
prior del matchmaker: prior = (1−α)·autoeval + α·pares con
α = n/(n+kPeer). Si nadie evalúa, el prior es autoevaluación pura y el armado
arranca ciego. Un solo evaluador no es evaluación de pares — es el admin
rankeando al plantel, por eso el corte es por cantidad de raters, no de filas.
Solo grupos de 8+ miembros.
Partidos
Jugados en los últimos 7 días
Todos los grupos. Mismas columnas de proceso que la tabla por grupo, para ver de un vistazo qué quedó a medias esta semana. Clickeá una fila para el detalle.
| Grupo | Fecha | Partido | Resultado | Vot. cerrada | MVP | Rústico | Morfón | Caudillo | Goleadores | Resumen IA | Relato | Push |
|---|
Por grupo
Estado de los procesos automáticos por partido de un grupo.
| ID | Fecha | Partido | Resultado | Vot. cerrada | MVP | Rústico | Morfón | Caudillo | Goleadores | Resumen IA | Relato | Push |
|---|
Retención por cohorte
Cada fila = semana de signup. Cada columna (W0..WN) = cuántas semanas después del registro. El valor es el % de la cohorte que tuvo al menos un evento en esa semana. Más oscuro = mejor retención.
Fulbito Wrapped
Resúmenes semestrales por grupo. Eliminar un resumen reabre la temporada para que el admin del grupo lo pueda regenerar.
| Grupo | Temporada | Tipo | Inicio | Fin | Cerrada | Resumen | Generado | Acciones |
|---|
Matchmaker — Sandbox
Simulá el armado de equipos con pesos custom. Pegá la lista de WhatsApp, parseala contra los miembros del grupo y tuneá los pesos. No persiste nada — es sandbox.
¿Cómo funciona cada parámetro?
Autoevaluación — multiplica la "base" del jugador (fitness + técnica) antes de sumar el rating efectivo. En v2 la base ya es bayesiana, así que este peso multiplica el resultado del mix prior↔evidence. Ojo con el nombre: el slider multiplica la base entera, y esa base ya no es solo autoeval (ver Prior más abajo).
Forma actual (4w) — bonus por desempeño reciente (MVPs / Caudillo / Rústico / goles de los últimos 4 weeks + racha de victorias). Aplica en v1 y en v2 igual: se suma encima de la base con su propio peso. Si lo ponés a 0, ignorás la forma reciente.
v2 — Bayesiano: el "skill base" del jugador no es solo lo que él se autoevaluó. Son dos mezclas encadenadas:
prior = (1 − α) · autoeval + α · evaluación de pares
base = (1 − trust) · prior + trust · evidence
- Prior: fitness + técnica, pero no solo los que el jugador se puso. Es la autoevaluación mezclada con el promedio de las evaluaciones que le pusieron sus compañeros (tabla
peer_ratings, ocultas: nadie ve las notas ajenas), conα = n / (n + kPeer)donden= cuántos lo evaluaron. Sin evaluadores → 100% autoeval. Invitados del grupo: no tienen autoevaluación, así que su prior es 100% las evals de pares (lo que cargó su creador + los compañeros) → α = 1. - Evidence: "rating revelado" por el histórico — votos MVP recibidos, Caudillo, Rústico (penaliza), win rate y goles+asist por partido. Todos ponderados con decay exponencial (los partidos viejos pesan menos). Calibrado al promedio del grupo: si jugaste como el promedio, evidence ≈ prior y tu base no cambia. Si jugaste mejor, sube; si peor, baja. Cero penalidad por jugar. Las evals de pares NO entran acá — solo al prior.
- Trust: cuánta confianza tener en el evidence. Empieza en 0 (jugador sin partidos = 100% prior) y crece con cada partido jugado, pero está capeado en 0.50 (
trustMax, hardcodeado en producción). O sea: el prior siempre conserva al menos la mitad del peso, por más partidos que se jueguen. Es un hedge contra evidence sucia (votos sociales, datos cargados a medias).
K (smoothing) — cuánto "se resiste" el prior. La fórmula es trust = min(N_eff / (N_eff + K), 0.50). Con K=35 → a 35 partidos efectivos la fórmula natural daría 0.5, que es justo el techo: de ahí en adelante sumar partidos ya no mueve el trust. K más alto = el bayesiano confía más en el prior, K bajo = el histórico llega al techo antes.
kPeer (smoothing de pares) — cuánto "se resiste" la autoevaluación frente a los compañeros, con α = n / (n + kPeer). Con kPeer=3: 1 evaluador pesa 0.25, 2 → 0.40, 3 → 0.50, 9 → 0.75. No tiene techo (a diferencia del trust): con muchos evaluadores la autoeval tiende a desaparecer del prior. kPeer más alto = la autoeval aguanta más; kPeer bajo = un solo compañero ya te reescribe el rating.
Cuánto pesan los pares en el rating final — su peso dentro de la base es α · (1 − trust). Ejemplos con los defaults de producción: 3 evaluadores + jugador nuevo (trust 0) → 50% de la base; 3 evaluadores + veterano (trust 0.5) → 25%; 9 evaluadores + veterano → 37,5%. Sobre el rating efectivo restale ~10% relativo, que se lo lleva el término de forma. Las columnas Ev. y α de la tabla de resultados muestran estos dos números por jugador.
Decay (por día) — cuánto pesa un partido viejo. Con 0.99 un partido de hace 30 días pesa 0.74, de hace 180 días pesa 0.16, de hace 1 año pesa 0.025. Más bajo = más cortoplacista (capta oscilaciones, lesiones, vacaciones). Más alto = más estable, todos los partidos cuentan.
Pesos del evidence — cómo se combinan las señales del histórico para formar el "evidence" final. Rústico se aplica restando, por eso el slider es "Rústico (−)". Win rate usa el sistema de puntos del fútbol: V=3, E=1, D=0 (fórmula (3V+E)/(3·PJ), misma que en badges H2H).
v1 — actual (el del selector de arriba) es autoevaluación pura: ignora por completo las evaluaciones de pares y el histórico. Base = (fitness + técnica)/5 y listo, y los invitados caen todos al promedio del grupo. Está solo para comparar contra v2; producción corre v2.
Pagos
Mercado Pago (PWA) + Google Play Billing (Android). Toggle de feature flags, métricas y log de transacciones.
Feature flags
| Key | Descripción | Pública | Estado |
|---|
Totales
Por rail
| Rail | Estado | Cantidad | Recaudación (ARS) |
|---|
Transacciones
| Fecha | Player | Plan | Rail | Plataforma | Monto | Estado | IDs externos |
|---|
Planes (pricing)
Cambios solo aplican a contrataciones nuevas. Las suscripciones activas mantienen su precio original.
| Code | Nombre | Mensual ARS | Anual ARS | Mensual USD | Anual USD | Activo | Acciones |
|---|
Suscripciones por grupo
| Grupo | Tier | Plan | Estado | Provider | Inicio | Vence / cobra | Contractor | Acciones |
|---|
Negocio
La salud comercial de un vistazo: cuánto entra de forma recurrente, cuántos grupos pagan, y cuántos entran/salen por mes.
Ingreso recurrente
Conversión y flujo
Estado de los grupos
Grupos en riesgo
Grupos a los que conviene prestarles atención antes de que se vayan: dejaron de jugar tras venir activos, tienen un cobro pendiente, o se les vence la sub/prueba en ≤7 días. Ordenados por urgencia.
| Grupo | Plan | Estado sub | Último partido | Motivo |
|---|
Costos
Cuánto cuesta operar Fulbito: costos variables de IA (resúmenes, relatos, fusiones, stickers, crónicas) calculados desde el uso real, más los costos fijos (suscripciones e infra) que cargás a mano. Todo consolidado contra el MRR para ver si el negocio da positivo.
Consolidado mensual
Costos variables — IA por uso
Unidades generadas en el período elegido × costo unitario. Elegí un mes calendario en el selector para analizar ese mes puntual. El TTS de los relatos usa el costo real guardado al generar cada audio; el resto son estimaciones (ajustables por env COST_*_USD en el container admin).
| Concepto | Unidades | Costo unitario (USD) | Total (USD) | Nota |
|---|
Evolución mes a mes
Totales por mes calendario (últimos 12 meses con actividad). Los fijos se aplican al valor actual mensualizado (la tabla de fijos no guarda histórico). El mes en curso es acumulado parcial.
| Mes | Relatos | Resúmenes | Fusiones | Stickers | Crónicas | Variable | Fijos (act.) | Total (USD) |
|---|
Costos fijos — suscripciones e infra
Lo que pagás todos los meses aunque nadie use la app (ElevenLabs, VPS, dominio…). Editá los montos reales acá — los anuales se prorratean a 1/12 por mes; los únicos no suman al mensual.
| Concepto | Detalle | Monto | Moneda | Periodicidad | ≈ /mes (USD) | Activo | Acciones |
|---|
No medido (menor): Whisper de goles por voz y moderación de testimonios (centavos), APIs gratuitas (Spotify, Strava hoy), comisiones de Mercado Pago / Google Play (se descuentan del ingreso, verlas en Pagos).