Les métas à poser sur la commande

Les métas à poser sur la commandeINOSHOP lit les commandes WooCommerce, les valide, et envoie l'événement Purchase à la Meta Conversions API depuis le serveur. Le site n'a rien à installer : ni script, ni clé, ni appel vers CONTROL.Il a une seule chose à faire : écrire six métas sur la commande au moment du checkout. Elles sont invisibles pour le client et ne coûtent rien — mais ce sont elles qui décident si Meta reconnaît l'acheteur ou non.

Pourquoi le site et pas nous ? Ces valeurs n'existent qu'à l'instant du passage de commande, dans le navigateur du client. Quand INOSHOP envoie l'événement — souvent des heures plus tard, à la validation d'un paiement à la livraison — il ne voit plus que son propre serveur. Les reprendre à ce moment-là donnerait l'IP de CONTROL et le user-agent de Guzzle : un rapprochement nul et un EMQ qui s'effondre.

Les six métasÀ écrire sur la commande WooCommerce, en une seule fois, juste après sa création.

Méta	Valeur	Rôle
`_fbp`	Cookie `_fbp` posé par le pixel Meta	Rapprochement navigateur
`_fbc`	Cookie `_fbc`, ou reconstruit depuis `fbclid`	Rapprochement publicité — le plus précieux
`_external_id`	Votre identifiant client stable (hachez-le si vous préférez)	Rapprochement compte
`_client_ip`	IP réelle du client	Rapprochement
`_client_user_agent`	User-agent du navigateur	Rapprochement
`_event_source_url`	La page de validation réellement visitée	`event_source_url` de l'événement

Les cinq premières alimentent le user_data de l'événement. La sixième n'en fait pas partie : elle devient l'event_source_url, c'est-à-dire le lieu déclaré de l'achat.En pratique

// Côté SERVEUR du site, au moment où la commande est créée.
// `contexte` est ce que vous avez déjà sous la main dans le handler.

await marquerMetaCommande(orderId, {
  _fbp: suivi.fbp,
  _fbc: suivi.fbc,
  _external_id: suivi.external_id,
  _client_ip: contexte.ip,
  _client_user_agent: contexte.userAgent,
  _event_source_url: contexte.url,   // ex. https://soraparfume.com/commande
});

Ou directement en REST WooCommerce :

http

PUT /wp-json/wc/v3/orders/1042
{
  "meta_data": [
    { "key": "_fbp", "value": "fb.1.1699..." },
    { "key": "_fbc", "value": "fb.1.1699....IwAR..." },
    { "key": "_external_id", "value": "c-8842" },
    { "key": "_client_ip", "value": "41.207.x.x" },
    { "key": "_client_user_agent", "value": "Mozilla/5.0 (...)" },
    { "key": "_event_source_url", "value": "https://soraparfume.com/commande" }
  ]
}

Une méta absente n'est jamais bloquante : INOSHOP omet le champ plutôt que d'envoyer une valeur vide, et tente un repli sur la session INOTRACK liée si le traqueur est installé. Mais un repli reste un repli — la valeur du checkout est toujours meilleure._event_source_url : à quoi ça sert vraimentC'est le domaine que Meta considère comme l'origine de l'achat. Il doit être celui où le pixel s'exécute et qui est vérifié dans le Business Manager.Sur une boutique headless, c'est le piège : l'API vit sur api.soraparfume.com, les clients achètent sur soraparfume.com. Sans cette méta, INOSHOP retombe sur l'adresse publique réglée dans CONTROL — correcte, mais c'est le domaine seul, pas la page. Avec la méta, l'Achat porte la même URL que le Prospect et que l'événement du pixel navigateur, ce que Meta exploite pour les rapprocher.

Attention

L'URL est vérifiée par INOSHOP. Elle arrive d'un en-tête Referer, donc du navigateur, donc de n'importe qui : une URL d'un domaine étranger à la boutique est écartée et remplacée par l'adresse publique. L'événement, lui, part normalement. soraparfume.com, www.soraparfume.com et boutique.soraparfume.com sont acceptés.

Le réglage correspondant dans CONTROL**INOSHOP → Boutiques → votre boutique → Connexion → « Adresse vue par les clients »**.À remplir uniquement si la boutique est headless. Sur une boutique WooCommerce classique, les deux adresses se confondent : laissez le champ vide.⚠️ Ne pas émettre de Purchase côté navigateurC'est le point qui coûte le plus cher quand on se trompe, et il est contre-intuitif.INOSHOP envoie le Purchase à la validation de la commande, pas au checkout. Sur du paiement à la livraison, cela peut être des heures ou des jours plus tard — c'est délibéré : dater l'événement à la création garde l'achat dans la fenêtre d'attribution de la publicité qui l'a généré.L'event_id est tiré à cet instant-là, côté serveur. Le navigateur du client, qui est passé bien avant, ne peut pas le connaître. Il n'y a donc aucune déduplication possible.Conséquence : si votre page de confirmation déclenche un fbq('track', 'Purchase'), chaque vente est comptée deux fois dans l'Events Manager, et votre ROAS affiché est faux d'un facteur deux.

Événement navigateur	À conserver ?
`PageView`, `ViewContent`, `AddToCart`, `InitiateCheckout`, `Lead`	Oui — INOSHOP ne les envoie pas
`Purchase`	Non — INOSHOP s'en charge, depuis le serveur

Si vous tenez à un Purchase navigateur (pour une mesure immédiate), dites-le nous : il faudra que le site pose lui-même l'event_id au checkout et qu'INOSHOP le reprenne — ce qui n'est pas le fonctionnement actuel, et ce que la fenêtre de déduplication de Meta (48 h) rend de toute façon inopérant sur une validation tardive.Ce qu'INOSHOP fait de son côtéRien à faire pour vous, mais utile à savoir pour lire l'Events Manager :

event_time = date de création de la commande, pas de validation.

action_source = website : l'achat a bien eu lieu sur le site, et c'est cette valeur qui autorise Meta à exploiter _fbp / _fbc.

Téléphone, email, nom, ville sont pris sur la commande et hachés en SHA-256 après normalisation. Rien de personnel ne part en clair.

Le numéro de téléphone reçoit le préfixe pays de la boutique s'il n'en a pas.

Un remboursement part comme événement personnalisé à valeur négative, daté du jour.

RecetteDans l'ordre, chacune se vérifie seule :

Une commande de test passée depuis le site porte bien les six métas (WooCommerce → la commande → « Champs personnalisés », ou GET /wp-json/wc/v3/orders/{id}).

_fbc est présent quand on arrive depuis une publicité (URL avec fbclid). C'est le signal le plus précieux : sans lui, l'achat n'est pas rattaché à la campagne.

_client_ip est l'IP du client, pas celle de votre serveur Next.js (attention derrière un proxy : lire x-forwarded-for).

_event_source_url porte le domaine public, pas celui de l'API.

CONTROL → la commande → onglet Meta CAPI : la provenance de chaque champ indique order et non session ou absent.

Le score de correspondance (EMQ) affiché après envoi dépasse 6/10.

Events Manager : un seul Purchase par commande, aucun avertissement de domaine non vérifié.

Dépannage

Symptôme	Cause la plus fréquente
EMQ bas (< 5)	Les métas ne sont pas posées, ou posées après l'envoi de l'événement
Provenance `session` partout dans l'onglet Meta CAPI	Le checkout ne transmet rien : c'est le traqueur INOTRACK qui sauve le rapprochement
Provenance `absent`	Ni le checkout ni le traqueur n'ont la valeur — vérifier que le pixel Meta pose bien ses cookies sur le domaine public
`_fbc` toujours vide	Le pixel ne pose `_fbc` que si l'URL d'arrivée contient `fbclid`. À reconstruire à la main si votre routeur nettoie l'URL
`_client_ip` = une IP interne (10.x, 172.x)	Vous lisez l'IP de la connexion et non `x-forwarded-for`
Achats comptés deux fois	Un `fbq('track','Purchase')` traîne sur la page de confirmation
Avertissement Meta « domaine non vérifié »	`_event_source_url` porte le domaine de l'API ; renseigner l'adresse publique dans CONTROL
Aucun achat dans l'Events Manager	La commande n'a pas été validée dans CONTROL : rien ne part avant

Voir aussi : ../inotrack/ — le traqueur, qui alimente le repli des signaux quand le checkout n'en transmet pas.