Informe técnico · Incidencia

Leads de Meta sin código postal

El 51% de los leads de Meta llegan a Zoho con el código postal volcado al campo Description en vez del campo Zip_Code. Causa identificada en la integración LeadChain ↔ Meta Graph API.

Fecha del análisis
2 de junio de 2026
Cliente
ESSAE Formación
Operado por
Acelera tu CRM
Periodo
11-may → 2-jun · 22 días
Desliza

Lo que está pasando, en una página

Análisis sobre 2.000 leads de Facebook Ads en los últimos 22 días — 375 leads únicos de Meta sobre formularios que piden código postal.

01

Qué pasa

193 de 375 leads (51%) entran a Zoho sin el campo Zip_Code rellenado.

El valor del código postal aparece en el campo Description como texto raw: código_postal:35212.
02

Impacto operativo

Cuatro automatizaciones rotas por cada lead malo.

Sin Zip_Code no se calcula Provincia_F, no se aplica Promoción asignada, no se enruta el lead al asesor por geografía y se rompe el scoring.
03

Diagnóstico

El bug está en la llamada de LeadChain a la Meta Graph API para obtener el field_data del lead.

Cuando esa llamada falla, el fallback ignora el mapping configurado y vuelca el payload raw a Description. No es problema de Meta Ads, ni del formulario, ni del mapping de LeadChain, ni de Zoho.

El mismo lead, entró dos veces

Luzmelly Diaz rellenó el formulario "Medicina Estética" el 1 de junio. Meta le asignó el leadgen_id 2063586544589919. LeadChain procesó ese leadgen_id dos veces, con resultados opuestos.

LEAD MALO · 18:35

Zoho ID 292095000506642248

Procesado 4h 43min después del primero. Mismo leadgen_id de Meta, pero esta vez el mapping no se aplicó.

  • Lead_ID: 2063586544589919
  • Portal_Id: vacío
  • Zip_Code: vacío
  • Description: código_postal:09007
  • Provincia_F: vacío
  • Promoción asignada: vacío
LEAD BUENO · 13:52

Zoho ID 292095000506512930

Procesado correctamente. LeadChain consiguió el field_data de Meta y aplicó el mapping configurado.

  • Portal_Id: 2063586544589919
  • Lead_ID: vacío
  • Zip_Code: 09007
  • Description: vacío
  • Provincia_F: Burgos
  • Promoción asignada: NO APLICA PROMO
Es matemáticamente imposible que sean dos leads distintos de Meta — Meta no reutiliza leadgen_ids. Son el mismo lead procesado dos veces por LeadChain, con un resultado distinto cada vez.

Lo que está en juego cada semana

Datos de Zoho CRM, periodo 11-may a 2-jun 2026.

375
Leads únicos de Meta
Forms _ZIP
51%
Entran con código postal en Description en vez de Zip_Code
193 de 375
12 / 0
Leads que pasan a diario por la ventana 18:26-18:35 — todos fallan, ninguno acierta
fallos vs aciertos

Cómo identificar un lead malo en Zoho

Los cuatro campos que cambian entre un procesamiento OK y uno FAIL.

OK

Portal_Id rellenado con el leadgen_id

El campo Portal_Id lleva el ID numérico que Meta asignó al lead (15-17 dígitos).

Si está rellenado, el mapping de LeadChain se aplicó correctamente.
FAIL

Lead_ID rellenado con el leadgen_id

Mismo valor numérico, pero LeadChain lo escribió en Lead_ID en vez de en Portal_Id.

Señal inequívoca de que el procesamiento cayó al fallback. Portal_Id queda vacío.
OK

Zip_Code con el código postal · Description vacío

El valor "09007" está en su campo correcto.

Los workflows posteriores (Provincia_F, Promoción) se ejecutan sin problema.
FAIL

Description: "código_postal:09007" · Zip_Code vacío

El valor está volcado en texto raw al campo Description.

Los workflows posteriores no encuentran el dato y quedan a medias.

Lo que determina si un lead entra bien o mal

Hemos analizado todas las variables posibles. Solo tres correlacionan con el fallo.

01

Hora del día — de 25% a 89% según hora

A las 13h fallan el 25% de los leads. A las 18h, el 71%. A las 11h, el 79%.

La única variable común a todos esos picos es la carga del servidor de LeadChain o de la Meta Graph API a esas horas. El mismo formulario, el mismo mapping, la misma cuenta de Zoho — solo cambia la hora.
02

Bursts — más leads juntos, más fallos

Cuando un lead llega menos de 60 segundos después del anterior, el fallo sube al 71%.

Si llega tras 5+ minutos de tranquilidad, baja al 51%. Patrón clásico de rate limit en una API externa.
03

Ventana 18:26-18:35 — 0 aciertos sostenidos

Todos los días, en esa ventana de 10 minutos: 12 leads acumulados, 12 fallos, 0 aciertos.

Estadísticamente imposible que sea aleatorio — es un proceso interno de LeadChain (cron, reproceso programado) que sistemáticamente cae en el fallback.

Lo que NO es la causa

Importante para no desviar el ticket. Hemos comprobado y descartado:

El formulario en Meta

Los 10 formularios _ZIP fallan en proporción similar (38-100%).

Incluso "Administración" que usa el campo estándar de Meta post_code falla al 57%. No es problema de cómo está montado el form.

La campaña o el anuncio

Todas las campañas de Meta fallan en porcentaje similar.

No es un anuncio o público concreto el que rompe el flujo.

El canal Facebook vs Instagram

Facebook 51% fallo · Instagram 54% fallo.

Idéntico — descarta problema en un canal específico.

El día de la semana

Lunes 44% · sábado 65%. Variación pequeña, no concluyente.

No es un día concreto el que rompe.

El comercial asignado

El Modified_By no correlaciona con el fallo.

Cualquier comercial recibe leads buenos y malos en proporción similar. No es problema de Zoho ni de los workflows del CRM.

En qué punto exacto se rompe

La cadena Meta → LeadChain → Zoho tiene 7 pasos. Hemos verificado cada uno. Solo uno explica el patrón observado.

Paso 1
Meta · usuario rellena el formulario
Instagram o Facebook. Funciona siempre — los leads llegan.
Paso 2
Meta · genera leadgen_id
ID único de 15-17 dígitos. Cada lead recibe uno.
Paso 3
Meta → LeadChain · webhook
El webhook lleva el leadgen_id. No lleva los datos completos del lead — solo el ID.
Paso 4
LeadChain · recibe el webhook
Funciona siempre. Todos los leads llegan a Zoho — esto está demostrado.
Paso 5
LeadChain → Meta Graph API · ⚠️ aquí se rompe
LeadChain llama a la Meta Graph API para pedir el field_data completo del lead. Cuando esta llamada falla por timeout o rate limit, todo el proceso se va al fallback. Este es el punto exacto del bug.
Paso 6
LeadChain · aplica el mapping configurado
Solo se ejecuta si el paso 5 va bien. Cuando el paso 5 falla, LeadChain hace fallback: vuelca los field_keys del payload inicial al campo Description con sintaxis "key:valor".
Paso 7
LeadChain → Zoho · crea el lead
Funciona siempre — el lead siempre se crea. La diferencia es que entra bien (con mapping aplicado) o mal (con datos en Description).

Por qué este diagnóstico no admite discusión

Tres pruebas matemáticamente irrefutables que descartan cualquier otra causa.

01

Mismo leadgen_id, dos registros distintos

El leadgen_id 2063586544589919 aparece en dos leads distintos de Zoho.

En uno como Portal_Id (bien procesado), en otro como Lead_ID (mal procesado). Creados con 4h 43min de diferencia. Meta nunca reutiliza leadgen_ids — son matemáticamente el mismo lead procesado dos veces por LeadChain con resultados opuestos.
02

Ventana de 0% éxito sostenido

Entre las 18:26 y 18:35 hora española, todos los días: 12 leads procesados, 12 fallos, 0 aciertos.

Estadísticamente imposible que sea aleatorio. Es un proceso interno de LeadChain que sistemáticamente cae en el fallback durante esa ventana.
03

Burst rate consistente con rate limit

Leads que llegan a menos de 60 segundos del anterior fallan el 71%. Leads tranquilos (>5min) fallan el 51%.

La diferencia de 20 puntos es la firma clásica de un rate limit en una API externa. En este caso, Meta Graph API.

Tres preguntas para el soporte de LeadChain

Las únicas tres preguntas cuya respuesta cierra esta incidencia. Solo el equipo técnico de LeadChain puede responderlas.

01

¿Qué corre a las 18:26-18:35?

Es la única ventana del día con 0% de éxito sostenido. ¿Qué cron, reproceso o batch tienen ustedes a esa hora? Es por donde hay que empezar a mirar.

02

Timeout y reintentos en Meta Graph API

¿Cuál es el timeout actual de la llamada a la Meta Graph API tras recibir el webhook? ¿Hay política de reintentos? ¿Backoff exponencial? El 71% de fallo en bursts indica que no hay resiliencia suficiente.

03

Por qué el fallback ignora el mapping

Cuando la Meta Graph API falla, el fallback crea el lead con field_data raw en Description en vez de respetar el mapping configurado. ¿Es un comportamiento intencionado o un bug?

Datos disponibles para verificación

Excel con los 375 leads analizados, agrupado en cuatro pestañas: resumen, 8 pares OK→FAIL (evidencia matemática), 193 leads que entraron mal directamente, 174 leads que entraron bien.

Descargar Excel completo