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

Comment configurer un schéma de valeur de conversion SKAdNetwork 4.0 ? Un schéma de valeur de conversion SKAdNetwork 4.0 mappe les événements post-installation ou les signaux de revenus vers des valeurs fines de 0 à 63 et des valeurs grossières (low, medium, high). Le niveau de données de postback d'Apple détermine quelle représentation de valeur de conversion et quels autres champs sensibles à la vie privée 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 App Tracking Transparency (ATT) d'Apple a fait passer l'accès à l'IDFA d'une disponibilité par défaut à un accès autorisé par l'utilisateur, déplaçant l'attribution mobile du rapprochement déterministe entre applications vers des cadres de mesure respectueux de la vie privée.

Comprendre les hiérarchies de valeurs de conversion SKAdNetwork 4.0

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

Avec SKAdNetwork 2.0 et 3.0, les annonceurs dépendaient d'une valeur de conversion unique et d'un minuteur roulant de 24 heures. Pour SKAN 3 et les versions antérieures, une valeur de conversion plus élevée pouvait redémarrer ce minuteur, ce qui incitait les développeurs à concevoir des systèmes de valeurs de conversion en augmentation monotone. Si un utilisateur effectuait un événement de conversion intégré, le SDK client intégré invoquait une API système pour mettre à jour un entier unique de 6 bits (0 à 63).

Le modèle à postback unique de SKAN offrait une visibilité limitée sur l'engagement post-installation se produisant après la période de conversion initiale pour les applications mobiles avec des tunnels de conversion longs, tels que les plateformes d'e-commerce par abonnement et les jeux mobiles mid-core.

SKAdNetwork 4.0 a restructuré ce paradigme de mesure en introduisant une structure multi-fenêtres SKAdNetwork 4.0 composée de trois fenêtres temporelles distinctes, des identifiants de source étendus ayant remplacé le modèle d'identifiant de campagne précédent, et un système de valeur de conversion à deux niveaux 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 remplies 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 intégré dans des entiers de 6 bits

Les valeurs de conversion fines représentent la métrique de mesure SKAN traditionnelle. Codées en tant qu'entier non signé de 6 bits, les valeurs fines prennent en charge 64 états numériques discrets allant de 0 à 63.

Parce que 6 bits offrent 64 valeurs potentielles, les développeurs conçoivent une logique de mapping pour encoder des jalons d'utilisateur spécifiques ou des fourchettes de revenus :

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

• Mapping des compartiments de revenus : Utilisation des 64 états fins disponibles pour représenter un état de base plus jusqu'à 63 compartiments de revenus (par ex. 1 = 0,01 $–0,99 $, 2 = 1,00 $–4,99 $, 63 = 500,00 $+).

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

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

Dans la fenêtre de conversion 1, Apple peut renvoyer la valeur de conversion fine ou 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 ensemble 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 grossières, mais pas les deux. Les étiquettes low (faible), medium (moyen) et high (élevé) n'ont aucune signification commerciale prédéfinie dans SKAdNetwork. L'application ou le réseau publicitaire définit ce que représente chaque niveau.

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

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

• medium : Indique une valeur post-installation modérée (par ex. étape intermédiaire de l'application atteinte ou 1,00 $–19,99 $ dépensés).

• high : Indique une valeur post-installation élevée (par ex. abonnement à haute valeur complété ou 20,00 $+ dépensés).

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 les valeurs fines et grossières fonctionnent à travers les fenêtres de conversion

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

La fenêtre de conversion 1 (Jours 0–2, environ les 48 premières heures après 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 que le système ne ferme la fenêtre. Pendant cette période, l'application mobile peut mettre à jour les valeurs de conversion plusieurs fois à mesure que l'utilisateur effectue des événements intégrés.

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 de 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)

Pour offrir une visibilité sur la rétention 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 de l'utilisateur se produisant 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 de l'utilisateur se produisant 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 se produisant pendant 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, l'application annoncée, le pays où l'application annoncée a été installée, et 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. Selon la documentation officielle du cadre SKAdNetwork d'Apple (StoreKit > SKAdNetwork), Apple ne publie pas de seuils universels de volume d'installation que les développeurs peuvent utiliser pour mapper les campagnes vers des niveaux de données fixes.

Le tableau ci-dessous décrit comment les charges utiles de données de postback sont corrélées aux niveaux de confidentialité à travers les fenêtres de conversion conformément à la documentation officielle du cadre SKAdNetwork d'Apple :

Utiliser la propriété lockWindow pour finaliser les fenêtres de conversion précocement

Le paramétrage lockWindow: true verrouille la valeur de conversion pour la fenêtre de conversion actuelle. 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 randomisé 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 prématurément la fenêtre de mesure et permet au processus de planification des postbacks d'Apple de commencer, ce qui peut amener le système à préparer le postback plus tôt, bien que le délai de livraison randomisé applicable soit toujours en vigueur.

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 SKAN 4.0

La gestion d'un schéma SKAdNetwork multi-fenêtres 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 de postback.

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

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

Alors que la fenêtre de conversion 1 offre la résolution de données la plus élevée (valeurs fines 6 bits), les fenêtres 2 et 3 fournissent des signaux de rétention à long terme cruciaux. Les analystes doivent prendre en compte les plages de délai de postback lors de la jonction des postbacks SKAN avec les registres de transactions internes.

Parce qu'Apple applique un délai aléatoire de 24 à 48 heures aux postbacks de la fenêtre 1 et jusqu'à 144 heures pour les fenêtres 2 et 3, les postbacks arrivant aux terminaux d'attribution ne représentent pas des conversions en temps réel. Au lieu de cela, ils représentent des fenêtres d'engagement historiques complétées quelques 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 de l' intégration du SDK d'attribution OpoInstall pour examiner la configuration de la structure de la charge utile.

Comment concevoir un schéma de valeur de conversion SKAdNetwork

Exemple de mapping de schéma de conversion SKAdNetwork 4.0

La conception d'un schéma SKAdNetwork nécessite de mapper les jalons intégrés et les niveaux d'achat vers des valeurs fines et grossières discrètes.

Le tableau ci-dessous illustre une conception de schéma de valeur de conversion standard pour une application mobile :

Cadre de conception de schéma de production : 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 donner la priorité soit à la progression rapide dans le tunnel, soit aux niveaux de revenus à long terme :

• Applications de jeux (revenus priorisés) : Les valeurs 0 à 10 mappent la progression précoce 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 dans les fenêtres 2 et 3 mappent la fréquence d'achat répétée (low = actif, medium = 2ème achat, high = dépensier VIP).

• Applications par abonnement (essai priorisé) : 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 niveaux d'abonnement. Les valeurs grossières dans les fenêtres 2 et 3 mappent les conversions essai-vers-payant (low = session active, medium = essai converti, high = abonnement renouvelé).

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

Choisir entre des modèles de schéma basés sur les revenus ou les événements nécessite d'aligner la logique de valeur de conversion avec les mécanismes de monétisation de l'application :

• Modèles basés sur les revenus (e-commerce & jeux) : Optimal pour les applications où les événements d'achat se produisent dans les 48 premières heures. En encodant les dépenses cumulées dans des compartiments de revenus progressivement plus larges, les plateformes côté demande (DSP) reçoivent des signaux de revenus disponibles pour l'analyse de campagne. Si le schéma est basé sur les revenus cumulés, chaque mise à jour de conversion doit encoder les revenus post-installation cumulés actuels de l'utilisateur plutôt que seulement le montant de la dernière transaction.

• Modèles de tunnel basés sur les événements (abonnements) : Optimal pour les applications avec des périodes d'essai ou de réflexion prolongées. En mappant des jalons séquentiels (par ex. inscription $\\to$ activation de l'essai $\\to$ abonnement), la mesure de campagne évalue les essayeurs à forte intention avant l'expiration des jours 0–2.

Concevoir des compartiments de revenus : mapper les plages IAP aux valeurs 0-63

Lors de l'analyse du rendement des dépenses publicitaires (ROAS), le mapping des valeurs fines 6 bits vers des compartiments de revenus représente une conception de schéma efficace. L'application calcule les revenus cumulés selon sa propre logique commerciale et encode le résultat dans la valeur de conversion. Les limites des compartiments ci-dessous sont illustratives plutôt qu'un mapping de production complet de 64 compartiments. En production, les limites de compartiment 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 d'e-commerce ou de jeux est structuré comme suit :

• Value 0 : Aucun événement post-installation mesuré / base.

• Value 1 : 0,01 $ à 0,99 $ (micro-transaction).

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

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

• $\\dots$

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

• Value 63 : 500,00 $+ (niveau de dépensier à haute valeur).

Lorsqu'un utilisateur effectue un achat intégré, le SDK mobile calcule les dépenses cumulées de l'utilisateur observées pendant la fenêtre 1, identifie le compartiment entier correspondant, et invoque updatePostbackConversionValue.

Concevoir des tunnels d'engagement : mapper les jalons séquentiels

Pour les applications d'abonnement ou les outils utilitaires où les achats intégrés se produisent tard dans le cycle de vie de l'utilisateur, mapper les valeurs fines aux jalons d'engagement séquentiels fournit des signaux de performance de campagne précoces.

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

• Value 1 : Inscription au compte terminée.

• Value 2 : Tutoriel d'onboarding terminé.

• Value 3 : Configuration du profil et préférences configurées.

• Value 4 : Essai gratuit activé.

• Value 5 : Premier partage de contenu intégré.

• Value 10 : Abonnement payant commencé.

SKAN 4.0 offre une gestion plus flexible de la valeur de conversion par rapport aux versions antérieures, bien que les annonceurs continuent généralement d'utiliser des stratégies de valeur croissante pour la stabilité de l'optimisation. L'application doit définir des règles de priorité déterministes afin que les événements multiples se produisant dans 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éma SKAdNetwork 4.0 de style production

1. Schéma de jeu mobile (hybride revenus + jalons)

Les applications de jeu utilisent un schéma hybride dans la fenêtre 1, réservant les valeurs inférieures (0–10) aux jalons 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 mappe indépendamment ces jalons vers des catégories grossières.

• Value 1: Tutoriel terminé (mapping grossier low)

• Value 5: Niveau 10 atteint (mapping grossier medium)

• Value 15: Premier IAP (0,99 $ - 9,99 $)

• Value 40: Dépensier moyen (10,00 $ - 99,99 $) (mapping grossier high)

• Value 63: Dépensier VIP (100,00 $+) (mapping grossier high)

2. Schéma d'application d'abonnement (focalisé sur l'essai & le renouvellement)

Les applications d'abonnement mappent la fenêtre 1 à la vitesse de conversion de l'essai gratuit, tout en utilisant les valeurs grossières des fenêtres 2 et 3 pour suivre les conversions essai-vers-payant à long terme et les événements de renouvellement.

• Fenêtre 1: Value 1 = Inscription, Value 10 = Essai commencé (mapping grossier medium), Value 63 = Abonnement annuel souscrit (mapping grossier high)

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

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

Gérer les schémas SKAdNetwork à grande échelle

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

Implémenter SKAdNetwork 4.0 avec StoreKit

Mises à jour programmatiques de la valeur 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 annoncée 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 les fenêtres 2 ou 3. Pour les applications utilisant les API SKAdNetwork 4, l'application annoncée doit être construite avec le SDK iOS 16.1 ou ultérieur et fonctionner sur iOS 16.1 ou ultérieur pour appeler SKAdNetwork.updatePostbackConversionValue(_:coarseValue:lockWindow:completionHandler:) au sein de StoreKit. AdAttributionKit est un cadre d'attribution Apple distinct et est en dehors du cadre de cet exemple d'implémentation de valeur de conversion SKAdNetwork.

La méthode accepte trois paramètres principaux :

1. fineValue : Un entier de 0 à 63.

2. coarseValue : Un enum SKAdNetwork.CoarseConversionValue (.low, .medium, .high).

3. lockWindow : Un indicateur booléen indiquant s'il faut finaliser la fenêtre précocement.

Pour la mesure multi-postback 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 charge utile 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 :

Note : Les extraits de schéma et de code suivants sont uniquement des exemples conceptuels et ne constituent pas une spécification API d'Apple ou d'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"
    }
  }
}

Meilleures pratiques pour la valeur 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 mapping qui correspondent à vos cibles de campagne principales. Les équipes d'achat média optimisant pour les conversions d'essai immédiates devraient donner la priorité aux jalons de tunnel séquentiels dans la fenêtre de conversion 1. À l'inverse, les équipes de performance évaluant les achats à haute valeur devraient implémenter des compartiments de revenus granulaires.

Consolider les campagnes pour des niveaux d'anonymat de foule clairs

Pour empêcher les postbacks de renvoyer des valeurs null ou de tomber vers des solutions de repli grossières, les équipes de croissance mobile gèrent la densité de campagne :

• Réduire la fragmentation des campagnes : Pour réduire la probabilité de niveaux de données de postback faibles, les équipes peuvent éviter la fragmentation inutile des campagnes et un ciblage trop étroit. Cependant, Apple ne publie pas de seuil de dépense ou d'installation universel qui garantit 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 brise 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 convaincues qu'aucun signal de conversion précieux supplémentaire n'est attendu dans la partie restante de cette fenêtre.

Checklist du schéma de valeur de conversion SKAdNetwork 4.0

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

• [ ] Objectif d'optimisation primaire : Définissez si votre campagne optimise pour des jalons d'engagement précoces ou des revenus cumulés sur 48 heures.
• [ ] Mapping de valeur fine Fenêtre 1 : Assignez des valeurs entières 6 bits discrètes (0–63) aux étapes de tunnel séquentiel ou aux compartiments de revenus.
• [ ] Mapping de valeur grossière Fenêtre 1 : Configurez les compartiments de chaîne grossière low, medium et high pour les envois à faible anonymat de foule.
• [ ] Mapping de valeur grossière Fenêtres 2 & 3 : Établissez une logique de suivi grossier pour les fenêtres de postback de 3–7 jours et 8–35 jours.
• [ ] Priorité des événements & Règles de verrouillage : Définissez la priorité des événements déterministes et configurez lockWindow: true uniquement sur les événements de conversion terminaux.

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

• Compresser les niveaux de dépensiers dans la valeur 63 : Assigner les achats de 10 $ et 1 000 $ au même compartiment 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, supprimant les événements d'achat ultérieurs sur 48 heures.

• Sur-compliquer 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 dépanner les valeurs nulles de postback SKAdNetwork et les baisses d'anonymat de foule

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

Lors de l'inspection des performances de campagne SKAN dans les tableaux de bord d'attribution, les analystes observent fréquemment des postbacks renvoyant 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 les informations de valeur de conversion.

Pour résoudre les baisses d'anonymat de foule et améliorer la visibilité de la valeur de conversion, les équipes de performance consolident les clés de campagne et évaluent la densité de la structure de campagne pour s'assurer que la vitesse d'installation franchit les seuils d'anonymat de foule.

Résoudre les désalignements de séquence et les pièges de déclassement de valeur 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 les états lockWindow avec prudence.

Si une application définit lockWindow: true sur un événement de faible valeur (par ex. Value 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-rapportée. Les développeurs doivent s'assurer que lockWindow: true est exécuté uniquement sur les événements de conversion terminaux et à haute valeur.

Gérer les plages de délai randomisées 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 randomisé de 24 à 48 heures. Les fenêtres 2 et 3 utilisent un délai randomisé 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 définir des ajustements d'enchères automatisés à fenêtre courte sur les flux de données SKAN.

Points clés

• Mesure multi-fenêtres : SKAN 4.0 étend 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'installation de campagne plus élevé peut permettre l'utilisation de valeurs fines, tandis que les campagnes à faible volume reçoivent des valeurs grossières ou des rédactions 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 de campagne plus rapide.

Résumé et cadre de décision

L'optimisation de la mesure des campagnes iOS conformément aux directives de confidentialité d'Apple nécessite la configuration d'un schéma de valeur de conversion SKAdNetwork bien structuré. Passer du suivi IDFA hérité aux postbacks multi-fenêtres SKAN 4.0 permet aux équipes de performance d'évaluer à la fois l'activation immédiate et la rétention des utilisateurs à long terme.

En mappant des valeurs fines 6 bits pour un engagement immédiat de 48 heures et des valeurs grossières pour des fenêtres étendues de 35 jours, les équipes de croissance capturent des signaux critiques de revenus et de rétention. L'intégration des SDK clients avec des outils de schéma SKAN automatisés fournit l'infrastructure nécessaire pour décoder les postbacks agrégés et fournir des signaux d'optimisation pour l'efficacité des campagnes iOS.

Pour explorer comment une 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, explorez nos guides techniques :

• SKAdNetwork vs attribution MMP : explications des différences clés : Comprenez comment le cadre natif SKAdNetwork d'Apple se compare aux modèles d'attribution des partenaires de mesure mobile (MMP) indépendants et comment les deux systèmes fonctionnent ensemble.

• Comment implémenter un SDK de suivi de parrainage avec Deferred Deep Linking et attribution d'installation : Apprenez comment les applications mobiles préservent le contexte d'acquisition tout au long des flux d'installation via l'App Store en utilisant le deep linking différé et les flux de travail des SDK d'attribution.

• Comment fonctionnent les partenaires de mesure mobile : Explorez comment 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 mobile (MMP), StoreKit, AdAttributionKit, Postback Serveur-à-Serveur

• API : Capacités de journalisation des événements d'attribution mobile OpoInstall, API Apple SKAdNetwork, API Apple AdAttributionKit

• Documentation officielle & Références :

  • Documentation développeur Apple sur le cadre SKAdNetwork

  • Documentation développeur Apple sur AdAttributionKit

  • Normes du groupe de travail Web Performance du W3C