Suivez les clics de vos emails d'outreach vers la démo avec un seul événement personnalisé

Vous envoyez dix emails à froid un mardi. Deux réponses arrivent, le reste est silencieux. La vraie question n'est pas votre taux d'ouverture — c'est lesquels des huit autres prospects ont cliqué jusqu'à la démo sans rien dire. Voici le setup le plus simple qui y répond proprement : un redirect sur votre propre domaine, un événement personnalisé dans Logly, cinq lignes de JavaScript.

Pourquoi le tracking de pages générique rate l'outreach

Une vue de la page démo est un signal grossier. Le tracker de pageviews par défaut voit trois événements identiques :

• Vous, connecté, en train de tester la page depuis le Wi-Fi d'un hôtel.
• Un visiteur aléatoire qui a cliqué sur un tweet à propos de votre lancement.
• Le CTO d'une SaaS de 30 personnes que vous avez emailé hier soir et qui lit votre hero en ce moment.

Seul le troisième mérite un follow-up à 9 h demain. Tant que vous ne séparez pas ce trafic, chaque "vues de la démo : 47" est du bruit déguisé en métrique. On veut isoler le clic venu de l'outreach pour pouvoir agir dessus — relancer, déprioriser, passer en "warm" — et ignorer le reste.

L'architecture minimale : un redirect, un événement

Imaginez que vous gérez une petite SaaS appelée Inboxly et que vous envoyez environ 10 emails à froid par jour. Chaque prospect reçoit un token court unique quand vous le mettez en file.

L'email contient un seul lien :

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

Cet endpoint vit sur votre propre domaine, dans votre propre Worker (ou Express, ou Flask — ce que vous avez déjà). Il fait deux choses et se retire :

// /c/:token  — handler 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
  );
}

Le COALESCE est la seule ligne maligne : on n'inscrit visited_at que la première fois, donc des clics répétés du même prospect n'écrasent pas le timestamp de first-touch. Le 302 les envoie vers la vraie URL de démo avec un paramètre ref que le frontend peut lire.

Sur la page démo, on déclenche l'événement uniquement si le ref correspond au nôtre :

<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>

C'est tout le pipeline. Le statut du prospect passe à "visited" dans votre DB. La cadence agrégée des clics apparaît dans le panneau d'événements de Logly sous le nom or_demo.

Pourquoi un événement personnalisé bat le tracking par UTM seul

Les UTM sont bien pour tagger une campagne ponctuelle, mais ils s'effondrent comme attribution d'outreach de trois manières prévisibles :

• Ils disparaissent au deuxième clic. Le prospect arrive sur /demo?utm_source=outreach, clique "Pricing", et l'UTM a disparu. Toute conversion plus loin dans le funnel ressemble à du trafic organique.
• Ils polluent les rapports de sources. Vous vous retrouvez avec outreach, outreach2, outreach_q2, et un outreach- mal tapé parce que vous étiez fatigué.
• Ils ne survivent pas proprement à un redirect côté serveur. Soit vous les perdez, soit vous les recollez sur l'URL de destination et vous finissez par réinventer exactement ce qu'un événement nommé fait déjà.

Un événement personnalisé est un signal nommé unique qui survit le reste de la session. Le nom (or_demo) est la clé de join avec votre propre DB si vous voulez creuser. Le panneau d'événements regroupe par nom, pas par un paramètre qu'il faut penser à nettoyer.

Garder le signal propre

La façon la plus rapide de ruiner cette métrique est de vous compter vous-même. Deux petites disciplines règlent ça :

<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>

Le chargement conditionnel garde p.js hors des sessions internes : pas d'événement, pas de pageview, pas de biais. Combiné au check du ref, la seule chose qui peut produire un événement or_demo est un vrai prospect cliquant sur un vrai lien d'outreach.

Quoi faire des données

Ouvrez le dashboard Logly, filtrez Événements → or_demo, et vous verrez la cadence des clics après chaque vague d'envois. Le volume est petit exprès — dix emails par jour signifie qu'un or_demo à un ou deux est déjà significatif. Croisez avec votre table prospects (token est la clé de join) pour savoir qui a cliqué, et vous avez une liste quotidienne assez courte pour être traitée à la main :

• Cliqueurs sans réponse à 48h → envoyez un follow-up d'une ligne qui ne mentionne pas le clic ("Est-ce que ça vous parle pour {{entreprise}} ?"). Ils se sont déjà pré-qualifiés.
• Cliqueurs → n'envoyez jamais l'email de "breakup". Vous avez une preuve d'intérêt ; le breakup est pour les fantômes, pas pour les lecteurs silencieux.
• Passez-les en "warm" dans votre statut de prospect, pour que la prochaine vague les place dans une séquence différente.

C'est de l'attribution d'outreach sans CRM. Toute la stack tient en une colonne dans une table SQLite/D1, un nom d'événement dans Logly, et la discipline de regarder la liste le vendredi matin.

Variantes à connaître

Un événement par destination. Si votre outreach pointe vers trois pages, utilisez or_demo, or_pricing, or_docs. Même pattern de redirect, événement différent sur chaque page. Le panneau les classera et vous apprendrez quel hook vos prospects veulent vraiment.

Ne suivez pas les ouvertures. Le tracking par pixel pour les opens est tentant et c'est surtout du bruit : Apple Mail Privacy Protection précharge les images, les passerelles de sécurité pré-cliquent les liens, et "ouvert" ne vous rapproche pas de "intéressé". Ça pousse aussi votre délivrabilité dans la mauvaise direction. Les clics sont le premier signal à optimiser ; les ouvertures, non.

Rotation des tokens. Si vous renvoyez au même prospect, générez un nouveau token. Ça garde visited_at honnête comme timestamp de premier contact par campagne plutôt que par vie.

Un redirect, un événement, une colonne

C'est toute la stack analytics dont vous avez besoin pour l'outreach jusqu'à ce que vous ayez plus de prospects que vous ne pouvez en lire en une seule fois. Quand vous franchirez ce seuil, l'étape suivante n'est pas un CRM — c'est d'enchaîner or_demo avec signup_started et signup_completed dans un funnel, pour voir à quelle étape vos cliqueurs chauds se refroidissent.