Impacto profundo de Google Tag Manager en el servidor

Antes de sumergirnos en Google Tag Manager (GTM) del lado del servidor, prefijaré el meollo de este post con una advertencia: respetar siempre la privacidad del usuario.

Cualquier técnica de recopilación de datos discutida aquí debe debe aplicarse con rectitud y no como una solución para eludir la regulación del consentimiento de recopilación de datos.

vista a 10.000 pies

He aquí una situación familiar - Google Tag Manager como lo hemos conocido durante años.

Su contenedor se carga en todas las páginas o pantallas de su sitio o aplicación y, en función de los eventos desencadenantes, los datos se envían a puntos finales propios y de terceros.

Funciona, está bien, pero no es perfecto. Bloqueadores de rastreo, fallos de JavaScript, muchos, muchas solicitudes a los puntos finales y un JavaScript ineficaz son riesgos y posibles problemas de rendimiento que pueden dar lugar a problemas de calidad de los datos.

GTM del lado del servidor traslada la solicitud del proveedor de etiquetas del cliente a un servidor: un servidor en Google Cloud Platform que vive en un subdominio de su sitio. El contenedor cargado en el navegador/aplicación sigue teniendo etiquetas y sigue enviando una solicitud, pero tiene mucho menos código, envía menos solicitudes, no se ve necesariamente afectado por el software antirrastreo, no envía la dirección IP del usuario a los proveedores de etiquetas de terceros y las cookies de origen se establecen correctamente de una manera que cumple con la Manera compatible con ITP.

Fuera de la caja: ¿qué es lo mejor?

Hay muchos motivos para entusiasmarse con GTM del lado del servidor en el sentido de que, en el lado del cliente, todo es muy familiar-pero mucho mejor El vendedor digital "tradicional" puede seguir configurando su(s) etiqueta(s) de Facebook con los mismos activadores y desplegar Floodlights según sea necesario. Igual, igual... pero diferente.

Como ya se ha mencionado, en lugar de enviar los datos al punto final del proveedor de etiquetas, se envían a un subdominio. Por ejemplo, si está en www.mysite.comgTM del lado del servidor enviará los datos a tracking.mysite.comun subdominio que puedes tener configurado.

¿Y eso es genial porque...?

• Respeta la privacidad del usuario: La dirección IP del usuario no se envía a terceros.
• Preserva la calidad de los datos: La prevención del rastreo no se produce en las peticiones a su propio dominio.
• Aligera la sobrecarga de código del lado del cliente: Las etiquetas requieren menos trabajo en el navegador, desplazando la carga de trabajo al servidor. Esto significa que lo que queda en GTM en el navegador hace menos, por lo que el sitio funciona más rápido.
• Consolida las peticiones del lado del cliente: Puedes enviar múltiples peticiones desde el servidor basándote en una petición desde el cliente.

En MightyHive, abogamos firmemente por centrarse en lo que es mejor para el usuario, no la capacidad de frustrar o eludir el software anti-seguimiento. Recordatorio: actúa con rectitud, no con egoísmo. En la actualidad, los datos se recogen, no se capturan. En el futuro, los datos se intercambiarán... Piénsalo un momento.

Impacto más profundo

¿Se ha dado cuenta de que las solicitudes de seguimiento se envían a su dominio y no al de un tercero? La carga de trabajo de recopilación de datos se traslada a su infraestructura.

¿Le parece que es como volver al registro del servidor web? ¿En qué se diferencia esto del registro de servidores web?

En mucho.

Los datos analíticos se formatean (se sesionan), se limpian (se elimina la información de identificación personal), se integran (se unen a los datos de Google Ads, Search Ads/Display & Video 360) y se presentan listos para desempeñar su función: el análisis y la optimización de todos los aspectos del negocio online, que, admitámoslo, consiste en mejorar el marketing.

Los registros de los servidores web no recogen todos los datos de comportamiento. Normalmente, los datos a nivel de registro no se integran con los datos del canal de marketing, lo que significa que no existe un bucle de retroalimentación para la activación de los datos.

Sin embargo, existen similitudes entre GTM del lado del servidor y el registro del servidor web. El servidor web recibe una solicitud, normalmente para una página, construye el contenido de la página y responde, posiblemente estableciendo cookies de origen junto con la respuesta. El punto final GTM del lado del servidor también recibe solicitudes y responde, potencialmente con cookies (pero con menos contenido).

Ahora... el servidor web sabe qué página está devolviendo.

En sabe qué datos mostrar en la capa de datos para registrar una transacción (por ejemplo).

La capa de datos es recogida por una etiqueta que se dispara en el navegador y luego enviada de vuelta al punto final de seguimiento.

El punto final toma entonces los mismos datos y los envía a Google Analytics (GA) para completar el viaje de ida y vuelta y obtener los datos analíticos registrados.

¡Uf!

Espere un minuto. Si el servidor web sabe que está mostrando una página de confirmación de "gracias" y sabe qué datos mostrar en la capa de datos, ¿por qué molestarse en enviar esto al navegador para que éste lo envíe de vuelta al punto final de seguimiento y luego a GA?

¿Por qué no eliminar algunos pasos en aras de la eficiencia? El servidor web sabe que está renderizando una página de confirmación. Por lo tanto, realiza exactamente la misma solicitud que el navegador y envía los datos de la transacción de GA directamente al punto final de seguimiento. Elimina el viaje de ida y vuelta del cliente.

Es bastante normal disparar etiquetas de conversión, Floodlights, FB pixels, Adnxs, TTD, etc. para registrar transacciones. No se las envíe al cliente para que las gestione. Cuando el servidor web responda con la página de confirmación, envíe esas solicitudes directamente al punto final de seguimiento. El punto final responde con los detalles de las cookies que hay que instalar, y el servidor web las envía junto con el contenido de la página de confirmación en la respuesta al cliente.

Piense en cuántas etiquetas de marketing y píxeles de seguimiento se activan en eventos a nivel de página. ¿Cuántas etiquetas necesitan realmente activarse en el cliente? ¿Cuántas etiquetas ni siquiera necesitan estar expuestas al navegador? ¿Y si, tal vez sólo etiquetas activadas por eventos a nivel de página? Tal vez sólo necesite un seguimiento a nivel de página si ha eliminado toda la hinchazón de datos? Entonces usted no necesita CNAME el subdominio de seguimiento, puede restringir el acceso a su punto final de seguimiento para sólo permitir que su servidor web acceda a través de https (piense en la restricción de rango IP). Eso es un montón menos de complejidad y una buena cantidad de partes móviles eliminadas de la solución.

Más simple es mejor. Ningún código es mejor que ningún códigocomo dice el refrán.

En conclusión

La solución GTM del lado del servidor ofrece una solución buena y correcta para la medición analítica digital. Es buena porque se puede mejorar la calidad de los datos, se protege más la privacidad del usuario y, significativamente, es un paso hacia la realización de menos trabajo en el navegador, lo que significa que los sitios y las aplicaciones son más rápidos.

Pensar en las posibles soluciones que ofrece la tecnología, con la motivación adecuada en mente, demuestra lo versátil que es la solución, la potencia de que dispone y las vías que quedan por explorar para aprovechar los datos de origen.