La conversación empezó por una queja menor: el administrador de eventos insistía en que faltaban «datos de precio válidos». Esa advertencia resultó ser la punta de un problema de medición que llevaba años funcionando mal sin que nadie lo notara.
El contexto: una empresa de software agroindustrial con 30 años en el mercado y más de 2.600 usuarios, que recibe alrededor de 800 registros al mes desde anuncios pagados hacia su CRM. Vende a haciendas, centros de acopio y agroindustrias; nadie compra en línea. Cada venta se cierra por llamada, demostración y visita.
Nos pidieron revisar por qué las recomendaciones de la plataforma no servían. Terminamos reconstruyendo la medición completa.
Parte 1
Lo que encontramos al abrir la caja
Lo primero fue medir en vivo, no asumir: el pixel cargado en el sitio real, el contenedor de etiquetas, los formularios y la atribución que guardaba el CRM en cada contacto.
El pixel no tenía ningún evento de conversión propio.
El contenedor de etiquetas tenía un solo tag: una vista de página. No existía ninguna etiqueta de conversión. Ni una.
Entonces, ¿de dónde salían las conversiones que la plataforma reportaba? Las fabricaba su configuración automática, que detecta clics y los interpreta como conversiones. Por eso ninguna podía llevar valor ni divisa: son eventos sintéticos, inferidos desde el navegador. La advertencia sobre «datos de precio» no era un fallo de configuración — era la consecuencia lógica de que nadie estuviera declarando nada.
El formulario vivía dentro de un iframe de otro dominio.
Los formularios del sitio estaban embebidos desde el CRM, en un dominio distinto. Eso significa que el pixel del sitio no puede leer nada de lo que ocurre dentro, y que el formulario no tiene forma de saber de qué anuncio venía la persona.
La atribución se estaba perdiendo justo en el punto donde más importa: el momento del registro.
Y el que casi cambia el proyecto: el sitio no captaba.
Antes de arreglar nada, medimos de dónde venían los registros de verdad. De los últimos cien envíos de formulario, noventa y nueve eran formularios instantáneos de la plataforma publicitaria. Los siete formularios embebidos en el sitio web habían recibido un envío en total, en varios meses.
Es decir: todo el trabajo de medir el formulario del sitio —que era lo que nos habían pedido— movía aproximadamente un lead al mes.
El hueco real no era de volumen. Era de calidad: la plataforma sabía cuántos leads entregaba, pero no tenía forma de saber cuáles servían.
Ese cambio de diagnóstico es lo que hizo valioso el proyecto. La plataforma optimiza hacia lo que se le enseña. Si solo se le enseña «entró un registro», va a buscar más registros — incluidos los que nunca van a comprar. Nadie le estaba enseñando qué pasaba después.
Parte 2
Lo que construimos
La pieza central fue mover la medición del navegador al servidor, y enseñarle a la plataforma los hitos comerciales reales en lugar del registro inicial.
Arquitectura resultante
↑ De vuelta a la plataforma por API de servidor: Lead calificado · Demo agendada · Demo realizada
Servidor a servidor, no navegador
El evento ya no lo dispara el navegador de la persona: lo envía el sistema cuando el hito ocurre de verdad. Un lead pasa a «calificado» cuando alguien lo llamó y confirmó tamaño, cargo e interés — no cuando hizo clic en un botón.
Deduplicación por identificador de evento
El riesgo obvio de enviar desde dos sitios es contar dos veces lo mismo. Se resuelve con un filtro estricto: solo se envía el registro que trae un event_id, un campo que únicamente inyecta el script propio de la web. Un registro que entra por formulario instantáneo nunca lo lleva, así que nunca se duplica.
Un efecto lateral que nos gustó: mientras no existan esos campos, el sistema no envía nada. El arranque queda controlado por construcción, no por disciplina.
Sin datos personales y sin cifras inventadas
Los hitos viajan enlazados por el identificador del lead, con el origen marcado como evento generado por sistema — la vía prevista para eventos de CRM sobre anuncios de clientes potenciales. No viaja ningún dato personal.
Y se tomó una decisión que recomendamos siempre: enviar divisa sin valor. Mientras no se pueda sustentar cuánto vale un lead calificado con datos de cierre reales, poner un número inventado contamina el modelo y las decisiones que se tomen con él.
Parte 3
Lo que apareció al cruzar las tres fuentes
Con la medición en su sitio, hicimos el ejercicio que casi nadie hace: comparar lo que dice la plataforma publicitaria, lo que hay en el CRM y lo que el equipo trabajó de verdad. Sobre unos 1.150 envíos de formulario de noventa días.
| Lo que encontramos | Por qué pasaba |
|---|---|
| 13 % eran reingresos | Personas cuyo teléfono ya existía en el CRM. El sistema no crea un contacto nuevo, así que desde la plataforma parecen registros nuevos y desde el CRM no aparecen. Nadie los estaba contando como lo que son. |
| 9 % nunca llegó | Envíos registrados en la plataforma sin ningún rastro en el CRM. Uno de cada once leads pagados se perdía en el camino sin que nadie lo supiera. |
| El informe duplicaba resultados | Sumaba tres eventos que se solapan entre sí: el genérico de cliente potencial ya incluye a los otros dos. El panel mostraba el doble de lo que el administrador de anuncios reportaba para el mismo periodo. |
| Los anuncios se renombran | La etiqueta de campaña guardada en cada lead conserva el nombre viejo del anuncio. Dos pautas que parecían distintas eran el mismo anuncio con dos nombres. El cruce hay que hacerlo por identificador, nunca por nombre. |
| Tres ventanas de tiempo distintas | El sistema contaba desde una fecha, las métricas desde otra y el administrador de anuncios desde una tercera. Ninguna cifra era comparable con ninguna otra, y todas eran «correctas». |
Ninguno de estos cinco problemas se ve mirando un panel. Todos aparecen al comparar dos fuentes que deberían decir lo mismo y no lo dicen.
Parte 4
Cuatro reglas que nos llevamos
1. El orden importa más que la configuración
Nunca apagues la detección automática de eventos antes de ver llegar el primer evento real por el canal nuevo. Si lo apagas antes, las campañas que optimizan por conversión se quedan sin ninguna señal y el rendimiento cae mientras todo «está bien configurado».
2. Mide de dónde vienen los leads antes de medir mejor los leads
Estuvimos a punto de dedicar semanas a instrumentar un formulario que recibía un envío al mes. Media hora de medición previa cambió el proyecto entero.
3. Optimizar por calidad necesita volumen
Una plataforma de anuncios necesita del orden de cincuenta eventos semanales por conjunto de anuncios para salir de la fase de aprendizaje. Con cien leads a la semana repartidos entre varios conjuntos, y solo una parte calificando, ese umbral no se alcanza. La devolución de calidad sirve primero como criterio de decisión humano —qué anuncio mantener y cuál cortar— y solo después, al consolidar conjuntos o crecer, como señal de optimización automática.
4. Una cifra sin su fuente no es un dato
El indicador de cobertura de llamadas que todos daban por bueno mezclaba dos procesos distintos y estaba inflado. Al medirlo contra las etiquetas reales de llamada bajó del 13 % declarado al 10,4 % real. Con el diagnóstico correcto se pudo ordenar la operación y subirlo al 16 % — algo imposible mientras el número mintiera a favor.