GA4 Manager

## El problema

## Decisiones clave

1. La configuración vive en un YAML

   Una propiedad GA4 se describe en un fichero que se versiona junto al código, y un comando la aplica. La opción --dry-run, para ver los cambios antes de tocar nada, ya estaba en la primera versión estable (1.0.0, 22 de noviembre de 2025).

2. API Admin v1alpha, a sabiendas

   Las dimensiones y métricas personalizadas y los grupos de canales solo existen en la v1alpha. Google puede cambiarla sin periodo de deprecación, y lo dejé escrito como decisión de arquitectura, con la obligación de vigilar sus notas de versión.

3. Permisos mínimos, separados por operación

   Las escrituras (setup, cleanup, link) piden el permiso de edición de Analytics; los informes y la validación, solo lectura. Una cuenta de solo lectura no puede ejecutar por error nada destructivo.

4. Un registro de herramientas para el servidor MCP

   Empezó con un if/else por herramienta. Al crecer, cada una repetía validación y manejo de errores, así que lo sustituí por un registro: cada herramienta es una entrada con su esquema y su ejecución, y todas pasan por el mismo middleware.

5. Diagnósticos deterministas, con estado local

   Los diagnósticos de Search Console son consultas a la API, no un modelo opinando: qué tocar lo decido yo. Para comparar cada ejecución con la anterior guardan un JSON junto a la configuración, con versión de esquema y fuera de git. Descarté guardarlo en el directorio personal porque rompe el modelo de proyecto con configuración propia.

## Qué salió mal

1. El MCP se tragaba los resultados (2.3.0, 5 de junio de 2026)

   La capa del servidor trataba cualquier código de salida distinto de cero como un fallo. Pero los comandos de diagnóstico salen con 2 cuando encuentran algo, que es justo para lo que sirven. El asistente recibía solo el error y ninguno de los hallazgos. Ahora el 2 cuenta como éxito.

2. Un informe que Google ya no hace (2.4.0, 15 de junio de 2026)

   La herramienta marcaba como fallo la usabilidad móvil. Google retiró ese informe en diciembre de 2023 y el campo llegaba vacío, que se leía como suspenso. Desde la 2.4.0 solo se fía de un veredicto real y lo demás se muestra como «n/a».

3. Una lista vacía que no era un problema de SEO

   La consulta de sitemaps devolvió una lista vacía para uno que sí estaba enviado. Antes de reenviarlo lo comprobé con otra llamada y allí estaba: el fallo era de mi herramienta.

4. Un tiempo de espera con 40 URLs (3.4.0, octubre de 2026)

   La llamada MCP agotó los 30 segundos al inspeccionar 40 URLs y tuve que ejecutar la CLI directamente. La solución fue inspeccionar de cinco en cinco y dejar que el MCP espere hasta cinco minutos.

5. Mis propios documentos no cuadraban

   El README, el del servidor MCP y mi blog daban cifras distintas de herramientas disponibles. El ADR ya decía que la cifra debía derivarse del registro, y no lo hice. Por eso aquí no hay ningún recuento.

## Qué haría distinto

• Generaría el recuento de herramientas y la tabla del README a partir del registro, en vez de escribirlos a mano.
• Trataría los códigos de salida de la CLI como parte del contrato con el MCP desde el primer día, no como un detalle que se descubre cuando falla.
• Probaría el MCP con la lista real de URLs de un sitio mediano antes de publicarlo: el tiempo de espera salió con 40 URLs.
• Empezaría con los diagnósticos de Search Console y dejaría la configuración de GA4 para después: es lo que más ha cambiado cómo trabajo.

## Cifras, solo medidas y con fecha

54 s

para inspeccionar 38 URLs con la v3.4.0, frente a unos cuatro minutos y medio antes del arreglo · artículo actualizado el 6 de octubre de 2026

6.012 impresiones, 20 clics

de mi blog en 28 días (0,33 % de CTR, posición media 7,6), medidos con la propia herramienta. Son cifras de mi sitio, no de uso de GA4 Manager · del 6 de septiembre al 3 de octubre de 2026

No tengo cifras de adopción (instalaciones, estrellas, descargas) y no las invento.