La noche en que el checkout de una tienda Shopify murió en Black Friday

No había monitoreo activo del checkout. Había Google Analytics, sí, pero nadie estaba viendo el dashboard en tiempo real a la 1 de la madrugada. La tienda confiaba en que 'Shopify no se cae', que es cierto —la infraestructura de Shopify no se cayó esa noche— pero una app de terceros sí puede dejar tu checkout inservible sin que la plataforma reporte nada raro.

Esa es la trampa: Shopify como plataforma estuvo perfectamente operativo toda la noche. El problema nunca fue de Shopify. Fue de una combinación específica de apps y código personalizado que nadie había revisado en meses, porque mientras no haya quejas, nadie mira.

Una alerta automática de caída de conversión —no de tráfico, de conversión— habría detectado el problema en minutos, no en horas. Es una configuración simple: si las ventas caen a cero con tráfico normal durante más de 15 minutos, alguien recibe una notificación. La mayoría de las tiendas Shopify en España no tienen esto configurado, porque nadie piensa en monitoreo de checkout hasta que ya es tarde.

Lo segundo que habría cambiado todo: una revisión previa a Black Friday de qué apps se actualizaron en las últimas semanas, y probar el flujo completo de compra con descuentos aplicados, no solo con el carrito vacío. Es una hora de trabajo que se salta casi siempre porque 'ya funciona'.

Los logs de Shopify no mienten, aunque tarden en contar la historia completa. A las 23:58, dos minutos antes de medianoche, la tienda registraba su pico de tráfico habitual: compradores entrando desde el email de campaña, el feed de anuncios calentado toda la semana, el boca a boca de quienes ya sabían que el descuento sería agresivo. A las 00:00:03 empezaron a entrar los primeros pedidos del lote de medianoche, uno detrás de otro, el carrito llenándose como cualquier otra noche grande.

A las 00:14, el contador interno del equipo de marketing —el que alguien miraba desde el móvil en la cama, medio dormido, solo para ver cómo iba— marcaba 340.000 € vendidos desde que arrancó la campaña a las 20:00. Todo normal. Mejor que normal: por encima de la proyección. A las 00:17, ese mismo contador se detuvo. No porque alguien lo cerrara. Porque dejó de recibir datos nuevos que registrar.

Entre las 00:17 y las 00:23 hubo un puñado de intentos de compra que sí llegaron a procesarse, de forma intermitente, como si el sistema tosiera entre fallo y fallo. Después de las 00:23, nada. Cero transacciones completadas durante las siguientes seis horas y media, mientras el tráfico —medido por Google Analytics, que seguía funcionando perfectamente porque vive fuera de Shopify y del checkout— se mantuvo alto hasta cerca de las 3 de la madrugada y luego bajó de forma gradual, como baja siempre un Black Friday, sin que nadie en la tienda supiera que cada una de esas visitas se estaba yendo con las manos vacías.

Para entender por qué pasó esto hace falta separar dos piezas que, por separado, funcionaban perfectamente. La primera: una app de upsell que, cuando un cliente añadía un producto al carrito, calculaba en tiempo real si calificaba para un descuento por volumen y mostraba una barra de progreso tipo 'te faltan 12 € para el siguiente descuento'. Es una funcionalidad común, probada, usada por miles de tiendas Shopify sin problema.

La segunda pieza: un script personalizado, escrito hace más de un año por un desarrollador que ya no trabajaba con la marca, que también calculaba descuentos por volumen, pero para un programa de fidelización distinto, pensado para clientes recurrentes identificados por su email. Ambos scripts, por separado, leían y escribían en la misma variable de sesión del carrito para guardar el total acumulado de descuentos aplicables.

Mientras el tráfico era bajo, las probabilidades de que ambos scripts intentaran escribir esa variable en el mismo instante exacto eran mínimas, casi anecdóticas: ocurría de tanto en tanto, generaba un pequeño retraso en la carga que nadie reportaba porque nadie lo notaba. Con el tráfico de Black Friday, cientos de carritos modificándose por segundo, la colisión dejó de ser una rareza estadística y se convirtió en la norma. El script entraba en lo que los desarrolladores llaman una condición de carrera: ambas piezas de código peleando por el mismo recurso, bloqueándose mutuamente, hasta que el proceso que debía confirmar el pago simplemente dejaba de responder.

El script de fidelización llevaba más de un año en producción sin que nadie lo tocara ni lo revisara. No era un error del desarrollador original —funcionaba perfectamente para lo que fue diseñado— sino un síntoma de algo mucho más común de lo que cualquier dueño de tienda quisiera admitir: nadie llevaba un inventario actualizado de qué scripts personalizados corrían sobre el tema, para qué servía cada uno, y si seguían siendo compatibles con las apps que se iban añadiendo después.

Es exactamente el mismo patrón que describimos en el caso de las apps que drenan presupuesto sin que nadie lo note: código y herramientas que se acumulan capa sobre capa, cada una añadida en un momento con una lógica propia, sin que nadie se siente después a revisar cómo interactúan entre sí. La diferencia es que, en este caso, la factura no llegó en euros al final de mes. Llegó de golpe, en forma de checkout muerto, la noche que más importaba.

Después del incidente, la configuración que se implementó fue deliberadamente simple, porque la complejidad es precisamente lo que falla a las tres de la madrugada cuando nadie tiene tiempo de leer documentación. Una alerta compara, cada cinco minutos, el número de visitas a la página de checkout contra el número de pedidos completados en esa misma ventana. Si la proporción cae por debajo de un umbral —algo claramente anómalo, no una fluctuación normal— dispara una notificación inmediata a un canal de mensajería que alguien del equipo técnico revisa en cuestión de minutos, no de horas.

No hace falta inteligencia artificial, ni un sistema sofisticado de machine learning prediciendo fallos antes de que ocurran. Hace falta una métrica bien elegida —conversión, no tráfico bruto— y un canal de aviso que de verdad llegue a alguien despierto o disponible para revisarlo. La mayoría de las tiendas Shopify en España no tienen ni lo uno ni lo otro, no porque sea caro o complicado de montar, sino porque nadie se sienta a montarlo hasta que ya vivió una noche como esta.

Con una tasa de conversión histórica de esa tienda en campañas de Black Friday, y el volumen de tráfico que efectivamente llegó durante esas seis horas y media de apagón, la estimación conservadora de ventas que no se concretaron ronda varias veces lo que la tienda terminó facturando en todo el resto del fin de semana. No es una cifra exacta —nunca se puede calcular con precisión absoluta cuánto se perdió, porque no hay transacción que contar— pero el orden de magnitud es suficiente para que cualquiera entienda por qué esta historia terminó convirtiéndose en la razón por la que la marca cambió por completo su forma de operar la tienda.

Hay un segundo costo, menos visible en una hoja de cálculo pero igual de real: la confianza interna del equipo en su propia infraestructura. Después de esa noche, cada campaña grande siguiente se vivió con un nivel de ansiedad que no existía antes, revisando el panel de forma obsesiva, sin confiar del todo en que 'esta vez no va a pasar'. Esa ansiedad tiene un costo en energía y atención que tampoco aparece en ningún informe financiero, pero que cualquiera que lo haya vivido reconoce de inmediato.

De las decenas de mensajes que llegaron al soporte de la marca durante los días siguientes, un patrón se repetía: gente que había visto el producto agotarse en redes sociales, que había entrado decidida a comprar, que había llegado hasta el último paso del checkout, y que simplemente se había encontrado con una rueda girando sin fin o un botón que no respondía. Algunos lo intentaron dos, tres veces, recargando la página, probando desde el móvil después de fallar en el ordenador. La mayoría, después del segundo o tercer intento fallido, se rindió y cerró la pestaña.

Lo que es casi imposible de medir, pero que cualquiera que haya trabajado en retención de clientes conoce bien, es cuántos de esos compradores frustrados no volvieron nunca más. No porque el producto no les gustara, sino porque la experiencia de 'quise comprar y no pude' deja una marca que compite directamente con la siguiente oportunidad de compra con cualquier otra marca que sí les resuelva el proceso sin fricción. Una campaña de Black Friday bien ejecutada no solo vende esa noche: construye la base de datos de clientes recurrentes para el resto del año. Esta, en particular, perdió parte de esa base antes de poder construirla.

Es una pregunta que surge siempre en estos casos: ¿por qué no se contactó al soporte de Shopify en el momento? La respuesta corta es que sí se intentó, horas después, cuando alguien finalmente detectó el problema. La respuesta larga es más incómoda: el soporte de Shopify, por diseño, no puede diagnosticar conflictos entre apps de terceros y código personalizado del tema, porque ese código no es de Shopify. Pueden confirmar que la plataforma funciona (y funcionaba), pero no pueden entrar a depurar un script escrito por un desarrollador externo hace un año.

Esta es una distinción que mucha gente no entiende hasta que la vive: Shopify es una infraestructura extraordinariamente sólida, pero todo lo que se construye encima —apps, temas personalizados, scripts a medida— es responsabilidad de quien lo instaló o lo escribió. No existe un soporte de Shopify capaz de resolver en minutos un conflicto entre dos piezas de código de terceros. Existe, en cambio, la posibilidad de tener a alguien que conozca esa tienda específica, su historial de cambios, sus scripts heredados, capaz de diagnosticarlo con contexto real en vez de empezar de cero.

Antes de esa campaña, el equipo había probado el checkout. Lo probaron, de hecho, varias veces: compraron un producto de prueba, verificaron que el descuento se aplicara, confirmaron que el email de confirmación llegara. Todo funcionó. El error no estaba en que no probaran el sistema. Estaba en que lo probaron de la única forma en que casi todo el mundo prueba un checkout: una persona, un navegador, un pedido a la vez, en condiciones de tráfico normal.

Ese tipo de prueba nunca va a revelar una condición de carrera que solo aparece cuando cientos de sesiones simultáneas pelean por el mismo recurso del servidor en el mismo instante. Para encontrar ese tipo de fallo hace falta simular carga real, algo que existen herramientas específicas para hacer, pero que casi ninguna tienda pequeña o mediana en España conoce o usa antes de una campaña grande. No es un paso complicado técnicamente. Es un paso que nadie piensa dar hasta que ya pagó el precio de no haberlo dado.

Esto es exactamente lo que cubre el mantenimiento mensual Shopify: alguien revisando apps, actualizaciones y comportamiento del checkout de forma constante, no solo cuando algo ya se rompió. Y es exactamente lo que cubre el soporte técnico urgente Shopify: que si algo falla a las 00:17 de un Black Friday, haya alguien a quien avisar que responda en horas, no cuando alguien se despierta por casualidad. El precio de este tipo de cobertura suele costar menos que una sola noche perdida como esta.

La tienda de esta historia sobrevivió al Black Friday. Perdió siete horas de la noche más cara del año, pero recuperó el resto del fin de semana porque, a partir de esa mañana, alguien se quedó revisando el checkout cada hora hasta el lunes. Meses después, esa misma tienda pasó por una campaña de rebajas de enero con el triple de tráfico simultáneo que aquel Black Friday, sin un solo minuto de caída, porque esta vez alguien sabía exactamente qué vigilar y cómo reaccionar en segundos, no en horas. La pregunta que vale la pena hacerse no es si algo así puede pasar. Es quién lo va a notar cuando pase, y cuánto va a tardar en hacer algo al respecto.