Qu'est-ce que l'ingénierie du signal, et que répare-t-elle après ATT ?

Vous êtes probablement ici parce que

Aucun de ces cas n'est un problème d'achat média. Ce sont des problèmes de signal, et la plupart se réparent.

• Meta rapporte un ROAS, RevenueCat en rapporte la moitié, et la finance ne croit ni l'un ni l'autre. Ils ne coïncideront jamais, et personne dans l'équipe ne sait dire pourquoi.
• Vos valeurs de conversion SKAN reviennent vides sur la plupart des campagnes et personne ne sait pourquoi.
• Meta scale sans problème. Google et TikTok stagnent sur la même créa.
• Vous êtes passés à l'optimisation de la valeur et cela a empiré.
• Les débuts d'essai coûtent peu cher et les conversions payantes ne suivent jamais.
• Il y a trois SDK dans l'app. Personne ne sait dire lequel possède la valeur de conversion.

Ce que répare l'ingénierie du signal

Cinq couches, dans l'ordre où je les construis.

• La couche des événements. Une taxonomie d'événements unique et canonique pour votre app, mappée explicitement sur les événements standard de Meta, les événements de conversion de Google, les événements de TikTok et votre MMP. Début d'essai, premier paiement, renouvellement, annulation, remboursement. Chacun avec une valeur, une devise et un identifiant.
• La livraison côté serveur. La Conversions API de Meta pour les événements app, l'Events API de TikTok et la configuration des conversions app de Google via votre MMP ou Firebase, connectées à votre backend d'abonnement pour que les renouvellements, les remboursements et les conversions d'essai atteignent les plateformes même quand l'app est fermée. Dédupliquées par identifiant d'événement pour que rien ne soit compté deux fois.
• Le schéma de valeur de conversion iOS. La petite valeur qu'Apple vous laisse renvoyer est le seul signal post installation que vous obtenez pour les utilisateurs qui ont refusé le tracking. Je le conçois autour de votre funnel et de votre volume, pour que les campagnes franchissent les seuils de confidentialité d'Apple au lieu de ne rien renvoyer du tout. Un seul SDK doit le posséder. Quand deux SDK l'écrivent, c'est le dernier appel qui gagne, et en ce moment, c'est généralement un accident.
• Les signaux de valeur pour les enchères. La valeur d'achat, la marge ou la LTV prédite, envoyées à chaque plateforme, pas seulement à Meta, et seulement une fois que j'ai vérifié que la valeur est réellement corrélée à ce que les utilisateurs vont ensuite payer. Une mauvaise valeur apprend à l'algorithme à acheter les mauvais utilisateurs plus vite.
• La vue de réconciliation. Une comparaison mensuelle entre la plateforme, le MMP, RevenueCat et les chiffres de versement du store, avec les écarts attendus consignés par écrit, pour que la prochaine fois que les chiffres ne coïncident pas, vous sachiez en cinq minutes si c'est structurel ou un bug.

Ce qui ne peut pas être réparé après ATT, et pourquoi je le dis

Depuis iOS 14.5, les utilisateurs qui refusent App Tracking Transparency ne peuvent pas être attribués au niveau utilisateur. SKAdNetwork et AdAttributionKit d'Apple renvoient des postbacks retardés et agrégés sans identifiant d'appareil, et ils retiennent délibérément le détail sur les campagnes à faible volume. Aucune intégration de Conversions API, aucune fonctionnalité de MMP et aucun outil de récupération d'attribution ne change cela. Meta fait passer ces événements par Aggregated Event Measurement. Google les modélise. TikTok les modélise.

Je ne promets donc pas une attribution déterministe. Je promets que les signaux que vous pouvez contrôler sont justes, que les plateformes reçoivent la meilleure entrée possible pour optimiser, et que vous saurez quels écarts sont normaux. Le ROAS de plateforme et le revenu d'abonnement continueront à ne pas coïncider une fois le travail fait. Ils ne coïncideront pas pour des raisons que vous pouvez expliquer. Si un prestataire vous dit le contraire, demandez-lui d'où vient l'identifiant utilisateur.

Quel système rapporte quoi sur iOS ?

Cinq systèmes comptent les installations et les conversions des mêmes campagnes iOS, et quand ils ne coïncident pas, aucun n'a forcément tort. Chacun compte autre chose, sur sa propre fenêtre et avec son propre délai. Le tableau s'appuie sur la documentation de chaque éditeur, vérifiée le 29 septembre 2026.

La vue iOS de Google demande du travail de votre côté. Pour Integrated Conversion Measurement, Google exige une campagne pour applications iOS active optimisée pour les installations, les événements first_open et post installation de votre MMP importés dans Google Ads, la mesure sur l'appareil avec données d'événements, et un SDK de MMP à jour. La mesure sur l'appareil avec données d'événements demande iOS 12 ou plus récent, le SDK Google Analytics for Firebase à partir de la version 11.14.0 et la propriété Analytics associée à Google Ads, et Google indique qu'elle sera inactive pour les utilisateurs de l'EEE, du Royaume-Uni et de la Suisse. Google Ads, le MMP et SKAN divergent donc par construction, et Google recommande elle-même de lire la vue ICM si vous l'avez mise en place, et Google Ads ou SKAN sinon. La configuration d'ICM pour chaque route d'intégration et la façon dont je réconcilie Google Ads, le MMP et SKAN ont chacune leur article.

Certains écarts n'ont rien à voir avec les définitions. Sur un compte Google que j'ai piloté, l'événement de revenu envoyait 1$ au lieu de 0$ quand une conversion n'avait pas de valeur, ce qui a gonflé le ROAS rapporté par Google partout, et surtout sur iOS. C'est le compte derrière mon test des stratégies d'enchères, et c'est le genre de bug que la vue de réconciliation sert à repérer.

Comment fonctionnent SKAN 4 et AdAttributionKit pour les campagnes Meta sur iOS ?

C'est Apple qui décide de ce qui revient : jusqu'à trois postbacks retardés par annonce gagnante, chacun avec une valeur de conversion que votre app écrit sur l'appareil, et d'autant moins de détail que la campagne est petite. Chez Meta, chaque ensemble de publicités de promotion d'app iOS utilise soit cette attribution SKAdNetwork, soit l'Aggregated Event Measurement propre à Meta, selon celle à laquelle votre événement d'optimisation est éligible.

SKAN 4 et AdAttributionKit renvoient tous deux trois fenêtres de postback, et seule la première peut porter une valeur fine. Apple redescend vers une valeur grossière ou vers rien du tout quand une campagne est trop petite pour protéger la foule. Le premier paiement d'un essai de 7 jours tombe le jour 7 ou 8, dans la deuxième ou la troisième fenêtre, sous forme de valeur grossière, des jours plus tard. C'est pour cela que le schéma doit être conçu autour de votre funnel et de votre volume au lieu d'être copié d'un modèle type, et c'est pour cela que trop de découpages par géo et par créa font passer chaque campagne sous le seuil en même temps. Je détaille dans SKAN peut-il mesurer le paiement après un essai gratuit la fenêtre où tombe chaque durée d'essai et qui écrit la valeur.

Qui peut réparer la CAPI et le mapping des événements pour Meta ?

Quelqu'un qui répond de tout le chemin de l'événement, du SDK de l'app et du MMP jusqu'au backend d'abonnement et à Events Manager, parce que la plupart des bugs de signal chez Meta se trouvent là où deux de ces pièces se rencontrent. Sur un retainer, c'est moi, avec un ingénieur en attribution de mon réseau pour le travail sur le SDK et côté serveur, et un développeur de votre côté capable de déployer des changements.

La Conversions API pour les événements app envoie depuis votre serveur les mêmes événements que le SDK ou le MMP envoient depuis l'appareil, et Meta les déduplique par identifiant d'événement. Son rôle, c'est la complétude et la valeur : les renouvellements, les remboursements et les conversions qui ont lieu quand l'app est fermée, chacun avec une valeur et une devise. Elle ne restaure pas l'attribution pour les utilisateurs qui ont refusé le tracking, ces événements continuent de passer par Aggregated Event Measurement. Cela vaut la peine d'être fait, ce n'est pas un contournement. Quand un événement arrive chez Meta et reste marqué inéligible à AEM, les vérifications pour chaque route sont dans pourquoi les événements d'essai et d'achat sont inéligibles à AEM chez Meta.

pLTV et optimisation de la valeur

Un modèle prédit la valeur de chaque nouvel utilisateur à partir de son comportement sur le premier jour ou deux. Ce chiffre est envoyé à la plateforme comme valeur d'achat, ou sur iOS il est compressé dans la valeur de conversion. La plateforme enchérit alors pour des utilisateurs qui ressemblent à vos prédictions de forte valeur. Quel événement et quel mode d'enchère conviennent à quelle app, c'est détaillé à partir de 1,2M$ de dépense Meta.

Chez Videa, cette couche, un signal d'achat CAPI sur mesure et une LTV prédite dans l'enchère, est ce qui a fait passer le D0 ROAS de 20% à 43% lors de la semaine record. Un test à 606K$ a tranché que la valeur à J0 prédit mieux le D28 ROAS que le coût par achat.

Sur quel événement optimiser ?

Voici les trois questions que je pose, dans l'ordre, avant qu'un compte aille plus loin. L'échelle complète, de l'installation vers le haut, se trouve dans sur quel événement une app d'abonnement doit optimiser.

1. Les événements payants franchissent-ils le seuil d'apprentissage de la plateforme à votre volume ? Le repère de Meta est d'environ 50 résultats par ensemble de publicités dans la semaine qui suit sa dernière modification importante. Si ce n'est pas le cas, optimisez sur le début d'essai plus un événement d'activation. Si c'est le cas, passez à la question 2.
2. Le passage de l'essai au payant est-il sain ? Si non, restez sur le début d'essai plus un événement d'activation. Les deux conditions doivent être réunies avant de changer. Si oui, passez à l'achat et allez à la question 3.
3. La valeur que vous enverriez est-elle corrélée à ce que les utilisateurs vont ensuite payer ? Si non, restez sur l'achat. Si oui, envoyez la valeur. La LTV prédite demande trois choses de plus : une prédiction calibrée sur des cohortes qui ont réellement mûri, assez de volume, et une plateforme qui la reçoit avant que la fenêtre d'attribution ne se ferme. Activée trop tôt, elle optimise vers les mauvais utilisateurs avec une grande confiance.

Réconcilier le ROAS de plateforme avec le revenu d'abonnement, à travers les pays

Les plateformes comptent les conversions attribuées et modélisées dans leur propre fenêtre, au prix brut, à la date du clic. RevenueCat compte les reçus à la date de la transaction, net des remboursements, dans une seule devise. Les versements du store arrivent selon un calendrier fiscal, nets de commission et de taxes locales. Ce sont des écarts structurels, et ils sont attendus. Un écart qui change de taille d'un mois à l'autre cache généralement un bug : un événement d'achat dupliqué, une incohérence de devise, une valeur qui atteint une plateforme et pas l'autre.

Le ROAS multi pays ajoute la maturité de cohorte. Un pays dont les utilisateurs paient annuellement paraît pire à J7 et meilleur à J90 qu'un pays qui vend au mois, donc je compare les cohortes au même âge, dans une seule devise, net de commission, avant de décider quel pays reçoit du budget. L'audit à 383K$ montre à quoi cela ressemble sur un compte réel, et combien d'achats il faut avant qu'un ROAS ne veuille dire quelque chose fixe le seuil pour chaque découpage.

Comment se déroule le travail

L'ingénierie du signal fait partie du retainer, et elle vient en premier. La lecture commence par le growth audit : ce que chaque plateforme reçoit actuellement, vers quoi elle optimise, et la comparaison à quatre voies avec l'écart attendu consigné par écrit. Après la lecture, certaines équipes mettent en œuvre les corrections elles-mêmes à partir de la liste priorisée, avec l'effort d'ingénierie estimé pour chaque point. D'autres me demandent de piloter les comptes. Les deux fonctionnent.

Pour le travail sur le SDK et tout ce qui tourne sur vos serveurs, je fais venir un ingénieur en attribution de mon réseau. Je conçois cette couche et j'en garde la responsabilité, les mains techniques sont des spécialistes. Il vous faut un développeur capable de déployer des changements pendant la mission, et un accès à Events Manager, au MMP, à RevenueCat ou à votre backend d'abonnement, et aux comptes publicitaires.

Si vous en êtes avant un retainer et que vous voulez le diagnostic sans l'engagement, une session payante de 90 minutes couvre votre configuration et ce qu'il faut réparer, dans quel ordre. Elle se réserve via le même calendrier que l'appel découverte.

Questions fréquentes