Postura de datos de analytics.

ÚLTIMA ACTUALIZACIÓN · September 17, 2026 (first published)

Esta página existe para entregársela a quien revise tu instalación. Describe el tag mag.js campo por campo: qué sale del navegador, qué nunca sale, qué se protege antes de enviarse, y cada interruptor que controlas. Si lo que buscas es cómo magig maneja tus datos como cliente, eso es la política de privacidad. Esta página es sobre tus visitantes.

La versión corta: la captura automática está diseñada para poder dejarse encendida dentro de un producto autenticado. Los ids de registro se quitan de las rutas, los query strings se descartan salvo que estén nombrados, y el texto dentro de los controles de formulario nunca se lee. Las tres cosas están activas por defecto, sin configuración.

01Qué manda cada evento

Cada evento lleva este sobre:

• project key — el id público de tu tracker, el que se ve en el script tag.
• anonymous id — un identificador aleatorio guardado en una cookie propia o en localStorage. No se deriva de nada personal y no se comparte entre nuestros clientes.
• session id — un id aleatorio que agrupa una visita.
• timestamp — cuándo se disparó el evento, según el reloj del navegador.
• URL y ruta de la página — después de la redacción (sección 03). Los segmentos de ruta con forma de id se reemplazan y los parámetros de query sin nombrar se quitan antes de enviar.
• referrer — cuando está presente, se redacta igual. Dentro de una app el referrer es la pantalla anterior, así que recibe el mismo tratamiento.
• atribución — los parámetros de campaña de la URL de llegada (utm_*, gclid, fbclid, ttclid, ref), para que tu propio dashboard pueda atribuir un registro al ad que lo produjo.
• user agent — el string de UA del navegador, truncado a 1 024 caracteres. Al llegar se parsea en tipo de dispositivo, navegador y sistema operativo; el string en crudo no se guarda en el evento.

Campos específicos por evento: un click agrega la etiqueta del elemento, su texto visible (los primeros 120 caracteres, sujeto a enmascarado), el id del elemento, el destino del enlace y las coordenadas del clic más el tamaño del viewport para los heatmaps. Un scroll agrega solo un porcentaje de profundidad. Una conversion o un identify agregan exactamente lo que le pases a window.mag.track() o window.mag.identify(): esas son tus propias llamadas, y mandamos lo que pongas en ellas.

02Qué nunca manda

• Nada de lo que se escriba en un formulario. Nunca se lee texto de los elementos <input>, <textarea>, <select> ni <option>. Ni truncado, ni hasheado: no se lee.
• Pulsaciones de teclas. No hay keylogging de ningún tipo.
• El contenido de la página en general. Capturamos el elemento en el que el visitante hizo clic, no el documento alrededor. No hay snapshot del DOM ni session replay.
• Las direcciones IP de tus visitantes. La IP del pedido se usa de forma transitoria para buscar un país y después se descarta: nunca se escribe en la tabla de eventos.
• Cookies de rastreo de terceros. El almacenamiento es solo propio, limitado a tu dominio, y nunca se usa para seguir a un visitante al sitio de nadie más.
• Datos mezclados entre clientes. Los eventos de tus visitantes pertenecen a tu proyecto.

03Protecciones activas por defecto

No requieren configuración. Un founder que pega el snippet y no lee nada más igual recibe las tres.

• Plantillado de rutas. Los segmentos de ruta con forma de id se reemplazan antes de enviar, así /requests/df7b4d99-898b-4b10-929d-6d0ee58a4be3 se manda como /requests/:id. La coincidencia es por forma, no por posición, y las formas son deliberadamente conservadoras: un slug de contenido como /pillar/clinica-medica/module/gastroenterologia pasa intacto. Plantillar de más es visible y recuperable; plantillar de menos es silencioso, así que la regla se inclina por dejar en paz las palabras legibles.
• Allowlist de query. Solo sobreviven los parámetros nombrados: los parámetros de campaña de la sección 01. Todo lo demás se descarta, incluidos los parámetros de los que nunca hemos oído. Esto es una allowlist y no una denylist a propósito: una denylist deja pasar justo el parámetro que a nadie se le ocurrió enumerar, que confiablemente es el que lleva un token o un id de registro.
• Enmascarado del texto de los clics. El texto nunca se toma de los controles de formulario, ni de nada que esté dentro de un elemento marcado con data-mag-private. Un elemento enmascarado no manda ningún campo de texto, en vez de mandar un placeholder.

Los destinos de los enlaces y los ids de los elementos pasan por la misma redacción que cualquier URL, porque href="/invoices/91f8-…" e id="invoice-12345" son dos de las formas más directas en que un id de registro se escapa en un clic.

04Qué puedes cambiar

Todos estos son atributos del script tag.

• data-exclude-paths="/app/*,/admin/*" — apaga la captura automática por completo en las rutas que coincidan. Se compara contra la ruta real, antes del plantillado. Tus propias llamadas a track() siguen disparándose, así que un registro detrás de un prefijo excluido igual se mide. identify() sigue registrando quién es la visita — las conversiones posteriores la llevan — pero no manda un evento propio desde una ruta excluida.
• data-mask-text=".client-name,.amount" — nunca manda texto de los elementos que coincidan con estos selectores.
• data-capture-query="utm_source,plan" — reemplaza la allowlist por defecto cuando necesitas conservar un parámetro específico.
• data-template-paths="false" — se sale del plantillado de rutas. Vale decirlo claro: esto hace la captura menos privada, y existe para apps cuyas rutas no llevan ids.
• data-disable="true" — el tag carga y no hace nada.
• data-mag-private — no es un atributo del script sino un marcador que pones en cualquier elemento de tu propio markup. Nada debajo de él reporta texto.

Agrega data-debug="true" mientras configuras y el SDK registra qué manda, y avisa en la consola cuando un selector de data-mask-text no coincide con ningún elemento, así un typo no se confunde con protección.

05Verificarlo tú

Nada de lo anterior hace falta tomarlo por fe. Abre tu pestaña de red, filtra por el pedido de ingest y lee el JSON: la redacción corre en el navegador, antes de que el pedido se envíe, así que lo que ves en ese payload es todo lo que sale. El tag se sirve lo suficientemente sin minificar como para leerlo en assets.magig.app/mag.js.

Que sea del lado del cliente es una decisión deliberada. Redactar en nuestros servidores significaría que el valor ya cruzó el cable, lo que es una promesa y no un control.

06Preguntas

Cualquier cosa que esta página no responda, incluido un campo específico sobre el que quien revisa necesite un dictamen, va a hi@magig.app. Si encuentras algo que el tag captura y que esta página no describe, dínoslo y lo vamos a tratar como un bug en el tag o un bug en esta página.