Click-to-WhatsApp con atribución al clic de Google Ads y Meta

Por qué WhatsApp rompe Google Ads y Meta Ads

Piensa en el viaje típico. El usuario ve un anuncio en Google o Instagram, pulsa, aterriza en la landing, lee un rato, pulsa el botón de WhatsApp, se abre la app. En ese momento, para el píxel y para Google Ads el rastro se corta. Lo que pasa después (si el usuario escribe, si el comercial responde, si hay ida y vuelta, si a los tres días se cierra una venta de 1.200 €) ocurre dentro de una app externa. Google y Meta no lo ven.

El único dato que queda registrado es "el usuario pulsó el botón". Ese dato, por sí solo, es basura estadística. No te dice si el lead era bueno o malo, si el comercial cerró o no, si el cliente valía 60 € al mes o 600. Smart Bidding, que solo puede aprender de las señales que le das, aprende lo único que tiene: a generar más clics en el botón de WhatsApp. No a generar ventas. Por eso en tantas cuentas los clics en WA suben mes a mes y la facturación se queda plana.

La consecuencia comercial es clara: estás pagando CPMs cada vez más altos por un comportamiento (pulsar un botón) que no correlaciona con ingresos. Si tu embudo real se cierra en WhatsApp, tu cuenta necesita una capa nueva que rescate la señal de venta y se la devuelva a los canales. Eso es lo que resuelve Click-to-WhatsApp con atribución.

Las dos arquitecturas posibles

Hay dos caminos para resolver este problema. Ambos llegan al mismo sitio (atribuir la venta al clic original), pero la mecánica y los casos de uso son distintos.

Arquitectura	Cuándo usarla	Ventaja principal
Meta CTWA nativo	Anuncios Meta (Facebook/Instagram) que van directamente a WhatsApp sin pasar por landing	Meta ya te da el wa_ref; solo hay que capturarlo y subir la conversión
Click interceptor en landing	Cualquier fuente (Google Ads, Meta Ads, TikTok, SEO, directo) que pasa por una landing con botón de WhatsApp	Funciona con todos los canales, no solo Meta. Más flexible.

En la mayoría de cuentas usamos las dos: Meta CTWA para campañas Meta que apuntan directo a WhatsApp, y click interceptor para todo lo demás. Son arquitecturas complementarias, no excluyentes.

Arquitectura A: Meta CTWA nativo

Meta lanzó Click-to-WhatsApp Ads (CTWA) como formato publicitario en 2024. Son anuncios de Facebook o Instagram cuyo CTA abre directamente WhatsApp sin pasar por una landing intermedia. Meta genera un identificador único por conversación (wa_ref) que vincula el mensaje con el anuncio que lo originó.

La parte buena: Meta hace la mitad del trabajo. En el payload que llega a tu webhook del WhatsApp, el wa_ref viene incluido. No tienes que inyectar nada en el texto del mensaje ni interceptar nada en el browser. La parte menos buena: solo aplica a campañas Meta específicamente configuradas como CTWA, y no cubre tráfico que venga de Google Ads, de SEO, de referrals o de otras fuentes.

Conceptualmente el flujo es: el webhook recibe el mensaje entrante con el wa_ref, lo cruzas con tu backend para recuperar el contexto de la campaña, y cuando el CRM marca la venta subes un evento Purchase a Meta CAPI con el valor real. Sin esto, Meta solo cuenta MessagingConversationStarted como conversión, que es tan poco útil como un clic en el botón.

Lo que no es trivial de CTWA: el matching fiable entre la conversación y el perfil del usuario de Meta (para poder atribuir futuros mensajes del mismo usuario sin perder el contexto), el manejo de deduplicación cuando una misma persona escribe dos veces al número, y la configuración correcta del Event Manager para que el Purchase subido vía CAPI se atribuya a la campaña y no se cuente dos veces. Cada una de estas piezas tiene matiz.

Arquitectura B: click interceptor en landing propia

Esta es la arquitectura que usamos cuando el tráfico puede venir de cualquier canal (Google Ads, Meta, TikTok, SEO, directo) y pasa por una landing antes de llegar a WhatsApp. Es más universal, pero requiere más trabajo en el frontend.

El principio es sencillo de enunciar y menos sencillo de ejecutar. Cuando el usuario pulsa el botón de WhatsApp en la landing, un script intercepta el clic antes de que se abra la app. En ese momento:

1. Genera un código de referencia único, típicamente basado en timestamp. Algo como [Ref: 1740412345].
2. Envía al backend la asociación entre ese código y el GCLID, FBCLID o UTMs que ya había capturado previamente en localStorage. Un pre-lead, sin datos del usuario todavía.
3. Inyecta el código dentro del mensaje pre-rellenado que WhatsApp abrirá. Algo como "Hola, quiero información [Ref: 1740412345]".
4. Abre WhatsApp con el mensaje ya listo.

Cuando el usuario envía el mensaje, llega al proveedor de WhatsApp del cliente (Cloud API de Meta, Wazzup, Cliengo, 360dialog, Twilio) que lo reenvía a tu webhook. El webhook extrae el código [Ref: XXXX] con un regex, lo cruza con la tabla de pre-leads, y completa el lead con el GCLID original. La conversación queda atribuida al clic.

Contado así suena a tutorial de YouTube. En la práctica, cada uno de esos cuatro pasos tiene trampas. Safari iOS es especialmente delicado: window.open se bloquea si no se llama de forma síncrona al clic, y al interponer una llamada fetch intermedia se pierde el bloque. Hay que usar navigator.sendBeacon y abrir la URL en el mismo tick del event loop. Si el sitio ya tenía un script de terceros (Aranet, Hubsell, herramientas similares) interceptando ese mismo clic, hay que coordinar prioridades para que no se peguen. Y el usuario puede, a veces, borrar el [Ref:] antes de enviar el mensaje, y eso no tiene solución técnica al 100 %.

El matching del mensaje entrante

Con la pieza de la landing resuelta, toca el otro extremo del flujo: cuando el mensaje llega al número de empresa. Este tramo depende del proveedor de WhatsApp que tengas. Trabajamos habitualmente con cinco, y la capa de atribución es la misma para todos; lo que cambia es el formato del webhook y el tipo de autenticación:

Proveedor	Dónde encaja	Peculiaridad principal
WhatsApp Cloud API (Meta)	Gratis, oficial, escalable	Requiere Business Manager verificado y gestión técnica del rate limiting
Wazzup	Integración rápida con Bitrix, Pipedrive, amoCRM	Whitelist de canales para evitar procesar mensajes de números outbound
Cliengo	Chatbot WhatsApp preconfigurado	Si el número ya está en su base, no re-envía el webhook (cuidado con tests repetidos)
360dialog	Partner BSP oficial para Europa	API muy cercana a la Cloud API de Meta, pocos extras
Twilio	Si ya usas Twilio para SMS o voz	Precio por conversación, orientado a enterprise

Independientemente del proveedor, el webhook hace lo mismo conceptualmente: recibe el mensaje, extrae el código de referencia, busca en la tabla de pre-leads, completa la ficha con el GCLID y marca el lead como "matched". Donde cambia cada proveedor es en el formato del payload, las excepciones (mensajes de prueba, eventos de status, echo de mensajes salientes) y en los rate limits.

Un punto que parece menor y que tarda semanas de producción en pulirse: la deduplicación. Un mismo usuario puede mandar varios mensajes seguidos. Cada mensaje dispara el webhook. Si no tienes buena deduplicación, generas varios pre-leads y el matching se ensucia. En las implementaciones nuestras en producción, este es el tipo de bug que aparece en la semana 3-4 y no antes.

La subida a paid media

Una vez la conversación está atribuida al clic original, cierras el loop cuando el CRM marca la venta. Ahí disparas la conversión de vuelta a los canales publicitarios con el valor real de la venta (no con un valor simbólico de lead). El cómo funciona ese tramo lo contamos entero en la guía de conversiones offline a Google Ads. Meta tiene su propio CAPI (Conversions API) con una lógica similar: envías un evento Purchase con event_id para deduplicación, fbclid o Enhanced Conversions como identificadores, y valor real.

La diferencia clave al llegar aquí: Smart Bidding ya no está aprendiendo de "clics en WhatsApp", está aprendiendo de "ventas reales de 300, 600 u 1.200 €". Y optimiza en consecuencia. Es el momento en el que el CPA real baja (aunque el CPL del canal suba un rato, que es algo que también explicamos en esa guía).

Los 4 problemas que vemos en cada implementación

Esta arquitectura se ve limpia en una diapositiva. En producción, estos son los cuatro sitios donde sistemáticamente hay fricción:

Problema	Causa típica
Mensajes entrantes sin código [Ref:]	El usuario lo borra porque le parece raro, o el proveedor ya tenía otro interceptor que lo sobreescribe, o el navegador cortó el texto prefill por longitud.
Doble inyección de código	Coexisten dos scripts de terceros interceptando el mismo botón. El mensaje llega con dos referencias y el regex hace match con la equivocada.
Leads de Wazzup/Cliengo que entran sin atribución	Proveedor configurado con varios canales activos (soporte, marketing, outbound) y el webhook procesa todos. Hay que aplicar whitelist de channelId.
Duplicados en el CRM	El mismo mensaje llega dos veces (retry del proveedor, network glitch) y crea dos leads. Falta idempotencia en el webhook.

Cada uno de estos tiene arreglo, pero ninguno es obvio la primera vez que te lo encuentras. En general se detectan cuando el volumen ya es alto y el ruido es medible (por ejemplo, detectar que hay un 12 % de leads de WhatsApp sin GCLID requiere tener al menos 500 leads/mes por WhatsApp para que el dato sea significativo). Implementaciones en fase piloto casi nunca los ven; aparecen en producción real.

Casos de uso reales

Sin nombrar clientes específicos, los verticales donde hemos visto más diferencia al implementar esta arquitectura:

Operadora ISP (fibra residencial)

Entre el 60 y el 70 % de las ventas se cierran por WhatsApp. Antes: Smart Bidding optimizaba por clics en botón WA y el CPL se veía en 18 €. El CPA real (con las ventas que cerraba el call center) era de 420 €. Después: subiendo conversión offline con el ticket real, Smart Bidding pasa a optimizar por ventas. CPL sube a 24 € durante 3 semanas de reaprendizaje, después CPA real baja a 260 € y se estabiliza. Mismo presupuesto, 38 % más de ventas.

Clínica dental (implantes + ortodoncia)

WhatsApp usado para pedir información antes de reservar primera visita. El 40 % de las consultas iniciales acaba en presupuesto presentado. Antes: Meta Ads optimizaba por inicio de conversación. Después: Meta optimiza por presupuesto presentado, con valor medio enlazado al tipo de tratamiento. ROAS atribuido pasa de 2.3x a 4.1x en 60 días.

Seguros de salud

Flujo combinado: formulario inicial y luego contacto por WhatsApp para cualificación. La atribución del formulario ya estaba montada; la parte de WhatsApp era ciega. Al cerrar el loop, campañas que antes se pausaban por CPL alto resultaron ser las que mejor ROAS tenían. La decisión de pausar o escalar campañas cambió completamente.

B2B con ciclo corto (formación profesional online)

Caso menos típico. Ciclo de cierre de 48-72h, principalmente por WhatsApp tras form inicial. La mayor mejora no fue en CPA sino en asignación entre LinkedIn y Meta Ads: descubrimos que Meta generaba leads que cerraban mejor en WhatsApp, aunque LinkedIn tenía mejor CPL aparente. Reasignación de presupuesto sin cambiar volumen total.

Preguntas frecuentes

¿Qué es Click-to-WhatsApp con atribución?

La técnica de vincular cada conversación de WhatsApp iniciada desde un anuncio con el clic original, de modo que la venta se atribuya al canal, campaña y keyword específica. En vez de "clics en WhatsApp", mides "ventas atribuidas a la campaña X".

¿Funciona con Meta Click-to-WhatsApp Ads?

Sí. Meta CTWA da un wa_ref por conversación que se captura del payload y se vincula al evento Purchase en Meta CAPI.

¿Qué proveedores de WhatsApp soportan esto?

Cualquiera que exponga webhook de mensajes entrantes. Trabajamos habitualmente con Cloud API de Meta, Wazzup, Cliengo, 360dialog y Twilio. La capa de atribución es la misma; cambia el formato del webhook.

¿Puedo medir conversaciones salientes?

Las iniciadas por el agente no llevan atribución publicitaria porque no hay clic previo. Sí puedes medir la respuesta del usuario a una campaña saliente y vincularla a la lista de envío. Es atribución a lista, no a clic.

¿Qué pasa si el usuario borra el código [Ref:] del mensaje?

Pierdes la atribución de ese mensaje específico. Estrategias para minimizarlo: inyectar el código al final del texto para que pase desapercibido, usar CTWA de Meta donde el identificador viaja en el payload y no en el texto, y educar al agente para copiar manualmente el código si detecta que falta. Tasas típicas de pérdida del 5-15 % en cuentas en producción.

¿Es esto lo mismo que WhatsApp Business Platform API?

No exactamente. WhatsApp Business Platform es la API oficial de Meta para enviar y recibir mensajes. Click-to-WhatsApp con atribución es una capa encima: usa la API (o la de un BSP como Wazzup o 360dialog) para recibir mensajes, y añade la lógica de atribución al anuncio original. Puedes tener la API sin la atribución; no al revés.

Sigue leyendo