Conversiones offline en Meta: manda la venta de tu CRM

Las conversiones offline en Meta son las ventas que ocurren fuera de tu web (una llamada, una reunión, un pago) y que se envían a Meta desde tu CRM con la API de conversiones. Esta guía es el paso a paso: qué evento mandar, qué campos llevar, cómo se cifran los datos, cómo evitar duplicados y cómo saber si Meta reconoce a la persona.

Actualizado: 2026-11-08

Qué resuelve y qué no cubre esta guía

El anuncio genera un lead, el comercial lo trabaja y la venta se cierra días o semanas después en el CRM. Meta solo ve el formulario. Si le cuentas la venta, puede optimizar para encontrar personas parecidas a las que compran, no a las que rellenan formularios. Eso es lo que hace la API de conversiones cuando se alimenta del CRM.

Aquí no repetimos qué es la API de conversiones: si necesitas la definición y el contexto, está explicado en este artículo de Acelera tu CRM. Esta guía parte de que ya sabes que existe y quieres saber cómo se manda la venta.

Qué evento mandar desde el CRM

Cada evento tiene un nombre (event_name), que puede ser uno estándar de Meta, como Lead o Purchase, o uno personalizado. Para un negocio con proceso comercial, un criterio práctico:

Lead cualificado (el comercial lo ha validado): suficientemente frecuente para que el algoritmo aprenda.
Venta cobrada (Purchase con valor y moneda en custom_data): la señal más fiable, pero con menos volumen y más retraso.

No hay una regla única. Si la venta llega con poco volumen, mandar también un evento intermedio ayuda a que el sistema tenga datos con los que aprender. Lo importante es que el evento signifique lo mismo siempre y que tu CRM lo dispare solo cuando de verdad ocurre.

Los campos de cada evento

Campo	Obligatorio	Para qué sirve
`event_name`	Sí	Qué ha pasado (`Lead`, `Purchase`, personalizado)
`event_time`	Sí	Marca de tiempo Unix, en segundos, de cuándo ocurrió realmente la acción
`action_source`	Sí	Dónde ocurrió: `website`, `phone_call`, `chat`, `email`, `physical_store`, `system_generated`, `business_messaging`, `app` u `other`
`user_data`	Sí	Datos del cliente para que Meta lo reconozca (ver abajo)
`event_id`	Recomendado	Identificador único para deduplicar
`custom_data`	No	Valor, moneda y datos de negocio
`event_source_url`	Solo en eventos de web	URL donde ocurrió; debe coincidir con tu dominio verificado

Para una venta que se cierra por teléfono o en una reunión, action_source debe describir cómo ocurrió de verdad (phone_call, physical_store, chat, email…) y other queda para lo que no encaje. Reserva website para conversiones que ocurren en la web; esas exigen además event_source_url y client_user_agent.

Parámetros de coincidencia y cifrado

Meta tiene que reconocer a la persona del CRM como una persona que vio o clicó tu anuncio. Eso se llama coincidencia, y se hace con los campos de user_data:

Parámetro	Dato	¿Hash SHA-256?
`em`	Correo, sin espacios y en minúsculas	Sí
`ph`	Teléfono sin símbolos ni ceros iniciales, con prefijo de país	Sí
`fn` y `ln`	Nombre y apellido en minúsculas, sin puntuación	Sí
`external_id`	Tu identificador del cliente en el CRM	Se recomienda hashearlo
`fbc`	Valor de la cookie `_fbc` (clic del anuncio)	No
`fbp`	Valor de la cookie `_fbp` (navegador)	No
`client_ip_address`, `client_user_agent`	IP y navegador	No
`lead_id`	Identificador de un lead de formularios instantáneos de Meta	No

Dos consecuencias para el CRM. Primera: guarda fbc y fbp en el lead cuando entra por la web, porque semanas después ya no se pueden recuperar. Segunda: normaliza antes de hashear, porque un correo con mayúsculas da otro hash y no coincide. Los valores no se hashean salvo los que indica la tabla.

Paso a paso: de la venta en el CRM a Meta

Captura en la entrada: guarda en el lead correo, teléfono, nombre, fbc, fbp y, si vienes de un formulario de Meta, el lead_id.
Define el evento y el momento exacto en que el CRM lo dispara (lead cualificado, venta cobrada).
Construye el evento con los campos de la tabla anterior, normalizando y cifrando.
Envía con una petición POST a graph.facebook.com/{versión}/{ID del píxel}/events con tu token de acceso. Admite hasta 1.000 eventos por petición.
Prueba en el Administrador de eventos, Eventos de prueba, con el test_event_code, y quítalo antes de pasar a producción.
Revisa en el Administrador de eventos que el evento llega y que la coincidencia es buena.

Envía el evento cuando ocurre, o en lotes muy cercanos al momento: Meta recomienda compartir los eventos en cuanto suceden.

Plazo, deduplicación y reintentos

Dos reglas de Meta que condicionan el diseño:

Plazo del evento: event_time puede ser anterior al envío, pero no más de 7 días (Meta admite un plazo más largo para eventos con action_source physical_store; compruébalo en su documentación). Si un solo evento del lote supera ese plazo, se rechaza la petición entera. Por eso la venta debe salir del CRM cuando se registra, no en un lote mensual.
Deduplicación: si llegan dos eventos con el mismo event_name y event_id, se conserva el primero. Sirve para evitar duplicados entre el píxel y el servidor y también para que un reintento no cuente dos veces la venta. Meta indica que esta deduplicación aplica a eventos recibidos dentro de las 48 horas posteriores al primero.

Usa como event_id algo estable del CRM, como el identificador de la venta o de la factura. Para el mismo lead que pasa por el píxel y por el servidor, el event_id del navegador y el del servidor deben ser idénticos.

Calidad de coincidencia: cómo saber si Meta te reconoce

El Administrador de eventos muestra una puntuación de calidad de coincidencia de eventos (sobre 10) para cada evento de servidor. Indica cuánto ayudan tus datos a asociar el evento con una cuenta de Meta. Solo los eventos coincidentes sirven para atribuir y para optimizar la entrega; los que no coinciden valen para medición básica. Para subir la puntuación, manda más parámetros y de mejor calidad: correo, teléfono, nombre y apellido, IP, y los dos identificadores de cookie. Meta indica que esta puntuación hoy solo está disponible para eventos web.

Errores típicos

No guardar fbc y fbp y descubrir semanas después que no hay forma de recuperarlos.
Hashear sin normalizar, o hashear lo que no debe hashearse (IP, user agent, cookies).
Enviar la venta con más de 7 días de retraso y que se rechace el lote.
No usar event_id y contar dos veces la misma venta.
Marcar todo como website aunque la venta fuera por teléfono.
Dejar el test_event_code puesto en producción: los eventos con ese código no se descartan y entran igualmente.

Cómo lo hace Acelera Sales

Acelera Sales mide tu publicidad hasta la venta cobrada en el CRM: cada venta vuelve al anuncio, la campaña y el canal que la originaron. Después devuelve esa venta a Meta con la API de conversiones; la devolución a Google como conversión offline es una capacidad del producto que se activa y se prueba en la implantación. Así los algoritmos aprenden de ventas y no solo de formularios. Los conectores listos son Meta, Google Ads/YouTube, Zoho CRM y HubSpot; cualquier otro CRM se conecta en la implantación.

El píxel guarda los identificadores del clic en el lead, y la optimización de algoritmos manda la venta a Meta con la API de conversiones cuando se cobra en el CRM. Puedes ver los CRM y plataformas conectables en integraciones o reservar una demo.

Fuentes

Preguntas frecuentes

¿Qué es una conversión offline en Meta?

Es una acción de negocio que ocurre fuera de tu web, como una venta cerrada por teléfono o en persona, y que envías a Meta desde tu CRM con la API de conversiones para que se asocie a un anuncio.

¿Qué valor de action_source uso para una venta cerrada por teléfono?

phone_call, si la conversión ocurrió por teléfono. Meta admite también email, chat, physical_store, system_generated, business_messaging, app, website y other. Elige el que describe cómo ocurrió.

¿Hasta cuántos días atrás puedo enviar una venta?

El event_time puede ser anterior al envío, pero no más de 7 días (Meta admite un plazo más largo para eventos con action_source physical_store; compruébalo en su documentación). Si un evento del lote supera ese plazo, se rechaza toda la petición.

¿Qué datos del cliente hay que cifrar?

Correo, teléfono, nombre y apellido se envían con hash SHA-256 tras normalizarlos; se recomienda también hashear el external_id. fbc, fbp, la IP y el user agent no se hashean.

¿Cómo evito contar dos veces la misma venta?

Enviando el mismo event_name y event_id: Meta conserva el primero. Usa un identificador estable del CRM, como el número de venta.

¿Cómo sé si Meta reconoce a la persona?

Mira la calidad de coincidencia de eventos en el Administrador de eventos. Sube con más parámetros de calidad: correo, teléfono, nombre, IP, fbc y fbp.

¿Puedo probar sin afectar a mis campañas?

Puedes ver los eventos de prueba en tiempo real con test_event_code (se genera en Eventos de prueba del Administrador de eventos), pero Meta no los descarta: usa datos de prueba y quita el código al pasar a producción.

Relacionados

Conversiones offline en Google Ads: sube la venta de tu CRM Server side tracking: qué es y por qué no es solo cookies Modelos de atribución: tipos, ejemplos y cuál elegir