OpenAdLibraryOpenAdLibrary
Natív hirdetési hálózatok

Natív hirdetési widget elhelyezése: Az RPM maximalizálására szolgáló pozíciók

A natív hirdetési widget pozíciója jobban befolyásolja az RPM-et, mint a mögötte álló hálózat. Íme az elhelyezési hierarchia, méretezési útmutatás és a változtatások megfelelő tesztelése.

Szerkesztős illusztráció: Natív hirdetési widget elhelyezése: Az RPM maximalizálására szolgáló pozíciók

A legmagasabb bevételt hozó pozíció egy natív hirdetési widget számára közvetlenül a cikk szövege alatt van, bármely hozzászólási szekció vagy lábléc felett, egyetlen sorban, négy-nyolc csempével; ez az egyetlen elhelyezés következetesen jobb teljesítményt nyújt, mint az oldalsáv, a cikk közepén és a látható zóna feletti elhelyezések, mert az olvasókat pont abban a pillanatban éri el, amikor befejezték a tartalom fogyasztását, és éppen döntenek a következő lépésről, nem pedig közben szakítja meg őket, vagy versenyez olyan tartalommal, amit még nem értek el.

Miért veri a pozíció szinte minden mást#

Egy tartalomajánló widget csak akkor keres, ha valaki rákattint, és a kattintások attól függenek, hogy az olvasót egy döntési pillanatban érjük el. A cikk szövege alatt van az oldal egyetlen legerősebb döntési pillanata: az olvasó befejezte azt, amiért jött, és a következő cselekvésük (lap bezárása, tovább görgetés, valamire kattintás) valóban eldöntetlen. Minden más pozíció arra kéri a feedben elhelyezett widgetet, hogy versenyezzen azzal, amit az olvasó aktívan csinál.

  • A látható zóna felett, bármely tartalom előtt: technikailag a legnagyobb láthatóságú pozíció, de megszakítja a szándékot, mielőtt az olvasónak bármi ok lenne megbízni az oldalban, és a CTR általában gyenge, mert senki sem azért jött, hogy ajánlásokat lásson olvasás előtt.
  • Cikk közepén, bekezdések közé illesztve: működhet nagyon hosszú formátumú tartalmaknál (2000+ szó) másodlagos elhelyezésként, de közvetlenül versenyez a cikkel, és károsíthatja az olvasási folyamatot, ami viszont károsítja az oldal alján lévő elsődleges hirdetési pozíciókat.
  • Oldalsáv: mobilon (ami a legtöbb kiadó forgalmát jelenti ma) nagyrészt figyelmen kívül hagyott, és asztali gépeken is egyre inkább a banner vakonyság miatt; a natív tartalomajánló csempék itt kifejezetten gyengébben teljesítenek a feedben elhelyezett pozíciókhoz képest, mert a formátum úgy épül fel, hogy tartalomnak nézzen ki, és a tartalom nem az oldalsávban él.
  • A cikk alatt, hozzászólások/lábléc felett: a legerősebb alapértelmezés. Itt jelennek meg a Taboola, Outbrain, MGID és Revcontent widgetek a hirdetési elhelyezések integrációk túlnyomó többségében, és ez az a pozíció, amelyre a saját ajánlott implementációik is először utalnak.

Méretezés és elrendezés#

A widget szélessége meg kell, hogy egyezzen a cikk oszlopával, ne nyúljon túl teljes oldalszélességben azon, ami a tartalom folyamatának részeként tűnik; egy olyan widget, amely inkább felragasztottnak tűnik, mint az oldal designjához tartozónak, még jó pozícióban is a banner vakonyság áldozatává válhat. Négy csempe egyetlen sorban jól működik keskenyebb cikkoszlopokhoz; hat-nyolc csempe két soros rácsban szélesebb elrendezésekhez illik, de ha egyetlen elhelyezésben sokkal több, mint nyolc csempét használunk, az általában növeli a megjelenéseket anélkül, hogy arányosan több kattintást generálna, mivel a figyelem több lehetőségre oszlik szét.

A kép mérete fontosabb, mint a legtöbb kiadó gondolná: az ajánló hálózatok általában jutalmazzák (jobb kitöltési aránnyal és gyakran jobb CPC-vel) azokat az elhelyezéseket, amelyek teljes minőségben renderelik a képeket, nem pedig erősen tömörített bélyegképeket, mivel a képminőség része a licit kreatív minőségi jeleinek súlyozásában. Ellenőrizze a konkrét hálózat aktuális specifikációs dokumentációját az ajánlott méretekért, mivel ezek időszakosan változnak.

Mobilra vonatkozó elhelyezési megjegyzések#

A mobil forgalom ma már dominál a legtöbb kiadó közönségében, és a mobil kétféleképpen változtatja meg a számításokat. Először is, a cikk alatti pozíció mobilon még dominánsabb, mivel egyáltalán nincs oldalsáv lehetőség, ami azt jelenti, hogy a feedben elhelyezett natív pozíció gyakorlatilag az egyetlen ingatlan, amely versenyez azért a "mi következik" döntési pillanatért. Másodszor, az olyan ragadós vagy automatikusan betöltődő widgetek, amelyek az olvasó cikk görgetésének befejezése előtt jelennek meg, általában visszaütnek, mind a felhasználói élmény, mind a hálózat saját minőségi pontozása szempontjából, amely egyre inkább bünteti a magas visszapattanási aránnyal vagy alacsony tartózkodási idővel társított elhelyezéseket.

Egy widget vs. több pozíció egymásra halmozása#

Egyetlen, jól elhelyezett widget futtatása a cikk alatt általában jobb, mint két-három kisebb widget szétszórva futtatása az oldalon. Minden további widget pozíció hígítja a figyelmet több döntési pont között, és a hozzáadott megjelenések nagy része alacsonyabb CTR csempénkénti arány árán jön, nem pedig valódi új interakció formájában. A kivétel a nagyon hosszú formátumú tartalom, ahol egy másodlagos, cikk közepén elhelyezett beillesztés a főbb szakaszok között növelheti a növekményes bevételt anélkül, hogy károsítaná az elsődleges, cikk alatti pozíciót, mivel a két elhelyezés valóban különböző pillanatokban éri el az olvasót (félig úton vs. befejezve).

Gyakori elhelyezési hibák, amelyek csendesen csökkentik az RPM-et#

  • A widget elhelyezése egy "tovább olvasás" vagy lapozási törés felett. Ha a cikke több oldalra oszlik, helyezze a widgetet a tartalom valódi vége után, nem egy lapozott felosztás első oldala után; azok az olvasók, akik még nem fejezték be a cikket, sokkal kevésbé valószínű, hogy rákattintanak egy ajánlásra.
  • Hagyni, hogy a widget a cikk saját képei betöltése előtt renderelődjön. Lassú kapcsolatoknál egy olyan widget, amely a főkép betöltése előtt jelenik meg, úgy tűnik, mintha egy másik, lassabb oldalhoz tartozna, és az olvasók visszapattannak, mielőtt bármelyik teljesen betöltődne.
  • A widget csempe képeinek túlságosan hasonlóvá tétele a saját oldal szerkesztős fotós stílusához. Ez ellentmondásosnak tűnhet, mivel az összeolvadás általában jó design tanács, de a natív hirdetési hálózatok akkor teljesítenek a legjobban, amikor a csempék felismerhetően egy másik, válogatott tartalomkészletet alkotnak, nem pedig megkülönböztethetetlenek a saját cikk bélyegképeitől; az olvasóknak fel kell ismerniük, hogy "további felfedeznivalók", nem pedig összekeverniük a saját oldal kapcsolódó bejegyzéseinek moduljával.
  • A láthatóság figyelmen kívül hagyása. Egy olyan widget, amely egy olyan oldal mélyén töltődik be, amelyet a legtöbb olvasó soha nem ér el, nem fog keresni, függetlenül az elhelyezés minőségétől. Ellenőrizze az analitikáját az átlagos görgetési mélységre az elhelyezés véglegesítése előtt; ha a legtöbb munkamenet nem éri el a 80%-os görgetést, akkor a cikk alatti widgetet feljebb kell mozgatni szerkezetileg, például a felette lévő kitöltő tartalom lerövidítésével.
  • Elfelejteni újra tesztelni egy oldaláttervezés után. Egy olyan áttervezés, amely megváltoztatja az oszlop szélességét, a betűméretet vagy a cikk hosszát, megváltoztatja a görgetési mélységet és az olvasási időt, ami megváltoztatja, hogy a meglévő widget pozíciója még mindig a megfelelő döntési pillanatban ér-e célba. Kezeljen minden áttervezést okként egy új elhelyezési teszt elvégzésére, nem pedig feltételezésként, hogy a régi pozíció még mindig működik.

Hogyan különbözik az elhelyezési útmutató hálózatonként#

A Taboola, Outbrain, MGID, Revcontent és MediaGo mindegyike közzéteszi saját ajánlott implementációját, és bár a cikk alatti pozíció a közös alapértelmezés mindegyiknél, a részletek (minimális csempeszám, szükséges távolság más hirdetési egységektől, hogy a natív és a display elhelyezések szomszédosak lehetnek-e) változnak és idővel változnak. Ellenőrizze a konkrét hálózat aktuális kiadói dokumentációját a csempeszámok vagy távolságok véglegesítése előtt, ne pedig feltételezze, hogy egy hálózat specifikációja egy másikra is vonatkozik; egy olyan elrendezés, amely megfelelő a Taboolán, teljesen megsérthet egy távolsági követelményt egy másik hálózaton.

Mi változik az AMP és az alkalmazásba ágyazott oldalak esetén#

Az AMP oldalak és az alkalmazásba ágyazott cikknézetek (Google Discover feedek, Apple News-stílusú burkolatok) gyakran korlátozzák, hogy hol és hogyan renderelődjön egy widget, és néhány hálózat fenntart külön AMP-specifikus címkéket csökkentett testreszabhatósággal. Ha a forgalmad jelentős része ezeken a felületeken érkezik, ellenőrizze közvetlenül a hálózat aktuális AMP integrációs dokumentációját, ne pedig feltételezze, hogy a szokásos asztali elhelyezés átvihető, mivel a renderelési viselkedés eléggé eltér ahhoz, hogy számítson mind a kitöltési arány, mind az elrendezés szempontjából.

Az elhelyezési változtatások megfelelő tesztelése#

Mivel az RPM egyesíti a CTR-t, a CPC-t és a kitöltési arányt egy számba, egy elhelyezési változtatáshoz legalább két-négy hét stabil forgalomra van szükség a tiszta értelmezéshez, és ideális esetben A/B felosztásra (néhány oldalon az új elhelyezés, néhányon a régi, ugyanabban az időszakban), nem pedig egyszerű előtte/utána összehasonlításra, mivel a forgalom összetétele hétről hétre változik, függetlenül attól, mit változtattunk az oldalon. Azok a kiadók, akik elhelyezési változtatást hajtanak végre, és három nap adat alapján ítélik meg, általában a zajra reagálnak, nem a jelre.

Tartsanak egy egyszerű naplót arról, hogy mi változott és mikor: dátum, érintett oldalsablon, és a konkrét változás (widgetet 200 képponttal feljebb mozgatták, második sort adtak hozzá, csempeszámot négyről hatra cserélték). E napló nélkül lehetetlen lesz egy későbbi RPM változást az elhelyezési változtatáshoz vagy egy szezonális hirdetői kereslet ingadozáshoz, vagy egy viral posztból származó forgalom összetétel változáshoz rendelni. A több sablont futtató kiadóknak (hír cikk, teszt bejegyzés, listás cikk) külön kell tesztelniük minden sablont is, mivel a 400 szavas hír cikken az ideális elhelyezés ritkán azonos egy 3000 szavas vásárlói útmutatón lévő ideális elhelyezéssel, amely teljesen más görgetési és olvasási idő profillal rendelkezik.

Hogyan illeszkedik be az OpenAdLibrary#

Mielőtt elköteleződne egy adott hálózat widgetje mellett a legnagyobb forgalmú oldalain, segít látni, hogy mely hirdetők aktívak jelenleg azon a hálózaton a tartalma vertikálisában, mivel egy olyan widget, amely mögött gyenge hirdetői kereslet áll, gyengébben teljesít, függetlenül attól, milyen jól helyezi el. Az OpenAdLibrary natív hirdetés kém eszköze lehetővé teszi, hogy ellenőrizze az élő kreatívok mennyiségét és a hirdetői mixet hálózatonként, mielőtt eldöntené, hová irányítja a legjobb leltárát.

GYIK#

Gyakran ismételt kérdések

Hol helyezzem el a natív hirdetési widgetet a legmagasabb RPM érdekében?
Közvetlenül a cikk szövege alatt, a hozzászólások szekció vagy a lábléc felett, egyetlen sorban, négy-nyolc csempével. Ez a pozíció következetesen jobb teljesítményt nyújt, mint az oldalsáv, a látható zóna feletti vagy a cikk közepén elhelyezett pozíciók, mert az olvasókat abban a pillanatban éri el, amikor befejezték a tartalom fogyasztását, és még nem döntöttek a következő lépésről.
Befolyásolja a widget mérete a kattintási arányt?
Igen. Négy csempe alkalmas keskeny cikkoszlopokhoz, hat-nyolc csempe rácsban szélesebb elrendezésekhez illik, és ha egyetlen elhelyezésben sokkal több, mint nyolc csempét használunk, az általában szétoszlatja a figyelmet anélkül, hogy arányosan több kattintást generálna. A widget szélességét a tartalom oszlopához kell igazítani, nem pedig teljes oldalszélességűre nyújtani.
Több natív hirdetési widgetet futtassak oldalanként?
Általában nem, a nagyon hosszú formátumú tartalmakon kívül. Egyetlen, jól elhelyezett widget a cikk alatt általában jobb teljesítményt nyújt, mint több kisebb widget, amelyeket szétszórva helyezünk el az oldalon, mivel minden további pozíció ugyanazért a korlátozott figyelemért versenyez. Egy másodlagos, cikk közepén elhelyezett pozíció működhet 2000 szónál hosszabb tartalmakon anélkül, hogy károsítaná az elsődleges pozíciót.
Különbözik a mobil elhelyezés az asztali változattól?
Igen. A mobil eszközökön nincs oldalsáv lehetőség, így a cikk alatti pozíció még dominánsabbá válik. Az olyan ragadós vagy automatikusan betöltődő widgetek, amelyek megszakítják a görgetést, mielőtt az olvasó befejezné a cikket, általában károsítják mind a felhasználói élményt, mind a hálózat minőségi pontozását, ami idővel csökkentheti a kitöltési arányt.
Mennyi ideig teszteljem egy elhelyezési változtatást, mielőtt értékelem az eredményeket?
Legalább két-négy hét stabil forgalommal, ideális esetben A/B teszteléssel (néhány oldalon az új elhelyezés, néhányon a régi, ugyanabban az időszakban), nem pedig egyszerű előtte/utána összehasonlítással, mivel az RPM a kattintási arányt, a CPC-t és a kitöltési arányt egyesíti, és a forgalom összetétele önmagában is változik hétről hétre, függetlenül attól, mit változtattunk az oldalon.
Az OpenAdLibrary Csapat
ÍrtaAz OpenAdLibrary Csapat
Ad intelligencia és natív hirdetéskutatás

Mi építjük az OpenAdLibrary-t, a nyílt hirdetésátláthatósági platformot. Rendszereink naponta élő natív hirdetéseket rögzítenek a Taboola, Outbrain, MGID, Revcontent, Teads, Yahoo és MSN hálózatokon, azonosítják az egyes hirdetések mögötti valódi hirdetőt, és követik a kattintást a céloldalig. Ezek az útmutatók összegyűjtik, amit ezekben az adatokban látunk, hogy gyorsabban kutatni tudd a piacot.