Vous avez activé le Conversions API (CAPI) Meta et l'Events API TikTok. Events Manager affiche des achats en hausse. L'algorithme scale. Puis Shopify vous montre moins de commandes que Meta ne compte de conversions — ou l'inverse.
Souvent, l'écart ne vient pas d'« iOS 14 » en général, mais de trois détails : event_id, identifiants de matching, et absence de test avant d'augmenter le budget.
Architecture recommandée pour une boutique Shopify
Le flux fiable pour un achat :
- Le client paie → Shopify émet un webhook
orders/paid(ouorders/create, selon ce que vous avez branché) - Votre serveur reçoit la commande, avec les identifiants capturés avant le paiement :
fbp,fbc,ttclid - Meta reçoit un événement
Purchase. TikTok reçoitCompletePayment, pas Purchase. Google ne reçoit pas un événement de ce nom : l'identifiant part dans le champorderId - Pixel et serveur partagent le même
event_id: l'identifiant numérique de la commande Shopify. Pas un gid, pas#1001, pas un suffixe_purchase
Ne déclenchez pas l'achat serveur uniquement depuis le pixel : un bloqueur, ou un onglet fermé avant la page de remerciement, et la commande payée ne part jamais si le webhook n'existe pas.
Meta CAPI : les champs qui font monter l'Event Match Quality
Meta affiche un score Event Match Quality (EMQ) par type d'événement. Un EMQ faible = matching probabiliste = optimisations instables.
Priorité des identifiants (achat Shopify)
| Champ | Source typique | Impact matching |
|---|---|---|
fbc | Cookie _fbc ou fbclid de l'URL au clic | Très élevé pour l'attribution clic |
fbp | Cookie _fbp posé par le pixel | Élevé |
em | Email checkout, SHA-256 normalisé (minuscules, trim) | Élevé |
ph | Téléphone E.164 hashé | Moyen à élevé |
client_ip_address + client_user_agent | Requête HTTP au moment de l'achat | Secours utile |
Erreurs courantes :
- Envoyer l'email en clair — Meta exige le hash SHA-256
- Oublier de normaliser (espaces, majuscules, +33 vs 0…)
- Ne pas transmettre
fbcparce que le checkout est sur un domaine Shopify sans persistence du cookie — solution : passerfbcliden note d'attribut ou cookie first-party avant checkout - Utiliser l'email de facturation différent de celui saisi au checkout Meta
event_id et dedup Meta
Pour chaque achat, générez un identifiant stable partagé entre pixel et CAPI. Bonnes pratiques :
event_id= identifiant numérique de la commande (par exemple1842), identique côté pixel et côté serveur- Même nom
Purchasedes deux côtés, pour Meta seulement - Même
event_time(timestamp Unix) à quelques secondes près — un écart de plusieurs heures peut empêcher la dedup - Même
valueetcurrency— un pixel à 49,90 € et un CAPI à 39,92 € après remise, ce sont deux événements aux yeux de Meta
Dans Events Manager → Diagnostics, vérifiez la ligne Deduplication : un taux élevé d'événements « browser + server » dedupliqués est sain. Si seuls les événements server remontent, votre pixel est probablement bloqué — ce n'est pas grave si le CAPI est complet, mais l'EMQ peut baisser sans fbp.
TikTok Events API : spécificités vs Meta
TikTok déduplique aussi avec event_id, le même nombre que chez Meta. Le nom d'événement, lui, est CompletePayment — côté pixel et côté Events API. Identifiants clés :
ttclid— équivalent du fbclid, à capturer sur la landing et persister jusqu'à l'achat- Email et téléphone hashés (mêmes règles de normalisation)
external_id— ID client Shopify hashé, utile pour les achats récurrents
TikTok Events Manager expose un indicateur de qualité des événements (libellé variable selon l'interface). Les mêmes principes s'appliquent : sans ttclid ni email, TikTok devine — et votre CPA optimisé sur du bruit.
Multi-plateforme : un webhook, plusieurs destinations
Une commande Shopify ne doit pas déclencher deux fois le CAPI par erreur de retry webhook. Pattern sûr :
- Idempotence : avant envoi, vérifier que cette commande n'a pas déjà été transmise
- Enregistrez la commande avant d'appeler Meta. Si Meta ne répond pas, retentez l'envoi dans une file. Renvoyer 500 à Shopify relance tout le webhook : sans idempotence, l'achat part deux fois
- Journalisez
event_idet le statut HTTP, pas l'email en clair
Checklist de validation avant de scaler le budget
1. Test Events (Meta)
Utilisez le code de test Events Manager. Passez une commande réelle ou sandbox. Confirmez :
- Événement Purchase reçu en Browser et Server
- Paramètres
em,fbc,fbpprésents côté server - Message de dedup OK pour le même
event_id
2. TikTok Test Event
Même procédure dans TikTok Events Manager. L'événement attendu est CompletePayment, avec le même event_id numérique. Vérifiez ttclid sur une commande issue d'un clic TikTok Ads (pas du trafic direct). Côté Google, le test porte sur le champ orderId, pas sur un événement nommé Purchase.
3. Réconciliation Shopify (7 jours glissants)
Comparez :
- Commandes payées Shopify (filtre date paiement)
- Conversions Purchase Meta (fenêtre 7j click, 1j view — ou votre config)
- Conversions TikTok
Un écart existe souvent : l'attribution d'une régie n'est pas le décompte des commandes. Un écart de l'ordre du double pointe plutôt une dedup cassée ou un double envoi. Beaucoup moins de conversions que de commandes payées pointe un envoi incomplet, ou un matching faible. Il n'y a pas de fourchette « normale » à recopier.
4. Valeur et remboursements
Envoyez le montant net payé (après remise, hors shipping si vous ne l'incluez pas dans votre définition de ROAS). Quand une commande est remboursée, certaines stacks envoient un événement d'annulation — si vous ne le faites pas, Meta continue d'optimiser sur du CA fantôme.
Erreurs qui coûtent cher (vue terrain)
- Double Purchase server — webhook + cron + pixel server-side sans idempotence → ROAS gonflé, algo scale dans le rouge
- event_id aléatoire à chaque retry — dedup impossible, conversions multipliées
- CAPI seul sans pixel — acceptable pour l'achat, mais perte des micro-événements funnel (ViewContent, AddToCart) pour le retargeting
- Ignorer Consent Mode / bandeau cookies — risque compliance + données partielles en UE ; le server-side n'exempte pas du consentement marketing
- Tester uniquement en navigation privée sans fbclid — fausse impression d'un EMQ « cassé »
Ce qu'une stack clé en main doit gérer pour vous
Si vous implémentez à la main, comptez maintenance continue (rotations token, changements API, monitoring). Une solution intégrée au stack Shopify + pub doit au minimum :
- Capturer
fbp,fbc,ttclidau parcours checkout - Forwarder
orders/paidavec hash PII conforme - Dedupliquer pixel + server via
event_idstable - Exposer un statut de santé (dernier envoi OK, EMQ indicatif, erreurs API)
ProfitPilot Pro envoie l'achat Shopify vers Meta (Purchase), TikTok (CompletePayment) et Google (champ orderId), avec le même identifiant numérique de commande. L'email et le téléphone partent hachés en SHA-256 quand le visiteur a consenti. Le profit net se calcule sur ces mêmes commandes. Le pas à pas est dans Documentation → Tracking.
Le contexte navigateur est dans les guides tracking server-side et iOS 14 et ROAS Meta.
L'essai dure 14 jours, sans carte. Le tracking server-side est inclus pendant l'essai et sur Starter, Pro et Agency. Le plan Free ne l'a pas. Créer un compte.