Product

De nouveaux champs sont désormais disponibles dans les Client Audit Logs !

Nous sommes ravis de  vous annoncer que des champs supplémentaires sont désormais disponibles dans nos Client Audit Logs (CAL).

En septembre dernier, nous avons mis à la disposition de tous nos partenaires les Client Audit Logs (CAL), la solution d’analyse de données au niveau des Logs développée par nos équipes, et qui fournit un reçu pour chaque transaction effectuée sur notre plateforme. Ce lancement a simplifié la récupération des données pour optimiser les partenariats et normaliser les efforts de reporting.

“En ce qui concerne les reportings auxquels nous avons généralement accès sur le marché, nous avons tout vu, de bonnes comme de mauvaises choses. Nous sommes donc ravis lorsqu’un Exchange partenaire publie des rapports plus détaillés et plus transparents auxquels nous pouvons nous fier. Il ne fait aucun doute dans notre esprit que cela mènera à une amélioration des revenus pour les éditeurs. C’est une démarche que chaque Exchange devrait avoir dans ses priorités.”
James Curran Co-Founder, CPO of Staq

Au cours des derniers mois, nous avons recueilli les commentaires de nos partenaires sur la meilleure façon de fournir des informations plus détaillées via les Client Audit Logs. Notre objectif est de fournir à tous les utilisateurs des CAL les données dont ils ont besoin , afin de leur permettre d’optimiser leur décisions d’achat et de vente sur Index Exchange. Ainsi, nous sommes ravis de partager l’ajout des champs suivants:

  • a_domain permet aux éditeurs et aux acheteurs d’identifier le domaine de l’annonceur transmis dans la “bid response”. Le champ indiquera le domaine sur lequel l’internaute atterrira une fois la publicité cliquée sur la page.
  • cookie_match_status contrôle la corrélation entre les “bid responses”, les impressions remportées et les “cookies matches”. Un match est défini lorsqu’Index Exchange a un ID spécifique à l’acheteur à transmettre dans la “bid request”. Les éditeurs peuvent suivre le moment où une impression a été générée, ou lorsqu’une enchère a été placée, avec un “cookie match” du DSP. Les acheteurs peuvent surveiller le statut afin de déterminer le pourcentage d’inventaire avec “cookie match”, et comprendre l’efficacité du match depuis  la “bid response” jusqu’à l’impression servie.
  • bid_stage explique en détail pourquoi un bid n’était pas éligible pour participer à l’enchère d’Index Exchange . Bid_stage permet aux acheteurs de résoudre les problèmes avec plus de granularité et de remporter des enchères qui auraient autrement été bloquées. Par exemple, si une enchère n’est pas éligible en raison d’un blocage défini par l’éditeur, “bid_stage” indiquera “block_by_publisher”. (Ce champ est uniquement disponible dans “Bid Events”).
  • min_bid_to_win indique la valeur qu’un DSP aurait besoin d’avoir pour enchérir sur d’autres offres et sur les étages du vendeur dans l’enchère. Ce champ fournit aux DSP un aperçu très détaillé de la vente aux enchères au niveau des enchères, leur permettant d’optimiser leurs algorithmes d’enchères afin de maximiser le “win rate” au prix le plus efficace. (Ce champ est uniquement disponible dans Bid Events).

Si vous souhaitez en savoir plus sur les Client Audit Logs, vous pouvez consulter notre base de connaissances ou contacter votre chargé de compte Index Exchange.