Sylius 2 : tracking et conversions seront-ils conservés ?

Pas automatiquement. Le tracking de votre boutique, balise Google Analytics, pixel Meta, événements d'ajout au panier et d'achat, ne fait pas partie de Sylius : il a été ajouté dans vos gabarits et vos scripts. Or Sylius 2 réécrit toute la boutique sur Twig Hooks et Symfony UX. Sans reprise, la plupart de ces mesures disparaissent sans aucune erreur visible. Avec un plan de marquage relevé avant le chantier et testé sur la préproduction, elles sont conservées à l'identique, historique compris.

Je suis développeur Sylius indépendant et j'ai mené des montées de version 1.x vers 2.x de boutiques en production. Le tracking est le poste que les dirigeants oublient le plus souvent dans leur cahier des charges, parce qu'il fonctionne depuis des années sans qu'on y pense. C'est aussi le premier qui se voit dans les chiffres, quand les ventes semblent s'effondrer dans les tableaux de bord alors que les commandes arrivent normalement.

Pourquoi le tracking ne suit-il pas tout seul la migration ?

Parce qu'il est accroché à l'interface, et que l'interface est la partie la plus réécrite. Le guide officiel UPGRADE-2.0 remplace Semantic UI et jQuery par Bootstrap 5 et Symfony UX, supprime les template events et Sonata Block, et organise désormais la boutique en Twig Hooks. En 1.x, les balises étaient souvent injectées par l'événement sylius.shop.layout.head ou dans un gabarit principal surchargé. En Sylius 2, ce gabarit n'est plus appelé et cet événement n'existe plus. La page s'affiche, la balise est absente, et aucun test fonctionnel ne le signale.

Votre historique, lui, ne craint rien : il est stocké dans Google Analytics et chez Meta. Ce qui est en jeu, ce sont les données qui suivent la bascule, et donc les décisions que vous prendrez avec.

Où le suivi des conversions casse-t-il concrètement ?

La balise de base dans le gabarit

Le gabarit de base de la boutique Sylius 2 propose un hook head dans l'en-tête de la page. C'est là que la balise Google ou le gestionnaire de balises se rebranchent proprement. La reprise est simple, encore faut-il savoir que la balise était là et sous quelle forme.

L'ajout au panier

En Sylius 2, le formulaire d'ajout au panier est un composant dynamique de Symfony UX, et les routes Ajax du panier de la 1.x, comme sylius_shop_ajax_cart_add_item, sont supprimées. Un script qui écoutait l'ancien appel jQuery pour envoyer l'événement add_to_cart ne se déclenche plus. Il faut le réécrire en s'appuyant sur le nouveau composant.

La page de confirmation de commande

La page de remerciement reste à l'adresse /order/thank-you, comme le montre le routage officiel des commandes. Un objectif Google Ads basé sur cette adresse continue donc de fonctionner. En revanche, son contenu est désormais rendu par un hook thank_you : le bloc qui envoyait l'événement purchase avec le montant et les produits doit y être reporté. Les événements e-commerce recommandés par Google Analytics restent les mêmes, ce qui facilite la comparaison avant et après.

Le tracking côté serveur

Certaines boutiques envoient l'achat depuis le serveur, au moment où le paiement passe à l'état payé, vers la Conversions API de Meta ou le Measurement Protocol de Google. En 1.x, ce code est souvent un callback de winzou/state-machine. Sylius 2 utilise Symfony Workflow par défaut : ces callbacks sont à réécrire, sujet traité dans l'article sur winzou et Symfony Workflow. Les paiements passent aussi par les Payment Requests, et la route de retour après paiement accepte désormais un paramètre supplémentaire : tout ce qui se déclenchait au retour du prestataire est à retester, comme je l'explique dans l'article sur les moyens de paiement.

Si vous ne savez pas où se trouvent vos balises, ce n'est pas un problème : c'est le premier livrable du diagnostic offert de migration Sylius 2. Sylius Upgrade Analyzer, l'outil que j'ai créé et publié sur le Sylius Store, signale les template events et les gabarits surchargés à reprendre, et je complète à la main par la lecture des scripts.

Comment éviter les doublons et les trous de mesure ?

Deux défauts reviennent après une reprise de tracking : l'achat compté deux fois, et l'achat pas compté du tout. Le premier se prévient avec l'identifiant de commande. Google Analytics dédoublonne les achats qui portent le même identifiant de transaction : j'envoie donc toujours le numéro de commande Sylius, jamais une valeur vide ou fixe. Côté Meta, quand le pixel et la Conversions API envoient le même achat, la déduplication repose sur un nom et un identifiant d'événement identiques des deux côtés.

Le second défaut, l'achat manquant, vient presque toujours du consentement ou d'un script qui ne se charge pas sur une étape du tunnel. Si votre bandeau de cookies est un plugin Sylius, il doit exister en version compatible Sylius 2, faute de quoi les balises qui attendent le consentement ne partent jamais. La vérification des plugins est détaillée dans la méthode pour vérifier et remplacer les plugins.

Comment tester le tracking avant la bascule ?

Je pars d'un plan de marquage écrit : chaque événement, la page ou l'action qui le déclenche, les données qu'il transporte. Ce document s'établit sur la boutique 1.14 en production, avant tout développement. Sur la préproduction Sylius 2, je rejoue chaque parcours : consultation d'un produit, ajout au panier, début de commande, choix de la livraison et du paiement, achat. Chaque événement est vérifié dans les outils de débogage de Google Analytics et de Meta, avec le bon montant, la bonne devise et le bon identifiant.

Après la bascule, le contrôle se fait par rapprochement. Chaque jour pendant les premières semaines, je compare le nombre de commandes enregistrées dans l'administration Sylius avec le nombre d'achats remontés dans Google Analytics et chez Meta. Un écart a toujours existé, à cause des bloqueurs et des refus de cookies. Ce qui compte, c'est qu'il reste du même ordre qu'avant la migration. Un écart qui se creuse brutalement désigne une balise oubliée. Les conséquences pour vos annonces sont traitées dans l'article sur les campagnes Google Ads et Meta Ads.

Ce que je vous propose

Sylius 1.14 ne reçoit plus de correctifs de sécurité après le 31 décembre 2026. Relever votre plan de marquage maintenant, pendant que la boutique 1.14 fonctionne, est la seule façon de pouvoir comparer ensuite. Demandez le diagnostic de migration offert : je passe votre projet à l'analyseur, je repère où vivent vos balises et vos événements, et je vous remets une estimation en jours qui inclut leur reprise.