Qu'est-ce que le Signal Engineering, et que corrige-t-il après ATT?

Vous êtes probablement ici parce que

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

• Meta rapporte un ROAS, RevenueCat en rapporte la moitié, et les finances ne croient ni l'un ni l'autre. Ils ne concorderont jamais, et personne dans l'équipe ne peut dire pourquoi.
• Vos valeurs de conversion SKAN reviennent vides sur la plupart des campagnes, et personne ne sait pourquoi.
• Meta monte à l'échelle sans problème. Google et TikTok stagnent sur la même création.
• Vous êtes passé à l'optimisation de la valeur et ça a empiré.
• Les débuts d'essai sont bon marché et les conversions payantes ne suivent jamais.
• Trois SDK sont installés dans l'application. Personne ne peut dire lequel contrôle la valeur de conversion.

Ce que le Signal Engineering corrige

Cinq couches, dans l'ordre où je les bâtis.

• La couche d'événements. Une taxonomie d'événements canonique unique pour votre application, cartographiée explicitement vers les événements standards de Meta, les événements de conversion de Google, les événements 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. Le Conversions API for app events de Meta, l'Events API de TikTok et la configuration de conversion d'application de Google par l'intermédiaire de votre MMP ou de Firebase, reliés à votre backend d'abonnement pour que les renouvellements, les remboursements et les conversions d'essai atteignent les plateformes même quand l'application est fermée. Dédupliqués par identifiant d'événement pour que rien ne compte deux fois.
• Le schéma de valeur de conversion iOS. La petite valeur qu'Apple vous permet de renvoyer est le seul signal que vous obtenez après l'installation pour les utilisateurs qui ont refusé le suivi. Je le conçois autour de votre entonnoir et de votre volume, pour que les campagnes franchissent les seuils de confidentialité d'Apple au lieu de ne rien renvoyer. Un seul SDK le contrôle. Quand deux SDK l'écrivent, c'est le dernier appel qui gagne, et en ce moment, c'est habituellement un accident.
• Les signaux de valeur pour l'enchère. 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 corrèle réellement avec ce que les utilisateurs finissent par payer. Une mauvaise valeur apprend à l'algorithme à acheter les mauvais utilisateurs, plus vite.
• La vue de réconciliation. Une comparaison mensuelle des chiffres de la plateforme, du MMP, de RevenueCat et des versements des boutiques, avec les écarts attendus consignés par écrit, pour que la prochaine fois que les chiffres ne concordent pas, vous sachiez en cinq minutes si c'est structurel ou si c'est un bogue.

Ce que ça ne peut pas corriger après ATT, et pourquoi je le dis

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

Je ne promets donc pas d'attribution déterministe. Je promets que les signaux que vous pouvez contrôler sont justes, que les plateformes reçoivent le meilleur intrant possible pour optimiser, et que vous saurez quels écarts sont normaux. Le ROAS de la plateforme et le revenu d'abonnement continueront de ne pas concorder une fois le travail terminé. Ils ne concorderont pas pour des raisons que vous pourrez expliquer. Si un fournisseur 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 concordent pas, aucun n'a nécessairement tort. Ils comptent des choses différentes, sur des fenêtres différentes, avec des délais différents. Le tableau s'appuie sur la documentation de chaque fournisseur, vérifiée le 29 septembre 2026.

Du côté de Google, la mesure iOS demande du travail de votre part. Pour l'Integrated Conversion Measurement, Google exige une campagne d'applications iOS active axée sur 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 exige 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 conception, et la recommandation de Google elle-même est 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 géré, 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 bogue 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 application é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'application iOS utilise soit cette attribution SKAdNetwork, soit l'Aggregated Event Measurement propre à Meta, selon celle à laquelle votre événement d'optimisation est admissible.

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 pourquoi le schéma doit être conçu autour de votre entonnoir et de votre volume au lieu d'être copié d'un modèle, et pourquoi trop de découpages par géo et par création font passer toutes les campagnes sous le seuil en même temps. Dans quelle fenêtre tombe chaque durée d'essai, et qui écrit la valeur, c'est dans SKAN peut-il mesurer le paiement après un essai gratuit.

Qui peut corriger le CAPI et la cartographie des événements pour Meta?

Quelqu'un qui est responsable du parcours complet de l'événement, du SDK de l'application et du MMP jusqu'au backend d'abonnement et à Events Manager, parce que la plupart des bogues de signal chez Meta se trouvent là où deux de ces pièces se rencontrent. Dans 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 livrer des changements.

Le Conversions API for app events envoie depuis votre serveur les mêmes événements que le SDK ou le MMP envoie 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 surviennent quand l'application est fermée, chacun avec une valeur et une devise. Ça ne restaure pas l'attribution pour les utilisateurs qui ont refusé le suivi; ces événements continuent de passer par l'Aggregated Event Measurement. Ça vaut la peine de le faire, mais ce n'est pas un contournement. Quand un événement arrive chez Meta et reste marqué non admissible à AEM, les vérifications pour chaque route sont dans pourquoi les événements d'essai et d'achat ne sont pas admissibles à AEM chez Meta.

pLTV et optimisation de la valeur

Un modèle prédit la valeur de chaque nouvel utilisateur à partir du comportement des un ou deux premiers jours. Ce chiffre est envoyé à la plateforme comme valeur d'achat, ou est compressé dans la valeur de conversion sur iOS. La plateforme enchérit ensuite pour des utilisateurs qui ressemblent à vos prédictions de haute valeur. Quel événement et quel mode d'enchère conviennent à quelle application est détaillé à partir de 1,2 M$ 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 ROAS D0 de 20 % à 43 % lors d'une semaine record. Un test à 606 000 $ a tranché que la valeur du jour zéro prédit mieux le ROAS D28 que le coût par achat.

Sur quel événement devriez-vous 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 application d'abonnement devrait 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 combiné à un événement d'activation. Si c'est le cas, passez à la question 2.
2. Le taux de conversion de l'essai au payant est-il sain? Si non, restez sur le début d'essai combiné à un événement d'activation. Les deux conditions doivent être remplies avant de changer. Si oui, passez à l'achat et allez à la question 3.
3. La valeur que vous enverriez corrèle-t-elle avec ce que les utilisateurs finissent par 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 par rapport à des cohortes qui ont réellement mûri, assez de volume, et une plateforme qui reçoit l'information avant la fermeture de la fenêtre d'attribution. Activée trop tôt, elle optimise vers les mauvais utilisateurs avec une grande confiance.

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

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

Le ROAS sur plusieurs pays ajoute la maturité des cohortes. Un pays dont les utilisateurs paient annuellement paraît pire au jour 7 et meilleur au jour 90 qu'un pays qui vend au mois, donc je compare les cohortes à âge égal, dans une seule devise, net de commission, avant de décider quel pays reçoit du budget. L'audit à 383 000 $ montre à quoi ça ressemble sur un compte réel, et le nombre d'achats qu'il faut à un ROAS avant qu'il veuille dire quelque chose fixe le seuil pour chaque découpage.

Comment le travail se déroule

Le Signal Engineering fait partie du retainer, et il 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 volets avec l'écart attendu consigné par écrit. Après la lecture, certaines équipes appliquent elles-mêmes les corrections à partir de la liste priorisée, avec l'effort d'ingénierie estimé pour chaque élément. D'autres me demandent de gérer les comptes. Les deux options conviennent.

Pour le travail sur le SDK et tout ce qui tourne sur vos serveurs, je fais appel à un ingénieur en attribution de mon réseau. Je conçois et je pilote la couche; les mains techniques sont des spécialistes. Il vous faut quelqu'un capable de livrer des changements pendant le mandat, ainsi qu'un accès en lecture à Events Manager, au MMP, à RevenueCat ou à votre backend d'abonnement, et aux comptes publicitaires.

Si vous en êtes à un stade antérieur à un retainer et que vous voulez le diagnostic sans le mandat, une session payante de 90 minutes couvre votre configuration et ce qu'il faut corriger, et dans quel ordre. Elle se réserve dans le même calendrier que l'appel initial.

Questions fréquentes