Conseguir que un usuario envíe un formulario es importante. Saber de dónde llegó ese usuario, qué formulario utilizó y si el envío terminó correctamente puede ser todavía más importante.
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 procesado correctamente. Esto nos permite diferenciar un simple clic en el botón de enviar de una conversión real.
En este tutorial veremos cómo plantear esta arquitectura y cómo generar un evento después de validar y procesar correctamente un formulario personalizado.
¿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 es importante porque evita registrar como conversiones intentos incompletos, errores de validación o determinados envíos automatizados.
El error de medir solamente el clic en “Enviar”
Una implementación sencilla podría escuchar mediante JavaScript el clic sobre el botón del formulario y generar inmediatamente un evento.
El problema es que el usuario puede hacer clic y encontrarse después con un campo obligatorio vacío, un error del servidor, una validación antispam fallida o cualquier otro problema que impida completar el envío.
En ese caso tendríamos una conversión registrada que realmente nunca ocurrió.
Por eso, en un proyecto de desarrollo web con WordPress, prefiero separar claramente la interacción del usuario de la confirmación real del proceso.
Arquitectura básica de una conversión
Podemos pensar el proceso de esta forma:
- El usuario llega a una página.
- Rellena el formulario.
- WordPress recibe los datos.
- Validamos los campos y las medidas de seguridad.
- Procesamos correctamente el formulario.
- Generamos la conversión.
A partir de ese momento podemos enviar el evento al sistema que necesitemos o ejecutar otras acciones relacionadas con el lead.
Ejemplo de formulario personalizado en WordPress
Para entenderlo 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 es válida dentro del flujo esperado.
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.
*/
}Todavía no hemos registrado ninguna conversión. Primero debemos 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 es crear una acción propia de WordPress que se ejecute únicamente después de completar el proceso:
do_action(
'hc_form_conversion',
array(
'form' => 'contact',
'email' => $email,
)
);Este código no envía todavía la conversión a ninguna plataforma. Simplemente crea un punto dentro de nuestra aplicación que representa un evento concreto: el formulario se ha procesado correctamente.
¿Por qué crear nuestro propio evento?
Porque desacoplamos el formulario del sistema que utilizará posteriormente la información.
Por ejemplo, podemos utilizar el mismo evento 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 muestra que cualquier componente puede escuchar 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, sistema de autenticación y estructura de datos exigidos por el servicio correspondiente.
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.
No confíes en campos ocultos enviados por el navegador
Los campos ocultos son útiles para transportar información, pero siguen formando parte de una petición controlada por el navegador y pueden ser manipulados.
Si un dato afecta a seguridad, permisos, precios o cualquier decisión sensible, debe comprobarse en el servidor y no considerarse fiable simplemente porque llegue mediante un campo hidden.
Conversión y lead no tienen por qué ser exactamente lo mismo
Otro detalle interesante es separar ambos conceptos.
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 duplicados, spam, solicitudes incompletas o contactos que no cumplen determinadas condiciones comerciales.
¿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 entonces debemos disparar en el navegador cualquier evento adicional que dependa de una conversión confirmada.
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 todo el flujo: validación, protección antispam, almacenamiento, atribución, comunicación con APIs, CRM y registro de conversiones.
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. A partir de ahí podemos generar un evento y conectarlo con analítica, campañas, APIs, CRM u otros sistemas.
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.
