Mi App Tenía Visitantes. Nadie Convertía. Una Herramienta Gratuita de IA Descubrió Exactamente Por Qué en 3 Días.
Tienes tráfico. Los usuarios hacen clic, entran a la app, el 62% logra pasar la puerta principal. Y después nada convierte. Los usuarios se van en algún punto entre la entrada y la acción, y no tienes ni idea dónde.
Un fundador de Indie Hackers lo dijo claramente el mes pasado: no conocer tu tasa de conversión base significa que no puedes medir si alguno de tus cambios realmente funcionó. Esa es la parte que nadie dice en voz alta. Tienes el tráfico. Tienes la caída. Entre los dos: una caja negra.
Podría haber reescrito el copy, cambiado los colores de los botones, reconstruido el onboarding desde cero por instinto (léase: pura adivinanza). En lugar de eso instalé Microsoft Clarity, una herramienta gratuita sin límite de sesiones, y pasé 3 días viendo qué hacían realmente mis usuarios en la app. No lo que asumía que hacían. Lo que realmente hacían.
El resultado: 20% de las sesiones tenían clics muertos. Los usuarios tocaban un elemento decorativo que parecía interactivo, no iban a ningún lado, y se iban. Además de eso, una falla estructural que Clarity no podía ver por sí solo: mi app era una SPA con una sola URL para cada pantalla. Los mapas de calor habían estado ciegos desde el día que lancé.
Por Qué Clarity y No las de Pago
Hotjar es la opción por defecto en todas las listas de herramientas SaaS. También cuesta $39/mes por 500 sesiones, con grabaciones bloqueadas detrás de niveles más altos. En etapa pre-PMF, no vas a pagar $39/mes para descubrir que las etiquetas de tus botones son confusas. La herramienta que realmente vas a configurar es la que no cuesta nada.
Clarity no tiene límite de sesiones. Grabaciones de sesiones, mapas de calor, mapas de scroll, mapas de clics, y puntuación de rendimiento Core Web Vitals todo viene gratis. 1 script tag en tu <head>, estás recolectando datos reales en 10 minutos. La relación señal-esfuerzo supera a todas las alternativas de pago antes del product-market fit.
Clarity también detecta señales de frustración automáticamente: rage clicks (usuarios tocando el mismo lugar 3 o más veces), clics muertos, scroll excesivo, y quick-backs están todos marcados sin configuración manual de eventos. No necesitas saber qué estás buscando. La herramienta te dice qué sesiones vale la pena ver.
Si estás en la etapa donde algo acaba de lanzarse y no puedes entender por qué el flujo de checkout no está convirtiendo, Vibe Coding, For Real cubre toda la decisión del stack antes de que llegues a analytics. Gratis en Kindle Unlimited, hecho para builders que han chocado exactamente con esta pared.
El trade-off: los datos viven en Azure. ¿Stack con compliance pesado? Ya sabes qué hacer. Para una herramienta estándar basada en WooCommerce o SaaS temprano sin requisitos específicos de retención de datos, no es una preocupación real.
3 Herramientas para 3 Trabajos
El principio antes de tocar cualquier cosa: el consumidor de los datos determina la herramienta correcta.
Si estás investigando manualmente, el dashboard es tu única opción. Es el único lugar donde existen las grabaciones de sesiones y mapas de calor. Ningún endpoint de API, ningún servidor MCP te da video de un usuario real navegando tu app. Si necesitas ver, abres el navegador.
Cuando necesitas automatizar, usa la REST API directamente. Métricas agregadas vía petición GET, enviadas a almacenamiento local, procesadas por tu propio código. Sin intermediario, sin overhead conversacional.
MCP más Claude es para consultas conversacionales. Pregunta en español simple, obtén análisis estructurado de vuelta. Los mismos datos subyacentes que la REST API, con límites idénticos. La interfaz es la mejora, no los datos.
Modo 1: Clics Muertos y la Trampa SPA
En el primer lote de datos de Clarity: 20% de sesiones con clics muertos, puntuación de rendimiento 91/100, 0 errores JS, y profundidad de scroll al 86% significando que los usuarios estaban leyendo más allá del fold. Y aún así nada convertía.
La disciplina que cambió cómo leo Clarity: el dashboard te dice el QUÉ. Llegar al POR QUÉ significa cavar en el código.
La primera hipótesis fue routing. Un estado de navegación roto enviando usuarios a la pantalla incorrecta después de una acción. Abrí 30 grabaciones de sesiones y las vi una tras otra. Mismo elemento, mismo lugar, sesión tras sesión. Los usuarios lo tocaban. No pasaba nada. Lo intentaban de nuevo. Se iban.
(MORISTE. Causa de muerte: un div con hover state y sin click handler.)
Resultó que el elemento era decorativo. Un div estilizado que parecía interactivo, tenía un hover state que había agregado por hábito durante la construcción, y estaba conectado a absolutamente nada. 1 de cada 5 usuarios estaba haciendo clic en una pared. Lo había desplegado así y nunca me di cuenta. (He desplegado cosas peores. Este es un espacio seguro.)
Fix: reemplacé el div con un botón conectado a la acción de conversión primaria. La tasa de clics muertos bajó en el siguiente lote de observación.
Mi hijo entró mientras estaba viendo la sesión 22 y preguntó por qué estaba viendo un video de alguien mirando una pantalla sin hacer nada. No pude explicárselo realmente. "Trabajo" cubre mucho terreno aparentemente 😅
Entonces surgió el problema más profundo.
Vale la pena quedarse con esto, porque cambia cómo lees cada mapa de calor que hayas visto. Clarity organiza todos los datos visuales por URL. Cada mapa de clics, cada mapa de scroll, cada mapa de calor está limitado a una URL específica. Para una app tradicional multi-página, esa estructura funciona bien. Para una SPA que renderiza 7 pantallas diferentes bajo una sola URL /app, significa que cada interacción a través de cada pantalla se agrega en 1 blob inútil. Un clic muerto en la pantalla de listado de productos se ve idéntico a un clic muerto en la confirmación de checkout, porque desde la perspectiva de Clarity, pasaron en la misma página. Había estado ejecutando esta configuración por meses, viendo mapas de calor agregados, sacando conclusiones sobre comportamiento de usuario, tomando decisiones de diseño basadas en esos datos, y cada punto de datos estaba contaminado. El desajuste estructural entre cómo las herramientas de analytics modelan páginas y cómo las SPAs realmente funcionan no es un bug de Clarity. Es un desajuste que no detectas hasta que ya has construido el modelo mental incorrecto de tus usuarios.
Las herramientas de analytics están construidas alrededor de URLs de página. Una SPA que nunca cambia su URL no les da nada con qué trabajar.
Tus mapas de calor han estado mintiendo desde el día de lanzamiento.
Fix: hash routing. /app/#product-listing, /app/#checkout, /app/#confirmation. Cada pantalla obtiene una URL direccionable. Luego etiquetado de eventos por pantalla vía clarity('set', 'screen', slug) para que las sesiones se segmenten limpiamente en el dashboard.
// Dispara cada vez que la pantalla activa cambia
router.on('routechange', (screenSlug) => {
clarity('set', 'screen', screenSlug);
});1 URL direccionable por pantalla también es un activo de marketing. Ahora puedes apuntar una campaña pagada directamente a /app/#checkout en lugar de volcar todo el tráfico en la puerta principal y esperar que el flujo de onboarding cierre la brecha.
Modo 2: La API y Sus Límites Duros
Una vez que quieras automatizar la extracción de métricas, sáltate el dashboard. Usa la Clarity Data Export API en el endpoint project-live-insights. Auth vía token: Settings, Data Export, Generate Token.
3 límites que debes conocer antes de escribir una sola línea:
La API tiene un límite de 10 peticiones por día, sin allowance de ráfaga, sin override. (Piénsalo como una barra de maná que se resetea a medianoche. No la gastes en llamadas de prueba.) Un cron job ejecutándose cada hora fallará por la mañana. Diseña tu horario de polling alrededor de esta restricción desde el inicio.
Cada petición cubre como máximo 3 días de historial. Sin vista rodante de 30 días, sin comparación de tendencias en una sola llamada. Construye tu propia capa de almacenamiento, acumula diariamente, deduplica por fecha. Después de 30 días tienes un mes rodante. Después de 90 días empiezas a ver señales de estacionalidad que vale la pena atender.
Cada petición acepta un máximo de 3 dimensiones simultáneamente. Device, country, y screen en una llamada: esas son tus 3. Agrega una 4ta y la petición falla. Más segmentación significa más llamadas y quema de cuota más rápida.
import requests
token = "your_clarity_project_token"
headers = {"Authorization": f"Bearer {token}"}
response = requests.get(
"https://www.clarity.ms/export-data/api/v1/project-live-insights",
headers=headers,
params={
"startDate": "2026-06-11",
"endDate": "2026-06-14",
"dimensions": "device,country,url"
}
)
data = response.json()Lo que la REST API no te da: grabaciones, mapas de calor, o detalle a nivel de sesión. Solo agregados. El comportamiento de usuario individual se queda en territorio del Modo 1.
Si ejecutas múltiples apps y quieres que estos datos alimenten algo más amplio, una configuración de monitoreo SaaS potenciada por Claude es una extensión natural. No es un patrón específico de Clarity, pero cierra la pregunta "¿está algo en llamas?" a través de todo tu portafolio sin revisar 5 dashboards.
Modo 3: Claude y MCP
El paquete @microsoft/clarity-mcp-server en npm (oficial de Microsoft) conecta Claude a la misma API que usas en el Modo 2. La diferencia es la interfaz.
npx @microsoft/clarity-mcp-server --token your_clarity_tokenCon el MCP conectado en Claude, preguntas en español simple:
"¿Qué pantallas tienen la tasa más alta de clics muertos en los últimos 3 días? Compara móvil vs desktop."
"¿Qué hicieron los usuarios inmediatamente antes de llegar a la pantalla de checkout sin completar una compra?"
Claude devuelve análisis estructurado. Patrones que tomarían una hora de revisión manual de sesiones se detectan en menos de un minuto. Hacer una pregunta de seguimiento es instantáneo. Aquí es donde MCP se gana su lugar: iteración rápida en hipótesis de investigación, no automatización por lotes.
Lo que MCP hereda de la API: cada límite, exactamente. Las mismas 10 peticiones por día, 3 días de historial, y máximo 3 dimensiones por petición se aplican aquí como lo hacen a la llamada REST cruda. El servidor MCP es un adaptador de transporte, no una capa de datos. Traduce la entrada conversacional de Claude en llamadas REST y formatea las respuestas de vuelta. No desbloquea ningún dato que la API no exponga ya. Ve esperando una mejor interfaz de investigación para los mismos datos, no un superpoder.
El modo que me sorprendió no fue la velocidad de respuestas individuales sino las comparaciones multi-variable. Le pedí a Claude que comparara señales de conversión entre sesiones con clics muertos y sesiones sin ellos. Ese cross-slice requiere 3 llamadas API separadas con diferentes combinaciones de dimensiones, matemática de cuota encima, y fusión manual de respuestas. El MCP manejó todo en 1 turno. Escribí 0 líneas de código y obtuve una comparación limpia en menos de un minuto.
Creo que MCP funciona mejor como herramienta de sprint de investigación: quema las 10 peticiones diarias en pruebas de hipótesis dirigidas, luego cambia a un script para todo lo repetible. Puede que esté leyendo esto mal, pero esa división ha sido limpia hasta ahora.
Vale la pena notar: una vez que el MCP llega a 10 peticiones, se acabó. Sin cola, sin retry. Planea tus preguntas antes de abrir la sesión, no durante. Las preguntas exploratorias queman cuota rápido.
Para cualquier cosa que ejecute en horario, un CLI hecho a propósito supera a MCP para automatización de producción: sin límite diario, sin sesión de Claude requerida, ejecuta en un cron sin overhead. Usa MCP para investigación, CLI para las cosas programadas. Cubren diferentes partes del trabajo.
Clics muertos: 20% de sesiones al inicio, apuntando a menos del 5%. Fix desplegado, midiendo. Hash routing activo, mapas de calor limpios por pantalla. Etiquetado de eventos por pantalla activo.
3 días y 1 herramienta gratuita. Esa URL debería haber estado ahí desde el lanzamiento 🤦♂️
Fuentes
- Microsoft Clarity — grabación de sesiones, mapas de calor, Core Web Vitals, gratis
- @microsoft/clarity-mcp-server — npm, oficial de Microsoft
- Clarity Data Export API — documentación de endpoint, límites de tasa
Este post puede contener enlaces de afiliado. Si haces clic en ellos, podría ganar una pequeña comisión (no te cuesta nada, y me ayuda a seguir enviando artículos de calidad todos los días para tu placer de lectura).