Producto independiente · Analítica de datos · Videojuegos
DBD Comp Hub
Hacer medible la escena competitiva de Dead by Daylight.
Una plataforma de analítica independiente que recopila datos de audiencia de Twitch, identifica transmisiones y eventos competitivos, y construye una visión histórica de una comunidad de videojuegos en evolución.
- Rol
- Concepto de producto, diseño UX/UI y desarrollo full stack
- Estado
- Independiente · en evolución
- Next.js
- React
- TypeScript
- PostgreSQL
- Supabase
- Drizzle ORM
- Tailwind CSS
El contexto
La escena competitiva de Dead by Daylight se ha convertido en una comunidad de jugadores, equipos, organizadores y espectadores.
Las estadísticas de categoría de Twitch agrupan transmisiones competitivas y casuales, así que la audiencia de la escena es difícil de aislar.
El proyecto nació de la curiosidad por esa audiencia, con la intención de responder estas preguntas con datos observables y no con impresiones.
El desafío
El problema central no era mostrar estadísticas. Era construir un sistema capaz de distinguir transmisiones competitivas dentro de una misma categoría de Twitch, y conservar suficiente historial para estudiar cómo cambia esa audiencia.
Preguntas que responde el producto
- ¿Cuánta audiencia mira contenido competitivo?
- ¿Qué proporción representa dentro de la audiencia total de Dead by Daylight?
- ¿Cómo cambia esa proporción con el tiempo?
- ¿Qué eventos y creadores concentran la mayor actividad?
Desafíos técnicos
- Recopilar datos de transmisiones de forma periódica desde una API externa con límites de tasa.
- Identificar transmisiones competitivas a partir de señales imperfectas, como títulos, etiquetas de canal y listas curadas.
- Mantener bajos los falsos positivos y los falsos negativos, y hacer revisables los casos ambiguos.
- Guardar historial para poder comparar datos temporales entre períodos.
- Relacionar transmisiones con posibles eventos competitivos sin tratar cada coincidencia como un torneo.
- Presentar estas cifras a lectores no técnicos sin exagerar lo que significan.
La solución
DBD Comp Hub es un conjunto de capacidades conectadas, no un solo gráfico.
Seguimiento de audiencia en vivo
La aplicación consulta la lista de transmisiones de Dead by Daylight en Twitch y guarda snapshots de espectadores totales, competitivos y casuales. La vista en vivo muestra la proporción actual de espectadores competitivos.
Clasificación de transmisiones competitivas
Cada transmisión se clasifica con una prioridad fija. Primero gana la lista de exclusiones, luego los canales competitivos curados y después las señales de título y etiquetas. Cada clasificación registra la regla que la produjo, y las etiquetas de revisión se conservan junto al resultado automático.
Analítica histórica
Los snapshots se guardan en PostgreSQL y se consultan como series temporales. La vista de analítica muestra la proporción competitiva a lo largo del tiempo, los cambios de audiencia y los picos, junto con las transmisiones que los explican.
Candidatos a evento
Las transmisiones que comparten un enfrentamiento, un organizador o un título se agrupan como candidatos a evento. Los candidatos quedan pendientes hasta que un revisor los confirma o los rechaza en el área de administración.
Directorio de streamers
Un directorio de canales vinculados a la escena competitiva facilita encontrar transmisiones competitivas activas.
Metodología transparente
Una página de metodología explica cómo se recopilan y clasifican los datos, qué mide cada métrica y dónde las estimaciones tienen límites.
Arquitectura técnica
El flujo siguiente es el camino de datos implementado, desde la API de Twitch hasta el dashboard.
-
01
API de Twitch
Lista de transmisiones y datos de usuarios, consultados con credenciales de la aplicación.
-
02
Recopilación de datos
Un endpoint protegido por secreto ejecuta la recopilación cada cinco minutos aproximadamente. Las solicitudes pasan por un limitador de tasa con presupuestos por minuto y por hora, y backoff exponencial.
-
03
Reglas de clasificación
Lista de exclusión, luego lista competitiva curada, luego heurísticas de título y etiquetas. Cada resultado guarda la regla y la versión del clasificador.
-
04
Base de datos
PostgreSQL con Drizzle ORM. Transmisiones, snapshots, clasificaciones, etiquetas de revisión, equipos, jugadores y candidatos a evento se guardan en tablas separadas.
-
05
Consultas analíticas
Las consultas construyen series temporales para la proporción en vivo, las tendencias históricas, los picos y el impacto de los eventos. Los valores medidos y las estimaciones derivadas se etiquetan por separado.
-
06
Dashboard en Next.js
Páginas renderizadas en el servidor y rutas de API presentan la vista en vivo, la analítica, los eventos, los streamers, los jugadores, los equipos y la metodología.
Decisiones de ingeniería
Cada decisión implica renunciar a algo a propósito.
Reglas y listas curadas en lugar de una caja negra de IA
Las reglas explícitas hacen trazable cada clasificación. Cuando una transmisión se clasifica mal, puedo ver qué regla la decidió y ajustar esa regla o la lista.
Snapshots periódicos en lugar de valores actuales
Las cifras en vivo cambian constantemente. Capturarlas en intervalos fijos las convierte en una serie que se puede comparar entre períodos, a costa de huecos cuando la recopilación se interrumpe.
Confirmación humana para los eventos
Que un título o un organizador coincida no prueba que un evento haya ocurrido. Los candidatos se agrupan automáticamente, pero una persona los confirma antes de que aparezcan como eventos.
Transparencia antes que precisión aparente
La proporción competitiva cuenta espectadores de transmisiones clasificadas como competitivas. No es una medición directa de jugadores competitivos, y la interfaz lo aclara.
UX/UI: diseño para la claridad
La interfaz convierte un conjunto de datos denso en pocas respuestas legibles.
- El titular responde primero la pregunta principal y luego explica en una línea qué significa "comp".
- Las audiencias total y competitiva se muestran una al lado de la otra con colores distintos, para que la proporción se lea con facilidad.
- Los gráficos temporales muestran por defecto el historial reciente, con controles de rango para períodos más largos.
- Las vistas de eventos y streamers están separadas de la vista en vivo, para que la exploración no compita con las cifras principales.
- Las páginas con datos incompletos o desactualizados muestran ese estado de forma explícita, en lugar de presentar cifras parciales como completas.
Flujo de trabajo de desarrollo
- Usé OpenCode y Claude durante el desarrollo para investigar, comparar enfoques e implementar partes del código.
- El concepto, las decisiones de producto, los criterios de clasificación y la revisión de cada cambio quedaron bajo mi dirección.
- Los flujos estructurados ayudaron a mantener cambios pequeños y revisables, y la suite de pruebas cubre la lógica de clasificación, eventos y analítica.
Lo que existe hoy
Resultados verificables del producto tal como funciona actualmente.
- Producto público en funcionamiento en dbd-hub.vercel.app.
- Recopilación periódica de datos de Twitch en snapshots de PostgreSQL.
- Clasificación de transmisiones competitivas y casuales, con etiquetas revisables.
- Analítica histórica de la proporción competitiva y de los picos de audiencia.
- Descubrimiento de candidatos a evento con confirmación humana.
- Directorio de streamers y una página de metodología que documenta los límites.
Desafíos y aprendizajes
La calidad de los datos importa más que la visualización
Un gráfico claro vale poco si la clasificación que hay detrás es incorrecta o si sus límites están ocultos. Gran parte del trabajo estuvo en el pipeline de datos y en su revisión, no en los gráficos.
La automatización necesita límites claros
Las reglas permiten escalar el análisis, pero los casos ambiguos siguen necesitando a una persona. Hacer explícito ese límite, en el código y en la interfaz, fue más útil que intentar automatizar cada decisión.
Mostrarlo no es lo mismo que validarlo
Lo compartí con streamers de la comunidad y a algunos no les quedó clara su utilidad. Creo que lo leyeron como un resumen de estadísticas de un fin de semana, y no como una herramienta de análisis histórico. Eso me mostró que la propuesta tiene que entenderse antes que los gráficos.
Lo que sigue
- Seguir acumulando historial, para que las tendencias de largo plazo sean medibles.
- Medir la precisión de la clasificación contra una muestra etiquetada.
- Mejorar el descubrimiento de eventos y su flujo de revisión.
- Recoger feedback de la comunidad sobre la clasificación y las métricas.
- Evaluar nuevas fuentes de datos solo cuando una necesidad esté validada.
- Revisar si el proyecto sigue teniendo sentido: lo replantearía si los datos resultaran demasiado básicos para análisis interesantes, o si la clasificación necesitara demasiado trabajo manual.
Más allá de un dashboard
DBD Comp Hub empezó como una pregunta personal sobre una comunidad de videojuegos que sigo, y terminó siendo un producto completo: APIs externas, reglas de clasificación, historial y analítica. Aunque no consiga muchos usuarios, ya me dejó algo valioso: construir una idea propia de principio a fin.
Proyecto comunitario independiente. No está afiliado, avalado ni patrocinado por Behaviour Interactive.