Partager via


Demande de notification - FAQ

Centre de données

Parfois, la demande de notification provient d’un autre centre de données que la demande d’enchère d’origine. Pourquoi cela se produit-il ?

Ce comportement est normal. La raison pour laquelle cela se produit est que la charge des impressions est équilibrée dans un centre de données particulier en fonction de l’emplacement de l’utilisateur. Certaines zones géographiques ont une double couverture avec nos centres de données. Selon le type d’appel aux enchères ou d’annonces publicitaires par lequel l’impression se produit, l’avis est en fait un processus distinct qui est déconnecté de la vente aux enchères elle-même. Cela se produit dans les situations où l’utilisateur est invité à recevoir une URL « d’acceptation » spéciale qui indique à son navigateur de récupérer le contenu publicitaire de nous séparément de l’appel publicitaire avec initié l’impression. Cette URL d’acceptation finale peut potentiellement être acheminée vers un autre centre de données que l’impression d’origine, ce qui entraîne le comportement que vous voyez et décrivez.

Alertes manquantes

Je vois des créations livrées avec des macros remplies, mais je n’ai pas reçu de demande de notification « gagnée » correspondante. Qu’est-ce qui pourrait être à l’origine de cela ?

Il existe plusieurs raisons pour lesquelles une demande de notification ne serait pas envoyée ou remise. En interne, nous conservons une métrique pour les alertes « ayant échoué », c’est-à-dire celles qui n’ont pas pu être envoyées en raison de problèmes de bande passante. Dans ce cas, vous rencontrerez probablement également une limitation ou un abandon lors de la demande d’offre. Dans ce cas, vous devriez voir un certain nombre de demandes de notification qui contiennent le message d’erreur « Demande limitée ou abandonnée ». Une autre cause potentielle de la non-remise des demandes de notification « gagnées » est que l’avis est remis une fois que nous avons reçu une sorte de confirmation que l’impression a été réellement gagnée. Pour les impressions où Xandr est le décideur final, nous envoyons l’avis à la fin de l’enchère une fois que nous avons déterminé le gagnant. Pour les enchères où Xandr n’est pas le décideur final (par exemple, les impressions côté serveur de partenaires d’approvisionnement comme Google Ad Manager, Rubicon, Pubmatic et AdMeld), nous envoyons la notification d’une impression « gagnée » lorsque la partie décisionnaire nous a informé que nous avons gagné. Dans certains cas, la réception du rappel peut prendre beaucoup de temps (nous l’appelons « accepter le rappel d’offre »). Lorsque le rappel d’acceptation de l’offre est reçu, nous case activée depuis combien de temps il a été depuis la vente aux enchères. Pour plusieurs raisons (décrites ci-dessous), si le temps écoulé est supérieur à 60 secondes, nous considérons que le rappel a expiré. Lorsque nous recevons un rappel expiré, nous ne le traitons pas comme un rappel normal. Plus particulièrement, nous n’enregistrons pas la victoire et nous n’envoyons pas de demande de notification pour cette vente aux enchères. Toutefois, nous fournissons la création de la même façon. Cela signifie que vous pouvez voir une création livrée sans aucune demande de notification correspondante. Les raisons pour lesquelles nous traitons différemment les rappels d’enchères d’acceptation « expiré » sont les suivantes :

  • Il est très courant que les partenaires fournisseurs émettent des rappels Xandr en double d’envoi pour la même impression. Cela entraîne l’envoi de plusieurs notifications en double aux soumissionnaires, ce qui nécessite une déduplication dans le pipeline de données. Plus nous pouvons réduire les doublons, plus la plateforme peut fonctionner efficacement.
  • La définition du seuil de délai d’expiration sur 60 secondes nous permet de réduire la période de recherche en arrière lors de l’agrégation de nos données de journal pour la création de rapports sur les impressions remises. Pour toutes les impressions où Xandr n’est pas le décideur final, nous conservons deux journaux : un pour notre vente aux enchères de l’impression et un pour le rappel d’acceptation de l’offre. Cela nous oblige à joindre ces deux journaux pour déterminer quelles impressions ont été remises. En réduisant la période de recherche en arrière, nous pouvons nous assurer que les rapports horaires présentent des délais minimaux. Le nombre de rappels expirés doit être minimal, de sorte que cela ne contribue pas de manière significative aux différences.
  • Très souvent, un rappel expiré est le résultat d’une connexion Internet très lente entre l’utilisateur et le serveur publicitaire. Si c’est le cas, il y a de fortes chances que l’utilisateur soit en train de naviguer hors de la page et ne voit pas l’annonce.

Erreurs

Les métriques me permettent de voir mon taux d’erreurs, mais je souhaite savoir quels types d’erreurs nous générons. Est-ce possible ?

Si vous obtenez notify_requests, par défaut, vous recevez des erreurs pour les délais d’expiration et les demandes limitées ou abandonnées. Tous les autres types d’erreurs sont inclus dans le "error" champ des notifications de perte. Par conséquent, pour avoir la meilleure compréhension de toutes les erreurs, il est recommandé d’avoir le "notify_lost" champ de votre objet soumissionnaire défini sur true. S’il s’agit d’un élément que vous souhaitez activer, demandez à votre représentant du support technique.