Obres Google Ads i hi ha una xifra de vendes. Obres GA4 i n'hi ha una altra. Meta Ads en compta unes quantes més. I al panell de la botiga, les comandes reals no coincideixen amb cap de les tres. No és mala sort: és el que passa quan tota la mesura d'un ecommerce depèn d'etiquetes que s'executen al navegador del client.
Google Ads ha publicat documentació específica sobre les conversions multi-source, encara en beta, que la premsa especialitzada va recollir el 16 de setembre de 2026. La idea és que la conversió web que ja mesura l'etiqueta es pugui complementar amb una segona font que surt del backend del negoci, com un CRM o una base de dades de comandes.
Aquí no repetim la notícia. Expliquem per què la font més fiable d'una venda continua sent la comanda real, què exigeix Google perquè aquesta segona font sumi sense duplicar res, i com ho hem plantejat en un ecommerce en PrestaShop, on primer hem ordenat la dada a casa.
La següent evolució de la mesura no és posar més etiquetes, sinó connectar millor les etiquetes amb les comandes reals de l'ecommerce.
El problema: GA4 i Google Ads no sempre veuen tota la realitat
Quan algú compra a la teva botiga passen dues coses que solem pensar com si fossin una. Al servidor es crea una comanda amb un número, un import, una moneda i un estat. Al navegador del client, la pàgina de confirmació executa un fragment de codi que avisa GA4, Google Ads i Meta Ads que hi ha hagut una compra.
La comanda no falla mai: sense comanda no hi ha venda. L'avís del navegador depèn de coses que no controles:
El problema no és estètic. Google Ads i Meta Ads decideixen on van els teus diners a partir de les conversions que reben. Si una campanya ven però la plataforma només en veu una part, l'algoritme pot retirar-li pressupost. Si compta vendes que després es cancel·len, pot premiar el que no et convé. Ho trobem sovint quan obrim un compte: el sistema comptava com a client qui no ho era, i el pressupost seguia aquella pista falsa.
Què són les conversions multi-source de Google Ads
La definició oficial és prou clara:
"By combining your tag-based website measurement and your additional data you can supplement the online signals captured by your Google tag with additional conversion data uploaded with Data Manager or Data Manager API from your backend systems, like a CRM or order database."
A la pràctica, la mateixa acció de conversió de Google Ads rep dues fonts: l'etiqueta de sempre i el registre de comandes del teu backend, connectat amb Google Ads Data Manager o amb la Data Manager API. Google les uneix amb l'identificador de transacció, que en una botiga és el número de comanda. Segons la documentació oficial, això permet:
- Recuperar conversions que l'etiqueta no va captar, si la comanda porta algun identificador que permeti atribuir-la a un clic d'anunci.
- Actualitzar el valor d'una conversió existent amb rectificacions, vendes addicionals o imports finals de la cistella.
- Completar dades d'usuari que l'etiqueta no va recollir, com el correu o el telèfon, que Google converteix en un format irreversible (hash).
Abans d'entusiasmar-se, els límits. És una beta i potser encara no està disponible per a tots els comptes. Només funciona amb accions de conversió web configurades manualment amb codi, amb l'etiqueta de Google o amb Google Tag Manager. No serveix per a les conversions importades de Google Analytics ni per a les basades en una URL. Primer entrebanc per a qualsevol ecommerce que mesura així: si les compres arriben a Google Ads importades des de GA4, l'opció ni tan sols apareix.
Per què el backend de l'ecommerce ha de ser la font fiable
La comanda existeix encara que el client hagi rebutjat les cookies, tingui un bloquejador o la pàgina de confirmació no hagi carregat. Té un identificador únic, un import real, una moneda i, sobretot, un estat: pagada, enviada, cancel·lada, retornada. L'etiqueta només veu l'instant de la pàgina de gràcies. No sap res del que passa després.
Google ho diu sense ambigüitats:
"The additional data source should be your complete and authoritative record of all relevant transactions (for example, from the e-commerce backend or CRM), not an export from another tag-based analytics system, which may also be affected by signal loss."
Una conseqüència fàcil de passar per alt: exportar les compres de GA4 i pujar-les com a segona font no arregla res, perquè GA4 també depèn d'etiquetes i té els mateixos forats.
I un segon detall que fa pujar el pes de la decisió: quan l'identificador d'una comanda coincideix amb una conversió de l'etiqueta, el valor que puges substitueix el de l'etiqueta de manera permanent. «Your additional data source becomes the source of truth for conversion value», diu Google. Si el backend està ordenat, és una bona notícia: fins i tot una devolució total es pot reflectir amb un valor 0. Si no ho està, és un problema.
Ara bé, cal afinar la idea. El backend és la font fiable de què s'ha venut, però no de d'on ha vingut. Una comanda no sap, per si sola, si el client va arribar des d'un anunci de Google, d'una campanya de Meta o escrivint l'adreça. Si ningú guarda aquesta relació a temps, es perd. És el buit que resol el cas que expliquem més avall, i el que separa una botiga que es pot mesurar d'una que acumula informes que no quadren.
L'error habitual: mesurar només amb etiquetes
Quan les xifres no quadren, la reacció habitual és afegir-hi més etiquetes: un segon píxel, un connector nou, un altre esdeveniment de compra «per si de cas». Més etiquetes no donen més veritat: donen més versions de la mateixa venda, i sovint vendes comptades dues vegades.
- La venda existeix per a la plataforma només si l'etiqueta s'executa al navegador.
- Consentiment, bloquejadors i errors d'implementació deixen forats que ningú veu.
- Cada plataforma dona la seva xifra i cap es pot contrastar amb les comandes.
- Les cancel·lacions i les devolucions no arriben mai a l'algoritme.
- Quan no quadra, s'hi afegeixen etiquetes i augmenta el risc de duplicar.
- L'etiqueta dona el senyal ràpid, però la referència és la comanda.
- Cada venda es pot resseguir fins a un identificador de comanda únic.
- El canal de captació queda associat a la comanda, no només a una visita.
- L'estat final de la comanda forma part de la dada.
- Les diferències entre plataformes i comandes es poden detectar i explicar.
Les etiquetes continuen sent imprescindibles: són ràpides i alimenten l'optimització gairebé en temps real. Google recomana recollir les dades d'usuari per totes dues vies, perquè la connexió amb el backend fa de recanvi quan l'etiqueta falla. El que no funciona és tractar-les com l'única font. Passa igual a Meta Ads, on el Píxel i la Conversions API no són rivals, sinó dues vies que s'han de deduplicar, i a Google, on els canvis en com es mostren els anuncis trenquen supòsits clàssics del tracking.
Arquitectura recomanada: del clic a la comanda real
No hi ha una única manera de construir-ho, però sí un ordre lògic que evita la majoria d'errors. Cinc capes, cadascuna dependent de l'anterior:
Dues precisions. La primera: saber el canal i tenir l'identificador del clic no és el mateix. Per respondre «d'on ve aquesta comanda» n'hi ha prou amb el canal. Per enviar una conversió addicional a Google Ads cal l'identificador que la lliga a un clic concret (GCLID, GBRAID o WBRAID) o dades d'usuari amb el tractament adequat. Si vols deixar la porta oberta a una fase posterior, decideix-ho al principi.
La segona: tot el que es desa al navegador o s'envia a una plataforma ha de respectar el consentiment de l'usuari. Com s'aplica en cada botiga s'ha de revisar amb qui porta la privacitat del negoci; aquest article no hi dona consell legal. Sí que recorda el que la documentació de Google deixa clar: només els esdeveniments amb consentiment serveixen per complementar les conversions.
Cas pràctic anònim: una integració en un ecommerce PrestaShop
En un projecte recent sobre un ecommerce en PrestaShop, a Daimatics hem implementat una capa d'atribució interna per associar el canal de captació amb la cistella i, després, amb la comanda real. No donem cap dada que permeti identificar el negoci; sí l'arquitectura, que és el que serveix a qualsevol altra botiga:
- Google Tag Manager detecta el canal d'entrada de l'usuari.
- La lògica identifica els senyals de cada origen: gclid, gbraid o wbraid per a Google Ads; fbclid o les UTM de Meta per a Meta Ads; UTM genèriques; la web de procedència per a l'orgànic, i l'absència de senyals per al trànsit directe.
- El canal es desa al navegador perquè no es perdi durant la navegació.
- La botiga exposa l'identificador de la cistella a la capa de dades.
- Google Tag Manager recull aquest identificador.
- Google Tag Manager envia al backend de la botiga dues dades: l'identificador de la cistella i el canal.
- El backend desa aquesta relació.
- Quan la cistella es converteix en comanda, el canal queda associat a la comanda real.
Què s'ha validat. En preproducció s'han validat correctament tres canals: Google Ads (CPC), Meta Ads i trànsit directe. L'orgànic queda contemplat per la lògica de la web de procedència, però es podrà validar millor amb trànsit real quan estigui publicat. Una validació en preproducció demostra que la lògica funciona, no quantes vendes s'hi associaran.
Què no s'ha fet, i per què importa. No s'ha creat cap conversió nova ni s'ha duplicat cap compra. La integració no envia cap altra compra a GA4 ni a Google Ads. Només desa una atribució interna:
I convé dir-ho clar: no és una implementació de conversions multi-source, ni una pujada de conversions offline a Google Ads, ni una connexió amb Google Ads Data Manager. I GA4 no queda substituït. És el pas previ: ordenar la dada a casa perquè qualsevol fase posterior tingui una base sòlida.
Com evitar duplicar conversions
Si un dia es connecta una font addicional, el risc més car és comptar dues vegades la mateixa venda. Un algoritme que veu més compres de les que hi ha no només infla informes: pot aprendre que campanyes mediocres són bones i posar-hi més pressupost. Cinc punts de la documentació de Google que convé tenir clars:
1. La deduplicació només passa dins d'una mateixa acció de conversió
"Google Ads only removes duplicate data within a single conversion action (between the tag and the additional data source), not across two different conversion actions."
Per això Google recomana afegir la font a l'acció de compra que ja existeix. Si se'n crea una de nova, no pot compartir objectiu de campanya amb l'original. Tampoc aconsella fer proves amb una acció duplicada: si cal comparar, parla de 28 dies d'escalfament.
2. El mateix identificador de transacció, exactament
Google enumera els errors típics: prefixos («order-12345» davant de «12345»), majúscules i minúscules, «12345» davant de «12345.0», zeros a l'esquerra o valors de mostra. L'identificador ha de ser únic, generat pel backend, de 64 caràcters com a màxim i sense dades que identifiquin el client. Si en dos dies coincideixen menys del 10% dels identificadors, Google avisa que les conversions poden estar sobrecomptades.
3. Els imports, en les mateixes unitats
Si l'etiqueta envia euros amb decimals i la base de dades guarda cèntims, Google no ho converteix. L'exemple és seu: 1000 en cèntims s'interpreta com 1.000 dòlars. I com que aquest valor sobreescriu el de l'etiqueta, l'error arriba a les estratègies d'oferta per valor. Google llança una alerta urgent si els dos valors es diferencien més de deu vegades en dos dies.
4. Els primers 14 dies no compten per a les ofertes; després sí, amb alertes o sense
Des de la primera pujada, les conversions noves surten als informes i als diagnòstics, però no a les ofertes, i les actualitzacions de valor queden desactivades. Passats 14 dies entren a les ofertes automàticament, «regardless of any diagnostic alerts». Aquests dies són per revisar, no per esperar.
5. Una sola font
Des de Data Manager només es pot connectar una font addicional per acció de conversió. L'API en permet més, però Google ho desaconsella: si les comandes viuen en dos sistemes, s'unifiquen abans.
Què fa Google Ads amb cada comanda de la font addicional| Situació | Què passa |
|---|---|
| L'identificador coincideix amb una conversió de l'etiqueta | El valor i la moneda de la font substitueixen els de l'etiqueta (acabat el període de prova) |
| Coincideix, i l'etiqueta no tenia dades d'usuari | S'hi afegeixen les dades d'usuari de la font |
| Coincideix, però altres camps són diferents, com l'identificador de clic | S'ignoren: manen els de l'etiqueta |
| No coincideix amb cap conversió | Es crea una conversió nova i Google intenta atribuir-la a un clic |
| El valor enviat és 0 | És vàlid, per exemple per a una devolució total |
En el cas de PrestaShop, no crear cap conversió nova no era una limitació: era la manera més segura de no duplicar-ne cap mentre la dada es validava.
Quines dades convé guardar des del principi
Si una botiga vol tenir oberta la porta a una segona font, la feina comença molt abans de connectar res:
- Identificador de comanda únic, el mateix que envia l'etiqueta i amb el mateix format.
- Data i hora de la conversió, amb la zona horària.
- Valor real de la comanda, en les mateixes unitats que l'etiqueta.
- Moneda.
- Identificadors de clic quan n'hi hagi: GCLID, GBRAID o WBRAID.
- Dades d'usuari quan escaigui i amb el tractament adequat.
- Consentiment registrat a cada comanda.
- Estat final de la comanda: pagada, cancel·lada o retornada.
- Canal de captació detectat.
No totes pesen igual. Identificador i data són obligatoris. D'identificadors d'atribució, Google en demana com a mínim un i recomana combinar el GCLID amb dades d'usuari: sense cap identificador d'atribució, la venda existeix, però Google no la pot lligar a un anunci. L'estat final i el canal no els demana Google, però són els que et diuen a tu si la venda s'ha cobrat i quina campanya la va portar.
El consentiment també és dada. Google permet indicar-lo fila a fila i només fa servir els esdeveniments amb consentiment. Si una fila no en porta, s'apliquen els valors per defecte del compte, que convé revisar.
I la frescor mana sobre l'històric. Google recomana pujar les dades dins de les 24 hores posteriors a la conversió, i avisa que pujar un any de vendes antigues no millora el rendiment actual: les actualitzacions de valor només es processen per a conversions dels últims 55 dies.
Quin paper pot tenir Google Ads Data Manager en una fase posterior
Google Ads Data Manager és l'eina de Google per portar dades pròpies de fora de Google a Google Ads amb una interfície de punt i clic. És al menú d'Eines del compte, i és per on passa la connexió d'una font addicional. Hi ha dues vies:
- Connexió directa, la que Google recomana quan està disponible. La llista oficial de fonts amb connexió directa inclou bases de dades com MySQL, PostgreSQL o BigQuery, Google Sheets, fitxers per SFTP o HTTPS i plataformes com Shopify, HubSpot o Salesforce. Si una font no hi és, Google remet a integracions de partners.
- Data Manager API, per a enviaments automatitzats per codi. Per connectar fonts addicionals, la documentació la reserva als comptes d'una llista d'accés.
Per què «fase posterior»? Perquè connectar és l'últim pas. Abans cal respondre que sí a quatre preguntes:
- La compra es mesura a Google Ads amb una acció de conversió web configurada amb codi, i no importada de GA4?
- L'etiqueta de compra ja envia un identificador de transacció únic i dinàmic?
- El backend guarda aquell mateix identificador, l'import en les mateixes unitats, la moneda, la data i l'estat?
- Hi ha identificadors d'atribució i consentiment registrats per a cada comanda?
Si alguna resposta és no, connectar ara vol dir importar el desordre. Si totes són sí, té sentit, i els 14 dies de prova serveixen per llegir els diagnòstics abans que la dada entri a les ofertes. Primer la dada, després la plataforma: el mateix ordre que defensem quan parlem de gestionar campanyes de Google Ads.
Conclusió: mesurar millor abans d'optimitzar més
Les campanyes no poden optimitzar bé si les plataformes no reben, o no interpreten correctament, les vendes reals. Aquesta beta apunta en una direcció clara: amb l'etiqueta sola no n'hi ha prou, i per al valor, la referència passa a ser la comanda del backend. Com més decisions es deleguen en sistemes automàtics, més pesa la qualitat de la dada que se'ls dona.
Una arquitectura que lliga canal, cistella i comanda va més enllà de Google Ads. És la base que permet alimentar una capa interna d'intel·ligència de negoci capaç de creuar comandes reals, canals detectats, GA4, Google Ads i Meta Ads, tenint en compte l'estat de cada comanda, el valor real i les devolucions o cancel·lacions. L'objectiu no és un informe més: és detectar les discrepàncies entre el que l'ecommerce ven realment i el que les plataformes publicitàries o analítiques aconsegueixen mesurar.
És el tipus de dada ordenada que necessita qualsevol sistema d'anàlisi, també Daimatics OS, l'ecosistema tecnològic propi que dona suport al model de treball de Daimatics: centralitza i relaciona dades, evidències, analítica, coneixement i processos de diferents disciplines per ampliar la capacitat d'anàlisi, priorització, execució i millora contínua de l'agència. No és una IA que ho fa tot. I sense dada ordenada, cap anàlisi no pot comparar res.
L'avantatge competitiu no és només invertir més en campanyes, sinó construir una mesura que connecti la captació amb la comanda real. Primer mesurar millor. Després, optimitzar més.
Preguntes freqüents
Què són les conversions multi-source de Google Ads?
Són una funció en beta que permet complementar una acció de conversió web de Google Ads, la que mesura l'etiqueta, amb una segona font de dades del backend del negoci, com una base de dades de comandes o un CRM. Les dues fonts s'uneixen per l'identificador de transacció. Segons Google, això pot ajudar a recuperar conversions que l'etiqueta no ha captat, a actualitzar-ne el valor i a completar dades d'usuari. En castellà, Google les anomena «conversiones de varias fuentes».
Les conversions multi-source substitueixen GA4 o l'etiqueta de Google?
No. La funció existeix per complementar l'etiqueta, i només està disponible per a accions de conversió web configurades amb codi a través de l'etiqueta de Google o de Google Tag Manager. GA4 tampoc queda substituït: continua sent l'eina d'analítica del web. De fet, les conversions importades de GA4 a Google Ads no poden fer servir aquesta funció; en aquest cas, Google indica que la combinació de dades s'ha de resoldre dins de Google Analytics abans d'importar-les.
Com evito que Google Ads compti dues vegades la mateixa venda?
Amb tres precaucions. Connectar la font addicional a l'acció de conversió de compra que ja existeix, perquè Google només deduplica dins d'una mateixa acció. Assegurar que l'etiqueta i el backend envien exactament el mateix identificador de comanda, sense prefixos, zeros a l'esquerra ni formats diferents. I no afegir una segona acció de compra al mateix objectiu de campanya. La pestanya de diagnòstics avisa si en dos dies coincideixen menys del 10% dels identificadors.
Es poden recuperar totes les vendes que Google Ads no ha vist?
No sempre, i convé desconfiar de qui ho prometi. Perquè una comanda recuperada s'atribueixi a un anunci, ha de portar almenys un identificador d'atribució, com l'identificador de clic de Google o dades d'usuari amb el tractament adequat. A més, només es fan servir els esdeveniments amb consentiment, i les dades que arriben tard perden pes per a les ofertes. Google diu que la funció «pot ajudar» a recuperar conversions perdudes, no que les recuperi totes.
Quines dades ha de tenir la meva botiga per fer servir una font addicional?
Com a mínim, l'identificador de la comanda, el mateix que envia l'etiqueta, i la data i hora de la conversió. A més, almenys un identificador d'atribució: GCLID, GBRAID, WBRAID o dades d'usuari com el correu o el telèfon; si no n'hi ha cap, Google demana camps d'adreça. Convé enviar també el valor i la moneda, en les mateixes unitats que l'etiqueta, i el consentiment de cada comanda.
Connectar una font addicional afecta les campanyes des del primer dia?
No. Des de la primera pujada de dades, la font entra en un període de prova de 14 dies: les conversions noves apareixen als informes i als diagnòstics, però no s'utilitzen per a les ofertes, i el valor de l'etiqueta no se sobreescriu. Passats els 14 dies, la font entra a les ofertes automàticament, encara que hi hagi alertes de diagnòstic pendents. Per això s'han de revisar durant aquell període.
Què passa amb el consentiment de les cookies?
Google permet indicar el consentiment de cada fila de dades amb dos camps, un per a l'ús de dades d'usuari en publicitat i un altre per a la personalització d'anuncis, i només fa servir els esdeveniments amb consentiment per complementar les conversions. Si una fila no porta informació de consentiment, s'apliquen els valors per defecte del compte. Com s'ha de recollir en cada negoci ho ha de revisar qui porta la privacitat de l'empresa: aquí només expliquem com ho tracta Google Ads.
Tinc una botiga en PrestaShop: la puc connectar directament a Google Ads Data Manager?
PrestaShop no apareix a la llista oficial de fonts amb connexió directa de Data Manager que hem consultat el 17 de setembre de 2026. La llista inclou bases de dades com MySQL o PostgreSQL i fitxers per SFTP o HTTPS; per a la resta, Google remet a integracions de partners o a la Data Manager API, que per a aquest ús està reservada als comptes d'una llista d'accés. Sigui quina sigui la via, la feina prèvia és la mateixa: un registre de comandes net, amb identificadors coherents amb l'etiqueta, i saber de quin canal ve cada comanda.
Saps si la teva mesura arriba fins a la comanda real?
Abans de connectar cap font nova a Google Ads, val la pena saber on es trenca avui la cadena entre el clic, la cistella i la comanda. Abans de proposar res, revisem el negoci, el web i les dades: així comença la nostra feina d'analítica web i tracking.
No prometem recuperar vendes ni cap xifra. Sí que et podem ajudar a entendre què veu cada plataforma, què diu el teu backend i què convé ordenar primer.
Parlem-ne →
