Meta CAPI en server-side avec Stape : la configuration par A-Track

Votre boutique enregistre des ventes que Meta Ads ne voit pas ? Le Pixel Meta, exécuté dans le navigateur, perd une partie de ses signaux à cause des restrictions d'Apple, des navigateurs et des bloqueurs. Résultat : l'algorithme optimise sur une vision partielle et vous risquez de couper des campagnes rentables. Voici comment nous déployons la Meta Conversions API (CAPI) en server-side avec Google Tag Manager et Stape.

En bref

• La Meta CAPI envoie vos événements depuis un serveur, en complément du Pixel, avec un event_id commun pour la déduplication.

• Un conteneur GTM server-side sur votre sous-domaine (par exemple data.votre-marque.ch) sert de point de collecte first-party et de filtre.

• La qualité des correspondances (EMQ) dépend surtout des données client envoyées, hachées en SHA-256.

• Le server-side n'est pas un contournement : sans consentement, rien ne part vers Meta.

Pourquoi le Pixel Meta seul ne suffit plus

Pendant des années, un simple script JavaScript suffisait à remonter les achats et à recibler les visiteurs. Ce tracking « client-side », exécuté dans Chrome ou Safari, dépend aujourd'hui de trop de facteurs que vous ne contrôlez pas.

iOS, ITP et bloqueurs : trois pertes de signal

1. App Tracking Transparency (iOS 14.5, avril 2021) : les applications, dont Facebook et Instagram, doivent demander l'autorisation de suivre l'utilisateur entre apps. Les refus réduisent les signaux disponibles pour l'attribution.

2. Intelligent Tracking Prevention de Safari (ITP) : Safari bloque les cookies tiers et limite à 7 jours les cookies first-party posés en JavaScript (24 h dans certains cas de tracking par lien). Un client qui clique lundi et achète dix jours plus tard n'est plus relié à l'annonce.

3. Bloqueurs de publicité : selon GWI (T2 2025), 30,9 % des internautes suisses en utilisent un. Des extensions comme uBlock Origin ou des navigateurs comme Brave empêchent souvent le chargement de fbevents.js, le script du Pixel.

Le coût d'une mesure incomplète

• Un algorithme qui apprend moins bien : Meta optimise la diffusion à partir des conversions qu'il voit. Moins de signaux, un ciblage moins précis.

• Des audiences similaires dégradées : les Lookalike se construisent sur vos acheteurs récents. S'il en manque une partie, la base de départ se déforme.

• Un ROAS sous-estimé : vous risquez de couper une campagne rentable parce que le Gestionnaire de publicités n'affiche pas toutes les ventes.

La solution : Meta CAPI en server-side avec Stape

Avec la Conversions API, ce n'est plus seulement le navigateur qui parle à Meta : votre serveur transmet les événements, de serveur à serveur. Nous utilisons pour cela un conteneur Google Tag Manager server-side (sGTM) hébergé chez Stape, avec un serveur en Europe.

Le principe en deux temps

1. Collecte first-party : le navigateur envoie les événements (vue de page, ajout au panier, achat) vers votre propre sous-domaine, qui pointe vers le conteneur serveur.

2. Distribution contrôlée : le conteneur vérifie le consentement, retire les données inutiles, hache les données client puis transmet l'événement à l'API Meta. Sans accord du visiteur, l'événement ne part pas.

Le sous-domaine personnalisé

Nous configurons un Custom Domain (par exemple data.votre-marque.ch). Les requêtes restent sur votre domaine : la collecte est first-party, plus résiliente aux restrictions techniques, et les cookies posés par votre serveur peuvent échapper à la limite de 7 jours des cookies JavaScript. Condition : le serveur doit partager l'adresse IP du site, sinon Safari applique aussi cette limite (WebKit, 2023). Un sous-domaine ne rend jamais légitime un envoi que le visiteur a refusé.

CAPI Gateway ou server GTM ?

Meta propose aussi la Conversions API Gateway, que Stape peut héberger. Elle se configure vite et déduplique automatiquement, mais elle ne sert que Meta et se contente de dupliquer les événements du Pixel. Nous privilégions le server GTM dès que plusieurs plateformes sont en jeu : le même conteneur alimente Meta, GA4, Google Ads, TikTok ou Klaviyo, avec un contrôle fin des données envoyées. En regroupant les envois côté serveur, vous limitez aussi le nombre de scripts tiers chargés dans la page, ce qui peut alléger son chargement. Règle absolue : une seule source serveur par jeu de données Meta, jamais Gateway et sGTM en parallèle sur les mêmes événements.

La configuration selon votre CMS

Meta CAPI n'est pas un bouton magique. Meta attend des données structurées, des informations client hachées en SHA-256 et des événements dédupliqués.

1. La règle universelle : la déduplication

Meta recommande d'utiliser le Pixel et la Conversions API ensemble (documentation Meta). Pour ne pas compter deux fois un achat, nous générons un event_id unique dans le navigateur, transmis au Pixel et au serveur avec le même nom d'événement. Meta ne garde qu'un événement si les deux arrivent dans les 48 heures.

2. WordPress et WooCommerce

• Nous posons un dataLayer e-commerce fiable sur WordPress et WooCommerce (plugin Stape, GTM4WP ou développement sur mesure).

• Le GTM web route view_item, add_to_cart et purchase vers le sous-domaine serveur.

• Côté sGTM, la balise Facebook Conversions API de Stape reçoit la valeur, la devise et les identifiants produits.

3. Shopify

• Sur Shopify, le tracking du checkout passe par les Customer Events, des pixels exécutés dans un environnement isolé.

• Nous utilisons l'application Stape pour Shopify ou les webhooks de commande : l'achat part du back-office, même si le client ferme son navigateur avant la page de remerciement.

• Point d'attention : l'état du consentement doit accompagner la commande, pour que le serveur sache s'il a le droit de l'envoyer à Meta.

Comparatif détaillé dans notre article Shopify vs WooCommerce en server-side.

4. PrestaShop et sites sur mesure

• Pour PrestaShop ou un site développé en React, Vue.js ou PHP, nous standardisons le dataLayer avec vos développeurs.

• Les données client (e-mail, téléphone, prénom, code postal) sont collectées au checkout, puis hachées dans le conteneur serveur : c'est le principal levier de l'Event Match Quality (EMQ).

5. Wix

Les intégrations natives de Wix restent basiques et peu paramétrables pour la conformité. Via GTM et l'application Stape pour Wix, nous reprenons la main sur le flux et sur les paramètres user_data.

Les options Stape que nous activons

Cocher « API » ne suffit pas. Deux options de Stape rendent la mesure plus stable, toujours dans le cadre du consentement.

• Custom Loader : GTM est chargé depuis votre propre domaine plutôt que depuis un domaine tiers. La collecte devient first-party de bout en bout. Les balises marketing restent soumises au choix du visiteur : un refus reste un refus.

• Cookie Keeper : Stape conserve certains identifiants first-party (par exemple _fbp et _fbc) et les restaure lorsque le navigateur les efface, ce qui aide l'attribution sur les cycles de vente longs (immobilier, B2B, luxe). Il ne fonctionne pas dans l'environnement isolé de Shopify.

Conformité LPD et RGPD : le serveur comme filtre

Depuis le 1er septembre 2023, la LPD révisée exige transparence et proportionnalité ; côté UE, le RGPD et la directive ePrivacy imposent le consentement préalable pour le suivi publicitaire. Les transferts vers les États-Unis sont encadrés par le Swiss-U.S. Data Privacy Framework depuis le 15 septembre 2024 (EU-U.S. DPF : 10 juillet 2023), pour les destinataires certifiés.

Le server-side n'est pas une conformité automatique, mais un point de contrôle :

1. Consentement appliqué côté serveur : la balise Meta du conteneur ne s'exécute qu'avec l'accord marketing du visiteur. Sans accord, aucun événement ne part vers Meta.

2. Minimisation : même avec accord, le conteneur supprime les paramètres inutiles (PII dans les URL, champs de formulaire) avant l'envoi.

3. Hachage : e-mail et téléphone sont hachés en SHA-256 avant l'envoi, comme Meta l'exige (paramètres client, Meta). Hacher n'est pas chiffrer : la donnée reste personnelle et pseudonymisée.

4. Hébergement en Europe : utile, mais insuffisant à lui seul, puisque Meta reste destinataire. Mentionnez-le dans votre politique de confidentialité.

Conseil A-Track

Refusez tout dans la bannière, passez une commande de test et suivez-la dans l'aperçu du conteneur serveur. Aucune requête ne doit partir vers Meta. Puis acceptez : l'achat doit apparaître une seule fois dans le Gestionnaire d'événements, avec le même event_id côté navigateur et serveur.

Cadre complet dans notre guide de conformité LPD et RGPD.

Ce que vous pouvez mesurer après la mise en place

Nous ne promettons pas un pourcentage de données « récupérées » : il dépend de votre audience, de votre taux de consentement et de votre CMS. Nous mesurons avant et après le déploiement, sur deux à quatre semaines de chaque côté, avec des indicateurs vérifiables :

• L'écart entre back-office et Meta : achats enregistrés par la boutique comparés aux achats attribués dans le Gestionnaire d'événements.

• L'Event Match Quality : la note sur 10 de vos événements d'achat, qui progresse avec la qualité des données client transmises.

• Le taux de déduplication : la part des événements reçus deux fois et correctement fusionnés.

• La phase d'apprentissage : avec des conversions plus complètes, les ensembles de publicités atteignent plus facilement le volume dont Meta a besoin pour sortir de l'apprentissage.

• La stabilité des audiences : listes de paniers abandonnés et de visiteurs qui se remplissent de nouveau.

Pour les bases de la Conversions API côté e-commerce, lisez aussi notre guide Facebook CAPI.

Conclusion : par où commencer

1. Mesurez l'écart actuel entre votre back-office et Meta sur 30 jours.

2. Choisissez l'architecture : Gateway si Meta est votre seul canal, server GTM dès que plusieurs plateformes sont en jeu.

3. Déployez avec event_id, sous-domaine first-party et filtre de consentement, puis refaites le test de refus après chaque mise à jour du site.