Com trackejar un allotjament turístic, des de GA4 fins al motor de reserves? Una pregunta que tot professional del sector turístic amb responsabilitat en direcció, vendes, revenue management o màrqueting s’ha fet alguna vegada. Un procés imprescindible que necessita qualsevol hotel boutique, cadena hotelera, càmping o apartament turístic, per saber d’on ve l’hoste que reserva, què el va convèncer i en quin punt de l’embut de conversió se li escapen els que no arriben a confirmar.
A continuació expliquem amb detall quines dades es recopilen realment en una pàgina web amb motor de reserves i per què aquestes dades mai poden coincidir entre ambdues plataformes.
Per què les estadístiques de l’allotjament (hosting), GA4 i motor de reserves no coincideixen?
Quan algú accedeix a una web, es generen dos tipus de rastre completament diferents. El primer viu al servidor: cada petició HTTP deixa una línia en un log amb la IP, el user-agent, l’URL sol·licitada, l’hora exacta i el codi de resposta. És una dada objectiva, sense consentiment de per mig, però també pobra: no identifica sessions de forma fiable ni permet reconstruir un recorregut, perquè cada petició és un esdeveniment aïllat sense memòria de les anteriors, i per això si comparem les dades estadístiques que ens ofereix el propi servidor d’hosting no tenen res a veure amb les que podem obtenir de GA4. El segon rastre és el que aporta valor analític real, i depèn de cookies o emmagatzematge local que sí 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ó contínua; una cookie de tercera part, cada vegada més residual després de les restriccions de Safari, Firefox, Edge i la pròpia deriva de Chrome, servia sobretot per a publicitat i atribució cross-domain. A això s’hi sumen tècniques complementàries com el fingerprinting de dispositiu o els píxels de conversió de Meta i Google Ads, que intenten compensar la pèrdua de cookies amb models probabilístics en lloc de registres directes.
Aquí apareix el primer problema seriós per a qualsevol allotjament turístic que vulgui mesurar el seu funnel complet: la web i el motor de reserves gairebé mai comparteixen domini, i aquesta frontera tècnica trenca la continuïtat del rastre. Fa deu anys, comparar les sessions de Google Analytics amb les reserves del motor ja era metodològicament qüestionable, però almenys tenia una lògica interpretable si es tenien en compte les evidents limitacions, perquè les cookies operaven sense necessitat de consentiment i el tracking cobria la immensa majoria del trànsit; la discrepància entre ambdues fonts existia, però eren dades més o menys manejables. El motor carregat en un subdomini o en un iframe tallava la sessió d’Analytics, que perdia el fil de la conversió, i el tracking acabava mostrant conclusions errònies sobre quin canal o campanya estava realment funcionant.
El consentiment de cookies, la gran barrera per a GA4
En el panorama actual, la compilació 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ó de multitud de sistemes per evitar el rastreig, una part significativa dels visitants rebutja el tracking de forma automàtica i, per compensar aquest buit, GA4 aplica modelització estadística 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ó o atribució de canal ja no és una anàlisi amb marge d’error acceptable, és comparar dos sistemes que mesuren realitats diferents amb metodologies diferents, i qualsevol decisió comercial construïda sobre aquesta comparació descansa sobre una base molt més fràgil de la que sembla.
A aquesta opacitat estructural s’hi suma una capa addicional que creix més ràpid del que molts panells d’analítica són capaços de reflectir: el software antitracking que el mateix usuari instal·la de forma voluntària. 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ó de rastreig millorada, intercepten l’script de GA4 o del píxel de conversió abans que arribi a executar-se, de manera que la visita ni tan sols apareix com a sessió perduda, simplement no existeix per a l’eina de mesurament. Les VPN afegeixen una altra capa de distorsió diferent: no bloquegen el tracking en si, però emmascaren la IP real del visitant i sovint alteren la seva geolocalització aparent, el que descol·loca els informes de procedència geogràfica i pot fer que una mateixa persona es registri com a dues sessions diferents si canvia de servidor VPN a mitja navegació. El resultat combinat és que una part del trànsit, i precisament la més sensible a temes de privacitat, queda sistemàticament invisible o mal atribuïda en qualsevol eina que depengui de JavaScript de client, el que reforça encara més la idea de que la dada de servidor del motor de reserves ha de ser l’ancoratge de qualsevol anàlisi seriosa de conversió, i no un complement de la dada d’Analytics.
Dit això, sí que és possible seguir el recorregut d’un viatger des de la visita a la web fins a la contractació al motor, encara que exigeix una configuració deliberada i no la que ve de “fàbrica” en la majoria d’instal·lacions, per la qual cosa es necessita en la majoria dels casos una empresa especialitzada en Google Tag Manager i que sigui capaç d’interpretar codi. El primer requisit és 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è el client ID viatgi entre ambdós 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àmetres d’URL o amb el propi proveïdor del motor. El segon requisit és instrumentar el motor amb els mateixos esdeveniments estàndard que utilitza qualsevol ecommerce: inici del procés de reserva, selecció d’habitació, introducció de dades de l’hoste, inici del pagament i compra confirmada, cadascun amb la seva marca de temps i el seu identificador de transacció. Sense aquests esdeveniments intermedis, el motor només 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és rellevant per l’impacte del consentiment en la qualitat de la dada, és 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ò sense saltar-se les normes de la llei de protecció de dades de torn.
El teu motor de reserves i la seva responsabilitat legal
Precisament perquè tota aquesta instrumentació implica tractar dades personals, el marge de maniobra tècnic està condicionat per un marc legal que convé prendre’s seriosament i no com un tràmit del banner de cookies. A la Unió Europea, el RGPD exigeix una base legal explícita per a qualsevol cookie no estrictament necessària, el que a la pràctica significa consentiment previ, informat i revocable, gestionat a través d’una plataforma de consentiment (CMP) que ha de registrar i poder demostrar què va acceptar cada usuari i quan; a Espanya, la LSSI-CE afegeix l’obligació d’informar amb claredat abans que s’executi qualsevol script de tercers. L’incompliment no és una qüestió teòrica: l’Agència Espanyola de Protecció de Dades ha sancionat empreses turístiques per activar Google Analytics o píxels publicitaris sense un consentiment vàlid, seguint una tendència que ja van marcar reguladors com la CNIL francesa o el Datenschutzbehörde austríac en declarar l’ús 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ó global anual, el que resulta especialment rellevant per a una consultora o operador amb presència en diversos països, on a més del RGPD conviuen altres règims que exigeixen atenció pròpia, com la CCPA i la seva successora CPRA a Califòrnia, la LGPD al Brasil o les lleis de protecció de dades específiques de cada país llatinoamericà.
Convé no perdre de vista, a més, que bona part d’aquest risc no depèn únicament de la configuració que faci el propi allotjament: no tots els motors de reserva del mercat compleixen amb la legalitat vigent en la captació i el tractament d’aquestes dades, i alguns injecten scripts de tercers, emmagatzemen informació de l’hoste fora de la Unió Europea o gestionen el consentiment de forma deficient sense que l’hotel ho sàpiga fins que arriba una inspecció. 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ïdor extern, així que abans de signar amb qualsevol motor convé exigir per escrit aquestes garanties i no donar-les per suposades només perquè el proveïdor sigui conegut al sector. A això s’hi afegeix la dimensió de seguretat: el motor de reserves maneja dades de pagament que cauen sota l’estàndard PCI-DSS, i qualsevol arquitectura de tracking server-side ha de dissenyar-se per no exposar ni retenir informació sensible de l’hoste més enllà del estrictament necessari, ni convertir el propi servidor en un punt addicional de risc davant d’una bretxa de seguretat.
Com crear un embut de conversió que doni suport a la teva estratègia de revenue management?
Muntar un embut de conversió útil és una qüestió de definir bé els passos i no d’acumular eines. Un embut mínimament informatiu hauria de registrar, com a passos diferenciats, l’arribada a la pàgina de disponibilitat, la selecció de dates i tipus d’habitació, la pantalla de tarifes i extres, el formulari de dades de l’hoste, la pantalla de pagament i la confirmació final, cadascun amb el seu propi esdeveniment i la seva pròpia taxa d’abandonament calculada respecte al pas anterior, no respecte al total de visitants de la web. Aquesta distinció importa perquè barrejar trànsit de la web amb passos del motor en un mateix embut sense marcar la transició entre ambdós sistemes és exactament l’error que porta a atribucions falses. L’exploració d’embuts de GA4, combinada amb les dades de transacció confirmada que reporta el propi motor de reserves i, si es vol anar més enllà, amb eines d’anàlisi 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ó.
Per a un revenue manager, aquest nivell de detall no és un capritx analític, és la base de decisions que mouen directament el RevPAR. Un embut mal instrumentat sol amagar el veritable motiu d’una conversió baixa darrere d’explicacions còmodes sobre preu o competència, quan el problema real és que el motor perd hostes al pas de tarifes i extres perquè la tarifa final no coincideix amb l’anunciada, o a la pantalla de pagament perquè el mètode preferit del mercat d’origen no està disponible. Sense aquest desglossament per pas, qualsevol decisió de mix de canal, d’inversió en campanyes o d’ajust de comissió davant l’OTA es pren sobre una xifra de conversió agregada que no distingeix entre fricció tècnica i decisió real de l’hoste, i això porta a corregir el preu quan el problema és de checkout, o a pujar la inversió en un canal amb un ROAS aparent inflat per una atribució que ja hem vist que és poc fiable. La disciplina de revenue management exigeix separar amb precisió quina part de la caiguda de conversió respon a estratègia comercial, és a dir tarifa, disponibilitat o restriccions, i quina part respon a fricció de producte digital, perquè són palanques diferents i es gestionen amb eines diferents.
La veritat sobre la recopilació de dades
La dada del motor de reserves ha de tractar-se com la font de veritat per a tot allò que sigui volum de reserves i ingressos, mentre que la dada de comportament web ha d’usar-se per entendre intenció i fricció, no per reconciliar xifres de venda ni per buscar veritats absolutes. Tractar ambdues fonts com si mesuressin el mateix és l’error de fons que arrossega bona part dels directius que persegueixen una certesa absoluta en el bigdata, i també una de les cortines de fum més habituals en el discurs comercial dels propis proveïdors de motors de reserva, que venen quadres de comandament i promeses d’atribució perfecta sobre una base de dades que, per disseny, mai pot ser-ho. Evitar aquest engany no exigeix més 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és 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ó final és que cap decisió sobre mix de canal, inversió en màrqueting o estratègia de paritat hauria de recolzar-se en una atribució digital que ja sabem que és parcial per disseny; la dada que de veritat ha de pilotar aquestes decisions és la que confirma la reserva, i la resta de la instrumentació només serveix per entendre per què aquella reserva no va arribar a produir-se.
Necessites auditar el teu sistema de mesurament per saber si disposes de les dades correctes per prendre les decisions encertades? Fem un cafè i ho comentem? wecandoit@thenetrevenue.com
