Matomo 5.10 en cámaras: métricas, roles y salida
Un caso anonimizado muestra cómo una cámara ordena métricas web con Matomo On-Premise, roles, API y respaldo sin depender de capturas sueltas.
Una campaña con 1.800 matriculados puede quedar sin lectura si la métrica vive en capturas reenviadas por chat. En una cámara profesional de Cuyo, Matomo 5.10 permitió separar sitios, usuarios, objetivos y reportes sobre una instalación propia, con una vista distinta para administración y comisión. Este caso explica qué dato captura el sitio, dónde se guarda, quién lo consulta y cómo probar exportación y restauración.
Dónde aparece la métrica sin dueño
La guía de Matomo On-Premise plantea una instalación propia para conservar los datos en servidores administrados por la organización. La misma página sostiene que Matomo On-Premise es usado por el 10% de los 10.000 sitios principales. Para una cámara cuyana, ese dato global ayuda a separar moda de operación verificable. El release Matomo 5.10.1 fue publicado el 29 de mayo. La decisión local no dependía de la versión por sí sola: la secretaria administrativa necesitaba saber cuántas visitas llegaban a una inscripción, qué campaña las traía, qué página cortaba el recorrido y quién podía mirar esos reportes. La captura reenviada era el antagonista. El objeto visible era un banner impreso de una capacitación, apoyado sobre una caja de credenciales con cordón rojo. El QR llevaba al formulario, pero el reporte quedaba en una imagen pegada en un chat. La cámara necesitaba una consulta repetible, permisos por área y una salida exportable para comisión directiva.
Cómo funciona por dentro
El flujo empieza cuando el sitio incorpora el código de seguimiento o usa la API de tracking. Matomo recibe visita, evento, campaña, objetivo, origen, navegador y hora. La aplicación PHP procesa esos datos y una base MySQL o MariaDB guarda visitas, acciones, sitios, usuarios, permisos y configuración. Los procesos de archivo preparan reportes para que el tablero responda sin recalcular todo en cada consulta. La guía de permisos separa view, write, admin y super user. Comunicación puede ver campañas; administración puede revisar objetivos; sistemas administra sitios, tokens, actualización y backup; comisión mira reportes agregados. La guía de API permite pedir reportes, administrar sitios y registrar datos desde otras aplicaciones. El backup copia base, archivos de configuración, plugins, logs necesarios y versión instalada. La prueba restaura una campaña de inscripción, abre el tablero, exporta el reporte por API y compara visitas, objetivos, usuario autorizado y fecha de cierre. La API de GitHub releases confirma Matomo 5.10.1 como release estable reciente. El dato global de GitHub Octoverse muestra que los equipos agregan automatizaciones y reportes en sistemas propios a velocidad creciente. Para una institución chica, la pregunta operativa es quién puede ver datos de socios y cuánto tiempo se conserva cada medición.
Qué se instala o configura primero
La pila mínima usa Matomo 5.10, PHP, MariaDB o MySQL, proxy HTTPS, SMTP, backup, monitoreo y una política de retención. Un despliegue chico para uno a cinco sitios queda entre USD 90 y USD 230 mensuales si incluye servidor, base, dominio, TLS, copia externa y alertas. Con dólar vendedor oficial de ARS 1.462, el rango mensual va de ARS 131.580 a ARS 336.260. La implementación inicial lleva 30 a 55 horas: instalación, sitios, usuarios, objetivos, campañas UTM, reportes, API, retención y restauración. El primer entregable verificable es una campaña de prueba con QR, objetivo, reporte exportado, permiso de lectura y restauración documentada. UMSA puede acompañar el caso desde la separación de roles y la prueba de salida. La cámara conserva su comunicación; Matomo guarda la medición en una base propia y entrega reportes por usuario. Si la entidad cambia de proveedor, debe llevarse configuración, base, reportes exportados y procedimiento de restauración. La política de privacidad se escribe antes de medir. Los formularios de socios, pagos o expedientes no deben mezclarse con eventos web innecesarios. La métrica útil para conducción es visita, campaña, página, objetivo y fecha. El dato personal sensible queda fuera del evento o se registra en el sistema que corresponde.
Dónde se rompe y cómo probarlo
El primer riesgo es el código de seguimiento ausente. La señal aparece cuando una página de inscripción recibe tráfico y Matomo no registra visitas. La prueba abre sitio, formulario y página de cierre; cada paso debe aparecer con hora y campaña. El segundo riesgo es el permiso excesivo. La señal aparece cuando comunicación puede cambiar configuración o ver todos los sitios. La prueba crea perfiles view, write, admin y super user; cada uno intenta leer, editar, borrar y exportar. El tercer riesgo es el token de API compartido. La señal aparece cuando varios reportes salen con la misma credencial. La prueba crea tokens por integración, revoca uno y verifica que el resto siga funcionando. El cuarto riesgo es la retención confusa. La señal aparece cuando una comisión pide comparar campañas y los datos históricos ya fueron borrados. La prueba define plazo, ejecuta un reporte viejo y guarda evidencia de archivo. El quinto riesgo es la restauración incompleta. La señal aparece cuando vuelve la base, pero faltan plugins, configuración o tareas de archivo. La prueba restaura en otro servidor, corre archivo y exporta el mismo reporte. Una cámara puede discutir comunicación cuando el reporte se puede abrir, repetir y llevarse.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.