Native vs Display RPM: Hvilken betaler utgivere mest?
Native betaler på klikk, display betaler på synlige visninger, og å sammenligne de to RPM-tallene direkte er villedende. Slik fungerer hver mekanisme i praksis for utgivere.

Native annonse-RPM og display annonse-RPM er ikke direkte sammenlignbare tall fordi de betales på forskjellige mekanismer: inntekter fra native widgets drives av klikk på anbefalt innhold, mens display-RPM drives av synlige visninger på bannerbeholdningen din. Ingen av formatene er universelt høyere betalende; hvilken som gir en bedre RPM på en gitt side avhenger av annonsørefterspørselen i ditt innhold, målgruppens klikkatferd, og hvor på siden hvert annonseformat befinner seg.
Hvorfor du ikke kan sammenligne de to RPM-tallene direkte#
RPM (inntekt per tusen sidevisninger) er en normalisert metrikk, noe som gjør det fristende å behandle en native RPM og en display RPM som utskiftbare tall du kan rangere mot hverandre. De måler ikke den samme underliggende atferden. En displayannonse tjener penger i det øyeblikket den gjengis og er synlig, uavhengig av om leseren samhandler med den i det hele tatt. En native widget tjener ingenting før en leser faktisk klikker seg videre til et anbefalt innhold, og da får du en andel av det annonsøren bydde for det spesifikke klikket. To sider med identiske sidevisninger kan gi svært forskjellige native RPM-er utelukkende basert på hvor overbevisende anbefalingstittlene er, uavhengig av display-RPM på samme side.
Mekanismene, side om side#
| Native (Taboola, Outbrain, MGID, Revcontent) | Display (bannere, Mediavine, Ezoic) | |
|---|---|---|
| Hva utløser betaling | Et klikk på et anbefalt element | En synlig visning |
| Hvor den vanligvis befinner seg | Slutten av artikkel, noen ganger midt i innholdet | Sidefelt, i innhold, klebrige enheter |
| Format | Overskrift + miniatyrbilde-rutenett, blander seg med redaksjonelt innhold | IAB-standard bannerstørrelser |
| Mest følsom for | Widget-klikkfrekvens, annonsørefterspørsel i nisje | Synlighet, annonsetetthet, dybde på header-budgivning |
| Beste innholdspassform | Langform redaksjonelt innhold, nysgjerrighetsvekkende overskrifter | Alle formater, fungerer over hele siden |
Hvorfor spørsmålet "hvilken betaler mest" ikke har ett svar#
Det ærlige svaret er at det avhenger av hva som driver trafikk til siden, hva innholdet handler om, og hvordan annonsen måles for konvertering lenger ned i trakten. En side med sterk intensjonsdrevet søketrafikk (noen som aktivt forsker på en helsetilstand eller et finansprodukt) har en tendens til å ha sterkere native widget-ytelse, siden leseren allerede er forberedt på å fortsette å lese relatert innhold og annonsører innen helse- og finansområdene, noen av de dypeste annonsørkategoriene sporet i OpenAdLibrarys indeks, byr aggressivt for det klikket. En side med mer passiv, rulledrevet sosiale medier-trafikk har ofte sterkere relativ display-ytelse, siden visninger akkumuleres uavhengig av om leseren engasjerer seg videre.
Nisje betyr mer enn format i de fleste tilfeller. Områder med tett annonsørefterspørsel (helse, finans og forsikring viser konsekvent størst kreativvolum i det native annonseøkosystemet) har en tendens til å gi sterke RPM-er i både native og display, ganske enkelt fordi flere annonsører konkurrerer om plass uavhengig av betalingsmekanismen. En nisje med lav etterspørsel vil underprestere i begge formater, og å bytte fra native til display, eller omvendt, vil ikke løse et fundamentalt etterspørselsproblem.
Hvor hvert format har en strukturell fordel#
Native har én klar strukturell fordel: det tjener penger på leseroppmerksomheten etter at de har fullført innholdet ditt, i det eksakte øyeblikket de bestemmer seg for om de skal forlate siden eller fortsette å bla. Det er et øyeblikk displayannonsering ikke får fange på samme måte, siden et banner tjener sin visning uavhengig av om leseren fullfører artikkelen eller forlater siden etter ti sekunder. Dette er delvis grunnen til at native widgets har en tendens til å gjøre uforholdsmessig bra på langform, dypt engasjerende innhold der en leser som fullfører stykket er en genuint engasjert leser.
Display har den motsatte fordelen: det tjener penger uavhengig av engasjementsdybde, noe som gjør det mer motstandsdyktig på innholdstyper der lesere skummer i stedet for å fullføre, som listeposter eller korte referanseartikler, og det passer naturlig inn i en bredere programmatisk annonsering-stabel sammen med direkte solgt beholdning. En administrert displaynettverks header-budgivning har også en tendens til å trekke ut mer verdi fra en enkelt visning enn et enkelt widget-klikk kan, når annonsørefterspørselen er genuint dyp, siden dusinvis av etterspørselskilder byr på den ene plassen samtidig.
Det praktiske svaret: kjør begge, mål separat#
Siden de to formatene tjener penger på forskjellig leseratferd på samme side, er det praktiske valget ikke å velge en vinner, det er å kjøre begge og følge med på hver RPM uavhengig i stedet for å prøve å tvinge frem ett kombinert tall. Hvis din native RPM er flat mens display-RPM fortsetter å stige, er det et signal om at widget-plasseringen, overskriftkvaliteten eller nisjeetterspørselen etter klikkinnhold trenger oppmerksomhet, ikke at native annonser som kategori underpresterer. Det motsatte gjelder også.
Å sjekke hva som faktisk kjører i ditt innholdsområde er den raskeste måten å kontrollere begge tallene på. OpenAdLibrarys native annonse-spionverktøy lar deg se live kreativvolum etter område og nettverk gratis, noe som forteller deg om lav native RPM i din nisje er et plasseringsproblem eller ganske enkelt et etterspørselsproblem du ikke kan optimalisere deg ut av.
Hva dette betyr for en utgiver som bestemmer hvor de skal investere innsats#
Hvis din native RPM henger langt etter i forhold til display-RPM på sammenlignbare sider, se først på widget-plassering og overskriftkvalitet før du antar at formatet i seg selv er feil for ditt innhold. Hvis begge henger etter i forhold til hva lignende utgivere rapporterer i din nisje, er det mer sannsynlig at problemet er annonsørefterspørselstetthet i din innholdskategori, noe ingen mengde optimalisering av annonsestabelen på noen side vil fullstendig fikse. Å tilpasse innholdsstrategi til påvist annonsørefterspørsel, i begge formater, har en tendens til å flytte på nålen mer enn å velge native fremfor display eller omvendt.
Hvordan synlighet stille former display-RPM spesifikt#
Display-RPM har en variabel som native for det meste omgår: synlighet. Et banner som gjengis under brettet og aldri faktisk blir rullet inn i synsfeltet, tjener ingenting under de fleste moderne header-budgivningsordninger, selv om det teknisk sett lastet på siden. Dette er grunnen til at to nettsteder med identiske rå sidevisninger og identisk annonsetetthet kan vise svært forskjellige display-RPM-er hvis den ene har et langsommere rullende, mer engasjert publikum og den andre har en høy frafallsrate som aldri får leserne forbi første skjerm. Native widgets, som sitter på slutten av en artikkel, filtrerer implisitt for en mer engasjert undergruppe av lesere, siden bare noen som faktisk har nådd bunnen av siden noen gang ser widgeten i det hele tatt, noe som er delvis grunnen til at native RPM per widget-visning har en tendens til å se sterk ut selv når overordnede side-RPM-sammenligninger blir mer rotete.
Hvorfor langtidsdata er et nyttig kryssjekk for begge formater#
Et signal som gjelder for både native og display-beslutninger er hvor lenge spesifikke annonsørkampanjer fortsetter å kjøre i ditt område. En annonsør som holder et native kreativt i live i uker, i stedet for å trekke det tilbake etter noen få dager, forteller deg implisitt at kampanjen er lønnsom nok til å opprettholde, noe som er en proxy for hvor mye vedvarende etterspørsel (og vedvarende RPM-støtte) du kan forvente i en gitt innholdsnisje. OpenAdLibrarys annonselangtidssignal sporer nettopp dette på tvers av indeksen, først-sett og sist-sett datoer på hvert kreativ, noe som gir utgivere en måte å vurdere om et nisjes native etterspørsel er et forbigående toppunkt eller en varig trend før de omstrukturerer en innholds- eller inntjeningsstrategi rundt det.
Kombinere de to formatene uten å overkomplisere måling#
Den enkleste praktiske oppsettet de fleste utgivere lander på er å kjøre en administrert display-stabel (Mediavine, Ezoic, eller et lignende nettverk) over hele siden som grunnlinje, legge til en enkelt native widget på slutten av artikkelen som et ekstra inntjeningslag, og gjennomgå begge RPM-tallene månedlig i stedet for daglig, siden dag-til-dag-svingninger i begge målestokkene for det meste er støy fra annonsørens budsjettpacing snarere enn et signal som er verdt å reagere på umiddelbart. Overoptimalisering av begge formater som svar på kortsiktige svingninger har en tendens til å kaste bort mer tid enn det tjener i ekstra inntekter.
En rask sjekkliste før du omstrukturerer noen av annonsestablene#
Før du antar at et lavt RPM-tall betyr at du bør droppe et format helt, gå gjennom en kort liste: bekreft at widgeten eller banneret faktisk gjengis riktig på mobil, siden en ødelagt mobiloppsett stille dreper en stor andel av de fleste nettsteders trafikkvektet RPM; sjekk om nisjen din viser genuin annonsørefterspørsel før du antar at formatet i seg selv underpresterer; sammenlign RPM over en hel måned i stedet for noen få dager for å jevne ut annonsørens budsjettpacing; og skill ut eventuelle geografiske blandingsendringer, siden et skift mot lavere-tier trafikkkilder vil dempe både native og display RPM samtidig på en måte som ikke har noe med formatvalg å gjøre.







