Google Analytics y Tag Manager

Del lado de Google hay dos cosas distintas de las que muchas veces se habla como si fueran una. Analytics es un producto de medición: recoge eventos de tus páginas, los atribuye a fuentes de tráfico con sus propias reglas y genera reportes sobre funnels y audiencias. Tag Manager es un contenedor: un solo script que instalas una vez y que después carga y configura todas las demás etiquetas (Analytics, píxeles de anuncios, widgets de chat, mapas de calor) sin más cambios de código, según los disparadores y las variables que tú definas.

Del lado de AppBO están los funnels, las landing pages, las páginas de pedido y de reserva, los formularios y el seguimiento propio de la plataforma, que guarda los parámetros de origen en campos del contacto y es la base de los reportes de atribución que muestra tu CRM. Los dos sistemas de medición se traslapan, pero no coinciden, y entender por qué es la mayor parte del trabajo: Analytics atribuye las sesiones con su propio modelo, mientras que la plataforma atribuye un contacto según lo que traía la URL en el momento en que se creó ese contacto.

Agregas Analytics y Tag Manager porque responden preguntas que el CRM no puede responder: cuántas personas llegaron al paso dos y abandonaron, qué hizo un visitante antes de convertir, en qué página está la caída. Lo haces con cuidado porque las formas estándar de instalarlos rompen lo que ya tienes. Una redirección que elimina los parámetros de la URL, un banner de consentimiento que bloquea el script propio de la plataforma, una etiqueta que reescribe enlaces, y el síntoma es que la atribución se queda vacía sin hacer ruido, no un error que alguien vea.

1. Antes de instalar nada, decide para qué sirve cada sistema. Analytics responde preguntas de comportamiento sobre el tráfico y las páginas; la atribución propia de la plataforma responde de dónde vino un contacto. Anota cuál manda en cada reporte, porque van a diferir y alguien lo va a preguntar.
2. Crea o identifica la propiedad de Analytics y anota su identificador de medición. Crea un contenedor de Tag Manager para el sitio y anota su identificador de contenedor. Mantenlos separados en tus notas, porque confundir los dos identificadores es un error común y desconcertante.
3. Decide desde dónde se carga Analytics. Instalarlo a través de Tag Manager y no directamente es el mejor patrón: un solo script que administrar y los controles de consentimiento en un solo lugar.
4. Instala el contenedor de Tag Manager en la configuración de códigos de seguimiento de la subcuenta, para que aplique a todos los funnels y páginas, en lugar de pegarlo página por página. Donde la plataforma ofrezca un área de código para el head y otra para el body, pon cada fragmento en el área que indican las propias instrucciones de Google.
5. Agrega también el contenedor al sitio web si el sitio es independiente, usando el mismo contenedor para que un solo modelo de datos cubra todo el recorrido.
6. Configura la etiqueta de Analytics dentro de Tag Manager con el identificador de medición, para que se active en todas las páginas, y publica la versión del contenedor. Un contenedor sin publicar no hace nada, y esa es la razón más común por la que una configuración correcta parece rota.
7. Protege los parámetros de la URL. Revisa cada redirección, regla canónica y paso del funnel en busca de cualquier cosa que elimine la cadena de consulta de la URL, porque ahí viven los identificadores de campaña y de clic. Una redirección que los elimina destruye de un solo golpe la atribución de la plataforma y la importación de conversiones a las plataformas de anuncios.
8. Confirma que, con el contenedor ya activo, el seguimiento propio de la plataforma sigue guardando la fuente, el medio, la campaña y los identificadores de clic de los anuncios en campos del contacto. Envía un formulario de prueba con parámetros en la URL y revisa el registro del contacto.
9. Define los eventos que vale la pena medir: vistas de pasos del funnel, inicios de formulario, envíos de formulario, reservas completadas y pedidos completados. Decide cuáles son conversiones en Analytics.
10. Implementa esos eventos con disparadores de Tag Manager. Prefiere disparadores basados en las señales propias de envío de formulario o de vista de página de la plataforma antes que selectores frágiles atados a un diseño en particular, y documenta cuál es cuál.
11. Configura la medición entre dominios si el recorrido pasa por un dominio del sitio web y un dominio del funnel. Sin ella, un visitante que cambia de dominio empieza una sesión nueva y Analytics atribuye la conversión a una referencia desde tu propio sitio.
12. Excluye el tráfico interno en Analytics, y agrega los dominios del procesador de pagos o de la herramienta de reservas a la lista de exclusión de referencias, para que el regreso desde el pago no parezca tráfico nuevo.
13. Maneja bien el consentimiento. Si usas un banner de consentimiento, configura los ajustes de consentimiento en Tag Manager para que las etiquetas se activen según la elección hecha, y verifica que el seguimiento esencial de la plataforma siga funcionando cuando se rechaza el consentimiento de marketing: prueba tanto el camino de aceptar como el de rechazar.
14. Decide si algún dato de identificación personal podría llegar a Analytics. Los parámetros de la URL que llevan una dirección de email y los valores de formulario que se envían a la capa de datos son los culpables habituales; enviarlos viola la política de Analytics, así que elimínalos o cífralos con hash antes de que lleguen a una etiqueta.
15. Verifica con el modo de vista previa de Tag Manager: recorre todo el funnel y confirma que cada etiqueta se activa una sola vez, con el disparador correcto, con los valores correctos y no en las páginas equivocadas.
16. Verifica en la vista en tiempo real de Analytics que los eventos llegan con los nombres y parámetros esperados.
17. Concilia a propósito después de una semana: compara las conversiones de Analytics con los contactos creados en la plataforma. Espera una diferencia, entiende cada causa (consentimiento, bloqueadores, bots, modelo de atribución, vencimiento de sesiones) y deja la explicación por escrito para que nadie la redescubra cada trimestre.
18. Lleva un registro de cambios de las versiones del contenedor. Una versión publicada es un despliegue, y poder decir qué cambió el día en que se movieron las cifras vale esa pequeña disciplina.

De las páginas de la plataforma a Google

• Eventos de vista de página de cada paso del funnel, landing page y página del sitio web que tenga el contenedor.
• Eventos personalizados que configures: inicios y envíos de formulario, reservas completadas, pedidos completados, clics en botones y enlaces, señales de desplazamiento y de interacción.
• Parámetros de evento como el nombre del funnel, el nombre del paso, el producto o servicio y el valor, cuando decidas enviarlo.
• Los valores de la capa de datos que expone la página, que es lo que leen los disparadores y las variables de Tag Manager.
• El estado del consentimiento, cuando hay una plataforma de consentimiento conectada a Tag Manager.
• Cualquier otra etiqueta que cargue el contenedor: píxeles de plataformas de anuncios, mapas de calor, widgets de chat.

De Google a la plataforma

• Nada, en la configuración normal. Analytics es un destino de medición, no una fuente; no escribe en los registros de contacto.
• Cuando tu versión de la plataforma ofrece una conexión de reportes con Analytics, se pueden leer cifras agregadas de vuelta para los paneles. Eso es reporte, no atribución, y no va a coincidir con las cifras propias del CRM.

Lo que resuelve en su lugar el seguimiento propio de la plataforma

• Los parámetros de campaña y los identificadores de clic de los anuncios que se toman de la URL y se guardan en campos del contacto en el primer contacto.
• La atribución que se muestra en un contacto y en los reportes del CRM.
• Los identificadores que se usan para importar conversiones de vuelta a las plataformas de anuncios.

Lo que no se mueve

• Datos de identificación personal. Las direcciones de email, los teléfonos y los nombres no deben enviarse a Analytics, tanto por su propia política como por buena práctica.
• La identidad individual del visitante, en ninguna dirección. Analytics no te va a decir a qué contacto pertenecía una sesión.
• Los datos históricos cuando se reemplaza una propiedad o un contenedor. Una propiedad nueva empieza vacía y nada se rellena hacia atrás.
• Los eventos del lado del servidor que genera la plataforma sin que intervenga un navegador, como un cambio de etapa en el pipeline, a menos que los envíes a propósito desde el servidor.
• La coincidencia entre los dos sistemas. Las cifras van a ser distintas, y la diferencia no es un error que haya que corregir.

Escenario: una agencia agrega Analytics y Tag Manager al funnel de un cliente y descubre que lleva semanas rompiendo la atribución.

1. El cliente reporta que la atribución del CRM muestra la mayoría de los prospectos como directos, a pesar de una inversión fuerte en anuncios pagados. La agencia empieza revisando el funnel en lugar de las plataformas de anuncios.
2. Se crea un contenedor de Tag Manager y se instala en la configuración de seguimiento de la subcuenta para que cubra todos los funnels y páginas. Dentro de él se configura la etiqueta de Analytics con el identificador de medición, para que se active en todas las páginas, y se publica la versión del contenedor.
3. Se abre el modo de vista previa y se recorre el funnel desde un clic de prueba en un anuncio. El contenedor se activa en el paso uno, después la página redirige al paso dos y la cadena de consulta desapareció.
4. La redirección, agregada meses antes para forzar una barra al final de la URL, está eliminando la cadena de consulta. Por eso el seguimiento de la plataforma nunca guardó los parámetros de campaña ni el identificador de clic, y por eso todos los prospectos parecían directos.
5. Se reescribe la redirección para que conserve la cadena de consulta. Un nuevo clic de prueba ahora lleva los parámetros hasta el paso dos, y el contacto de prueba resultante muestra la campaña, el medio y el identificador de clic en su registro.
6. Con la atribución restaurada, se arma la medición de comportamiento: eventos de vista para cada paso del funnel, un evento de inicio de formulario y un evento de envío de formulario configurado como conversión en Analytics.
7. Los disparadores se basan en la señal propia de envío de formulario de la plataforma y no en un selector CSS, para que un cambio de diseño posterior no los rompa sin avisar.
8. Se configura la medición entre dominios, porque el sitio web y el funnel del cliente están en dominios distintos y Analytics venía tratando el cambio de dominio como una nueva sesión referida.
9. El dominio del procesador de pagos se agrega a la lista de exclusión de referencias, para que regresar desde el pago ya no inicie una sesión nueva atribuida al procesador.
10. El banner de consentimiento se conecta a los ajustes de consentimiento de Tag Manager. Se prueban los dos caminos: al aceptar, se activan Analytics y los píxeles de anuncios; al rechazar, no se activan, y el manejo esencial de formularios de la plataforma sigue funcionando.
11. Una semana después se concilian las cifras. Analytics reporta menos conversiones que los contactos que reporta la plataforma; las diferencias se explican por el consentimiento rechazado, los bloqueadores de anuncios y una página donde un bot estaba enviando el formulario.
12. Se agregan una regla de filtro de bots y un campo trampa (honeypot), y se documenta la brecha restante para que el cliente entienda por qué los dos paneles difieren y cuál usar para cada pregunta.
13. Los reportes del funnel ahora muestran una caída grande entre el paso dos y el paso tres. Se reescribe ese paso, y los datos de las dos semanas siguientes muestran la caída reducida a la mitad. Una pregunta que el CRM por sí solo nunca habría podido responder.
14. Un mes después, cuando las conversiones se duplican de repente, se usa el historial de versiones del contenedor: un colega había agregado una segunda etiqueta de Analytics. La comparación de versiones lo muestra en un minuto y se elimina.

Límites de uso

La recolección del lado del cliente no tiene límites de uso como los de una API, pero Analytics sí aplica límites de cardinalidad y de recolección. Hay topes en la cantidad de nombres de evento distintos, de parámetros y de dimensiones personalizadas, y umbrales por encima de los cuales los reportes agrupan los valores en una categoría de otros. Un contenedor que envía un nombre de evento que contiene un identificador único agota la cardinalidad y arruina los reportes. La API de reportes tiene sus propias cuotas cuando lees datos de vuelta. Revisa los límites publicados actualmente por Google para tu tipo de propiedad en lugar de suponerlos, y mantén los nombres de eventos y parámetros dentro de un vocabulario pequeño y controlado.

Reintentos e idempotencia

En la medición del lado del cliente no hay idempotencia, y ese es todo el problema: una etiqueta que se activa dos veces cuenta dos veces. Las causas habituales son un contenedor instalado tanto en la configuración global de la subcuenta como otra vez en una página individual, dos etiquetas de Analytics en un mismo contenedor, un disparador que se activa con una vista de página y también con un cambio de historial en un flujo de una sola página, y una página de agradecimiento que el visitante puede recargar o volver a visitar. Activa las etiquetas de conversión con un disparador que ocurra una sola vez, elimina duplicados con un identificador de transacción o de evento cuando la etiqueta lo permita, y usa el modo de vista previa para contar las activaciones en lugar de suponer.

Trampas al mapear campos

Los nombres de eventos y parámetros distinguen mayúsculas y minúsculas, y un nombre casi igual crea un segundo evento del que nadie saca reportes. Los parámetros tienen que registrarse como dimensiones personalizadas antes de aparecer en los reportes, y el registro no es retroactivo, así que un parámetro enviado durante un mes antes de registrarlo queda invisible para ese mes. Un valor enviado como texto donde se espera un número no se va a agregar. Los disparadores basados en selectores CSS se rompen cada vez que se rediseña una página, y la falla es silenciosa. La trampa de mapeo más grave es enviar datos de identificación personal en un parámetro, lo que viola la política de Analytics y puede poner en riesgo la propiedad.

Creación de duplicados

Aquí los duplicados son mediciones duplicadas, no registros duplicados, y son la causa más común de un panel en el que nadie confía: contenedores instalados dos veces, etiquetas de Analytics dobles, una etiqueta de conversión que se activa al cargar una página de confirmación que se puede recargar. Aparte, un visitante que pasa del dominio del sitio web al dominio del funnel sin medición entre dominios se cuenta como dos usuarios en dos sesiones, lo que infla el conteo de usuarios y destruye la atribución por fuente.

Pruebas contra producción

El modo de vista previa de Tag Manager y las vistas en tiempo real y de depuración de Analytics son un entorno de pruebas realmente bueno: puedes ver cómo se evalúa cada etiqueta, disparador y variable antes de publicar. Usa un entorno de contenedor separado o una propiedad de prueba para los cambios grandes, y nunca pruebes una etiqueta de conversión nueva contra la propiedad de producción durante un periodo de reportes que piensas usar. Recuerda que el modo de vista previa demuestra que la etiqueta se activa, no que aparece en los reportes: por los retrasos de procesamiento, una etiqueta que se activa bien puede tardar horas en aparecer en los reportes estándar.

Vencimiento de la autorización

El contenedor del lado del cliente no necesita ningún token y sigue funcionando indefinidamente, lo cual es a la vez la comodidad y el riesgo: nada vence, así que nada obliga a una revisión, y un contenedor puede seguir cargando una etiqueta de una herramienta que el negocio dejó de usar hace dos años. Cuando conectaste Analytics para llevar reportes a un panel, esa conexión es una autorización OAuth normal y se rompe por las causas de siempre. Audita el contenido del contenedor de forma periódica en lugar de esperar a que algo falle.

Lo que se rompe con más frecuencia

• Una redirección o regla canónica que elimina la cadena de consulta de la URL, lo que destruye de un solo golpe la atribución de la plataforma y la importación de conversiones a las plataformas de anuncios. La falla más dañina de esta área.
• Un contenedor creado pero nunca publicado, así que no se activa nada.
• Un banner de consentimiento que bloquea el seguimiento propio de la plataforma junto con las etiquetas de marketing, así que la atribución desaparece para todos los que rechazan.
• La medición entre dominios nunca configurada, con autorreferencias que explican la mayor parte del tráfico.
• Conversiones contadas dos veces por un contenedor duplicado o una segunda etiqueta de Analytics.
• Disparadores atados al código de la página que un rediseño rompe sin avisar.
• Direcciones de email que llegan a Analytics en una URL de página o en un valor de la capa de datos.
• Cifras de Analytics y cifras del CRM comparadas como si tuvieran que coincidir, con la diferencia tratada como una falla.
• Dominios de pago o de reservas que quedaron fuera de la lista de exclusión de referencias y le atribuyen las conversiones al procesador.
• Un contenedor usado como depósito de cada script que alguien pidió alguna vez, que hace más lentas las páginas y carga etiquetas que nadie sabe explicar.