Auditoría de instrumentación del funnel de conversión

Landings de edición · Google Analytics 4 + Google Tag Manager
Preparado por Juana Betancourt · 2026-09-03 · Ventana analizada: 2026-06-05 a 2026-09-03 (90 días) · Propiedad GA4 493104153
Necesitamos de Clan

1. Acceso al contenedor de Google Tag Manager (quien lo administre hoy) para poder especificar y validar el arreglo de instrumentación descrito en este reporte.

2. Confirmar si el formulario del bloque #contact-form en las landings de edición está pensado para renderizar 3 versiones simultáneas (español/inglés/portugués) — apareció así en la auditoría y no estaba documentado.

Resumen

Hoy es posible medir cuándo alguien llega a una landing de edición y cuándo completa la aplicación (evento apply_submit / lead). Todo lo que pasa en el medio — llegar al bloque del formulario, empezar a completarlo, en qué tramo del scroll se pierde el interés — no se está capturando en ninguna de las 5 landings de edición activas. La causa es técnica y puntual: el formulario está embebido como iframe de Tally, y el trigger automático de eventos de formulario de Google Tag Manager no puede leer adentro de un iframe de otro dominio sin un listener específico. El dato de conversión final (cuántos completan) está sano; el tramo intermedio del funnel es hoy una caja negra.

Lo que sí se puede medir hoy

Paso del funnelEvento GA490 díasEstado
Llega a la landing de la ediciónpage_view15.173 vistas / 13.053 usuarios (Bariloche)medido
Scroll profundo (único umbral disponible: 90%)scroll1.065 usuarios (8,2%)parcial
Llega al bloque del formulariosin dato
Empieza a completar el formulariosin dato
Click en CTA interno ("Aplicar", "Reservar")sin dato
Completa el formularioapply_submit / lead43 usuariosmedido

La landing de Bariloche · Septiembre 2026 concentra el 90% del tráfico de edición y se usa como referencia; el mismo patrón de instrumentación se repite en las otras 4.

Verificación técnica — por qué el tramo intermedio es invisible

Se inspeccionó el HTML publicado de las 5 landings de edición activas. Las 5 embeben el formulario de aplicación como <iframe data-tally-src="https://tally.so/embed/...">, sin ningún <form> nativo en la página:

LandingEmbed del formulario
Bariloche · Septiembre 2026tally.so/embed/0QA0Dy (iframe)
Tandil · Noviembre 2026tally.so/embed/QKEPbY (iframe)
Tandil Teams · Noviembre 2026 (B2B)tally.so/embed/680zOk (iframe)
Buzios · Octubre 2026tally.so/embed/ODVOqk (iframe)
Recreio · Diciembre 2026tally.so/embed/ODVOqk (iframe)

El trigger automático "Form Start" de GTM escucha interacciones sobre elementos <form> del documento principal. Un iframe de otro dominio (tally.so) es un documento aparte: GTM no ve lo que pasa adentro salvo que Tally lo avise explícitamente vía window.postMessage y se configure un trigger de evento personalizado que lo escuche. Hoy ese listener no existe, así que ningún evento de interacción con el formulario de aplicación llega a GTM/GA4.

El evento apply_submit sí funciona porque está atado a otra cosa: la carga de la página de agradecimiento /es/thank-you, a la que Tally redirige después de un envío exitoso. Esa página vive en el dominio de Clan, así que GTM la ve sin problema — por eso el dato de conversión final es confiable aunque el paso anterior no lo sea.

Qué mide en realidad el evento form_start de GA4

Se registraron 129 eventos form_start en la ventana analizada. Ninguno corresponde a una landing de edición. Se verificó qué formulario nativo vive en cada página donde sí dispara:

PáginaEventos (90d)Formulario real
/es/ediciones72"Avisame de la próxima edición" (wf-form-proxima-edicion)
/es (home)39Newsletter / próxima edición
/es/contacto10Formulario de contacto
/es/comunidad/claners7Newsletter

Es decir: el form_start de GA4 mide intención de newsletter, contacto o lista de espera — no intención de aplicar a un viaje. Cualquier lectura previa que cruzara este número con la conversión a lead de una edición estaría comparando cosas distintas.

Qué no se puede responder hoy con los datos disponibles

Próximo paso propuesto

Especificar y validar en GTM un trigger de evento personalizado que escuche los mensajes que Tally emite por postMessage (inicio de formulario y avance de página), en reemplazo del trigger automático que hoy no alcanza el iframe. Esto cierra el tramo ciego del funnel sin tocar el embed ni el formulario en sí. Queda pendiente de que Clan habilite el acceso al contenedor de GTM para poder implementarlo.


Metodología: reporte de eventos vía GA4 Data API (propiedad 493104153) sobre los últimos 90 días, cruzado con inspección directa del HTML publicado de cada landing (2026-09-03) y con el catálogo de formularios de Tally (14 forms, vía API de Tally). No se registran custom dimensions ni custom metrics en la propiedad — el análisis usa exclusivamente dimensiones estándar de GA4.