iOS 14 et le pixel Meta : ce qui a vraiment cassé (et quoi faire maintenant)

Quand Apple a livré l'App Tracking Transparency (ATT) avec iOS 14.5, la machine publicitaire de Meta a encaissé un coup visible. Les conversions rapportées ont chuté, les audiences ont rétréci et le retour sur dépense publicitaire a paru pire du jour au lendemain. Des années plus tard, beaucoup de marchands PrestaShop utilisent encore la même configuration uniquement-pixel qu'ATT a discrètement cassée — et se demandent encore pourquoi Meta sous-déclare leurs ventes.

En résumé : le pixel basé sur le navigateur a perdu le signal sur lequel il s'appuyait, et la solution consiste à envoyer les conversions depuis votre serveur. Mais pour corriger en confiance, il est utile de comprendre exactement ce qui a changé et pourquoi l'ancienne approche ne peut jamais se rétablir totalement seule. Voici ce qui s'est passé en détail.

Ce que l'App Tracking Transparency a vraiment fait

L'ATT a forcé les applications à demander la permission avant de suivre les utilisateurs à travers les applications et sites web d'autres entreprises. La fameuse invite « Demander à l'app de ne pas suivre » a fait que une large majorité d'utilisateurs s'est désinscrite — selon la plupart des sources, l'écrasante majorité. Pour Meta, cela a coupé un flux de signal inter-applications utilisé pour attribuer les conversions et constituer les audiences.

Fait crucial, l'ATT n'a pas affecté que le comportement dans les applications. Elle faisait partie d'un mouvement plus large d'Apple pour limiter le suivi inter-sites dans Safari et iOS aussi, s'ajoutant aux restrictions de cookies déjà imposées par l'Intelligent Tracking Prevention.

L'effet combiné a fait que Meta ne pouvait plus suivre de façon fiable une personne depuis la vue d'une publicité jusqu'à l'achat sur votre boutique. Les conversions avaient toujours lieu ; Meta perdait simplement le fil qui les reliait aux publicités qui les avaient provoquées.

Pourquoi le pixel a commencé à manquer des ventes

Le pixel Meta est du JavaScript côté client. Il dépend des cookies du navigateur — principalement _fbp (un identifiant de navigateur first-party posé par Meta) et _fbc (qui stocke l'identifiant de clic issu du paramètre fbclid dans l'URL publicitaire) — pour relier un acheteur à la publicité sur laquelle il a cliqué.

Quand ces cookies sont bloqués, raccourcis ou jamais posés, le pixel se déclenche tout de même mais ne peut faire correspondre la conversion à un clic. La vente a eu lieu ; Meta ne peut simplement pas prouver qu'elle vient de Meta.

Ajoutez les bloqueurs de publicités qui annulent entièrement la requête du pixel — souvent 30 % ou plus d'une audience — et vous obtenez la sous-déclaration que décrivent les marchands : un vrai chiffre d'affaires en banque, mais bien moins crédité dans le Gestionnaire de publicités. Le pire, c'est que la perte est biaisée précisément vers les audiences soucieuses de leur vie privée et très iOS que beaucoup de boutiques souhaitent le plus atteindre.

La Conversions API restaure le signal

La réponse de Meta est la Conversions API (CAPI) — un canal serveur à serveur qui envoie les événements de conversion directement depuis votre back-end vers Meta, contournant entièrement le navigateur. Comme elle s'exécute côté serveur, elle est immunisée contre les bloqueurs de publicités, les onglets fermés et la plupart des restrictions de cookies.

Avec Meta CAPI en place, un purchase enregistré par PrestaShop est envoyé à Meta avec tous les signaux de correspondance disponibles — e-mail haché, téléphone haché, et un _fbc reconstruit côté serveur à partir du fbclid dans l'URL de destination lorsque le cookie navigateur manque.

Cette reconstruction de _fbc est un petit détail à l'impact démesuré : elle récupère l'attribution que les restrictions de cookies d'Apple détruiraient autrement, en capturant l'identifiant de clic au moment de l'arrivée plutôt qu'en s'appuyant sur un cookie qui pourrait ne jamais survivre jusqu'au paiement.

Déduplication : pixel et CAPI sans double comptage

Vous ne jetez pas le pixel. La configuration la plus solide fait tourner le pixel et la CAPI ensemble : le pixel capte le comportement riche du navigateur et le contexte sur le site, tandis que la CAPI garantit que la conversion elle-même est enregistrée. Le risque est évident — si les deux signalent la même vente, Meta pourrait la compter deux fois et gonfler vos résultats.

La solution est la déduplication d'événements. Le pixel et le serveur envoient tous deux le même event_id pour une action donnée, et Meta les fusionne en un seul événement, en préférant celui arrivé avec les meilleures données. Bien fait, vous obtenez la couverture du côté serveur avec la richesse du côté client et sans inflation.

Obtenir un event_id identique sur les deux canaux est la partie qui fait trébucher la plupart des configurations faites maison, car il doit être déterministe et généré de la même manière dans le navigateur et sur le serveur. Notre page comment ça marche montre comment cela est câblé sur PrestaShop.

Ce que cela signifie pour les audiences et les enchères

Restaurer le signal de conversion n'est pas qu'une question de rapports plus propres. Les systèmes de diffusion et d'optimisation de Meta apprennent des conversions que vous renvoyez. Quand le pixel laissait discrètement tomber un tiers ou plus de vos ventes, Meta optimisait contre une image déformée — sous-enchérissant sur des audiences qui convertissaient en silence et jugeant mal les créations qui fonctionnaient.

Alimenter Meta avec des données de conversion complètes et côté serveur, dotées de signaux de correspondance solides, permet à son optimisation de voir la vraie valeur de chaque clic et de chaque audience. Beaucoup de marchands constatent que le reciblage et les audiences similaires performent nettement mieux une fois que la CAPI envoie des données fiables, simplement parce que les entrées ne sont plus cassées.

Un meilleur signal en entrée signifie une meilleure diffusion en sortie — le même principe qui s'applique à toute plateforme publicitaire moderne. Il vaut la peine de le rappeler car cela reformule la CAPI : d'une corvée de conformité en un levier de croissance. Les marchands qui traitent les données de conversion comme un actif de premier ordre tirent systématiquement plus du même budget publicitaire que ceux qui laissent le pixel se dégrader en silence.

Ce que les marchands PrestaShop devraient faire maintenant

Commencez par accepter qu'une configuration uniquement-pixel laisse des conversions — et donc de la performance publicitaire — sur la table. Ajoutez ensuite la CAPI par-dessus, en partageant un seul event_id par événement pour une déduplication propre, et assurez-vous que les données first-party comme l'e-mail et le téléphone sont normalisées et hachées en SHA-256 avant de quitter votre serveur.

PrestaSignal gère tout cela via un conteneur sGTM auto-hébergé, afin que le pixel et la CAPI restent synchronisés sans que vous touchiez au code de la page de confirmation. Le jeton d'accès CAPI reste côté serveur et n'atteint jamais le navigateur, et les PII sont hachées avant transmission.

Si Meta continue de sous-déclarer vos ventes, réservez un audit et nous mesurerons l'écart sur votre boutique et vous montrerons exactement ce que la CAPI récupérerait.