Quelle est la différence en une phrase ?
Le tracking côté client voit le contexte ; le tracking côté serveur voit la vérité. Le navigateur connaît les paramètres UTM, le referrer, l'appareil et la page — et perd des événements à cause des bloqueurs. Votre back end sait ce qui s'est réellement passé — un abonnement démarré, un paiement échoué — et ignore tout du chemin qui a mené l'utilisateur jusque-là. Ce guide traite d'une seule question : où instrumenter. Pour savoir quoi suivre — le nommage et la liste d'événements de départ — voyez le plan de tracking pour startups ; pour comprendre pourquoi la donnée doit être first-party tout court, voyez données first-party et tracking. Les deux moitiés tiennent dans un seul plan de tracking.
Que voit le tracking côté client — et que rate-t-il ?
Le côté client, c'est là que vit le contexte. Le SDK dans le navigateur capture les paramètres UTM, le referrer, la page d'atterrissage, l'appareil et le comportement de session — tout ce dont l'attribution et l'analyse de funnel ont besoin. Ce qu'il rate, ce sont des utilisateurs entiers : d'après les données GWI agrégées par Backlinko, 29,5 % des internautes dans le monde utilisaient un bloqueur de publicité au moins occasionnellement au deuxième trimestre 2025 — environ 1,77 milliard de personnes. Beaucoup de bloqueurs stoppent les scripts d'analytics avec les publicités : une part mesurable de vos événements côté client n'est jamais envoyée.
Même sans bloqueur, Safari rend la mesure lacunaire. D'après la documentation ITP de WebKit, Safari plafonne l'expiration des cookies posés en JavaScript à sept jours et supprime tout le reste du stockage accessible aux scripts — localStorage, IndexedDB — après sept jours d'utilisation de Safari sans interaction avec votre site. Passée cette fenêtre de sept jours d'utilisation, un visiteur qui revient paraît nouveau, et l'identité se brise. La perte se mesure : quand Plausible a comparé ses propres chiffres à ceux de Google Analytics sur un site en tendance sur Hacker News et Reddit, lors d'un test fin août 2021, Google Analytics a manqué 58,67 % des visiteurs — un cas extrême, très tech ; Plausible cite des travaux antérieurs situant le blocage sous les 10 % sur les sites lifestyle et au-delà de 25 % sur les sites orientés tech.
Que voit le tracking côté serveur — et que rate-t-il ?
Le tracking côté serveur, c'est votre back end qui rapporte les changements d'état à l'API d'événements : subscription_started, payment_failed, plan_changed. Ces événements se produisent sur vos serveurs, pas dans le navigateur — les enregistrer là n'est pas un contournement, c'est la source honnête. Aucun bloqueur sur le chemin, aucun plafond de stockage qui les efface, et le décompte colle à votre base de données parce qu'il en vient. Un événement côté serveur fait foi parce qu'il enregistre ce que votre système a fait, pas ce qu'un navigateur a réussi à rapporter. L'angle mort, c'est le contexte : votre back end ignore quelle campagne, quel referrer ou quel appareil a amené l'utilisateur — ce contexte n'a jamais existé que côté client.
Client vs serveur : quels événements vont où ?
| Classe d'événement | Où l'instrumenter | Pourquoi |
|---|---|---|
| Pages vues & attribution de campagne | Client | UTM, referrer et page d'atterrissage n'existent que dans le navigateur. |
| Usage des fonctionnalités produit | Client (serveur aussi si critique) | Le contexte UI compte ; doublez côté serveur quand une métrique en dépend. |
| Inscription & connexion | Les deux | Le point de jonction d'identité — le même identifiant utilisateur des deux côtés. |
| Revenu & état d'abonnement | Serveur | Les événements d'argent naissent dans votre back end ; le décompte doit coller à votre base. |
| Événements e-mail, webhook & intégrations | Serveur | Ils arrivent par webhooks de vos prestataires — rien à capturer côté client. |
Comment une petite équipe répartit-elle les événements ?
- Tout ce qui touche l'argent — essais, abonnements, paiements, remboursements — part côté serveur. Quand le churn ou le MRR doit être juste, le serveur est la source de vérité.
- Tout ce qui touche l'attribution — pages vues, campagnes, referrers — reste côté client. Ce contexte ne se reconstruit pas après coup.
- Identifiez sur les deux chemins avec le même identifiant utilisateur : les funnels se recollent et les tests A/B à faible trafic assignent chaque utilisateur à une seule variante, d'un appareil à l'autre.
- Acceptez l'écart. Les chiffres client sous-comptent par construction ; servez-vous-en pour la direction, et des événements serveur pour tout ce que vous publiez.
Pourquoi les deux chiffres ne collent-ils jamais ?
Faites tourner les deux et les décomptes divergeront — en permanence. Le chiffre client sous-compte parce que bloqueurs et ITP mangent des événements ; le chiffre serveur n'a pas le contexte pour dire d'où viennent les utilisateurs. Ce n'est pas un bug à corriger mais une propriété à nommer : attendez-vous à un écart persistant entre l'analytics client et la vérité serveur, connaissez son ordre de grandeur pour votre audience, et cessez de le pourchasser. Publiez chaque chiffre depuis son côté honnête — l'attribution et la direction du funnel depuis les données client ; tout ce qui atteint un rapport investisseurs ou une facture — taux de churn, MRR, abonnements actifs — calculé sur les événements serveur. Les plateformes d'engagement comme Iterable et Ortto acceptent les deux sources pour cette raison.
Comment fromHello gère-t-il la question ?
fromHello fait de cette répartition le comportement par défaut. Le SDK JS/TS suit les événements côté client et tient une file d'attente hors ligne adossée au localStorage — les événements déclenchés pendant une coupure persistent et sont renvoyés quand le navigateur repasse en ligne — tandis que la même API d'événements accepte les envois côté serveur : subscription_started arrive tout droit de votre back end, avec une clé d'API. Les deux chemins écrivent sur un seul profil : l'attribution capturée par le SDK et les événements de revenu envoyés par votre serveur décrivent la même personne. Segments, parcours et analytics lisent ce profil unique — vous scindez l'instrumentation, pas l'identité.