Consejos prácticos para mejorar la atribución de la conversión en Facebook

Una correcta atribución de las conversiones en Facebook es esencial para las empresas que quieren sacar el máximo partido a la publicidad de pago. Aunque algunas empresas siguen confiando en el seguimiento del navegador, cambiar al seguimiento del lado del servidor puede proporcionar datos más precisos. El etiquetado del lado del servidor permite la comunicación directa con su servidor y el de Facebook, proporcionando datos de calidad de primera parte y utilizando cookies de primera parte.

Esta publicación del blog proporcionará consejos prácticos para ayudarle a mejorar la atribución de la conversión de Facebook mediante el etiquetado del lado del servidor.

Una de las principales ventajas del etiquetado s2s es que proporciona una mayor precisión respecto a los métodos de seguimiento del lado del cliente. Esto se debe a que el etiquetado de servidor a servidor no puede ser bloqueado, ya que la comunicación se realiza a nivel de servidor. Herramientas como AdBlocker u otros mecanismos de prevención del seguimiento no pueden acceder a los datos enviados a través del servidor.

Cuando se activa la integración FB s2s, su servidor se comunica directamente con los servidores de Facebook. Envía datos fiables sobre los eventos y los usuarios que han visitado su sitio web, lo que ayuda a FB a atribuir a sus usuarios a sus perfiles de FB de forma precisa, lo que supone una información de calidad y una mayor probabilidad de éxito en la segmentación.

La forma más popular de seguimiento y monitoreo de Facebook de servidor a servidor es la configuración de la API de conversión de Facebook con la ayuda del contenedor de Google Tag Manager del servidor. Pero hay varios enfoques para configurar FB CAPI en sGTM. En esta guía, quiero describir diferentes métodos de configuración de FB CAPI, cómo cada forma impacta la atribución de FB, y cómo mejorar la atribución. 

Estas sugerencias se basan en la experiencia de stape y en los comentarios de los clientes de stape. 

Facebook recomienda configurar CAPI utilizando el método navegador+servidor. Cuando el seguimiento del navegador está bloqueado, el seguimiento del servidor seguirá enviando datos del usuario a Facebook. Cuando se activa tanto el seguimiento del navegador como el del servidor, FB utiliza el nombre del evento y el ID del evento para la deduplicación de eventos. Descarta un evento y mantiene otro para evitar el exceso de información.

Tenemos una entrada en el blog que describe cómo configurar Facebook CAPI utilizando el servidor GTM. 

FB da mayor prioridad a los eventos del navegador. Cuando ven tanto eventos del navegador como del servidor, su algoritmo de deduplicación probablemente descartará los eventos del servidor y registrará los del navegador. Así que si usted envía más datos con un evento de servidor, FB no podrá leer estos datos. Tampoco combinan los parámetros de los eventos de la web y del servidor. 

Un aspecto esencial de la configuración de FB CAPI mediante métodos híbridos a través de Google Tag Manager surge cuando se utiliza GA4 (o cualquier otra etiqueta GTM) para entregar datos de la web al servidor GTM. En los casos en que AdBlocker bloquea GA4, no proporciona datos a sGTM, lo que significa que las etiquetas FB CAPI tampoco se activan. Así que en este escenario, los eventos del navegador no se activan, así como las etiquetas del servidor.

Para solucionar este problema, stape ha creado el power-up Custom Loader. Este power-up hace que su script GTM y GA4 sea resistente a los AdBlockers. Así, cuando AdBlocker utiliza su capacidad máxima y bloquea las peticiones gtm.js o collect, Custom Loader las oculta y evita que sean bloqueadas. De esta forma, cuando el píxel de FB no funciona, su etiqueta GA4 seguirá entregando datos al contenedor sGTM, y sGTM enviará los eventos FB CAPI a Facebook, lo que significa que la acción del usuario tiene seguimiento.

Consulta este artículo para saber más sobre power-up de Custom Loader y cómo puede hacer que Web GTM y Google Analytics 4 sean resistentes a AdBlockers. 

Ventajas:

• FB recomienda configurar el método navegador+servidor.

Desventajas:

• El seguimiento del servidor puede bloquearse a menos que se utilice el encendido del cargador personalizado Stape (el caso de uso se describe anteriormente en la entrada del blog).
• Implementación más completa si no se utiliza GTM web para configurar los píxeles de FB.
• Cuando un usuario en un dispositivo iOS opta por no participar en el seguimiento, los eventos de la web y del servidor no se enviarán. (Hablaré de ello más adelante en la entrada del blog).

Aunque Facebook no recomienda enviar sólo eventos del servidor, es una buena solución si tiene más datos de usuarios o eventos en el contenedor de Google Tag Manager del servidor que en el de la web. O utilizar cualquier técnica para enriquecer los datos del servidor. Ya tenemos dos entradas en el blog sobre cómo se pueden enriquecer los datos de sGTM con la ayuda de Firestore o Google Sheets.

Recomiendo enviar eventos sólo del servidor en una situación así. La razón principal es que al utilizar el método web+servidor, FB preferirá los eventos web y omitirá todos los parámetros de usuario y de evento enviados desde el servidor. Esto significa que se perderán datos valiosos que pueden ayudar a la atribución de conversiones, y FB tendrá menos precisión al atribuir eventos a las campañas.

La atribución de conversión de FB de los usuarios de iOS que optaron por no hacer seguimiento es otra discusión larga y controvertida. En la documentación oficial, FB dice que FB CAPI no ayuda a seguir a los usuarios que han optado por no participar en el seguimiento. Aunque algunos estudios de casos y nuestro experimento muestran que una de las formas de seguir a las personas que optaron por no hacer seguimiento en iOS es enviando sólo los eventos del servidor a través de FB CAPI.

Esta teoría se basa en la lógica de que con el seguimiento web+servidor FB ve el ID del dispositivo mediante el píxel y no recoge todos los eventos para este ID de dispositivo. Pero cuando se envían eventos a través del servidor, FB sólo tiene acceso a los datos que se configuran y no conoce el ID del dispositivo o si el usuario optó por no hacer el seguimiento.

Ventajas:

• Mejore la atribución de la conversión en caso de que tenga más datos en sGTM.
• Se tarda menos en implementar ya que no hay necesidad de configurar la deduplicación de píxeles y eventos de FB.
• Puede seguir a los usuarios que hayan optado por no participar en el seguimiento.

Desventajas:

• FB no recomienda este método.
• Tendrá que enviar manualmente el fbp ya que el ID del navegador no será generado por el píxel de FB. Si utiliza la etiqueta FB CAPI, puede habilitar fácilmente esta opción.

La configuración de FB CAPI a través de webhooks es similar al envío de eventos FB sólo a través del servidor. La única diferencia es cómo se envían los datos desde el servidor de Google Tag Manager. En el método nº 2 (seguimiento sólo a través del servidor), se envían los datos desde GTM web a sGTM mediante GA4, UA o Data Tag. Con este método, puede desencadenar eventos FB CAPI basados en los datos que envía a través de Webhooks.

Los CMS más populares tienen funcionalidades que permiten configurar webhooks fácilmente. Con la activación de stape Preview Header, puede depurar los webhooks entrantes en sGTM. Ya tenemos una entrada en el blog sobre cómo enviar webhooks a sGTM.

Los webhooks pueden ser una excelente fuente de datos para el sGTM, ya que llevan información completa sobre los pedidos y los usuarios.

El principal beneficio de usar webhooks para enviar eventos FB CAPI es que estos eventos no pueden ser bloqueados. Algunos clientes prefieren probar el envío del mismo evento a través de navegador+servidor frente a webhook (sólo servidor). De esta manera, pueden realizar pruebas divididas y comparar qué método tiene una mayor tasa de coincidencia y un mejor impacto en la atribución de la conversión.

Ventajas:

• Mejore la atribución de la conversión, ya que los Webhooks incluyen datos valiosos sobre el usuario y el pedido
• Usted puede seguir a los usuarios que optaron por no hacer el seguimiento en los dispositivos iOS.
• Ofrece una excelente oportunidad para realizar pruebas divididas de seguimiento web+servidor vs. servidor a través del GTM web vs. servidor a través de los webhooks.

Desventajas:

• Puede tardar más en configurarse ya que tendrá que configurar los webhooks.

El equipo de Stape ha creado una nueva etiqueta sGTM diseñada explícitamente para enviar la conversión offline de FB desde sGTM. Usando esta etiqueta, puede enviar automáticamente los eventos de conversión offline de FB a FB. Anteriormente había que construir una integración personalizada o cargar manualmente el offline a través de CSV. 

La principal ventaja de los eventos FB offline es que pueden medirse en paralelo con los eventos FB pixel y FB CAPI. Puede probar por separado si los eventos de conversión web+servidor, solo servidor o FB offline funcionan con mayor precisión en términos de atribución.

Además de eso, nuestros experimentos mostraron que al usar webhooks como fuente de datos para las conversiones fuera de línea de FB, FB puede seguir a las personas que optaron por no seguir en los dispositivos iOS. La razón principal es que las conversiones offline se consideran datos de origen que se comparten con FB.

Otra ventaja considerable es la mayor ventana de atribución de los eventos offline de FB. Tiene una ventana de atribución de clics de 28 días en comparación con los 7 días máximos de FB CAPI o píxel. 

Recientemente hemos empezado a recomendar a los clientes de Stape que configuren la conversión FB Offline en paralelo con el seguimiento FB CAPI. La razón principal es que le da más información para evaluar el rendimiento de las campañas, y la configuración de la conversión FB Offline no le llevará mucho tiempo si ya ha implementado FB CAPI.

Ventajas:

• Puede seguir el rendimiento de la campaña en paralelo con el píxel de FB o CAPI. Todo lo que necesita hacer es personalizar las columnas en el gestor de anuncios.
• Las conversiones offline de FB tienen una ventana de atribución de 28 días.
• Alta probabilidad de que siga a los usuarios que optaron por no seguir el rastro en los dispositivos iOS 14/15.

Desventajas:

• Se necesita un tiempo adicional para su puesta en marcha.

Gracias por seguir conmigo hasta el final de esta entrada del blog. Ahora que ya sabe qué consejos utilizamos para mejorar la atribución de la conversión de las campañas de FB de los clientes de Stape con la ayuda del etiquetado del lado del servidor, es hora de poner en práctica estos conocimientos.

Recuerde que ninguna solución se adapta a todos los sitios web, ya que las tecnologías y los embudos de conversión son diferentes. Intenta experimentar y encontrar el método que mejor le funcione.

Estamos aquí para ayudarle si necesita ayuda para configurar su seguimiento o solucionar cualquier problema. Y asegúrese de volver a visitarnos con regularidad, ya que seguiremos actualizando nuestro blog con las últimas noticias y conocimientos sobre marketing digital. ¡Hasta luego!