CA
Sol·licitar demo
Mesurament

Tracking server-side: què és, què canvia i quan el necessites

Amb l'etiquetatge clàssic, el navegador de cada usuari envia les dades directament a Google, Meta o TikTok. Amb el tracking server-side, les envia primer a un servidor teu, i és aquest servidor el que decideix què arriba a cada plataforma.

Daniel Gonzalez · Director Comercial7 min de lectura
Il·lustració de l'article: Tracking server-side: què és, què canvia i quan el necessites

Durant anys, mesurar una campanya consistia a enganxar al web el píxel de cada plataforma. Funcionava, però cada cop es perden més dades pel rebuig de cookies, les restriccions dels navegadors i els bloquejadors, i el web s'omple de codi de tercers que no controles.

El tracking server-side, també anomenat etiquetatge del costat del servidor, canvia el recorregut d'aquestes dades. En aquest article expliquem com funciona, què millora, què no resol i quan val la pena.

En resum

  • Els esdeveniments del teu web o la teva app van primer a un servidor en un subdomini teu, com tag.eldomini.com, i des d'allà a cada plataforma per API.
  • Guanyes control sobre quines dades comparteixes, cookies pròpies més duradores i menys scripts de tercers a la pàgina.
  • No substitueix el consentiment ni és un mesurament sense cookies màgic: l'usuari continua decidint.
  • Si combines esdeveniments del navegador i del servidor, cal deduplicar-los amb un event_id.
  • Té cost d'allotjament i necessita un responsable tècnic. No tots els anunciants el necessiten.

Què és el tracking server-side

En l'etiquetatge del costat del client (client-side), el navegador de l'usuari carrega l'etiqueta de cada plataforma i envia els esdeveniments directament a Google, Meta o TikTok. Cada proveïdor rep el que recull el seu script.

En l'etiquetatge del costat del servidor (server-side), el web envia els esdeveniments a un únic destí: un servidor d'etiquetatge que viu en un subdomini teu. Aquest servidor rep l'esdeveniment, el processa i el reenvia a cada plataforma per les seves API.

Esquema Recorregut d'un esdeveniment amb tracking server-side
La diferència clau: entre l'usuari i les plataformes hi ha un punt intermedi que controles tu.

Què canvia respecte a l'etiquetatge al navegador

Les peticions van al teu propi domini

El navegador ja no parla amb desenes de dominis de tercers, sinó amb un subdomini teu. Per al navegador és trànsit propi (first-party).

El servidor decideix què arriba a cada plataforma

Pots treure la IP o paràmetres de l'URL abans de reenviar, enviar a cada plataforma només els esdeveniments que li corresponen i descartar trànsit que no vols comptar, com bots o proves internes. És el canvi més important: decideixes tu què es comparteix.

Cookies pròpies que duren més

Safari, amb la seva Intelligent Tracking Prevention (ITP), limita a set dies les cookies creades per JavaScript, i les de tercers directament no les admet. Les cookies que fixa el teu servidor en una resposta HTTP des del teu domini poden durar més, així que un usuari que torna al cap de dues setmanes continua sent reconeixible. Un matís: Safari també limita les cookies de servidor quan el subdomini d'etiquetatge apunta a una infraestructura molt diferent de la del teu web, així que com es configura importa.

Menys codi de tercers a la pàgina

Si diverses plataformes s'alimenten des del servidor, pots retirar alguns dels seus scripts del web. Menys JavaScript de tercers sol voler dir una pàgina que carrega abans.

Què no fa el tracking server-side

  • No evita el consentiment. Si l'usuari rebutja les cookies de publicitat o analítica, aquestes dades no es poden enviar, vagin pel navegador o pel servidor. El servidor ha de llegir el senyal del teu CMP i respectar-lo.
  • No és mesurament sense cookies per art de màgia. Continua fent servir cookies, només que pròpies. El que millora és la seva durada i el control, no la necessitat de permís.
  • No esquiva tots els bloquejadors. Un subdomini propi resisteix millor que els dominis coneguts de les plataformes, però alguns bloquejadors també detecten els scripts o les rutes habituals de l'etiquetatge.

Quines peces calen

  1. Un servidor d'etiquetatge. L'opció més estesa és Google Tag Manager server-side, que es pot desplegar a Google Cloud Run o en un proveïdor gestionat que l'allotja per tu.
  2. Un subdomini propi. Per exemple, tag.eldomini.com, apuntant a aquest servidor.
  3. Un contenidor web. El GTM de tota la vida o l'etiqueta de Google a la pàgina, configurats per enviar els esdeveniments al teu servidor en lloc de a cada plataforma.
  4. Un contenidor de servidor. Rep les peticions mitjançant «clients» que les interpreten i dispara les etiquetes de cada destí.
  5. Les etiquetes de cada plataforma. L'API de conversions de Meta, les conversions millorades de Google Ads, l'Events API de TikTok i el Measurement Protocol de GA4, entre altres.

La peça de Meta l'expliquem a la guia de l'API de conversions.

Deduplicació: quan el navegador i el servidor envien el mateix esdeveniment

Moltes instal·lacions mantenen el píxel al navegador i hi afegeixen l'enviament des del servidor. És raonable, però la mateixa compra arriba dues vegades. Perquè la plataforma la compti una sola vegada, els dos enviaments han de portar el mateix identificador: a Meta i a TikTok, el mateix nom d'esdeveniment i el mateix event_id; a Google Ads, el mateix ID de transacció. Sense això, les conversions s'inflen i les pujes aprenen de dades duplicades.

Enriquir els esdeveniments amb dades del teu negoci

El navegador només sap el que passa al web. El teu servidor pot consultar altres sistemes abans de reenviar l'esdeveniment: el marge de la comanda des de l'ERP, la qualitat del lead des del CRM o si el client ja havia comprat abans. El que passa dies després, com una venda tancada per telèfon o una devolució, es completa amb conversions offline des de la teva font de la veritat.

Costos i manteniment

Un servidor d'etiquetatge és infraestructura i costa diners cada mes. A Cloud Run, Google recomana diverses instàncies per a producció, i el cost creix amb el trànsit. Un proveïdor gestionat simplifica el desplegament a canvi d'una quota.

El cost menys visible és el de manteniment. Algú ha de vigilar que el servidor respon, actualitzar les plantilles i comprovar que el consentiment i la deduplicació continuen funcionant després de cada canvi al web. Sense un responsable tècnic, un muntatge server-side es degrada en silenci.

Quan el necessites i quan no

Et compensa si es compleixen diverses d'aquestes condicions:

  • Inverteixes en diverses plataformes i les seves pujes automàtiques depenen de les conversions que reben.
  • Una part rellevant del teu trànsit arriba des de Safari o des d'iOS.
  • Vols controlar quines dades personals rep cada proveïdor.
  • Vols enviar valors de negoci, com el marge o la qualitat del lead, i no només l'esdeveniment.
  • Tens algú, intern o extern, que s'encarregui de mantenir-lo.

Probablement encara no el necessites si inverteixes poc en mitjans, fas servir una sola plataforma amb la seva integració nativa o les teves conversions ja arriben des del CRM com a conversions offline.

Errors habituals

  • Muntar-lo per saltar-se el consentiment. És un risc legal i, a més, no és per a això que serveix.
  • Duplicar esdeveniments. Enviar des del navegador i des del servidor sense un event_id comú.
  • Fer servir un domini que no és el teu. Sense subdomini propi, es perd bona part de l'avantatge de les cookies first-party.
  • No tenir responsable. Ningú no revisa el servidor fins que les conversions cauen.

Com ho fa Babuin

A MonkeyFlux, els esdeveniments del teu web i la teva app passen per un servidor al teu propi domini, com tag.eldomini.com, amb cookies first-party. Allà s'aplica el consentiment, es dedupliquen els esdeveniments per event_id i s'enriqueixen amb dades del teu CRM i el teu ERP, com el marge, el LTV, la qualitat del lead o les devolucions. Després s'envien a cada plataforma per Conversions API, Enhanced Conversions, Events API o Measurement Protocol. És compatible amb el teu contenidor server-side de GTM.

Amb aquests senyals, Babuin mesura cada mitjà contra els resultats del teu negoci, MonkeyBot puja cap a valor real i DBA reparteix cada dia el pressupost entre canals.

Preguntes freqüents

El tracking server-side evita haver de demanar consentiment de cookies?

No. El consentiment s'aplica igual tant si les dades surten del navegador com si surten del teu servidor. El correcte és que el servidor llegeixi el senyal del teu CMP i només enviï a cada plataforma les dades dels usuaris que han acceptat aquest ús.

Quina diferència hi ha entre GTM web i GTM server-side?

GTM web s'executa al navegador de l'usuari i envia les dades directament a cada plataforma. GTM server-side s'executa en un servidor teu: rep els esdeveniments del contenidor web i decideix què reenvia a cada destí, amb quines dades i en quin moment.

Quant costa Google Tag Manager server-side?

GTM és gratuït, però el servidor on s'executa no ho és. El cost depèn del trànsit, del nombre d'instàncies i de si l'allotges a Google Cloud Run o en un proveïdor gestionat. A això cal sumar-hi el temps de qui el manté.

El tracking server-side substitueix el píxel de Meta?

No necessàriament. Moltes instal·lacions combinen el píxel amb l'API de conversions i dedupliquen els esdeveniments amb el mateix event_id. Així Meta rep l'esdeveniment encara que un dels dos enviaments falli, i el compta una sola vegada.

Optimitza amb les dades del teu negoci

T’ensenyem Babuin amb els teus mitjans i la teva font de la veritat. Sense compromís.