Fonctionnalités prises en charge pour on-device decisioning

Le SDK JS Adobe Target offre aux clients la possibilité de choisir entre les performances et l’actualisation des données pour les décisions. En d’autres termes, si la diffusion de contenu personnalisé le plus pertinent et attrayant par le biais de l’apprentissage automatique est la plus importante pour vous, un appel au serveur en direct doit être effectué. Mais lorsque les performances sont plus critiques, une décision doit être prise sur l’appareil et en mémoire. Pour que on-device decisioning fonctionne, reportez-vous aux sections suivantes qui répertorient les fonctionnalités prises en charge.

Types d’activité pris en charge

Le tableau suivant indique les types d’activité créés par le compositeur d’expérience d’après les formulaires ou le compositeur d’expérience visuelle (VEC) sont pris en charge ou non pour on-device decisioning.

Type d’activité

Pris en charge ?

Test A/B

Oui

affectation automatique

Non

Ciblage automatique

Non

Test multivarié (MVT)

Non

Ciblage d’expérience (XT)

Oui

Automated Personalization

Non

Recommendations

Non

Activités utilisant Analytics pour Target (A4T)

Oui

Ciblage de l’audience

Le tableau suivant indique les règles d’audience prises en charge ou non pour on-device decisioning.

Ciblage géographique pour on-device decisioning

Pour maintenir une latence minimale pour les activités on-device decisioning avec des audiences basées sur la géolocalisation, Adobe vous recommande de fournir vous-même les valeurs géographiques dans l’appel à getOffers. Définissez l’objet Geo dans le contexte de la requête. Cela signifie, à partir du navigateur, un moyen de déterminer l’emplacement de chaque visiteur. Par exemple, vous pouvez effectuer une recherche IP/géo à l’aide d’un service que vous configurez. Certains fournisseurs d’hébergement, tels que Google Cloud, fournissent cette fonctionnalité par le biais d’en-têtes personnalisés dans chaque HttpServletRequest.

window.adobe.target.getOffers({
    decisioningMethod: "on-device",
    request: {
        context: {
            geo: {
                city: "SAN FRANCISCO",
                countryCode: "US",
                stateCode: "CA",
                latitude: 37.75,
                longitude: -122.4
            }
        },
        execute: {
            pageLoad: {}
        }
    }
})

Cependant, si vous ne parvenez pas à effectuer des recherches IP vers géo sur votre serveur, mais que vous souhaitez toujours effectuer on-device decisioning pour les demandes getOffers qui contiennent des audiences basées sur la géographie, cela est également pris en charge. L’inconvénient de cette approche est qu’elle utilise une recherche IP/géo distante, ce qui ajoute une latence à chaque appel getOffers. Cette latence doit être inférieure à un appel getOffers avec prise de décision côté serveur, car elle atteint un réseau de diffusion de contenu situé près de votre serveur. Indiquez uniquement le champ "ipAddress" dans l’objet Geo dans le contexte de votre requête pour que le SDK récupère la géolocalisation de l’adresse IP de votre visiteur. Si un autre champ en plus de "ipAddress" est fourni, le SDK Target ne récupérera pas les métadonnées de géolocalisation pour la résolution.

window.adobe.target.getOffers({
    decisioningMethod: "on-device",
    request: {
        context: {
            geo: {
                ipAddress: "127.0.0.1"
            }
        },
        execute: {
            pageLoad: {}
        }
    }
})

Méthode d’affectation

Le tableau suivant indique les méthodes d’attribution prises en charge ou non pour on-device decisioning.