OpenAdLibraryOpenAdLibrary
Affiliate & Media Buying

Blokerer adblockere native annoncer? Sådan slipper widgets igennem

Adblockere fanger en reel del af native annoncetrafik, men ikke alt. Her er årsagen til, at widget-domæner bliver filtreret, mens publisher-renderede native indhold ofte ikke gør.

Redaktionel illustration: Blokerer adblockere native annoncer? Sådan slipper widgets igennem

Adblockere blokerer nogle native annoncer og lader andre slippe igennem, og opdelingen afhænger af, hvordan widget'en serveres, ikke af om formatet er "native". Widgets indlæst fra et netværks eget script-domæne (som et Taboola- eller Outbrain-tag) er på populære filterlister som EasyList, så en betydelig andel af adblocker-brugere ser dem aldrig. Indhold, som en publisher serverer nativt, i sin egen markup, uden et tredjepartsscript-kald, bliver normalt ikke fanget af noget, fordi der ikke er noget adserver-domæne for en filterliste at matche mod.

Hvorfor adblockere fungerer, som de gør#

De fleste forbruger-adblockere (uBlock Origin, AdBlock Plus og de indbyggede blokkere i Brave og nogle mobilbrowsere) fungerer ved at matche netværksanmodninger og sideelementer mod fællesskabsvedligeholdte filterlister. EasyList er den største og mest udbredte. Disse lister fungerer på niveauet af domæner, subdomæner og CSS-selektorer: hvis et script anmodes fra et kendt adserver-værtsnavn, eller et element matcher et kendt annoncebeholder-klassenavn, blokeres eller skjules det, før det renderes.

Denne tilgang blev bygget til traditionel displayannoncering, hvor annoncen tydeligt kommer fra en separat adserver (et DoubleClick- eller AppNexus-kald for eksempel), der er let at fingerprinte. Native widgets komplicerer denne model, fordi anmodningen ofte kommer fra netværkets eget brandede domæne (taboola.com, outbrain.com, mgid.com), som filterlistevedligeholdere har haft år til at identificere og tilføje. Så det er ikke korrekt at sige, at native annoncering er usynlig for blokkere; de store netværks standard widget-domæner er faktisk på EasyList og lignende lister, og en reel andel af adblocker-trafik indlæser slet ikke native annonce-widget'en.

Hvor native stadig slipper igennem#

Gabet, der holder natives effektive blokeringsrate lavere end banner- eller videoformater, kommer fra et par steder:

  • Publisher-side rendering. Nogle publishers integrerer en anbefalingswidgets output direkte i deres egne sideskabeloner i stedet for at indlæse det som en åbenlys tredjeparts iframe, hvilket gør det sværere for en generisk filterregel at isolere rent fra omgivende redaktionelt indhold.
  • Visuel camouflage selv når anmodningen indlæses. En native enhed, der kommer igennem, renderes som et billede og en overskrift, der matcher sidens grid. Selv brugere uden en blokerer, som ser annoncen, registrerer ofte ikke den som en annonce på samme måde som et banner, hvilket er et relateret men separat fænomen fra adblockering (ofte kaldet bannerblindhed, og native blev specifikt designet til at reducere det).
  • CNAME-cloaking og first-party proxy. Nogle adtech bruger en publishers eget subdomæne (via en CNAME DNS-post) til at dirigere, hvad der teknisk set er tredjeparts adserver-trafik, gennem hvad der ligner en first-party-anmodning. Dette er en kendt, aktivt omstridt praksis: flere filterlistevedligeholdere og browserudviklere har bygget specifikke modforanstaltninger mod CNAME-baseret sporing, så dens effektivitet mod blokkere er blevet mindre, ikke større.

Hvad dette betyder for annoncører og publishers#

Hvis du er annoncør, er den praktiske implikation, at natives eksponering for adblockering er reel men delvis. Den er lavere end display og dramatisk lavere end pre-roll video, hvilket forklarer en del af natives holdbarhed som en kanal, men du bør ikke antage, at hver eneste visning, en adserver rapporterer, faktisk blev vist foran et menneske, der kunne se den, et koncept dækket bredere i vores gennemgang af synlighed. Hvis du er en publisher, der er afhængig af native anbefalingsindtægter, skærer den samme logik den anden vej: en del af din trafik med adblockere aktiveret vil aldrig indlæse widget'en overhovedet, hvilket er værd at tage med i RPM-forventninger snarere end at behandle rapporterede visninger som det fulde publikum.

Format Typisk eksponering for filterliste-blokering
Banner/display Høj, veletablerede adserver-domæner og beholder-mønstre
Pre-roll video Høj, plus separat video-specifikt blokeringsværktøj
Native widget (standard script) Delvis, store netværksdomæner er på almindelige lister
Native indhold serveret nativt af publisher, intet tredjepartsscript Lav til ingen, intet for en filterliste at matche

Compliance-vinklen, ingen taler om#

Der er en anden grund til, at native annoncer nogle gange ser ud til at "slippe igennem", som intet har at gøre med adblockere: uoverensstemmende eller manglende annoncetags og inkonsekvent afsløringsmærkning. En widget, der ikke er tydeligt markeret "Sponsoreret", kan for en tilfældig læser se ud som om den undgik opdagelse helt, når den i virkeligheden bare ikke var mærket godt fra starten. Det er et policy- og brandsikkerhedsproblem for netværket og annoncøren, adskilt fra alt, hvad en browsertilføjelse gør, og et distinkt problem fra den annoncesvindel, der direkte overtræder netværkspolitik. Det er også en af de ting, der dukker op, når man reviderer en konkurrents native annonce forsyningskæde: om afsløringsmærkning er konsekvent på tværs af de geografier og publishers, en annoncør kører i, og hvordan det sammenlignes med hvordan Taboola-annoncer fungerer på placeringsniveauet.

Hvordan blokeringsrater varierer efter platform og browser#

Billedet er heller ikke ensartet på tværs af enheder. Desktop-browsere har de dybeste tilføjelsesøkosystemer, så desktop adblocker-adoption har tendens til at være betydeligt højere end mobil, hvor installation af en blokerer normalt betyder en dedikeret app eller en browser med indbygget filtrering (Brave, nogle privathedsorienterede mobilbrowsere) snarere end en simpel tilføjelsesinstallation. Den asymmetri er en af grundene til, at native kampagner, der målretter mobil-tung beholdning, ofte rapporterer forskellig effektiv synlighed end den samme kreative, der kører på desktop-placeringer, selv før nogen forskel i kreativ ydeevne overvejes. Det er også en del af grunden til, at geografisk mix betyder noget her: adblocker-adoption varierer betydeligt efter land, generelt højere i markeder med stærk privathedsværktøjsbevidsthed og lavere, hvor mobil-først browsing dominerer.

Indtægtssidens pres, der former alt dette#

Publishers er afhængige af native anbefalingsindtægter nok til, at nogle stille har skubbet tilbage mod blokering på måder ud over CNAME-tricks, inklusive "acceptable ads"-stil whitelistingsprogrammer, som nogle blokkere kører, hvor visse annonceformater (inklusive nogle native placeringer) bliver tilladt som standard, hvis de opfylder angivne ikke-påtrængende kriterier. Dette er et virkeligt omstridt område: nogle brugere ser det som en rimelig kompromis, andre ser det som blokkere, der monetiserer undtagelser. Uanset hvad er det en anden grund til, at en given native placerings virkelige blokeringsrate er tættere på "det afhænger af den specifikke blokerers politik" end et enkelt universelt tal.

Hvad dette betyder, hvis du forsøger at undersøge konkurrenters native annoncer#

Hvis du reviderer, hvad der faktisk kører, skal du ikke stole på at browse med en blokerer deaktiveret i én browserprofil og antage, at det er repræsentativt; fang på tværs af enhedstyper og helst uden at stole på live browsing overhovedet, da manuelt at skifte blokkere geo-for-geo ikke skalerer og stadig går glip af server-side rendering-forskelle mellem publishers. Dette er en del af grunden til, at uafhængige indeks eksisterer: i stedet for manuelt at deaktivere tilføjelser og gen-crawle manuelt, fanger OpenAdLibrary's native annonce spionværktøj native kreativer direkte ved kilden på tværs af netværk og publishers, så hvad du ser i indekset afspejler, hvad der faktisk serveres, ikke hvad én browserkonfiguration tilfældigvis lod slippe igennem.

En hurtig test, du selv kan køre#

Hvis du vil se dette førstehånds, indlæs den samme side med en mainstream blokerer aktiveret og deaktiveret, og se hvad der sker med anbefalingswidget'en i bunden af en artikel. På mange mellemstore publishers, der kører en standard Taboola- eller Outbrain-integration, forsvinder widget'en helt med blokeren tændt, nogle gange efterlader et synligt hul i layoutet, hvor pladsholderen ikke fik chancen for at fylde ud. På andre publishers, især dem, der har tilpasset integrationen eller blandet den tættere med deres eget indholdsanbefalingssystem, er forskellen langt mindre åbenlys. Denne inkonsekvens på tværs af publishers, ikke et enkelt teknisk trick, er den virkelige grund til, at "stopper adblock native annoncer" ikke har et enkelt klart svar.

Bundlinjen#

Adblockere blokerer en reel del af native annoncetrafik, specifikt de standard widget-scripts fra store netværk, der er på populære filterlister. Hvad de ikke pålideligt fanger, er indhold renderet nativt inden for en publishers egen skabelon, eller den visuelle camouflage, der forhindrer native annoncer i at blive registreret som annoncer, selv når de indlæses. Hvis du budgetterer eller rapporterer mod native, skal du behandle "serverede visninger" og "visninger faktisk set af et menneske" som to forskellige tal, for for dette format specifikt er gabet mellem dem reelt.

Ofte stillede spørgsmål

Blokerer adblockere Taboola og Outbrain widgets?
Delvist. De standard widget-script-domæner for store native netværk er inkluderet på populære filterlister som EasyList, så en del af adblocker-brugere vil slet ikke indlæse widget'en. Publisher-side implementeringer, der undgår et åbenlyst tredjepartsscript-kald, bliver mindre konsekvent fanget.
Hvorfor har native annoncer lavere adblockeringsrater end bannerannoncer?
Native annoncer renderes som billeder og overskrifter, der er stylede til at matche den omgivende side, hvilket gør dem sværere for både filterlisteregler og menneskelig mønstergenkendelse at isolere, sammenlignet med et tydeligt afgrænset banner knyttet til et velkendt adserver-domæne.
Hvad er CNAME-cloaking i adtech?
CNAME-cloaking dirigerer tredjeparts annonce- eller sporingsanmodninger gennem en publishers eget subdomæne via en DNS CNAME-post, hvilket får trafikken til at ligne first-party for en filterliste. Browserudviklere og filterlistevedligeholdere har bygget specifikke modforanstaltninger mod det, så det er blevet mindre pålideligt over tid.
Bør annoncører antage, at alle native visninger faktisk blev set?
Nej. Adblocker-adoption og generel bannerblindhed betyder, at rapporterede visninger og visninger faktisk opfattet af et menneske er forskellige tal, især for native. Budget- og rapporteringsbeslutninger bør behandle dette gap som reelt snarere end at antage, at fuld levering er lig med fuld synlighed.
OpenAdLibrary-teamet
Skrevet afOpenAdLibrary-teamet
Ad-intelligence & native annoncering research

Vi bygger OpenAdLibrary, den åbne ad-transparency-platform. Hver dag indsamler vores systemer live native annoncer på tværs af Taboola, Outbrain, MGID, Revcontent, Teads, Yahoo og MSN, identificerer den rigtige annoncør bag hver enkelt og følger klikket til dens landingsside. Disse guides destillerer, hvad vi ser i disse data, så du kan undersøge markedet hurtigere.