Conseguir que un usuario envíe un formulario es importante. Saber de dónde llegó, qué formulario utilizó y si el envío terminó correctamente puede ser todavía más útil.
Cuando desarrollamos formularios personalizados en WordPress podemos registrar una conversión exactamente en el momento en que el servidor confirma que el formulario ha sido validado y procesado correctamente.
Esto permite diferenciar un simple clic en el botón de enviar de una conversión realmente confirmada.
En este tutorial veremos cómo plantear esta arquitectura en WordPress y cómo generar un evento que posteriormente pueda utilizarse para analítica, atribución, APIs, CRM u otros procesos.
¿Qué consideramos una conversión en un formulario?
Antes de implementar código debemos definir qué queremos medir.
Un usuario puede visitar una página, empezar a rellenar un formulario e incluso hacer clic en el botón de enviar. Ninguna de estas acciones significa necesariamente que el formulario haya llegado correctamente a su destino.
Para un formulario de contacto, una definición mucho más fiable sería:
Conversión = formulario validado y procesado correctamente por el servidor.
Esta diferencia evita registrar como conversiones intentos incompletos, errores de validación, fallos durante el procesamiento o determinados envíos automatizados.
El error de medir solamente el clic en “Enviar”
Una implementación muy sencilla podría escuchar mediante JavaScript el clic sobre el botón del formulario y generar inmediatamente un evento de conversión.
El problema es que el clic no confirma el resultado.
Después de pulsar el botón, el usuario todavía puede encontrarse con un campo obligatorio vacío, una dirección de correo no válida, una comprobación antispam fallida, un error del servidor o cualquier otra circunstancia que impida completar el envío.
En ese caso tendríamos una conversión registrada que realmente nunca ocurrió.
Por eso, dentro de un proyecto de desarrollo web, conviene separar claramente la interacción del usuario de la confirmación real del proceso.
Arquitectura básica para registrar una conversión
Podemos representar el proceso de esta forma:
- El usuario llega a una página.
- Rellena el formulario.
- Envía la información.
- WordPress recibe los datos.
- Validamos los campos y las medidas de seguridad.
- Procesamos la operación correspondiente.
- Confirmamos que el proceso terminó correctamente.
- Generamos la conversión.
A partir de ese momento podemos enviar el evento al sistema de medición que necesitemos o ejecutar otras acciones relacionadas con el lead.
Ejemplo de formulario personalizado en WordPress
Para entender el proceso utilizaremos un formulario muy sencillo con nombre y correo electrónico.
<form method="post" id="contact-form">
<?php wp_nonce_field( 'hc_contact_form', 'hc_contact_nonce' ); ?>
<p>
<label for="name">Nombre</label>
<input
type="text"
id="name"
name="name"
required
>
</p>
<p>
<label for="email">Email</label>
<input
type="email"
id="email"
name="email"
required
>
</p>
<button type="submit" name="hc_submit">
Enviar
</button>
</form>El formulario incluye un nonce de WordPress que utilizaremos durante el procesamiento para comprobar que la petición forma parte del flujo esperado.
El nonce es una pieza de la validación, pero no sustituye otras medidas necesarias como validar los datos recibidos, comprobar permisos cuando corresponda o aplicar mecanismos específicos contra abuso y spam.
Validar los datos antes de registrar la conversión
Ahora podemos recibir y validar los datos en PHP:
if ( isset( $_POST['hc_submit'] ) ) {
if (
! isset( $_POST['hc_contact_nonce'] ) ||
! wp_verify_nonce(
sanitize_text_field(
wp_unslash( $_POST['hc_contact_nonce'] )
),
'hc_contact_form'
)
) {
return;
}
$name = isset( $_POST['name'] )
? sanitize_text_field( wp_unslash( $_POST['name'] ) )
: '';
$email = isset( $_POST['email'] )
? sanitize_email( wp_unslash( $_POST['email'] ) )
: '';
if ( empty( $name ) || ! is_email( $email ) ) {
return;
}
/*
* Procesar el formulario.
*
* Por ejemplo:
* - enviar un email;
* - guardar un lead;
* - llamar a una API;
* - enviar información a un CRM.
*/
}En este punto todavía no deberíamos registrar ninguna conversión.
Hemos comprobado que los datos tienen una estructura válida, pero todavía necesitamos saber si la operación que consideramos importante ha terminado correctamente.
Generar un evento solamente cuando existe una conversión real
Una forma limpia de estructurar nuestro desarrollo consiste en crear una acción propia de WordPress que se ejecute únicamente después de completar correctamente el proceso.
do_action(
'hc_form_conversion',
array(
'form' => 'contact',
'email' => $email,
)
);Este código todavía no envía la conversión a Google Analytics, un CRM o cualquier otra plataforma.
Lo que hemos creado es un punto dentro de nuestra aplicación que representa un acontecimiento concreto:
El formulario se ha procesado correctamente.
¿Por qué crear nuestro propio evento?
Porque de esta forma desacoplamos la lógica del formulario de los sistemas que utilizarán posteriormente la información.
El formulario se ocupa de recibir, validar y procesar los datos. Otros componentes pueden escuchar el evento y decidir qué hacer después.
Por ejemplo, podemos utilizarlo para registrar internamente la conversión:
function hc_register_form_conversion( $data ) {
error_log(
sprintf(
'Conversión formulario: %s',
sanitize_key( $data['form'] )
)
);
}
add_action(
'hc_form_conversion',
'hc_register_form_conversion'
);En un proyecto real no utilizaríamos necesariamente error_log() como sistema de analítica. El ejemplo simplemente demuestra que otro componente puede reaccionar ante la conversión sin modificar la lógica principal del formulario.
Enviar la conversión a una API o CRM
El mismo evento puede utilizarse para comunicar WordPress con un servicio externo mediante una API.
function hc_send_conversion_to_api( $data ) {
$response = wp_remote_post(
'https://api.ejemplo.com/conversions',
array(
'timeout' => 10,
'headers' => array(
'Content-Type' => 'application/json',
),
'body' => wp_json_encode(
array(
'form' => sanitize_key( $data['form'] ),
)
),
)
);
if ( is_wp_error( $response ) ) {
// Registrar o gestionar el error.
return;
}
}
add_action(
'hc_form_conversion',
'hc_send_conversion_to_api'
);La URL es únicamente ilustrativa. En una implementación real utilizaríamos el endpoint, método de autenticación y estructura de datos exigidos por el servicio correspondiente.
Esta separación permite además conectar el mismo formulario con diferentes destinos sin convertir su lógica principal en una sucesión de integraciones específicas.
Guardar el origen de la conversión
Registrar que hubo una conversión es útil, pero podemos obtener mucha más información si relacionamos el envío con la visita que lo originó.
Por ejemplo, podríamos conservar determinados parámetros de atribución presentes cuando el usuario llega a la web:
utm_sourceutm_mediumutm_campaignutm_term- página de entrada;
- página donde se produjo la conversión.
De esta forma dejamos de responder únicamente a la pregunta “¿cuántos formularios recibí?” y podemos empezar a analizar qué visitas y campañas están generando esos formularios.
La atribución debe conservarse antes de enviar el formulario
Existe un detalle importante: los parámetros de campaña pueden estar presentes en la primera página visitada y desaparecer durante la navegación antes de que el usuario llegue al formulario.
Por eso, si queremos atribuir correctamente la conversión, necesitamos conservar la información relevante durante la sesión o mediante el mecanismo que hayamos diseñado para ese proyecto.
Cuando finalmente se produce el envío, podemos asociar esa información a la conversión confirmada.
No confíes en campos ocultos enviados por el navegador
Los campos ocultos pueden resultar útiles para transportar información, pero siguen formando parte de una petición controlada por el navegador y pueden ser manipulados.
Por tanto, un campo hidden no debe convertirse automáticamente en una fuente fiable de información.
Si un dato afecta a seguridad, permisos, precios o cualquier otra decisión sensible, debe comprobarse en el servidor y no considerarse válido simplemente porque haya llegado mediante el formulario.
Conversión y lead no tienen por qué ser exactamente lo mismo
También conviene separar los conceptos de conversión y lead válido.
Podemos registrar una conversión porque el formulario se ha enviado correctamente y, posteriormente, determinar si ese envío constituye un lead válido según las reglas del negocio.
Por ejemplo, un sistema podría identificar posteriormente:
- duplicados;
- spam;
- solicitudes incompletas;
- contactos que no cumplen determinadas condiciones comerciales.
Esta distinción resulta especialmente importante cuando el formulario forma parte de un proceso comercial conectado posteriormente con un CRM.
¿Y si el formulario utiliza AJAX?
El principio es exactamente el mismo.
El navegador envía la petición mediante JavaScript, WordPress valida y procesa los datos en el servidor y devuelve una respuesta indicando si la operación terminó correctamente.
Solo después de recibir una confirmación positiva deberíamos disparar en el navegador cualquier evento adicional que dependa de una conversión confirmada.
Por ejemplo, ese momento podría utilizarse para informar a una capa de analítica, mostrar una pantalla de confirmación o ejecutar otra acción que solo tenga sentido después de un envío válido.
Qué información podemos asociar a una conversión
Una vez que disponemos de una arquitectura propia, el evento puede contener más contexto que un simple “formulario enviado”.
Dependiendo del proyecto podríamos trabajar con información como:
- identificador del formulario;
- fecha y hora;
- página donde se produjo;
- origen o campaña;
- tipo de solicitud;
- estado del procesamiento;
- identificador interno del lead, cuando exista.
No significa que debamos enviar toda esa información a todos los sistemas. Cada integración debería recibir únicamente los datos necesarios para su función.
Formularios personalizados y medición de conversiones
Una de las ventajas de desarrollar un formulario específicamente para un proyecto es que no estamos limitados a enviar un correo electrónico.
Podemos diseñar el flujo completo: validación, protección antispam, almacenamiento, atribución, comunicación con APIs, envío hacia un CRM y registro de conversiones.
El formulario deja así de ser un elemento aislado de la web y puede convertirse en una pieza integrada dentro del proceso comercial y de medición.
Si necesitas implementar este tipo de lógica, mi servicio de creación de formularios personalizados para WordPress está orientado precisamente a formularios que necesitan hacer algo más que enviar un mensaje.
Conclusión
Registrar correctamente una conversión de formulario no consiste simplemente en detectar que alguien ha pulsado el botón “Enviar”.
Una implementación fiable debe confirmar primero que el servidor ha validado y procesado correctamente la solicitud. Solo entonces existe el evento que hemos decidido considerar una conversión.
A partir de ahí podemos conectar ese evento con analítica, campañas, APIs, CRM u otros sistemas sin mezclar toda esa lógica dentro del propio formulario.
Cuando además conservamos información sobre el origen de la visita, el formulario deja de ser únicamente un medio de contacto y pasa a convertirse en una fuente de datos para entender qué acciones están generando oportunidades reales.
