Els esdeveniments purchase duplicats inflen ingressos i redueixen la confiança en la conversió. Les causes habituals són dues integracions, una etiqueta activada per page view i data layer, recàrregues de thank-you o mesurament de navegador i servidor sense coordinar.
No eliminis comandes reals per corregir Analytics. Repara la recollida, anota el període i utilitza botiga i passarel·la com a fonts financeres.
Demostra la duplicació
Utilitza una compra controlada i revisa DebugView, Tag Assistant i Network. Registra transaction_id, hores, valors i origen.
- dos requests en una càrrega
- un a cada recàrrega
- navegador més servidor
- dos ID diferents per una ordre
- duplicació només als informesNo enviïs correu, adreça o pagament com a paràmetres.
Inventaria totes les fonts
Llista connectors d’analítica, snippets del tema, Google tag, contenidors Tag Manager, consentiment i endpoints server-side.
Revisa scripts i measurement ID duplicats. Una integració pot carregar Google tag directament i una altra mitjançant GTM. Tria un únic propietari de purchase; altres sistemes poden consumir el data layer compartit sense inventar una transacció.
Inspecciona triggers de GTM
L’etiqueta pot disparar amb purchase i també per URL /order-received/. Usa Preview i anota quin trigger activa cada tag.
Prefereix un esdeveniment ecommerce amb camps obligatoris, no la URL. La confirmació es pot recarregar o obrir sense un pagament nou. Limita el trigger duplicat i publica una versió documentada.
Confirma que el contenidor publicat coincideixi amb Preview. Entorns GTM i scripts en cau poden fer que la prova vegi una regla i el client una altra. Anota ID, versió i hostname de cada request.
Prova la recàrrega
Recarrega la confirmació controlada. Si apareix una altra petició, falta protecció de client.
GA4 pot deduplicar ID iguals en alguns processos, però la recollida ha d’enviar un esdeveniment intencionat. Els flags locals poden fallar amb cau o un altre navegador. No utilitzis la clau secreta de la comanda com a identificador.
Coordina navegador i servidor
El mesurament server-side millora cobertura quan el client no torna de la passarel·la. Si continua actiu el navegador, tots dos necessiten el mateix ID i una estratègia explícita.
Registra l’origen en logs segurs i decideix quina ruta mana segons el consentiment. No generis un ID aleatori a cada reintent.
Prova dues crides simultànies amb el mateix ID i una altra minuts després. La protecció ha de ser atòmica i persistent; una marca en memòria no serveix si la petició arriba a un altre worker.
Revisa el consentiment
En acceptar, la plataforma pot alliberar etiquetes en cua després d’haver enviat la compra o inicialitzar mesurament juntament amb GTM.
Prova Acceptar, Rebutjar i indecís en perfils nous. Després del rebuig, analytics opcional ha de continuar apagat. Una acceptació posterior no ha de reproduir compres històriques sense un disseny aprovat.
Aplica la correcció mínima
Desactiva una font o trigger duplicat sense refer tot el data layer. Revisa quins altres events administra el connector abans d’eliminar-lo.
Documenta versió, ID controlat i nombre de peticions abans/després. Neteja assets pertinents i confirma el contenidor públic.
Verifica la integritat
Prova compra, recàrrega, revisita des de la passarel·la i reintent del servidor. Cada ordre ha de produir una compra lògica amb ID, moneda i valor estables.
Comprova DebugView i no només l’informe: dos requests poden quedar deduplicats en ingressos i activar dues conversions publicitàries. Revisa els reemborsaments per separat. El manteniment recurrent ha de comparar ID GA4 únics amb comandes pagades.
Inclou una prova amb el bloquejador del navegador desactivat i una altra amb el consentiment rebutjat. Així distingiràs duplicació estructural d’una diferència esperada entre perfils de mesurament.