Todos los casos de éxito

Caso de éxito

3.338 fallos en 30 días. Nueve de cada diez no levantaron ningún error.

AdaptlyPost

SaaS de programación y publicación en redes sociales

Del 13 de julio al 13 de agosto de 2026

La página de inicio de AdaptlyPost

75.167

grabaciones analizadas

del 13 de julio al 13 de agosto de 2026

3.338

fallos reales

4,4 % de todo lo analizado

66

causas distintas

1 crítica, 7 altas, 15 medias, 43 bajas

90 %

no levantaron ningún error

3.019 de 3.338 sin error de consola ni de red

En resumen

Flowsery analizó 75.167 grabaciones de sesión de adaptlypost.com en un mes y encontró 3.338 fallos reales procedentes de 66 causas distintas. Nueve de cada diez de esos fallos no levantaron ningún error de consola ni de red, y las sesiones que sí llevaban un error fueron un fallo real el 2,8 % de las veces. Siguen cuatro hallazgos, ordenados por lo que costaron y no por cuántas veces saltaron.

Entre el 13 de julio y el 13 de agosto de 2026, Flowsery analizó 75.167 grabaciones de sesión de adaptlypost.com y marcó 3.338 de ellas como un fallo real para el visitante. Agrupar por causa redujo esa cifra a 66 bugs distintos: uno crítico, siete altos, quince medios, cuarenta y tres bajos.

3.019 de los 3.338 fallos no llevaban error de consola ni error de red. Nueve de cada diez. En ese mismo mes, 11.598 sesiones sí llevaban un error, y 319 de ellas resultaron ser un fallo real. Un monitor de errores habría avisado por las once mil sesiones equivocadas y habría dormido durante las tres mil que importaban.

Los cuatro hallazgos de abajo están ordenados por lo que costaron, no por cuántas veces saltaron.

Sobre AdaptlyPost

AdaptlyPost es un programador de redes sociales que se vende con una prueba de 7 días. Publica en cinco idiomas y tiene un blog con un glosario que Google indexa. AdaptlyPost y Flowsery tienen el mismo fundador.

La página de inicio de AdaptlyPost
La página de inicio de AdaptlyPost.

Cómo se hizo el estudio

La grabación de sesiones llevaba unos dos meses en marcha en el sitio antes de que el análisis con IA se encendiera, el 13 de julio de 2026. Este estudio cubre exactamente un mes desde esa fecha. Las 75.167 grabaciones son ese atraso más todo lo que el tráfico en vivo produjo mientras corría la pipeline.

Una grabación cuenta como fallo cuando el visitante intentó hacer algo que la página ofrecía y la página no lo entregó. Una tarjeta rechazada no es un fallo, porque que un banco diga que no no es un bug. Un botón de pago que no hace nada al pulsarlo sí lo es. Cada fallo lleva una severidad, pasos de reproducción y un enlace a la grabación. Los fallos con la misma causa se agrupan, que es como 3.338 se convirtieron en 66.

De grabaciones a causas
Grabaciones analizadas75.167
Fallos reales3.338 · 4,4 %
Causas distintas66
66 causas por gravedad
1 crítica7 altas15 medias43 bajas
Agrupar por causa convierte 3.338 sesiones en 66 entradas.

Hallazgo 1: el checkout bloqueó pagos de cinco formas distintas

Siete sesiones en la ventana terminaron con el propio sitio deteniendo un pago, de cinco formas separadas.

Lo que los visitantes vieron en el paso de pago
1
Un error de servidor en el botón de prueba. En la versión en portugués, el visitante pulsa "iniciar prueba gratuita" y la petición falla en el servidor. En pantalla no aparece nada útil. Cuatro reintentos, y se va.
2
"Internal server error" en Start Free Trial. El visitante reintenta, cambia el ciclo de facturación, prueba con PayPal y no vuelve.
3
Un botón de PayPal muerto. Datos de facturación rellenados, clics rápidos en "Pay with PayPal", ninguna respuesta, sesión terminada.
4
Una mejora de plan rechazada por una regla de facturación. Un cliente existente intenta pasar a un plan mayor y recibe "Payment Failed", porque el sistema de suscripciones no cambia la fecha de inicio de un plan que ya se ha cobrado. Cinco sesiones. La más larga son 34 minutos reabriendo la ventana de pago y clicando antes de rendirse.
5
Un 404 en la página de mejora de plan. En una de las versiones de idioma, la ruta de mejora no existía. El visitante deambula por inicio, panel y facturación, nunca encuentra la forma de pagar más, y se va.
Los textos entre comillas son lo que había en la pantalla del visitante.

Dos de los cinco, los errores de servidor, aparecerían en un rastreador de errores. La regla de facturación es el sistema de pagos funcionando como se diseñó, rechazando a un cliente que quiere pagar más. El botón de PayPal muerto no lanza absolutamente nada. La página de mejora de plan que falta es un 404, y los 404 son ruido de fondo en cualquier sitio.

El único problema crítico estaba en la página de inicio de sesión en francés. Un visitante envió el formulario y la página mostró "400: Bad Request", casi seguro porque el widget anti-bots nunca llegó a renderizarse. Se fue. Un formulario de inicio de sesión debería decir "Email o contraseña incorrectos", no enseñar un código HTTP.

Hallazgo 2: un control se tragó los clics en 17 rutas

48 sesiones repartidas en 17 rutas distintas muestran el mismo patrón. Un visitante pulsa un selector, no pasa nada visible, vuelve a pulsar, y otra vez, y luego se va.

Es un solo componente, reutilizado en cada página que pide al visitante elegir algo.

  • En el editor de publicaciones en alemán, un cliente con sesión iniciada abre los ajustes de Pinterest y pulsa "elegir tablero" repetidamente. El desplegable nunca se abre. Pulsa "publicar ahora" igualmente. La publicación nunca sale.
  • En el generador de posts con IA, "Select Platform" no produce respuesta tras varios clics. El visitante se rinde y pulsa el título de la página.
  • En la calculadora de tarifas de influencers, el botón de nivel de engagement ignora seis segundos de clics insistentes antes de registrar por fin uno.
  • En el verificador de disponibilidad de nombre de usuario, tres clics sobre la lista de plataformas no hacen nada. El visitante nunca llega a "Check Availability".

Ninguno lanza una excepción. En todos los casos es un manejador de clic que dispara contra un componente cuyo estado visual nunca se actualiza, así que el visitante no puede distinguir "ignorado" de "roto". Los clics de rabia son la única señal, y esa señal existe solo dentro de una grabación.

Un selector, un visitante, seis segundos
0 s6 s
10clics
0cambios en pantalla
0errores registrados
Diez clics en seis segundos sobre el selector de nivel de engagement de la calculadora de tarifas para influencers. Nada cambió en pantalla y nada quedó registrado.

Hallazgo 3: las traducciones que no cargaron

AdaptlyPost publica en cinco idiomas, y se notan las costuras. Nueve sesiones en la ventana, en cuatro rutas, terminaron con el visitante mirando algo que nunca debió ser texto: una clave de traducción, una página de error en el idioma equivocado o un marcador de posición.

Lo que vio el visitanteSesionesDóndeSeñal de error
Claves de traducción como texto de la página5/en/media-kitNinguna
Una página 500 tras cambiar de idioma2Página de inicioHTTP 500
Archivos JSON de idioma devolviendo 4042Analizador de nivel de lectura, un artículo del blog404 en segundo plano

La página del media kit es el caso más claro. Cinco visitantes aterrizaron en ella y vieron "brandFacts.mediaKit.title" y "brandFacts.mediaKit.description" donde deberían estar el titular y el texto. Ninguno hizo clic en nada. La página devolvió 200 sin errores de consola, así que nada la señaló.

Lo que vieron cinco visitantes en /en/media-kit
adaptlypost.com/en/media-kit
brandFacts.mediaKit.eyebrow brandFacts.mediaKit.title brandFacts.mediaKit.description brandFacts.mediaKit.assetsDescription
Cada cadena de la página es la clave que el archivo de traducción debería haber resuelto. La página devolvió 200.

Cambiar el idioma a portugués produjo una página 500 con "Ocorreu um erro inesperado". El botón de reintentar cargó la página de inicio en portugués, y 17 minutos después volvió el mismo 500. Otro visitante recibió en la página de inicio en inglés un overlay 500 cuyo botón de reintentar decía "Intentar otra vez", español en una página en inglés.

El selector de idioma también pide archivos de idioma que no existen. Una sesión en el analizador de nivel de lectura registró 24 errores 404 en segundo plano para archivos como /locales/fr/gdpr.json. Cambiar un artículo del blog a español hizo lo mismo.

Después de cerrar la ventana, el 18 de agosto, la versión en español de la guía de zonas seguras salió con el marcador de posición "Original text" como titular principal.

Nada de esto lanza un error que sirva. Las claves en bruto y el marcador de posición son una página renderizando la cadena equivocada. Los 404 de idioma son peticiones en segundo plano que nadie mira. Solo las páginas 500 avisarían a alguien, y una de ellas se resolvió sola al reintentar.

Hallazgo 4: las URLs de glosario que devuelven 404

El hallazgo mayor por número de sesiones, y el más aburrido, que es como sobrevivió tanto tiempo.

Los artículos de glosario de AdaptlyPost viven en /blog/<slug>. En algún momento se publicaron, y luego se indexaron, en /blog/glossary-<slug>. El sitio no tiene ruta para la forma con prefijo.

  • 382 URLs /blog/glossary-* distintas aparecieron en fallos, en 1.287 sesiones
  • La mayor parte de ese tráfico llegó directamente desde un resultado de búsqueda
  • Diez slugs de muestra cotejados con el directorio de contenido: ocho de los diez artículos existen, en la URL sin prefijo

Los artículos existen y posicionan. La URL que Google indexó apunta a nada, y una sola regla de redirección lo arreglaría.

Los 404 del glosario en cifras
382URLs /blog/glossary-* distintas que devuelven 404
1.287sesiones que aterrizaron en una
8 de 10artículos muestreados existen en la URL sin prefijo
1regla de redirección para arreglarlo
La mayoría de esas sesiones llegaron directamente desde un resultado de búsqueda.

Lo que vio la monitorización de errores

De las 75.167 grabaciones analizadas, 11.598 llevaban un error de consola o de red. 319 de esas eran un fallo real y visible para el visitante. Eso es un 2,8 % de precisión. Abre las repeticiones filtradas por "tiene errores" y 97 de cada 100 serán un rastreador bloqueado o un fetch cancelado.

La otra dirección es peor. De los 3.338 fallos reales, 3.019 no llevaban ningún error. La mayor parte de lo de arriba vive en ese 90 %: el botón de PayPal muerto, la regla de facturación, los clics tragados, la página del media kit imprimiendo sus claves de traducción.

La marca de error como detector
Sesiones marcadas que eran fallos reales2,8 %
Fallos reales que la marca no vio90 %
11.598 marcadas, 319 reales. 3.338 reales, 3.019 sin marcar. Falla en las dos direcciones.

De una repetición a un cambio revisable

El día después de cerrarse la ventana, el agente de Flowsery tomó el problema del selector de engagement del hallazgo 2, leyó la grabación y abrió un pull request contra el código de AdaptlyPost.

Su lectura del bug: pulsar una opción actualizaba un estado que el visitante no podía ver, así que en pantalla no cambiaba nada y el grabador recogió diez clics sin respuesta. El cambio recablea el control para que se comporte como los selectores del sitio que ya funcionan. Un commit, un archivo.

Del clic de rabia al pull request
Sesión grabada
Problema deduplicado
El agente lee la repetición
Cambio abierto a revisión
Nadie lo pidió y nadie abrió la repetición.

Dónde están las cosas

HallazgoSesiones en la ventanaSeñal de errorEstado
El checkout bloqueó pagos, de cinco formas72 de 5 modosArreglado
400 en crudo en el inicio de sesión1HTTP 400Arreglado
El selector se tragó los clics48, en 17 rutasNingunaArreglado
Traducciones que no cargaron9, en 4 rutas3 de 9Arreglado
URLs de glosario que devuelven 4041.287HTTP 404Arreglado

Lo que cambió en el mes es la forma del backlog. Antes del 13 de julio era lo que a alguien le daba por notar. Después, es una lista ordenada donde cada entrada lleva un recuento de sesiones, una fecha de primera aparición, una severidad, pasos de reproducción y una grabación que abrir.

"Deberíamos mirar el checkout" pierde contra un ítem del roadmap. "Siete personas intentaron pagar y el checkout se lo impidió, de cinco formas distintas, y aquí tienes la grabación de una" no pierde.

Lo que se generaliza

El mismo mes, dos vistas
Lo que vio el stack
  • Un 200 con una página completamente renderizada
  • Un 200 que lleva dentro un mensaje de error
  • Un manejador de clic que disparó con normalidad
  • 11.598 sesiones marcadas, 319 de ellas reales
Lo que vieron las grabaciones
  • Un titular que dice brandFacts.mediaKit.title
  • Un cliente de pago al que se le rechaza una mejora de plan
  • Diez clics sin respuesta y luego el visitante se va
  • 3.338 fallos reales, 66 causas distintas
El noventa por ciento de la columna derecha es invisible para la izquierda.

Ordena por coste, no por volumen. Los 404 del glosario tocaron 1.287 sesiones y los del checkout siete, y los del checkout valen más.

Trata los controles silenciosos como bugs sin telemetría. Un desplegable muerto no lanza nada, no registra nada y devuelve 200. La única prueba de que existe es una persona pulsando el mismo punto diez veces, y esa prueba está en la grabación o en ninguna parte.

Lee lo que muestra la página, no lo que devolvió el servidor. Un titular que dice brandFacts.mediaKit.title es un 200 sin errores de consola, y también lo es una página en español cuyo titular principal es "Original text". Ninguno aparece como caída de embudo, porque el visitante nunca entró en el embudo.

Descubre lo que tu panel de errores no ve

El mismo análisis que corrió sobre AdaptlyPost, sobre tu propio sitio.