Tracking

iOS 14+ : pourquoi votre ROAS Meta est faux (et comment le corriger)

Depuis iOS 14.5, une partie des achats n'arrive plus dans le pixel Meta. Pourquoi le ROAS affiché peut diverger des commandes Shopify, et ce que l'envoi serveur change.

Arthur Reboul8 minMis à jour le 25 septembre 2026
Sommaire

Depuis avril 2021 et la mise à jour iOS 14.5, Apple impose à toutes les applications de demander le consentement explicite des utilisateurs avant de les tracker. Cette politique, appelée App Tracking Transparency (ATT), a fondamentalement changé le paysage publicitaire.

Depuis, une part importante des utilisateurs iOS refuse le suivi dans les applications. Safari limite aussi la durée de vie des cookies posés par JavaScript. Une portion des achats devient donc invisible pour Meta, ou seulement estimée. La part exacte dépend de votre trafic : comparez les commandes Shopify aux conversions affichées, sur la même période.

Ce qui est réellement cassé

Avant iOS 14.5, le pixel Meta fonctionnait de manière simple : un bout de JavaScript sur votre site envoyait les événements (page vue, ajout au panier, achat) à Meta, qui les associait au clic publicitaire grâce au cookie fbclid.

Maintenant, voici ce qui se passe :

  • Le cookie fbclid est bloqué ou expire en 24h sur Safari (ITP) au lieu de 7 jours
  • Les bloqueurs de publicité peuvent supprimer le pixel Meta dans le navigateur
  • ATT empêche Meta de matcher le clic pub avec l'achat si l'utilisateur refuse le tracking dans l'app Facebook
  • La fenêtre d'attribution est réduite à 7 jours par défaut (contre 28 jours auparavant)

Résultat : Meta ne voit qu'une fraction des conversions réelles. Et paradoxalement, il arrive aussi que Meta sur-reporte certaines conversions grâce à sa modélisation statistique, créant un ROAS artificiel qui ne correspond à rien de réel.

Ce que vous pouvez mesurer, vous

Il n'y a pas un pourcentage unique de conversions « perdues ». Ce qui est observable sur une boutique :

  • une partie des achats n'atteint pas le pixel navigateur (bloqueur, Safari, refus de suivi dans l'app)
  • Meta complète les trous par une modélisation que vous ne pouvez pas auditer ligne à ligne
  • le ROAS affiché peut donc être au-dessus ou en dessous du chiffre d'affaires réellement encaissé
  • le retargeting souffre en plus, parce qu'il dépend des audiences de visiteurs vues par le pixel

La comparaison utile : commandes payées Shopify d'un côté, conversions Meta de l'autre, mêmes dates. L'écart est le vôtre. Ce n'est pas une moyenne ProfitPilot.

La modélisation de Meta : un pansement sur une jambe de bois

Meta a introduit l'Aggregated Event Measurement (AEM) et un système de modélisation statistique pour "estimer" les conversions manquantes. Le problème, c'est que cette modélisation est une boîte noire.

Vous n'avez aucune idée de comment Meta calcule ces estimations. Et Meta a un intérêt direct à vous montrer un ROAS favorable : plus vous pensez que vos pubs fonctionnent, plus vous dépensez.

La solution : le tracking server-side (CAPI)

Le Conversions API (CAPI) de Meta permet d'envoyer les événements de conversion directement depuis votre serveur, sans passer par le navigateur de l'utilisateur. C'est la solution officielle de Meta pour contourner les limitations iOS.

Voici comment cela fonctionne :

  • Quand un achat se produit sur votre boutique, votre serveur envoie l'événement directement à Meta
  • Meta reçoit l'événement avec des identifiants (email hashé, téléphone, IP) pour matcher avec le clic pub
  • Les ad-blockers ne peuvent pas bloquer cette communication serveur-à-serveur
  • L'événement part du serveur : ni l'ITP de Safari ni un bloqueur ne peuvent l'arrêter

Le fingerprinting pour combler les trous restants

Même avec le CAPI, certains visiteurs restent difficiles à rattacher (cookies effacés, navigation privée). Une empreinte technique du navigateur peut reconnaître un appareil sans cookie. Ce n'est pas un accord préalable : tant que la personne n'a pas dit oui, le marchand doit pouvoir refuser cet envoi. Le détail est dans la politique de confidentialité.

Comment mettre en place le tracking server-side

Il existe plusieurs approches :

  • Manuellement : développer un endpoint API qui reçoit les événements et les forwarde à Meta via le CAPI. Complexe et chronophage.
  • Via Google Tag Manager Server : nécessite un serveur dédié (Google Cloud Run), une configuration technique avancée, et un coût mensuel supplémentaire.
  • Avec ProfitPilot Pro : sur Shopify, le pixel s'active depuis l'éditeur de thème. Les commandes arrivent par la connexion boutique, pas par le script. L'achat part vers Meta (Purchase), TikTok (CompletePayment) et Google (champ orderId), avec le même identifiant numérique de commande. Le guide pas à pas est dans Documentation → Tracking.

L'impact concret sur vos campagnes

En récupérant les conversions manquantes, vous permettez à l'algorithme de Meta de mieux optimiser vos campagnes. Plus Meta a de données de conversion, mieux il cible les audiences susceptibles d'acheter.

Ce que ça change, concrètement :

  • L'événement part du serveur : ni l'ITP de Safari ni un bloqueur ne peuvent l'arrêter
  • L'identité est hachée côté serveur, donc plus complète que ce que le navigateur peut transmettre
  • Votre taux de correspondance réel est affiché dans le tableau de bord — c'est votre mesure, pas une moyenne promise

L'essai dure 14 jours, sans carte. Créer un compte, puis comparez vos commandes Shopify aux conversions Meta sur la même période.

Questions fréquentes

Pourquoi le ROAS Meta peut diverger des commandes Shopify ?

Une partie des achats n'atteint pas le pixel (bloqueur, Safari, refus de suivi dans l'application). Meta complète par une estimation. La comparaison utile, ce sont les commandes payées contre les conversions affichées, sur les mêmes dates.

AR

Arthur Reboul

Fondateur de ProfitPilot Pro

Essai 14 jours, sans carte

Boutique Shopify, dépenses Meta, TikTok et Google, profit net sur la période.

Créer un compte

À lire ensuite