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.

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.






