SKAN mesure-t-il le paiement d'abonnement après l'essai gratuit ?

Parfois, et uniquement sous forme de coarse value (low, medium ou high), jamais de fine value. Le prélèvement qui suit un essai gratuit a lieu côté Apple et arrive chez RevenueCat en server to server, alors que SKAN n’enregistre que ce que l’app écrit sur l’appareil. Le paiement ne compte donc que si votre unique composant d’écriture de la valeur de conversion s’exécute dans l’app avant la fermeture de la fenêtre où il tombe. La durée de l’essai change la réponse. Sans essai, le premier paiement peut arriver dans la première fenêtre, en fine value. L’essai gratuit le plus court qu’Apple propose (3 jours) le repousse déjà dans la deuxième fenêtre, un essai de 1 semaine généralement dans la troisième, en coarse value uniquement dans les deux cas. Un essai qui se termine après le jour 35 manque toutes les fenêtres.

Périmètre : les apps subscription iOS avec RevenueCat, un MMP (AppsFlyer et Singular sont les deux dont j’ai vérifié les règles de relais) ou Firebase, sur SKAdNetwork 4 et AdAttributionKit, qui achètent sur Meta et Google, toutes régions. J’ai vérifié chaque fait sur les plateformes le 1er octobre 2026, sur la page de l’éditeur lui-même.

Que se passe-t-il entre “RevenueCat a enregistré le paiement” et “l’appareil a mis à jour la valeur” ?

Six étapes, et l’écart se situe entre la troisième et la cinquième.

1. Premier lancement. L’horloge d’Apple démarre ici. La page SKAdNetwork Receiving postbacks in multiple conversion windows définit trois fenêtres à partir du premier lancement : jours 0 à 2, 3 à 7 et 8 à 35. Seul le premier postback peut porter une fine value, que la méthode de mise à jour d’Apple définit comme un nombre de 0 à 63.
2. Début de l’essai. Le plus souvent sur le paywall, lors de la première session, donc dans la fenêtre 1, là où le SDK de l’appareil le voit.
3. Paiement confirmé. Quand l’essai se termine, l’App Store prélève le paiement. La page Event Types and Fields de RevenueCat présente un premier prélèvement réussi comme un RENEWAL avec is_trial_conversion à true. Un essai que personne n’a annulé n’est pas un paiement, et un entitlement actif non plus. La page Reducing involuntary subscriber churn d’Apple indique qu’un renouvellement échoué entre en billing retry pendant 60 jours au maximum, et qu’avec Billing Grace Period activé, l’utilisateur garde un accès complet pendant qu’Apple essaie d’encaisser.
4. Relais serveur. RevenueCat envoie l’événement au MMP server to server. La page SKAN Conversion Studio d’AppsFlyer indique qu’AppsFlyer recalcule la valeur, que le SDK met à jour l’appareil si l’app est ouverte, et que sinon le serveur attend la prochaine ouverture de l’app, qui doit avoir lieu avant l’expiration de la fenêtre, faute de quoi l’événement est ignoré. La page S2S Support for Conversion Models FAQ de Singular décrit la même attente pour une fonctionnalité que Singular active à votre demande. Elle ne marche qu’en mode SKAN managé, et si la fenêtre se ferme ou si l’utilisateur ne rouvre jamais l’app, Singular ne peut pas mettre la valeur à jour.
5. Exécution sur l’appareil. Le SDK appelle la méthode de mise à jour d’Apple. La valeur est comptée dans la fenêtre ouverte à ce moment, pas dans celle où le prélèvement a eu lieu. La page updatePostbackConversionValue d’Apple indique que la fine value est ignorée après la première fenêtre.
6. Postback. Une fois la fenêtre fermée, Apple envoie le postback après un délai aléatoire : 24 à 48 heures pour le premier, 24 à 144 heures pour le deuxième et le troisième. Apple indique aussi que l’app doit mettre à jour la valeur pendant chaque fenêtre pour être éligible à plus d’un postback, donc un utilisateur qui n’ouvre jamais l’app entre le jour 3 et le jour 7 laisse la fenêtre 2 sans rien à rapporter. Une publicité dans le palier le plus bas d’Apple, le Tier 0, ne reçoit ni deuxième ni troisième postback.

Qui écrit la valeur de conversion ?

Un seul point d’écriture, sur l’appareil. Chaque méthode de mise à jour documentée par Apple est un appel que fait l’app. Je n’ai trouvé aucune API serveur.

RevenueCat n’est pas ce point d’écriture. Sa page Meta Ads dit qu’il “doesn’t update SKAN conversion values” (il ne met pas à jour les valeurs de conversion SKAN) et recommande qu’un seul composant fasse la mise à jour, que ce soit l’app, le SDK Meta ou un MMP, pour que les valeurs n’entrent pas en conflit. Sa page Singular indique qu’il ne peut pas les modifier à partir de ses événements serveur. Sa page AppsFlyer vous demande aussi de supprimer le suivi de revenu côté client pour éviter le double comptage, ce qui veut dire qu’avec cette configuration même un achat du jour 0 ne peut atteindre le SDK AppsFlyer que par le relais serveur.

Les éditeurs mettent en garde contre un deuxième point d’écriture. La page Set up your SKAdNetwork conversion value schema de Google indique qu’il est fortement recommandé de configurer le schéma à un seul endroit. La version Google Analytics de Set up your SKAdNetwork conversion value schema a une option qui permet au SDK Firebase de définir la valeur pour chaque fenêtre, et la page Get started with Google Analytics for iOS+ de Firebase indique que le SDK enregistre automatiquement l’app auprès de SKAdNetwork sauf si vous réglez GOOGLE_ANALYTICS_REGISTRATION_WITH_AD_NETWORK_ENABLED sur NO. L’article SKAN 4.0 anomalies explained d’AppsFlyer indique que toute mise à jour écrase la précédente, y compris les mises à jour de type SKAN 3 et les enregistrements d’install venant d’un autre SDK. Cet article a paru pour la première fois en août 2023 et c’est le récit d’un éditeur, pas celui d’Apple. La page de la méthode d’Apple ne dit pas ce qui se passe quand deux SDK l’appellent.

AdAttributionKit n’ajoute pas de point d’écriture. La page Understanding AdAttributionKit and SKAdNetwork interoperability d’Apple indique que les appels de valeur de conversion SKAdNetwork sont reproduits dans AdAttributionKit et qu’une seule impression l’emporte sur les deux frameworks.

Dans quelle fenêtre le premier paiement peut-il tomber ?

Le tableau suppose que l’essai démarre lors de la première session. Un essai démarré le jour 2 décale chaque date de deux jours. Les durées d’essai sont celles de l’essai gratuit qu’Apple liste dans Set up introductory offers for auto-renewable subscriptions, la plus courte étant de 3 jours. Les cellules des fenêtres 2 et 3 ne valent que pour les publicités en Tier 1 ou au-dessus, car une publicité en Tier 0 ne reçoit aucun postback après le premier.

Ajoutez le délai de postback pour obtenir un calendrier. Un paiement de la fenêtre 3 arrive chez votre MMP entre le jour 36 et le jour 41 après le premier lancement, sauf si la fenêtre a été verrouillée plus tôt.

Que couvre le guide de RevenueCat lui-même, et que laisse-t-il de côté ?

Le guide How to use RevenueCat server-to-server events for SKAdNetwork attribution de RevenueCat, publié le 18 février 2025, est le guide d’éditeur le plus détaillé que je connaisse sur ce problème. Il place les essais de moins de sept jours dans la fenêtre deux et les essais de sept jours dans la fenêtre trois, ce qui correspond au tableau, et il propose deux correctifs : vérifier le statut de l’essai chaque fois que l’app revient au premier plan, et un push silencieux quand l’essai se termine. Il indique aussi que son approche ne garantit pas une exactitude complète. Ce que j’y ajoute :

• Les limites d’Apple sur le push silencieux. La page Pushing background updates to your App d’Apple indique que les notifications en arrière-plan sont peu prioritaires, que leur livraison n’est pas garantie, que le système peut les brider (Apple dit de ne pas en envoyer plus de deux ou trois par heure), et qu’une notification en attente est supprimée si l’app est fermée de force. L’une des conclusions du guide, selon laquelle les notifications serveur d’Apple, via RevenueCat, permettent de suivre les conversions sans que l’utilisateur ouvre l’app, va plus loin que ce que la documentation d’Apple permet d’affirmer.
• Le point d’écriture. Le code du guide écrit dans SKAdNetwork depuis l’app. Si le SDK de votre MMP écrit aussi, vous avez maintenant deux points d’écriture. Faites plutôt passer l’événement par votre unique point d’écriture.
• Paiement contre entitlement. La vérification du guide lit un entitlement actif qui n’est plus dans sa période d’essai. Mappez plutôt la valeur sur le prélèvement encaissé, car Billing Grace Period peut garder un entitlement actif pendant qu’Apple essaie encore d’encaisser.
• Ce que les plateformes font de la valeur, dans la section suivante.
• Les changements de framework depuis. La page AdAttributionKit Updates d’Apple liste des changements en juin 2024 et en juin 2025, et rien en 2026 à la date de cette vérification.

Que font Google et Meta d’un paiement d’essai en coarse value ?

Google dit qu’il ne l’utilise pas. La page de Google Ads sur le schéma indique que la modélisation des conversions de Google n’utilise que les fine values et que “we currently do not support SKAN version 4’s coarse conversion values” (nous ne prenons actuellement pas en charge les coarse conversion values de SKAN version 4). La même page demande plus de 10 événements de conversion par jour pour chaque événement du schéma et environ 50 installs par jour. Ce sont les recommandations de Google pour le schéma, pas le seuil de confidentialité d’Apple, et Apple ne publie aucun nombre d’installs pour ses paliers. Donc, pour les App Campaigns iOS, le signal SKAN sur lequel Google apprend, c’est ce qui se passe pendant les deux premiers jours. Les conversions modélisées de Google et son Integrated Conversion Measurement sont distinctes de SKAN, et je mets les trois côte à côte dans pourquoi Google Ads, le MMP et SKAN rapportent des conversions iOS différentes.

Meta a sa propre configuration. Configure Apple’s SKAdNetwork in Meta Events Manager vous permet de configurer des événements avec des fine values et des coarse values pour SKAdNetwork 4, soit d’après les recommandations de Meta, soit en important le schéma de votre MMP, soit à la main. La page indique aussi que Meta déploie progressivement la prise en charge de SKAdNetwork 4, qui peut ne pas encore être disponible pour vous. Prepare your app integration for Apple’s SKAdNetwork demande aux apps qui utilisent le Facebook SDK for iOS d’être en version 16.2.1 ou ultérieure, et déconseille de diminuer les valeurs de conversion ou de verrouiller les fenêtres. AppsFlyer propose les deux : un réglage qui laisse un revenu négatif, comme un remboursement, abaisser la valeur, et un verrouillage qui envoie le postback plus tôt. Si l’essentiel de votre budget iOS part sur Meta, décidez de ces deux réglages en gardant sous les yeux le conseil de Meta. La page de configuration indique que les événements avec des coarse values peuvent améliorer la performance des publicités. Elle ne dit pas comment la diffusion pondère une coarse value de la fenêtre 3, et je n’ai trouvé aucune page de Meta confirmant les postbacks AdAttributionKit, donc je n’affirme ni l’un ni l’autre.

Qu’est-ce que cela change pour l’événement d’optimisation Meta ?

Sur SKAN, le paiement de l’essai arrive tard, en coarse value, et seulement pour les utilisateurs qui ouvrent l’app après avoir payé. Un événement de la première session arrive dans la fenêtre 1 et peut être une fine value. Les événements que SKAN peut remonter vite à Meta sont donc des événements précoces : un début d’essai, un début d’essai avec une condition qui prédit le paiement, ou une formule payante achetée le jour 0. Le paiement peut tout de même figurer dans le schéma pour les fenêtres 2 et 3, comme coarse value. Je l’y lirais comme un rapport tardif sur la cohorte et je ne compterais pas dessus pour orienter la diffusion, puisque Meta ne dit pas comment la diffusion le pondère. L’Aggregated Event Measurement de Meta est une voie distincte avec ses propres règles, et quand Events Manager y marque l’essai ou l’achat comme inéligible, les vérifications se trouvent dans pourquoi les événements d’essai et d’achat sont inéligibles à Meta AEM. Le choix de l’événement lui-même est traité dans pour quel événement une app subscription doit optimiser.

Qu’est-ce qui change pour un jeu mobile ?

L’essentiel du problème de relais disparaît, parce que le paiement a lieu dans la session. Quand le SDK du MMP enregistre un achat in app sur l’appareil lui-même, il peut écrire la valeur dans cette session, et la fenêtre 1 peut la porter comme fine value. Le Conversion Studio d’AppsFlyer peut mesurer le revenu global, revenu publicitaire compris, via un seul événement, af_skad_revenue, et note que les valeurs de revenu publicitaire ne deviennent jamais négatives. Un jeu hybride peut répartir ses 64 fine values de la fenêtre 1 entre achats, revenu publicitaire et progression, et utiliser les coarse values des fenêtres 2 et 3 pour la rétention ou un premier achat.

La partie la plus difficile est le volume. Apple fixe le palier d’après la taille de la foule, un soft launch est petit par nature, et une publicité en Tier 0 reçoit un seul postback sans valeur. Des campagnes moins nombreuses et plus grosses franchissent les paliers plus vite, ce que je couvre dans moins de campagnes, plus de signal. Ce qu’un soft launch doit prouver, et le schéma SKAN qui va avec, se trouve sur l’acquisition d’utilisateurs pour jeux mobiles.

Comment le tester avant que la dépense augmente ?

Je ferais quatre vérifications avant qu’un schéma d’essai porte du budget. Chacune découle des pages d’éditeurs citées plus haut.

1. Le point d’écriture. Un seul SDK appelle la méthode de mise à jour d’Apple, et Google et Meta reçoivent le même schéma que celui qu’il suit. L’option de Firebase pour définir les valeurs et les mises à jour SKAN de tout autre SDK sont désactivées.
2. L’événement. Le paiement est mappé sur le prélèvement encaissé, le RENEWAL de RevenueCat avec is_trial_conversion, pas sur un début d’essai plus une absence d’annulation.
3. Les deux voies de relais. AppsFlyer documente deux voies pour un événement serveur : le SDK met à jour la valeur immédiatement si l’app est en cours d’utilisation, ou le serveur la retient jusqu’au prochain lancement de l’app. Suivez une conversion d’essai relayée sur chaque voie avec un appareil de test et notez quand l’appel de mise à jour s’est exécuté.
4. La lecture de cohorte. Pour une cohorte arrivée à maturité, au moins le jour 41 après le premier lancement, comparez les conversions d’essai que RevenueCat enregistre pour les utilisateurs que votre MMP attribue à ce réseau avec les valeurs de paiement que votre MMP a décodées pour les fenêtres 2 et 3. L’écart mélange les paiements écrits trop tard, les publicités en Tier 0 qui ne reçoivent aucun postback ultérieur et les différences d’attribution entre les deux sources, donc rapportez-le comme un écart. Ne le gonflez pas pour combler la différence.

Que prends-je en charge sur ce sujet ?

Je traite cela dans le signal engineering : un seul point d’écriture, un schéma construit autour de votre essai et de votre volume, et une attente formulée par écrit sur ce que SKAN montrera et ne montrera pas, avant que quiconque juge une campagne là-dessus. Pour savoir si la mesure est en cause, je la vérifie dans le growth audit.

Sources

Toutes vérifiées le 1er octobre 2026.

• Apple Developer : Receiving postbacks in multiple conversion windows pour SKAdNetwork, et la page AdAttributionKit du même nom, sans date de page.
• Apple Developer : Set up introductory offers for auto-renewable subscriptions, sans date de page.
• Apple Developer : Understanding AdAttributionKit and SKAdNetwork interoperability, sans date de page.
• Apple Developer : updatePostbackConversionValue(_:coarseValue:lockWindow:completionHandler:), sans date de page.
• Apple Developer : AdAttributionKit Updates, entrées de juin 2024 et de juin 2025.
• Apple Developer : Pushing background updates to your App, sans date de page.
• Apple Developer : Reducing involuntary subscriber churn, sans date de page.
• Google Ads Help : Set up your SKAdNetwork conversion value schema, sans date de page.
• Google Analytics Help : Set up your SKAdNetwork conversion value schema, sans date de page.
• Firebase : Get started with Google Analytics for iOS+, modifié le 1er octobre 2026.
• Meta Business Help Center : Configure Apple’s SKAdNetwork in Meta Events Manager, sans date de page.
• Meta Business Help Center : Prepare your app integration for Apple’s SKAdNetwork, sans date de page.
• AppsFlyer : SKAN Conversion Studio, modifié le 26 avril 2026.
• Blog AppsFlyer : SKAN 4.0 anomalies explained, publié le 8 août 2023, modifié le 13 novembre 2025.
• Singular : S2S Support for Conversion Models FAQ, modifié le 17 décembre 2024.
• Documentation RevenueCat : Meta Ads, AppsFlyer, Singular et Event Types and Fields, sans date de page.
• Blog RevenueCat : How to use RevenueCat server-to-server events for SKAdNetwork attribution, publié le 18 février 2025, modifié le 19 février 2025.