← Proyectos

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 app

El 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

Pantalla de inicio del prototipo: ¿Reconoces la canción?, con el botón Participar ahora y los tres datos de la partida: 3 canciones, 10 segundos por ronda y 3 alternativas
Prototipo
Validar el juego
Pantalla de partida de la instancia de Chile: ¿Cuál es esta canción?, pregunta 2 de 3, con el contador de diez segundos y tres alternativas sobre la imagen del parlante
Lanzamiento
Activación en tienda
Selector de instancia: ¿Dónde vas a jugar?, con las tarjetas de Perú y Colombia marcadas como demo interna y la de Chile con la campaña de Falabella
Expansión
Habilitar nuevos países

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.

Diagrama del algoritmo de selección musical: el catálogo distingue canciones disponibles y canciones recientes excluidas, selecciona un bloque de nueve y lo divide en tres audios y seis distractores
Diagrama de la precarga de audio: muestra canciones cargadas, una descarga activa y canciones en espera antes de priorizar las tres pistas de la partida; el audio queda disponible como Blob con el archivo original como alternativa

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.

Diagrama del cronómetro ligado a la reproducción: las respuestas permanecen bloqueadas y el reloj en cero hasta el evento playing; waiting o stalled congelan el tiempo y un nuevo playing lo reanuda

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.

Diagrama de tres instancias de la experiencia Sonos funcionando en paralelo para Perú, Colombia y Chile: cada país tiene su propio grupo de canciones, participantes y base de datos

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.

Diagrama del sistema de registro de la experiencia Sonos: un iPad envía el formulario a través de Vercel Functions, JavaScript y Apps Script hasta Google Sheets, y un segundo iPad muestra la confirmación de participación

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íaResponsabilidad
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

Alcance

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.

Catálogo

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.

Mantenimiento

Frontend sin dependencias

Sin build ni paquetes externos, con menos piezas que actualizar durante la activación.

Autonomía

Control sin
actualizaciones

Activar o cerrar las inscripciones se resuelve en la configuración de cada instancia, sin publicar una nueva versión.

¿Qué experiencia puede crear tu próxima campaña?

Diseñemos un recorrido interactivo que conecte a las personas con tu marca.