Skip to main content
Les pannes réseau et les erreurs serveur passagères arrivent. L’API des événements serveur est conçue pour que les relances soient sans danger, à condition de suivre le principe de l’event_id.

Le fonctionnement de l’idempotence

Chaque événement accepte un champ event_id. Lorsque le même event_id arrive plusieurs fois, le traitement marque la deuxième occurrence comme doublon et l’exclut des analyses. Vos totaux de conversions restent justes, même si vous relancez une requête plusieurs fois. La règle : générez l’event_id une seule fois, avant la première tentative, et réutilisez la même valeur à chaque relance de cet événement.

Schéma de mise en œuvre

Rythme des relances

Plafonnez le délai à 30–60 secondes. Après 5 tentatives infructueuses, enregistrez l’événement et déclenchez une alerte — ne relancez pas indéfiniment.

Quand relancer, quand arrêter

Conserver event_id pour les événements critiques

Pour les conversions à forte valeur (achats, abonnements), générez et enregistrez l’event_id avant l’appel réseau — vous pourrez ainsi relancer même après un redémarrage du processus :