Astro et Umami : suivre les clics sans alourdir son site

Dernièrement, j’ai écrit un petit article de présentation et d’installation rapide d’Umami. J’en avais marre d’alourdir mes sites avec des plugins ou la couche Google Analytics.

Mais vous vous en doutez : Umami, quand il ne remonte que les visites, c’est très bien pour une vision d’ensemble. Par contre, on a parfois besoin d’un peu plus de précision pour voir si son contenu est vraiment exploité.

Quand on ajoute des statistiques sur un site, on pense souvent aux pages vues. Là, j’avais besoin de plus d’informations pour mieux comprendre ce que je dois améliorer et ce qui est réellement consulté :

• ➡️ est-ce que les lecteurs cliquent sur le bouton de partage LinkedIn ?
• ➡️ est-ce qu’ils copient le lien de l’article ?
• ➡️ est-ce qu’ils utilisent les boutons de retour, les liens externes ou le sommaire ?
• ➡️ est-ce qu’un formulaire fonctionne vraiment côté utilisateur ?

Grâce aux événements personnalisés Umami, on peut suivre ces interactions sans transformer le site en usine à gaz. L’idée n’est pas de tout mesurer. L’idée est de donner un nom clair aux actions qui comptent.

Pourquoi suivre les boutons ?

Une page vue répond à une question simple : la page a-t-elle été consultée ?

Un événement répond à une question un peu plus fine : qu’est-ce que la personne a fait sur la page ?

Pour un article, cela peut vite devenir très intéressant. Si un bouton de partage n’est jamais utilisé, on peut se poser plusieurs questions. Si le bouton LinkedIn fonctionne bien, il mérite peut-être d’être mieux mis en avant. Si la copie du lien est plus utilisée que le partage sur les réseaux sociaux, cela indique que les lecteurs préfèrent partager l’article de manière directe. Si aucun bouton de partage n’est utilisé, cela peut aussi suggérer que l’article n’est pas suffisamment intéressant ou engageant pour donner envie d’être partagé.

Ce type de suivi reste léger, mais il permet tout de même de dégager des tendances pertinentes.

Astro + Umami

Astro génère des pages très rapides, souvent statiques. C’est parfait pour un blog, mais ça veut dire qu’il faut réfléchir à la manière d’ajouter du JavaScript.

Umami, lui, fonctionne avec un script de tracking chargé côté navigateur. Une fois le script présent sur la page, il peut recevoir :

• ➡️ les pages vues ;
• ➡️ les événements personnalisés ;
• ➡️ des propriétés associées à chaque événement.

La cohabitation est donc assez naturelle :

Astro rend la page
       -> le script Umami est chargé
       -> un clic utilisateur déclenche un événement
       -> Umami reçoit un nom d'événement + quelques données utiles

Exemple concret : les boutons de partage

Sur un article, on peut avoir deux boutons qui semblent proches :

• ➡️ partager sur LinkedIn ;
• ➡️ copier le lien de l’article.

Visuellement, ce sont deux actions de partage. Mais côté analytics, ce ne sont pas les mêmes comportements.

Le clic LinkedIn envoie le lecteur vers une plateforme externe. La copie du lien reste dans le navigateur et sert souvent à partager ailleurs : messagerie, documentation interne, Slack, Teams, mail, etc.

Je préfère donc les suivre séparément.

<a
  href={shareLinks.linkedin}
  target="_blank"
  rel="noopener noreferrer"
  aria-label="Share on LinkedIn"
  data-umami-disable-outbound
  data-umami-event="article_share_click"
  data-umami-event-label="Partager l'article sur LinkedIn"
  data-umami-event-action="click"
  data-umami-event-provider="linkedin"
  data-umami-event-share-type="linkedin"
  data-umami-event-article-title={title}
  data-umami-event-article-url={url}
>
  LinkedIn
</a>

Pour le bouton qui copie le lien :

<button
  type="button"
  aria-label="Copy link"
  data-url={url}
  data-umami-event="article_share_copy"
  data-umami-event-label="Copier le lien de partage de l'article"
  data-umami-event-action="copy"
  data-umami-event-provider="copy-link"
  data-umami-event-share-type="copy-link"
  data-umami-event-article-title={title}
  data-umami-event-article-url={url}
>
  Copier le lien
</button>

La différence est volontaire :

• ➡️ article_share_click pour le clic vers LinkedIn ;
• ➡️ article_share_copy pour la copie du lien ;
• ➡️ provider pour savoir quel canal est concerné ;
• ➡️ share_type pour filtrer facilement les modes de partage ;
• ➡️ label pour avoir un intitulé lisible dans Umami.

Le petit détail qui compte ici, c’est data-umami-disable-outbound sur LinkedIn. Sans ça, le clic peut être compté à la fois comme événement de partage et comme lien sortant générique. Ce n’est pas dramatique, mais ça brouille la lecture.

Un helper global pour éviter de répéter du JavaScript

Dans mon cas, je préfère centraliser la logique Umami dans un composant de layout.

L’idée est simple : si un élément possède data-umami-event, le clic est automatiquement capturé. Les autres attributs data-umami-event-* deviennent des propriétés de l’événement.

Exemple :

data-umami-event-provider="linkedin"

devient côté événement :

{
  "provider": "linkedin"
}

Et :

data-umami-event-article-title="Mon article"

devient :

{
  "article_title": "Mon article"
}

Cette approche garde les composants Astro assez lisibles. On décrit le tracking directement sur le bouton, sans ajouter un gestionnaire de clic spécifique partout.

Côté intégration Astro, j’ai gardé les responsabilités séparées dans des fichiers .astro dédiés :

• ➡️ Analytics.astro charge le script Umami, avec l’ID du site et la gestion du consentement si elle est activée ;
• ➡️ UmamiEvents.astro écoute les interactions globales côté navigateur et transforme les attributs data-umami-event-* en propriétés envoyées à Umami ;
• ➡️ ArticleUmamiEvents.astro ajoute le suivi propre aux articles, comme les paliers de lecture article_read_25, article_read_50, article_read_75 et article_read_100.

Dans le layout principal, on charge la base une seule fois :

<Analytics />
<UmamiEvents />

Puis, dans le layout des articles, on peut ajouter le suivi spécifique au contenu :

<ArticleUmamiEvents title={title} url={fullUrl} />

Le reste du site n’a plus besoin de connaître toute la logique JavaScript. Les composants comme les boutons de partage restent simples : ils portent seulement les attributs nécessaires au tracking.

Nommer ses événements proprement

Le plus dur dans le tracking n’est pas la technique. C’est souvent le nommage.

Quelques règles simples aident beaucoup :

• ➡️ commencer par le contexte : article, site, contact, newsletter ;
• ➡️ ajouter l’action : share, copy, submit, click ;
• ➡️ rester stable dans le temps ;
• ➡️ éviter les noms trop génériques comme button_click ;
• ➡️ ajouter un label lisible pour l’humain.

Par exemple :

article_share_click
article_share_copy
article_feedback_vote
back_to_articles_click
outbound_link_click

Ce n’est pas plus long à écrire, et c’est beaucoup plus agréable à lire ensuite dans Umami.

Exploiter le retour dans Umami

Petit tour rapide des informations qui remontent dans la partie Site > Événements. Le journal d’activité permet de voir les pages consultées, mais aussi les événements déclenchés par les visiteurs.

Et après, nous avons l’onglet Propriétés, qui permet un filtrage beaucoup plus fin, par exemple en affichant uniquement les événements liés au bouton de partage LinkedIn.

Conclusion

Astro et Umami cohabitent très bien quand on garde une règle simple : le site reste léger, et le tracking reste explicite.

On n’a pas besoin de mesurer tout ce qui bouge. Quelques événements bien nommés suffisent pour comprendre si les boutons servent vraiment, si les lecteurs partagent les articles, et quelles actions méritent d’être améliorées.

Pour un blog technique, c’est exactement le bon niveau de détail : assez de signal pour progresser, pas assez de bruit pour se perdre.