Explication des paires clé-valeur (KVP) de PubGuru
Publié: 2018-01-17Ce message a été mis à jour pour la dernière fois le 21 mars 2022
Chez MonetizeMore, nous utilisons de nombreuses paires clé-valeur (KVP) pour transmettre les informations de ciblage et de suivi dans la pile d'annonces. Voici ce que signifie chaque KVP :
- m2_bidder : code de l'enchérisseur pour le gagnant de l'enchère d'en-tête pour cette impression
- m2_pb : valeur de l'enchère la plus élevée du gagnant de l'enchère d'en-tête pour cette impression. PubGuru prend en charge les devises internationales. La devise est donc celle que l'éditeur utilise dans DFP.
- m2_size : taille de la création gagnante pour l'enchère d'en-tête pour cette impression.
- m2_config : représente la version du code HB ainsi que le nom de la config. Cela nous permet de calculer les performances des différentes versions de notre code HB.
- m2_bidder_list : pour un petit pourcentage de pages vues, nous supprimons un enchérisseur de l'enchère. Cela nous permet de voir le lift causé par chaque enchérisseur. Chaque caractère de cette chaîne correspond à un enchérisseur. Nous l'avons utilisé pour trouver des enchérisseurs qui ne faisaient que remplacer d'autres ou qui ralentissaient l'enchère au point de réduire le RPM de la page.
- test1, test10, test50, test90 : périodiquement, les éditeurs souhaitent tester les éléments de campagne éligibles sur certaines pages vues uniquement. Pour chacun d'entre eux, ils ont par défaut une valeur de "0". Sur 1% des pages vues, test1 = 1. Sur 10% des pages vues, test10 = 1. Sur 50% des pages vues, test50 = 1. Et sur 90% des pages vues, test90 = 1.
- m2_traffic : bien que nous exécutions par défaut les enchères d'en-tête sur 100 % des pages vues, nous pouvons désactiver les enchères d'en-tête sur un pourcentage de pages vues. Ce KVP vous indique si HB a été activé pour cette impression et pour quel pourcentage de pages vues il a été activé. Ainsi, par exemple, "hbon-50" signifie que 50 % des pages vues pour ce segment avaient HB activé, et pour cette impression particulière, HB était activé.
- m2_overbid : par défaut, nous configurons les éléments de campagne HB avec un plafond d'enchère de 20 USD ou l'équivalent en devise étrangère pour les éditeurs utilisant d'autres devises dans leur compte DFP. Toute enchère supérieure à ce plafond est arrondie au plafond inférieur. En effet, DFP a à la fois une limite d'éléments de campagne à vie et une limite d'éléments de campagne actifs. La création irresponsable d'éléments de campagne peut détruire complètement un compte DFP, et comme les comptes DFP sont liés aux comptes AdX et Adsense, cela détruit toute la chaîne de comptes Google d'un éditeur. C'est incontestablement mauvais. Pourtant, certains éditeurs ont des audiences pour lesquelles il peut être avantageux d'augmenter le plafond de l'enchère au-delà de 20 $. Puisqu'il n'y a pas de plafond KVP à vie, nous utilisons m2_overbid pour suivre les enchères qui dépassent le plafond d'enchère et qui sont arrondies à l'inférieur. Les éditeurs qui voient des enchères non négligeables au-dessus de leur plafond verront leur plafond augmenté.
- m2_timeout : il s'agit d'un combo KVP utilisé pour suivre l'heure de l'enchère. Le KVP prend le format suivant : t#e#, ou parfois t#e#x#. Le nombre qui suit le t est le délai d'attente de base défini pour l'enchère. Le nombre qui suit le e est le temps écoulé réel pour l'enchère. Parfois, cela est plus court que le délai d'expiration (toutes les enchères ont été renvoyées plus tôt et DFP était prêt à déclencher des impressions). Parfois, cela est plus long que le délai d'expiration (généralement lorsque DFP n'est pas prêt).
- m2_auction_extension : ce combo KVP est utilisé pour suivre les paramètres testés pour l'extension de l'enchère. Avec l'extension d'enchère, nous vérifions la densité et la distribution de l'enchère de l'éditeur pour cette page vue, et nous prolongeons éventuellement l'enchère si cela est susceptible d'être rentable.
- pageview : il est mis à 1 pour chaque nouvelle page vue. Pour calculer le nombre de pages vues dans lesquelles notre technologie s'est réellement exécutée, additionnez le nombre total d'impressions remplies et non remplies pageview=1. Cela peut être différent de Google Analytics car GA n'est généralement pas bloqué par les publicités alors que DFP est bloqué par les publicités. Ignorez le chiffre d'affaires.
- session : ceci est similaire au KVP pageview sauf qu'il suit les sessions à la place. Pour calculer le nombre de sessions au cours desquelles notre technologie a réellement fonctionné, additionnez le nombre total d'impressions remplies et non remplies où session=1. Encore une fois, cela peut différer de GA en raison d'adblock.
- request_uri : certains éditeurs souhaitent suivre les revenus par article. La méthode la plus simple pour les éditeurs est l'attribution des revenus request_uri. C'est tout après le nom de domaine. Il est important de noter cependant que les KVP ont une limite de 40 caractères, de sorte que les éditeurs avec de longues URL peuvent voir leurs valeurs request_uri tronquées.
- session_depth : représente le nombre de pages vues dans la session de l'utilisateur. Certains éditeurs souhaitent uniquement activer certains partenaires de demande dans les pages vues ultérieurement au cours de la session.
- a9 : PubGuru prend en charge le chargement latéral de la technologie d'enchères d'en-tête d'Amazon A9. A9 n'est pas géré dans notre wrapper, mais nous synchronisons les deux délais d'attente entre HB et A9 afin qu'aucun des deux ne puisse mettre fin à l'enchère plus tôt. Dans ce KVP, nous suivons l'état de A9 au moment où l'impression se déclenche.
- google : Google, en tant que société de publicité, exige que le contenu de l'éditeur soit sans danger pour la marque et généralement adapté aux familles. Afin de répondre à cela, nous avons un système d'avertissement qui recherche et identifie les contenus controversés. L'éditeur peut ensuite définir google=0, google=no ou google=off afin de désactiver tous les éléments de campagne Google pour cette impression.
- wrapper : généralement utilisé lorsqu'un éditeur a mis en place un test 50/50 entre PubGuru et un autre wrapper. Tant que cela est défini sur 50 %, on peut simplement comparer le revenu total entre les deux segments wrapper pour voir lequel a le RPM de page le plus élevé.
KVP d'attribution des revenus
PubGuru Header Bidding prend également en charge l'attribution des bénéfices. Cela se fait via des UTM, et chaque UTM a un KVP correspondant : utm_source , utm_campaign , utm_content , utm_term , utm_medium . Étant donné que DFP ne prend pas en charge les rapports sur plusieurs KVP, nous prenons également en charge les KVP combinés :
- utm_source_campaign : source et campagne séparées par deux-points
- utm_scm : source, campagne et support, séparés par des deux-points
KVP tiers
Certains de nos partenaires publicitaires ajoutent également des KVP dans la pile publicitaire. Ceux-ci inclus:
- amznbid : le hachage de l'enchère pour Amazon A9.
- oxb, ox160x600 , ox300x250 , ox300x600 , ox320x50 , ox728x90 , et similaires : certaines implémentations du soumissionnaire d'OpenX ont utilisé ces KVP.