Facebook Conversion API y Google Tag Manager server side, una unión casi perfecta

Tras varias semanas de duro trabajo, ya puedo presentar la implementación paso a paso que he realizado para poder integrar Facebook Conversion API (más conocida como FB CAPI) a través de GTM server-side. Creo que es un desarrollo que va a cambiar mucho nuestro concepto de cómo entendemos el Marketing Digital y las campañas.

Este post no pretende ser una guía especializada, ni oficial. Sino todo lo contrario, ser un añadido a los estándares marcados. Los cuales muchas veces se quedan cortos.

Volviendo la vista atrás, todavía tengo grabado en mi mente el mes de octubre del año pasado, cuando empecé a planificar esta puesta en marcha. Inicialmente parecía sencillo y en ningún caso podía imaginar los problemas con los que me iba a encontrar. Han sido muchos y muy diferentes. Desde la aparición repentina del IOS14 prompt, pasando por los cambios en las versiones de la API de Facebook o incompatibilidades entre FB y Google, hasta los distintos templates «oficiales» publicados (muy diferentes unos de otros).

De hecho, ha sido esta semana cuando por fin se anunciaba una solución eficiente: usar GA4 como punto de partida para enviar la información a FB. Sin embargo, semanas antes tras muchos prueba-error yo ya había podido llegar a esta solución. Aunque con la modificación del template previo que había publicado FB y no con el nuevo publicado. Era una cuestión de lógica intentando buscar un camino a algo que llevaba meses bloqueado por factores externos a mí. El camino era ese precisamente, si existen incompatibilidades entre FB y Google, «eliminémoslas». Usemos solo una de ellas: GA4.

La siguiente implementación está actualizada en base al último y más nuevo template publicado. He descartado, como es lógico, presentar lo realizado en el template previo. Aunque serviría igualmente «casi» de manera idéntica.

Qué es Facebook Conversion API

Es una API (Application Programming Interface) especializada en la optimización de las conversiones generadas en un sitio web, app u otro dispositivo conectado (para esto último sería necesario el Measurement Protocol de GA4).

Funciona desde el lado del servidor, y esencialmente permite compartir con FB la información de eventos relevantes con la intención de mejorar el rendimiento y la medición de las campañas publicitarias. Facebook Conversion API permite hacer acciones como:

Controlar los datos compartidos con terceros.
Optimizar y precisar la información enviada.
Medir las interacciones de una manera menos lesiva.

Cómo integrar Facebook CAPI a través de GTM server-side

Esta implementación, ahora que ya está desarrollada y testeada, la puede llevar a cabo cualquier persona que tenga una mínima experiencia con las tecnologías y las plataformas a continuación descritas. Sin embargo, el nivel de optimización que al que se puede llegar es casi ilimitado. Las opciones son infinitas.

Fase 1) Configurar correctamente GTM server-side

Esto de por sí da para un post. Así que en este caso me atendré simplemente a detallar aquello que deberemos tener en cuenta de cara a implementar Facebook CAPI.

En este caso concreto, lo primero es tener claro que queremos conseguir con GTM server-side. Entre las muchas ventajas que podemos enumerar, las más importantes son …

Evitar el futuro bloqueo de third_party cookies.
Mejorar la velocidad de carga. Cabe señalar que el píxel de FB es una de las librerías que más recursos consume y que por lo tanto más afecta al rendimiento de nuestras páginas.
Conexión directa con las plataformas de terceros.

Una vez se plantean sus ventajas, se debe «instalar» el contenedor de gtm-server-side en Google Cloud a través de su shell. Atención a este paso, porque aunque se pueden hacer determinados hacks, lo idóneo es generar un contenedor por cada dominio de primer nivel que controlemos. Es decir, si nuestro ecosistema tiene la siguiente estructura: ejemplo.es y ejemplo.co.uk; deberíamos generar dos contenedores server-side diferentes y en cada uno de ellos cumplimentar el campo ‘Tagging server URL’ con un subdominio o directorio que nos permita seguir bajo ese mismo dominio. Algo tipo gtm.ejemplo.es y gtm.ejemplo.co.uk.

Configuración GTM server side por dominio

Configuración de GTM server-side para un dominio ccTLD específico.

Fase 2) Creación o actualización de dataLayers

En este punto no me queda otro remedio que dar por hecho que quien está leyendo esto ya tiene añadidos los dataLayers necesarios para poder realizar el seguimiento su sitio web (incluido quienes tienen comercios electrónicos integrando los relativos al Ecommerce GA4). Partiendo de esta premisa, en nuestro caso, debido a la singularidad del negocio hemos tenido que agregar nuevas claves a los dataLayers. Estas variables son las que nos han permitido seguir hacia delante.

Fase 3) Configuración de GTM client y server-side

Hay numerosas formas de llevar a cabo el desarrollo dentro de GTM client-side (el GTM habitual, el que no es server-side). Sin embargo, recomiendo, al menos durante las primeras semanas de puesta en marcha del proyecto, seguir la siguiente estrategia:

Crear una nueva propiedad de GA4 que recoja solo los hits que se enviarán a FB a través de GTM server-side. Ya habrá tiempo de aunar todo más adelante cuando estemos seguros que el resultado satisface nuestras expectativas.
En el contenedor GTM client-side crear los 2 siguientes tags. El propósito de esto no es otro que comprobar cuántos hits se procesarán realmente en FB Ads comparándolos con lo que se reciben en GA4.
- Etiqueta de tipo GA4 Event llamada ‘GTM server side CC’ con al menos los event-parameters ‘transport_url’ y ‘first_party_collection‘ tal y como se ve en la parte izquierda de la siguiente imagen. A la derecha simplemente se ha creado un activador que salte con cualquier evento (aquí se podrían indicar únicamente los que nos interesen enviar a FB CAPI) y dos variables para controlar a qué servidor se debe enviar los datos.

Configuración de etiquetas, activadores y variables en GTM client side

Desarrollo propuesto para facilitar el envío y validación de los datos.

- Etiqueta de tipo GA4 Event llamada ‘GTM server side All’ cuya única funcionalidad es enviar a la nueva propiedad de GA4 la misma información que se controla con la otra etiqueta. Es decir, en vez de enviarlo a la ‘transport_url’ concreta de cada dominio, enviarlo a Google Analytics directamente (bien como hasta ahora directamente desde el GTM client-side o usando el Cliente GA4 en el lado de GTM server-side). Esta etiqueta nos va ayudar a validar todo el proceso durante varias semanas. Luego no será necesaria.

En GTM server-side, después de importar este Tag Template de FB, habrá que acometer algunos cambios programáticos (siempre y cuando, como en nuestro caso, hayamos usado claves de dataLayer no habituales). En este caso, y puesto que se trata de un site SPA (Single Page Application), se ha aprovechado el evento custom ‘spa’; el cual se genera por cada cambio de url aunque no haya una carga de página al uso.

Modificación del template Facebook Conversion API según dataLayer custom

Modificaciones en el Template de FB CAPI para eventos custom no previstos.

Llegado a este punto ya solo queda confirmar que la información que enviamos desde GTM client-side se recibe en GTM server-side y este la procesa para enviarla a Facebook CAPI. La comprobación se deberá hacer tanto en el debugger de GTM server-side como en el Business Manager de FB, concretamente en el Administrador de eventos. Te recomiendo que primero hagas pruebas a través de la pestaña ‘Probar eventos’ añadiendo al campo Test Event Code de la etiqueta creada para FB en GTM server-side el código mostrado en dicha pestaña.

Comprobando el correcto funcionamiento de Facebook Conversion API via GTM server-side

Comprobación de eventos recibidos vía GTM server-side y FB Business Manager.

Si ves los resultados en el propio Business Manager de FB sin errores aparentes será el momento de validarlo en el entorno de producción real.

Antes de despedirme, detallar que el comentario ‘Deduplicados’ que aparece en cada uno de los eventos denota simplemente que FB ha sido capaz de entender que ese evento se ha enviado a través del navegador también y por lo tanto no lo contabilizará dos veces. Es capaz de hacer esto gracias a varias variables como la IP, el país o el event_id asociado a cada uno de los eventos. Lógicamente cuando pasado un tiempo todo esté perfectamente validado se podrá descartar la implementación del lado del cliente, lo cual además hará que nuestro sitio web se cargue más rápido entre otras ventajas.

Con esto termino el post de esta semana. Espero «verte» la semana que viene. Si deseas que desarrolle algún tema en concreto, no dudes en escribirme a través de este formulario. Lo tendré en cuenta para siguientes posts 😉 ¡Un saludo y gracias por leerme!

Publicidad y campañas, Marketing Digital