Mide los clics de tu outreach al demo con un solo evento personalizado

Mandas diez emails en frío un martes. Llegan dos respuestas, el resto silencio. La pregunta que de verdad importa no es tu open rate — es cuáles de los otros ocho prospectos hicieron clic hasta el demo y no dijeron nada. Aquí está el montaje más pequeño que responde esa pregunta limpiamente: un redirect en tu propio dominio, un evento personalizado en Logly, cinco líneas de JavaScript.

Por qué el tracking de páginas genérico no sirve para outreach

Una visita al demo es una señal muy gruesa. El tracker de pageviews por defecto ve tres eventos idénticos:

• Tú, logado, haciendo QA de la página desde el wifi de un hotel.
• Un visitante random que llegó desde un tuit sobre tu lanzamiento.
• El CTO de una SaaS de 30 personas a la que mandaste un email anoche y que está leyendo tu hero ahora mismo.

Solo el tercero merece un follow-up a las 9 de la mañana de mañana. Hasta que separes ese tráfico, cualquier "demo page views: 47" es ruido disfrazado de métrica. Queremos aislar el clic que viene del outreach para poder actuar sobre él — reactivar, despriorizar, promover a "warm" — e ignorar el resto.

La arquitectura mínima: un redirect, un evento

Imagina que tienes una SaaS pequeña llamada Inboxly y mandas unos 10 emails en frío al día. Cada prospecto recibe un token corto único cuando lo metes en la cola.

El email contiene un solo enlace:

https://inboxly.app/c/9f2a

Ese endpoint vive en tu propio dominio, en tu propio Worker (o Express, o Flask — lo que ya tengas). Hace dos cosas y se quita de en medio:

// /c/:token  — handler en Cloudflare Worker
export async function handleClick(req, env) {
  const token = new URL(req.url).pathname.split('/').pop();

  await env.DB.prepare(
    `UPDATE prospects
        SET visited_at = COALESCE(visited_at, ?1)
      WHERE token = ?2`
  ).bind(Date.now(), token).run();

  return Response.redirect(
    `https://inboxly.app/demo?ref=outreach_${token}`,
    302
  );
}

El COALESCE es la única línea con truco: solo estampamos visited_at la primera vez, así que clics repetidos del mismo prospecto no sobrescriben el timestamp de first-touch. El 302 los manda al demo real con un ref que el frontend puede leer.

En la página del demo disparamos el evento solo si el ref tiene nuestra pinta:

<script defer src="https://logly.uk/p.js" data-site="inboxly"></script>
<script>
  const ref = new URLSearchParams(location.search).get('ref') || '';
  if (ref.startsWith('outreach_')) {
    window.logly && window.logly('event', 'or_demo');
  }
</script>

Ese es el pipeline entero. El estado del prospecto pasa a "visitado" en tu DB. La cadencia agregada de clics aparece en el panel de eventos de Logly como or_demo.

Por qué un evento personalizado le gana al tracking solo con UTMs

Los UTMs están bien para taggear campañas puntuales, pero se rompen como atribución de outreach de tres formas predecibles:

• Desaparecen en el segundo clic. El prospecto cae en /demo?utm_source=outreach, pulsa "Pricing", y el UTM ya no está. Cualquier conversión más abajo del embudo parece tráfico orgánico.
• Ensucian los informes de fuentes. Acabas con outreach, outreach2, outreach_q2, y un outreach- con typo porque el tú-de-antes estaba cansado.
• No sobreviven limpios a un redirect en servidor. O los pierdes, o los pegas a mano en la URL de destino y acabas reinventando exactamente lo que un evento con nombre ya hace.

Un evento personalizado es una señal con nombre único que sobrevive el resto de la sesión. El nombre (or_demo) es la clave de join con tu propia DB si quieres profundizar. El panel de eventos agrupa por nombre, no por un parámetro que tienes que acordarte de limpiar.

Cómo mantener la señal limpia

La forma más rápida de cargarte esta métrica es contarte a ti mismo. Dos disciplinas pequeñas lo arreglan:

<script>
  const isInternal =
    location.hostname === 'staging.inboxly.app' ||
    document.cookie.includes('staff=1');

  if (!isInternal) {
    const s = document.createElement('script');
    s.defer = true;
    s.src = 'https://logly.uk/p.js';
    s.dataset.site = 'inboxly';
    document.head.appendChild(s);
  }
</script>

La carga condicional mantiene p.js fuera de las sesiones de staff: no se dispara evento, no se cuenta pageview, no se contamina. Combinado con el check del ref, lo único que puede generar un evento or_demo es un prospecto real haciendo clic en un enlace real de outreach.

Qué hacer con los datos

Abre el dashboard de Logly, filtra Eventos → or_demo, y verás la cadencia de clics tras cada tanda de envíos. El volumen es pequeño a propósito — diez emails al día significa que un or_demo de uno o dos ya es significativo. Cruza con tu tabla prospects (token es la clave de join) para saber quién hizo clic, y tienes una lista diaria corta como para tratarla a mano:

• Quienes hicieron clic y no respondieron en 48h → mándales un follow-up de una línea que no mencione el clic ("¿Te encaja para {{empresa}}?"). Ya se han pre-cualificado solos.
• Quienes hicieron clic → nunca mandes el email de "breakup". Tienes prueba de interés; el breakup es para fantasmas, no para los que están leyendo en silencio.
• Promueve a "warm" en tu estado de prospect, para que la siguiente tanda les meta en una secuencia distinta.

Esto es atribución de outreach sin CRM. La stack entera es una columna en una tabla SQLite/D1, un nombre de evento en Logly, y la disciplina de mirar la lista el viernes por la mañana.

Variaciones que merece la pena mencionar

Un evento por destino. Si tu outreach enlaza a tres sitios, usa or_demo, or_pricing, or_docs. Mismo patrón de redirect, evento distinto en cada landing. El panel los rankea y descubres qué gancho quieren tus prospectos.

No midas aperturas. El tracking por pixel para opens es tentador y mayormente ruido: Apple Mail Privacy Protection precarga las imágenes, las pasarelas de seguridad pre-clican los enlaces, y "abrió" no te acerca a "interesado". Además te empuja la entregabilidad en la mala dirección. Los clics son la primera señal que merece la pena optimizar; las aperturas no.

Rotación de tokens. Si reenvías al mismo prospecto, genera un token nuevo. Mantiene visited_at honesto como timestamp de primer toque por campaña en lugar de por vida.

Un redirect, un evento, una columna

Esa es la stack entera de analítica para outreach que necesitas hasta que tengas más prospectos de los que puedes leer en una sola sentada. Cuando cruces ese umbral, el siguiente paso no es un CRM — es encadenar or_demo con signup_started y signup_completed en un embudo, para ver en qué paso se enfrían tus clickers calientes.