SKAdNetwork - SKAN

SKAdNetwork impose à l'acquisition iOS une conversion agrégée, anonyme et censurée. Le comprendre, c'est cesser de piloter contre ses biais pour piloter avec eux : réconciliation conservative, KPI de nouvel utilisateur, LTV prédictive.

Verre mi-transparent : données nettes à gauche, brouillées et masquées à droite - le privacy threshold SKAN illustré
Les chiffres que tu ne vois pas

SKAdNetwork (SKAN) est le protocole de mesure publicitaire qu’Apple a mis en place avec iOS 14.5, en parallèle d’App Tracking Transparency (ATT). Là où l’ancien système permettait de tracer chaque utilisateur individuellement via son IDFA, SKAN inverse la logique : c’est l’appareil lui-même qui génère et envoie une attribution agrégée, anonyme et bornée - sans que le réseau publicitaire ni le MMP (Mobile Measurement Partner) ne voient qui a installé quoi.

Le protocole a été conçu pour permettre la mesure des campagnes sans accéder à des données individuelles. En pratique, il envoie un seul postback par install attribué : un signal sans identifiant utilisateur, sans horodatage précis, contenant une valeur de conversion sur 6 bits configurée par l’annonceur. La documentation de ses biais est principalement le fait de praticiens UA - notamment le Mobile User Acquisition Show et les analyses d’Eric Seufert sur Mobile Dev Memo - travaillant dans des conditions réelles. Certains effets macro (impact de l’ATT sur l’efficacité publicitaire) ont fait l’objet d’une mesure économétrique rigoureuse, via des panels traitement/contrôle publiés et relayés par Eric Seufert.

SKAN vit dans un écosystème en mouvement : la plateforme a plafonné à ~25 % d’adoption en 2025 aux États-Unis et son avenir dépend de décisions d’Apple non encore arrêtées. Ce qui ne bouge pas : la mécanique de ses biais, et la façon d’en tenir compte dans le pilotage UA iOS.

Cette page couvre la mécanique de SKAN, ses biais les plus coûteux, et comment piloter avec eux. L’ingénierie du signal - comment concevoir sa conversion value sous la contrainte des 6 bits - est traitée séparément.

L’essentiel en 5 points

  • SKAN génère un seul postback par install : agrégé, anonyme, sans IDFA ; la conversion value (6 bits, fenêtre courte) est la seule matière que l’annonceur contrôle.
  • Le privacy threshold censure les valeurs de conversion sous ~10 installs/jour/campagne : des CPA à 700-1 000 $ peuvent n’être que des artefacts de censure, pas un effondrement de l’efficacité.
  • Deux chiffres SKAN issus de réseaux différents ne se comparent pas : Facebook, TikTok et Snapchat appliquent le protocole sur des périmètres de campagne distincts.
  • Dashboard vs facture : les réseaux reportent en probabiliste mais facturent sur SKAN - écart structurel de 30 à 40 % à intégrer dans tout pilotage.
  • La bonne posture n’est pas de contourner SKAN, mais de piloter avec ses contraintes : réconciliation sur le billable spend, KPI de nouvel utilisateur Apple ID, LTV prédictive comme signal de qualité.

Un seul postback, trois variables : la contrainte de fond

Le pendant app de « le crédit n’est pas la cause » plante le décor : depuis ATT, la chaîne déterministe clic → install → achat qui fondait la mesure mobile est techniquement rompue. Deux reconstructions incompatibles se disputent le terrain - SKAdNetwork agrégé d’un côté, fingerprinting gonflé de l’autre.

SKAN est un cadre volontairement pauvre. À chaque install attribué, Apple renvoie un seul postback émis depuis l’appareil, en last-touch, sans identifiant utilisateur ni horodatage d’install. Ce postback part vers le réseau publicitaire - pas vers le MMP - et ne contient que trois variables exploitables : l’éditeur source, l’identifiant de campagne posé par le réseau, et une conversion value configurée par l’annonceur. Ces 6 bits ne sont pas standardisés d’un réseau à l’autre (la valeur 17 peut signifier n’importe quoi selon l’annonceur) et sont captés dans une fenêtre courte. Toute la mesure UA post-ATT se replie donc sur cet encodage : transformer une propension LTV dans un espace contraint est devenu un métier à part entière.

Deux chiffres SKAN ne se comparent pas

L’argument de vente de SKAN était l’uniformité : un terrain de comparaison identique entre partenaires, là où le probabiliste fragmenté (chaque réseau son propre reporting) est une boîte noire. La promesse est en partie trahie par la façon dont les réseaux instrumentent le protocole.

« Une campagne SKAN » ne veut pas dire la même chose partout. Facebook expose 9 campagnes × 5 ad groups, TikTok 11 × 2 - chacun traitant créatifs ou ad sets comme des campagnes SKAN distinctes. Conséquence directe : les seuils d’installs journaliers au-delà desquels la censure devient minimale (Facebook ~88, Snapchat ~75, TikTok ~90) ne sont pas comparables entre réseaux, parce que le périmètre d’une campagne SKAN diffère selon la plateforme. Le level playing field est réel à l’intérieur d’un réseau, illusoire entre réseaux. Il ne remplace pas un test d’incrémentalité pour arbitrer un budget cross-canal.

Le piège du seuil : un régime qui pénalise les petits budgets

Le cœur du biais SKAN est le privacy threshold (ou crowd anonymity) : quand le volume d’installs d’une campagne est faible, Apple estime qu’on pourrait ré-identifier un utilisateur à partir des conversions, et censure la valeur de conversion. L’effet est brutal et contre-intuitif : selon une étude AppsFlyer sur son portefeuille d’apps, en dessous de ~10 installs par jour et par campagne, près de 90 % des valeurs de conversion sont obfusquées. Le seuil se déclenche sur le nombre d’installs, pas sur le nombre d’événements post-install - peu importe le volume d’achats, c’est le compte d’installs journalier qui décide. Résultat : des CPA affichés de 700 à 1 000 $ sur des campagnes dont le CPA réel tournait à 30-50 $.

Le mécanisme crée un cercle vicieux structurel : trop peu de volume pour dépasser le seuil, pas de signal pour scaler, donc pas de volume - avantage mécanique aux gros budgets. Ce biais rejoint ce que l’économétrie a mesuré de l’ATT lui-même : Eric Seufert relaie les travaux de Daniel McCarthy montrant que l’efficacité des publicités à optimisation de conversion Meta a chuté d’environ 37 % (panels traitement vs contrôle), et que les petites entreprises dépendantes de Meta iOS ont encaissé un choc de revenus deux fois plus lourd (~-68 % relatif), en partie faute de diversification possible. SKAN n’a pas créé ce déséquilibre, il l’inscrit dans la mesure : la granularité qu’il refuse aux petits est précisément celle dont ils auraient le plus besoin.

La facture ne dit pas la vérité du dashboard

Deuxième piège de pilotage : le chiffre qu’on regarde tous les jours n’est pas celui qu’on paie. La plupart des réseaux optimisent et reportent en probabiliste dans le dashboard quotidien, mais facturent sur les données SKAN - d’où un écart de 30 à 40 % entre la dépense affichée et la facture réelle du mois, documenté par le Mobile User Acquisition Show. Piloter un CPA ou un ROAS sur le dashboard réseau, c’est sous-estimer son coût réel d’un tiers.

L’intégrité du signal a par ailleurs posé un problème d’architecture. Dans la version initiale, les postbacks transitaient par les réseaux, qui pouvaient modifier les champs non signés par Apple. Cas documenté par le Mobile UA Show : au moins un réseau remplaçait des valeurs null (données masquées par le seuil) par des zéros (install sans valeur), deux choses sémantiquement distinctes, gonflant artificiellement ses conversions. iOS 15 a corrigé la faille en imposant aux réseaux de transmettre les postbacks bruts au MMP, rendant la vérification indépendante enfin possible.

Si ta scale-up plafonne aujourd’hui

1. Réconcilier sur le billable spend, pas sur le dashboard.

Pour comparer un ad network à Meta ou TikTok, prendre les conversions SKAN et le billable spend comme actuals - ne jamais mélanger les conversions probabilistes hétérogènes des dashboards. Moins flatteur, mais comparable.

2. Piloter sur le coût par nouvel utilisateur Apple ID, pas sur le CPI device.

Ce KPI oblige à suivre le taux de redownload par canal pour isoler les vrais nouveaux. C’est la seule métrique cohérente avec le protocole SKAN.

3. Ne pas confondre censure et inefficacité.

Un CPA SKAN gonflé sous le seuil n’est pas le signe d’une campagne sous-performante : c’est un artefact statistique. L’interprétation correcte requiert de savoir si la campagne est au-dessus ou en dessous du seuil d’installs journaliers.

4. Mesurer la LTV cohorte côté app, indépendamment de l’attribution SKAN.

La LTV, la rétention et les cohortes au niveau app restent calculables via l’IDFV dans le MMP. SKAN supprime le lien install → campagne, pas la mesure agrégée de la valeur. Avant de modéliser l’attribution, vérifier que ces métriques app-level sont bien collectées.

5. Envisager la LTV prédictive dès que les budgets iOS sont significatifs.

Un modèle ML appliqué aux cohortes où l’attribution est complète permet d’envoyer un signal de conversion précis sans attendre 30-90 jours. Son ROI croît avec les budgets iOS - c’est l’investissement qui débloque l’optimisation à la valeur plutôt qu’au volume.

Pour aller plus loin

  • Attribution Plateforme et Mobile (MMP) - Post-ATT, l’attribution mobile déterministe s’est effondrée : ce que rapporte la régie est soit agrégé (SKAdNetwork), soit reconstruit par fingerprinting biaisé - à traiter comme probabiliste, à corriger par l’incrémentalité.
  • Campagnes App Mobile - L’app mobile n’est pas un canal de plus mais un autre écosystème digital : post-ATT, l’attribution régie y est une illusion par construction. L’UA se pilote en blended et LTV cohorte, un canal maîtrisé d’abord.
  • Rétention et LTV - La croissance ne vient pas de la rétention mais de la pénétration : la rétention est le sol de l’économie unitaire - matériel en revenu récurrent, où elle protège la valeur cohorte que le dashboard ne mesure pas.

Sources

ℹ️ À propos de cette page

Reaching Kibo explore les vrais moteurs de la croissance des scale-ups B2C - et comment les mettre en pratique. Cette page appartient à Basecamp, le playbook du projet.

Elle est rédigée par IA, d’après le cadre et la direction que je donne. Une erreur, un désaccord, une source à ajouter ? Écris-moi : romain@reachingkibo.com.