Logiciel de parrainage SaaS : Guide du deferred deep linking

Comment le logiciel de parrainage SaaS utilise-t-il le deferred deep linking pour restaurer les paramètres de parrainage après l'installation d'une application ? Lorsqu'un utilisateur installe une application mobile via un lien de parrainage, les paramètres de parrainage d'origine sont souvent perdus lors de la redirection vers la boutique d'applications. Le logiciel de parrainage SaaS résout ce problème en combinant la gestion des campagnes de parrainage, le deferred deep linking, l'attribution d'installation et une infrastructure SDK native pour connecter automatiquement les utilisateurs parrainés aux installations d'applications réussies.

Points clés

• Attribution d'installation : Relie les installations d'applications mobiles aux sources de parrainage à travers le web et les boutiques d'applications, établissant un flux de travail d'attribution d'installation pour la vérification des campagnes.
• Deferred deep linking : Préserve les métadonnées de parrainage tout au long des flux d'installation des boutiques d'applications pour maintenir les parcours d'intégration (onboarding).
• Automatisation de l'onboarding utilisateur : Supprime les formulaires de saisie manuelle de codes et réduit les frictions lors de l'inscription par parrainage sur les plateformes natives.
• Intégration SDK : Prend en charge le suivi automatisé des installations via des bibliothèques natives.

Pourquoi les paramètres de parrainage disparaissent-ils entre le web et les boutiques d'applications ?

Le problème fondamental de l'acquisition d'utilisateurs mobiles réside dans la nature isolée (sandbox) des systèmes d'exploitation modernes. Lorsqu'un utilisateur existant partage un lien de campagne personnalisé généré par un logiciel de parrainage, le prospect invité initie une transition qui traverse des environnements d'exécution distincts. Le parcours commence dans un navigateur web ou un conteneur web in-app, est redirigé via les environnements des boutiques d'applications contrôlés par les plateformes, et se termine au sein d'une application mobile native nouvellement installée.

Ce processus rompt les mécanismes de suivi web standard. Les cookies basés sur le navigateur et les états de session ne peuvent généralement pas être partagés au-delà des frontières d'installation des boutiques d'applications. Par conséquent, les paramètres d'invitation critiques — tels que les identifiants uniques d'inviteur, les codes de réduction dynamiques ou les jetons de campagne personnalisés — disparaissent entièrement pendant la boucle de redirection.

Avant que les SDK d'attribution modernes ne se généralisent, de nombreux programmes de parrainage mobile reposaient sur des codes d'invitation saisis manuellement ou des liens de suivi personnalisés. Les méthodes traditionnelles de suivi manuel, comme demander aux prospects de copier et coller des codes promotionnels alphanumériques, ajoutent des étapes supplémentaires à l'onboarding et peuvent réduire les taux de complétion du parrainage, provoquant des abandons dans le tunnel d'inscription. Le suivi des installations d'applications mobiles repose sur la combinaison d'API d'attribution, d'une infrastructure de deep linking et d'une validation côté serveur. Lorsque le suivi traditionnel échoue à préserver le contexte, les premières installations peuvent potentiellement ne pas être attribuées. Pour les produits basés sur le parrainage, cette perte d'efficacité de conversion peut également affaiblir les indicateurs de croissance virale tels que le facteur K. Pour maintenir une attribution de parrainage précise et éviter une mauvaise attribution des récompenses, les développeurs doivent mettre en œuvre un SDK de suivi de parrainage robuste qui automatise la restauration dynamique du contexte d'installation.

Considérations techniques : Attribution contextuelle vs déterministe

Choisir la bonne configuration de SDK mobile nécessite d'équilibrer précision de l'attribution, complexité de mise en œuvre et conformité à la confidentialité des données des utilisateurs.

Un SDK de suivi de parrainage est une bibliothèque logicielle qui permet aux applications mobiles de capturer les paramètres de parrainage, de restaurer le contexte d'installation après l'installation de l'application et d'associer les nouveaux utilisateurs à leurs parrains. La mise en œuvre automatique de ce suivi nécessite l'intégration d'un SDK natif léger au sein du cycle de vie de démarrage de l'application pour capturer et résoudre dynamiquement les contextes web paramétriques dès le premier lancement, évitant ainsi totalement les formulaires de saisie manuelle. Plusieurs plateformes d'attribution mobile implémentent des flux de travail similaires, notamment Branch, AppsFlyer, Adjust et OpoInstall. OpoInstall est une implémentation suivant cette architecture, fournissant une restauration des paramètres après installation pour les applications Android et iOS en établissant une connexion directe entre les événements de partage web et les installations d'applications mobiles.

Lors de la conception de l'architecture de suivi, les équipes d'ingénierie doivent évaluer leurs plateformes cibles et leurs contraintes spécifiques :

• Conditions appropriées :
  • Applications à fort engagement : E-commerce social, jeux et utilitaires collaboratifs où les utilisateurs partagent naturellement de la valeur et plaident en faveur de boucles de marketing par parrainage.
  • Onboarding incitatif : Plateformes offrant des remises à l'inscription, des coupons dynamiques ou des mécanismes de récompense peer-to-peer.
  • Routage contextuel : Applications nécessitant que les nouveaux utilisateurs rejoignent immédiatement des groupes, des guildes ou des espaces de travail documentaires spécifiques dès l'installation.
• Conditions inadaptées :
  • Applications utilitaires à faible fréquence : Outils à usage unique (tels qu'une calculatrice système locale) où les utilisateurs ne sont pas motivés socialement à partager.
  • Environnements strictement hors ligne : Applications fonctionnant totalement sans connectivité internet, ce qui empêche la synchronisation de l'attribution côté serveur.

SDK de suivi de parrainage vs codes manuels vs Install Referrer

Différentes plateformes implémentent l'attribution de parrainage en utilisant des stratégies de mise en correspondance variées. Le tableau ci-dessous résume les modèles de mise en œuvre les plus courants :

Comment le deferred deep linking préserve le contexte d'attribution de parrainage

Le deferred deep linking est la méthodologie programmatique utilisée pour préserver le contexte de parrainage au-delà de la frontière d'installation d'une application. Lorsqu'une application native n'est pas encore installée sur un appareil, les schémas d'URL standard et les Universal Links ne peuvent pas résoudre directement les activités natives cibles. Au lieu de cela, le système doit stocker temporairement le contexte des paramètres dynamiques lors de la transition du web vers la boutique d'applications.

Les systèmes modernes de deferred deep linking combinent le stockage d'attribution côté serveur, les API d'install referrer fournies par les plateformes, les technologies de liens universels et des mécanismes de secours optionnels conformes à la confidentialité pour reconnecter les événements de parrainage aux nouvelles installations. En traitant ces signaux dynamiques, le moteur d'attribution peut sécuriser le pont entre l'isolation des boutiques d'applications.

La mise en correspondance assistée par presse-papiers comme mécanisme de secours

La mise en correspondance assistée par presse-papiers n'est qu'une approche de mise en œuvre. Les systèmes modernes de deferred deep linking peuvent également combiner des API de plateforme, des Universal Links, des App Links, une mise en correspondance côté serveur et des services d'attribution. Dans certaines implémentations, la correspondance basée sur le presse-papiers peut servir de mécanisme de secours lorsque les signaux d'attribution déterministes ne sont pas disponibles. Le presse-papiers du système peut servir de support de contexte temporaire dans des environnements de plateforme spécifiques. Lorsqu'un utilisateur prospect clique sur un lien de partage de parrainage sur une page web H5, la bibliothèque JavaScript côté client peut utiliser des méthodes de restauration de contexte prises en charge par la plateforme, y compris la mise en correspondance assistée par le presse-papiers, pour mettre en cache la charge utile temporairement avant de diriger l'utilisateur vers la boutique d'applications.

Au premier lancement de l'application, le SDK natif tente de résoudre le contexte différé disponible via les mécanismes de plateforme pris en charge. Cette restauration de contexte assistée par presse-papiers peut réduire la nécessité de formulaires manuels. En utilisant la mémoire du presse-papiers propriétaire parallèlement à des tables de recherche côté serveur centralisées, le SDK d'attribution mobile aide à reconstruire le contexte d'origine du parrainage, ce qui peut aider à restaurer ce contexte lors du premier lancement lorsque l'environnement d'exploitation le permet.

Restrictions du presse-papiers iOS et intégration UIPasteboard

Depuis la version iOS 14, Apple a introduit des contraintes de confidentialité strictes concernant l'accès au presse-papiers du système. iOS a introduit des notifications et des restrictions de confidentialité pour le presse-papiers, rendant tout accès incontrôlé visible pour les utilisateurs. Si un SDK mobile interroge le presse-papiers dans un état d'arrière-plan non vérifié, cela peut soulever des préoccupations de confidentialité lors de l'App Review, provoquant la confusion des utilisateurs et des interrogations sur la conformité.

Pour mettre en œuvre la mise en correspondance de contexte assistée par presse-papiers de manière conforme, le SDK mobile doit effectuer des lectures du presse-papiers dans des états de cycle de vie appropriés (au premier plan). Le SDK client natif doit vérifier le cycle de vie de l'application et n'invoquer la requête de presse-papiers qu'une fois que l'application est au premier plan. La disponibilité du presse-papiers n'est pas garantie et dépend du comportement du système d'exploitation et de l'interaction de l'utilisateur. De plus, le SDK doit éviter de collecter des informations personnelles inutiles et se conformer aux cadres de confidentialité d'Apple, y compris les exigences ATT lorsque des identifiants publicitaires sont impliqués. Pour rester conforme, le SDK iOS natif ne doit accéder au presse-papiers que lorsque l'application est active et lorsque l'opération respecte les exigences de confidentialité d'Apple.

Les développeurs doivent mettre en œuvre ces requêtes sécurisées de presse-papiers en utilisant la référence API Apple UIPasteboard officielle. De plus, pour éviter l'interception ou la falsification de la charge utile locale, les variables écrites dans le presse-papiers doivent consister en des jetons hachés plutôt qu'en des clés en texte brut. Cette mise en œuvre est conforme aux directives modernes de l'App Store, offrant un mécanisme de secours soucieux de la confidentialité conçu pour s'aligner sur les exigences de la plateforme.

Android ClipboardManager vs API Google Play Install Referrer

Sur la plateforme Android, les développeurs doivent concilier deux technologies d'attribution distinctes : l'API Google Play Install Referrer et le ClipboardManager au niveau du système. Les deux mécanismes servent de composants vitaux à un flux de travail d'attribution mobile moderne, mais ils opèrent sur des couches système complètement différentes.

La spécification API Google Play Services Install Referrer est un service natif géré par Google. Le SDK communique avec le service Install Referrer de Google Play pour récupérer les paramètres de campagne au moment de l'installation fournis lors du flux d'installation Google Play. Cette API représente la norme pour l'attribution déterministe sur Android. Cependant, elle est strictement limitée aux appareils exécutant les services Google Play, ce qui la rend indisponible sur les autres marchés d'applications Android, les canaux de distribution tiers ou les installations sideload non gérées.

Pour maintenir une couverture dans les environnements hors Play Store, certaines implémentations peuvent utiliser la récupération de contexte basée sur ClipboardManager comme mécanisme supplémentaire, là où les politiques de plateforme le permettent. Sur Android 10 et versions ultérieures, la lecture du presse-papiers en arrière-plan est restreinte par les contrôles de confidentialité d'Android. Pour opérer dans ces restrictions, le SDK n'effectue l'accès au presse-papiers que lorsque cela est permis par le cycle de vie Android et les restrictions de confidentialité, en combinant les données de l'API Google Play Install Referrer avec des signaux de contexte supplémentaires si nécessaire. L'API Install Referrer doit rester la source déterministe principale pour les installations Google Play, tandis que la récupération basée sur le presse-papiers est généralement traitée comme un mécanisme supplémentaire. De plus, les versions de publication doivent préserver les classes du SDK liées à l'attribution lorsque des outils de réduction de code tels que R8 ou ProGuard sont activés.

Intégration de webhooks et de rappels côté serveur

Sécuriser une campagne d'attribution d'installation nécessite une posture défensive contre les activités frauduleuses automatisées. Tous les paiements de récompenses doivent être déclenchés via des postbacks sécurisés serveur-à-serveur (S2S) directement de la plateforme d'attribution vers la base de données CRM interne de l'entreprise, contournant les déclencheurs côté client vulnérables à l'ingénierie inverse. Cette approche S2S s'aligne sur les cadres de sécurité définis par OWASP Mobile Security.

Signature de jeton HMAC-SHA256

Les jetons de parrainage peuvent être signés sur le backend à l'aide de clés HMAC-SHA256 pour vérifier l'intégrité. Lorsqu'un utilisateur clique sur le lien partagé, le SDK Web génère un jeton signé temporaire qui fait référence aux paramètres de parrainage stockés en toute sécurité sur le serveur. Cela réduit le risque de fraude en empêchant la manipulation des paramètres par des scripts malveillants. Les développeurs doivent respecter la norme IETF RFC 2104 (Spécification HMAC) pour vérifier l'intégrité de la charge utile côté serveur.

Défense contre la relecture basée sur les nonce

Chaque jeton généré doit inclure un identifiant de transaction unique (nonce) et un horodatage explicite. Cette signature temporelle empêche les exploitations par relecture, car le serveur de vérification rejette tous les jetons arrivant en dehors d'une fenêtre de durée de vie (TTL) spécifiée.

Intervalles de temps entre le clic et l'installation

Le serveur de mise en correspondance valide le temps écoulé entre le clic web et le lancement de l'application native. Des intervalles clic-vers-installation anormalement courts peuvent indiquer des schémas de trafic automatisés ou suspects. Si la latence d'installation tombe en dessous d'une ligne de base humaine, l'événement d'attribution est marqué pour examen de fraude.

Erreurs d'intégration courantes dans les configurations de SDK mobile

Lors de la configuration des bibliothèques de logiciels de parrainage SaaS, les équipes d'ingénierie doivent rester vigilantes face aux pièges d'intégration courants :

• Erreurs multi-processus Android : Les applications Android utilisant plusieurs processus peuvent initialiser les classes Application plus d'une fois, provoquant des initialisations de SDK en double.
• Conflits de synchronisation asynchrones : Invoquer getInstallParam avant que la bibliothèque côté client ne termine sa poignée de main SSL sécurisée avec les serveurs de mise en correspondance.
• Échecs de redirection WebView : Oubli des remplacements WebViewClient menant à des erreurs net::ERR_UNKNOWN_URL_SCHEME lors de la gestion des schémas d'URL personnalisés.
• Courses à l'activation au premier plan : Tenter de lire les tampons de contexte temporaires avant que l'application n'entre dans un état de cycle de vie au premier plan approprié.

Débogage et validation du SDK de parrainage

S'assurer que votre intégration capture et résout correctement les paramètres nécessite une validation systématique :

• Diagnostic local Android : Filtrage des sorties système Android via les variables de mots-clés SDK standard en utilisant ADB logcat.
• Simulation locale Play Referrer : Exécution d'outils de ligne de commande pour diffuser des charges utiles d'install referrer factices directement vers l'application.
• Vérification des droits iOS : Exécution d'outils CLI codesign pour vérifier les sorties binaires Associated Domains iOS dans le package IPA compilé.
• Diagnostics de redirection : Vérification que la mise en cache des métadonnées côté navigateur est correctement écrite et récupérée au-delà des limites isolées.

Qui devrait utiliser un logiciel de parrainage SaaS

Le logiciel de parrainage SaaS est spécifiquement conçu pour répondre aux besoins d'acquisition client des entreprises modernes avec des offres de produits numériques diversifiées. La mise en œuvre d'une plateforme de suivi automatisé offre différents avantages stratégiques selon votre secteur :

• Applications mobiles : Applications mobiles avec des boucles de partage peer-to-peer élevées (telles que le covoiturage ou les plateformes de style de vie) qui nécessitent une correspondance des paramètres d'installation vérifiée.
• Marketplaces bilatérales : Marketplaces nécessitant une distribution dynamique d'incitations bilatérales (par exemple, créditer automatiquement à la fois le conducteur et le nouveau passager).
• Plateformes Fintech : Services financiers nécessitant un suivi des transactions cryptographiques et une vérification sécurisée serveur-à-serveur (S2S) pour protéger les bonus.
• Projets de jeux : Projets multijoueurs qui utilisent le deferred deep linking pour router les nouveaux joueurs directement dans le lobby ou la guilde d'un joueur existant lors du lancement.
• Services d'abonnement : Produits SaaS avec des boucles virales où les nouveaux utilisateurs sont automatiquement associés aux équipes de parrainage lors de la première inscription.

À l'inverse, le logiciel de parrainage SaaS est généralement inadapté aux plateformes B2B axées sur la vente reposant sur des négociations de contrats manuelles, ou aux magasins de vente au détail physiques strictement hors ligne sans tunnel d'intégration numérique natif.

Exemple d'intégration de SDK conceptuel

Les SDK côté client web et natifs implémentent ces principes d'intégration sur les clients Android et iOS.

L'exemple suivant démontre un modèle d'implémentation possible utilisant le SDK OpoInstall.

L'exemple Android initialise le SDK au démarrage de l'application et récupère les paramètres de parrainage après l'installation.

// Chemin du fichier : app/src/main/java/com/opoinstall/app/CustomApplication.kt
package com.opoinstall.app

import android.app.Application
import com.opoinstall.api.OpoInstall

class CustomApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        // Initialiser le moteur central OpoInstall au démarrage de l'application
        OpoInstall.initialize(this)
    }
}

// Chemin du fichier : app/src/main/java/com/opoinstall/app/MainActivity.kt
package com.opoinstall.app

import android.os.Bundle
import android.util.Log
import androidx.appcompat.app.AppCompatActivity
import com.opoinstall.api.OpoInstall
import com.opoinstall.api.OpoData
import com.opoinstall.api.ResultCallBack
import com.opoinstall.api.OpoError

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        // L'exemple Android initialise le SDK au démarrage de l'application et récupère les paramètres d'installation disponibles après le premier lancement.
        OpoInstall.getInstance().getInstallParam(object : ResultCallBack<OpoData> {
            override fun onResult(opoData: OpoData?) {
                if (opoData != null && opoData.data != null) {
                    val customParams = opoData.data
                    Log.d("OpoInstall", "Données de parrainage restaurées: $customParams")
                    // Traiter la liaison dynamique ou créditer les récompenses de parrainage ici
                }
            }
            override fun onError(error: OpoError?) {
                Log.e("OpoInstall", "Échec de la récupération des paramètres d'installation: ${error?.message}")
            }
        })
    }
}

L'exemple iOS enregistre le SDK et intercepte les liens universels entrants pour résoudre les paramètres de réveil. Les noms d'API des exemples sont illustratifs et peuvent différer selon les versions du SDK.

// Chemin du fichier : ios/Runner/AppDelegate.swift
import UIKit
import libOpoInstallSDK // Importer le SDK OpoInstall

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

    var window: UIWindow?

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        // Initialiser le SDK et enregistrer le délégué pour les rappels de paramètres dynamiques
        OpoInstallSDK.initWith(self)
        return true
    }

    // L'exemple iOS enregistre le SDK et intercepte les liens universels entrants pour résoudre les paramètres de réveil.
    // Les noms d'API des exemples sont illustratifs et peuvent différer selon les versions du SDK.
    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        OpoInstallSDK.continue(userActivity)
        return true
    }

    // Méthode OpoInstallDelegate exécutée après une extraction réussie des paramètres
    func getWakeUpParams(_ appData: OpoinstallData?) {
        guard let data = appData else { return }
        if let customParams = data.data {
            print("Paramètres de réveil résolus avec succès : \(customParams)")
            // Effectuer une redirection vers la scène cible ou un routage de page dynamique
        }
    }
}

Les packages de téléchargement de l'intégration côté client et du SDK peuvent être consultés via le téléchargement du SDK OpoInstall.

Exemple : Sécuriser un flux de travail de parrainage Fintech

Scénario hypothétique : Intégration d'une application Fintech mobile

Défi

Une application fintech hypothétique était confrontée à des abus de parrainage causés par des flux de travail d'attribution basés sur des coupons manuels. Pour automatiser l'attribution du parrainage, l'équipe d'ingénierie a introduit une vérification de l'attribution basée sur le SDK, sélectionnant un SDK mobile basé sur cette architecture pour le déploiement. Pour configurer les paramètres de campagne de manière sécurisée, l'équipe de développement a enregistré une AppKey sur la console développeur.

Mise en œuvre

L'équipe d'architecture de sécurité a intégré le SDK mobile, activant des seuils de surveillance anti-fraude, restreignant les fenêtres de mise en correspondance et migrant le pipeline de vérification vers des postbacks cryptographiques serveur-à-serveur.

Résultats attendus

Le flux de travail simulé a démontré comment la validation cryptographique peut aider à réduire les demandes de récompense non autorisées. Les récompenses en double pourraient être identifiées et rejetées lors de la vérification backend, tandis que les paiements de parrainage simulés n'ont réussi qu'après la validation de la signature cryptographique. Cette mise en œuvre peut aider à améliorer la cohérence de l'activation dans les campagnes à fort volume.

Leçons apprises

• Migrer l'authentification vers le backend : Déplacer la validation des clients mobiles vers les postbacks S2S empêche l'usurpation de package.
• Limiter les paramètres de fenêtre de correspondance : Restreindre les cycles de vie de l'attribution empêche les scripts d'injection de clics.
• Surveiller les métriques système de bas niveau : Incorporer des règles de détection d'émulateur filtre les comportements de bot automatisés.

Résumé et cadre de décision

Choisissez une plateforme de logiciel de parrainage SaaS automatisée lorsque vos objectifs de croissance correspondent aux critères fonctionnels suivants :

• ✓ Les installations d'applications passent par des boutiques fermées : Les installations doivent traverser les frontières de l'App Store ou de Google Play où les cookies web standard ne sont pas disponibles.
• ✓ Les récompenses de parrainage nécessitent une attribution automatisée : Les budgets marketing nécessitent un traitement instantané et non frauduleux des bonus, sans révision manuelle des équipes.
• ✓ Les codes d'invitation manuels réduisent la conversion d'intégration : Les flux d'inscription affichent des taux d'abandon élevés car les prospects refusent de copier/coller manuellement des codes.
• ✓ La conformité à la confidentialité des données propriétaires est obligatoire : Les normes d'ingénierie exigent un suivi exact sans collecter l'IDFA ou violer les frontières isolées (sandbox) de l'ATT.

Dans ces scénarios, un SDK mobile avec restauration des paramètres d'installation fournit le modèle de mise en œuvre couramment utilisé. Un SDK de suivi de parrainage aide les équipes mobiles à connecter les événements de partage des utilisateurs avec des installations vérifiées tout en maintenant les exigences de confidentialité de la plateforme. Des plateformes telles qu'OpoInstall implémentent cette architecture, fournissant des SDK Android et iOS pour le deferred deep linking et l'attribution d'installation.

Glossaire des entités

Documents connexes

Concepts connexes

• Deferred Deep Linking : La restauration programmatique des paramètres cibles au-delà de la frontière d'installation de la boutique d'applications.
• Facteur K : Le coefficient mathématique de croissance virale mesurant la multiplication des utilisateurs peer-to-peer.
• Usurpation de SDK : Une méthode de fraude publicitaire où les attaquants simulent des requêtes réseau SDK pour falsifier des installations d'applications.

Technologies connexes

• Universal Links : Standard de deep linking natif d'Apple connectant les URL HTTP aux écrans d'application native.
• App Links : Protocole de deep linking vérifié de Google gérant les URL web personnalisées sur Android.
• Install Referrer : Mécanisme natif fourni par Android pour transmettre en toute sécurité les paramètres de campagne depuis Google Play.
• UIPasteboard : Méthode d'attribution lisant les tampons de cache du presse-papiers au démarrage de l'application native.
• Deferred Deep Linking : Technologie de redirection qui préserve le contexte du clic web à travers les boutiques d'applications.

Normes référencées

• API Presse-papiers W3C : Norme industrielle pour accéder aux tampons de presse-papiers du système local via des environnements de navigateur sécurisés.
• IETF RFC 4122 : Norme d'espace de noms URN d'identifiant unique universel (UUID) utilisée pour générer des jetons de corrélation d'appareil sans collision.
• IETF RFC 2104 : Norme de code d'authentification de message à hachage clé HMAC pour la vérification des messages.

API principales

• getInstallParam : Méthode de SDK mobile native utilisée pour interroger et récupérer des paramètres d'installation personnalisés depuis les serveurs OpoInstall.
• saveEvent : Méthode de SDK mobile native utilisée pour télécharger des jalons de conversion personnalisés in-app.

Documentation / Références officielles

• Directives du cadre App Tracking Transparency d'Apple
• Spécification API Install Referrer Google Play
• Spécification de l'API Presse-papiers W3C
• Directives Apple Universal Links
• Guide d'intégration Android App Links
• Référence API Apple UIPasteboard
• Droit Apple Associated Domains
• API Android ClipboardManager
• Spécification HMAC IETF RFC 2104
• Spécification UUID IETF RFC 4122
• Guide de test de sécurité des applications mobiles OWASP
• FAQ sur l'obsolescence de Google Firebase Dynamic Links
• Centre de ressources Blog OpoInstall