![\"\"](\"https:\/\/www.thenetrevenue.com\/wp-content\/uploads\/2026\/07\/recopilacion-datos-web-motor-reservas.jpeg\")
<\/p>\nCom trackejar un allotjament tur\u00edstic, des de GA4 fins al motor de reserves? Una pregunta que tot professional del sector tur\u00edstic amb responsabilitat en direcci\u00f3, vendes, revenue management o m\u00e0rqueting s’ha fet alguna vegada. Un proc\u00e9s imprescindible que necessita qualsevol hotel boutique, cadena hotelera, c\u00e0mping o apartament tur\u00edstic, per saber d’on ve l’hoste que reserva, qu\u00e8 el va conv\u00e8ncer i en quin punt de l’embut de conversi\u00f3 se li escapen els que no arriben a confirmar.<\/p>\n
A continuaci\u00f3 expliquem amb detall quines dades es recopilen realment en una p\u00e0gina web amb motor de reserves i per qu\u00e8 aquestes dades mai poden coincidir entre ambdues plataformes.<\/p>\n
<\/p>\n
Quan alg\u00fa accedeix a una web, es generen dos tipus de rastre completament diferents. El primer viu al servidor: cada petici\u00f3 HTTP deixa una l\u00ednia en un log amb la IP, el user-agent, l’URL sol\u00b7licitada, l’hora exacta i el codi de resposta. \u00c9s una dada objectiva, sense consentiment de per mig, per\u00f2 tamb\u00e9 pobra: no identifica sessions de forma fiable ni permet reconstruir un recorregut, perqu\u00e8 cada petici\u00f3 \u00e9s un esdeveniment a\u00efllat sense mem\u00f2ria de les anteriors, i per aix\u00f2 si comparem les dades estad\u00edstiques que ens ofereix el propi servidor d’hosting no tenen res a veure amb les que podem obtenir de GA4. El segon rastre \u00e9s el que aporta valor anal\u00edtic real, i dep\u00e8n de cookies o emmagatzematge local que s\u00ed que requereixen consentiment sota el RGPD. Una cookie de primera part, com el client ID que genera GA4, permet unir diverses visites d’un mateix navegador en una sessi\u00f3 cont\u00ednua; una cookie de tercera part, cada vegada m\u00e9s residual despr\u00e9s de les restriccions de Safari, Firefox, Edge i la pr\u00f2pia deriva de Chrome, servia sobretot per a publicitat i atribuci\u00f3 cross-domain. A aix\u00f2 s’hi sumen t\u00e8cniques complement\u00e0ries com el fingerprinting de dispositiu o els p\u00edxels de conversi\u00f3 de Meta i Google Ads, que intenten compensar la p\u00e8rdua de cookies amb models probabil\u00edstics en lloc de registres directes.<\/p>\n
Aqu\u00ed apareix el primer problema seri\u00f3s per a qualsevol allotjament tur\u00edstic que vulgui mesurar el seu funnel complet: la web i el motor de reserves gaireb\u00e9 mai comparteixen domini, i aquesta frontera t\u00e8cnica trenca la continu\u00eftat del rastre. Fa deu anys, comparar les sessions de Google Analytics amb les reserves del motor ja era metodol\u00f2gicament q\u00fcestionable, per\u00f2 almenys tenia una l\u00f2gica interpretable si es tenien en compte les evidents limitacions, perqu\u00e8 les cookies operaven sense necessitat de consentiment i el tracking cobria la immensa majoria del tr\u00e0nsit; la discrep\u00e0ncia entre ambdues fonts existia, per\u00f2 eren dades m\u00e9s o menys manejables. El motor carregat en un subdomini o en un iframe tallava la sessi\u00f3 d’Analytics, que perdia el fil de la conversi\u00f3, i el tracking acabava mostrant conclusions err\u00f2nies sobre quin canal o campanya estava realment funcionant.<\/p>\n
<\/p>\n
En el panorama actual, la compilaci\u00f3 de dades dels visitants s’ha complicat de forma estructural i permanent, i en gran part a causa del consentiment de cookies, encara que hi ha altres motius. Amb l’aparici\u00f3 de multitud de sistemes per evitar el rastreig, una part significativa dels visitants rebutja el tracking de forma autom\u00e0tica i, per compensar aquest buit, GA4 aplica modelitzaci\u00f3 estad\u00edstica que omple els forats amb estimacions, no amb registres reals de comportament. El motor de reserves, en canvi, no estima res: compta transaccions confirmades amb dades de servidor, sense mostreig ni model de per mig. Comparar ambdues fonts per treure conclusions sobre conversi\u00f3 o atribuci\u00f3 de canal ja no \u00e9s una an\u00e0lisi amb marge d’error acceptable, \u00e9s comparar dos sistemes que mesuren realitats diferents amb metodologies diferents, i qualsevol decisi\u00f3 comercial constru\u00efda sobre aquesta comparaci\u00f3 descansa sobre una base molt m\u00e9s fr\u00e0gil de la que sembla.<\/p>\n
A aquesta opacitat estructural s’hi suma una capa addicional que creix m\u00e9s r\u00e0pid del que molts panells d’anal\u00edtica s\u00f3n capa\u00e7os de reflectir: el software antitracking que el mateix usuari instal\u00b7la de forma volunt\u00e0ria. Extensions i programes com Malwarebytes Browser Guard, Ghostery o Privacy Badger, juntament amb els bloquejadors natius que ja porten integrats navegadors com Brave, Safari amb el seu Intelligent Tracking Prevention o Firefox amb la protecci\u00f3 de rastreig millorada, intercepten l’script de GA4 o del p\u00edxel de conversi\u00f3 abans que arribi a executar-se, de manera que la visita ni tan sols apareix com a sessi\u00f3 perduda, simplement no existeix per a l’eina de mesurament. Les VPN afegeixen una altra capa de distorsi\u00f3 diferent: no bloquegen el tracking en si, per\u00f2 emmascaren la IP real del visitant i sovint alteren la seva geolocalitzaci\u00f3 aparent, el que descol\u00b7loca els informes de proced\u00e8ncia geogr\u00e0fica i pot fer que una mateixa persona es registri com a dues sessions diferents si canvia de servidor VPN a mitja navegaci\u00f3. El resultat combinat \u00e9s que una part del tr\u00e0nsit, i precisament la m\u00e9s sensible a temes de privacitat, queda sistem\u00e0ticament invisible o mal atribu\u00efda en qualsevol eina que depengui de JavaScript de client, el que refor\u00e7a encara m\u00e9s la idea de que la dada de servidor del motor de reserves ha de ser l’ancoratge de qualsevol an\u00e0lisi seriosa de conversi\u00f3, i no un complement de la dada d’Analytics.<\/p>\n
Dit aix\u00f2, s\u00ed que \u00e9s possible seguir el recorregut d’un viatger des de la visita a la web fins a la contractaci\u00f3 al motor, encara que exigeix una configuraci\u00f3 deliberada i no la que ve de “f\u00e0brica” en la majoria d’instal\u00b7lacions, per la qual cosa es necessita en la majoria dels casos una empresa especialitzada en Google Tag Manager i que sigui capa\u00e7 d’interpretar codi. El primer requisit \u00e9s el seguiment entre dominis: si el motor viu en un domini o subdomini diferent al de la web, cal configurar el cross-domain measurement de GA4 perqu\u00e8 el client ID viatgi entre ambd\u00f3s sense trencar-se, una cosa que molts motors de reserva de tercers no permeten de forma nativa i que sovint obliga a treballar amb par\u00e0metres d’URL o amb el propi prove\u00efdor del motor. El segon requisit \u00e9s instrumentar el motor amb els mateixos esdeveniments est\u00e0ndard que utilitza qualsevol ecommerce: inici del proc\u00e9s de reserva, selecci\u00f3 d’habitaci\u00f3, introducci\u00f3 de dades de l’hoste, inici del pagament i compra confirmada, cadascun amb la seva marca de temps i el seu identificador de transacci\u00f3. Sense aquests esdeveniments intermedis, el motor nom\u00e9s informa de reserves completades o abandonades en bloc, sense visibilitat de en quin pas concret es perd el lead. El tercer requisit, cada vegada m\u00e9s rellevant per l’impacte del consentiment en la qualitat de la dada, \u00e9s plantejar-se un contenidor server-side de Google Tag Manager, que permet enviar esdeveniments des del propi servidor de l’hotel en lloc de dependre exclusivament del navegador de l’usuari, millorant la fiabilitat del mesurament fins i tot quan el visitant ha limitat el rastreig al client, i tot aix\u00f2 sense saltar-se les normes de la llei de protecci\u00f3 de dades de torn.<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Precisament perqu\u00e8 tota aquesta instrumentaci\u00f3 implica tractar dades personals, el marge de maniobra t\u00e8cnic est\u00e0 condicionat per un marc legal que conv\u00e9 prendre’s seriosament i no com un tr\u00e0mit del banner de cookies. A la Uni\u00f3 Europea, el RGPD exigeix una base legal expl\u00edcita per a qualsevol cookie no estrictament necess\u00e0ria, el que a la pr\u00e0ctica significa consentiment previ, informat i revocable, gestionat a trav\u00e9s d’una plataforma de consentiment (CMP) que ha de registrar i poder demostrar qu\u00e8 va acceptar cada usuari i quan; a Espanya, la LSSI-CE afegeix l’obligaci\u00f3 d’informar amb claredat abans que s’executi qualsevol script de tercers. L’incompliment no \u00e9s una q\u00fcesti\u00f3 te\u00f2rica: l’Ag\u00e8ncia Espanyola de Protecci\u00f3 de Dades ha sancionat empreses tur\u00edstiques per activar Google Analytics o p\u00edxels publicitaris sense un consentiment v\u00e0lid, seguint una tend\u00e8ncia que ja van marcar reguladors com la CNIL francesa o el Datenschutzbeh\u00f6rde austr\u00edac en declarar l’\u00fas de Google Analytics contrari al RGPD en determinades configuracions. Les sancions sota el RGPD poden arribar als vint milions d’euros o al quatre per cent de la facturaci\u00f3 global anual, el que resulta especialment rellevant per a una consultora o operador amb pres\u00e8ncia en diversos pa\u00efsos, on a m\u00e9s del RGPD conviuen altres r\u00e8gims que exigeixen atenci\u00f3 pr\u00f2pia, com la CCPA i la seva successora CPRA a Calif\u00f2rnia, la LGPD al Brasil o les lleis de protecci\u00f3 de dades espec\u00edfiques de cada pa\u00eds llatinoameric\u00e0.<\/p>\n
Conv\u00e9 no perdre de vista, a m\u00e9s, que bona part d’aquest risc no dep\u00e8n \u00fanicament de la configuraci\u00f3 que faci el propi allotjament: no tots els motors de reserva del mercat compleixen amb la legalitat vigent en la captaci\u00f3 i el tractament d’aquestes dades, i alguns injecten scripts de tercers, emmagatzemen informaci\u00f3 de l’hoste fora de la Uni\u00f3 Europea o gestionen el consentiment de forma deficient sense que l’hotel ho s\u00e0piga fins que arriba una inspecci\u00f3. Contractar un motor sense auditar abans com gestiona el consentiment, on allotja les dades i si compleix amb el RGPD trasllada aquest risc directament a l’allotjament, que continua sent responsable del tractament encara que la fallada estigui en l’eina d’un prove\u00efdor extern, aix\u00ed que abans de signar amb qualsevol motor conv\u00e9 exigir per escrit aquestes garanties i no donar-les per suposades nom\u00e9s perqu\u00e8 el prove\u00efdor sigui conegut al sector. A aix\u00f2 s’hi afegeix la dimensi\u00f3 de seguretat: el motor de reserves maneja dades de pagament que cauen sota l’est\u00e0ndard PCI-DSS, i qualsevol arquitectura de tracking server-side ha de dissenyar-se per no exposar ni retenir informaci\u00f3 sensible de l’hoste m\u00e9s enll\u00e0 del estrictament necessari, ni convertir el propi servidor en un punt addicional de risc davant d’una bretxa de seguretat.<\/p>\n
<\/p>\n
Muntar un embut de conversi\u00f3 \u00fatil \u00e9s una q\u00fcesti\u00f3 de definir b\u00e9 els passos i no d’acumular eines. Un embut m\u00ednimament informatiu hauria de registrar, com a passos diferenciats, l’arribada a la p\u00e0gina de disponibilitat, la selecci\u00f3 de dates i tipus d’habitaci\u00f3, la pantalla de tarifes i extres, el formulari de dades de l’hoste, la pantalla de pagament i la confirmaci\u00f3 final, cadascun amb el seu propi esdeveniment i la seva pr\u00f2pia taxa d’abandonament calculada respecte al pas anterior, no respecte al total de visitants de la web. Aquesta distinci\u00f3 importa perqu\u00e8 barrejar tr\u00e0nsit de la web amb passos del motor en un mateix embut sense marcar la transici\u00f3 entre ambd\u00f3s sistemes \u00e9s exactament l’error que porta a atribucions falses. L’exploraci\u00f3 d’embuts de GA4, combinada amb les dades de transacci\u00f3 confirmada que reporta el propi motor de reserves i, si es vol anar m\u00e9s enll\u00e0, amb eines d’an\u00e0lisi de comportament com Hotjar o Microsoft Clarity per observar on dubta l’usuari dins de cada pantalla, dona una fotografia raonablement completa d’on es perd la conversi\u00f3.<\/p>\n
Per a un revenue manager, aquest nivell de detall no \u00e9s un capritx anal\u00edtic, \u00e9s la base de decisions que mouen directament el RevPAR. Un embut mal instrumentat sol amagar el veritable motiu d’una conversi\u00f3 baixa darrere d’explicacions c\u00f2modes sobre preu o compet\u00e8ncia, quan el problema real \u00e9s que el motor perd hostes al pas de tarifes i extres perqu\u00e8 la tarifa final no coincideix amb l’anunciada, o a la pantalla de pagament perqu\u00e8 el m\u00e8tode preferit del mercat d’origen no est\u00e0 disponible. Sense aquest desglossament per pas, qualsevol decisi\u00f3 de mix de canal, d’inversi\u00f3 en campanyes o d’ajust de comissi\u00f3 davant l’OTA es pren sobre una xifra de conversi\u00f3 agregada que no distingeix entre fricci\u00f3 t\u00e8cnica i decisi\u00f3 real de l’hoste, i aix\u00f2 porta a corregir el preu quan el problema \u00e9s de checkout, o a pujar la inversi\u00f3 en un canal amb un ROAS aparent inflat per una atribuci\u00f3 que ja hem vist que \u00e9s poc fiable. La disciplina de revenue management exigeix separar amb precisi\u00f3 quina part de la caiguda de conversi\u00f3 respon a estrat\u00e8gia comercial, \u00e9s a dir tarifa, disponibilitat o restriccions, i quina part respon a fricci\u00f3 de producte digital, perqu\u00e8 s\u00f3n palanques diferents i es gestionen amb eines diferents.<\/p>\n
<\/p>\n
La dada del motor de reserves ha de tractar-se com la font de veritat per a tot all\u00f2 que sigui volum de reserves i ingressos, mentre que la dada de comportament web ha d’usar-se per entendre intenci\u00f3 i fricci\u00f3, no per reconciliar xifres de venda ni per buscar veritats absolutes. Tractar ambdues fonts com si mesuressin el mateix \u00e9s l’error de fons que arrossega bona part dels directius que persegueixen una certesa absoluta en el bigdata, i tamb\u00e9 una de les cortines de fum m\u00e9s habituals en el discurs comercial dels propis prove\u00efdors de motors de reserva, que venen quadres de comandament i promeses d’atribuci\u00f3 perfecta sobre una base de dades que, per disseny, mai pot ser-ho. Evitar aquest engany no exigeix m\u00e9s tecnologia, exigeix entendre de veritat com funciona aquest ecosistema de dades i construir des del principi una arquitectura de mesurament pensada per a les dues realitats que convivim en qualsevol proc\u00e9s de reserva online, sempre dins d’un marc de compliment que protegeixi tant l’hoste com el propi negoci. Per al revenue manager, la implicaci\u00f3 final \u00e9s que cap decisi\u00f3 sobre mix de canal, inversi\u00f3 en m\u00e0rqueting o estrat\u00e8gia de paritat hauria de recolzar-se en una atribuci\u00f3 digital que ja sabem que \u00e9s parcial per disseny; la dada que de veritat ha de pilotar aquestes decisions \u00e9s la que confirma la reserva, i la resta de la instrumentaci\u00f3 nom\u00e9s serveix per entendre per qu\u00e8 aquella reserva no va arribar a produir-se.<\/p>\n
Necessites auditar el teu sistema de mesurament per saber si disposes de les dades correctes per prendre les decisions encertades? Fem un caf\u00e8 i ho comentem? wecandoit@thenetrevenue.com<\/b><\/p>\n
<\/p>\n
![\"\"](\"https:\/\/www.thenetrevenue.com\/wp-content\/uploads\/2026\/07\/analisis-datos-web-motor-reservas-scaled.jpg\")
<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Com trackejar la web d’un allotjament tur\u00edstic, de GA4 al motor de reserves? Una pregunta que tot professional del sector tur\u00edstic amb responsabilitat en direcci\u00f3, vendes, revenue management o m\u00e0rqueting s’ha fet alguna vegada.<\/p>\n","protected":false},"author":1,"featured_media":9897,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[63],"tags":[219,126,44,220],"class_list":["post-9921","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-marqueting","tag-analitica-web","tag-marketing","tag-revenue-management","tag-tracking"],"yoast_head":"\n