Attribution mobile sans GAID : attribuer les installations sans identifiants publicitaires

Comment gérer l'attribution d'applications mobiles sans accès aux identifiants publicitaires ? Il est tout à fait possible d'attribuer les installations d'applications sans GAID ni IDFA, mais l'architecture sous-jacente évolue : plutôt que de s'appuyer sur un identifiant publicitaire persistant, les pipelines modernes combinent des frameworks d'attribution gérés par les plateformes, l'API Google Play Install Referrer, le routage de paramètres contextuels first-party et la validation côté serveur.

Un identifiant publicitaire (Advertising ID) est un identifiant logiciel réinitialisable fourni par la plateforme mobile à des fins publicitaires et de mesure. Sur Android, il s'agit du GAID fourni via les services Google Play ; sur les plateformes Apple, l'accès à l'IDFA est régi par le framework App Tracking Transparency.

En bref : résumé de l'attribution mobile sans identifiant

Le Google Advertising ID n'est pas remplacé par un identifiant unique interchangeable. L'attribution se divise plutôt en plusieurs primitives spécialisées :

Rapports de campagnes publicitaires payantes (Android) : Utilisez l'API Google Play Install Referrer pour récupérer les paramètres de campagne gérés par la boutique pour les installations distribuées via Google Play.

Rapports de campagnes publicitaires payantes (iOS) : Utilisez Apple AdAttributionKit et SKAdNetwork pour des postbacks signés par la plateforme et respectueux de la confidentialité.

Parcours d'intégration web-to-app et parrainages : Utilisez une couche de restauration du contexte d'installation first-party (telle que OpoInstall) pour réappliquer les codes promo, identifiants de salon et jetons de parrainage dès le premier lancement.

Retiblage inter-applications : Nécessite un identifiant ou un mécanisme de mesure autorisé et pris en charge par la plateforme, ainsi que le respect des politiques de la plateforme, des contrôles utilisateur et des exigences de consentement applicables.

Matrice de décision architecturale : choisir la bonne primitive d'attribution

Pour déterminer le mécanisme technique adapté à votre application, évaluez vos exigences opérationnelles spécifiques par rapport aux fonctionnalités des plateformes :

Remplacement du GAID : ce qui fonctionne réellement

Lorsque les équipes d'ingénierie recherchent un « remplaçant au GAID », elles cherchent souvent à résoudre plusieurs problèmes opérationnels déconnectés avec un seul outil. En production, les architectures dépendantes du GAID doivent être déconstruites en quatre solutions indépendantes :

                        Flux GAID hérités
                                 │
     ┌───────────────────────────┼───────────────────────────┐
     │                           │                           │
     ▼                           ▼                           ▼
ROI des campagnes payantes      Routage Web-to-App          Association de parrainage
     │                           │                           │
     ▼                           ▼                           ▼
Play Install Referrer /     Contexte First-Party        Restauration de jeton
AdAttributionKit            Routage de paramètres       de parrainage First-Party

Remplacement de la récupération du contexte d'installation basé sur le GAID : Utilisez Google Play Install Referrer le cas échéant pour les installations distribuées via le Play Store, conjointement avec des intégrations de réseaux publicitaires et des API d'attribution prises en charge par la plateforme. Ces frameworks fournissent le contexte d'origine de l'installation sans exposer de matériel persistant ni d'identifiants publicitaires.

Remplacement du GAID pour l'intégration et le deep linking : Déployez une couche de restauration du contexte d'installation first-party (telle que OpoInstall). Plutôt que d'interroger un identifiant publicitaire pour croiser les journaux de clics, transmettez des paramètres dynamiques via des URL de campagne propriétaires et restaurez-les au premier lancement de l'application via le SDK client.

Remplacement du GAID pour l'identité utilisateur : Utilisez des systèmes de compte first-party authentifiés (tels qu'OAuth ou des UUID d'utilisateurs internes) plutôt que des clés publicitaires au niveau de l'appareil.

Taxonomie architecturale de base : ce que fournissent les différentes primitives

GAID vs Install Referrer vs Restauration de paramètres First-Party

Alternatives au GAID pour l'attribution d'applications Android

Lorsqu'elles opèrent sur des appareils Android sans accès au Google Advertising ID, les équipes d'ingénierie déploient des mécanismes alternatifs adaptés à des canaux de campagne spécifiques :

Comment les plateformes d'attribution mobile (MMP) gèrent la mesure sans GAID

Les partenaires de mesure mobile (MMP) tels qu'AppsFlyer, Adjust, Singular et Branch ont adapté leurs architectures techniques pour prendre en charge la mesure en l'absence d'identifiants publicitaires :

En associant un MMP pour les rapports macro des réseaux publicitaires à une couche de routage contextuel first-party pour la personnalisation micro de l'intégration, les équipes d'ingénierie peuvent établir une pile de mesure et d'intégration complémentaire sans enfreindre les bacs à sable de confidentialité des systèmes d'exploitation.

Pourquoi les restrictions d'identifiants publicitaires perturbent l'attribution mobile déterministe

La dépendance historique aux identifiants publicitaires persistants

Pendant plus d'une décennie, la publicité à la performance mobile s'est appuyée sur une correspondance déterministe au niveau de l'appareil alimentée par les identifiants publicitaires des plateformes : le Google Advertising ID (GAID) sur Android et l'identifiant pour les annonceurs (IDFA) sur iOS. Dans ce flux de travail traditionnel, les réseaux publicitaires capturaient l'identifiant publicitaire de l'utilisateur lors de l'impression ou du clic sur l'annonce. Lorsque l'application était ensuite installée et lancée, le SDK d'attribution intégré interrogeait le système d'exploitation de l'appareil pour récupérer l'identifiant publicitaire correspondant.

Une simple recherche d'égalité côté serveur ($GAID*{\\text{click}} == GAID*{\\text{install}}$) établissait un lien non ambigu entre les dépenses marketing et l'installation de l'application. Ce mécanisme permettait une attribution multi-réseau déterministe, un profilage inter-éditeur et un retiblage automatisé sans nécessiter d'état de session en temps réel ni de transport de paramètres contextuels.

Le mécanisme de mise à zéro des identifiants et des restrictions de plateforme

Les architectures des systèmes d'exploitation mobiles ont évolué pour restreindre le suivi des appareils inter-applications sans le consentement explicite de l'utilisateur.

Sur les plateformes Apple, les directives Apple App Tracking Transparency exigent que les applications demandent l'autorisation de suivi via ATTrackingManager.requestTrackingAuthorization. En l'absence d'autorisation, le système d'exploitation retient l'IDFA. Les applications doivent gérer proprement les états denied (refusé), restricted (restreint) et notDetermined (non déterminé) sans supposer qu'un identifiant publicitaire est accessible.

Sur Android, selon la documentation sur les modifications de comportement d'Android 13, Google a introduit des contrôles de permission explicites dans les services Google Play. Pour les applications ciblant Android 13 (niveau d'API 33) ou supérieur, les développeurs doivent déclarer la permission com.google.android.gms.permission.AD_ID dans leur manifeste pour accéder à l'identifiant publicitaire. Lorsque cette permission est omise, ou lorsqu'un utilisateur limite le suivi publicitaire ou supprime son identifiant publicitaire, les services Google Play peuvent renvoyer un identifiant mis à zéro (00000000-0000-0000-0000-000000000000) ou indiquer que l'identifiant n'est pas disponible selon l'état de l'appareil et le comportement des services Google Play.

L'échec des pipelines d'attribution publicitaire déterministe

Lorsque l'identifiant publicitaire n'est pas disponible ou mis à zéro, un pipeline d'attribution qui dépend de l'égalité des identifiants ne peut plus effectuer de correspondance fiable au niveau de l'utilisateur. Un identifiant publicitaire mis à zéro ou indisponible ne peut pas fournir de clé unique pour distinguer les parcours de conversion individuels.

Pour maintenir la mesure des campagnes et le suivi des conversions, les équipes d'ingénierie doivent s'affranchir des dépendances aux identifiants publicitaires. Les architectures modernes découplent l'attribution des installations des identifiants d'appareils persistants, en s'appuyant sur le routage contextuel first-party et les frameworks de mesure fournis par les plateformes.

Dans cette architecture, OpoInstall est présenté comme une couche de restauration du contexte d'installation first-party / de deep linking différé plutôt que comme un remplaçant universel de Google Play Install Referrer, AdAttributionKit, SKAdNetwork ou d'autres systèmes d'attribution publicitaire gérés par les plateformes.

Comment les permissions d'identifiant publicitaire Android et l'ATT d'Apple affectent l'attribution

Politiques de permission AD_ID de Google Play sur Android 13 et supérieur

Google Play applique une gouvernance de politique granulaire sur l'extraction des identifiants publicitaires :

Exigence de déclaration dans le manifeste : Les applications ciblant Android 13 (niveau d'API 33) ou supérieur doivent déclarer <uses-permission android:name="com.google.android.gms.permission.AD_ID"/> dans leur manifeste. Si omis, les appels à AdvertisingIdClient.getAdvertisingIdInfo(context) renvoient des zéros ou indiquent un état indisponible.

Contrôles de confidentialité de l'utilisateur : Lorsqu'un utilisateur limite le suivi publicitaire ou supprime son identifiant publicitaire, les services Google Play renvoient des zéros ou un état indisponible. Les politiques pour les développeurs Google Play interdisent explicitement de contourner ou de reconstituer l'identifiant publicitaire réinitialisé à l'aide d'autres identifiants d'appareils persistants.

Exclusions de politique pour les applications sensibles : Les politiques de Google Play interdisent de déclarer la permission AD_ID dans les applications ciblant les enfants ou soumises aux contraintes de la politique familiale, obligeant les développeurs à adopter des pipelines de mesure sans identifiant.

Framework Apple AppTrackingTransparency et états d'autorisation

Sur iOS, l'accès aux identifiants est régi par l'état du système ATTrackingManager.AuthorizationStatus :

notDetermined (0) : L'utilisateur n'a pas encore répondu à la demande d'autorisation ATT. L'application ne doit pas supposer que l'accès à l'IDFA est disponible.

restricted (1) : L'appareil est restreint par le contrôle parental ou des profils de gestion d'appareils ; le suivi est désactivé à l'échelle du système.

denied (2) : L'utilisateur a explicitement sélectionné « Demander à l'app de ne pas suivre » sur la invite ou a désactivé les demandes de suivi globalement dans les paramètres de confidentialité iOS. L'application ne doit pas s'appuyer sur l'IDFA.

authorized (3) : L'utilisateur a explicitement accordé l'autorisation de suivi sur les applications et sites web tiers, permettant l'accès à l'IDFA sous réserve des politiques de la plateforme Apple.

Déclaration de limite architecturale importante

Distinction importante : Supprimer le GAID ou l'IDFA d'une architecture d'attribution ne rend pas automatiquement chaque technique de suivi alternative respectueuse de la vie privée ou conforme aux politiques. Selon les directives du framework App Tracking Transparency d'Apple, Apple définit le suivi comme l'association de données d'utilisateurs ou d'appareils collectées à partir de votre app avec des données de tiers à des fins de publicité ciblée ou de mesure, ou le partage de données avec un courtier en données. Si un pipeline d'ingénierie collecte les caractéristiques de l'appareil pour reconstituer une identité persistante inter-applications, il reste soumis aux politiques de suivi de la plateforme, qu'un identifiant publicitaire ait été consulté ou non. Le routage de paramètres first-party doit rester cantonné au contexte immédiat d'intégration et de conversion du parcours initié par l'utilisateur.

Ce que l'attribution sans identifiant ne signifie pas

L'attribution sans identifiant ne signifie pas une analyse sans identifiant. Les applications peuvent toujours traiter des identifiants de compte, des jetons de session first-party ou des paramètres de deep linking requis pour la fonctionnalité interne du produit. L'objectif architectural est d'éliminer la dépendance aux identifiants publicitaires persistants inter-applications pour la correspondance des installations, plutôt de prétendre que toutes les données d'attribution sont entièrement anonymes.

Trois problèmes d'attribution à ne pas confondre

Lors de la conception d'une architecture d'attribution mobile sans identifiants publicitaires, les équipes d'ingénierie doivent différencier trois objectifs opérationnels distincts :

Un mécanisme de routage first-party peut résoudre le deep linking différé et l'attribution de parrainage sans nécessiter de GAID ni d'IDFA, mais il ne doit pas être présenté comme un remplaçant universel de l'attribution publicitaire gérée par les plateformes.

Quand les équipes de croissance doivent-elles déployer une couche d'attribution First-Party ?

Le déploiement d'une couche d'attribution first-party indépendante est recommandé pour les applications exploitant des flux de produits spécifiques :

Applications SaaS et d'abonnement : Plateformes B2B où le trafic marketing commence sur le web de bureau ou mobile et se convertit en comptes d'applications natives nécessitant une restauration de session pré-authentifiée.

Applications de jeux : Jeux multijoueurs ou sociaux où les nouveaux joueurs doivent rejoindre automatiquement la partie, la guilde ou le salon d'un parrain dès le premier lancement sans codes de salon manuels.

Plateformes e-commerce : Applications d'achat proposant des remises de bienvenue personnalisées ou restaurant l'état de paniers actifs des campagnes web mobiles directement vers les vues de paiement natives.

Plateformes de parrainage et de fidélité : Produits stimulant des boucles virales organiques nécessitant une association fiable de jetons parrain-filleul sans obliger les utilisateurs à copier-coller des chaînes de coupons.

Plan architectural pour le routage de paramètres First-Party sans identifiant

Découpler l'attribution des identifiants d'appareils persistants

Dans cet article, nous utilisons le routage de paramètres contextuels (également connu sous le nom d'attribution différée first-party ou de restauration du contexte d'installation) pour décrire la transmission first-party du contexte de campagne ou de parrainage via un parcours web-to-app initié par l'utilisateur.

Les architectures d'attribution modernes se concentrent sur le contexte transactionnel de l'engagement marketing plutôt que d'essayer de suivre l'appareil physique. Lorsqu'un utilisateur potentiel clique sur un lien de campagne, l'interaction se voit attribuer une charge utile de routage transitoire contenant des métadonnées de campagne, des jetons de canal et des paramètres de routage d'application.

Cette charge utile voyage à travers l'entonnoir de conversion parallèlement au parcours utilisateur, permettant à l'application mobile de restaurer l'intention contextuelle au lancement sans interroger les identifiants publicitaires au niveau du système.

Une architecture d'attribution à deux couches

Une architecture d'attribution d'entreprise sépare le deep linking direct des flux d'installation gérés par la boutique :

                Interaction marketing utilisateur
                          │
         ┌────────────────┴────────────────┐
         │                                       │
   Lien d'application direct             Flux boutique / publicitaire
         │                                       │
 Universal Links /                  ┌──────┴───────┐
    App Links                       │                           │
         │                       Android                       Apple
         │                   Play Install                   Attribution
         │                      Referrer                    publicitaire de
         │                                                   la plateforme
         │                            │                              │
         └──────────────┬────────┴──────┬───────┘
                                       │                              │
                                         Signaux d'attribution / de routage
                                                        │
                                             Validation côté serveur
                                                        │
                                    ┌─────────┴─────────┐
                                    │                                      │
                              Contexte trouvé                        Aucun signal
                                   │                                      │
                             Routage / Association                   Organique /
                             First-Party                           Solution de repli gracieuse

Mécanique technique du routage de paramètres contextuels et des solutions de repli

Le rôle du transport de paramètres First-Party

Le transport de paramètres first-party repose sur l'analyse des requêtes web standard et la mise en cache sécurisée des sessions côté serveur. Les développeurs peuvent consulter la documentation du SDK OpoInstall pour connaître les spécifications techniques concernant les modèles d'association de paramètres.

Le routage de paramètres first-party utilisé uniquement pour l'intégration directe ne nécessite pas nécessairement l'ATT lorsque l'implémentation ne répond pas à la définition du suivi d'Apple ; les équipes doivent évaluer le flux de données réel et l'objectif par rapport aux politiques actuelles d'Apple.

Solutions de repli d'attribution d'installation spécifiques à la plateforme

Lorsque les liens profonds directs sont interrompus par l'installation depuis la boutique, les primitives spécifiques à la plateforme fournissent des données d'attribution structurées :

Android (Google Play Install Referrer) : Le guide de l'API Google Play Install Referrer expose les informations de référent associées à l'installation sur le Play Store et fournit les horodatages de clic et d'installation. La documentation de l'API spécifie une fenêtre de disponibilité de 90 jours pour les données de référent. Les applications doivent conserver et traiter cette valeur conformément à leurs propres règles d'attribution et de gestion des réinstallations plutôt que de la traiter comme un identifiant d'installation permanent. Notez que les paramètres doivent être explicitement transmis via Google Play ; les paramètres de requête de page de destination arbitraires ne peuplent pas automatiquement cette API.

Attribution sur la plateforme Apple : La pile d'attribution d'applications moderne d'Apple comprend le framework Apple AdAttributionKit, ainsi que l'interopérabilité avec SKAdNetwork pour les flux de travail publicitaires pris en charge. AdAttributionKit lui-même ne nécessite pas d'invite d'autorisation ATT ; cependant, d'autres flux de données dans la même application peuvent toujours constituer un suivi et nécessiter par conséquent une autorisation ATT. AdAttributionKit fonctionne dans le cadre du framework publicitaire signé d'Apple avec les réseaux publicitaires éligibles enregistrés auprès des frameworks d'attribution d'Apple.

Pourquoi l'attribution basée sur le presse-papiers ne doit pas être une stratégie principale

Le transfert par le presse-papiers ou le presse-papiers doit généralement être traité comme un mécanisme de repli exceptionnel plutôt que comme une conception d'attribution principale. L'accès au presse-papiers introduit des notifications de confidentialité visibles par l'utilisateur, des restrictions de plateforme et une disponibilité incohérente selon les versions des systèmes d'exploitation. Lorsque le stockage dans le presse-papiers est évalué :

Portée explicite : Les charges utiles doivent être de courte durée et limitées au minimum de données spécifiques à l'application requises pour le flux first-party prévu. Les valeurs sensibles doivent être protégées de manière appropriée en transit et au repos.

Nettoyage immédiat : Les applications doivent rapidement effacer ou écraser les jetons de paramètres temporaires une fois consommés lors de la séquence de lancement initiale.

Conformité aux politiques : Utilisez les mécanismes du presse-papiers uniquement lorsqu'il existe un flux utilisateur first-party clairement défini et après examen de la politique de plateforme applicable.

Solution de repli gracieuse et états non attribués

Une architecture de confidentialité résiliente n'essaie pas de forcer les correspondances d'attribution par le biais d'empreintes numériques d'appareils invasives :

Lien d'application direct / Universal Link : Réveil instantané de l'application native lorsque celle-ci est déjà installée sur l'appareil.

Transmission de paramètres gérée par la boutique : Récupération des paramètres de campagne via les API de la plateforme (telles que Google Play Install Referrer) lorsqu'ils sont disponibles.

Restauration de paramètres First-Party : Correspondance des nouvelles sessions d'installation avec les interactions de pages de destination web actives dans une fenêtre temporelle restreinte.

Aucun signal (Non attribué) : Lorsque les conditions réseau changent, que les sessions expirent ou qu'aucun contexte correspondant n'existe, l'application revient en toute sécurité à un état par défaut propre sans interrompre l'expérience d'intégration de l'utilisateur.

Exemple de scénario d'implémentation : restauration du contexte avec OpoInstall

Pour comprendre comment ces primitives fonctionnent en production, prenons l'exemple d'une application de jeu mobile multi-plateforme exécutant deux canaux d'acquisition simultanés :

Canal A (Publicités programmatiques payantes) : Une campagne publicitaire diffusée sur des réseaux publicitaires externes redirigeant vers l'App Store et Google Play.

Canal B (Partage viral par les utilisateurs) : Des joueurs existants partageant des liens d'invitation personnalisés (https://game.example.com/join?room=9876&inviter=usr_432) via des applications de messagerie sociale.

*   

[Canal A : Publicité payante] ──> [Téléchargement boutique] ──> [Play Referrer / AdAttributionKit] ──> [ROI publicitaire agrégé]
[Canal B : Invitation] ──> [Page de destination web] ──> [Restauration de jeton First-Party] ──> [Rejoindre automatiquement le salon de jeu]

Lorsqu'un nouvel utilisateur s'installe via le Canal A, l'application s'appuie sur l'API Google Play Install Referrer ou Apple AdAttributionKit pour rendre compte des performances de la campagne aux tableaux de bord marketing. Lorsqu'un utilisateur s'installe via le Canal B, le SDK de routage first-party capture le jeton d'invitation dynamique dès le premier lancement, faisant immédiatement rejoindre le nouveau joueur au salon 9876 sans interroger les identifiants publicitaires ni déclencher d'invites ATT.

Cas d'échec de production courants dans l'attribution mobile sans identifiant

Lors du déploiement d'une architecture d'attribution qui ne repose pas sur des identifiants publicitaires persistants, les équipes d'ingénierie rencontrent fréquemment des modes de défaillance opérationnels spécifiques :

Cas d'échec 1 : Paramètres de page de destination perdus après la redirection vers la boutique : Si les liens de campagne redirigent via des réducteurs d'URL intermédiaires non encodés, les paramètres de requête tels que channelCode ou referrer peuvent être supprimés avant d'atteindre le script de la page de destination ou la destination de l'app store.

Cas d'échec 2 : Remboursement de parrainage dupliqué et verrous d'idempotence manquants : En production, si le client mobile invoque la restauration de paramètres à chaque événement Activity.onResume ou de premier plan de l'application sans vérifier un indicateur de persistance local, les utilisateurs peuvent déclencher des demandes de récompense dupliquées ou une navigation répétée par lien profond.

Cas d'échec 3 : Mauvaise gestion de l'état de réinstallation : Bien que le Google Play Install Referrer conserve les données historiques du référent jusqu'à 90 jours, les applications réinstallées peuvent recevoir des données d'attribution obsolètes provenant d'un cycle de vie d'installation précédent, à moins que le backend client ne valide si un compte a déjà terminé son inscription.

Cas d'échec 4 : Installations organiques mal classées via de larges fenêtres de correspondance : Si les fenêtres de correspondance de session côté serveur sont configurées de manière trop large dans des environnements dotés de réseaux partagés ou d'une forte densité d'utilisateurs, les installations organiques peuvent entrer en collision avec des sessions de clics web sans rapport.

Modèle d'intégration SDK illustratif pour la restauration du contexte d'installation First-Party

Aperçu de l'intégration côté client

Un SDK de restauration du contexte d'installation first-party peut être utilisé pour implémenter la restauration de paramètres contextuels sans nécessiter d'identifiant publicitaire. Les équipes de développement peuvent télécharger les packages du SDK mobile OpoInstall et les ressources d'intégration.

Remarque sur l'API du SDK : Le cycle de vie d'initialisation et de récupération présenté ci-dessous est une implémentation pseudo illustrative. Les noms d'API ci-dessous sont intentionnellement illustratifs et ne doivent pas être traités comme de la documentation fournisseur. En production, préférez l'initialisation au niveau de l'application documentée du SDK et le cycle de vie du contexte d'installation plutôt que de coupler la récupération d'attribution directement au cycle de vie d'une Activité individuelle. Vérifiez toutes les classes, les noms de méthodes, les types de rappels et les clés de configuration par rapport à la documentation actuelle du fournisseur avant une utilisation en production.

// Implémentation Android : Extraction de paramètres sans identifiant (Modèle d'architecture)
// Emplacement dans la partie A : [CODE_BLOCK_01]
// Remarque : Pseudo-implémentation illustrative basée sur les contrats du SDK OpoInstall.

// ----------------------------------------------------------------------------
// 1. AndroidManifest.xml (Extrait d'exemple)
// ----------------------------------------------------------------------------
/*
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.myapp">
    <uses-permission android:name="android.permission.INTERNET"/>
    <application android:name=".CustomApplication" android:label="@string/app_name">
        <!-- Configurez la clé d'application en utilisant la méthode spécifiée dans la documentation fournisseur -->
        <meta-data android:name="com.opoinstall.APP_KEY" android:value="YOUR_APPKEY"/>
    </application>
</manifest>
*/

// ----------------------------------------------------------------------------
// 2. CustomApplication.kt : Cycle de vie de la machine à états au niveau de l'application
// ----------------------------------------------------------------------------
package com.example.myapp

import android.app.Application
import android.util.Log
import com.opoinstall.api.OpoData
import com.opoinstall.api.OpoError
import com.opoinstall.api.OpoInstall
import com.opoinstall.api.ResultCallBack

class CustomApplication : Application() {

    enum class AttributionState {
        NOT_STARTED,
        FETCHING,
        PROCESSED
    }

    override fun onCreate() {
        super.onCreate()
        
        // Initialiser le SDK de routage first-party dans le processus principal
        OpoInstall.initialize(this)

        // Récupérer le contexte d'installation une seule fois au niveau de l'application
        if (getAttributionState() == AttributionState.NOT_STARTED) {
            fetchInstallContext()
        }
    }

    private fun fetchInstallContext() {
        setAttributionState(AttributionState.FETCHING)

        OpoInstall.getInstance().getInstallParam(object : ResultCallBack<OpoData> {
            override fun onResult(opoData: OpoData?) {
                setAttributionState(AttributionState.PROCESSED)
                if (opoData != null) {
                    val channelCode = opoData.channelCode
                    val customData = opoData.data
                    Log.d("InstallContext", "Contexte restauré : Canal=$channelCode, Données=$customData")
                    handleInstallContext(channelCode, customData)
                }
            }

            override fun onError(opoError: OpoError?) {
                // Si une panne réseau temporaire se produit, l'état peut rester réessayable ou retomber proprement
                Log.w("InstallContext", "Requête d'attribution terminée avec le statut : ${opoError?.errorMsg}")
                setAttributionState(AttributionState.PROCESSED)
            }
        })
    }

    private fun getAttributionState(): AttributionState {
        val raw = getSharedPreferences("attribution_prefs", MODE_PRIVATE)
            .getString("state", AttributionState.NOT_STARTED.name)
        return AttributionState.valueOf(raw ?: AttributionState.NOT_STARTED.name)
    }

    private fun setAttributionState(state: AttributionState) {
        getSharedPreferences("attribution_prefs", MODE_PRIVATE)
            .edit()
            .putString("state", state.name)
            .apply()
    }

    private fun handleInstallContext(channelCode: String?, customData: String?) {
        // Transmettre le contexte restauré aux services internes de compte/routage
    }
}

Implémentation iOS : Intégration du cycle de vie Swift

Sur iOS, l'application intègre le SDK au sein du délégué de cycle de vie de l'application. Le SDK récupère les paramètres d'installation de manière asynchrone sur le thread d'exécution principal sans invoquer de demandes d'autorisation AppTrackingTransparency lorsque le suivi inter-applications n'est pas effectué.

L'implémentation Swift ci-dessous illustre un flux de travail d'initialisation et d'extraction de paramètres :

// Modèle d'intégration iOS : Récupération du contexte d'installation au niveau de l'application
// Emplacement dans la partie A : [CODE_BLOCK_02]
// Remarque : PSEUDOCODE UNIQUEMENT. Les noms de types et de méthodes sont des espaces réservés illustratifs.

// ----------------------------------------------------------------------------
// 1. Info.plist (Extrait d'exemple)
// ----------------------------------------------------------------------------
/*
<!-- Configurez la clé d'application en utilisant la méthode spécifiée dans la documentation fournisseur -->
<key>com.opoinstall.APP_KEY</key>
<string>YOUR_APPKEY</string>
*/

// ----------------------------------------------------------------------------
// 2. AppDelegate.swift : Initialisation du cycle de vie et récupération du contexte
// ----------------------------------------------------------------------------
import UIKit
// Remarque : Importation du module SDK omise intentionnellement ; utilisez le nom de module fourni par votre gestionnaire de packages.

enum InstallContextState: String {
    case notStarted = "NOT_STARTED"
    case fetching = "FETCHING"
    case processed = "PROCESSED"
}

@main
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

    var window: UIWindow?

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        
        // Initialiser le SDK de routage first-party sans invoquer l'autorisation ATT
        OpoInstallSDK.initWith(self)

        // Sécuriser la récupération avec une vérification de la machine à états au point d'entrée de l'application
        if getInstallContextState() == .notStarted {
            fetchInstallContext()
        }

        return true
    }

    private func fetchInstallContext() {
        setInstallContextState(.fetching)

        // Récupérer les paramètres d'installation différée de manière asynchrone
        OpoInstallSDK.defaultManager()?.getInstallParmsCompleted({ [weak self] (appData: OpoinstallData?) in
            DispatchQueue.main.async {
                self?.setInstallContextState(.processed)

                if let data = appData?.data {
                    let channel = appData?.channelCode
                    self?.handleInstallContext(channelCode: channel, customData: data)
                }
            }
        })
    }

    private func getInstallContextState() -> InstallContextState {
        let raw = UserDefaults.standard.string(forKey: "install_context_state") ?? InstallContextState.notStarted.rawValue
        return InstallContextState(rawValue: raw) ?? .notStarted
    }

    private func setInstallContextState(_ state: InstallContextState) {
        UserDefaults.standard.set(state.rawValue, forKey: "install_context_state")
    }

    private func handleInstallContext(channelCode: String?, customData: String) {
        // Transmettre le contexte restauré aux services internes de compte/routage
    }

    // Rappel du délégué Universal Link pour le deep linking
    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        OpoInstallSDK.continue(userActivity)
        return true
    }
}

Considérations d'ingénierie pour l'implémentation client

Cycles de vie de l'UI non bloquants : Initialisez toujours les SDK d'attribution de manière asynchrone et interrogez les paramètres sans bloquer le thread d'interface utilisateur principal lors du lancement de l'application.

Gestion locale de l'idempotence : Maintenez une machine à états ou un indicateur persistant (par exemple, NOT_STARTED, FETCHING, PROCESSED) pour gérer l'extraction de paramètres proprement et éviter les requêtes API redondantes.

Défense contre la relecture côté serveur : Validez les charges utiles de paramètres dynamiques par rapport aux journaux de transactions du backend pour vérifier que les codes de parrainage ou les jetons promotionnels ne peuvent pas être rejoués de manière malveillante.

API d'attribution de plateforme et transition vers Privacy Sandbox

Attribution sur la plateforme Android et transition vers Privacy Sandbox

Les API de reporting d'attribution d'Android ont été conçues pour prendre en charge la mesure respectueuse de la vie privée à travers les applications et le web sans s'appuyer sur des identifiants inter-parties.

Les API de reporting d'attribution d'Android sont disponibles pour les intégrations Privacy Sandbox prises en charge, mais elles ne constituent pas un remplacement universel d'Install Referrer ou d'une intégration MMP. L'applicabilité en production dépend de la version spécifique d'Android, de l'intégration de la technologie publicitaire, des exigences d'inscription et de la prise en charge de l'écosystème. Les équipes doivent vérifier la documentation actuelle d'Android Privacy Sandbox avant de faire du reporting d'attribution une dépendance de production.

Pour les applications Android distribuées via le Play Store, Google Play Install Referrer reste un mécanisme first-party pratique pour récupérer les paramètres de campagne associés à une installation sur le Play Store. Les réseaux publicitaires et les fournisseurs d'attribution peuvent également proposer des intégrations de mesure prises en charge par la plateforme.

Attribution sur la plateforme Apple : AdAttributionKit et SKAdNetwork

Sur iOS, Apple fournit des mécanismes d'attribution respectueux de la vie privée centrés sur AdAttributionKit, qui prend en charge les campagnes publicitaires d'applications sur l'App Store et les marchés alternatifs, ainsi que l'interopérabilité avec SKAdNetwork. Ces frameworks fournissent des signaux d'attribution gérés par la plateforme sans exposer d'identifiant publicitaire d'appareil persistant. La granularité et le timing des rapports restent régis par les seuils de confidentialité d'Apple et les fenêtres d'attribution.

Coexistence du routage First-Party et des API de plateforme

Les API de confidentialité des plateformes et le routage contextuel first-party répondent à des exigences d'ingénierie différentes :

API de confidentialité des plateformes : Conçues pour la mesure publicitaire au niveau macro, le calcul du ROI des réseaux publicitaires et l'optimisation des campagnes programmatiques sans identifiants persistants.

Routage de paramètres First-Party : Conçu pour l'intégration d'applications au niveau micro, l'association instantanée de récompenses de parrainage d'utilisateur à utilisateur, le routage de liens profonds et les parcours de conversion web-to-app directs.

Comment valider la précision de l'attribution dans les environnements de bac à sable

Tester l'attribution des installations lorsque l'accès à l'identifiant publicitaire n'est pas disponible

Pour vérifier qu'une application gère correctement l'attribution des installations sur divers appareils et états d'autorisation :

État AD_ID manquant : Déployez une version de test Android qui exclut la permission com.google.android.gms.permission.AD_ID de AndroidManifest.xml et vérifiez que l'application s'initialise proprement.

Limitations des identifiants utilisateur : Sur un appareil de test Android avec les services Google Play, activez les limitations publicitaires ou supprimez l'identifiant publicitaire dans les paramètres du système pour vous assurer que l'extraction des paramètres ne plante pas ou ne se bloque pas.

Simulation de campagne Play Store : Déclenchez un parcours d'installation à l'aide d'une URL de campagne de test qui transmet explicitement la valeur attendue via le mécanisme Google Play Install Referrer. Ne supposez pas qu'un paramètre de requête de page de destination arbitraire deviendra automatiquement une valeur d'Install Referrer.

Vérification de la réinstallation : Réinstallez l'application après une installation attribuée précédente et vérifiez que le flux d'attribution ne réutilise pas incorrectement un ancien état de première installation.

Vérification du repli organique : Lancez une version non liée pour confirmer que getInstallParam se résout proprement à null ou à un repli organique sans se bloquer.

Simuler les états refusés de l'ATT sur les appareils iOS physiques

Pour tester la récupération de paramètres iOS lorsque le suivi est refusé :

Installez la version de test sur un appareil iOS physique via Xcode.

Vérifiez que la méthode de récupération des paramètres du SDK s'exécute de manière asynchrone et résout les paramètres avec succès sans demander l'ATT ni interroger les API IDFA.

Testez les comportements de lancement d'application à la fois pour le démarrage à froid et les cycles de vie de réveil en arrière-plan.

Auditer les charges utiles réseau pour la minimisation des données

Les équipes de sécurité et de conformité doivent inspecter le trafic réseau côté client à l'aide d'un proxy HTTP :

Confirmer l'exclusion des identifiants : Vérifiez que les requêtes d'attribution sortantes n'incluent pas d'identifiants persistants tels que l'IMEI, les adresses MAC, l'ID Android (SSAID) ou des chaînes IDFA non autorisées.

Sécurité du transport : Assurez-vous que la communication de l'API d'attribution utilise HTTPS avec des configurations TLS actuelles et une validation de certificat standard.

Protection de la charge utile : Confirmez que les jetons dynamiques stockés en transit ou dans des mémoires tampons temporaires utilisent des normes de protection appropriées.

Créer une infrastructure d'attribution sans identifiant avec OpoInstall

Les équipes d'ingénierie évaluant une pile de croissance indépendante des identifiants publicitaires ont besoin de trois capacités techniques fondamentales :

Restauration de contexte transparente : Transmission de métadonnées personnalisées des pages de destination web vers les applications natives sans codes de parrainage manuels ni collecte d'identifiants matériels.

Gestion du contexte de campagne multi-plateforme : Gestion des campagnes web-to-app et mobiles sur l'ensemble des plateformes sans nécessiter de multiples versions d'applications.

Conformité stricte aux plateformes : Fonctionnement entièrement au sein des bacs à sable d'applications first-party et respect des contraintes de confidentialité des systèmes d'exploitation.

Pour explorer les modèles d'implémentation pour la mesure mobile et le routage, consultez la documentation OpoInstall ou accédez à la console développeur OpoInstall.

Résumé et cadre de décision

Pour bâtir des architectures de croissance mobile durables malgré des restrictions croissantes sur les identifiants publicitaires, les équipes d'ingénierie doivent s'affranchir des dépendances héritées du GAID et de l'IDFA. S'appuyer sur des identifiants d'appareils persistants introduit une fragilité structurelle à mesure que les systèmes d'exploitation et les politiques réglementaires continuent de restreindre le suivi inter-applications.

Un framework d'attribution moderne associe le transport de paramètres first-party, des API de mesure gérées par la plateforme et une extraction SDK côté client résiliente. En déployant des architectures de routage contextuel, les équipes mobiles maintiennent des parcours de conversion web-to-app fiables tout en restant alignées sur les exigences de confidentialité des plateformes.

Matériel connexe

Concepts : Restrictions d'identifiants publicitaires, routage de paramètres contextuels, Install Referrer, AdAttributionKit, App Tracking Transparency

Technologies : API Google Play Install Referrer, API publicitaire Google Play Services, Framework Apple ATT, Apple AdAttributionKit, SDK mobile OpoInstall

Sujets de sécurité : Minimisation des données mobiles, protection contre la relecture, sécurité du transport

API : API Google Play Install Referrer, API Google Advertising ID, API Apple App Tracking Transparency, API de paramètres d'installation OpoInstall

Documentation officielle

Android

Documentation de l'identifiant publicitaire des services Google Play

Modifications du comportement d'Android 13 pour l'identifiant publicitaire

Guide de l'API Google Play Install Referrer

Apple

Documentation du développeur Apple sur l'App Tracking Transparency

Documentation du développeur Apple sur AdAttributionKit

Documentation du développeur Apple sur l'attribution publicitaire

Comprendre l'interopérabilité d'AdAttributionKit et SKAdNetwork

Attribution préservant la confidentialité

Présentation de Google Privacy Sandbox