Analítica web autoalojada: opciones para un VPS

¿Qué herramienta de analítica web autoalojada debería ejecutar en un VPS?

La analítica web autoalojada se divide en dos familias, y elegir la familia incorrecta cuesta más que elegir el producto incorrecto. Una familia ejecuta un script pequeño en el navegador del visitante y almacena lo que informa ese script. La otra familia lee el registro de acceso que ya escribe el servidor web. Todo lo demás, incluida la base de datos y la memoria que necesita, depende de esa elección.

La respuesta breve para un servidor pequeño. GoatCounter y Medama caben en 1 GB, porque cada uno consta de un proceso que trabaja sobre un archivo. Umami añade un contenedor de Postgres y ofrece un panel que una persona sin conocimientos técnicos puede entender. Plausible Community Edition y Rybbit utilizan ClickHouse, así que debe prever 2 GB de RAM o más. Matomo es el producto completo y requiere un servidor dimensionado para el tráfico. GoAccess no añade nada a la página, porque lee un registro que ya existe.

Etiqueta de script o registro del servidor: qué puede ver cada uno

Una etiqueta de script mide los navegadores. La página se carga, el script se ejecuta y envía una petición al recopilador. Todo lo que interrumpa esa cadena queda fuera de su alcance: JavaScript desactivado, una lista de filtros que bloquea la petición, una petición fallida al recopilador o un crawler que nunca ejecuta scripts.

Un analizador de registros mide las peticiones. El servidor web escribe una línea por cada petición, tanto si instala algo como si no, de modo que los datos ya están en el disco. Ve todos los crawlers y todas las visitas a archivos que no incluyen una etiqueta de script. No puede ver lo que ocurre dentro del navegador. Tampoco puede ver una página servida desde la caché del navegador o desde una CDN (red de distribución de contenido) situada delante de su servidor, porque esa petición nunca llegó a él.

Las dos cifras no coincidirán, y ninguna es incorrecta. Matomo puede hacer ambas cosas. Su documentación indica qué datos se pierden al importar registros frente a usar su tracker de JavaScript: resolución de pantalla y títulos de página, eventos, seguimiento de contenido, mapas de calor, grabaciones de sesiones y analítica de formularios. Esa es la limitación de contar peticiones en lugar de navegadores.

El tráfico de bots explica la otra mitad de la diferencia. Los recuentos basados en registros incluyen crawlers salvo que los filtre. En un sitio normal, la proporción de crawlers es suficientemente alta como para cambiar sus conclusiones. GoAccess y la importación de registros de Matomo filtran los bots conocidos. Ninguno puede filtrar un crawler que falsifica su agente de usuario. Por eso conviene combinar cualquier recuento basado en registros con el bloqueo de crawlers de IA en el servidor y leer el registro después del bloqueo, no antes.

GoAccess: análisis de los registros existentes

Instálelo desde el repositorio propio del proyecto para Debian y Ubuntu, porque los paquetes de la distribución tardan en incorporar las nuevas versiones.

wget -O - https://deb.goaccess.io/gnugpg.key | gpg --dearmor | sudo tee /usr/share/keyrings/goaccess.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/goaccess.gpg arch=$(dpkg --print-architecture)] https://deb.goaccess.io/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/goaccess.list
sudo apt-get update
sudo apt-get install goaccess

A continuación, indíquele el registro y genere un informe estático.

goaccess /var/log/nginx/access.log -o ~/report.html --log-format=COMBINED

Ese comando falla con Permission denied para un usuario normal, porque en Ubuntu el registro de nginx pertenece a root y al grupo adm. Añádase a ese grupo con sudo usermod -aG adm $USER y cierre la sesión e iníciela de nuevo, porque la pertenencia a grupos se lee al iniciar sesión. Ejecute id y compruebe que adm aparece en la lista antes de volver a intentarlo.

Un informe sobre el registro activo sólo incluye las entradas que logrotate todavía no ha movido. Las peticiones de ayer están en access.log.1 y las anteriores están comprimidas, por lo que una vista semanal también debe leer los archivos rotados.

zcat /var/log/nginx/access.log.*.gz | goaccess - --log-format=COMBINED -o ~/last-week.html

También existe un modo en tiempo real, --real-time-html, que actualiza la página mediante un WebSocket. Requiere un segundo puerto y su propia regla del proxy. Para la mayoría de los sitios, basta con generar un informe cada hora mediante cron, y hay menos elementos que proteger.

GoatCounter: un binario de Go y un archivo SQLite

GoatCounter se distribuye como un binario compilado estáticamente, por lo que no es necesario instalar ningún entorno de ejecución. Descargue una compilación de la página de versiones y ejecútela, o use la imagen.

docker run -p 8080:8080 -v goatcounter-data:/home/goatcounter/goatcounter-data arp242/goatcounter

Como binario, goatcounter serve escucha en el puerto 8080 y crea la base de datos SQLite en ./goatcounter-data/db.sqlite3. Cree el primer sitio desde la línea de comandos en lugar de usar el asistente web cuando la instancia ya esté detrás de un proxy.

goatcounter db create site -vhost=stats.example.com -user.email=me@example.com

Puede gestionar su propio certificado con goatcounter serve -listen=:443 -tls=tls,rdr,acme mediante ACME (entorno de gestión automática de certificados), lo que resulta útil en un servidor que no ejecuta ningún otro servicio. Si nginx o Caddy ya administra el puerto 443, deje GoatCounter en el puerto 8080 y configure el proxy para que reenvíe las peticiones. El script de seguimiento ocupa alrededor de 3.5K según la cifra del propio proyecto, y también existe un píxel de seguimiento para las páginas que no incluyen JavaScript. Si SQLite se convierte en el límite de un sitio con mucha carga, el mismo binario admite Postgres mediante goatcounter serve -db 'postgresql+dbname=goatcounter'. Las copias de seguridad consisten en copiar un archivo, que es el principal argumento a favor de este tipo de herramienta.

Medama: un contenedor único que afirma consumir 256 MB

Medama es la opción de un único binario más reciente de esta guía. Está diseñado para no usar cookies y el proyecto indica que el rastreador ocupa menos de 1 KB, además de afirmar que permite ejecutar sitios pequeños en máquinas virtuales con 256 MB de memoria. Esas son las cifras publicadas por el proyecto, no mediciones realizadas para esta guía.

docker volume create medama-data
docker run -d -p 127.0.0.1:8080:8080 -v medama-data:/app/data ghcr.io/medama-io/medama:latest

El comando oficial publica el puerto como 8080:8080. El prefijo de loopback anterior es intencionado y la sección sobre el reverse proxy explica el motivo. El primer inicio de sesión se realiza con admin y la contraseña es CHANGE_ME_ON_FIRST_LOGIN; el nombre de esa contraseña es la instrucción.

Hay un modo de fallo documentado que debe tener en cuenta. El inicio de sesión sólo funciona mediante HTTPS o en localhost. Por tanto, si configura el proxy antes que el certificado, el formulario rechaza una contraseña correcta y no muestra el motivo. Complete primero la configuración de TLS (transport layer security) y después inicie sesión.

Umami: PostgreSQL y un panel que resulta familiar

git clone https://github.com/umami-software/umami.git
cd umami
docker compose up -d

Esto inicia la aplicación en el puerto 3000 junto con un contenedor de PostgreSQL. La documentación indica PostgreSQL v12.14 como versión mínima y Node.js 18.18 o posterior si compila desde el código fuente. Existe una imagen precompilada, docker.umami.is/umami-software/umami:postgresql-latest, que necesita que DATABASE_URL apunte a una base de datos que ya esté en ejecución.

El primer inicio de sesión es admin con la contraseña umami. Cámbiela antes de apuntar el DNS al servidor, porque la instancia queda accesible desde Internet en cuanto el registro resuelve y el proxy responde. Para consultar los detalles de Compose, los archivos de entorno y la política de reinicio, vea una pila de Docker Compose en un VPS en lugar de copiar una pila que no haya leído.

El consumo se limita a un proceso de Node y PostgreSQL. Es más pesado que un binario único y mucho más ligero que cualquier opción que ejecute ClickHouse.

Plausible Community Edition: ClickHouse fija el mínimo de RAM

git clone -b v3.2.1 --single-branch https://github.com/plausible/community-edition plausible-ce
cd plausible-ce
touch .env
echo "BASE_URL=https://stats.example.com" >> .env
echo "SECRET_KEY_BASE=$(openssl rand -base64 48)" >> .env
docker compose up -d

La versión v3.2.1 es la actual en agosto de 2026, y el comando clone la fija de forma intencionada. La pila tiene tres partes: la aplicación, Postgres para las cuentas y la configuración, y ClickHouse para los datos de eventos. SECRET_KEY_BASE debe ser una cadena de al menos 64 bytes, que es lo que genera la llamada openssl.

Los requisitos de Plausible piden al menos 2 GB de RAM para que ClickHouse y la aplicación no activen el OOM killer, además de una CPU compatible con SSE 4.2 o NEON, que ClickHouse necesita. Conviene comprobar este segundo requisito antes de comprar, ya que es una diferencia práctica al elegir entre un VPS ARM y uno x86. ClickHouse también usará tanta memoria como crea disponible. En un servidor compartido, establezca un límite como se describe en limitar la memoria de los contenedores en Compose.

BASE_URL debe coincidir exactamente con la URL pública. Si no coincide, inicia sesión, la aplicación redirige al host incorrecto y la cookie de sesión se escribe para un dominio en el que el navegador no está. Por eso vuelve al formulario de inicio de sesión sin mostrar ningún mensaje de error.

El archivo compose incluido no publica ningún puerto, porque se presupone que habrá un proxy delante. Añada un override que publique el puerto de aplicación predeterminado sólo en loopback.

cat > compose.override.yml << EOF
services:
    plausible:
        ports:
            - 127.0.0.1:8000:8000
EOF

Matomo: el producto completo y el servidor que necesita

Matomo se ejecuta con PHP y MySQL o MariaDB, por lo que encaja en la pila web clásica y no en una pila de contenedores. También es la única herramienta de esta guía que publica recomendaciones de hardware según el volumen de tráfico.

[
  {
    "label": "100K/month",
    "cpu_cores": 2,
    "ram_gb": 2,
    "disk_gb": 50
  },
  {
    "label": "1M/month",
    "cpu_cores": 4,
    "ram_gb": 8,
    "disk_gb": 250
  },
  {
    "label": "10M/month",
    "cpu_cores": 8,
    "ram_gb": 16,
    "disk_gb": 400
  }
]

Esos son los requisitos mínimos publicados por Matomo en agosto de 2026, no mediciones realizadas para esta guía. Hasta 100,000 páginas vistas al mes, necesita 2 núcleos de CPU, 2 GB de RAM y 50 GB de SSD. Un solo servidor aloja la aplicación y la base de datos. En 1M/month, la recomendación pasa a ser 8 GB de RAM y 250 GB de disco. En 10M/month, Matomo recomienda dos servidores. La última fila muestra los requisitos del servidor de base de datos: 16 GB de RAM y 400 GB de disco. Compare esas cifras de disco con las opciones independientes, en las que todo el conjunto de datos se almacena en un único archivo SQLite.

El archivado es lo que suele sorprender. De forma predeterminada, Matomo genera los informes cuando alguien abre el panel. A medida que crecen los datos, el panel se vuelve más lento y finalmente agota el tiempo de espera. La solución documentada consiste en desactivar el archivado activado por el navegador en la configuración general y ejecutar el archivador desde cron, con el usuario propietario de los archivos de Matomo y desde el directorio de Matomo.

php console core:archive --url=https://analytics.example.com

Matomo también conserva tablas de registros sin procesar junto a las tablas de informes procesados. Puede eliminar los datos sin procesar antiguos y los informes antiguos según una programación. Active esta opción durante la instalación, no cuando el disco ya esté lleno. Matomo también puede importar registros de acceso del servidor, por lo que es el único producto de esta guía que cubre ambas familias a la vez.

Rybbit y las pilas más recientes

git clone https://github.com/rybbit-io/rybbit.git
cd rybbit
chmod +x *.sh
./setup.sh your.domain.name

Rybbit es una incorporación reciente con un panel moderno. El script de instalación escribe el archivo de entorno y levanta la pila con Docker Compose. Ejecuta ClickHouse e incluye Caddy como servidor web propio. Caddy ocupa el puerto 443 y solicita un certificado para el dominio que se le indique. Si nginx ya usa el puerto 443 en el servidor, el script no podrá enlazarlo. En ese caso, use el procedimiento manual con Compose del proyecto y colóquelo detrás del proxy existente. La documentación indica al menos 2 GB de RAM, pruebas en Ubuntu 24 LTS y ARMv8.2-A o una versión posterior en ARM debido a ClickHouse.

La advertencia aplicable a cualquier proyecto joven es clara: las funciones se incorporan rápidamente y los cambios incompatibles también. Fije una etiqueta, lea las notas de la versión antes de hacer pull y cree primero una copia de seguridad de la base de datos.

Retención y crecimiento del disco: mídalos en su propio servidor

El crecimiento del disco depende de lo que la herramienta almacena por evento. GoatCounter agrega las visitas en contadores, por lo que su archivo crece más según las páginas y los días distintos que según el volumen bruto. Umami y Matomo almacenan una fila por evento, y Matomo añade tablas de informes procesados a las tablas sin procesar. ClickHouse almacena los eventos por columnas y los comprime mucho. Por eso Plausible soporta un volumen que sometería a mucha presión a un almacén basado en filas.

Esta guía no publica una cifra de megabytes por millón de visitas de página porque no la ha medido con su tráfico. Tome la medición usted mismo. Ajuste los nombres del servicio y del usuario para que coincidan con su archivo de Compose.

du -h goatcounter-data/db.sqlite3
docker compose exec db psql -U umami -d umami -c "SELECT pg_size_pretty(pg_database_size('umami'));"
docker compose exec plausible_events_db clickhouse-client -q "SELECT formatReadableSize(sum(bytes_on_disk)) FROM system.parts WHERE active"

Anote el número, espere una semana, vuelva a anotarlo y divida la diferencia entre las visitas de página que el panel informa para esa semana. Esa cifra corresponde a su sitio y a su filtrado de bots, por lo que es más útil que cualquier promedio publicado. Después, establezca un límite de retención mientras el número todavía sea pequeño. Un disco lleno detiene todos los servicios del VPS, no sólo la analítica. Este es el argumento más importante para mantener el volumen de la base de datos en un lugar sobre el que df -h le avise. Ese riesgo merece más atención en un servidor que ya almacena algo voluminoso, porque un servidor de fotos autohospedado agotará el disco mucho antes de que cualquier base de datos de analítica se acerque a ese límite.

Cómo se comporta detrás de un reverse proxy en un subdominio

Coloque el collector en un subdominio del sitio que mide, como stats.example.com. Así, las solicitudes al collector se consideran de primer origen y no se ven afectadas por las reglas del navegador que bloquean las solicitudes de terceros.

Enlace la aplicación a loopback cuando publique el puerto del contenedor. Docker escribe sus propias reglas de firewall antes que ufw, por lo que un contenedor publicado como -p 3000:3000 es accesible desde Internet aunque ufw status indique que el puerto está denegado. Pruébelo desde otra máquina con curl http://SERVER_IP:3000 y verá el panel. Publicado como -p 127.0.0.1:3000:3000, la misma prueba devuelve Connection refused y sólo el proxy puede acceder a él. Este mismo criterio no sólo oculta un panel: es fundamental para ejecutar un servicio onion en el mismo equipo, donde cualquier servicio que siga respondiendo en la interfaz pública permite vincular la dirección oculta con su IP. El endpoint del recolector debe seguir siendo accesible desde Internet, pero el panel no. Si prefiere consultarlo a través de una red privada en lugar de publicar un segundo subdominio, anunciar la red del VPS a su tailnet con un router de subred le permite hacerlo sin abrir un puerto.

server {
    listen 443 ssl;
    server_name stats.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Las cabeceras de reenvío son obligatorias en este caso. Sin X-Forwarded-For, todas las visitas llegan desde 127.0.0.1, por lo que el informe por país queda vacío y los visitantes únicos tienden a reducirse a uno. Cada proyecto decide qué cabecera acepta y con qué configuración, así que revise una vez su documentación sobre proxies en lugar de asumirlo. Caddy establece esas cabeceras por sí mismo, y un Caddyfile para la misma tarea tiene dos líneas.

stats.example.com {
    reverse_proxy 127.0.0.1:3000
}

Si todavía no ha elegido un proxy, la comparación de nginx, Caddy y Traefik explica cuál se adapta mejor a un solo equipo con varios subdominios.

¿Sigues necesitando un banner de cookies si alojas el servicio por tu cuenta?

El alojamiento propio cambia quién conserva los datos. No cambia lo que establece la ley sobre esos datos. Hay que separar dos reglas. La regla de consentimiento de ePrivacy se refiere a almacenar o leer cualquier dato en el dispositivo del visitante, por lo que una herramienta que no establece ninguna cookie ni escribe nada en el almacenamiento local queda fuera de ese requisito concreto. El RGPD se refiere al tratamiento de datos personales, y una dirección IP cuenta como dato personal. Por tanto, sigues necesitando una base jurídica, un plazo de conservación y una respuesta cuando alguien pregunte qué datos conservas sobre esa persona.

Plausible, Umami, GoatCounter y Medama no establecen ninguna cookie de forma predeterminada. Lo que deriva cada uno en su lugar varía según el proyecto y cambia entre versiones, así que consulta la documentación de privacidad del propio proyecto en lugar de un resumen. Matomo incluye anonimización de IP y un endpoint de exclusión voluntaria que debes habilitar en la interfaz de administración.

Los organismos reguladores llegan a conclusiones diferentes en cada país. Por ejemplo, la CNIL francesa publica las condiciones en las que la medición de audiencia puede estar exenta del consentimiento. Esta sección es un resumen informativo y no constituye asesoramiento jurídico. Para un sitio real con usuarios reales, consulta a un abogado de tu jurisdicción.

Hay un aspecto que suele pasarse por alto: un registro de acceso también contiene datos personales. GoAccess no añade ningún script a la página y aun así procesa direcciones IP, por lo que la analítica basada en registros no queda automáticamente fuera de la normativa. Trasladar un servicio a tu propio servidor reubica la exposición, pero no la elimina. Por eso lo que realmente oculta una instancia de SearXNG alojada por tu cuenta termina en los motores de búsqueda, mientras que las consultas siguen quedando en tus propios registros.

Bloqueadores de anuncios y por qué disminuirán sus cifras

Las listas de filtros buscan coincidencias en el nombre de host y en el patrón de la URL. Un producto de analítica alojado es fácil de identificar porque todo el mundo lo carga desde el mismo nombre de host conocido. Si mueve el recopilador a su propio subdominio, ese nombre de host desaparece de la solicitud. Si sirve el script desde una ruta que haya elegido, también desaparece el nombre de archivo conocido. Ambos cambios modifican los datos con los que debe trabajar una lista de filtros.

Esta publicación no afirma una tasa de bloqueo porque no la midió. La proporción de visitantes que bloquea una configuración concreta depende de su audiencia. Una audiencia de desarrolladores bloquea mucho más que una audiencia general. Mida su propia diferencia. Durante la misma semana, cuente con GoAccess las solicitudes de páginas HTML en el registro de acceso y compárelas con las páginas vistas que informa su herramienta basada en scripts. La diferencia corresponde a visitas bloqueadas y a páginas servidas desde la caché de su sitio.

Espere que los totales cambien el día que deje de usar un producto alojado. También debe asumir que parte de ese cambio no tendrá relación con el bloqueo. Los productos no coinciden en la definición de página vista, en si un cambio de ruta dentro de una aplicación de una sola página cuenta como una página vista ni en el momento en que termina una sesión. Compare las tendencias de varias semanas antes de concluir que el tráfico disminuyó.

Cuál usar para cada sitio

• Un sitio personal o un blog con menos de aproximadamente 50,000 páginas vistas al mes: GoatCounter o Medama, en un VPS de 1 GB, con copias de seguridad que consistan en copiar archivos.
• Un sitio donde no pueda añadir un script, o con una audiencia que bloquee scripts de forma generalizada: GoAccess sobre el registro existente, ejecutado según una programación.
• Un sitio de una pequeña empresa cuyo panel vaya a consultar otra persona: Umami, con su contenedor de Postgres.
• Un sitio en el que quiera configurar objetivos y embudos, en un equipo con 2 GB de RAM o más: Plausible Community Edition, o Rybbit si quiere el panel más reciente y acepta un proyecto más joven.
• Muchos sitios, muchas cuentas de usuario o la necesidad de conservar los datos sin procesar según su propia política de retención: Matomo, dimensionado según las indicaciones publicadas anteriormente.

Empiece con la herramienta más pequeña que responda a su pregunta real. Pasar de GoatCounter a Plausible más adelante sólo requiere un subdominio y le permite conservar parte del historial. Pasar de Matomo a cualquier otra opción requiere una migración que no será sencilla. Si todavía está decidiendo qué más alojar en el mismo equipo, la comparativa general de servicios autoalojados explica qué puede añadir junto a él. Si lo que realmente necesita es trazabilidad a nivel de solicitud de una aplicación, en lugar de recuentos de visitantes, un servicio de observabilidad autoalojado es la herramienta adecuada.

FAQ

¿El uso de analítica autohospedada elimina la necesidad de un aviso de cookies?

No, y son dos cuestiones distintas. La regla de consentimiento de ePrivacy se aplica al almacenamiento o la lectura de datos en el dispositivo del visitante. Por tanto, una herramienta que no establece ninguna cookie ni escribe datos en el almacenamiento local queda fuera de ese requisito concreto. GDPR es una norma diferente y se aplica al tratamiento de datos personales. Una dirección IP es un dato personal, por lo que aun sin cookies necesita una base jurídica y un límite de conservación. El autohospedaje traslada los datos a su servidor y hace que usted sea la parte responsable de ellos. Consulte las directrices de su autoridad de control y pida asesoramiento jurídico para su caso.

¿Cuánta RAM necesita la analítica autohospedada en un VPS?

La capacidad de almacenamiento de datos es el factor determinante, no el panel. GoatCounter y Medama se ejecutan como un único proceso sobre un único archivo, y la documentación de Medama indica que los sitios pequeños funcionan en máquinas con 256 MB. Umami añade un contenedor de Postgres junto a una aplicación Node. Plausible Community Edition y Rybbit ejecutan ClickHouse, y ambos proyectos indican un mínimo de 2 GB. Las propias recomendaciones de Matomo parten de 2 núcleos de CPU y 2 GB de RAM para hasta 100,000 pageviews al mes.

¿Por qué las cifras autohospedadas son inferiores a las de la analítica que sustituí?

Hay dos causas, y ambas son reales. Las listas de filtros bloquean algunas peticiones al recopilador, por lo que todas las herramientas basadas en scripts pierden esas visitas. Además, los productos cuentan de forma diferente, porque varían la definición de pageview y el momento en que termina una sesión. Compare una semana de peticiones de páginas HTML de su access log con la misma semana de pageviews basados en scripts. Esa diferencia corresponde a visitas bloqueadas más páginas servidas desde la caché, medida en su propio sitio en lugar de basarse en el porcentaje publicado por otra persona.

¿Puedo ejecutar Plausible o Rybbit en un VPS ARM?

Ambos ejecutan ClickHouse, y ClickHouse necesita SSE 4.2 en x86 o NEON en ARM. Los requisitos de Plausible lo indican exactamente así, y la documentación de Rybbit señala que los sistemas ARM necesitan ARMv8.2-A o una versión posterior. Los núcleos ARM actuales para servidores cumplen ese requisito, pero los más antiguos no. El fallo aparece cuando ClickHouse se niega a iniciar con un error del conjunto de instrucciones, no como un mensaje del registro de la aplicación. En un equipo ARM pequeño, las herramientas que usan un único archivo evitan esta cuestión, porque ninguna ejecuta ClickHouse.

¿Debería analizar los registros del servidor en lugar de usar un script de seguimiento?

Use el análisis de registros cuando no pueda añadir un script, cuando su audiencia bloquee muchos scripts o cuando quiera un recuento que incluya crawlers. GoAccess lee un registro que su servidor ya escribe, por lo que no añade peso a las páginas ni necesita una base de datos. A cambio, pierde todo lo que ocurre dentro del navegador y no registra las páginas servidas desde una CDN o desde la caché del navegador, porque esa petición nunca llegó al servidor. Muchos sitios ejecutan ambos métodos y los tratan como dos mediciones diferentes.