Plassering av native annonse-widget: Posisjoner som maksimerer RPM

Den høyest inntjenende posisjonen for en native annonse-widget er direkte under artikkelteksten, over eventuelt kommentarfelt eller bunntekst, med en størrelse på en enkelt rad med fire til åtte fliser; denne ene plasseringen overgår konsekvent sidefelt, midt i artikkelen og plasseringer over folden fordi den fanger lesere i det nøyaktige øyeblikket de har fullført innholdet og bestemmer seg for hva de skal gjøre videre, i stedet for å avbryte dem midt i lesingen eller konkurrere med innhold de ennå ikke har nådd.

Hvorfor posisjon slår nesten alt annet#

En innholdsanbefalingswidget tjener bare når noen klikker på den, og klikk avhenger av å fange en leser i et beslutningsøyeblikk. Under artikkelteksten er det eneste sterkeste beslutningsøyeblikket på en side: leseren har fullført det de kom for, og deres neste handling (lukk fanen, fortsett å scrolle, klikk på noe) er genuint uavklart. Hver annen posisjon ber in-feed-widgeten om å konkurrere med noe leseren aktivt gjør.

• Over folden, før noe innhold: teknisk sett den høyest synlige plassen, men den avbryter intensjonen før leseren har noen grunn til å stole på siden, og CTR er typisk svak fordi ingen kom for å se anbefalinger før de har lest noe.
• Midt i artikkelen, satt inn mellom avsnitt: kan fungere for svært langt innhold (2000+ ord) som en sekundær plassering, men den konkurrerer direkte med artikkelen selv og kan skade leseflyten, som igjen skader dine primære annonseplasser lenger ned på siden.
• Sidefelt: i stor grad ignorert på mobil (mesteparten av utgivertrafikken i dag) og i økende grad ignorert på desktop på grunn av bannerblindhet; native innholdsanbefalingsfliser underpresterer spesifikt her sammenlignet med in-feed-posisjoner fordi formatet er bygget for å se ut som innhold, og innhold lever ikke i sidefelt.
• Under artikkelen, over kommentarer/bunntekst: den sterkeste standarden. Dette er hvor Taboola, Outbrain, MGID og Revcontent-widget-er vises i det store flertallet av annonseplassering-integrasjoner, og det er posisjonen deres egne anbefalte implementeringer peker på først.

Størrelse og oppsett#

Widget-bredde bør samsvare med artikkelkolonnen din, ikke strekkes over full sidebredde utover det som føles som en del av innholdsstrømmen; en widget som ser ut som den er limt på i stedet for å være naturlig for sidedesignet, har en tendens til å bli bannerblind selv i en god posisjon. Fire fliser i en enkelt rad fungerer bra for smalere artikkelkolonner; seks til åtte fliser i et to-rads rutenett passer til bredere oppsett, men å gå mye forbi åtte fliser i én plassering legger vanligvis til visninger uten å legge til proporsjonale klikk, siden oppmerksomheten sprer seg tynt over flere alternativer.

Bildestørrelse betyr mer enn de fleste utgivere antar: anbefalingsnettverk belønner generelt (med bedre fyllgrad og ofte bedre CPC) plasseringer som gjengir bilder i full kvalitet i stedet for sterkt komprimerte miniatyrbilder, siden bildekvalitet er en del av det kreativkvalitetssignalene i auksjonen vektlegger. Sjekk det spesifikke nettverkets nåværende spesifikasjonsdokumentasjon for anbefalte dimensjoner, siden disse endres periodisk.

Mobilspesifikke plasseringsnotater#

Mobiltrafikk dominerer de fleste utgivers publikum nå, og mobil endrer kalkylene på to måter. For det første er posisjonen under artikkelen enda mer dominerende på mobil siden det ikke finnes noe sidefelt-alternativ i det hele tatt, noe som betyr at in-feed native plassering effektivt blir den eneste eiendommen som konkurrerer om det "hva nå"-beslutningen. For det andre har sticky eller automatisk innlastende widget-er som vises før en leser har fullført å scrolle artikkelen en tendens til å slå tilbake, både på brukeropplevelsen og på nettverkets egen kvalitetsscoring, som i økende grad straffer plasseringer assosiert med høyt frafall eller lav oppholdstid.

Én widget vs. stable flere posisjoner#

Å kjøre en enkelt godt plassert widget under artikkelen slår vanligvis å kjøre to eller tre mindre widget-er spredt utover siden. Hver ekstra widget-posisjon fortynner oppmerksomheten over flere beslutningspunkter, og mesteparten av de ekstra visningene kommer på bekostning av lavere CTR per flis i stedet for genuint ny engasjement. Unntaket er svært langt innhold, hvor en sekundær innsetting midt i artikkelen mellom store seksjoner kan legge til inkrementell inntekt uten å kannibalisere den primære plassen under artikkelen, siden de to plasseringene fanger leseren på genuint forskjellige tidspunkt (midtveis vs. ferdig).

Vanlige plasseringsfeil som i stillhet koster RPM#

• Plassere widget-en over en "les mer"- eller pagineringsbrytning. Hvis artikkelen din deles over flere sider, plasser widget-en etter den sanne slutten på innholdet, ikke etter side én av en paginert deling; lesere som ikke har fullført stykket er langt mindre sannsynlig til å klikke på en anbefaling.
• La widget-en gjengis før artikkelens egne bilder lastes. På trege tilkoblinger ser en widget som tegnes før hovedbildet er ferdig lastet ut som den tilhører en annen, tregere side, og lesere hopper av før noen av dem lastes fullstendig.
• Matche widget-flisebilder for nært med nettstedets egen redaksjonelle fotostil. Dette høres kontraintuitivt ut, siden å blande seg inn vanligvis er god designråd, men native annonsenettverk presterer best når flisene gjenkjennelig er et annet, kurert sett med innhold, ikke uatskillelig fra dine egne artikkelminiatyrbilder; lesere må registrere det som "mer å utforske," ikke forveksle det med nettstedets eget relaterte innlegg-modul.
• Ignorere synlighet. En widget som lastes langt ned på en side de fleste lesere aldri når, vil ikke tjene penger uavhengig av posisjonskvalitet. Sjekk analysene dine for gjennomsnittlig scrolldybde før du finaliserer en plassering; hvis de fleste øktene ikke når 80% scroll, kan widget-en din under artikkelen måtte flyttes opp strukturelt, for eksempel ved å forkorte fyllinnhold over den.
• Glemme å teste på nytt etter en nettstedsoppussing. En oppussing som endrer kolonnebredde, skriftstørrelse eller artikkellengde forskyver scrolldybde og lesetid, som endrer om din eksisterende widget-posisjon fortsatt lander på rett beslutningsøyeblikk. Behandle hver oppussing som en grunn til å kjøre en plassertest på nytt, ikke en antakelse om at den gamle posisjonen fortsatt fungerer.

Hvordan plasseringsveiledning varierer etter nettverk#

Taboola, Outbrain, MGID, Revcontent og MediaGo publiserer hver sine egne anbefalte implementeringer, og mens posisjonen under artikkelen er den felles standarden på tvers av alle, varierer detaljene (minimum antall fliser, påkrevd avstand fra andre annonseenheter, om native og display-plasseringer kan sitte ved siden av) og endres over tid. Sjekk det spesifikke nettverkets nåværende utgiverdokumentasjon før du finaliserer fliseantall eller avstand, i stedet for å anta at ett nettverks spesifikasjon gjelder for et annet; et oppsett som er kompatibelt på Taboola kan bryte et avstandskrav på et helt annet nettverk.

Hva endres for AMP- og app-innbakte sider#

AMP-sider og app-innbakte artikkelvisninger (Google Discover-feeder, Apple News-lignende innpakninger) begrenser ofte hvor og hvordan en widget kan gjengis, og noen nettverk opprettholder separate AMP-spesifikke koder med redusert tilpasning. Hvis en betydelig andel av trafikken din kommer gjennom disse overflatene, sjekk nettverkets nåværende AMP-integrasjonsdokumentasjon direkte i stedet for å anta at din standard desktop-plassering overføres, siden gjengivelsesatferd er forskjellig nok til å bety noe for både fyllgrad og oppsett.

Testing av plasseringsendringer riktig#

Fordi RPM blander CTR, CPC og fyllgrad til ett tall, trenger en plasseringsendring minst to til fire uker med stabil trafikk for å leses klart, og helst en A/B-splitt (noen sider med den nye plasseringen, noen med den gamle, samme tidsvindu) i stedet for en ren før/etter-sammenligning, siden trafikkmiksen endrer seg fra uke til uke uavhengig av hva du endrer på siden. Utgivere som gjør en plasseringsendring og vurderer den ut fra tre dagers data reagerer vanligvis på støy, ikke signal.

Hold en enkel logg over hva som endret seg og når: dato, sidesjablon berørt, og den spesifikke endringen (flyttet widget opp 200 piksler, la til en ekstra rad, byttet fliseantall fra fire til seks). Uten den loggen blir det umulig å tilskrive en senere RPM-endring til plasseringsendringen versus en sesongmessig svingning i annonsøretterføringspørsel eller en trafikkmiksendring fra et viralt innlegg. Utgivere som kjører flere sjabloner (nyhetsartikkel, anmeldelsesinnlegg, listicle) bør teste hver sjablon separat også, siden den ideelle plasseringen på et 400-ords nyhetsinnlegg sjelden er identisk med den ideelle plasseringen på en 3000-ords kjøpsguide med et helt annet scroll- og lesetidsprofil.

Hvordan OpenAdLibrary passer inn#

Før du forplikter deg til en spesifikk nettverks widget på dine høyest trafikkerte sider, hjelper det å se hvilke annonsører som faktisk er aktive på det nettverket i innholdets vertikal akkurat nå, siden en widget med svak annonsøretterføringspørsel bak den vil underprestere uavhengig av hvor godt du plasserer den. OpenAdLibrarys native annonse-spionverktøy lar deg sjekke live kreativt volum og annonsørmiks per nettverk før du bestemmer deg for hvor du skal dirigere ditt beste inventar.

FAQ#