# Segment côté serveur : tracker des événements métier depuis une extension

> Envoyer les événements métier (inscription, achat) vers Segment directement depuis le serveur WordPress, pour ne plus dépendre d'un script client bloquable.

- Auteur : WordPress Développement
- Publié le : 2021-12-26
- Mis à jour le : 2021-12-26
- Catégorie : Extensions
- URL : https://www.wpmoderne.fr/extensions/tracker-evenements-metier-cote-serveur-segment/

## L’essentiel

- L'API HTTP Tracking de Segment accepte des appels serveur à serveur
- Un événement serveur n'est jamais bloqué par un bloqueur de publicités
- Chaque événement doit porter un identifiant utilisateur stable et cohérent

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()` :

> L'essentiel à retenir : L'API HTTP Tracking de Segment accepte des appels serveur à serveur ; Un événement serveur n'est jamais bloqué par un bloqueur de publicités ; Chaque événement doit porter un identifiant utilisateur stable et cohérent

## 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 `identify` relie 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.