# Segment sur un site multilingue : un événement, plusieurs langues, une vérité

> Sans paramétrage dédié, les tableaux de bord issus de Segment faussent souvent les comparaisons entre langues d'un même site, en confondant langue et contenu.

- Auteur : WordPress Développement
- Publié le : 2024-03-01
- Mis à jour le : 2024-03-01
- Catégorie : Multilingue
- URL : https://www.wpmoderne.fr/multilingue/segment-multilingue-tracking-langue-contenu/

## L’essentiel

- Un même événement doit porter la langue en propriété, pas dans son nom
- Confondre langue et contenu casse les comparaisons de conversion
- Un plan de tracking documenté évite la dérive entre développeurs

« Pourquoi le taux de conversion de la version allemande semble deux fois plus bas que la version française dans nos tableaux Segment ? » Cette question, posée par une équipe data lors d'une revue mensuelle, cachait un problème de tracking, pas un problème de performance produit réel. En creusant, l'événement `Bouton Ajouter au panier cliqué` avait été implémenté trois fois par trois développeurs différents, à des moments différents, chacun avec un nom d'événement légèrement différent selon la langue de la page où il avait travaillé en premier : `Add to cart clicked`, `Ajout panier`, et `Warenkorb Klick`.

Ce sujet ne traite pas de Google Analytics, déjà couvert par la catégorie SEO : il porte spécifiquement sur la manière de structurer les événements Segment sur un site WordPress multilingue pour que les comparaisons entre langues restent fiables, un piège de tracking qui touche n'importe quel outil de collecte d'événements construit sur le même principe.

## Le piège : la langue s'infiltre dans le nom de l'événement

Le problème de fond est presque toujours le même : au lieu de considérer la langue comme une propriété de l'événement (une donnée contextuelle attachée), les développeurs successifs l'ont laissée s'infiltrer dans le nom même de l'événement, souvent sans s'en rendre compte, simplement parce que chacun a codé le nom de l'événement en dur dans la langue du contenu qu'il avait sous les yeux au moment de l'implémentation. Segment, comme la plupart des outils de tracking par événements, traite deux noms différents comme deux événements totalement distincts dans ses rapports, ce qui rend impossible une agrégation correcte sans retraitement manuel des données a posteriori.

## La bonne structure : un nom fixe, une propriété de langue

> L'essentiel à retenir : Un même événement doit porter la langue en propriété, pas dans son nom ; Confondre langue et contenu casse les comparaisons de conversion ; Un plan de tracking documenté évite la dérive entre développeurs

La règle à appliquer systématiquement consiste à figer le nom de l'événement en anglais technique, indépendamment de la langue affichée au visiteur, et à transmettre la langue comme une propriété explicite de l'événement :

```
<?php
$current_lang = function_exists( 'pll_current_language' ) ? pll_current_language() : 'fr';
?>
<script>
document.querySelector('.add-to-cart').addEventListener('click', function() {
  analytics.track('Add to Cart Clicked', {
    product_id: '<?php echo esc_js( $product_id ); ?>',
    language: '<?php echo esc_js( $current_lang ); ?>',
    currency: '<?php echo esc_js( $currency ); ?>'
  });
});
</script>
```

Avec cette structure, un seul événement `Add to Cart Clicked` regroupe tous les clics toutes langues confondues, et la propriété `language` permet de segmenter les rapports à volonté, par langue, sans jamais fragmenter artificiellement l'événement en plusieurs entités distinctes selon qui l'a implémenté et dans quel contexte.

## Documenter un plan de tracking avant de coder

La solution durable n'est pas seulement technique, elle est organisationnelle : un plan de tracking documenté, partagé entre toutes les personnes qui implémentent des événements Segment sur le site, fixe une bonne fois pour toutes le nom exact de chaque événement et la liste de ses propriétés attendues, y compris la propriété de langue. Ce document, souvent un simple tableau partagé, évite qu'un nouveau développeur ne réinvente un nom d'événement légèrement différent pour un comportement déjà tracké ailleurs.

| Événement | Propriétés attendues | Déclencheur |
| --- | --- | --- |
| Add to Cart Clicked | product_id, language, currency | Clic sur le bouton d'ajout au panier |
| Checkout Started | cart_value, language, item_count | Accès à la page de commande |
| Language Switched | from_language, to_language, page_type | Clic sur le sélecteur de langue |

### Un événement dédié au changement de langue lui-même

Au-delà de la propriété de langue attachée à chaque événement métier, un événement spécifique qui capture le changement de langue en lui-même (`Language Switched`) apporte une information précieuse rarement collectée : combien de visiteurs changent de langue en cours de navigation, depuis quelle langue vers quelle langue, et sur quel type de page. Cette donnée aide à identifier si le choix de langue par défaut (détection navigateur ou géolocalisation) est réellement pertinent pour l'audience du site.

## Corriger l'historique existant, ou l'accepter comme tel

Sur un site où le problème est déjà installé depuis des mois, deux options existent. La première consiste à renommer rétroactivement les événements historiques dans l'entrepôt de données en aval (souvent via une table de correspondance dans l'outil d'analyse de données connecté à Segment), ce qui demande une intervention data plus lourde. La seconde, plus pragmatique à court terme, consiste à corriger uniquement l'implémentation à partir d'une date donnée et à documenter clairement, dans les rapports, la rupture de série pour éviter toute comparaison erronée entre l'avant et l'après correctif.

- Ne jamais coder un nom d'événement dans la langue affichée au visiteur
- Toujours transmettre la langue comme propriété d'événement, jamais dans son nom
- Documenter un plan de tracking partagé avant toute nouvelle implémentation
- Ajouter un événement dédié au changement de langue pour mesurer sa fréquence réelle

## En résumé

Un tableau de bord qui semble révéler une mauvaise performance d'une langue cache parfois, en réalité, un défaut de structuration du tracking. Sur un site multilingue, traiter la langue comme une propriété d'événement plutôt que comme une variante de son nom est la règle la plus simple à appliquer et la plus coûteuse à corriger après coup si elle est oubliée dès le départ.