Présentation des fonctionnalités prises en charge

Dernière mise à jour : 2023-07-27
  • Rubriques :
  • APIs/SDKs
    Afficher plus sur ce sujet
  • Créé pour :
  • Developer

Adobe TargetLes SDK côté serveur permettent aux développeurs 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. Pour prise de décision sur appareil pour travailler, reportez-vous à la liste suivante des fonctionnalités prises en charge :

  • Types d’activité
  • Ciblage d’audience
  • Méthode d’affectation

Types d’activités

Le tableau suivant indique laquelle types d’activités créé à l’aide de la fonction Compositeur d’expérience d’après les formulaires sont prises en charge ou non prises en charge pour prise de décision sur appareil.

Type d’activité Pris en charge
Test A/B Oui
affectation automatique Non
ciblage automatique Non
Analytics for Target (A4T) Oui
Test multivarié (MVT) Non
Ciblage d’expérience (XT) Oui
Automated Personalization (AP) Non
Recommandations Non

Ciblage de l’audience

Le tableau suivant indique les règles d’audience prises en charge ou non par prise de décision sur appareil.

Règle d’audience Prise de décision sur appareil
Géo Oui
Réseau Non
Mobile Non
Paramètres personnalisés Oui
Système d’exploitation Oui
Pages du site Oui
Navigateur Oui
Profil du visiteur Non
Sources de trafic Non
Période Oui
Audiences Experience Cloud (Audiences de Adobe Audience Manager, Adobe Analytics et Adobe Experience Manager Non

Ciblage géographique pour prise de décision sur appareil

Pour maintenir une latence proche de zéro pour prise de décision sur appareil activités avec des audiences basées sur la géographie, Adobe vous recommande de fournir les valeurs géographiques vous-même dans l’appel à la fonction getOffers. Pour ce faire, définissez la variable Geo dans le Context de la requête. Cela signifie que votre serveur aura besoin d’un moyen de déterminer l’emplacement de chaque utilisateur final. Par exemple, votre serveur peut 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.

const CONFIG = {
    client: "acmeclient",
    organizationId: "1234567890@AdobeOrg",
    decisioningMethod: "on-device"
};

const targetClient = TargetClient.create(CONFIG);

targetClient.getOffers({
    request: {
        context: {
            geo: {
                city: "SAN FRANCISCO",
                countryCode: "US",
                stateCode: "CA",
                latitude: 37.75,
                longitude: -122.4
            }
        },
        execute: {
            pageLoad: {}
        }
    }
})
public class TargetRequestUtils {

    public static Context getContext(HttpServletRequest request) {
        Context context = new Context()
            .geo(ipToGeoLookup(request.getRemoteAddr()))
            .channel(ChannelType.WEB)
            .timeOffsetInMinutes(330.0)
            .address(getAddress(request));
        return context;
    }

    public static Geo ipToGeoLookup(String ip) {
        GeoResult geoResult = geoLookupService.lookup(ip);
        return new Geo()
            .city(geoResult.getCity())
            .stateCode(geoResult.getStateCode())
            .countryCode(geoResult.getCountryCode());
    }

}

Cependant, si vous ne pouvez pas effectuer de recherches IP vers géo sur votre serveur, mais que vous souhaitez toujours effectuer des recherches prise de décision sur appareil pour getOffers requêtes contenant des audiences basées sur la géographie, cette fonctionnalité est également prise en charge. L’inconvénient de cette approche est qu’elle utilise une recherche IP/géo distante, ce qui ajoute une latence à chaque getOffers appelez . Cette latence doit être inférieure à une valeur distante getOffers , puisqu’il atteint un réseau de diffusion de contenu situé près de votre serveur. Vous ne devez fournir que la variable ipAddress dans le champ Geo dans le Context de votre requête, afin que le SDK récupère la géolocalisation de l’adresse IP de votre utilisateur. Si un autre champ s’ajoute à la variable ipAddress est fourni, la variable Target Le SDK ne récupère pas les métadonnées de géolocalisation pour la résolution.

const CONFIG = {
    client: "acmeclient",
    organizationId: "1234567890@AdobeOrg",
    decisioningMethod: "on-device"
};

const targetClient = TargetClient.create(CONFIG);

targetClient.getOffers({
    request: {
        context: {
            geo: {
                ipAddress: "127.0.0.1"
            }
        },
        execute: {
            pageLoad: {}
        }
    }
})
public class TargetRequestUtils {

    public static Context getContext(HttpServletRequest request) {
        Context context = new Context()
            .geo(new Geo().ipAddress(request.getRemoteAddr()))
            .channel(ChannelType.WEB)
            .timeOffsetInMinutes(330.0)
            .address(getAddress(request));
        return context;
    }

}

Méthode d’affectation

Le tableau suivant indique les méthodes d’attribution prises en charge ou non par prise de décision sur appareil.

Méthode d’affectation Pris en charge
Manuel Oui
Auto affecter à la meilleure expérience Non
Ciblage automatique pour les expériences personnalisées Non

Sur cette page