Configuración de formularios

Beaconry se engancha al evento de envío de siete plugins de formularios del lado del servidor y dispara una conversión de lead a cada canal que tengas conectado, con el email, el teléfono y cualquier otra PII reconocida hasheada antes de salir de tu servidor. Sin pegamento de JavaScript, sin snippets de píxel por formulario. Activa el plugin, enciende la integración del formulario, listo.

Los siete adaptadores

Cada plugin de formularios tiene un adaptador dedicado que se enlaza al hook de envío real de ese plugin (no a un listener genérico del DOM). Un adaptador solo se registra cuando su plugin anfitrión está realmente cargado, así que una instalación con solo Fluent Forms nunca arrastra rutas de código de Gravity. Los siete vienen en cada build de Beaconry y son estables. No hay adaptadores beta.

La columna "descubrimiento eager" importa para la ergonomía de la configuración. Fluent y Kadence Advanced exponen su lista completa de formularios a una sola consulta, así que Beaconry puede mostrar cada formulario en la tabla de mapeo en el momento en que abres la pestaña Formularios. Los otros plugins guardan los formularios de maneras que son demasiado costosas de escanear en cada carga de página del admin, por eso sus filas aparecen tras el primer envío real. El seguimiento sigue funcionando para esos formularios de inmediato, solo configuras los overrides después de que hayan disparado una vez.

Encender una integración de formulario

La pestaña Formularios solo aparece en el menú de Beaconry cuando al menos un plugin de formularios compatible está activo, así que nunca te quedas mirando una pestaña vacía. Dentro de ella, cada plugin detectado tiene un interruptor maestro. Enciéndelo y cada formulario que pertenezca a ese plugin empieza a disparar eventos de lead al enviar. No hay nada que pegar en el formulario en sí.

Si quieres rastrear solo algunos de los formularios de un plugin, usa la whitelist por formulario en la misma pestaña en lugar del interruptor general. Una whitelist vacía significa "todos los formularios"; añadir entradas la reduce exactamente a esos.

Cómo funciona la detección automática

Beaconry nunca te pide que nombres tus formularios a mano. Dos mecanismos mantienen la tabla de mapeo sincronizada con la realidad:

1. Sincronización eager del catálogo. Cada vez que se renderiza la pestaña Formularios, Beaconry le pide a cada adaptador activo sus formularios y los fusiona en el catálogo almacenado. Los formularios nuevos reciben una fila por defecto vacía, los formularios renombrados ven su etiqueta refrescada, y tus ajustes existentes por formulario quedan intactos. Así que un formulario que acabas de construir en Fluent o Kadence Advanced es configurable antes de haber sido enviado alguna vez.
2. Registro lazy en el primer envío. Para los plugins que no se pueden escanear de forma barata (y para el formulario de bloque inline de Kadence), el primer envío real registra el formulario. A partir de ese punto tiene una fila en la tabla como cualquier otro.

De cualquier modo, el formulario se indexa con un id compuesto estable (plugin_formid, saneado), así que el mismo formulario siempre mapea a la misma fila de configuración a través de renders y envíos.

La interfaz de mapeo de campos por formulario

Cuando un visitante envía, Beaconry recorre los campos enviados e intenta reconocer los que son útiles para la calidad de match del anunciante: email, teléfono, nombre, apellido, código postal, ciudad, estado, país, género, fecha de nacimiento y un id de cliente externo. El reconocimiento es una heurística sobre la etiqueta y el nombre del campo, afinada para redacciones en inglés, alemán y español. Así que E-Mail, email_1, Ihre Mail-Adresse resuelven todos al slot de email; Vorname resuelve a nombre; PLZ y Postleitzahl resuelven a código postal.

La pestaña Formularios renderiza una tabla por formulario con cada campo detectado junto a aquello a lo que la heurística lo resolvió. Cada fila lleva un desplegable para que puedas sobrescribir la suposición:

• Déjalo en el valor por defecto dinámico Auto (X) para aceptar la heurística.
• Elige un destino diferente para remapear un campo que la heurística etiquetó mal o se saltó (por ejemplo, un campo alemán Land que quieras mapear a país, que la heurística incorporada deja en paz a propósito para evitar falsos matches como Deutschland o Landkreis).
• Elige No mapear para excluir un campo por completo (ver la siguiente sección).

Los overrides son por formulario, no globales. La misma etiqueta de campo puede mapear a slots distintos en dos formularios diferentes, y la fila se anota con (auto) o (manual) para que veas de un vistazo qué campos has tocado.

Aparte del mapeo de PII, cada formulario tiene un tipo de lead. El valor por defecto es un lead genérico, pero puedes fijar un formulario en Contacto, Solicitud, Suscripción, Registro, Cita, Prueba, Descarga o Donación, o proporcionar un nombre de evento totalmente personalizado por canal. El tipo de lead es lo que decide el nombre de evento enviado a cada plataforma:

El dispatcher resuelve el nombre de evento correspondiente para cada canal conectado a partir de una sola elección de tipo, así que eliges el significado de negocio una vez y cada plataforma recibe el nombre que espera. Un tipo no fijado o desconocido recae en un lead simple.

El marcador manual de omisión

La heurística de PII es deliberadamente eager, porque subreconocer te cuesta calidad de match del anunciante. Pero a veces un campo parece PII y no quieres que se reenvíe. Un campo "Motivo del contacto" con la palabra "mail" dentro, un número de referencia interno que coincide por patrón con la regla de id externo, un campo de texto libre que casualmente contiene la palabra "tel". Para esos, el desplegable de mapeo de campos tiene una opción No mapear.

Elegirla almacena un marcador de omisión explícito para ese campo en ese formulario. Lo importante es que el marcador es explícito: no solo borra tu override, sino que detiene activamente que la heurística incorporada vuelva a coincidir el campo como respaldo. Así que un campo que omitiste sigue omitido aunque su nombre todavía parezca email o teléfono. En la tabla se muestra como una decisión manual, no como un campo sin coincidencia, así que puedes distinguir "lo excluí a propósito" de "la heurística no encontró nada aquí".

Úsalo siempre que la heurística tenga razón técnicamente sobre la redacción pero se equivoque sobre la intención. Es la alternativa limpia a renombrar un campo de formulario solo para esquivar el seguimiento.

Qué pasa al enviar

Cuando se envía un formulario rastreado, Beaconry construye un evento de lead canónico y lo despacha a través del mismo forwarder del lado del servidor que usa cualquier otro evento. En concreto:

• Los campos reconocidos se recogen en un bloque de datos de usuario (em, ph, fn, ln, zp, ct, st, país, género, fecha de nacimiento, id externo). El teléfono se normaliza hacia E.164, el género a una sola f/m, la fecha de nacimiento a YYYYMMDD, todo antes del hashing.
• Cada canal que tengas conectado recibe el evento, cada uno con la PII hasheada con SHA-256 según la spec de match de ese canal. Los valores en bruto nunca salen de tu servidor. Un canal que no hayas conectado simplemente se omite.
• El nombre de evento por canal viene del tipo de lead del formulario (ver la tabla de arriba). Por defecto es generate_lead para GA4 y Lead para las plataformas de anuncios.
• La clave estable del formulario se adjunta como content id, así que Meta y TikTok dejan de advertir sobre detalles de contenido faltantes y obtienes una audiencia limpia por formulario sobre la que construir. La etiqueta de tipo de lead de Beaconry se registra internamente para la columna "Fuente" de los Logs y el Live-Dashboard, pero deliberadamente no se escribe en content_category (ese campo está reservado para categorías reales de catálogo de productos de los adaptadores de commerce).
• Si el modo híbrido está activo para un canal, el motor del navegador inyecta un event_id compartido en el momento del envío para que el proveedor deduplique las copias del lead del navegador y del servidor. Ver Modo Híbrido.

Como el envío ya ocurrió en PHP (el visitante hizo clic en enviar), no hay una nueva comprobación de consentimiento separada en esta capa. El consentimiento se aplica una vez, de forma central, en el dispatcher, la misma puerta que cubre commerce y eventos personalizados.

¿No quieres reenviar un formulario entero?

Tres palancas, en orden de contundencia:

1. Omisión por campo para excluir el valor de un campo mientras se sigue rastreando el lead (el marcador de omisión de arriba).
2. Whitelist por formulario para rastrear solo formularios concretos de un plugin.
3. Interruptor maestro del plugin apagado para dejar de rastrear los formularios de ese plugin por completo.

¿Quieres saber dónde abandonan los visitantes?

El seguimiento de leads te dice quién convirtió. La analítica de embudo de formularios te dice quién empezó y abandonó, y en qué campo. Es una funcionalidad separada y opt-in en la misma pestaña Formularios que registra inicios de formulario, abandonos y envíos de lead por formulario, solo con nombres de campo y conteos (nunca valores de campo). Es analítica pura por construcción: un abandono llega como mucho a GA4 (y solo cuando lo enciendes), nunca a un canal de anuncios, y los checkouts de commerce están excluidos porque tienen su propio embudo de vista-a-compra. Actívala en Beaconry → Formularios → Form-Funnel y lee allí la tabla de abandono por formulario (inicios, leads, abandonos, tasa de conversión, campos con más abandono).