0 % des événements métier perdus, contre une perte estimée entre 15 et 30 % côté navigateur selon les études sur l’usage des bloqueurs de publicités et de trackers : c’est l’écart qui justifie de faire remonter certains événements business directement depuis le serveur WordPress plutôt que depuis le script JavaScript embarqué dans le navigateur du visiteur.
Segment propose une bibliothèque client classique (analytics.js), largement utilisée pour tracker les vues de page et les interactions front-end. Mais pour des événements qui déterminent des décisions métier importantes — inscription validée, achat confirmé, changement de statut d’abonnement — s’appuyer uniquement sur un script exécuté dans le navigateur expose à une perte de données difficile à quantifier a posteriori.
Pourquoi le tracking client ne suffit pas pour les événements critiques
Un bloqueur de publicités, une extension de confidentialité, ou simplement un utilisateur qui ferme l’onglet avant l’exécution complète du script de tracking : toutes ces situations font disparaître un événement sans que personne ne s’en aperçoive côté analytics, alors même que l’action métier — l’inscription, l’achat — a bien eu lieu côté serveur. Pour une entreprise qui pilote ses décisions produit sur ces chiffres, cet écart silencieux peut fausser des arbitrages entiers.
Le tracking côté serveur contourne ce problème par construction : l’événement est envoyé directement depuis le code PHP qui traite la commande ou l’inscription, sans dépendre du navigateur du visiteur ni de ce qu’il choisit d’y bloquer.
Utiliser l’API HTTP Tracking de Segment
Segment expose une API HTTP dédiée au tracking serveur à serveur, authentifiée par la clé d’écriture (write key) de la source configurée dans l’espace Segment. L’appel se fait simplement via wp_remote_post() :
Envoyer un événement « Commande confirmée »
function boutique_tracker_evenement_serveur( $utilisateur_id, $nom_evenement, $proprietes ) {
$reponse = wp_remote_post( 'https://api.segment.io/v1/track', array(
'headers' => array(
'Authorization' => 'Basic ' . base64_encode( SEGMENT_WRITE_KEY . ':' ),
'Content-Type' => 'application/json',
),
'body' => wp_json_encode( array(
'userId' => (string) $utilisateur_id,
'event' => $nom_evenement,
'properties' => $proprietes,
'timestamp' => gmdate( 'c' ),
) ),
'timeout' => 5,
) );
if ( is_wp_error( $reponse ) ) {
error_log( 'Segment indisponible : ' . $reponse->get_error_message() );
}
}
add_action( 'boutique_commande_confirmee', function ( $commande ) {
boutique_tracker_evenement_serveur(
$commande->get_customer_id(),
'Order Completed',
array(
'order_id' => $commande->get_id(),
'total' => $commande->get_total(),
'currency' => 'EUR',
)
);
} );Le nom d’événement Order Completed suit la convention Segment Spec pour l’e-commerce, ce qui permet de bénéficier directement des intégrations préconstruites vers les outils en aval (entrepôt de données, outil de visualisation) sans mapping supplémentaire.
Fiabiliser l’identifiant utilisateur entre client et serveur
Le point le plus délicat de cette architecture n’est pas l’envoi de l’événement, mais la cohérence de l’identifiant utilisateur entre les événements envoyés côté client (avant connexion, par exemple lors d’une visite anonyme) et ceux envoyés côté serveur une fois l’utilisateur identifié. Sans réconciliation, Segment traite ces événements comme provenant de deux profils distincts, ce qui casse tout le parcours d’analyse.
- Un identifiant anonyme (
anonymousId) est généré côté client dès la première visite et stocké en cookie. - Au moment de l’inscription ou de la connexion, un appel
identifyrelie cet identifiant anonyme à l’identifiant utilisateur WordPress. - Tous les événements serveur suivants utilisent systématiquement cet identifiant utilisateur stable, jamais un identifiant de session temporaire.
Traiter les échecs d’envoi sans bloquer la commande
L’appel à Segment ne doit jamais retarder ni faire échouer le traitement métier principal. Il est déclenché après la confirmation effective de la commande, de façon asynchrone si possible via Action Scheduler, avec un simple enregistrement en log en cas d’échec plutôt qu’une nouvelle tentative bloquante immédiate :
Un événement analytics perdu est regrettable ; une commande bloquée parce qu’un service tiers de tracking est indisponible est inacceptable.
En résumé
Le tracking côté serveur ne remplace pas le tracking côté client : les deux sont complémentaires, le premier garantissant la fiabilité des événements métier critiques, le second couvrant les interactions purement comportementales (défilement de page, survol, clics d’interface). Pour toute décision qui s’appuie sur des chiffres de conversion ou de revenu, faire remonter l’événement depuis le serveur reste la seule garantie de ne pas piloter une entreprise sur des données amputées par un bloqueur de publicités.
