Exigences et recommandations en matière d’enchères

Exigences d’intégration des enchères

Toutes les intégrations internes doivent suivre les critères ci-dessous afin de mettre en œuvre une intégration correcte et optimale.

• Il faut envoyer des demandes pour la totalité des impressions publicitaires gagnantes (par exemple, celles qui ne sont pas vendues directement).
• Il faut envoyer une seule demande pour chaque opportunité d’impression.
• Il ne faut pas associer des demandes d’enchères à des demandes standard (c’est-à-dire des tags) pour la même unité publicitaire.
• Il ne faut pas envoyer de demande pour la même opportunité d’impression sur les cascades et les enchères.
• Il faut envoyer des notifications de gain, de perte et de délai avec les codes de perte appropriés.
• Il faut obtenir le buyeruid du client utilisant le SDK Audience Network. Le buyeruid est le token d’enchérisseur de l’utilisateur·ice généré côté client à l’aide de la méthode getBidderToken du SDK Audience Network.
• Il faut utiliser le SDK Audience Network pour récupérer et rendre des publicités.
• Il faut demander la publicité uniquement si l’offre gagne l’enchère.
• Il faut envoyer des demandes d’enchères à l’aide du token d’authentification (clé secrète et ID de demande).
• Il faut ajouter un en-tête HTTP à chaque demande, appelé x-fb-pool-routing-token, qui contient le token de l’enchérisseur en tant que valeur.
• Il faut établir plusieurs tarifs planchers pour les autres sources de demandes comprises dans une cascade traditionnelle lors de l’association à un système d’enchères. Deux prix planchers sont généralement un bon départ. Cela permet un contrôle plus complet de la manière dont l’enchère entre en concurrence avec la cascade, ce qui augmentera le rendement global.

Recommandations en matière d’enchères

En plus des critères d’intégration optimaux, nous conseillons de suivre ces recommandations.

• Il est recommandé d’établir un délai de demande d’enchère d’au moins une seconde.
• Il est recommandé de récupérer le token de l’enchérisseur sur le serveur pour chaque demande d’enchère.
• Il est recommandé d’envoyer un ID unique pour chaque demande.
• Il est recommandé de lire et d’enregistrer l’en-tête HTTP x-fb-an-errors sur les réponses d’enchères avec un code de statut autre que 200 pour qu’il soit utilisé dans la résolution de problèmes.
• Il est recommandé de lire et d’enregistrer l’en-tête HTTP x-fb-an-request-id sur les réponses d’enchères pour qu’il soit utilisé dans la résolution de problèmes.
• Il est recommandé d’utiliser des ID de placement existants pour les enchères et de ne pas créer de nouveaux placements, sauf lorsque vous réalisez des tests A/B ou vous utilisez une plateforme partenaire nécessitant de nouveaux placements.
• Il est recommandé d’utiliser l’intégration serveur à serveur lorsque cela est possible pour modifier le traitement et l’utilisation du réseau par l’appareil et le réseau de l’utilisateur·ice vers les serveurs et le réseau de l’éditeur, ainsi que pour permettre des modifications des offres et des enchères sans changement de l’application.
• Vous pouvez transmettre un corps de requête compressé avec gzip si vous fournissez un en-tête Content-Encoding:gzip à votre requête.
• Il est recommandé de ne pas utiliser de prix planchers pour les enchères, car celles-ci seraient ignorées.

Voir aussi

• Intégration d’enchères
• Configuration de la plateforme