FAQ - Processus d’intégration des partenaires de fourniture

OpenRTB

Il existe des spécifications « 2.4 » et « Mobile 2.2 » mentionnées dans le wiki. Quelle est la différence ? Nous (le fournisseur de services partagés) sommes une entreprise mobile. Quelle version oRTB devons-nous utiliser ?

Xandr prend en charge la spécification OpenRTB 2.4 pour la réception de toutes les impressions de type de média. Pour certaines intégrations mobiles héritées, Xandr est toujours rétrocompatible avec la spécification OpenRTB 2.2. Pour tous les nouveaux types d’intégrations, suivez la spécification OpenRTB 2.4.

Quelle est la version la plus récente de VPAID et MRAID que vous prenez en charge ?

La vidéo Xandr prend actuellement en charge les versions VPAID 1 et 2 et VAST 1, 2 et 3. Nous prenons actuellement en charge MRAID version 2.0. pour mobile. Nous sommes rétrocompatibles avec OpenRTB versions 2.2 et 2.3.

Datacenters

Où se trouvent vos centres de données ?

Xandr gère actuellement cinq centres de données : LAX1 à Los Angeles, NYM2 à North Bergen, NJ, AMS3 à Amsterdam aux Pays-Bas, FRA1 à Francfort en Allemagne et SIN3 à Singapour.

Comment puis-je tester la latence dans les différents centres de données ?

Pour tester la latence dans le centre de données de la côte Est (métro de New York), vous pouvez effectuer un test ping jump.nym1.adnxs.net. Le centre de données de la côte Ouest peut faire l’objet d’un test ping avec jump.lax1.adnxs.net et le centre de données européen est disponible sur jump.ams1.adnxs.net.

Votre liste de vérification des prérequis mentionne les limites de délai d’expiration des enchères mondiales et la mesure de la latence à nos adresses IP (les fournisseurs de services de sécurité). Pouvez-vous spécifier quel type de test sera effectué pour cette activité ?

Xandr a la possibilité de définir une durée d’enchère maximale variable pour chaque fournisseur de services partagés. À cet effet, nous mesurons la latence la plus élevée entre les contrôleurs de domaine SSP et les contrôleurs de domaine Xandr dans toutes les régions. Le résultat est utilisé pour définir la durée maximale des enchères sur Xandr avant qu’une réponse d’offre soit considérée comme expirée pour le SSP. Supposons que la durée maximale des enchères sur votre plateforme est de 100 ms. Nous calculons 100 ms (latence maximale entre les contrôleurs de domaine, par exemple 18 ms) - mémoire tampon de 10 ms = 72 ms. Le résultat est la durée maximale définie sur Xandr pour votre SSP et les réponses d’enchères plus lentes sont supprimées avant d’atteindre votre plateforme.

Nous (le fournisseur de services partagés) avons remarqué que la latence est très élevée et il semble que le paramètre tmax n’est pas respecté du tout. Vous utilisez tmax ? Si c’est le cas, doit-il être activé ou quelque chose du genre de votre côté ?

La tmax valeur ne peut pas être définie dynamiquement sur la demande d’offre sur la plateforme Xandr. Il doit être défini par le support de Xandr pour votre siège de membre et pour chacun de vos centres de données individuellement. Le tmax champ est également mis en évidence dans les spécifications OpenRTB comme étant géré différemment sur la plateforme Xandr ici.

ID de membre

Est-il possible d’avoir notre MEMBER_ALIAS et MEMBER_ID?

Oui. Comme il s’agit d’un prérequis pour notre processus standard, demandez votre MEMBER_ALIAS et MEMBER_ID à votre contact Xandr.

Où pouvons-nous (le fournisseur de services partagés) trouver notre ID de siège à fournir aux clients qui souhaitent enchérir sur notre plateforme ? Est-ce quelque chose qui est accessible à tout le monde ou est-ce quelque chose que nous pouvons fournir au cas par cas à nos annonceurs ?

L’ID de siège est également appelé ID de membre et est attribué à chaque partenaire sur la plateforme de Xandr une fois le contrat commercial finalisé. L’ID de siège/membre reste le même tout au long de la durée de vie de l’objet partenaire et peut être référencé par d’autres partenaires pour ajuster, par exemple, leurs paramètres de qualité des annonces, pour cibler leurs campagnes spécifiquement sur l’ID de membre, ou pour autoriser/bloquer certains membres vendeurs/acheteurs.

wseat est pris en charge, mais comment puis-je l’utiliser ? Quelles sont les valeurs possibles et où trouver le mappage ?

wseat Le champ de la demande d’offre OpenRTB contient un tableau d’ID de siège d’acheteur placés dans les listes d’autorisation (par exemple, les annonceurs, les agences) qui sont autorisés à soumissionner sur cette impression. Dans la convention de nommage Xandr, les ID de siège et les ID de membre sont identiques. Par conséquent, le wseat tableau doit être rempli avec des ID de membre valides qui peuvent être récupérés via le service membre de la plateforme.

"wseat": [
    "958",
    "1417"
]

ID d’éditeur

Comment (le fournisseur de services partagés) devons-nous définir les relations d’inventaire pour les objets publisher ?

Pour créer des objets d’éditeur sous le siège de membre du fournisseur de services partagés ou modifier la configuration existante de l’éditeur, l’API ou l’interface utilisateur vous oblige à envoyer des informations de relation d’inventaire . Dans de nombreux cas, la relation est « Éditeur unique provenant directement de l’éditeur ». Dans ce cas, pour instance, les champs obligatoires à remplir via le service serveur de publication sont les suivants :

{
    "publisher": {
        "name": "Standard Publisher",
        "state": "active",
        "code": "4321",
        "reselling_exposure": "public",
        "expose_domains": true,
        "final_auction_type": "First Price",
        "inventory_relationship": "indirect_single_publisher",
        "inventory_source": "other",
        "inventory_source_name": "Publisher name for indirect_single_publisher",
        "contact": {
            "name": "The name of the point of contact for this publisher.",
            "phone": "contact phone number",
            "email": "CSPFeedback@appnexus.com"
        },
        "billing_dba": "Publisher name as in inventory_source_name",
        "billing_address1": "The street information of the billing address.",
        "billing_address2": "The street information of the billing address cont.",
        "billing_city": "The city of the billing address.",
        "billing_state": "The state of the billing address.",
        "billing_zip": "10010",
        "billing_country": "The country of the billing address."
    }
}

Donc, si nous (le fournisseur de services partagés) définissons l’exposition de revente à des privés, nous ne permettrons pas à d’autres membres de revendre notre approvisionnement, n’est-ce pas ? Cependant, nous serons toujours en mesure de participer à des enchères ouvertes et de vendre notre inventaire via des ID de transaction ?

Non. L’inventaire peut être ciblé au niveau du réseau et de l’éditeur. Il ne peut être acheté qu’au niveau du groupe de placement. Par conséquent, pour permettre aux acheteurs de cibler et d’acheter votre inventaire, vous devez effectuer les actions suivantes :

• Exposer l’inventaire pour le ciblage par les acheteurs : cette opération est également appelée « exposition de revente » et peut être effectuée pour l’ensemble du réseau ou par éditeur. Cela le rend ciblable. Pour obtenir des instructions sur la façon de désactiver ce paramètre, consultez Service Publisher.

• Activer les groupes de placement (et tous leurs placements) pour la revente : pour pouvoir être revendus à d’autres membres, un groupe de placement doit être activé pour la revente en le configurant pour participer à la Place de marché RTB. Cela le rend achetable. Pour obtenir des instructions sur la façon de désactiver ce paramètre, consultez Service de site.

Pouvez-vous nous conseiller (le fournisseur de services partagés) sur le nom de l’éditeur ? Recommandez-vous d’utiliser le nom ou un ID qui représente l’éditeur dans notre système interne ?

Xandr suggère fortement d’utiliser les noms de serveur de publication qui sont clairement identifiables avec le serveur de publication (name champ décrit dans Utiliser l’API pour synchroniser votre structure d’inventaire. N’utilisez pas vos ID internes (du fournisseur de services partagés) qui sont uniquement connus de votre plateforme interne pour le nommage du serveur de publication. Consultez un exemple de structure de mappage d’inventaire ci-dessous :

L’API est-elle publisher.is_oo importante ?

Comme décrit dans la documentation du service serveur de publication, si ce paramètre est défini sur true, le serveur de publication est détenu et géré par le réseau. Cela signifie que le réseau obtient 100 % du chiffre d’affaires. Toutefois, si et is_ooinventory_relationship sont spécifiés, inventory_relationship remplace is_oo par la valeur appropriée en fonction de la relation.

Comment devons-nous implémenter Ads.txt / App-Ads.txt dans le cadre de notre intégration SSP ?

Consultez la documentation sur la prise en charge des Ads.txt et App-Ads.txt et contactez vos éditeurs avec les instructions de la section « Éditeurs » (ou simplement les diriger vers cette page) avec votre ID de membre afin qu’ils puissent vous ajouter à leur ads.txt/app-ads.txt fichier.

ID de transaction

Devons-nous (le fournisseur de services partagés) préinscrire les ID de transaction (PMP) sur la plateforme Xandr avant de les envoyer dans le protocole OpenRTB ?

Pour pouvoir vendre des ID de transaction sur la plateforme Xandr, vous devez les préinscrire à l’aide du service Deal.

{
    "deal": {
        "active": true,
        "code": "5612",
        "name": "Standard Deal",
        "start_date": "2017-04-10 00:00:00",
        "type": {
            "id": 1
        },
        "buyer": {
            "id": 882
        }
    }
}

Notre (le fournisseur de services partagés) deal.id sera deal.code dans le système Xandr. Pouvez-vous préciser comment les SSP deal.id seront référencés dans la demande d’offre ? Ou contient-il uniquement l’ID de transaction Xandr ?

Les ID de transaction sont référencés selon deal.code la façon dont les objets d’inventaire sont mappés sur Xandr. Le fournisseur de deal.id services partagés est défini deal code sur sur la plateforme de Xandr via le service deal lors de la création de la transaction. Le pmp.deals tableau sur la demande d’enchère OpenRTB doit inclure le SSP deal.idexterne . Xandr lit l’externe deal.id à partir de la demande d’offre et le mappe à l’objet ID de transaction interne via le mappage fourni dans le deal.code champ. Consultez l’exemple de demande d’offre OpenRTB ci-dessous (faisant référence à l’objet deal dans la question précédente) :

[...] "pmp":{"deals":[{"id":"5612" [...]

Est-il vrai que nous serons obligés de transmettre l’ID de membre acheteur pour chaque transaction créée entre nous (le fournisseur de services partagés) et Xandr ? Quel est le processus ici ? Chaque agence qui souhaite acheter l’inventaire de l’éditeur via l’ID de transaction doit fournir un ID de siège de membre unique ?

Les transactions sont créées sur la base d’une relation de 1 à 1 entre le vendeur et l’acheteur. Le membre vendeur de transactions doit connaître l’ID de membre acheteur pour pouvoir créer une transaction dans la plateforme de Xandr.

Points de terminaison

Dois-je (le fournisseur de services partagés) continuer à utiliser dans &test=1 le point de terminaison pour les demandes d’enchères OpenRTB de production ?

Non. N’utilisez pas pour les &test=1 demandes d’enchère OpenRTB de production, les &test=1 données de création de rapports ne seront PAS générées.

Xandr fournit-il des points de terminaison de test pour tester la fonctionnalité OpenRTB avant que nous (le fournisseur de services partagés) n’ayons potentiellement signé le contrat ?

Non. Xandr ne fournit pas d’environnements de test ou de bac à sable distincts pour les intégrations OpenRTB standard. Utilisez sur le point de terminaison de production pour indiquer le test=1 trafic de test.

Mon domaine de point de terminaison Xandr change-t-il lors de la mise à niveau vers OpenRTB ?

Non. La seule partie qui change est le point de terminaison réel de /CUSTOM_ENDPOINT à /openrtb2. Les nouveaux points de terminaison corrects pour le protocole OpenRTB2 sont donc les suivants :

https://MEMBER_ALIAS-useast.adnxs.com/openrtb2?member_id=MEMBER_ID
https://MEMBER_ALIAS-uswest.adnxs.com/openrtb2?member_id=MEMBER_ID
https://MEMBER_ALIAS-emea.adnxs.com/openrtb2?member_id=MEMBER_ID
https://MEMBER_ALIAS-apac.adnxs.com/openrtb2?member_id=MEMBER_ID

Est-il possible d’appeler l’URL de l’avis de victoire à partir du balisage publicitaire à des fins de test ou d’audit sans déclencher d’indicateurs de qualité d’inventaire et de marquer l’impression comme une impression de test ?

Absolument. Utilisez les informations suivantes dans l’en-tête de l’appel pour indiquer que l’appel /ab ou /openrtb_win est à des fins de test uniquement :

curl -v --header 'X-is-test: 1' --header 'Host: ib.adnxs.com' 'https://nym1-ib.adnxs.com/ab?e=wqT_3QKoCfA8qAQAAAMA1gAFAQjQis3HBRCUvPSr_...&referrer=appnexus.com&pp=1'

ID d’utilisateur

La demande d’enchère contient des données non valides "buyeruid". Devons-nous résoudre ce problème ? Si c’est le cas, pouvez-vous fournir de la documentation ?

Oui. Le buyeruid champ contient l’ID utilisateur Xandr que vous nous envoyez pour indiquer l’utilisateur que vous avez précédemment mis en correspondance via le pixel usersync. L’objet de demande d’enchère doit contenir un ID utilisateur valide dans le buyeruid champ, afin d’être considéré comme une demande d’enchère avec des données utilisateur correspondantes. Pour plus d’informations sur l’objet utilisateur de la demande d’enchère , consultez Demande d’enchère entrante provenant de fournisseurs de services de sécurité.

La synchronisation de l’utilisateur standard avec Xandr nécessite l’hébergement de la table de correspondance utilisateur, n’est-ce pas ? Xandr lancerait-il la synchronisation utilisateur ? Si c’est le cas, quel volume pourrions-nous prévoir ici ?

Les intégrations SSP OpenRTB standard Xandr nécessitent que le fournisseur de services partagés stocke le mappage utilisateur dans son propre système. En règle générale, un pixel image 1x1 sur les pages SSP appelle le service Xandr getUID et retourne des UUID Xandr pour le stockage. Le format du pixel est disponible dans Mappage des ID utilisateur. Le serveur qui reçoit des appels usersync de Xandr doit être en mesure de gérer 1K-3K QPS.

Nous (le fournisseur de services partagés) nous demandons si Xandr prend en charge la synchronisation bidirectionnelle des utilisateurs ?

Xandr ne prend pas en charge usersync bidirectionnel qui implique le stockage des tables de mappage usersync SSP côté Xandr. Toutefois, la synchronisation utilisateur lancée par Xandr est entièrement prise en charge. Il permet à Xandr de supprimer le pixel usersync des SSP sur l’ensemble de l’univers des ID utilisateur Xandr. La configuration du pixel usersync initié par Xandr fait partie du processus d’intégration.

Quelle est la meilleure façon de tester et de confirmer que la synchronisation utilisateur fonctionne comme prévu ?

Le moyen le plus simple de vérifier si le buyeruid (ID utilisateur Xandr) est correctement mappé consiste à utiliser l’enchère de débogage. En ajoutant &debug=1 à l’appel de demande d’offre, vous devez recevoir status: success la sortie comme ci-dessous :

[COOKIESHEET] cookie source: provided uid
[COOKIESHEET]   mobile optout action: none
[COOKIESHEET]   get request:
[COOKIESHEET]       uid source: provided uid
[COOKIESHEET]       uid: 5160786676315026726
[COOKIESHEET]       status: success
[COOKIESHEET]   map request: none
[COOKIESHEET]   mobile request: none

Xandr nécessite-t-il que buyeruid le champ soit rempli avec les ID d’utilisateur Xandr pour In-App inventaire mobile ?

Le buyeruid n’est pas obligatoire pour In-App demandes d’enchères OpenRTB. Toutefois, il est recommandé de toujours fournir le buyeruid afin de garantir des taux de correspondance utilisateur les plus élevés. Xandr tente d’abord de faire correspondre les ID mobiles et, en cas d’absence de correspondance, tente de faire correspondre le buyeruid. Si les deux valeurs sont fournies, les ID mobiles correctement mis en correspondance sont prioritaires sur buyeruid.

Quels sont les paramètres d’intervalle pour les déclenchements de pixels usersync ?

Par défaut, Xandr définit pour le pixel usersync SSP déclenche les paramètres max_interval=432000 internes (5 jours) et min_interval=43200 (12 heures). Intervalle maximal : nombre maximal de secondes que nous allons attendre entre les synchronisations pour ce pixel. Par exemple, si nous n’avons pas déclenché de pixel depuis 5 jours, incluez-le dans l’algorithme pour sélectionner les pixels usersync à déclencher. Intervalle minimal : nombre de secondes que nous attendrons entre les nouvelles tentatives d’un pixel de synchronisation si nous ne sommes pas en mesure de confirmer que la synchronisation s’est correctement produite (nous avons peut-être supprimé le pixel, mais il n’a pas été déclenché correctement ou l’utilisateur s’est éloigné rapidement). Par exemple, si nous venons de déclencher le pixel, n’essayez pas de le synchroniser à nouveau pendant au moins 12 heures.

Combien de temps Xandr stocke-t-il les données utilisateur ?

Actuellement, la durée de vie (TTL) approximative des données utilisateur (ID utilisateur Xandr) est de 60 jours.

Quelle est la différence entre le /getuid service et ?/getuidnb

Si l’utilisateur n’a PAS l’ID Xandr stocké dans l’espace de cookie Xandr et n’a PAS de cookies collants :

• /getuid forwards avec UID=0

• /getuidnb ne transfère PAS avec UID=0 (le fournisseur de services partagés ne reçoit 0 pas de valeurs provenant d’environnements de cookies non collants)

Demandes d’enchères

Les demandes d’enchères OpenRTB ont le imp.tagid champ . Xandr s’attend-il à ce que ce champ contienne le correspondant placement.id accessible à partir du service de placement ? Ou est-ce qu’il s’agit de la placement.codvaleur e (également gérée par le biais du service de placement d’API) ?

imp.tagid serait la placement.code valeur dans le service de placement. Il doit s’agir de la même valeur que celle que vous transmettez ou site.idapp.id sur la demande d’enchère.

Quelle est la séquence de recherche d’inventaire pour les ID d’objet de demande d’enchère OpenRTB ?

Xandr correspond aux ID fournis dans les demandes d’enchères OpenRTB à l’aide de la séquence de recherche suivante :

1. imp.tagid - used to lookup by placement code
2. bidrequest.app.id - used to lookup by placement code
3. bidrequest.site.id - used to lookup by placement code
4. use bidrequest.site.publisher.id or bidrequest.app.publisher.id to lookup publisher by code and try to get default publisher placement

La demande d’enchère comprend plusieurs objets mediatype. Lesquelles, si ce n’est pas toutes, seront envoyées à l’achat et finalement traitées ?

OpenRTB prend en charge les requêtes multiformat. Toutefois, les réponses aux enchères ne sont pas clairement définies pour plusieurs types de supports. Par conséquent, nous prenons en charge les demandes d’enchères multiformat avec une hiérarchisation codée en dur entre les types de médias. Ainsi, par exemple, si une demande arrive en tant que native et vidéo, elle est transformée en simple demande vidéo lorsqu’elle est envoyée au côté achat. L’ordre est le suivant :

1. video
2. audio
3. banner
4. native

Qu’advient-il de l’impression de demande d’offre si un éditeur n’est pas mappé dans la hiérarchie d’inventaire du siège de membre ?

Dans ce cas, la source d’impression de l’éditeur semble incorrecte et peut entraîner un filtrage. Xandr ne modifie en aucune façon les propriétés de l’impression. Toutefois, l’offre vendue dans l’échange ouvert Xandr est analysée et vérifiée pour s’assurer que l’inventaire représente le chemin d’achat le plus direct, transparent et efficace pour nos acheteurs. Les impressions qui ne répondent pas à ces exigences peuvent être inéligibles pour la vente RTB. Ces impressions peuvent toujours être vendues via des offres. Si vous rencontrez des problèmes de livraison sur la place de marché ouverte, vous pouvez envisager de configurer une transaction avec un acheteur spécifique pour monétiser votre inventaire.

Xandr répond-il à plusieurs impressions dans les demandes d’enchères ? Ou répondez-vous à un seul objet d’impression par demande d’offre ?

Nous prenons en charge plusieurs objets d’impression dans une demande d’enchère conformément aux spécifications OpenRTB. Chaque objet d’impression exécute sa propre vente aux enchères et obtient des enchères individuelles des acheteurs.

Quelles sont les recommandations de Xandr pour les définitions de ressources natives classiques sur la demande d’enchère native ?

Afin de faciliter l’adoption et de maximiser la portée de votre vendeur parmi les acheteurs natifs, des recommandations sont faites pour les tailles minimales et les proportions ci-dessous :

La ressource d’image dans la demande d’enchère native utilise le type 1 pour l’icône d’application, le logo de marque ou similaire. Xandr prend-il en charge des tailles d’icône spécifiques, par exemple 50 x 50 ?

Non. Actuellement, les ID de création Xandr ne contiennent pas d’informations sur la taille de l’icône/logo du créateur natif soumis par l’acheteur. Toutes les demandes d’enchère natives, y compris le type img 1, doivent être déclarées comme taille 0x0.

Dans la partie native de la requête ("native-request-native" champ) - Je vois que vous attendez une chaîne encodée au format JSON. Pouvez-vous également accepter un objet normal ?

Le champ natif dans le nœud native.request doit être une chaîne. Étant donné que la spécification Native 1.0 est techniquement une spécification à elle seule et peut être théoriquement utilisée en dehors de la spécification OpenRTB2.3, le contenu du champ natif ne peut pas faire partie de la structure JSON et doit donc être « échappé » pour apparaître sous forme de chaîne.

En ce qui concerne l’impression tagid interne de la demande, devons-nous (le fournisseur de services partagés) mapper tous nos placements sur Xandr ? Ou pourrions-nous simplement laisser ce champ rester vide, ou remplacer la valeur par la site.idvaleur ?

Oui, non et non ! Vous devez mapper tout votre inventaire aux placements Xandr. Ne laissez pas le tagid champ sur la demande d’offre vide, les deux champs, tagid et site.id mappez au même placement.code champ sur l’objet de placement Xandr.

La méthode de remise de balisage par défaut sur Xandr est l’attribut bid.adm de la réponse d’enchère, que nous (le fournisseur de services partagés) ne prenons actuellement pas en charge. Prenez-vous en charge l’autre remise de balisage publicitaire via l’attribut bid.nurl ?

Oui, nous prenons en charge le balisage publicitaire servi sur l’avis de victoire. Selon la spécification OpenRTB, il existe plusieurs méthodes standard pour transférer le balisage du soumissionnaire (Xandr) vers l’échange (le SSP). La méthode de remise de balisage publicitaire par défaut sur Xandr est via l’attribut bid.adm . L’autre méthode de remise de balisage via l’attribut win notice bid.nurl sera choisie si le fournisseur de services partagés fournit l’attribut BidRequestExtension sur la demande d’enchère entrante.

"ext": { "appnexus": { "markup_delivery": 1 } }

Lorsque Xandr lit les domaines ou URL de référent à partir des demandes d’enchère OpenRTB, Xandr examine-t-il le domain champ ou le page champ ?

Nous examinons les deux champs pour déterminer l’URL ou le domaine du référent. Le page champ est préféré à la demande d’offredomain entrante de champ des fournisseurs de services de sécurité.

Comment la réponse Xandr respecte-t-elle notre liste de blocages d’éditeurs, telles que les domaines, les catégories ou les attributs bloqués ? En d’autres termes, comment nous assurer que les créatifs qui servent via l’intégration OpenRTB n’enfreignent pas nos listes de blocs d’éditeur ?

À cet effet, IAB a introduit les champs wseatde demande d’enchère , bcatbadv et bapp dans le protocole OpenRTB. En outre, la plateforme de Xandr permet une forme moins dynamique de paramètres de blocage du serveur de publication via le service de profil publicitaire.

La prise en charge de plusieurs objets imp sur la demande d’enchère nécessite-t-elle une configuration de votre côté ?

Xandr prend en charge par défaut plusieurs imp objets sur les demandes d’enchères. Chaque imp objet est traité comme une impression distincte sur la plateforme Xandr. Le fait que plusieurs impressions soient envoyées à Xandr inclus dans la même demande d’offre n’a pas d’autres conséquences que l’économie des ressources réseau et la surcharge de connexion.

Xandr

Comment Xandr gère-t-il 0 les cas de périmètre null lorsqu’il s’agit de valeurs de ressources natives, par exemple wmin/hmin?

Par exemple : si les champs wmin/hmin de ressource img natifs sont définis sur 0 ou null dans la demande d’enchère, Xandr les traite logiquement comme si ces champs avaient été omis dans la demande d’enchère. Cela signifie que les soumissionnaires externes verront la même demande de soumission qui leur sera envoyée sans ces champs, c’est-à-dire que ces champs seront supprimés pour des raisons d’efficacité.

Que signifie réellement le private_auction dans le pmp des demandes d’offre et quelles sont les implications de sa définition sur , c’est-à-dire 1que seules les offres pour des transactions spécifiées sont acceptées ?

Si nous recevons une impression d’enchère privée d’un vendeur OpenRTB, nous soumettons uniquement les offres qui seront acceptées dans la vente aux enchères tierce. L’implication du pmp.private_auction=1 est que Xandr n’enverra PAS la demande d’offre à d’autres soumissionnaires acheteurs potentiels qui ne sont pas spécifiés par les transactions sur cette impression.

Xandr envoie-t-il le imp.bidfloor champ de la demande de soumission OpenRTB SSP aux soumissionnaires externes ?

Oui. Xandr reçoit et évalue le prix plancher au niveau de l’impression et transmet le imp.bidfloor aux acheteurs soumissionnaires externes.

Nous (le fournisseur de services partagés) voyons une partie de nos demandes d’enchères renvoyer une réponse HTTP 400 incorrecte. Pourquoi ?

Il s’agit du comportement actuel pour le placement inactif, le groupe de placement ou le serveur de publication et les tailles de bannière non valides. HTTP 400 est retourné si aucune impression valide n’est trouvée dans la requête.

Réponses aux enchères

Quelles sont les réponses HTTP attendues aux demandes d’enchères ?

Les réponses HTTP attendues aux demandes d’enchères sont répertoriées ci-dessous :

• 200 OK : une réponse d’offre valide a été retournée.
• 204 AUCUN CONTENU : aucune enchère n’a été retournée.
• 400 MALFORMED : la demande d’enchère entrante contient un site.id, app.id, app.publisher.idou site.publisher.id qui est mappé à un objet de publication ou de placement inactif dans le système Xandr. Pour plus d’informations, consultez Résolution des problèmes de remise générale Étape 2 .

Nous (le fournisseur de services partagés) avons besoin d’un bid.adomain paramètre dans toutes les réponses d’enchères. Toutes les réponses d’enchère de Xandr contiennent-elles un bid.adomain champ rempli ? Est-il possible d’obtenir le domaine de l’annonceur, même s’il n’est pas dans le champ openrtb bid.adomain - mais dans un autre domaine ?

Xandr suit de très près la spécification OpenRTB et ne définit pas le champ de domaine comme requis. Toutefois, toutes les créations ont une marque associée, y compris la marque inconnue (ID 1), qui est automatiquement attribuée aux nouveaux créatifs non audités. La marque inconnue est liée à l’appnexus.com de domaine. Par conséquent, nous nous attendons à ce que toutes les réponses d’enchères incluent le domaine, à l’exception de celles qui contiennent des éléments créatifs associés à des marques qui n’ont pas de domaine associé à eux (<0,08 % de tous les créatifs) en raison de stratégies internes ou d’autres raisons.

Que sont les catégories NEX10-101 sur la réponse d’enchère OpenRTB ?

Ignorez ces catégories. Ils sont redondants avec nos catégories IAB et seront dépréciés dans les prochains mois !

adm Le champ de la réponse d’enchère peut-il être un objet normal ?

Non. adm contient le balisage publicitaire qui sera servi à la page ou à l’application. Il ne peut pas s’agir d’une structure JSON.

Nous (le fournisseur de services partagés) avons vu que la largeur et la hauteur dans la réponse sont 1x1. Retournez-vous la largeur et la hauteur exactes de la taille de l’annonce vidéo ?

Pour les types de supports autres que les bannières : la largeur et la hauteur de la réponse d’enchère ne représentent pas la taille réelle du contenu créatif (ou le balisage publicitaire) à remettre à la page de l’éditeur. Par exemple : les créations de type multimédia vidéo utilisent plusieurs fichiers multimédias pour la distribution, et une flexibilité similaire est offerte pour les tailles de ressources d’image natives. Pour ces créatifs, la largeur et la hauteur exactes sont transférées à un niveau plus profond de l’objet créatif, qui peut être aperçu à l’aide de la syntaxe suivante :

Video: https://{DATACENTER}-ib.adnxs.com/cr?id={APN_CREATIVE_ID}&format=vast 
Native: https://{DATACENTER}-ib.adnxs.com/cr?id={APN_CREATIVE_ID}&format=json

Voulez-vous que nous (le fournisseur de services partagés) fasse quelque chose avec l’iurl ? Est-il pertinent pour les réponses d’enchère vidéo ? Cette URL a-t-elle une stratégie d’expiration ? J’ai essayé de me connecter à l’un des exemples et il semble que l’URL n’est pas valide ?

L’iurl représente l’aperçu créatif sur notre plateforme et est une URL statique (voir la syntaxe ci-dessus), c’est-à-dire n’expire pas. Vous pouvez l’utiliser à des fins de pré-audit, de mise en cache créative, etc. Le id paramètre représente l’ID créatif Xandr et est unique sur notre plateforme. Pour la préversion de la vidéo créative, attachez le paramètre de format « vaste » à l’iurl pour afficher le xml, par exemple https://fra1-ib.adnxs.com/cr?id=48265354&format=vast

Le prix de la vente aux enchères est-il en dollars américains de majoration publicitaire ? Je suppose que c’est CPM, n’est-ce pas ?

Xandr suit la spécification OpenRTB ici. Le prix utilise la même devise et les mêmes unités que l’offre, dans la plupart des cas USD et CPM.

Comment pouvons-nous (le fournisseur de services partagés) confirmer lors du test si la demande d’offre retourne une offre sans offre ou est syntaxiquement incorrecte ?

N’hésitez pas à utiliser le debug=1 paramètre comme indiqué ci-dessous sur l’appel manuel pour exécuter une enchère de débogage générale.

Conseil : si aucune sortie de débogage n’est retournée, il est très probable que la structure de la demande d’offre ne fonctionne pas correctement ou que le placement ne fonctionne pas.

https://MEMBER_ALIAS-useast.adnxs.com/openrtb2?member_id=MEMBER_ID&debug=1
https://MEMBER_ALIAS-uswest.adnxs.com/openrtb2?member_id=MEMBER_ID&debug=1
https://MEMBER_ALIAS-emea.adnxs.com/openrtb2?member_id=MEMBER_ID&debug=1
https://MEMBER_ALIAS-apac.adnxs.com/openrtb2?member_id=MEMBER_ID&debug=1

Comment devons-nous passer le prix final dans la notification gagnante ? Nous (le fournisseur de services partagés) voyons qu’il existe une macro pp=$(AUCTION_PRICE). Quel encodage/format est nécessaire ?

Si le auction type champ de la demande d’offre est défini comme at=2 (enchère de deuxième prix), la ${AUCTION_PRICE} macro doit être remplie par le SSP pour recevoir le deuxième prix. Le prix de règlement doit utiliser la même devise, les mêmes unités et le même format/encodage que l’offre (généralement usd et CPM).

Remplacement correct des AUCTION_PRICE macros

pp=0.47

Devons-nous (le fournisseur de services partagés) utiliser le chiffrement lorsque nous vous transmettons le prix gagnant ? Pouvez-vous confirmer quels algorithmes de chiffrement sont pris en charge ?

Nous ne prenons pas encore en charge l’encodage de la AUCTION_PRICE macro dans les intégrations standard.

Comment le rendu de l’imptracker Xandr et du clicktracker doivent-ils être implémentés sur la page de l’éditeur ? Pouvons-nous implémenter notre imptracker (SSP) pour déclencher l’événement d’impression win et L’imptracker Xandr sur l’impression est un événement visible ? Cela entraînerait-il des écarts pour les clics ?

Oui, toutes les différences dans l’implémentation de l’imptracker entre votre fournisseur de services partagés et l’événement de déclenchement de Xandr entraînent un comportement discrépante. Les clics seront également impactés, car ils dépendent du minutage de l’imptracker.

Nous (le fournisseur de services partagés) sommes maintenant opérationnels avec OpenRTB natif. Avez-vous une table de correspondance de champs afin que nous puissions communiquer aux acheteurs quels champs OpenRTB correspondent à quels champs créatifs dans Xandr ?

Les acheteurs natifs, les acheteurs de plateforme et les fournisseurs de services de sécurité externes doivent préinscrire les créations natives en fonction du service créatif. (Consultez les exemples pour plus d’informations.)

L’ordre des enchères dans le json de réponse d’offre suit-il un certain modèle, par exemple l’ordre décroissant basé sur le prix de l’offre ?

Non, nous ne garantissons aucun ordre dans la structure du tableau JSON de réponse d’enchère. Nous vous recommandons d’évaluer les enchères et d’appliquer votre logique de sélection d’enchères strictement après avoir analysé la réponse JSON complète.

Quelles sont les limites de délai d’expiration pour les appels d’impression win notify ?

Les limites de délai d’expiration pour les appels win notify varient selon les types de médias. Les délais d’expiration suivants s’appliquent aux /ab, /it appels et /openrtb_win :

• banner: 5 minutes
• native: 60 minutes
• video: 360 minutes

Quelles sont les limites de délai d’expiration pour le suivi des clics ?

Pour l’URL de suivi des clics, la fenêtre de recherche d’agrégation après que l’impression a été traitée sur la plateforme de Xandr est :

• banner: 120 minutes
• native: 120 minutes
• video: 120 minutes

Reporting

Quels sont les rapports et métriques disponibles sur la plateforme de Xandr, et comment pouvons-nous (le fournisseur de services partagés) récupérer ces rapports ?

Le type de rapport le plus courant exécuté par les fournisseurs de services de sécurité est le rapport Analyse réseau. Ce rapport fournit des informations sur ce qui sert généralement, ce qui se porte bien, à la fois du côté de l’achat et de la vente. Tous les rapports sont obtenus via les services d’API de création de rapports. Reportez-vous à la liste complète des types de rapports disponibles.

Voici un exemple de la séquence d’appels d’API nécessaire pour obtenir un rapport Network Analytics pour les 7 derniers jours :

echo "AUTH to AppNexus API: "
curl -bc -cc -X POST -s -d '{"auth":{"username":"YOUR_USERNAME","password":"YOUR_PASSWORD"}}' "https://api.appnexus.com/auth"
{
    "response": {
        "status": "OK"
    }
}
 
echo "POST to report API service: "
curl -bc -cc -X POST -s -d '{ "report": { "report_type":"network_analytics", "columns":[ "hour", "seller_member_name", "buyer_member_name", "publisher_name", "publisher_id", "publisher_code", "imps", "clicks", "total_convs", "revenue", "ctr", "convs_rate" ], "report_interval":"last_7_days", "format":"csv" } }' "https://api.appnexus.com/report?member_id=MEMBER_ID"
{
    "response": {
        "report_id": "287efed55c091dc97e2c839580962cba",
        "status": "OK"
    }
}
 
echo "DOWNLOAD from report-download API service: "
curl -bc -cc -s "https://api.appnexus.com/report-download?id=287efed55c091dc97e2c839580962cba" 
hour,seller_member_name,buyer_member_name,publisher_name,publisher_id,publisher_code,imps,clicks,total_convs,revenue,ctr,convs_rate
2017-06-02 05:00,Member Inc.,Test Buyer,Example Publisher,777999,222333,0,0,0,0.000000,0.000000000000000000,0.000000000000000000
2017-05-31 13:00,Member Inc.,Test Buyer - Netherlands,Publisher Name AG,555777,100200,172,0,0,0.000000,0.000000000000000000,0.000000000000000000