Si votre Snap Pixel se charge mais que PURCHASE n'apparaît jamais dans le Gestionnaire d'événements, la cause est presque toujours l'une de six : un nom d'événement en minuscules, un transaction_id manquant, le pixel absent de la vraie page de confirmation, une redirection de paiement externe qui rompt la session, un checkout sur une seule page qui réinitialise le pixel, ou des événements dédupliqués face à un flux de l'API Conversions.
Suivez-les dans cet ordre. Les trois premières expliquent l'essentiel de ce que je trouve.
Le suivi Snapchat fait l'objet de bien moins d'articles que Meta ou Google, donc quand il casse, vous êtes en grande partie livré à vous-même. Les articles existants sont souvent écrits par des entreprises qui vendent un produit de suivi, et s'arrêtent donc à « installez notre application ». Voici la séquence que je suis réellement, dans mon ordre, et pourquoi cet ordre.
D'abord : confirmer que l'événement n'arrive vraiment pas
Avant de changer quoi que ce soit, établissez si l'événement manque ou s'il est simplement retardé. Deux vérifications, soixante secondes.
Vérifiez le réseau, pas le tableau de bord. Ouvrez votre page de confirmation dans Chrome, ouvrez les DevTools (F12), allez dans l'onglet Network et filtrez sur tr.snapchat.com. Effectuez un vrai achat de test. Si vous voyez une requête partir avec votre ID de pixel et le nom de l'événement, le navigateur fait son travail et votre problème se situe en aval : rapports, déduplication ou attribution. Si rien ne part, le problème est sur la page.
L'extension de navigateur Snap Pixel Helper fait le même travail avec une interface plus conviviale, et vous dira aussi si le pixel est seulement installé. J'utilise l'onglet Network parce qu'il montre la charge utile exacte, et c'est généralement là que se trouve la réponse.
Les rapports du Gestionnaire d'événements ne sont pas instantanés. Avant de conclure qu'un événement manque, attendez quelques heures et vérifiez à nouveau. J'ai vu des gens réécrire un checkout qui fonctionnait parce qu'ils avaient regardé un tableau de bord quatre-vingt-dix secondes après une commande de test.
Les six causes, classées
Le nom de l'événement est en minuscules
Les événements standard de Snapchat sont en majuscules : PURCHASE, ADD_CART, PAGE_VIEW, START_CHECKOUT. Si vous envoyez purchase, il n'est pas reconnu comme un événement standard. Le plus sournois, c'est qu'il peut quand même se déclencher et apparaître quelque part : il ne sera simplement pas traité comme la conversion standard, et l'optimisation des campagnes et les rapports se comportent comme si rien ne s'était passé.
C'est la cause numéro un parce qu'elle produit exactement le symptôme décrit, « le pixel se déclenche mais le Gestionnaire d'événements n'affiche rien », et parce que recopier une implémentation Meta est un réflexe naturel. Meta utilise Purchase. Snapchat, non.
{
event: "Purchase",
price: 24.00,
currency: "USD"
}
{
event: "PURCHASE",
price: 24.00,
currency: "USD",
transaction_id: "1047"
}
PURCHASE. Ici, la casse n'est pas un détail esthétique.Aucun transaction_id n'est envoyé
Sans transaction_id, Snapchat ne peut pas distinguer une vraie seconde commande d'un même client qui actualise la page de confirmation. Snap documente une fenêtre de déduplication de 30 jours sur transaction_id, contre 48 heures pour client_dedup_id.
La panne fonctionne dans les deux sens, c'est pourquoi elle est si haut dans la liste. Omettez-le et les actualisations gonflent votre nombre d'achats. Envoyez une valeur qui n'est pas vraiment unique par commande (un ID de panier, de checkout ou de session) et des commandes légitimes sont fusionnées en une seule et disparaissent. Le second cas ressemble exactement à « mes événements ne se déclenchent pas ».
transaction_id diffère entre les deux et qu'il correspond au numéro de commande attribué par votre boutique.Le pixel n'est pas sur la page qui confirme réellement la commande
Presque tout le monde installe le pixel sur tout le site et suppose que la page de confirmation en hérite. Souvent, ce n'est pas le cas. Les checkouts hébergés, les pages d'état de commande et les parcours de vente additionnelle après achat sont souvent rendus en dehors du thème ou du modèle qui contient votre code de suivi.
À vérifier en particulier : si vous proposez une vente additionnelle après achat, la page où arrive le client juste après avoir payé n'est peut-être pas celle que vous considérez comme la page de remerciement.
Une redirection de paiement externe rompt la session
Quand le checkout passe la main à une passerelle externe puis renvoie le client vers une page de commande reçue, cet aller-retour peut rompre la session du navigateur dont dépend le pixel. L'achat se finalise, le client voit sa confirmation, et l'événement n'atteint jamais Snapchat, ou arrive privé des identifiants nécessaires à son attribution.
C'est le moment où une configuration uniquement navigateur ne suffit plus. Le tracking côté serveur via l'API Conversions est la solution durable, car l'événement part de votre serveur et ne dépend jamais de la survie à une redirection.
Un checkout sur une seule page réinitialise le pixel
Dans les applications monopages, si l'initialisation du pixel s'exécute à chaque affichage de page virtuel, l'état du pixel est réinitialisé à chaque fois. Les données de correspondance avancée recueillies plus tôt dans le parcours sont perdues, et l'événement d'achat arrive sans les identifiants qui le rendent utile : pauvre, mal rapproché, parfois non attribué.
L'événement se déclenche. Il ne porte simplement pas ce dont il a besoin, c'est pourquoi on le prend facilement pour « fonctionnel ».
La déduplication absorbe l'événement
Si vous faites tourner le pixel et l'API Conversions (ce que vous devriez faire), Snapchat déduplique via client_dedup_id (fenêtre de 48 heures) ou transaction_id (30 jours). Deux événements partageant un identifiant sont comptés une seule fois, par conception.
Cela devient un problème quand le navigateur et le serveur ne sont pas d'accord sur cet identifiant. Si l'association est fausse, soit vous comptez tout en double, soit vous perdez discrètement un côté. Selon Snap, les événements hors achat correspondent à client_dedup_id et les événements d'achat à transaction_id, et surtout, la valeur doit être identique sur chaque chemin qui envoie cet événement.
transaction_id reste protégé 30 jours. Sur client_dedup_id, cette protection expire au bout de 48 heures, c'est pourquoi Snap associe les achats à transaction_id et tout le reste à client_dedup_id.D'où viennent mes propres chiffres
Je n'ai pas un large échantillon de clients sur Snapchat, et je ne vais pas prétendre le contraire. Ce que j'ai, c'est une boutique que j'ai gérée de bout en bout, la mienne, où le suivi fonctionnait : c'est la seule raison pour laquelle je peux parler de ce que produit une configuration Snapchat saine.
AlphaMart : ma propre boutique, pas un client
- Dépenses publicitaires
- $1,452
- Achats
- 1,034
- Coût par achat
- $1.40
- ROAS
- 5.69×
Un contexte important, sinon ces chiffres me flattent : à 5,69× sur 1 452 $, cela fait environ 8 262 $ de chiffre d'affaires suivi sur 1 034 commandes, soit un panier moyen d'environ 8 $. C'était un produit à petit prix. Un coût par achat de 1,40 $ n'a pas du tout la même valeur avec un panier moyen de 8 $ qu'avec un panier de 80 $, et quiconque cite un CPA sans le panier moyen à côté ne vous montre que la moitié du chiffre.
Les chiffres proviennent d'une période qui s'est terminée en mai 2024. Je les date plutôt que de les présenter comme actuels.
Ce qui compte pour cet article dans ces 1 034 achats, ce n'est pas le ROAS. C'est qu'une boutique qui envoie à ce volume un événement PURCHASE propre, bien nommé et correctement dédupliqué vous donne une référence fiable de ce à quoi ressemble « ça marche », et rend évident le moment où quelque chose s'arrête.
Ce que je ne peux pas vous dire
Deux limites honnêtes, car un article qui n'en admet aucune en cache généralement quelques-unes.
Je ne peux pas vous donner un classement de fréquence issu d'un large échantillon. L'ordre ci-dessus reflète un petit nombre de comptes, plus ce que les modes de défaillance impliquent logiquement : un nom d'événement en minuscules casse les rapports de façon systématique, il a donc sa place en tête, quelle que soit la fréquence à laquelle je l'ai personnellement rencontré. Voyez ce classement comme un ordre de recherche sensé, pas comme une statistique.
L'interface de Snapchat change. Les chemins de menu deviennent vite obsolètes, c'est pourquoi les vérifications ci-dessus s'appuient sur la requête réseau et la charge utile plutôt que sur l'emplacement actuel d'un bouton. La charge utile, c'est ce qui est réellement vrai.
En résumé
- Ouvrez l'onglet Network, filtrez sur
tr.snapchat.com, passez une commande de test. - Vérifiez que le nom de l'événement est exactement
PURCHASE, en majuscules. - Vérifiez que
transaction_idest présent et unique par commande. - Vérifiez que le pixel existe sur la page où arrive réellement le client.
- Si le checkout quitte votre domaine, prévoyez l'API Conversions.
- Si vous faites tourner le pixel et la CAPI, vérifiez que l'identifiant de déduplication est strictement identique des deux côtés.
Si vous avez passé les six vérifications et que l'événement n'arrive toujours pas, le problème n'est généralement pas le pixel : c'est que la page que vous testez n'est pas celle qu'atteignent vos clients. Revenez en arrière et passez un vrai achat avec de l'argent réel, sur un téléphone, depuis un clic sur une annonce. Les commandes de test via un lien de préproduction sautent précisément les parties qui cassent.
Vous ne savez pas laquelle des six est en cause ?
Envoyez-moi l'URL de votre boutique et je vous dirai ce que fait votre suivi. Aucun accès au compte n'est nécessaire pour commencer, juste le lien.
Obtenir un audit de suivi gratuit →