Schéma des valeurs de conversion SKAdNetwork 4.0 : valeurs fines, valeurs grossières et fenêtres de conversion

Comment configurer un schéma de valeurs de conversion SKAdNetwork 4.0 ? Un schéma de valeurs de conversion SKAdNetwork 4.0 associe des événements post-installation ou des signaux de revenus à des valeurs fines allant de 0 à 63 ainsi qu'à des valeurs grossières (low, medium, high). Le niveau de données de postback d'Apple détermine quelle représentation de la valeur de conversion et quels autres champs sensibles à la confidentialité peuvent apparaître dans un postback éligible.

L'IDFA (Identifier for Advertisers) est l'identifiant publicitaire réinitialisable d'Apple pour la mesure publicitaire sur iOS. Le cadre ATT (App Tracking Transparency) d'Apple a transformé l'accès à l'IDFA, passant d'une disponibilité système par défaut à un accès autorisé par l'utilisateur, faisant ainsi évoluer l'attribution mobile d'une approche de rapprochement inter-applications déterministe vers des cadres de mesure respectueux de la vie privée.

Comprendre les hiérarchies de valeurs de conversion de SKAdNetwork 4.0

L'évolution structurelle : du postback unique de SKAN 3.0 à la mesure multi-fenêtre de SKAN 4.0

Sous SKAdNetwork 2.0 et 3.0, les annonceurs s'appuyaient sur une valeur de conversion unique et un minuteur glissant de 24 heures. Pour SKAN 3 et les versions antérieures, une valeur de conversion plus élevée pouvait redémarrer le minuteur glissant de 24 heures, ce qui incitait les développeurs à concevoir des schémas de valeurs de conversion à croissance monotone. Lorsqu'un utilisateur complétait un événement de conversion in-app, le SDK client intégré invoquait une API système pour mettre à jour un entier unique de 6 bits (de 0 à 63).

Le modèle de postback unique de SKAN offrait une visibilité limitée sur l'engagement post-installation survenant après la période de conversion initiale pour les applications mobiles dotées de tunnels de conversion plus longs, telles que les plateformes de commerce électronique par abonnement et les jeux mobiles de type mid-core.

SKAdNetwork 4.0 a restructuré ce paradigme de mesure en introduisant une structure multi-fenêtre SKAdNetwork 4.0 comprenant trois fenêtres temporelles distinctes, des identifiants de source élargis qui ont remplacé le modèle d'identifiant de campagne précédent, ainsi qu'un système de valeurs de conversion à double niveau composé de valeurs fines et grossières. SKAdNetwork 4 peut générer jusqu'à trois postbacks pour une attribution publicitaire gagnante. Les deuxième et troisième postbacks ne sont disponibles que lorsque les conditions de confidentialité applicables sont réunies et que les fenêtres de conversion correspondantes produisent des informations de conversion éligibles ; le Niveau 0 ne reçoit que le premier postback.

Valeurs fines : encoder l'engagement in-app dans des entiers de 6 bits

Les valeurs de conversion fines représentent la métrique de mesure SKAN traditionnelle. Encodées sous la forme d'un entier non signé de 6 bits, les valeurs fines prennent en charge 64 états numériques distincts allant de 0 à 63.

Puisque 6 bits offrent 64 valeurs potentielles, les développeurs conçoivent une logique de mappage pour encoder des étapes clés spécifiques ou des plages de revenus :

• Mappage séquentiel du tunnel : attribution de valeurs de manière séquentielle en fonction de la profondeur du tunnel (par ex. 1 = Inscription, 2 = Intégration, 3 = Niveau 5, 4 = Achat).

• Mappage par tranches de revenus : utilisation des 64 états fins disponibles pour représenter un état de base ainsi que jusqu'à 63 tranches de revenus (par ex. 1 = 0,01 $–0,99 $, 2 = 1,00 $–4,99 $, $\dots, 63 = 500,00 $ et plus).

Les valeurs de conversion fines ne sont renvoyées que dans le premier postback. Les deuxième et troisième postbacks renvoient quant à eux des valeurs de conversion grossières.

Valeurs grossières : catégoriser la valeur post-installation en niveaux bas, moyen et haut

Dans la fenêtre de conversion 1, Apple peut renvoyer soit la valeur de conversion fine, soit la valeur de conversion grossière selon le niveau de données de postback applicable. Les fenêtres de conversion 2 et 3 utilisent des valeurs de conversion grossières. Les valeurs fines et grossières sont fournies conjointement lorsque l'application appelle l'API de valeur de conversion SKAN 4 ; Apple détermine ensuite quelle représentation, le cas échéant, est incluse dans le premier postback en fonction du niveau de données de postback. Les postbacks peuvent contenir soit des valeurs de conversion fines, soit des valeurs grossières, mais pas les deux. Les libellés bas, moyen et haut n'ont aucune signification commerciale prédéfinie dans SKAdNetwork. C'est l'application ou le réseau publicitaire qui définit ce que chaque niveau représente.

Une valeur de conversion grossière consiste en une propriété de type chaîne de caractères contenant l'une des trois valeurs explicites suivantes :

• low : indique un engagement de base post-installation (par ex. inscription complétée ou session initiée).

• medium : indique une valeur post-installation modérée (par ex. jalon intermédiaire de l'application atteint ou dépenses comprises entre 1,00 $ et 19,99 $).

• high : indique une valeur post-installation élevée (par ex. abonnement à haute valeur complété ou dépenses de 20,00 $ et plus).

Dans les fenêtres de conversion 2 et 3, le champ de valeur de conversion n'est pas utilisé pour les valeurs fines ; le système peut renvoyer la valeur de conversion grossière fournie par le développeur lorsque les conditions de confidentialité le permettent.

Comment fonctionnent les valeurs fines et grossières à travers les fenêtres de conversion

Fenêtre de conversion 1 (Jours 0 à 2)

La fenêtre de conversion 1 (Jours 0 à 2, soit environ les 48 premières heures suivant le premier lancement de l'application) couvre la période de mesure initiale après l'installation, pendant laquelle les développeurs peuvent mettre à jour les valeurs de conversion fines ou grossières avant la fermeture de la fenêtre par le système. Durant ce laps de temps, l'application mobile peut mettre à jour les valeurs de conversion plusieurs fois à mesure que l'utilisateur accomplit des événements in-app.

Selon le niveau de données de postback attribué par Apple, la fenêtre de conversion 1 délivre soit une valeur fine (0 à 63), soit une valeur grossière (low, medium, high). Si le niveau de données de postback est le Niveau 0, le premier postback ne contient que l'identifiant de source hiérarchique à deux chiffres ; la valeur de conversion fine ou grossière est omise.

Fenêtres de conversion 2 (3 à 7 jours) et 3 (8 à 35 jours)

Afin d'offrir une visibilité sur la fidélisation des utilisateurs à moyen et long terme, SKAdNetwork 4.0 a introduit deux fenêtres de conversion supplémentaires :

• Fenêtre de conversion 2 : mesure l'engagement des utilisateurs survenant pendant la période de mesure des jours 3 à 7 post-installation (une fenêtre de 5 jours).

• Fenêtre de conversion 3 : mesure l'engagement des utilisateurs survenant pendant la période de mesure des jours 8 à 35 post-installation (une fenêtre de 28 jours).

Contrairement à la fenêtre 1, les fenêtres de conversion 2 et 3 transmettent uniquement des valeurs grossières. Les valeurs fines (0 à 63) ne sont pas prises en charge dans les fenêtres 2 et 3. Les développeurs déterminent la valeur grossière rapportée pour chaque fenêtre en fonction des événements survenus au cours de cette période de mesure.

Comprendre les niveaux de données de postback et l'anonymat de foule

Apple détermine un niveau de données de postback pour le téléchargement de l'application en fonction de la taille de la foule associée à l'application ou au domaine source, de l'application faisant l'objet de la promotion, du pays où l'application a été installée, ainsi que de l'identifiant de source hiérarchique fourni par le réseau publicitaire. Selon le niveau, le premier postback peut exposer deux, trois ou quatre chiffres de l'identifiant de source hiérarchique, tandis que la valeur de conversion peut être omise, renvoyée sous forme grossière ou renvoyée sous forme fine. Conformément à la documentation officielle du cadre SKAdNetwork d'Apple (StoreKit > SKAdNetwork), Apple ne publie pas de seuils de volume d'installations universels que les développeurs peuvent utiliser pour associer des campagnes à des niveaux de données fixes.

Le tableau ci-dessous indique comment les charges utiles (payloads) de données de postback corrèlent avec les niveaux de confidentialité à travers les fenêtres de conversion, conformément à la documentation officielle du cadre SKAdNetwork d'Apple :

Utilisation de la propriété lockWindow pour finaliser prématurément les fenêtres de conversion

Définir lockWindow: true verrouille la valeur de conversion pour la fenêtre de conversion en cours. Le système prépare immédiatement le postback correspondant et ignore les mises à jour ultérieures de la valeur de conversion dans cette fenêtre. Le postback reste soumis au délai de livraison aléatoire d'Apple.

Par exemple, si un utilisateur effectue un achat 6 heures après le début de la fenêtre de conversion 1, l'application peut définir lockWindow: true. Cela ferme la fenêtre de mesure de manière anticipée et permet au processus de planification des postbacks d'Apple de démarrer, ce qui peut amener le système à préparer le postback plus tôt, bien que le délai de livraison aléatoire applicable s'applique toujours.

Comparaison structurelle des fenêtres de conversion SKAdNetwork 1, 2 et 3

Évaluation comparative du timing des postbacks, des types de valeurs et des fenêtres de délai de SKAN 4.0

La gestion d'un schéma SKAdNetwork multi-fenêtre nécessite de mapper les déclencheurs d'événements en fonction de la durée de la fenêtre, de la granularité des valeurs prises en charge et des plages de délai des postbacks.

Le tableau ci-dessous compare les caractéristiques techniques des fenêtres de conversion 1, 2 et 3 :

Évaluation de la granularité des données et des horodatages à travers les fenêtres de conversion SKAN

Tandis que la fenêtre de conversion 1 offre la plus haute résolution de données (valeurs fines de 6 bits), les fenêtres 2 et 3 fournissent des signaux de rétention à long terme cruciaux. Les analystes doivent tenir compte des plages de délai des postbacks lorsqu'ils recoupent les postbacks SKAN avec les registres de transactions internes.

Étant donné qu'Apple applique un délai aléatoire de 24 à 48 heures pour les postbacks de la fenêtre 1 et pouvant aller jusqu'à 144 heures pour les fenêtres 2 et 3, les postbacks parvenant aux points de terminaison d'attribution ne représentent pas des conversions en temps réel. Ils représentent plutôt des fenêtres d'engagement historiques achevées plusieurs jours auparavant.

Les ingénieurs cherchant à configurer la journalisation du SDK côté client et l'analyse automatisée des postbacks SKAN peuvent se référer à la documentation sur l'intégration du SDK d'attribution OpoInstall pour examiner la configuration de la structure des charges utiles.

Comment concevoir un schéma de valeurs de conversion SKAdNetwork

Exemple de mappage de schéma de conversion SKAdNetwork 4.0

La conception d'un schéma SKAdNetwork nécessite de mapper les étapes clés in-app et les tranches d'achat à des valeurs fines et grossières distinctes.

Le tableau ci-dessous illustre la conception d'un schéma de valeurs de conversion standard pour une application mobile :

Cadre de conception de schéma pour la production : applications de jeux vs applications par abonnement

Selon la dynamique de monétisation du produit, les équipes d'ingénierie adaptent les configurations de schéma pour privilégier soit la progression instantanée dans le tunnel, soit les tranches de revenus à long terme :

• Applications de jeux (priorité aux revenus) : les valeurs 0 à 10 mappent la progression initiale du tutoriel, tandis que les valeurs 11 à 63 représentent les revenus cumulés observés pendant la fenêtre 1. Les valeurs grossières des fenêtres 2 et 3 mappent la fréquence des achats répétés (low = actif, medium = 2e achat, high = dépensier VIP).

• Applications par abonnement (priorité à l'essai) : les valeurs 0 à 5 mappent l'inscription et la complétion du profil, la valeur 10 mappe l'activation de l'essai gratuit, et les valeurs 20 à 63 mappent les sélections de formules d'abonnement. Les valeurs grossières des fenêtres 2 et 3 mappent les conversions d'essai en payant (low = session active, medium = essai converti, high = abonnement renouvelé).

Comment choisir entre des valeurs de conversion basées sur les revenus et basées sur les événements

Le choix entre des modèles de schéma basés sur les revenus et basés sur les événements nécessite d'aligner la logique des valeurs de conversion avec la mécanique de monétisation de l'application :

• Modèles basés sur les revenus (e-commerce et jeux) : optimaux pour les applications où les achats se produisent au cours des 48 premières heures. En encodant les dépenses cumulées dans des tranches de revenus progressivement plus larges, les plateformes côté demande (DSP) reçoivent des signaux de revenus exploitables pour l'analyse des campagnes. Si le schéma est basé sur le revenu cumulé, chaque mise à jour de conversion doit encoder le revenu cumulé actuel de l'utilisateur après l'installation, et non seulement le montant de la dernière transaction.

• Modèles de tunnel basés sur les événements (abonnements) : optimaux pour les applications dotées de périodes d'essai ou de réflexion prolongées. En mappant des étapes séquentielles (par ex. de l'inscription à l'activation de l'essai puis à l'abonnement), la mesure de campagne évalue les utilisateurs en période d'essai à forte intention avant l'expiration des jours 0 à 2.

Conception des tranches de revenus : mapper les plages d'achats in-app (IAP) aux valeurs 0-63

Lors de l'analyse du retour sur les dépenses publicitaires (ROAS), le mappage des valeurs fines de 6 bits à des tranches de revenus constitue une conception de schéma efficace. L'application calcule le revenu cumulé selon sa propre logique commerciale et encode le résultat dans la valeur de conversion. Les limites de tranches ci-dessous sont illustratives et ne constituent pas un mappage de production complet à 64 tranches. En production, les limites de tranches doivent être dérivées de la distribution des payeurs de l'application, de la sensibilité attendue au ROAS et des objectifs de campagne.

Un exemple de schéma de revenus à 6 bits pour une application de e-commerce ou de jeux est structuré comme suit :

• Valeur 0 : Aucun événement post-installation mesuré / base de référence.

• Valeur 1 : 0,01 $ à 0,99 $ (Micro-transaction).

• Valeur 2 : 1,00 $ à 4,99 $.

• Valeur 3 : 5,00 $ à 9,99 $.

• dots\dotsdots

• Valeur 62 : 250,00 $ à 499,99 $.

• Valeur 63 : 500,00 $ et plus (tranche des gros dépensiers).

Lorsqu'un utilisateur effectue un achat in-app, le SDK mobile calcule les dépenses cumulées de l'utilisateur observées pendant la fenêtre 1, identifie la tranche entière correspondante et appelle updatePostbackConversionValue.

Conception des tunnels d'engagement : mapper les étapes séquentielles

Pour les applications par abonnement ou les outils utilitaires où les achats in-app surviennent tardivement dans le cycle de vie de l'utilisateur, le mappage des valeurs fines à des étapes d'engagement séquentielles fournit des signaux précoces de performance de campagne.

Un schéma d'étapes d'engagement mappe la profondeur de la progression :

• Valeur 1 : Inscription au compte complétée.

• Valeur 2 : Tutoriel d'intégration terminé.

• Valeur 3 : Configuration du profil et des préférences effectuée.

• Valeur 4 : Essai gratuit activé.

• Valeur 5 : Premier partage de contenu in-app.

• Valeur 10 : Abonnement payant démarré.

SKAN 4.0 offre une gestion plus flexible des valeurs de conversion par rapport aux versions antérieures, bien que les annonceurs continuent généralement d'utiliser des stratégies de valeurs croissantes pour des raisons de stabilité d'optimisation. L'application doit définir des règles de préséance déterministes de sorte que de multiples événements survenant au cours de la même fenêtre se résolvent en un seul état final fin/grossier.

[App Launch / Event] ──> [SDK Calls updatePostbackConversionValue]
                                    │
                                    ▼
         ┌──────────────────────────┴──────────────────────────┐
         ▼                                                     ▼
[Conversion Window 1 (0-2 Days)]               [Conversion Window 2 & 3]
 (Fine 0-63 or Coarse)                               (Coarse Only: Low/Med/High)
         │                                                     │
         └──────────────────────────┬──────────────────────────┘
                                    ▼
                [Apple Attribution System Delayed Postback]
                                    │
                                    ▼
               [Attribution / Analytics Backend]

Exemples illustratifs de schémas SKAdNetwork 4.0 de type production

1. Schéma pour jeu mobile (hybride revenus + étapes clés)

Les applications de jeux utilisent un schéma hybride dans la fenêtre 1, réservant les valeurs inférieures (0–10) aux étapes du tutoriel et allouant les valeurs supérieures (11–63) aux revenus cumulés observés pendant la fenêtre 1. Dans ce schéma illustratif, l'application associe indépendamment ces étapes à des catégories grossières.

Valeur 1 : Tutoriel terminé (mappage grossier low)
Valeur 5 : Niveau 10 atteint (mappage grossier medium)
Valeur 15 : Premier IAP (0,99 $ - 9,99 $)
Valeur 40 : Dépensier moyen (10,00 $ - 99,99 $) (mappage grossier high)
Valeur 63 : Dépensier VIP (100,00 $ et plus) (mappage grossier high)

2. Schéma pour application par abonnement (centré sur l'essai et le renouvellement)

Les applications par abonnement associent la fenêtre 1 à la vélocité de conversion des essais gratuits, tout en utilisant les valeurs grossières des fenêtres 2 et 3 pour suivre les conversions d'essai en payant à long terme et les événements de renouvellement.

• Fenêtre 1 : Valeur 1 = Inscription, Valeur 10 = Essai démarré (mappage grossier medium), Valeur 63 = Abonnement à la formule annuelle (mappage grossier high)

• Fenêtre 2 (Jours 3-7) : low = Session active, medium = Essai converti, high = Formule annuelle conservée

• Fenêtre 3 (Jours 8-35) : low = Ré-engagement sur l'app, medium = Abonné payant actif, high = Abonnement renouvelé

Gestion des schémas SKAdNetwork à grande échelle

Pour les équipes de croissance et d'ingénierie des données gérant de multiples campagnes iOS, une gestion centralisée des valeurs de conversion permet de réduire les erreurs d'implémentation, d'automatiser le mappage des charges utiles et de maintenir une visibilité complète sur les postbacks. La configuration de flux de travail sécurisés d'attribution d'installations garantit l'intégrité des charges utiles à travers les SDK clients et les bases de données de reporting backend.

Implémentation de SKAdNetwork 4.0 avec StoreKit

Mises à jour programmatiques des valeurs de conversion via StoreKit

Les postbacks SKAdNetwork 4 sont disponibles lorsque les conditions d'éligibilité SKAdNetwork 4 pertinentes sont remplies. Pour recevoir plusieurs postbacks SKAdNetwork 4, l'application faisant l'objet de la promotion doit mettre à jour les valeurs de conversion pendant les fenêtres de conversion applicables. Une mise à jour dans la fenêtre 1 ne crée pas automatiquement de valeurs de conversion pour la fenêtre 2 ou la fenêtre 3. Pour les applications utilisant les API SKAdNetwork 4, l'application faisant l'objet de la promotion doit être construite avec le SDK iOS 16.1 ou version ultérieure et s'exécuter sur iOS 16.1 ou version ultérieure pour appeler SKAdNetwork.updatePostbackConversionValue(_:coarseValue:lockWindow:completionHandler:) au sein de StoreKit. AdAttributionKit est un cadre d'attribution Apple distinct et se trouve hors du champ d'application de cet exemple d'implémentation de valeur de conversion SKAdNetwork.

La méthode accepte trois paramètres principaux :

1. fineValue : Un entier compris entre 0 et 63.

2. coarseValue : Une énumération SKAdNetwork.CoarseConversionValue (.low, .medium, .high).

3. lockWindow : Un indicateur booléen indiquant s'il faut finaliser la fenêtre de manière anticipée.

Pour la mesure de postbacks multiples de SKAdNetwork 4, l'application doit continuer à mettre à jour les valeurs de conversion pendant les fenêtres de conversion applicables ; définir une valeur pour la fenêtre 1 ne remplit pas automatiquement les fenêtres 2 et 3.

Les développeurs peuvent se référer aux spécifications techniques concernant les schémas de journaux d'événements bruts et les structures de charges utiles SKAN dans la documentation officielle pour développeurs.

Le code et le schéma ci-dessous illustrent comment les développeurs invoquent l'API de mise à jour SKAN 4.0 en Swift et comment les collecteurs backend formatent la charge utile de postback résultante :

Remarque : Le schéma et les extraits de code suivants sont des exemples conceptuels uniquement et ne constituent pas une spécification d'API Apple ou OpoInstall.

// Swift Example: Updating SKAdNetwork 4.0 Conversion Value on iOS 16.1+
import StoreKit

func updateSKANConversionValue(fineValue: Int, coarseValue: SKAdNetwork.CoarseConversionValue, shouldLock: Bool) {
    guard (0...63).contains(fineValue) else { return }
    if #available(iOS 16.1, *) {
        SKAdNetwork.updatePostbackConversionValue(fineValue, coarseValue: coarseValue, lockWindow: shouldLock) { error in
            if let error = error {
                print("SKAN Update Error: \(error.localizedDescription)")
            } else {
                print("SKAN Value Updated Successfully: Fine = \(fineValue), Coarse = \(coarseValue.rawValue), Locked = \(shouldLock)")
            }
        }
    } else {
        // Deprecated legacy API used for compatibility with older OS versions.
        SKAdNetwork.updateConversionValue(fineValue)
    }
}

{
  "example_only": true,
  "privacy_note": "Illustrative schema only",
  "measurement_model": "cumulative_revenue",
  "precedence": "highest_qualifying_value",
  "lock_policy": "lock_on_terminal_conversion",
  "event_type": "skan_conversion_value_mapping_config",
  "app_id": "com.example.iosapp",
  "skan_schema_version": "4.0",
  "window_1_config": {
    "fine_value_mappings": [
      { "value": 0, "event_name": "app_launch_or_baseline", "min_revenue_cents": 0 },
      { "value": 1, "event_name": "registration", "min_revenue_cents": 0 },
      { "value": 10, "event_name": "free_trial", "min_revenue_cents": 0 },
      { "value": 30, "event_name": "first_purchase", "min_revenue_cents": 100 },
      { "value": 63, "event_name": "whale_purchase", "min_revenue_cents": 50000 }
    ],
    "coarse_value_mappings": {
      "low": "app_launch_or_registration",
      "medium": "first_purchase_under_20",
      "high": "purchase_over_20"
    }
  },
  "window_2_config": {
    "coarse_value_mappings": {
      "low": "d3_d7_active_session",
      "medium": "d3_d7_repeat_purchase",
      "high": "d3_d7_subscription_renewed"
    }
  },
  "window_3_config": {
    "coarse_value_mappings": {
      "low": "d8_d35_active_session",
      "medium": "d8_d35_repeat_purchase",
      "high": "d8_d35_subscription_retained"
    }
  }
}

Bonnes pratiques relatives aux valeurs de conversion SKAdNetwork

Aligner la conception du schéma de conversion sur les objectifs de campagne

La conception d'un schéma SKAdNetwork nécessite de sélectionner des règles de mappage qui correspondent à vos principaux objectifs de campagne. Les équipes d'achat média optimisant les conversions d'essai immédiates doivent privilégier les étapes séquentielles du tunnel dans la fenêtre de conversion 1. Inversement, les équipes de performance évaluant les achats à haute valeur doivent implémenter des tranches de revenus granulaires.

Consolider les campagnes pour atteindre les seuils d'anonymat de foule

Pour éviter que les postbacks ne renvoient des valeurs null ou ne basculent vers des solutions de repli grossières, les équipes de croissance mobile gèrent la densité des campagnes :

• Réduire la fragmentation des campagnes : pour diminuer la probabilité d'obtenir des niveaux de données de postback faibles, les équipes peuvent éviter une fragmentation inutile des campagnes et un ciblage excessivement restreint. Cependant, Apple ne publie pas de seuil universel de dépenses ou d'installations garantissant un niveau de données de postback spécifique.

• Élargir les paramètres de ciblage : évitez un ciblage géographique ou démographique trop étroit qui enfreindrait les seuils d'anonymat de foule.

• Optimiser la stratégie LockWindow : les équipes devraient généralement envisager d'utiliser lockWindow: true uniquement lorsqu'elles sont certaines qu'aucun autre signal de conversion précieux n'est attendu dans la partie restante de cette fenêtre.

Liste de contrôle pour le schéma de valeurs de conversion SKAdNetwork 4.0

Pour garantir une conformité totale du suivi SKAdNetwork 4.0 et maximiser la mesure de la LTV, vérifiez que votre schéma satisfait aux exigences d'ingénierie suivantes :

• [ ] Objectif d'optimisation principal : définissez si votre campagne s'optimise pour les étapes d'engagement précoces ou pour les revenus cumulés sur 48 heures.
[ ] Mappage des valeurs fines de la fenêtre 1 : attribuez des valeurs entières de 6 bits distinctes (0–63) aux étapes séquentielles du tunnel ou aux tranches de revenus.
[ ] Mappage des valeurs grossières de la fenêtre 1 : configurez des buckets de chaînes grossières low, medium et high pour les diffusions à faible anonymat de foule.
[ ] Mappage des valeurs grossières des fenêtres 2 et 3 : établissez une logique de suivi grossière pour les fenêtres de postback de 3–7 jours et de 8–35 jours.
[ ] Préséance des événements et règles de verrouillage : définissez une préséance d'événements déterministe et configurez lockWindow: true uniquement sur les événements de conversion terminaux.

Erreurs courantes de conception de schémas SKAN 4.0 qui réduisent la qualité de la mesure

• Compresser les tranches de dépensiers dans la valeur 63 : attribuer des achats de 10 $ et de 1 000 $ au même bucket supérieur réduit la différenciation des revenus disponible pour l'analyse et l'optimisation des campagnes.

• Exécution prématurée de LockWindow : appeler lockWindow: true sur un événement d'inscription précoce verrouille définitivement la fenêtre de conversion 1, éliminant les achats ultérieurs survenant dans les 48 heures.

• Surcomplexifier les fenêtres 2 et 3 : tenter de mapper des règles grossières complexes pour des postbacks arrivant jusqu'à 35 jours plus tard complique l'évaluation des campagnes sans améliorer l'optimisation des enchères précoces.

Comment résoudre les problèmes de valeurs nulles dans les postbacks SKAdNetwork et les baisses d'anonymat de foule

Diagnostiquer des taux élevés de valeurs de conversion nulles : comprendre le faible anonymat de foule des campagnes

Lors de l'inspection des performances des campagnes SKAN dans les tableaux de bord d'attribution, les analystes observent fréquemment des postbacks renvoyant des valeurs null ou des valeurs de conversion manquantes. Une proportion élevée de valeurs de conversion manquantes peut indiquer que le niveau de données de postback applicable ne permet pas à Apple de divulguer des informations sur les valeurs de conversion.

Pour résoudre les baisses d'anonymat de foule et améliorer la visibilité des valeurs de conversion, les équipes de performance consolident les clés de campagne et évaluent la densité de la structure des campagnes pour s'enquérir que la vélocité des installations dépasse les seuils d'anonymat de foule.

Résoudre les décalages de séquence et les pièges de rétrogradation des valeurs de conversion

Dans SKAdNetwork 4.0, les valeurs de conversion peuvent être mises à jour de manière flexible pendant la fenêtre 1, mais les développeurs doivent gérer soigneusement les états de lockWindow.

Si une application définit lockWindow: true sur un événement de faible valeur (par ex. Valeur 2 = Inscription), la fenêtre se verrouille définitivement. Si l'utilisateur effectue ensuite un achat de 100 $ 10 minutes plus tard dans la fenêtre de 48 heures, le système ne peut pas mettre à jour la valeur de conversion, ce qui entraîne une LTV de campagne sous-estimée. Les développeurs doivent s'assurer que lockWindow: true est exécuté sur des événements de conversion terminaux et à haute valeur.

Gérer les plages de délais aléatoires imposées par le système d'attribution d'Apple

Pour empêcher les annonceurs de tenter de ré-identifier des utilisateurs individuels en faisant correspondre les horodatages de conversion avec les journaux de clics web, Apple impose un délai aléatoire obligatoire sur tous les envois de postbacks.

Pour la fenêtre de conversion 1, le système prépare le postback lorsque la fenêtre de conversion se ferme ou lorsque l'application verrouille la fenêtre. Apple applique ensuite un délai aléatoire de 24 à 48 heures. Les fenêtres 2 et 3 utilisent un délai aléatoire de 24 à 144 heures après la fermeture ou le verrouillage de la fenêtre correspondante. Les pipelines d'ingénierie des données doivent tenir compte de ces délais systématiques, en évitant de configurer des ajustements d'enchères automatisés à court terme sur les flux de données SKAN.

Points clés à retenir

• Mesure multi-fenêtre : SKAN 4.0 élargit la mesure sur trois fenêtres de postback (0-2 jours, 3-7 jours, 8-35 jours), en utilisant des valeurs fines (0-63) et grossières (low, medium, high).

• Seuils d'anonymat de foule : Un volume d'installations de campagne plus élevé peut activer des valeurs fines, tandis que les campagnes à faible volume reçoivent des valeurs grossières ou des occultations sous forme de null pour préserver la confidentialité.

• Utilisation stratégique de LockWindow : L'exécution de lockWindow: true sur les événements de conversion terminaux peut réduire le temps d'attente avant le verrouillage de la fenêtre, permettant un retour d'information plus rapide sur les campagnes.

Résumé et cadre décisionnel

L'optimisation de la mesure des campagnes iOS dans le respect des directives de confidentialité d'Apple nécessite la configuration d'un schéma de valeurs de conversion SKAdNetwork bien structuré. La transition du suivi IDFA historique vers les postbacks multi-fenêtres de SKAN 4.0 permet aux équipes de performance d'évaluer à la fois l'activation immédiate et la rétention à long terme des utilisateurs.

Pour découvrir comment la mesure mobile unifiée peut optimiser la stratégie de croissance de votre application, consultez la référence d'implémentation de l'attribution mobile OpoInstall ou créez un compte sur la console développeur OpoInstall.

Ressources associées

Pour approfondir votre compréhension de la mesure SKAdNetwork, de l'infrastructure d'attribution mobile et de la croissance d'applications respectueuse de la vie privée, découvrez nos guides techniques :

SKAdNetwork vs attribution MMP : explications des différences clés : découvrez comment le cadre natif SKAdNetwork d'Apple se compare aux modèles d'attribution de partenaires de mesure mobiles (MMP) indépendants et comment les deux systèmes fonctionnent ensemble.
Comment implémenter un SDK de suivi des parrainages avec deep linking différé et attribution d'installations : apprenez comment les applications mobiles préservent le contexte d'acquisition à travers les flux d'installation sur les app stores en utilisant le deep linking différé et les flux de travail des SDK d'attribution.
Comment fonctionnent les partenaires de mesure mobiles (MMP) : explorez la manière dont les plateformes MMP ingèrent les signaux d'attribution, traitent les événements post-installation et génèrent des rapports de mesure de campagne agrégés.

Sujets associés

Concepts : SKAdNetwork, Valeur de conversion, Fenêtre de postback, Anonymat de foule, LockWindow
Technologies : Partenaires de mesure mobiles (MMP), StoreKit, AdAttributionKit, Postback de serveur à serveur
API : Capacités de journalisation des événements d'attribution mobile OpoInstall, API Apple SKAdNetwork, API Apple AdAttributionKit

• Documentation officielle et références :

  Documentation du développeur Apple sur le cadre SKAdNetwork
  Documentation du développeur Apple sur AdAttributionKit
  Standards du groupe de travail sur les performances web du W3C