Conversiones multi-source: por qué tu ecommerce necesita conectar campañas, carrito y pedido real

Abres Google Ads y hay una cifra de ventas. Abres GA4 y hay otra. Meta Ads cuenta unas cuantas más. Y en el panel de la tienda, los pedidos reales no coinciden con ninguna de las tres. No es mala suerte: es lo que pasa cuando toda la medición de un ecommerce depende de etiquetas que se ejecutan en el navegador del cliente.

Google Ads ha publicado documentación específica sobre las conversiones multi-source, todavía en beta, que la prensa especializada recogió el 16 de septiembre de 2026. La idea es que la conversión web que ya mide la etiqueta se pueda complementar con una segunda fuente que sale del backend del negocio, como un CRM o una base de datos de pedidos.

Aquí no repetimos la noticia. Explicamos por qué la fuente más fiable de una venta sigue siendo el pedido real, qué exige Google para que esta segunda fuente sume sin duplicar nada, y cómo lo hemos planteado en un ecommerce en PrestaShop, donde primero hemos ordenado el dato en casa.

La siguiente evolución de la medición no es poner más etiquetas, sino conectar mejor las etiquetas con los pedidos reales del ecommerce.

El problema: GA4 y Google Ads no siempre ven toda la realidad

Cuando alguien compra en tu tienda pasan dos cosas que solemos pensar como si fueran una. En el servidor se crea un pedido con un número, un importe, una moneda y un estado. En el navegador del cliente, la página de confirmación ejecuta un fragmento de código que avisa a GA4, Google Ads y Meta Ads de que ha habido una compra.

El pedido no falla nunca: sin pedido no hay venta. El aviso del navegador depende de cosas que no controlas:

El problema no es estético. Google Ads y Meta Ads deciden dónde va tu dinero a partir de las conversiones que reciben. Si una campaña vende pero la plataforma solo ve una parte, el algoritmo puede retirarle presupuesto. Si cuenta ventas que después se cancelan, puede premiar lo que no te conviene. Lo encontramos a menudo cuando abrimos una cuenta: el sistema contaba como cliente a quien no lo era, y el presupuesto seguía aquella pista falsa.

Qué son las conversiones multi-source de Google Ads

La definición oficial es bastante 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."

En la práctica, la misma acción de conversión de Google Ads recibe dos fuentes: la etiqueta de siempre y el registro de pedidos de tu backend, conectado con Google Ads Data Manager o con la Data Manager API. Google las une con elidentificador de transacción, que en una tienda es el número de pedido. Según la documentación oficial, esto permite:

1. Recuperar conversiones que la etiqueta no captó, si el pedido lleva algún identificador que permita atribuirlo a un clic de anuncio.
2. Actualizar el valor de una conversión existente con rectificaciones, ventas adicionales o importes finales del carrito.
3. Completar datos de usuario que la etiqueta no recogió, como el correo o el teléfono, que Google convierte en un formato irreversible (hash).

Antes de entusiasmarse, los límites. Es una beta y quizá todavía no está disponible para todas las cuentas. Solo funciona con acciones de conversión web configuradas manualmente con código, con la etiqueta de Google o con Google Tag Manager. No sirve para las conversiones importadas de Google Analytics ni para las basadas en una URL. Primer obstáculo para cualquier ecommerce que mide así: si las compras llegan a Google Ads importadas desde GA4, la opción ni siquiera aparece.

Por qué el backend del ecommerce debe ser la fuente fiable

El pedido existe aunque el cliente haya rechazado las cookies, tenga un bloqueador o la página de confirmación no haya cargado. Tiene un identificador único, un importe real, una moneda y, sobre todo, un estado: pagado, enviado, cancelado, devuelto. La etiqueta solo ve el instante de la página de agradecimiento. No sabe nada de lo que pasa después.

Google lo dice sin ambigüedades:

"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 consecuencia fácil de pasar por alto: exportar las compras de GA4 y subirlas como segunda fuente no arregla nada, porque GA4 también depende de etiquetas y tiene los mismos agujeros.

Y un segundo detalle que hace subir el peso de la decisión: cuando el identificador de un pedido coincide con una conversión de la etiqueta, el valor que subes sustituye al de la etiqueta de forma permanente. «Your additional data source becomes the source of truth for conversion value», dice Google. Si el backend está ordenado, es una buena noticia: incluso una devolución total se puede reflejar con un valor 0. Si no lo está, es un problema.

Ahora bien, hay que afinar la idea. El backend es la fuente fiable de qué se ha vendido, pero no de dónde ha venido. Un pedido no sabe, por sí solo, si el cliente llegó desde un anuncio de Google, de una campaña de Meta o escribiendo la dirección. Si nadie guarda esta relación a tiempo, se pierde. Es el vacío que resuelve el caso que explicamos más abajo, y lo que separa una tienda que se puede medir de una que acumula informes que no cuadran.

El error habitual: medir solo con etiquetas

Cuando las cifras no cuadran, la reacción habitual es añadir más etiquetas: un segundo píxel, un conector nuevo, otro evento de compra «por si acaso». Más etiquetas no dan más verdad: dan más versiones de la misma venta, y a menudo ventas contadas dos veces.

Las etiquetas siguen siendo imprescindibles: son rápidas y alimentan la optimización casi en tiempo real. Google recomienda recoger los datos de usuario por las dos vías, porque la conexión con el backend hace de recambio cuando la etiqueta falla. Lo que no funciona es tratarlas como la única fuente. Pasa igual en Meta Ads, donde el Píxel y la Conversions API no son rivales, sino dos vías que hay que deduplicar, y en Google, donde los cambios en cómo se muestran los anuncios rompen supuestos clásicos del tracking.

Arquitectura recomendada: del clic al pedido real

No hay una única manera de construirlo, pero sí un orden lógico que evita la mayoría de errores. Cinco capas, cada una dependiente de la anterior:

Dos precisiones. La primera: saber el canal y tener el identificador del clic no es lo mismo. Para responder «de dónde viene este pedido» basta con el canal. Para enviar una conversión adicional a Google Ads hace falta el identificador que la liga a un clic concreto (GCLID, GBRAID o WBRAID) o datos de usuario con el tratamiento adecuado. Si quieres dejar la puerta abierta a una fase posterior, decídelo desde el principio.

La segunda: todo lo que se guarda en el navegador o se envía a una plataforma debe respetar el consentimiento del usuario. Cómo se aplica en cada tienda hay que revisarlo con quien lleve la privacidad del negocio; este artículo no da consejo legal sobre eso. Sí que recuerda lo que la documentación de Google deja claro: solo los eventos con consentimiento sirven para complementar las conversiones.

Caso práctico anónimo: una integración en un ecommerce PrestaShop

En un proyecto reciente sobre un ecommerce en PrestaShopen Daimatics hemos implementado una capa de atribución interna para asociar el canal de captación con el carrito y, después, con el pedido real. No damos ningún dato que permita identificar el negocio; sí la arquitectura, que es lo que sirve a cualquier otra tienda:

1. Google Tag Manager detecta el canal de entrada del usuario.
2. La lógica identifica las señales de cada origen: gclid, gbraid o wbraid para Google Ads; fbclid o las UTM de Meta para Meta Ads; UTM genéricas; la web de procedencia para el orgánico, y la ausencia de señales para el tráfico directo.
3. El canal se guarda en el navegador para que no se pierda durante la navegación.
4. La tienda expone el identificador del carrito en la capa de datos.
5. Google Tag Manager recoge este identificador.
6. Google Tag Manager envía al backend de la tienda dos datos: el identificador del carrito y el canal.
7. El backend guarda esta relación.
8. Cuando el carrito se convierte en pedido, el canal queda asociado al pedido real.

Qué se ha validado. En preproducción se han validado correctamente tres canales: Google Ads (CPC), Meta Ads y tráfico directo. El orgánico queda contemplado por la lógica de la web de procedencia, pero se podrá validar mejor con tráfico real cuando esté publicado. Una validación en preproducción demuestra que la lógica funciona, no cuántas ventas se le asociarán.

Qué no se ha hecho, y por qué importa. No se ha creado ninguna conversión nueva ni se ha duplicado ninguna compra. La integración no envía ninguna otra compra a GA4 ni a Google Ads. Solo guarda una atribución interna:

Y conviene decirlo claro: no es una implementación de conversiones multi-source, ni una subida de conversiones offline a Google Ads, ni una conexión con Google Ads Data Manager. Y GA4 no queda sustituido. Es el paso previo: ordenar el dato en casa para que cualquier fase posterior tenga una base sólida.

Cómo evitar duplicar conversiones

Si un día se conecta una fuente adicional, el riesgo más caro es contar dos veces la misma venta. Un algoritmo que ve más compras de las que hay no solo infla informes: puede aprender que campañas mediocres son buenas y ponerles más presupuesto. Cinco puntos de la documentación de Google que conviene tener claros:

1. La deduplicación solo pasa dentro de una misma acción de conversión

"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."

Por eso Google recomienda añadir la fuente a la acción de compra que ya existe. Si se crea una nueva, no puede compartir objetivo de campaña con la original. Tampoco aconseja hacer pruebas con una acción duplicada: si hay que comparar, habla de 28 días de calentamiento.

2. El mismo identificador de transacción, exactamente

Google enumera los errores típicos: prefijos («order-12345» frente a «12345»), mayúsculas y minúsculas, «12345» frente a «12345.0», ceros a la izquierda o valores de muestra. El identificador debe ser único, generado por el backend, de 64 caracteres como máximo y sin datos que identifiquen al cliente. Si en dos días coinciden menos del 10% de los identificadores, Google avisa de que las conversiones pueden estar sobrecontadas.

3. Los importes, en las mismas unidades

Si la etiqueta envía euros con decimales y la base de datos guarda céntimos, Google no lo convierte. El ejemplo es suyo: 1000 en céntimos se interpreta como 1.000 dólares. Y como ese valor sobrescribe el de la etiqueta, el error llega a las estrategias de puja por valor. Google lanza una alerta urgente si los dos valores se diferencian más de diez veces en dos días.

4. Los primeros 14 días no cuentan para las pujas; después sí, con alertas o sin ellas

Desde la primera subida, las conversiones nuevas salen en los informes y en los diagnósticos, pero no en las pujas, y las actualizaciones de valor quedan desactivadas. Pasados 14 días entran en las pujas automáticamente, «regardless of any diagnostic alerts». Estos días son para revisar, no para esperar.

5. Una sola fuente

Desde Data Manager solo se puede conectar una fuente adicional por acción de conversión. La API permite más, pero Google lo desaconseja: si los pedidos viven en dos sistemas, se unifican antes.

En el caso de PrestaShop, no crear ninguna conversión nueva no era una limitación: era la manera más segura de no duplicar ninguna mientras el dato se validaba.

Qué datos conviene guardar desde el principio

Si una tienda quiere tener abierta la puerta a una segunda fuente, el trabajo empieza mucho antes de conectar nada:

No todos pesan igual. Identificador y fecha son obligatorios. De identificadores de atribución, Google pide como mínimo uno y recomienda combinar el GCLID con datos de usuario: sin ningún identificador de atribución, la venta existe, pero Google no puede ligarla a un anuncio. El estado final y el canal no los pide Google, pero son los que te dicen a ti si la venta se ha cobrado y qué campaña la trajo.

El consentimiento también es dato. Google permite indicarlo fila a fila y solo usa los eventos con consentimiento. Si una fila no lo lleva, se aplican los valores por defecto de la cuenta, que conviene revisar.

Y la frescura manda sobre el histórico. Google recomienda subir los datos dentro de las 24 horas posteriores a la conversión, y avisa de que subir un año de ventas antiguas no mejora el rendimiento actual: las actualizaciones de valor solo se procesan para conversiones de los últimos 55 días.

Qué papel puede tener Google Ads Data Manager en una fase posterior

Google Ads Data Manager es la herramienta de Google para llevar datos propios de fuera de Google a Google Ads con una interfaz de apuntar y hacer clic. Está en el menú de Herramientas de la cuenta, y es por donde pasa la conexión de una fuente adicional. Hay dos vías:

• Conexión directa, la que Google recomienda cuando está disponible. La lista oficial de fuentes con conexión directa incluye bases de datos como MySQL, PostgreSQL o BigQuery, Google Sheets, archivos por SFTP o HTTPS y plataformas como Shopify, HubSpot o Salesforce. Si una fuente no está, Google remite a integraciones de partners.
• Data Manager API, para envíos automatizados por código. Para conectar fuentes adicionales, la documentación la reserva a las cuentas de una lista de acceso.

¿Por qué «fase posterior»? Porque conectar es el último paso. Antes hay que responder que sí a cuatro preguntas:

1. ¿La compra se mide en Google Ads con una acción de conversión web configurada con código, y no importada de GA4?
2. ¿La etiqueta de compra ya envía un identificador de transacción único y dinámico?
3. ¿El backend guarda ese mismo identificador, el importe en las mismas unidades, la moneda, la fecha y el estado?
4. ¿Hay identificadores de atribución y consentimiento registrados para cada pedido?

Si alguna respuesta es no, conectar ahora significa importar el desorden. Si todas son sí, tiene sentido, y los 14 días de prueba sirven para leer los diagnósticos antes de que el dato entre en las pujas. Primero el dato, después la plataforma: el mismo orden que defendemos cuando hablamos de gestionar campañas de Google Ads.

Conclusión: medir mejor antes de optimizar más

Las campañas no pueden optimizar bien si las plataformas no reciben, o no interpretan correctamente, las ventas reales. Esta beta apunta en una dirección clara: con la etiqueta sola no basta, y para el valor, la referencia pasa a ser el pedido del backend. Cuantas más decisiones se delegan en sistemas automáticos, más pesa la calidad del dato que se les da.

Una arquitectura que liga canal, carrito y pedido va más allá de Google Ads. Es la base que permite alimentar una capa interna de inteligencia de negocio capaz de cruzar pedidos reales, canales detectados, GA4, Google Ads y Meta Ads, teniendo en cuenta el estado de cada pedido, el valor real y las devoluciones o cancelaciones. El objetivo no es un informe más: es detectar las discrepancias entre lo que el ecommerce vende realmente y lo que las plataformas publicitarias o analíticas consiguen medir.

Es el tipo de dato ordenado que necesita cualquier sistema de análisis, también Daimatics OS, el ecosistema tecnológico propio que da soporte al modelo de trabajo de Daimatics: centraliza y relaciona datos, evidencias, analítica, conocimiento y procesos de diferentes disciplinas para ampliar la capacidad de análisis, priorización, ejecución y mejora continua de la agencia. No es una IA que lo hace todo. Y sin dato ordenado, ningún análisis puede comparar nada.

La ventaja competitiva no es solo invertir más en campañas, sino construir una medición que conecte la captación con el pedido real. Primero medir mejor. Después, optimizar más.