Comment recibler les visiteurs web avec des bannières intelligentes dynamiques

Comment lancer des campagnes de reciblage à l'aide de bannières intelligentes ? Le déploiement de campagnes de reciblage avec des bannières intelligentes nécessite de capturer le contexte de navigation web first-party, d'afficher des bannières HTML dynamiques avec des appels à l'action (CTA) en deep-link contextuels, et de rediriger les utilisateurs vers les scènes correspondantes au sein de l'application mobile tout en transmettant les jetons d'attribution.

Le reciblage des visiteurs web via des bannières intelligentes est une stratégie d'ingénierie de croissance qui capture le contexte de navigation first-party sur les sites mobiles et affiche des bannières promotionnelles personnalisées pour diriger les visiteurs directement vers des scènes natives. En remplaçant les liens statiques vers l'App Store par des deep-links contextuels, ces bannières aident à préserver l'intention de l'utilisateur, à réengager les utilisateurs actifs et à soutenir l'engagement à long terme sur l'application.

Comment le reciblage des visiteurs web soutient l'engagement in-app

Le paradoxe de l'intention web mobile : Volume de navigation élevé vs faibles taux de conversion

Les sites web mobiles représentent un canal d'acquisition vaste, capturant le trafic en haut de tunnel provenant de la recherche organique, des campagnes payantes, des réseaux sociaux et de la syndication de contenu. Cependant, le comportement des consommateurs sur mobile présente un paradoxe : les utilisateurs parcourent, recherchent et évaluent souvent des produits sur le web mobile, alors que les applications natives offrent des parcours transactionnels plus fluides grâce à la conservation de l'état local et à une navigation simplifiée.

Les navigateurs mobiles introduisent des points de friction opérationnels par rapport aux applications natives, tels que les exigences de ré-authentification ou les formulaires web multi-étapes. Lorsqu'un visiteur à forte intention consulte un catalogue produit ou ajoute des articles à un panier sur mobile, l'absence de transition directe vers l'environnement in-app peut contribuer à l'abandon de panier et réduire la valeur vie client (LTV).

Surmonter la « perte au lobby » : Pourquoi réengager les utilisateurs sur la page d'accueil nuit à la conversion

Un défi courant du reciblage web mobile est le déploiement de bannières statiques qui dirigent les utilisateurs vers l'écran d'accueil par défaut de l'application native. Lorsqu'un utilisateur actif ou inactif consulte un produit spécifique sur un site web, cliquer sur une bannière générique déclenche un lancement d'application qui les envoie sur le lobby principal.

Cette déconnexion crée une friction cognitive immédiate. L'utilisateur doit naviguer manuellement dans les menus, effectuer de nouvelles recherches ou retrouver son panier à partir de zéro. Chaque étape manuelle augmente le risque de décrochage. Les bannières intelligentes dynamiques traitent cette friction en associant directement le contexte de navigation web aux routes des deep-links, dirigeant les utilisateurs vers la vue produit pertinente, le panier pré-rempli ou la page promotionnelle au sein de l'application native.

Évaluer le « Time-to-Action » en tant que métrique de friction opérationnelle pour les visiteurs web

Dans le marketing du cycle de vie, l'attention de l'utilisateur diminue rapidement avec les délais de navigation. La métrique opérationnelle Time-to-Action ($T_{\text{action}}$) mesure la durée temporelle entre le moment où un visiteur web clique sur une bannière de reciblage et le moment où il interagit activement avec l'élément cible ou l'écran de paiement à l'intérieur de l'application native :

Dans les tunnels sans contexte, le $T_{\text{action}}$ est prolongé par la navigation manuelle et les délais de recherche dans l'application. Le routage contextuel permet de réduire la partie consacrée à la navigation manuelle du $T_{\text{action}}$. Toutefois, le $T_{\text{action}}$ total inclut toujours le lancement de l'application, la restauration des paramètres, la validation locale, l'autorisation serveur et le rendu de la scène. Minimiser la navigation manuelle préserve l'intention d'achat et crée une opportunité testable pour améliorer la complétion des paiements.

Comment l'assemblage contextuel transforme les bannières web statiques en outils de reciblage

Capturer le contexte web first-party et gérer les cycles de stockage

Contrairement aux bannières statiques affichant un contenu codé en dur, les bannières de reciblage dynamique inspectent les données de session web first-party pour adapter le message. Lorsqu'un visiteur navigue sur un site mobile, des scripts côté client lisent l'état de la session depuis le DOM, les paramètres de requête de l'URL ou le stockage web first-party (sessionStorage ou localStorage) :

• SKU produit consulté : Capture l'identifiant spécifique du produit (ex: item_id=SKU_5501) actuellement consulté.
• Jetons d'abandon de panier : Lit les identifiants de panier en attente et les indicateurs d'éligibilité aux remises.
• Affinité de catégorie : Suit les catégories de navigation principales (ex: électronique, habillement) pour personnaliser les promotions de secours.

Les architectes doivent prendre en compte les cycles de vie du stockage des navigateurs mobiles. Selon les politiques modernes de prévention du suivi WebKit, le stockage inscriptible par script client (localStorage, sessionStorage, IndexedDB) peut être supprimé après sept jours sans interaction de l'utilisateur avec le site, selon l'état de prévention du suivi de WebKit et l'engagement récent. Le stockage du navigateur doit être traité comme un cache de session côté client temporaire, et non comme un profil client durable ou une base de données faisant autorité. L'état du panier, la disponibilité des articles et les droits de l'utilisateur doivent toujours être résolus et vérifiés côté serveur.

Limites de confidentialité et consentement pour les données de reciblage

La collecte et la transmission du contexte de navigation à travers les frontières web et natives nécessitent un respect strict de la gouvernance de la vie privée :

• Minimisation des données : Collectez et utilisez le contexte de reciblage uniquement sous réserve des politiques de consentement, d'avis, de conservation et de minimisation des données applicables au site et à l'application.
• Pas de PII dans les URL : Évitez d'encoder directement des données personnelles identifiables (PII) ou des attributs sensibles dans les URL de bannières ou le stockage côté client.
• État éphémère : Traitez le contexte de navigation capturé comme un état first-party éphémère soumis aux préférences de consentement de l'utilisateur et aux règles de prévention de suivi des plateformes.

Rendu de contenu dynamique : Mise à jour en temps réel des bannières

Une fois le contexte de session extrait, la bannière met à jour sa mise en page dynamiquement :

• Le titre de la bannière passe d'un texte générique à des invites contextuelles (ex: « Continuer votre commande » ou « Voir le produit dans l'App »).
• Le bouton CTA passe d'un standard « INSTALLER » à une invite actionnable (ex: « Ouvrir le panier »).
• Les visuels dynamiques affichent la vignette du produit spécifique avec les indicateurs de stock ou de prix actuels.

Cette pertinence contextuelle transforme la bannière d'un élément publicitaire passif en un utilitaire interactif.

Gestion des contraintes inter-domaines : Recommandation de sous-domaines dédiés pour les Universal Links

Lors du déploiement d'Universal Links sur iOS, les architectes web doivent naviguer dans la contrainte de navigation « même domaine » d'Apple Safari, documentée dans la documentation développeur Apple sur l'autorisation aux apps et sites web de lier votre contenu. Si un utilisateur consulte une page sur https://example.com et clique sur un Universal Link pointant vers le même domaine, Safari reste généralement dans le navigateur plutôt que de lancer l'application native.

Utiliser un hôte de routage associé distinctement peut éviter ce comportement, mais l'ouverture de l'application native dépend toujours d'une association valide, de l'éligibilité de l'application installée et de l'état de la plateforme :

• Hébergez le site mobile principal sur https://www.example.com.
• Routez les cibles des bannières via un sous-domaine associé vérifié, tel que https://app.example.com/product/5501.

Le rôle du deep linking différé quand l'application n'est pas installée

Tous les visiteurs web reciblés par des bannières dynamiques n'ont pas l'application installée. Les schémas d'URI personnalisés (myapp://) peuvent échouer sur les appareils sans l'application, sauf si la page propose un repli explicite.

Le deep linking différé résout ce scénario. Lorsqu'un utilisateur non équipé clique sur une bannière, la couche de routage capture le contexte de destination (comme le SKU consulté et le jeton promo actif) sur le serveur d'attribution avant de rediriger le navigateur vers Google Play ou l'App Store. Lorsque l'utilisateur télécharge et ouvre l'application pour la première fois, un SDK d'attribution récupère les paramètres mis en cache, permettant à l'application native de restaurer la scène ciblée au premier lancement, là où les politiques de confidentialité des plateformes le permettent.

Mécaniques techniques de liaison de paramètres dynamiques et routage deep link

Structurer les paramètres d'URL pour le reciblage

Une chaîne de requête de reciblage robuste structure clairement la destination, les jetons promotionnels et l'attribution de campagne :

https://app.example.com/promo/cart?scene=cart&item_id=SKU_5501&promo_code=RESTART10&token=TK_1234567890abcdef&utm_source=web_retargeting

Cette charge utile sépare proprement les instructions de routage (scene=cart), les identifiants métier (item_id) et le contexte de suivi (utm_source).

Enforcement de la sanitisation des données côté client et contraintes de longueur

Conformément au guide OWASP de test de sécurité des applications mobiles sur les deep links non sécurisés, tous les paramètres extraits d'URL web ou de stockage client doivent être traités comme des entrées non fiables.

Avant de construire les charges utiles de deep-link :

• Validez les identifiants de scene par rapport à une liste blanche de cibles approuvées (cart, product_detail, promo_hub).
• Appliquez des filtres d'expression régulière alphanumériques (ex: ^[A-Za-z0-9_-]{1,64}$) sur les identifiants et codes promo.
• Appliquez des limites de longueur strictes sur les jetons de route (ex: 16 à 128 caractères) et validez les chaînes de campagne contre une politique définie, en rejetant ou remplaçant les valeurs invalides par des valeurs par défaut sécurisées.
• Traitez les jetons de route comme des références opaques non fiables. La possession d'un jeton ne doit jamais autoriser l'accès au panier, aux remises ou aux actions de compte sans validation backend authentifiée.

Déclenchement des transferts via les gestionnaires du SDK Web

Une intégration type du SDK Web OpoInstall expose une méthode de transfert wake-or-install ; vérifiez le nom exact de la méthode, le constructeur, le chemin CDN et le schéma de paramètres par rapport à la version du SDK déployée dans votre environnement.

OpoInstall prend en charge le transfert inter-plateforme web-vers-app et la récupération différée des paramètres ; le mécanisme de routage exact et le contrat SDK dépendent de la version déployée. Consultez la documentation d'intégration SDK pour les paramètres d'interface complets et les spécifications API.

[L'utilisateur consulte une page web mobile (ex: SKU_1024)]
                         │
                         ▼
[Le script capture le contexte dans une session first-party]
                         │
                         ▼
[La bannière intelligente dynamique affiche une offre contextuelle]
                         │
                         ▼
[L'utilisateur clique sur "CONTINUER DANS L'APP"]
                         │
     ┌───────────────────┴───────────────────┐
     ▼                                       ▼
[App installée]                      [App non installée]
     │                                       │
     ▼                                       ▼
[Universal Link / App Link]         [Couche de routage web]
     │                                       │
     ▼                                       ▼
[Lancement direct de l'app]          [Téléchargement / Deep Link différé]
     │                                       │
     └───────────────────┬───────────────────┘
                         ▼
          [Récupération des paramètres par le SDK natif]
                         │
                         ▼
          [Validation de l'état serveur et auth]
                         │
                         ▼
          [Affiche la scène in-app ciblée]

Comment concevoir une restauration de scène in-app fluide pour le reciblage

Gestion des démarrages à froid vs résumés en arrière-plan sur Android et iOS

Les applications mobiles natives doivent gérer les charges utiles de reciblage entrant via des états d'exécution distincts :

• Reprise (Warm Resume) : L'app est déjà en mémoire. Sur Android, l'intent est délivré à onNewIntent. Sur iOS, le lien est transmis à scene(_:continue:). Le routeur de l'app navigue dans la hiérarchie active sans réinitialiser l'état global.
• Démarrage à froid (Cold Start) : Le processus est terminé. Le système d'exploitation démarre le processus et transmet l'intent. L'architecture doit capturer la charge utile, vérifier l'initialisation et router vers la scène cible une fois les hiérarchies d'interface chargées.

Isoler les identifiants de routage des identifiants d'authentification utilisateur

Les URL deep link et bannières web-vers-app ne doivent porter que l'intention de routage (quel produit ou panier afficher) et des jetons de référence opaques de courte durée. En aucun cas, les chaînes de requête ne doivent contenir d'identifiants de base de données bruts, mots de passe ou jetons de session non hachés.

L'application native doit résoudre indépendamment l'authentification utilisateur depuis son magasin sécurisé local (comme iOS Keychain ou Android Keystore) avant d'afficher des informations privées ou de modifier l'état du compte.

Implémentation de portes d'autorisation serveur pour les remises exclusives et le panier

Une chaîne de requête deep-link valide ne garantit pas qu'une promotion est active ou que l'utilisateur est éligible. Les applications clientes doivent soumettre les jetons de route au backend pour vérification :

• Vérifiez que les codes promotionnels (promo_code) ne sont pas expirés et éligibles.
• Validez que les jetons de panier sont actifs et appartiennent au compte authentifié.
• Appliquez l'idempotence et des contrôles de rejeu pour prévenir les abus de coupons.

Gestion des cibles obsolètes : Routage de secours pour offres expirées ou ruptures de stock

Les visiteurs peuvent cliquer sur des bannières plusieurs jours après la fin d'une offre ou la rupture de stock d'un produit. Si une app tente de charger un produit supprimé sans validation, les utilisateurs rencontrent des interfaces cassées.

Les architectures de production imposent une porte de secours à deux niveaux :

1. Vérification côté client : Si la scène cible est méconnue ou la syntaxe malformée, router immédiatement vers l'écran d'accueil par défaut.
2. Vérification côté serveur : Si la route est valide mais que l'article est en rupture ou le code expiré, afficher une notification modale informative (ex: « Cet article est en rupture, découvrez nos recommandations ») et basculer vers le hub de catégorie pertinent.

Implémentation Front-end et Mobile pour les bannières contextuelles

Structurer le script front-end contextuel avec des replis pré-attachés

L'implémentation suppose qu'un composant de bannière modulaire est déjà monté dans le balisage de la page web. Le script applique des contrôles de nullité, une classification de plateforme, des vérifications de cooldown et une sanitisation stricte avant de se lier aux gestionnaires du SDK. La personnalisation du texte de la bannière est dérivée directement du modèle de données normalisé pour assurer l'alignement entre le texte affiché et la charge utile de transfert.

Interception des intents Android et extraction de paramètres en Kotlin

Sur Android, la MainActivity principale capture les intents entrants via onCreate et onNewIntent, normalisant les types de données et validant les champs avant de déléguer l'autorisation au backend.

Traitement des Universal Links via SceneDelegate en Swift (iOS)

Sur iOS, SceneDelegate.swift traite les Universal Links via scene(_:continue:), analysant les paramètres, sanitant les entrées et routant vers les contrôleurs de vue natifs sur l'acteur principal.

L'implémentation ci-dessous démontre la configuration de bannière front-end et l'extraction de paramètres native (Kotlin pour Android et Swift pour iOS). Les schémas OpoInstall sont illustrés ci-dessous ; vérifiez les noms de packages, classes SDK, chemins CDN et signatures de méthodes avec la version actuelle du SDK OpoInstall.

// JavaScript : Extraction contextuelle, gating plateforme et intégration SDK
// Modèle d'intégration type. Vérifiez les URL de scripts, noms de constructeurs et signatures API
// avec la release de production du SDK OpoInstall déployée.
// Note : Supposons un composant de bannière réutilisable avec les IDs cibles déjà monté.
(function() {
    var DISMISS_KEY = "retarget_smart_banner_dismissed_at";
    var COOL_DOWN_MS = 7 * 24 * 60 * 60 * 1000; // Fenêtre de 7 jours

    // 1. Évaluation plateforme : Supprimer sur desktop
    function getMobilePlatform() {
        var ua = navigator.userAgent || navigator.vendor || window.opera;
        if (/Android/i.test(ua)) return "android";
        var isIOS = /iPad|iPhone|iPod/.test(ua) && !window.MSStream;
        var isIPadOS = (navigator.platform === "MacIntel" && navigator.maxTouchPoints > 1);
        if (isIOS || isIPadOS) return "ios";
        return "unsupported_desktop";
    }

    var platform = getMobilePlatform();
    if (platform === "unsupported_desktop") {
        return; // Suppress on desktop browsers
    }

    // 2. Vérification de fermeture via Local Storage
    function shouldShowBanner() {
        try {
            var dismissedAt = localStorage.getItem(DISMISS_KEY);
            if (!dismissedAt) return true;
            var now = new Date().getTime();
            return (now - parseInt(dismissedAt, 10)) > COOL_DOWN_MS;
        } catch (e) {
            return true; // Fallback to display if localStorage is restricted
        }
    }

    if (!shouldShowBanner()) {
        return;
    }

    // DOM Null-Guards : Vérifier éléments avant manipulation
    var bannerContainer = document.getElementById("dynamicRetargetBanner");
    var closeBtn = document.getElementById("bannerCloseBtn");
    var actionBtn = document.getElementById("bannerActionBtn");
    var bannerTitle = document.getElementById("bannerTitle");

    if (!bannerContainer || !actionBtn || !bannerTitle) {
        return;
    }

    // 3. Extraction et sanitisation (schéma 'item_id' cohérent)
    var urlParams = new URLSearchParams(window.location.search);
    var rawScene = urlParams.get("scene") || "cart";
    var rawId = urlParams.get("item_id") || "";
    var rawPromo = urlParams.get("promo_code") || "";
    var rawToken = urlParams.get("token") || "";
    var rawChannel = urlParams.get("utm_source") || "web_retargeting";

    function sanitizePayload() {
        var allowedScenes = ["cart", "product_detail", "promo_hub"];
        var targetScene = allowedScenes.indexOf(rawScene) !== -1 ? rawScene : "cart";

        var idRegex = /^[A-Za-z0-9_-]{1,64}$/;
        var targetId = idRegex.test(rawId) ? rawId : "";

        // Validation indépendante code promo (limite 32-caractères)
        var promoRegex = /^[A-Za-z0-9_-]{1,32}$/;
        var promoCode = promoRegex.test(rawPromo) ? rawPromo : "";

        var tokenRegex = /^[A-Za-z0-9_-]{16,128}$/;
        var routeToken = tokenRegex.test(rawToken) ? rawToken : "";

        var channelRegex = /^[A-Za-z0-9_-]{1,32}$/;
        var channelCode = channelRegex.test(rawChannel) ? rawChannel : "web_retargeting";

        var payload = {
            scene: targetScene,
            token: routeToken
        };
        if (targetId.length > 0) {
            payload.item_id = targetId;
        }
        if (promoCode.length > 0) {
            payload.promo_code = promoCode;
        }

        return {
            payload: payload,
            channelCode: channelCode
        };
    }

    var normalizedData = sanitizePayload();

    // Personnaliser le contenu basé sur le modèle normalisé
    if (normalizedData.payload.scene === "cart") {
        bannerTitle.textContent = "Continuer votre commande";
        actionBtn.textContent = "OUVRIR PANIER";
    } else if (normalizedData.payload.scene === "product_detail") {
        bannerTitle.textContent = "Voir le produit dans l'App";
        actionBtn.textContent = "VOIR ARTICLE";
    }

    bannerContainer.style.display = "block";

    // Gérer la fermeture utilisateur
    if (closeBtn) {
        closeBtn.addEventListener("click", function() {
            try {
                localStorage.setItem(DISMISS_KEY, new Date().getTime().toString());
            } catch (e) {}
            bannerContainer.style.display = "none";
        });
    }

    // 4. Route de secours statique initiale
    function executeStaticFallback() {
        if (platform === "android") {
            window.location.href = "https://play.google.com/store/apps/details?id=com.example.app";
        } else if (platform === "ios") {
            window.location.href = "https://apps.apple.com/app/id123456789";
        }
    }

    var activeClickHandler = function() {
        executeStaticFallback();
    };

    actionBtn.addEventListener("click", function(e) {
        activeClickHandler(e);
    });

    // 5. Injection dynamique de script pour intégration SDK
    var script = document.createElement("script");
    script.type = "text/javascript";
    script.src = "https://web.cdn.opoinstallcloud.com/openinstall.js";

    script.onload = function() {
        try {
            if (typeof OpenInstall === "function") {
                var openInstall = new OpenInstall({
                    appKey: "YOUR_OPOINSTALL_APPKEY",
                    onready: function() {
                        var m = this;
                        // Upgrade vers deep link dynamique une fois le SDK prêt
                        activeClickHandler = function() {
                            var sanitized = sanitizePayload();
                            m.wakeupOrInstall({
                                data: sanitized.payload,
                                channelCode: sanitized.channelCode
                            });
                        };
                    }
                }, actionBtn);
            }
        } catch (err) {
            // Garder repli statique si l'init échoue
        }
    };

    script.onerror = function() {
        // Garder repli statique si la requête réseau échoue
    };

    document.head.appendChild(script);
})();

// Android : MainActivity.kt - Traitement des intents de réengagement & validation
package com.example.app.ui

import android.content.Intent
import android.os.Bundle
import android.util.Log
import androidx.appcompat.app.AppCompatActivity
import com.opoinstall.api.OpoInstall
import com.opoinstall.api.listener.AppWakeUpAdapter
import com.opoinstall.api.model.AppData
import org.json.JSONObject

data class ValidatedRetargetingRoute(
    val scene: String,
    val targetId: String,
    val promoCode: String,
    val routeToken: String,
    val rawKeys: Set<String>
)

object OpoInstallPayloadAdapter {
    fun normalize(rawPayload: Any?): ValidatedRetargetingRoute? {
        if (rawPayload == null) return null

        val stringMap = when (rawPayload) {
            is String -> parseJsonStringStrict(rawPayload)
            is Map<*, *> -> parseMapStrict(rawPayload)
            is JSONObject -> parseJsonObjectStrict(rawPayload)
            else -> {
                Log.w("PayloadAdapter", "Type de charge utile SDK non supporté : ${rawPayload.javaClass.name}")
                null
            }
        } ?: return null

        val scene = stringMap["scene"] ?: ""
        if (scene.isEmpty()) return null

        return ValidatedRetargetingRoute(
            scene = scene,
            targetId = stringMap["item_id"] ?: "",
            promoCode = stringMap["promo_code"] ?: "",
            routeToken = stringMap["token"] ?: "",
            rawKeys = stringMap.keys
        )
    }

    private fun parseJsonStringStrict(rawJson: String): Map<String, String>? {
        return try {
            val json = JSONObject(rawJson)
            parseJsonObjectStrict(json)
        } catch (e: Exception) {
            Log.e("PayloadAdapter", "Échec parsing JSON string", e)
            null
        }
    }

    private fun parseJsonObjectStrict(json: JSONObject): Map<String, String>? {
        val map = mutableMapOf<String, String>()
        for (key in json.keys()) {
            val value = json.opt(key)
            if (value !is String) {
                Log.w("PayloadAdapter", "Valeur non-string rejetée pour la clé : $key")
                null
            }
            map[key] = value as String
        }
        return map
    }

    private fun parseMapStrict(rawMap: Map<*, *>): Map<String, String>? {
        val map = mutableMapOf<String, String>()
        for ((key, value) in rawMap) {
            if (key !is String || value !is String) {
                return null
            }
            map[key] = value
        }
        return map
    }
}

object RetargetingRouteValidator {
    private val allowedKeys = setOf("scene", "item_id", "promo_code", "token")
    private val allowedScenes = setOf("cart", "product_detail", "promo_hub")

    fun validate(payload: ValidatedRetargetingRoute): ValidatedRetargetingRoute? {
        if (!allowedKeys.containsAll(payload.rawKeys)) {
            return null
        }
        if (!allowedScenes.contains(payload.scene)) {
            return null
        }
        // Validation regex alphanumérique
        val alphanumericRegex = Regex("^[A-Za-z0-9_-]+$")
        if (payload.targetId.isNotEmpty() && (payload.targetId.length > 64 || !payload.targetId.matches(alphanumericRegex))) {
            return null
        }
        if (payload.promoCode.isNotEmpty() && (payload.promoCode.length > 32 || !payload.promoCode.matches(alphanumericRegex))) {
            return null
        }
        if (payload.routeToken.isNotEmpty() && (payload.routeToken.length !in 16..128 || !payload.routeToken.matches(alphanumericRegex))) {
            return null
        }
        return payload
    }
}

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        intent?.let { handleRetargetingIntent(it) }
    }
    override fun onNewIntent(intent: Intent) {
        super.onNewIntent(intent)
        setIntent(intent)
        handleRetargetingIntent(intent)
    }
    private fun handleRetargetingIntent(intent: Intent) {
        OpoInstall.getInstance().getWakeUp(intent, object : AppWakeUpAdapter() {
            override fun onWakeUp(appData: AppData?) {
                val rawPayload = appData?.data ?: return
                val canonicalPayload = OpoInstallPayloadAdapter.normalize(rawPayload)
                val validatedRoute = canonicalPayload?.let { RetargetingRouteValidator.validate(it) }

                if (validatedRoute != null) {
                    BackendRouteAuthorizer.verifyRouteAuthorization(validatedRoute.scene, validatedRoute.targetId, validatedRoute.routeToken) { isAuthorized ->
                        runOnUiThread { if (isAuthorized) executeTargetNavigation(validatedRoute) else executeLobbyFallback("Expiration.") }
                    }
                } else {
                    runOnUiThread { executeLobbyFallback("Charge utile invalide.") }
                }
            }
        })
    }
    private fun executeTargetNavigation(route: ValidatedRetargetingRoute) { }
    private fun executeLobbyFallback(reason: String) { }
}
object BackendRouteAuthorizer {
    fun verifyRouteAuthorization(scene: String, targetId: String, token: String, callback: (Boolean) -> Unit) {
        callback(false)
    }
}

// iOS : SceneDelegate.swift - Processing des Universal Links
import UIKit
import libOpoInstallSDK

struct ValidatedRetargetingRoute {
    let scene: String, targetId: String, promoCode: String, routeToken: String, rawKeys: Set<String>
}

class OpoInstallPayloadAdapter {
    static func normalize(rawPayload: Any?) -> ValidatedRetargetingRoute? {
        guard let payload = rawPayload, let dict = payload as? [String: Any] else { return nil }
        // ... logique de normalisation (identique Kotlin) ...
        return nil // Implémentation complète requise
    }
}

class SceneDelegate: UIResponder, UIWindowSceneDelegate, OpoInstallDelegate {
    func getWakeUpParams(_ appData: OpoInstallData?) {
        guard let data = appData, let rawPayload = data.data else { return }
        // Logique de validation et navigation
    }
}

Exécution thread-safe : Préserver la sécurité du thread UI

Les callbacks de scène arrivent sur le cycle de vie UIKit ; les callbacks asynchrones d'autorisation doivent marshaler les mutations UI vers l'acteur principal ou le thread UI pour maintenir la sécurité thread et prévenir les glitches de rendu.

Matrice de performance du tunnel Web vers App

Portes de télémétrie pour le reciblage

Pour évaluer les performances, les équipes growth suivent quatre métriques principales :

• Taux de clic bannière (CTR) : Proportion des visiteurs qui cliquent sur la bannière intelligente.
• Taux d'ouverture in-app (CAOR) : Pourcentage de clics résultant en une ouverture d'application vérifiée.
• Taux de succès de restauration de scène : Pourcentage de sessions deep-link qui valident et affichent la scène cible.
• Taux de conversion (CVR) : Proportion d'utilisateurs reciblés complétant une action cœur (paiement, enregistrement) dans la fenêtre d'attribution.

Audit des courbes de rétention : Expérimentation par cohortes

L'efficacité du réengagement doit être évaluée via des expérimentations contrôlées distinguant le lift métier Intent-to-Treat (ITT) de la rétention conditionnelle :

1. Taux d'app active ITT ($A_t$) : Compare des cohortes randomisées exposées à des bannières contextuelles vs bannières génériques.
2. Rétention post-ouverture conditionnelle ($R_t$) : Analyse la persistance parmi ceux ayant complété le transfert web-vers-app.

Matrice comparative des approches de bannières

Résumé et cadre de décision

Le reciblage des visiteurs web via des bannières intelligentes dynamiques fait le pont entre le trafic de découverte et les expériences in-app avec contexte préservé. Se fier à des bannières statiques gaspille une intention d'achat précieuse et introduit une friction qui doit être mesurée.

En capturant des signaux web first-party, en rendant des bannières HTML personnalisées et en exécutant des transferts deep-link, les équipes techniques réduisent la friction et soutiennent l'engagement. Le ROI des campagnes doit être validé empiriquement via des expérimentations en cohortes.

Pour explorer les architectures de bannières inter-plateformes et de deep linking dynamique, consultez la documentation d'intégration SDK.

Matériels associés

• Concepts : Engagement App, Redirection Web vers App, Bannières dynamiques, Restauration de scène, Tunnels de reciblage
• Technologies : Universal Links, Android App Links, Deep Linking différé, Stockage Web W3C
• Standards : IETF RFC 3986, Spécifications Apple Associated Domains, Android Digital Asset Links, Guide OWASP MASTG
• APIs / Modèles d'intégration : Modèle d'intégration deep-linking web-vers-app, Android getIntent, iOS UIWindowSceneDelegate