Dominios, referrers y etiquetas
La lista blanca de dominios que controla la atribución, la lista de referrers ignorados y las etiquetas de eventos.
La pestaña Data tiene tres listas. Dos deciden cómo se atribuye tu tráfico y una simplemente hace la interfaz más fácil de leer.
De todo lo que hay en los ajustes del proyecto, la lista de dominios es la que más conviene dejar bien desde el primer día — es el único ajuste de acá cuyo efecto no se puede aplicar retroactivamente.
Dominios
Los dominios de tu proyecto se listan con el principal marcado como · primary. El dominio principal se deriva de la URL de tu proyecto y no se puede eliminar. Agrega más con el formulario debajo de la lista (placeholder: app.yourproduct.com).
Por qué importan los dominios
El colector usa tu lista de dominios como lista blanca de orígenes.
Un evento de navegador cuyo Origin no esté en la lista —o falte por completo— igual se acepta. No se descarta. Pero queda marcado como no atribuido, y se le quitan los campos de referrer, UTM y atribución.
Así que te quedas con el tráfico y pierdes la historia detrás. La visita cuenta; de dónde vino, no. Durante la configuración inicial, un evento desde un origen no listado ni siquiera aparece en la pantalla de prueba, y así es como la mayoría descubre el problema.
Si sirves tu app desde app.yourproduct.com además de yourproduct.com, agrega los dos. Si no, cada evento de tu subdominio de app llega sin fuente, sin campaña y sin referrer — y tu tabla de fuentes subestima en silencio los canales que traen uso real.
Sitio de marketing en el dominio raíz, producto en un subdominio, documentación en un tercer host: son tres entradas, y las tres tienen que estar.
Este es el ajuste para arreglar antes de acumular datos, no después. La atribución que se quita no se recupera — a diferencia de tu configuración de tracking, que puedes cambiar retroactivamente cuando quieras.
Validación
Los dominios se normalizan a un host en minúsculas. Se quitan el esquema, el www., el puerto y la ruta, así que https://www.Example.com:443/app queda como example.com.
Valores rechazados:
| Rechazado | Ejemplos |
|---|---|
| Comas o espacios | a.com, b.com |
| Comodines | *.example.com |
| Direcciones IPv4 sueltas | 192.168.1.10 |
localhost | localhost |
| Cualquier cosa con menos de 2 etiquetas | example |
| Hosts de más de 253 caracteres | — |
Una entrada inválida muestra Invalid domain.
No hay soporte para comodines, así que los subdominios se listan uno por uno.
| Límite | Valor |
|---|---|
| Máx. dominios | 64 |
Referrers ignorados
Un campo de texto — un host por línea, o separados por comas. Al guardar se reemplaza la lista entera.
El texto de ayuda: Domains that don’t count as a source (one per line): stripe.com, accounts.google.com…
El problema que resuelve
Los proveedores de pago y autenticación devuelven usuarios a tu sitio. Alguien hace clic en tu anuncio de Google, navega, paga por Stripe y aterriza en tu página de confirmación — con stripe.com como referrer.
Sin esta lista, Stripe aparece como fuente de tráfico. Eso engaña. Stripe no te trajo ese cliente; te lo devolvió. El usuario originalmente vino de otro lado, y ese otro lado es justo lo que estás tratando de medir.
Si lo dejas pasar, tu “fuente” con mejor conversión termina siendo tu propio flujo de checkout — un número cierto e inútil al mismo tiempo.
Entradas típicas:
stripe.com
checkout.stripe.com
accounts.google.com
github.com
paypal.comAgrega todo aquello por lo que tu stack hace pasar usuarios: procesadores de pago, proveedores OAuth, portales SSO, enlaces de verificación de email.
Misma validación de host que en dominios, con una diferencia: las entradas inválidas se descartan en silencio en vez de dar error. Si una línea no sobrevive al guardado, no era un host válido.
| Límite | Valor |
|---|---|
| Máx. referrers ignorados | 64 |
Tus propios dominios no hace falta que estén acá — un referrer que coincide con tu propio host ya se ignora como navegación interna. Mira fuentes para el orden completo de clasificación.
Etiquetas de eventos
Mapean un nombre de evento a un nombre amigable para mostrar:
account_created → Signup
ticket_purchased → Ticket sold
fv_project_created → First projectTu código sigue enviando account_created; la interfaz muestra Signup.
El texto se trunca a 60 caracteres, así que mantén las etiquetas cortas — son títulos, no oraciones.
Las etiquetas aparecen en:
- la franja de estadísticas de Pulse,
- el embudo del recorrido,
- los títulos de los gráficos,
- las tarjetas del portafolio.
Esto es solo presentación. No afecta la coincidencia, el conteo, los alias ni las alertas — cambia lo que lees, nunca lo que se mide.
Igual vale la pena hacerlo. Los nombres en snake_case son correctos en el código y un poco hostiles en un dashboard, sobre todo en uno que le muestras a alguien que no escribió la instrumentación. Una etiqueta cuesta diez segundos y hace que el embudo se lea de un vistazo.
Una pasada rápida de configuración
- Agrega todos los hosts desde los que sirves — raíz, subdominio de app, documentación, cualquier cosa con el tracker puesto.
- Agrega tus proveedores de pago y autenticación a los referrers ignorados.
- Etiqueta tus eventos de conversión y de primer valor.
Después revisa fuentes en uno o dos días. Si tu propio dominio o tu proveedor de pagos aparece como fuente, algo de esta página necesita una línea más.
Qué sigue
- Fuentes — cómo se clasifica la atribución
- Ajustes del proyecto — las otras tres pestañas
- Conversiones y activación — definir el éxito
- Salir a producción — la checklist previa al lanzamiento
- Solución de problemas — cuando llegan eventos pero no atribución