Sonos
Una experiencia musical y una oportunidad de ganar
Juego de reconocimiento musical creado para una activación retail de Sonos. Cada participante escucha tres fragmentos y responde contra el tiempo: los aciertos y la velocidad definen el ranking del día. El recorrido funciona de forma autónoma en tienda y permite configurar cada país con sus propias reglas de acceso, vigencia, cupos y destino de los registros.
Explorar la appEl concurso tenía que sostener el ritmo de la tienda
El punto de venta definió las decisiones del proyecto, no la preferencia técnica.
En una activación retail, cualquier interrupción se convierte en parte de la experiencia de marca. Si el audio tarda, la pantalla no vuelve al inicio o la conexión se corta, la fila se detiene y el equipo de tienda tiene que intervenir.
El encargo exigía que cada participante pudiera registrarse, jugar y dejar el concurso listo para la siguiente persona sin asistencia técnica. La solución debía sostener ese ciclo completo durante toda la jornada, incluso con una conexión intermitente.
- JavaScript
- Vercel Functions
- Apps Script
- Google Sheets
Del prototipo a una experiencia
configurable por país
Del registro al ranking
El participante selecciona su país, deja sus datos para participar en el sorteo final y confirma que está listo. La app presenta tres desafíos musicales de diez segundos: en cada uno escucha un fragmento y elige la canción correcta.
Al terminar, ve una pantalla con sus aciertos y tiempos, que determinan su posición en el ranking del día. El resultado queda registrado en la base de datos correspondiente y la app vuelve al inicio de la instancia seleccionada, lista para recibir al siguiente participante.
Azar en las canciones, precisión en el tiempo
Una selección sin repeticiones inmediatas
El catálogo contiene cincuenta canciones. Antes de cada partida, la app excluye las dieciocho usadas en las dos rondas anteriores y aplica un shuffle Fisher-Yates para formar un bloque de nueve. La rotación se conserva en localStorage, separada por instancia, catálogo y versión.
Un segundo shuffle define los tres audios. Las seis canciones restantes se reparten como distractores, dos por pregunta, de modo que cada canción cumple una sola función dentro de la partida.
El audio tiene prioridad
Al entrar a una instancia, el catálogo comienza a precargarse en segundo plano, una pista a la vez. Cuando se prepara la partida, las tres canciones que van a sonar pasan al frente de la cola y cualquier descarga de fondo vuelve a esperar.
Cada pista lista se conserva como un Blob. Si ese recurso falla, la app recurre al archivo original y mantiene el concurso en marcha.
Un cronómetro ligado a la reproducción
El reloj no comienza al mostrar la pregunta. Las alternativas permanecen bloqueadas hasta que el navegador emite playing; solo entonces la app toma la marca inicial con performance.now(). Si el audio entra en waiting o stalled, el tiempo se congela y continúa con el siguiente playing.
Cada pregunta genera además un token de reproducción propio, que descarta respuestas tardías y callbacks de la canción anterior. La carga, el buffering y los reintentos nunca consumen segundos del participante ni alteran su posición en el ranking.
Cambian las reglas, no el código
Chile fue la primera activación. Preparar la experiencia para Perú y Colombia no significó duplicar el proyecto: cada mercado se convirtió en una instancia de la misma aplicación.
Un identificador reúne todo lo que cambia en cada mercado: el país permitido, el estado, la vigencia, el cupo y el destino de los registros. El recorrido, la mecánica y el despliegue permanecen compartidos. Incorporar otro mercado es agregar una entrada de configuración, no mantener otra copia del código.
Antes de cargar la experiencia, una función en el borde compara la instancia solicitada con el país de la visita. La regla geográfica vive en un solo punto y no se repite pantalla por pantalla.
Operar sin sumar otra plataforma
Los registros llegan a Google Sheets, una planilla por país, porque es la herramienta que el equipo de marketing ya usaba a diario. Crear un panel propio habría añadido otra interfaz que aprender y mantener después de la campaña.
El estado de cada instancia se concentra en el hub: si la experiencia está activa y si acepta inscripciones. Abrir o cerrar un concurso es cambiar esa configuración, no desplegar una nueva versión.
El hub también es el único componente con permiso de escritura y valida cada registro antes de enviarlo a Sheets. Un bloqueo de concurrencia evita que dos tablets ocupen al mismo tiempo el último cupo.
Cada pieza responde a una restricción concreta
El stack se mantuvo deliberadamente pequeño. Cada componente asumió una función específica, sin añadir infraestructura que hubiera que sostener después de la campaña.
| Tecnología | Responsabilidad |
|---|---|
| JavaScript vanilla, sin build ni dependencias | Ejecutar las ocho pantallas sin build, framework ni dependencias que actualizar durante la campaña. |
| Audio HTML5 nativo | Exponer directamente los eventos que controlan la reproducción y el cronómetro. |
| Vercel Functions | Resolver el acceso geográfico desde un único punto de entrada. |
| Google Apps Script | Concentrar el estado de las instancias, validar los registros y controlar la escritura. |
| Google Sheets | Entregar los datos en una herramienta que el equipo ya sabía filtrar, ordenar y exportar. |
Lo que quedó resuelto
Una base multipaís
Chile, Perú y Colombia comparten el mismo código. Un mercado nuevo se incorpora como otra instancia, sin rutas ni despliegues separados.
Rotación ampliable
El catálogo actual reúne 50 canciones y puede crecer sin cambiar la lógica de selección ni la memoria de rondas recientes.
Frontend sin dependencias
Sin build ni paquetes externos, con menos piezas que actualizar durante la activación.
Control sin
actualizaciones
Activar o cerrar las inscripciones se resuelve en la configuración de cada instancia, sin publicar una nueva versión.