Spiegazione delle coppie chiave-valore (KVP) di PubGuru

Questo post è stato aggiornato di recente il 21 marzo 2022

In MonetizeMore, utilizziamo numerose coppie chiave-valore (KVP) per trasferire le informazioni per il targeting e il tracciamento nello stack di annunci. Ecco cosa significa ogni KVP:

• m2_bidder : codice dell'offerente per il vincitore dell'asta di offerte su intestazioni per quell'impressione
• m2_pb : valore dell'offerta superiore del vincitore dell'asta di offerta dell'intestazione per quell'impressione. PubGuru supporta la valuta internazionale, quindi la valuta è quella utilizzata dal publisher in DFP.
• m2_size : dimensione della creatività del vincitore per l'asta di offerte su intestazioni per quell'impressione.
• m2_config : rappresenta la versione del codice HB e il nome della configurazione. Questo ci consente di calcolare le prestazioni di diverse versioni del nostro codice HB.
• m2_bidder_list : per una piccola percentuale di visualizzazioni di pagina, escludiamo un offerente dall'asta. Questo ci consente di vedere l'aumento causato da ciascun offerente. Ogni carattere in questa stringa corrisponde a un offerente. L'abbiamo utilizzato per trovare offerenti che stavano semplicemente riempiendo altri o rallentando l'asta fino al punto di abbassare l'RPM della pagina.
• test1, test10, test50, test90 : periodicamente, i publisher desiderano verificare che gli elementi pubblicitari siano idonei solo per determinate visualizzazioni di pagina. Per ognuno di questi, il valore predefinito è "0". Sull'1% delle visualizzazioni di pagina, test1 = 1. Sul 10% delle visualizzazioni di pagina, test10 = 1. Sul 50% delle visualizzazioni di pagina, test50 = 1. E sul 90% delle visualizzazioni di pagina, test90 = 1.
• m2_traffic : sebbene per impostazione predefinita eseguiamo l'header bidding sul 100% delle visualizzazioni di pagina, possiamo disabilitare l'header bidding su una percentuale di pagine visualizzate. Questo KVP ti dice se HB è stato abilitato per quell'impressione e per quale percentuale di visualizzazioni di pagina è stato abilitato. Quindi, ad esempio, "hbon-50" significa che il 50% delle visualizzazioni di pagina per quel segmento aveva HB abilitato e per quella particolare impressione, HB era abilitato.
• m2_overbid : per impostazione predefinita, impostiamo gli elementi pubblicitari HB su un limite di offerta di $ 20 USD o l'equivalente in valuta estera per i publisher che utilizzano altre valute nel proprio account DFP. Qualsiasi offerta superiore a questo limite viene arrotondata per difetto al limite. Ciò è dovuto al fatto che DFP ha sia un limite di elementi pubblicitari per tutta la durata sia un limite di elementi pubblicitari attivi. La creazione irresponsabile di elementi pubblicitari può distruggere completamente un account DFP e, poiché gli account DFP sono associati agli account AdX e AdSense, distrugge l'intera catena di account Google di un publisher. Questo è senza dubbio un male. Tuttavia, alcuni editori hanno segmenti di pubblico in cui potrebbe essere vantaggioso aumentare il limite di offerta oltre i $ 20. Poiché non esiste un limite KVP a vita, utilizziamo m2_overbid per tenere traccia delle offerte che superano il limite dell'offerta e vengono arrotondate per difetto. Gli editori che vedono offerte non trascurabili al di sopra del loro limite vedranno aumentare il loro limite.
• m2_timeout : questo è un KVP combinato utilizzato per tenere traccia del tempo per l'asta. Il KVP assume il seguente formato: t#e#, o talvolta t#e#x#. Il numero che segue la t è il timeout di base impostato per l'asta. Il numero che segue la e è il tempo effettivo trascorso per l'asta. A volte questo è più breve del timeout (tutte le offerte sono tornate in anticipo e DFP era pronto a generare impressioni). A volte questo è più lungo del timeout (di solito perché DFP non è pronto).
• m2_auction_extension : questa combinazione KVP viene utilizzata per tenere traccia dei parametri testati per l'estensione dell'asta. Con l'estensione dell'asta, controlliamo la densità e la distribuzione dell'offerta del publisher per quella visualizzazione di pagina e potenzialmente estendiamo l'asta se è probabile che sia redditizia.
• pageview : questo è impostato su 1 per ogni nuova visualizzazione di pagina. Per calcolare il numero di visualizzazioni di pagina in cui la nostra tecnologia è stata effettivamente eseguita, somma il numero totale di visualizzazioni di pagina riempite e inevase=1. Questo potrebbe essere diverso da Google Analytics perché GA di solito non è adblocked mentre DFP è adblocked. Ignora il numero delle entrate.
• session : è simile al KVP della visualizzazione di pagina, tranne per il fatto che tiene traccia delle sessioni. Per calcolare il numero di sessioni in cui la nostra tecnologia è stata effettivamente eseguita, somma il numero totale di impressioni evase e non evase dove session=1. Ancora una volta, questo può differire da GA a causa del blocco degli annunci.
• request_uri : alcuni editori desiderano monitorare le entrate per articolo. Il metodo più semplice per gli editori per eseguire questa operazione è l'attribuzione delle entrate request_uri. Questo è tutto dopo il nome di dominio. È importante notare, tuttavia, che i KVP hanno un limite massimo di 40 caratteri, quindi i publisher con URL lunghi possono vedersi troncati i valori request_uri.
• session_depth : rappresenta il numero di visualizzazioni di pagina nella sessione dell'utente. Alcuni publisher desiderano abilitare solo determinati partner di domanda nelle visualizzazioni di pagina successive della sessione.
• a9 : PubGuru supporta il sideload della tecnologia di offerta di intestazioni di Amazon A9. A9 non viene gestito all'interno del nostro wrapper, ma sincronizziamo i due timeout tra HB e A9 in modo che nessuno dei due possa terminare l'asta in anticipo. In questo KVP, monitoriamo lo stato di A9 al momento dell'attivazione dell'impressione.
• google : Google come società pubblicitaria richiede che i contenuti degli editori siano sicuri per il brand e generalmente adatti alle famiglie. Per far fronte a questo, abbiamo un sistema di avviso che cerca e identifica i contenuti controversi. Il publisher può quindi impostare google=0, google=no o google=off per disattivare tutti gli elementi pubblicitari di Google per quell'impressione.
• wrapper : tipicamente utilizzato quando un editore ha impostato un test 50/50 tra PubGuru e un altro wrapper. Finché questo è impostato al 50%, si può semplicemente confrontare il ricavo totale tra i due segmenti wrapper per vedere quale ha l'RPM pagina più alto.

KVP di attribuzione dei ricavi

PubGuru Header Bidding supporta anche l'attribuzione dei profitti. Questo viene fatto tramite UTM e ogni UTM ha un KVP corrispondente: utm_source , utm_campaign , utm_content , utm_term , utm_medium . Poiché DFP non supporta rapporti su più KVP, supportiamo anche KVP combinati:

• utm_source_campaign : sorgente e campagna separate da due punti
• utm_scm : sorgente, campagna e mezzo, separati da due punti

KVP di terze parti

Alcuni dei nostri partner pubblicitari aggiungono anche KVP nello stack di annunci. Questi includono:

• amznbid : l'hash dell'offerta per Amazon A9.
• oxb, ox160x600 , ox300x250 , ox300x600 , ox320x50 , ox728x90 e simili: alcune implementazioni dell'offerente di OpenX hanno utilizzato questi KVP.