Flux de travail S2S SKAdNetwork : Comment vérifier les postbacks des réseaux publicitaires

Comment les DSP gèrent-ils les postbacks SKAdNetwork ? Les plateformes côté demande (DSP) et les réseaux publicitaires gèrent les postbacks SKAdNetwork en mettant en place des points de terminaison d'ingestion HTTP POST sécurisés, en construisant la chaîne de messages UTF-8 sérialisée à l'aide du délimiteur U+2063, en vérifiant la signature cryptographique ECDSA P-256 d'Apple par rapport à la clé publique publiée par Apple, et en enregistrant les identifiants de transaction vérifiés afin d'éviter tout traitement en double avant de mettre à jour les modèles d'enchères.

Un postback de validation d'installation SKAdNetwork est une notification HTTPS POST signée par Apple que le système d'exploitation envoie à un réseau publicitaire éligible et, pour les attributions gagnantes, facultativement au point de terminaison de copie configuré du développeur de l'application faisant l'objet de la publicité. Pour garantir l'intégrité des données, les systèmes d'ingestion back-end doivent vérifier la signature ECDSA P-256 d'Apple, valider la sérialisation des paramètres et appliquer une déduplication au niveau de la transaction.

L'architecture de l'ingestion des postbacks SKAdNetwork pour les DSP et les réseaux publicitaires

Le double pipeline d'ingestion : livraison directe au réseau publicitaire vs points de terminaison de postback des développeurs

Lorsqu'une installation d'application iOS attribuée se produit, le sous-système d'attribution d'Apple transmet les postbacks de validation d'installation via HTTPS POST :

• Ingestion par le réseau publicitaire: L'appareil livre le postback gagnant principal (did-win: true) directement à l'URL du serveur enregistrée sous le ad-network-id correspondant dans le registre d'Apple.
• Ingestion de la copie du développeur: Si l'application annoncée spécifie la clé NSAdvertisingAttributionReportEndpoint dans son fichier Info.plist, l'appareil transmet simultanément une copie exacte du postback gagnant directement sur le serveur du développeur.
• Routage des postbacks non gagnants: À partir de SKAdNetwork 3.0, si plusieurs réseaux publicitaires étaient qualifiés pour l'attribution mais n'ont pas gagné, l'appareil envoie jusqu'à cinq postbacks non gagnants (did-win: false) directement à ces réseaux publicitaires secondaires qualifiés. Les postbacks non gagnants ne sont pas livrés au point de terminaison de copie du développeur.

Les points de terminaison d'ingestion back-end doivent répondre avec un code HTTP 200 OK. Si l'appareil ne reçoit pas de réponse 200, il peut relayer la livraison jusqu'à neuf fois sur une période maximale de neuf jours.

Le rôle de NSAdvertisingAttributionReportEndpoint dans l'audit des développeurs

Le paramètre NSAdvertisingAttributionReportEndpoint permet aux développeurs d'applications de recevoir des copies directes des postbacks gagnants indépendamment du transfert des réseaux publicitaires :

• Audit indépendant: Les développeurs reçoivent des copies exactes de tous les postbacks gagnants générés pour leur application, ce qui permet une validation interne des rapports des réseaux publicitaires.
• Chemin de point de terminaison dédié: Le serveur du développeur doit héberger le point de terminaison à l'adresse https://<domain>/.well-known/skadnetwork/report-attribution/.
• Distinction AdAttributionKit: Pour AdAttributionKit, Apple définit une configuration de routage distincte vers https://<domain>/.well-known/appattribution/report-attribution/, qui utilise une architecture de vérification JWS (JSON Web Signature).

Comment les MMP ingèrent, agrègent et normalisent les flux d'événements S2S multi-réseaux

Selon les intégrations commerciales, les Mobile Measurement Partners (MMP) peuvent ingérer des données SKAdNetwork par le biais d'un transfert côté développeur, d'intégrations avec des réseaux publicitaires ou de flux de serveurs partenaires personnalisés :

• Ingestion multi-source: Ingestion de données de postback vérifiées transmises depuis les points de terminaison des développeurs aux côtés des flux de rapports directs des réseaux publicitaires.
• Déduplication entre les flux: Normalisation et déduplication des enregistrements à l'aide de l'transaction-id unique sur les copies partagées des réseaux publicitaires et des développeurs.
• Normalisation BI en aval: Correspondance des valeurs de conversion granulaires et non granulaires avec les modèles de revenus et les événements d'entonnoir définis par le client.

Voir aussi : SKAdNetwork ──> Modèle d'attribution mobile

Vérification cryptographique : validation de la signature ECDSA P-256 d'Apple

Comprendre la pile cryptographique : courbe NIST P-256 (secp256r1) avec SHA-256

Chaque postback SKAdNetwork comprend un champ attribution-signature. Cette signature cryptographique est générée par Apple à l'aide de l'algorithme de signature numérique à courbe elliptique (ECDSA) avec la courbe NIST P-256 (secp256r1) et un condensé SHA-256.

La signature valide deux propriétés de sécurité fondamentales :

• Authenticité: Le postback a été généré directement par le sous-système de la plateforme d'Apple sur un appareil vérifié, et non falsifié par un client ou un proxy malveillant.
• Intégrité: Les paramètres couverts par la signature n'ont pas été modifiés lors du transport.

Utilisation de la clé publique SKAdNetwork publiée par Apple

Pour vérifier la signature, le serveur d'ingestion doit charger la clé publique officielle d'Apple. Pour SKAdNetwork 2.1 et versions ultérieures, Apple publie une clé publique NIST P-256 dédiée dans sa documentation pour développeurs :

• Initialisation de la clé: La clé publique est chargée en mémoire en tant qu'objet de clé publique X.509/DER standard lors de l'initialisation du serveur.
• Contrôle de signature asymétrique: Le moteur de vérification reconstitue la chaîne de messages sérialisée en UTF-8 exacte, calcule le hachage SHA-256 et vérifie l'attribution-signature décodée en Base64 par rapport au message reconstitué.

[Device / Subsystem] ──► [Dispatches Signed JSON Postback]
                                     │
                                     ▼
                  [DSP / Ad Network Ingestion Endpoint]
                  (HTTPS POST to registered postback URL)
                                     │
                                     ▼
                  [Parse JSON & Reconstruct Message String]
                  (Concatenate UTF-8 fields with \u2063)
                                     │
                                     ▼
                  [ECDSA P-256 Public Key Signature Verification]
                                     │
                      ┌──────────────┴──────────────┐
                      ▼                                                          ▼
               [Signature Valid]                                         [Signature Invalid]
                      │                                                          │
                      ▼                                                          ▼
            [Atomic Deduplication]                                       [Log Error & Discard]
            (Check transaction-id)
                      │
                      ▼
            [Process Attribution]

Pourquoi un hachage seul est insuffisant : vérification de signature asymétrique

Puisqu'Apple signe la charge utile à l'aide de sa clé privée et ne distribue pas de secret partagé, la validation symétrique (telle que HMAC-SHA256) ne peut pas être utilisée. Les moteurs d'ingestion doivent implémenter une vérification de signature à clé publique asymétrique standard à l'aide de bibliothèques cryptographiques standard (telles qu'OpenSSL, crypto de Node.js ou cryptography de Python).

Construction de la chaîne de messages pour la vérification de la signature

Le protocole de sérialisation strict : le rôle du séparateur invisible (\u2063)

Apple spécifie un format de sérialisation d'octets UTF-8 exact pour construire la chaîne de messages pour la validation de la signature. Les paramètres doivent être concaténés dans une séquence précise, séparés par le caractère Unicode invisible \u2063 (séparateur invisible U+2063, séquence d'octets UTF-8 0xE2 0x81 0xA3) :

Le remplacement par des espaces blancs, de la ponctuation standard ou des séparateurs Unicode alternatifs entraînera l'échec de la vérification cryptographique.

Ordre des paramètres spécifique à la version pour SKAN 4.0

Selon la documentation pour développeurs d'Apple sur la vérification d'un postback de validation d'installation, les paramètres des postbacks SKAdNetwork 4.0 doivent être sérialisés dans l'ordre exact suivant :

1. version (par exemple, "4.0")
2. ad-network-id (par exemple, "example123.skadnetwork")
3. source-identifier (par exemple, "4821")
4. app-id (par exemple, 1234567890)
5. transaction-id (par exemple, "6a8b1c2d-3e4f-5a6b-7c8d-9e0f1a2b3c4d")
6. redownload (par exemple, "true" ou "false" sous forme de chaîne en minuscules)
7. source-app-id (pour les annonces application à application) OU source-domain (pour les annonces Web vers application dans Safari), inclus uniquement s'il est présent dans le postback
8. fidelity-type (par exemple, 1 pour les annonces affichées par StoreKit ou les annonces Web attribuées par SKAdNetwork ; 0 pour les annonces avec affichage)
9. did-win (par exemple, "true" ou "false" sous forme de chaîne en minuscules)
10. postback-sequence-index (par exemple, 0, 1 ou 2)

Spécification cruciale de SKAN 4 : les valeurs de conversion sont exclues de la signature

Dans SKAdNetwork 4.0, la signature d'Apple n'inclut pas conversion-value ni coarse-conversion-value, même lorsque l'un de ces champs est présent dans la charge utile JSON. La chaîne sérialisée pour SKAN 4 se termine par postback-sequence-index. Tenter d'ajouter des valeurs de conversion à la chaîne de messages entraînera l'échec de la vérification.

La charge utile JSON ci-dessous illustre un schéma complet de postback SKAdNetwork 4.0. La signature ci-dessous est un espace réservé illustratif et ne passera pas la vérification cryptographique ; pour les tests unitaires, utilisez les exemples signés d'Apple provenant de la documentation de vérification officielle :

{
  "version": "4.0",
  "ad-network-id": "example123.skadnetwork",
  "source-identifier": "4821",
  "app-id": 1234567890,
  "transaction-id": "6a8b1c2d-3e4f-5a6b-7c8d-9e0f1a2b3c4d",
  "redownload": false,
  "source-app-id": 9876543210,
  "fidelity-type": 1,
  "did-win": true,
  "postback-sequence-index": 0,
  "conversion-value": 47,
  "attribution-signature": "MEQCIFz8...SAMPLE_CRYPTOGRAPHIC_SIGNATURE...=="
}

Gestion des charges utiles SKAN 4.0 multi-fenêtres et des points de terminaison des développeurs

Analyse de postback-sequence-index à travers des fenêtres de conversion séquentielles

Dans SKAdNetwork 4.0, les conversions génèrent des postbacks provenant de fenêtres de conversion s'étendant jusqu'à 35 jours après le premier lancement de l'application, la livraison réelle ayant lieu après les retards post-fenêtre randomisés d'Apple. Les systèmes d'ingestion back-end analysent le champ postback-sequence-index pour attribuer les données de conversion à la bonne fenêtre de cycle de vie :

• Indice 0 (Fenêtre 1 : Jours 0–2): Contient soit une valeur de conversion fine (0–63), soit une valeur de conversion grossière (low, medium, high), ou le champ est absent.
• Indice 1 (Fenêtre 2 : Jours 3–7): Pour les niveaux de données de postback 1–3, peut divulguer une coarse-conversion-value (low, medium, high) lorsqu'elle est fournie ; le niveau 0 n'est pas éligible pour les deuxième ou troisième postbacks.
• Indice 2 (Fenêtre 3 : Jours 8–35): Pour les niveaux de données de postback 1–3, peut divulguer une coarse-conversion-value (low, medium, high) lorsqu'elle est fournie ; le niveau 0 n'est pas éligible pour les deuxième ou troisième postbacks.

Gestion des valeurs de conversion fines vs grossières

Les décodeurs d'ingestion doivent tenir compte de la variabilité des charges utiles :

• Exclusion mutuelle: Apple spécifie qu'un postback de validation d'installation peut contenir soit conversion-value, soit coarse-conversion-value, mais jamais les deux simultanément.
• Valeurs de conversion absentes: Si le niveau de données de postback attribué est faible (niveau 0), les champs de valeur de conversion sont omis de la charge utile JSON.

Défense contre les attaques par rejeu et les charges utiles de conversion falsifiées

Le rôle de l'transaction-id en tant que clé de déduplication

Chaque postback SKAdNetwork contient un UUID transaction-id unique. La documentation d'Apple conseille aux récepteurs d'utiliser cet identifiant comme clé d'idempotence pour détecter et rejeter les postbacks de conversion en double.

Étant donné que les écouteurs de postback sont des points de terminaison HTTPS accessibles publiquement, des acteurs malveillants pourraient tenter des attaques par rejeu en capturant un postback valide et en le soumettant à nouveau à plusieurs reprises pour gonfler artificiellement les mesures de conversion.

Mise en œuvre d'une mise en cache en mémoire distribuée et de registres persistants

Apple ne prescrit pas de période de conservation universelle pour la déduplication. Les récepteurs de production doivent conserver un enregistrement d'idempotence durable pour les ID de transaction vérifiés en fonction de leurs exigences de rapprochement et de défense contre le rejeu ; le TTL de Redis peut être utilisé comme une optimisation de cache à chaud plutôt que comme le seul registre de doublons faisant autorité :

1. Vérification cryptographique d'abord: Vérifiez entièrement la signature ECDSA par rapport à la clé publique d'Apple avant d'enregistrer l'ID de transaction dans le stockage.
2. Déduplication atomique: Exécutez une opération d'écriture atomique (par exemple, SET key value NX EX <seconds> dans Redis) soutenue par une contrainte unique de base de données relationnelle ou documentaire persistante.
3. Horizon de déduplication: Définissez une fenêtre de conservation opérationnelle dans la couche de cache qui couvre la livraison prévue des postbacks, les nouvelles tentatives du réseau (Apple réessaie les livraisons échouées pendant un maximum de 9 jours) et le rapprochement en aval.

L'implémentation back-end ci-dessous démontre la validation de la signature, la validation du schéma et la déduplication atomique en Python :

import base64
import json
import redis
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives.serialization import load_der_public_key
from cryptography.exceptions import InvalidSignature

# Initialize Redis client for hot-cache transaction deduplication
redis_client = redis.Redis(host='localhost', port=6379, db=0, decode_responses=True)

# Official Apple SKAdNetwork 2.1+ Public Key (Base64 DER encoded, published by Apple)
APPLE_SKAN_PUBLIC_KEY_B64 = (
    "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWdp8GPcGqmhgzEFj9Z2nSpQVdday"
    "aPe4FMzqM9wib1+aHaaIzoHoLN9zW4K8y4SPykE3YVK3sVqW6Af0lfx3gg=="
)

# Exact Apple-specified invisible separator: U+2063 INVISIBLE SEPARATOR (UTF-8: 0xE2 0x81 0xA3)
SEPARATOR = "\u2063"

def construct_skan4_message_bytes(payload: dict) -> bytes:
    """
    Constructs the serialized UTF-8 message string for SKAN 4.0 signature verification.
    Apple specification explicitly EXCLUDES conversion-value and coarse-conversion-value from the signature.
    """
    parts = [
        str(payload["version"]),
        str(payload["ad-network-id"]),
        str(payload["source-identifier"]),
        str(payload["app-id"]),
        str(payload["transaction-id"]),
        "true" if payload["redownload"] is True else "false"
    ]

    # Include source-app-id (app ad) OR source-domain (web ad) if present
    if payload.get("source-app-id") is not None:
        parts.append(str(payload["source-app-id"]))
    elif payload.get("source-domain") is not None:
        parts.append(str(payload["source-domain"]))

    parts.append(str(payload["fidelity-type"]))
    parts.append("true" if payload["did-win"] is True else "false")
    parts.append(str(payload["postback-sequence-index"]))

    # Join with U+2063 separator and encode to UTF-8
    message_string = SEPARATOR.join(parts)
    return message_string.encode('utf-8')

def verify_and_ingest_skan4_postback(postback_json_str: str) -> dict:
    """
    Validates payload schema, verifies the ECDSA P-256 signature against Apple's public key,
    and performs atomic transaction-id deduplication.
    """
    try:
        payload = json.loads(postback_json_str)
    except Exception:
        return {"status": "REJECTED", "reason": "INVALID_JSON_FORMAT"}

    # Version Gate: Enforce SKAN 4.0 payload handling
    if payload.get("version") != "4.0":
        return {"status": "REJECTED", "reason": "UNSUPPORTED_SKAN_VERSION"}

    # Schema Validation: Required fields for SKAN 4.0
    required_fields = [
        "version", "ad-network-id", "source-identifier", "app-id",
        "transaction-id", "redownload", "fidelity-type", "did-win",
        "postback-sequence-index", "attribution-signature"
    ]
    for field in required_fields:
        if field not in payload:
            return {"status": "REJECTED", "reason": f"MISSING_REQUIRED_FIELD_{field.upper()}"}

    # Strict Type Validation
    if not isinstance(payload["redownload"], bool):
        return {"status": "REJECTED", "reason": "INVALID_TYPE_REDOWNLOAD"}
    if not isinstance(payload["did-win"], bool):
        return {"status": "REJECTED", "reason": "INVALID_TYPE_DID_WIN"}
    if payload["postback-sequence-index"] not in (0, 1, 2):
        return {"status": "REJECTED", "reason": "INVALID_SEQUENCE_INDEX"}
    if payload["fidelity-type"] not in (0, 1):
        return {"status": "REJECTED", "reason": "INVALID_FIDELITY_TYPE"}

    # Enforce mutual exclusivity between source-app-id and source-domain
    has_source_app = payload.get("source-app-id") is not None
    has_source_domain = payload.get("source-domain") is not None
    if has_source_app and has_source_domain:
        return {"status": "REJECTED", "reason": "CONFLICTING_SOURCE_FIELDS"}

    signature_b64 = payload["attribution-signature"]
    transaction_id = payload["transaction-id"]

    try:
        # Step 1: Reconstruct the exact UTF-8 serialized message
        message_bytes = construct_skan4_message_bytes(payload)
        signature_der = base64.b64decode(signature_b64, validate=True)

        # Step 2: Verify ECDSA P-256 / SHA-256 signature using Apple's published public key
        apple_public_key = load_der_public_key(base64.b64decode(APPLE_SKAN_PUBLIC_KEY_B64))
        apple_public_key.verify(
            signature_der,
            message_bytes,
            ec.ECDSA(hashes.SHA256())
        )
    except InvalidSignature:
        return {"status": "REJECTED", "reason": "INVALID_CRYPTOGRAPHIC_SIGNATURE"}
    except Exception as e:
        return {"status": "ERROR", "reason": f"VERIFICATION_FAILED: {str(e)}"}

    # Step 3: Atomic Deduplication via Redis (Hot cache layer)
    # Note: In production, pair this hot cache with a persistent unique database constraint.
    # 14-day TTL (1,209,600 seconds) serves as an illustrative receiver cache policy covering retries.
    is_new = redis_client.set(f"skan_tx:{transaction_id}", "1", nx=True, ex=1209600)
    if not is_new:
        return {"status": "DUPLICATE", "reason": "TRANSACTION_ALREADY_PROCESSED"}

    return {
        "status": "VERIFIED",
        "transaction_id": transaction_id,
        "sequence_index": payload["postback-sequence-index"],
        "did_win": payload["did-win"]
    }

Ingestion des postbacks dans les modèles d'enchères en temps réel et les optimiseurs de CPA

Dissocier l'ingestion en périphérie du traitement asynchrone

Les DSP à fort volume traitent des volumes de postbacks substantiels pendant les périodes de campagne de pointe. Le traitement synchrone en aval peut introduire des goulots d'étranglement au niveau de la latence.

Les architectures d'entreprise mettent en œuvre un pipeline asynchrone :

1. Récepteur en périphérie: Accepte la requête HTTP POST entrante, vérifie l'authenticité de la signature, exécute une déduplication atomique sur l'transaction-id et renvoie immédiatement un code HTTP 200 OK.
2. File d'attente d'événements: Publie la charge utile vérifiée sur un courtier d'événements distribué (par exemple, Apache Kafka ou AWS SQS).
3. Travailleurs d'enchères et d'analyse: Consomme le flux d'événements, associe les valeurs de conversion aux mesures de revenus et met à jour les modèles de CPA cibles des enchères en temps réel (RTB).

Utilisation de l'identifiant de source hiérarchique

Le premier postback gagnant peut exposer deux, trois ou quatre chiffres du source-identifier hiérarchique, selon le niveau de données du postback. La signification sémantique de ces chiffres est définie par la propre taxonomie d'identifiants de source du réseau publicitaire. Les systèmes d'enchères doivent résoudre l'identifiant de source reçu par rapport aux propres métadonnées de campagne du réseau plutôt que de supposer une correspondance universelle entre la longueur des chiffres et un emplacement ou une granularité de création spécifique.

Matrice comparative : livraison directe d'Apple vs ingestion S2S par les MMP

Résumé et cadre de décision

La gestion des postbacks SKAdNetwork à grande échelle nécessite de combiner une ingestion en périphérie à faible latence avec une validation cryptographique rigoureuse et une déduplication au niveau de la transaction. Étant donné que les postbacks d'Apple influencent directement l'allocation budgétaire et les algorithmes d'enchères, la validation des signatures ECDSA et l'application de l'idempotence de l'transaction-id protègent les pipelines d'ingestion contre les postbacks falsifiés ou altérés et le traitement de rejeu en double.

Pour compléter les rapports SKAdNetwork médiés par la plateforme par l'intégration d'utilisateurs au niveau micro et le routage de liens profonds instantané, les équipes d'ingénierie déploient des architectures de routage first-party aux côtés des API de la plateforme.

Pour en savoir plus sur la configuration des postbacks d'attribution côté serveur et des pipelines de liens profonds, consultez la documentation d'OpoInstall.

Documents associés

• Concepts: Postbacks S2S, Vérification cryptographique, ECDSA P-256, Défense contre les attaques par rejeu, Déduplication des transactions

• Technologies: Apple SKAdNetwork, Apple AdAttributionKit, Cache en mémoire Redis, SDK mobile OpoInstall

• Normes: IETF RFC 8259 (Échange de données JSON), RFC 5480 (Cryptographie à courbe elliptique)

• API: API StoreKit SKAdNetwork, Spécification de livraison de postbacks S2S d'Apple, API S2S d'OpoInstall

Documentation officielle

• Documentation pour développeurs d'Apple sur la vérification d'un postback de validation d'installation

• Documentation pour développeurs d'Apple sur l'identification des paramètres dans les postbacks de validation d'installation

• Documentation pour développeurs d'Apple sur la configuration d'une application annoncée

• Documentation pour développeurs d'Apple sur SKAdNetwork

• Documentation pour développeurs d'Apple sur AdAttributionKit