Subida de conversiones offline a Google Ads: guía técnica 2026

Por qué importa subir ventas, no leads

Si tu cuenta de Google Ads no sube conversiones offline, Smart Bidding solo ve una señal: formulario rellenado. Eso basta mientras todos tus leads valgan lo mismo, pero en cualquier negocio real no valen lo mismo. Un lead que acaba contratando fibra de 60 €/mes no vale lo que uno que solo consulta precios. Si no se lo cuentas a Google, el algoritmo optimiza por volumen de leads, no por volumen de ventas. Y eso es lo que, a final de mes, te come el margen.

Lo vemos todas las semanas cuando auditamos cuentas. Una campaña con CPL de 20 € parece barata. La misma campaña, cruzada contra el CRM del cliente, convierte un 2 % en venta real. CPA efectivo: 1.000 €. Otra campaña tiene CPL de 50 € (el pm recién llegado la quería pausar) pero convierte un 15 %. CPA efectivo: 333 €. Google no distingue una de otra hasta que alguien le da la señal de venta. Y el 80 % de las cuentas medianas que vemos nunca se la da.

GCLID, auto-tagging y conversiones offline

Antes de meternos en harina, tres cosas que conviene tener claras.

1. El GCLID es la llave maestra

Cuando alguien pulsa un anuncio de Google Ads, Google añade un parámetro ?gclid=Cj0KCQ... al final de la URL de destino. Ese string es un identificador único del clic. Google (y solo Google) sabe a qué campaña, grupo de anuncios, keyword, hora y dispositivo corresponde. Si tu servidor se queda con ese GCLID y lo vincula a una venta que ocurre semanas después, Google puede re-atribuir la venta al clic original sin que tú le digas absolutamente nada sobre el usuario.

El GCLID es, en la práctica, la privacy-safe version del user identifier. No te hace falta CRM conectado a Google, ni Audiences, ni Google Signals. Solo hay que capturarlo y no perderlo. Más fácil dicho que hecho, como ahora veremos.

2. Hay dos caminos para devolverle la venta a Google

Google ofrece dos mecanismos: Conversion Upload API (para integraciones en tiempo real, push por cada venta) y Data Manager vía feed CSV programado en una URL HTTPS (para subidas batch cada 1-6 horas). Ambos llegan al mismo endpoint interno y producen exactamente el mismo resultado en los reportes de Google Ads. La diferencia está en la complejidad de operación.

Cuál usar depende de cómo esté montado tu stack (si tienes backend propio o no), cuántas ventas al día mueves, y si quieres controlar el timing de la subida al minuto o te vale "hoy antes del cierre". En las cuentas que gestionamos acabamos usando casi siempre Data Manager con feed CSV, porque simplifica la operación y evita depender de que Python no se caiga. Pero hay casos donde la API tiene sentido, sobre todo cuando el propio CRM es el que dispara la subida.

3. La ventana de atribución es de 90 días

Google acepta conversiones cuyo GCLID tenga menos de 90 días desde el clic original. Si un lead tarda cuatro meses en cerrar la venta, la conversión se rechaza con CLICK_TOO_OLD. En negocios con ciclos de venta largos (seguros, inmobiliaria, B2B) esto obliga a subir también estados intermedios (lead cualificado, visita programada, reunión confirmada) con un valor parcial, para que Smart Bidding tenga señal dentro de ventana. No es trivial definir qué estados subir y con qué valor cada uno. De eso depende buena parte del éxito.

Dónde se captura (y dónde se pierde) el GCLID

El primer eslabón es el más frágil. Si el GCLID no se captura bien, lo demás da igual. La idea básica es leer el parámetro de la URL y persistirlo (normalmente en localStorage) para que sobreviva a recargas, navegación interna y al momento en que el usuario por fin decide rellenar el formulario o pulsar el botón de WhatsApp, que puede ser 3 clics después de aterrizar.

Este es el snippet base que recomendamos colocar en Google Tag Manager (Custom HTML Tag, trigger All Pages, prioridad alta para que se ejecute antes que otros scripts):

<script>
(function(){
  try {
    var params = new URLSearchParams(window.location.search);
    var keys = ['gclid', 'fbclid', 'ttclid', 'msclkid',
                'utm_source', 'utm_medium', 'utm_campaign',
                'utm_content', 'utm_term'];
    keys.forEach(function(k){
      var v = params.get(k);
      if (v) localStorage.setItem('wt_' + k, v);
    });
  } catch(e) { /* silent fail */ }
})();
</script>

Eso es lo fácil. Lo que no es tan obvio en el snippet anterior es todo lo que NO cubre. Algunos ejemplos reales que hemos encontrado en auditorías en los últimos meses:

• Safari (ITP). Borra localStorage tras 7 días de inactividad del usuario. En negocios B2B con ciclos de 30+ días, pierdes el GCLID casi siempre. Solución: enviar al servidor cuanto antes.
• Incógnito. Persistencia cero. Si el visitante navega en incógnito, tienes una única ventana para capturar la intención.
• Landing con redirects. Si tu URL final pasa por un redirect de afiliados o cloaking, el query string se pierde por el camino a no ser que lo preserves explícitamente.
• Iframes embebidos. Algunos CMSs cargan los forms en iframe cross-origin. localStorage del iframe es distinto al del top. Se necesita postMessage o trick similar.
• Multi-tab. El usuario abre dos pestañas, rellena el form en la segunda (que entró sin GCLID). Hay que propagar entre tabs con storage events.

En producción, el snippet que acabamos usando tiene entre 40 y 80 líneas para cubrir estos casos. Es de esas cosas que se ven triviales en el blog y complicadas cuando en una auditoría descubres que el 60 % de tus GCLIDs se están perdiendo en Safari.

El salto al CRM, donde casi todo se rompe

Aquí es donde suelen explotar las cuentas. Tienes el GCLID en localStorage, perfecto. Ahora necesitas que viaje con el lead desde la landing hasta la ficha de contacto en tu CRM, sin que se pierda por el camino. Y los caminos son muchos.

Formulario web tradicional

El patrón estándar es añadir un input type="hidden" al formulario y rellenarlo desde localStorage antes del submit. Cinco líneas de código. Funciona en el 95 % de los casos, salvo cuando el submit es async y el input se lee antes de que localStorage esté listo, o cuando el CRM no acepta campos custom en la request, o cuando una validación JS borra el input, o cuando... ya se entiende el patrón.

Clic en botón de WhatsApp

Este es el caso que más ha crecido en los últimos 18 meses, sobre todo en verticales como telecom, salud y servicios profesionales en LATAM, donde el 60-70 % de las ventas se cierran por WhatsApp. El reto es conceptualmente interesante: el usuario pulsa un enlace que abre WhatsApp (una app externa), escribe un mensaje, y el mensaje llega a un número de empresa. ¿Cómo vincular ese mensaje entrante al clic original de Google Ads?

La respuesta corta: interceptas el clic antes de que se abra WhatsApp, generas un código de referencia único tipo [Ref: 1740412345], lo inyectas en el mensaje pre-rellenado, envías al backend la asociación ref_id → gclid, y cuando tu webhook de WhatsApp recibe el mensaje entrante, extrae el [Ref:] con un regex y cierra el loop.

La respuesta larga tiene capa tras capa de sutilezas. ¿Y si el usuario borra el [Ref:] porque le parece raro? ¿Y si el botón de WhatsApp es un componente de terceros (Aranet, Hubsell) que ya intercepta el clic con su propio handler? ¿Y si el proveedor de WhatsApp (Wazzup, Cliengo, Cloud API de Meta, 360dialog, Twilio) usa un payload distinto? ¿Qué pasa en Safari iOS donde el window.open se bloquea si no es síncrono al clic? ¿Cómo deduplicas cuando el usuario manda dos mensajes seguidos? Cada una de esas preguntas es un bug en producción esperando a pasar. En WinTracker tenemos todas esas respuestas ya compiladas en un script de GTM reusable, pero no es una cosa que montes en una tarde.

Formularios de terceros (Typeform, Calendly, Bitrix24)

Cada uno tiene su propio mecanismo para pasar parámetros a través. Typeform usa hidden fields declarados en el editor; Calendly permite ?utm_* pero corta otros parámetros; Bitrix24 a veces acepta campos custom, a veces no. Cada uno es un trabajo de integración distinto.

CRMs grandes (HubSpot, Salesforce, Pipedrive)

Los CRMs modernos aceptan un campo custom en la ficha de contacto. En HubSpot lo llamamos hs_google_click_id; en Salesforce, GCLID__c; en Pipedrive, un custom field del tipo texto. La configuración en sí es trivial, pero hay que vigilar que el permiso de escritura del API user lo incluya, y que los workflows de deduplicación no pisen el campo cuando re-crean un contacto existente.

La acción de conversión en Google Ads

Antes de subir nada, tienes que tener una acción de conversión preparada para recibir los datos. En Google Ads → Herramientas → Conversiones → + Nueva acción:

1. Elige Importar como fuente.
2. Luego Otras fuentes de datos y Clics (no Leads ni Call).
3. Nombre de la acción: algo limpio tipo VENTA_CRM o LEAD_CUALIFICADO.
4. Categoría: Compra si es venta, Lead si es cualificación.
5. Valor: Usar valores diferentes para cada conversión. Esto es crítico: sin esto, Smart Bidding no puede aprender por valor.
6. Cuenta: 1 (el lead puede aparecer varias veces pero solo cuenta una venta por GCLID).
7. Ventana: 90 días (el máximo). Reducirlo no tiene sentido.
8. Incluir en "Conversiones" = Sí si es la conversión principal para Smart Bidding.

Subir la venta: los dos caminos posibles

Aquí es donde la teoría termina y la operación empieza. Tus ventas están en el CRM; la acción de conversión está creada en Google Ads; toca conectar los dos extremos.

Opción A: Conversion Upload API (tiempo real)

Llamas a la Conversion Upload API cada vez que un lead pasa a estado "venta" en tu CRM. Requiere developer token de Google Ads API, OAuth configurado, y un backend que dispare la llamada desde el webhook o el trigger de cambio de estado del CRM.

Esta ruta es limpia cuando la operación ya tiene una capa de backend propia. En la práctica surgen preguntas operativas que tardan semanas de debug en producción: cómo gestionar reintentos cuando la API devuelve errores parciales, cómo evitar subir la misma venta dos veces si el CRM cambia de estado un par de veces, qué hacer cuando el usuario rehúsa la venta a los dos días, cómo tratar las conversiones rechazadas por CLICK_TOO_OLD para aprender a subir antes. Todo resoluble, pero cada respuesta añade una capa al código.

Opción B: Data Manager con feed CSV (batch, cada N horas)

En lugar de hacer push, dejas que Google haga pull a una URL HTTPS tuya que devuelve un CSV con todas las ventas pendientes de subir. Se configura en Google Ads → Administrador de datos → Nueva conexión → URL HTTPS, con credenciales y frecuencia (cada 1h como máximo).

Es el camino que elegimos en la mayoría de cuentas cuando podemos. Simplifica la operación, no requiere mantener un servicio Python corriendo, y permite regenerar el feed desde cero si algo se tuerce. El formato del CSV es muy específico (7 columnas exactas, sin BOM, encoding estricto) y tiene tres o cuatro sutilezas que no aparecen en la documentación pero que hacen que Google rechace el 95 % de las filas si están mal. La primera vez que lo monta alguien sin experiencia, típicamente tarda dos o tres iteraciones hasta que importa limpio.

Migrar Smart Bidding a valor de venta

Tener las conversiones subidas no hace nada por sí solo. Hay que decirle a Google que las use como objetivo de optimización. Dos pasos:

1. En la acción de conversión (la que creaste antes), confirma que Incluir en "Conversiones" está activado y que Valor usa "valores diferentes".
2. En la campaña, cambia la estrategia de puja de Maximizar conversiones a Maximizar el valor de las conversiones. Si quieres añadir suelo de rentabilidad, activa tROAS; si no, deja a Google aprender 3-4 semanas y luego ajusta.

El reaprendizaje tarda entre 2 y 3 semanas. Durante esa ventana el CPL típicamente sube un 10-20 % mientras Smart Bidding busca leads de mayor valor, y es normal. Lo que importa es el CPA real al final del embudo, que suele bajar entre un 25 y un 40 % una vez estabilizado. La parte difícil de esta transición no es técnica, es comercial: convencer al responsable de marketing de que el CPL subiendo durante tres semanas no es un problema, es el camino. En las cuentas donde lo hemos hecho, tener un cuadro de mando con CPA real (no CPL) en tiempo real ayuda muchísimo a mantener los nervios.

Los 5 errores que vemos en cada auditoría

Una vez montado el pipeline, lo que vemos una y otra vez cuando auditamos cuentas que ya suben conversiones offline pero con problemas:

Síntoma	Qué lo causa
CLICK_TOO_OLD (muchos)	Se suben las ventas demasiado tarde o el ciclo de venta supera los 90 días sin subir estados intermedios.
UNPARSEABLE_GCLID	GCLID truncado o con encoding dañado al viajar por CRM / proxys. Faltan validaciones antes de enviar.
"Timestamp precedes click"	Offset horario mal aplicado. El servidor guarda UTC pero se sube como si fuera hora local.
0 conversiones importadas, 100 % errores	GCLID duplicado en el feed con la misma Conversion Name. Típico cuando un mismo lead recibe varias actualizaciones de estado.
Varias acciones muestran el mismo número	Un único feed CSV sirviendo varias acciones. Data Manager ignora la columna "Conversion Name" y asigna todas las filas a la acción vinculada al schedule.

Cada uno de estos errores nos ha pasado en producción y tiene su solución específica. Algunas son de código, otras de configuración en Google Ads, otras de arquitectura del feed. El hilo común: ninguno salta el primer día; aparecen cuando el volumen crece o cuando se cambia algo (un nuevo canal, una nueva campaña, una actualización de Google Ads API).

Enhanced Conversions for Leads: el salvavidas

Hasta aquí, el flujo depende 100 % del GCLID. Cuando el GCLID se pierde (cookies bloqueadas, usuario que cambia de navegador entre el clic y la venta, ITP agresivo en Safari, incógnito), la conversión no se atribuye aunque el cliente sí haya comprado.

Enhanced Conversions for Leads es el mecanismo de Google para rescatar esos casos. En lugar de identificar al usuario por GCLID, le mandas el email o el teléfono hasheado con SHA-256 y Google hace el match contra el usuario de Google que hizo el clic original. No recupera el 100 %, pero sí un 10-30 % adicional de ventas que de otra forma se perdían. Es, básicamente, un seguro a todo riesgo sobre tu atribución.

Montarlo técnicamente es añadir una o dos columnas al payload de subida (Hashed Email, Hashed Phone Number), con normalización estándar (lowercase trim en email, formato E.164 en teléfono). Lo delicado es el cumplimiento: Google requiere que el consentimiento del usuario cubra el uso de sus datos para matching publicitario. En España y LATAM es lo que marca la AEPD / la LGPD brasileña / el equivalente local. En la práctica significa ajustar el texto del checkbox de consentimiento y tener la política de privacidad al día.

Preguntas frecuentes

¿Cuánto tarda Google Ads en procesar una conversión offline?

Entre 6 y 48 horas. Se atribuye a la fecha del clic original, no a la fecha en que la subes. Si subes hoy una venta cuyo clic fue hace 20 días, la conversión aparece retroactivamente en el reporting de hace 20 días (no en el de hoy). Esto despista a veces cuando se revisan informes.

¿Qué diferencia hay entre Conversion Upload API y Data Manager?

La API es integración en tiempo real; Data Manager es polling programado a un CSV. Ambos producen el mismo resultado final. Si ya tienes backend y quieres cada venta arriba en segundos, API. Si prefieres simplicidad operativa, Data Manager cada 1-6 horas suele ser suficiente.

¿Cuál es el límite de días para subir una conversión?

90 días desde el clic. Si lo pasas, Google rechaza con CLICK_TOO_OLD. Por eso conviene tener cron diario y no acumular ventas sin subir.

¿Necesito Enhanced Conversions for Leads si ya tengo GCLID?

No es obligatorio, pero sí recomendable. Cubre entre un 10 y un 30 % más de ventas que el GCLID solo no atribuye. El trabajo extra es mínimo si ya tienes el pipeline montado.

¿Subir conversiones offline rompe el aprendizaje de Smart Bidding?

Al contrario, lo mejora. Lo que sí requiere reaprendizaje es cambiar la estrategia de puja (de Maximizar Conversiones a Maximizar Valor de Conversiones): 2-3 semanas en las que Google re-explora. Durante ese tiempo, el CPL puede subir un 10-20 % mientras el algoritmo busca leads de mayor valor.

¿Hace falta mantener este pipeline cuando ya funciona?

Sí. Google Ads cambia la API cada 3-6 meses (v15, v16, v17... y van ya más de 20 versiones). Cada cambio puede romper el pipeline silenciosamente. Un feed que hoy importa 99 % puede mañana importar 0 % si no actualizas. En las cuentas que gestionamos, revisamos los logs de subida semanalmente y ajustamos lo que hace falta.

Sigue leyendo