Dos años después, le arrancamos el corazón a SeenWant y lo reconstruimos.
Concretamente, el motor de swipe — el sistema que decide qué peli, serie, libro o juego mostrarte. El motor v1 funcionaba bien. Era el «bien» que destruye productos en silencio. Los usuarios swipeaban. No terminaban listas. Veían crecer su Want sin sacar nunca de él. La señal era buena pero el bucle estaba roto.
Este post es lo que aprendimos, lo que construimos y por qué creemos que la mayoría de feeds algorítmicos son silenciosamente malos.
El motor original
V1 era directo. Sacaba candidatos de cuatro fuentes:
- Coincidencias de género
- Filtrado colaborativo
- Trending
- Rellenos de cold-start
La baraja era una mezcla ponderada. Ajustable. Razonable. Estándar de industria.
Funcionaba como funciona el estándar de industria: mostrando «suficientemente bueno» sin sorprender nunca.
Lo que notamos
Seis meses tras el lanzamiento, en analítica fueron señales raras:
- Conversión Want-a-Seen baja. Wantear sin Seen. La Want list, cementerio.
- Tiempo-hasta-primer-Seen alto. Aún tras onboarding, dos semanas de media para marcar algo.
- Sesiones repetidas cortas. Dos minutos, aburrimiento, fuera.
- Power-users menos enganchados que casual. Los más activos ignoraban nuestras recomendaciones.
Cada señal tenía explicación. El mensaje compuesto: el motor fallaba el trabajo real.
Cuál es el trabajo real
Debate interno meses. El trabajo bajo el que lanzamos fue «mostrar lo que les gustará». El que deberíamos haber lanzado: «ayudar a decidir qué consumir a continuación».
Suena igual. No lo es.
«Mostrar lo que gustará» optimiza swipe-right rate. La meta equivocada.
«Ayudar a decidir qué consumir» optimiza algo más difícil: la tasa a la que un Want se vuelve Seen. La conversión de interés a acción.
Cuando cambiamos a esa meta, casi todo en el motor tuvo que cambiar.
Cinco cosas que hacíamos mal
1. Optimizamos por «más candidatos»
V1 asumía que más opciones, mejor. 30 candidatos por sesión.
Mal. Tras 12, fatiga. A 20, calidad de swipe cae. A 30, los usuarios solo limpian.
Fix v2: capar a 12. Que cada uno se gane el slot.
2. Tratamos los cuatro tipos igual
Recomendar libro funciona distinto a peli. Libro = compromiso de 10 horas. Peli = 2. Juego = 50 potenciales.
V1 mostraba los cuatro con igual peso. Wantean libros como pelis pero solo Seen 5%.
Fix v2: ponderación por tipo. Libros requieren señal mucho más fuerte. Juegos aún más. Pelis: las decisiones más rápidas; más permisivos.
3. Confiamos demasiado en el sistema de géneros
«Drama» es género. «Horror» también. «Thriller psicológico» también. La taxonomía es un caos, las pelis se cross-tag generosamente.
V1 usaba solapamiento de género como señal primaria. A quien le gustó una peli coreana lenta le recomendaban cada tag «Drama», incluyendo familiares americanas de los 90.
Fix v2: reemplazamos coincidencia de género por embeddings. Las pelis ahora viven en un espacio de similaridad aprendido del comportamiento real.
4. No modelamos la habitación
La mayoría de usuarios no ven solos. V1 trataba cada recomendación como si fuera la única audiencia.
Fix v2: un modo «viendo con» que permite swipear con otro perfil en mente.
5. Sobre-recompensábamos lo reciente
Los trending estaban demasiado pesados. Una peli de hace un mes vencía a una de 2003 con misma relevancia real.
Fix v2: recencia es bono pequeño, no multiplicador.
La nueva arquitectura
El motor v2 tiene cuatro partes:
Espacio de embeddings
Cada título tiene un embedding 384-dim que captura «qué tipo de peli». Lo aprendimos de co-ocurrencia: títulos a menudo Wanted por los mismos usuarios cluster juntos.
Lo nuevo: cómo se entrenan — sobre Want-a-Seen transiciones, no Want solos. Want sin Seen es señal débil. Want con 5 estrellas Seen, fuerte. Los embeddings aprenden de las fuertes.
Vector de gusto por usuario
Cada usuario, vector 384-dim. Promedio ponderado de Seen. Actualiza tras cada Seen, no cada Want.
Decisión clave: actualizamos en Seen, no en Want. La mayoría de motores actualizan en engagement. Nosotros en finalización.
Selección de candidatos
El conjunto: títulos más cercanos al vector, filtrado por:
- No Wanted, Seen, Skipped
- Disponible en los streamings conectados
- Coincide con ajustes (idiomas, filtros)
Re-rankeamos con: valoraciones de amigos, recencia, inyección de diversidad.
Inyección de diversidad
Un motor pure embedding-similarity colapsa.
Reservamos 2-3 slots de cada 12 a recomendaciones off-vector. Algunas aterrizan mal. Algunas brillantemente. Evita el colapso algorítmico que vuelve estériles los feeds.
Lo que medimos ahora
Tres métricas reemplazan la vieja:
- Conversión Want-a-Seen (W2S). % de Want que vuelven Seen en 30 días. Meta: 35%. Actual: 31%. Subió desde 14% pre-rebuild.
- Tiempo-hasta-decisión. De «aburrido» a «esto miro». Meta: menos de 3 min. Actual: 2:48. Bajó desde 4:12.
- Recommendation reuse rate. Cuando recomendamos y el usuario Want, ¿vuelve a buscarlo? Meta: 70%/60 días. Actual: 64%.
Más difíciles de mover que swipe-right rate. Y las correctas.
Qué viene
Experimentos:
- Recomendaciones condicionadas por humor.
- Mejora cold-start.
- Integración del grafo de amigos.
La lección
Lo grande no fue técnico. Fue reformulación.
Los motores son malos porque optimizan lo equivocado — engagement, swipe-rate, tiempo-en-plataforma. Métricas fáciles de medir y de manipular. La métrica más honesta: ¿el usuario terminó con mejor experiencia?
Si usaste SeenWant antes — sentirás la diferencia. Si no — dale un swipe y dinos.
¿Curiosos por la arquitectura en detalle? Publicamos un follow-up sobre el pipeline de entrenamiento de embeddings. Suscríbete al RSS.
