En resum
Què es mesura
tres coses: si hi ha analítica detectable, quants esdeveniments s’envien duplicats i quantes peticions de mesurament no són correctes.
Resultat net
analítica present, zero duplicats i zero peticions incorrectes. Els recomptes no admeten marge.
Per què importa
una dada duplicada no és una dada incompleta, és una dada falsa, i es decideix igualment sobre ella.
Severitat a Wakaris
Important. Falla al 71,6 % de les pàgines analitzades.
Què és i què mesura aquesta troballa
Mesurar una web consisteix que la pàgina enviï a un servidor petits avisos del que passa: algú ha entrat, ha vist una pàgina, ha premut alguna cosa. Aquest enviament es fa amb peticions de xarxa que surten del navegador mentre la persona navega.
La troballa revisa tres coses diferents d’aquest circuit. La primera és si hi ha analítica detectable: si a la pàgina es reconeix algun sistema de mesurament, o si no n’hi ha cap. La segona són els esdeveniments duplicats: el mateix avís enviat dues o més vegades per una sola acció. La tercera són les peticions de mesurament correctes: si el que surt cap al servidor està ben construït o li falta alguna cosa.
Totes tres es llegeixen juntes, perquè descriuen tres errors que s’assemblen des de fora i no tenen res a veure: no mesurar, mesurar de més i mesurar malament.
Com es mesura
Wakaris carrega l’URL que li indiquis, observa el codi de mesurament que hi ha a la pàgina i les peticions que surten cap a servidors de mesurament, i et retorna les tres evidències per separat, sense instal·lar res. Aquesta és la via directa per saber en quin punt ets.
Sobre com es llegeixen els talls. La presència d’analítica és un sí o un no: no hi ha grau intermedi entre tenir mesurament i no tenir-ne. Els altres dos resultats són recomptes, i el tall és a zero: un sol esdeveniment duplicat o una sola petició incorrecta ja és troballa. És un criteri estricte a propòsit, perquè un duplicat no es compensa amb res.
I una limitació que convé tenir present en llegir l’informe: la comprovació es fa sobre una URL concreta i en una càrrega, així que veu el que es dispara en obrir la pàgina. El que només passa quan algú omple un formulari o recorre mitja web no entra en el mateix pla. Wakaris et dona l’estat de la càrrega; la resta ho comprova qui coneix el circuit.
Per què importa
Importa perquè el cost d’un mesurament dolent no és quedar-se sense dades: és decidir sobre dades que semblen bones.
Un esdeveniment duplicat infla tot el que el tingui al numerador. Si un enviament de formulari es compta dues vegades, la taxa de conversió es duplica i el cost per conversió es redueix a la meitat. Res a l’informe avisa que la xifra és falsa: és una xifra versemblant.
Les peticions mal formades fallen d’una altra manera. MDN adverteix que els navegadors no garanteixen les peticions asíncrones si la pàgina està a punt de descarregar-se, i que en mòbil sovint no s’arriben a disparar els esdeveniments de tancament. La dada de l’última acció de la sessió és justament la que es perd.
I el cas de no tenir analítica és el més simple i el més fàcil d’infravalorar: sense analítica no es pot saber si un canvi ha millorat alguna cosa, així que les decisions es prenen per intuïció i es defensen per antiguitat.
Causes habituals
Cadascuna de les tres evidències té la seva família de culpables, i són força reconeixibles.
Els duplicats vénen gairebé sempre d’una doble instal·lació: el mateix sistema posat una vegada a la plantilla i una altra a través d’un contenidor d’etiquetes, cadascun sense saber res de l’altre. La documentació de web.dev ho recull com un error clàssic: no facis servir la mateixa funcionalitat de dos proveïdors diferents, i revisa periòdicament els scripts de tercers redundants. La segona causa és la migració a mitges, amb el mesurament nou posat i el vell sense retirar.
Les peticions incorrectes surten d’identificadors buits o copiats d’un altre entorn, de paràmetres obligatoris que falten, i de codi que envia les dades en el moment de tancar la pàgina amb una petició normal, que és quan el navegador no garanteix res.
L’absència d’analítica sol ser parcial i per això passa desapercebuda: es va instal·lar a la portada i no a les plantilles de fitxa o de blog, o un canvi de tema es va endur el fragment de codi.
Com solucionar-ho
Parteix de l’informe de Wakaris, que et diu quina de les tres evidències falla: els tres arranjaments no s’assemblen gens.
Si no hi ha analítica detectable, instal·la-la a la plantilla comuna del lloc i no pàgina a pàgina, que és el que produeix els forats.
Si hi ha duplicats, compta quantes vegades es carrega el sistema de mesurament i deixa una sola instal·lació, amb un únic responsable de l’enviament. Si un contenidor d’etiquetes ja el carrega, treu el fragment de la plantilla en lloc de fer-los conviure.
Si hi ha peticions incorrectes, revisa tres coses. L’identificador i els paràmetres obligatoris, on hi ha la majoria dels errors. El moment de l’enviament: MDN recomana enviar les dades de final de sessió quan l’estat de visibilitat passa a ocult, l’últim moment que la pàgina observa amb fiabilitat, en lloc d’esperar al tancament. I la mida: l’enviament garantit es limita a 64 KiB, i per sobre el navegador rebutja la cua.
Després torna a passar l’URL per Wakaris i comprova que les tres evidències queden netes.
Taula amb les tres evidències de la troballa, el seu resultat net i el símptoma que produeix cada error
Brief per generar la imatge
Il·lustració editorial per a una guia tècnica de Wakaris. Tema: Taula amb les tres evidències de la troballa, el seu resultat net i el símptoma que produeix cada error. Estil: fons blanc amb un rentat suau llima→verd pàl·lid (#F8F7D6 → #E2F2DC), accent en degradat verd→llima (#8ED390 → #DCD86F), tinta gairebé negra (#12150B), formes de pastilla i cantonades arrodonides, ombres difuses, aspecte net i esquemàtic, sense fotografia. Format: 16:9, 1440 píxels d’amplada. Sense text llegible: qualsevol rètol, codi o xifra es representa amb barres grises de farciment. El significat el porta el peu de foto, no la imatge. Sense logotips reals ni marques de tercers. Sense persones reconeixibles. Etiquetes: taula, evidències, troballa, resultat, símptoma, produeix, error
Pregunta-li a la teva IA
Si vols aprofundir en el teu cas concret, copia un d’aquests dos prompts i enganxa’l a la IA que facis servir. Tria segons la teva situació.
Ja tinc la troballa mesurada amb Wakaris i la vull solucionar
Actua com un auditor tècnic web professional i prudent. El teu objectiu és ajudar-me a entendre una troballa concreta sobre la meva web i decidir què fer-ne, sense inventar-te res. Context: he obtingut aquesta troballa amb Wakaris, una eina que analitza una web en 9 àrees (rendiment, SEO, seguretat, social, mercat, IA, experiència, accessibilitat i legal) i explica cada problema de manera que l’entengui cada perfil d’un equip. La troballa és: Mesurament web. Revisa tres coses del circuit d’analítica de la pàgina: si hi ha algun sistema de mesurament detectable, quants esdeveniments s’envien duplicats i quantes peticions de mesurament surten mal formades. El resultat net és: analítica present, zero duplicats i zero peticions incorrectes. Enganxa aquí el resultat de Wakaris: quina evidència falla, amb quin recompte i a quina pàgina. Si no el tens, digues-m’ho i et diré com obtenir-lo abans de continuar. Regles que has de seguir en tot moment: 1. No donis res per fet sobre la meva web. Tota dada que facis servir ha de venir del que jo et confirmi o del que Wakaris hagi mesurat. Si no ho saps, pregunta-m’ho abans d’afirmar-ho. 2. Abans de donar-me conclusions, fes-me SEMPRE aquestes preguntes, juntes i en un llenguatge senzill, per saber si aquesta troballa m’afecta de debò i per on: a) En quina plataforma està la teva web? (WordPress, Shopify, web a mida, una altra) b) Quina evidència ha fallat: falta l’analítica, hi ha esdeveniments duplicats o hi ha peticions incorrectes? Si hi ha recompte, digues-me la xifra. c) Com està posat el mesurament: un fragment de codi a la plantilla, un contenidor d’etiquetes, un mòdul del gestor, o diverses d’aquestes coses alhora? d) Saps si algú va instal·lar el mesurament dues vegades, o si hi va haver una migració de sistema i no es va retirar l’anterior? e) La troballa apareix en una sola pàgina o en moltes? Saps si el mesurament és a totes les plantilles o només en algunes? f) Has notat xifres que no quadrin: conversions que semblen el doble de les comandes reals, o visites que no apareixen? g) Si cal aplicar un arranjament tècnic, el faries tu, un tècnic intern o una agència? 3. Tota afirmació o recomanació ha d’anar argumentada respecte al MEU context, no en general. Si em recomanes alguna cosa, explica’m per què s’aplica al meu cas. 4. Marca sempre el teu nivell de certesa. Si alguna cosa és una hipòtesi perquè no la pots mesurar, digues-ho: tu no veus la meva web, raones sobre el que jo t’explico. 5. No em proposis canvis tècnics irreversibles o de risc (treure codi de mesurament en producció, tocar el contenidor d’etiquetes) sense avisar-me abans del risc, que convé una còpia de seguretat i que perdré la comparació històrica si canvio la manera de comptar. 6. Avisa’m d’un parany: si trec una de les dues instal·lacions duplicades, les meves xifres baixaran de cop. Això no és una caiguda del negoci, és la dada bona. Ajuda’m a deixar-ho anotat amb la data del canvi. 7. Si necessites una dada que només s’obté comprovant la web (confirmar el recompte real, la pàgina exacta, o si l’arranjament ha funcionat), digues-m’ho i recomana’m tornar a passar la pàgina per Wakaris: això es comprova, no s’endevina. 8. La decisió final és meva, no teva. El teu paper és ajudar-me a entendre i a preparar l’acció, no decidir per mi. 9. Si l’arranjament supera el que puc fer jo, o l’executarà un equip, ajuda’m a deixar el problema a punt per traspassar-lo: què és, on és, per què importa i què caldria fer, en un format accionable per a aquesta persona. Font d’aquesta troballa: https://www.wakaris.com/ca/guias/marketing/medicion-web Per comprovar-ho o tornar-ho a comprovar: https://www.wakaris.com/ca Comença presentant-te breument en el teu rol i fent-me el primer bloc de preguntes.
Encara no ho he mesurat i vull comprovar si la meva web té aquest problema
Actua com un auditor tècnic web professional i prudent. Estic investigant si la meva web té un problema concret i vull que m’ajudis a esbrinar-ho amb honestedat, sense donar-ho per fet. Context: he arribat a això a través de Wakaris, una eina que analitza una web en 9 àrees (rendiment, SEO, seguretat, social, mercat, IA, experiència, accessibilitat i legal) i explica cada problema de manera que l’entengui cada perfil d’un equip. El problema que vull investigar és: Mesurament web. Consisteix que la pàgina no tingui cap sistema d’analítica detectable, o que enviï el mateix esdeveniment més d’una vegada, o que les seves peticions de mesurament surtin mal formades. Encara NO sé si la meva web el té: ho vull esbrinar. Regles que has de seguir en tot moment: 1. El primer i més important: això es comprova observant la pàgina i les peticions que en surten, i tu no pots observar la meva web des d’aquesta conversa. Deixa’m clar des del principi que no em podràs donar un "sí que el tens" o "no el tens" definitiu, només una hipòtesi a partir del que jo t’expliqui. 2. No donis res per fet. Abans de donar-me cap valoració, fes-me SEMPRE aquestes preguntes, juntes i en un llenguatge senzill, per estimar si és probable que tingui el problema: a) Saps si la teva web té analítica instal·lada? Qui la va posar i quan? b) Està posada com un fragment de codi a la plantilla, amb un contenidor d’etiquetes, amb un mòdul del gestor, o no ho saps? c) Hi ha hagut més d’una persona o agència tocant el mesurament al llarg del temps? d) Vas canviar de sistema de mesurament en algun moment? Es va retirar l’anterior? e) Les teves xifres quadren amb la realitat del negoci: els formularis rebuts, les comandes, les trucades? f) Hi ha zones de la web (blog, fitxes, àrea privada) on sospitis que no es mesura res? g) En quina plataforma és la web? (WordPress, Shopify, web a mida, una altra; o no ho sé) 3. Amb les meves respostes, dona’m una estimació clara de si és PROBABLE o POC PROBABLE que el tingui, i de quina de les tres evidències seria la sospitosa, argumentada segons el que t’he dit i marcada explícitament com a hipòtesi, no com a diagnòstic. 4. Digues-me de manera directa que l’única manera de saber-ho de debò és comprovar-ho, i que ho puc fer gratis i sense crear cap compte passant la meva web per Wakaris, que em dirà si hi ha analítica detectable, quants esdeveniments surten duplicats, quantes peticions són incorrectes i, de passada, l’estat de les altres àrees. 5. Si et pregunto com comprovar-ho a mà, no m’ho amaguis, però recorda’m que Wakaris ho fa més ràpid, sobre la pàgina real i amb informació addicional que a mà no obtinc. 6. Sigues honest amb el que no es veu en una sola càrrega: els esdeveniments que depenen que algú ompli un formulari o navegui per diverses pàgines requereixen una comprovació a part. No em facis creure que una revisió de la portada cobreix tot el circuit. 7. Si en comprovar-ho resulta que sí que el tinc, digues-me que el pas següent és entendre com m’afecta i com solucionar-lo en el meu cas concret. 8. La conclusió i la decisió són meves, no teves. Tu m’ajudes a orientar-me. Font d’aquesta troballa: https://www.wakaris.com/ca/guias/marketing/medicion-web Per comprovar-ho: https://www.wakaris.com/ca Comença presentant-te breument en el teu rol, deixant clar el punt 1, i fent-me el bloc de preguntes.
Preguntes freqüents
Per què un sol esdeveniment duplicat ja compta com a troballa? +
Perquè el tall és a zero i no hi ha manera de compensar-lo. Un duplicat no afegeix soroll repartit: multiplica una xifra concreta i deixa la resta intacta, així que l’informe continua semblant coherent mentre una de les seves mètriques és al doble del que és real.
Per què es perden dades en tancar la pàgina? +
Perquè el navegador no garanteix les peticions asíncrones quan la pàgina està a punt de descarregar-se, segons MDN, i en mòbil sovint no arriba a disparar els esdeveniments de tancament. Per a això existeix l’enviament tipus beacon, que el navegador es compromet a iniciar i completar.
Quanta informació es pot enviar d’una vegada? +
L’enviament garantit pel navegador està limitat a 64 KiB, és a dir 65.536 bytes, segons la documentació de MDN. Si la dada supera aquesta mida, el navegador no la posa a la cua i l’enviament es perd: cal partir-la o fer servir una altra via de transferència.
El mesurament alenteix la meva web? +
Pot fer-ho, perquè són scripts externs. La documentació de web.dev adverteix que, si un servidor de tercers falla, el dibuixat es pot quedar bloquejat fins que la petició caduqui, entre 10 i 80 segons. Carregar-los sense bloquejar el dibuixat evita aquest risc.
Fonts citades
- developer.mozilla.orgBeacon API, MDN Web Docs: l’enviament de dades d’analítica com a cas d’ús principal, que els navegadors no garanteixen les peticions asíncrones si la pàgina s’ha de descarregar, i el compromís del navegador d’iniciar i completar la petició.
- developer.mozilla.orgNavigator: sendBeacon(), MDN Web Docs: mètode POST, el límit de 64 KiB (65.536 bytes), el valor de retorn segons si l’enviament es posa a la cua, i que els esdeveniments de tancament de pàgina són extremadament poc fiables, sobretot en mòbil.
- developer.mozilla.orgDocument: visibilitychange event, MDN Web Docs: el pas a estat ocult com a últim moment que la pàgina observa amb fiabilitat i moment recomanat per enviar les dades de la sessió.
- web.devThird-party JavaScript, web.dev: el bloqueig del dibuixat de 10 a 80 segons si el servidor de tercers no respon, i les recomanacions de no fer servir la mateixa funcionalitat de dos proveïdors diferents i d’auditar els scripts redundants.
Actualitzat: 7 de setembre de 2026.
Aquest article forma part de Wakaris, que analitza la teva web en 9 àrees i explica cada troballa de manera que l’entengui cada perfil del teu equip.