Mobil céloldalak natív hirdetésekhez: Tervezési szabályok, amelyek konvertálnak

A natív hirdetési forgalom túlnyomórészt mobil, mivel olyan tartalomfeedekből származik, amelyeket a felhasználók a telefonjukon görgetnek, így egy asztali gépre épített, majd lefelé adaptált előoldal rosszabbul teljesít, mint egy eleve mobil-first alapokra tervezett. A legfontosabb tervezési szabályok az oldalsúly, a hüvelykujjal elérhető CTA elhelyezés, az egyszerű oszlopos elrendezés, valamint annak elkerülése, amit a hálózatok megfelelőségi felülvizsgálata intersticiálisnak vagy kényszerített interakciónak tekint.

Miért bukik el olyan gyakran az asztali-first majd adaptálás megközelítés#

Azok a csapatok, amelyek először asztali monitoron terveznek egy előoldalt, hajlamosak olyan feltételezéseket beépíteni, amelyek nem élik túl a telefonos kicsinyítést: több oszlopos elrendezések, amelyek az utolsó pillanatban olvashatatlan egyszerű oszlopba préselődnek, hős képek, amelyek széles képarányra vannak vágva és elvesztik fókuszpontjukat, amikor újra vágják őket keskeny képarányra, valamint CTA elhelyezés, amelyet az asztali képernyőn kiegyensúlyozottnak tűnő elrendezés diktál, nem pedig az, amit a hüvelykujj ténylegesen elér. Egyik sem jelenik meg "hibaként", amit egy gyors asztali felülvizsgálat során észrevennének; csak akkor tűnnek fel, amikor az oldalt úgy nézi meg, ahogy a tényleges látogatója fogja, ezért ha az első vázlattól kezdve mobil-first épít, majd opcionálisan felfelé adaptál asztalira, kevesebb meglepetést okoz, mint a fordított irány.

Tervezzen a hüvelykujjra, ne az egérre#

Minden olyan elem, amely pontos érintést igényel, csökkenti a konverziókat telefonon. A CTA gomboknak elég nagynak kell lenniük a megbízható érintéshez, olyan helyen kell lenniük, ahol a hüvelykujj természetesen tartózkodik (az alsó-középső vagy alsó-harmad része a képernyőnek jobban működik, mint egy olyan gomb, amelyhez nyújtózkodni kell a tetejére), és távol kell lenniük más kattintható elemektől, hogy egy tévesztés ne küldje valaki oda, ahová nem szánta. Egy ragadós CTA sáv, amely látható marad, amíg az olvasó végiggörget egy hosszabb advertorialon, megszünteti a visszagörgetés szükségességét, miután meggyőződtek, ami annál fontosabb, minél hosszabb az oldala, és minél inkább egy teljes narratíva felé hajlik a formátuma, nem pedig egy rövid hídoldal.

Az oldalsúly konverziós tényező, nem csak technikai kérdés#

Minden extra másodperc betöltési idő mobil kapcsolaton egy esélyt jelent arra, hogy elveszít valakit, aki impulzív kattintással érkezett egy tartalomfeedből, és nulla türelme van egy lassú oldalhoz. Tömörítse agresszíven a hős képeket, kerülje az automatikusan lejátszódó videót (ami több hálózaton megfelelőségi vizsgálatot von maga után, és olyan mobiladatot éget, amelyet az olvasó nem vállalt el), lustán töltse be a sáv alatti tartalmat, és tartsa egyszerűen a DOM-ot. Ez együtt jár a domain és a tárhely választásával; egy lassú, túlterhelt megosztott szerver mögött üzemeltetett oldal, vagy amelyik egy szükségtelen extra átirányítási ugráson megy keresztül, tönkreteszi a jó tervezést, mielőtt egyetlen pixel megjelenne. A jó tárhely a jó mobil tervezés előfeltétele, nem egy különálló kérdés, amelyet később meg lehet oldani.

Elrendezés: egyszerű oszlop, függőleges folyam, oldalirányú meglepetések nélkül#

A több oszlopos elrendezések, amelyek asztali gépen működnek, általában rosszul omlanak össze mobilon, hacsak nem eleve mobil-first tervezték őket. Ragaszkodjon egy egyszerű függőleges oszlophoz: hős kép vagy címsor blokk, támogató szöveg rövid bekezdésekben, egyértelmű vizuális törés a CTA előtt, majd az ajánlat átmenet vagy a következő tartalomblokk. Kerülje teljesen a vízszintes görgetést; ez zavaró telefonon, és ritkán szándékos, amikor előfordul.

Mit kerüljön, mert a hálózatok jelezni fogják#

• Kényszerített intersticiálisok vagy felugró ablakok, amelyek blokkolják a tartalmat egy valódi felhasználói művelet előtt. A legtöbb natív hálózat szerkesztői irányelvei ezeket rossz felhasználói élménynek és a kreatív elutasítások gyakori forrásának tekintik; ellenőrizze az adott hálózat aktuális dokumentációját, mielőtt bármilyen intersticiális mintára támaszkodna.
• Automatikusan lejátszódó hang vagy videó. Ugyanez az indoklás: meglepi az olvasót, elégeti az adatforgalmát, és felhívja a felülvizsgálati figyelmet.
• Hamis rendszer UI elemek (hamis "alacsony akkumulátor" figyelmeztetések, hamis értesítési sávok, hamis bezáró gombok, amelyek nem zárnak be semmit). Ezek közel állnak a cloaking területéhez, ahogy a megfelelőségi csapatok olvassák őket, még akkor is, ha nincs technikai cloaking, mert megtévesztik az olvasót arról, hogy mit néz.
• A közzététel elrejtve vagy egy érintés mögé bújtatva. A szponzorációs és reklámközzétételeknek láthatónak kell lenniük további interakció nélkül az olvasó részéről; lásd: FTC Közzétételi szabályok advertorialokhoz és natív hirdetésekhez a "látható" jelenlegi iránymutatás szerinti jelentéséhez.

Tipográfia és olvasási ritmus kis képernyőn#

A szövegtörzs, amely asztali monitoron kényelmes, gyakran túl kicsi telefonon, hacsak nem szándékosan mobilra állítja be: elég nagy alap betűméret a csípés-zoomolás nélküli olvasáshoz, bő sorköz, és a bekezdések rövidek, legfeljebb három-négy sor szünet előtt. A hosszú, megszakítás nélküli bekezdések az egyik leggyorsabb módja annak, hogy elveszítsen egy mobil olvasót az oldal közepén, mivel nincs vizuális pihenőpont, amely jelezné a haladást. Törje meg a hosszabb advertorial szöveget alcímekkel, kiemelt idézetekkel vagy egy releváns képpel néhány bekezdésenként, hogy segítse a tempót és adjon az olvasónak okot a továbbgörgetésre, ahelyett, hogy az első szövegfalnál elpattanna.

Érintési célpontok a CTA-n túl#

Az elsődleges CTA megkapja a tervezési figyelmet, de a másodlagos érinthető elemeknek (egy "tudj meg többet" link, egy bezáró gomb bármely elvethető elemen, navigáció, ha az oldalnak van) ugyanolyan hüvelykujj-barát méretezésre és távolságra van szükségük. Egy bezáró gomb, amely technikailag jelen van, de túl kicsi a megbízható érintéshez, a gyakorlatban nem működik bezáró gombként, és frusztrálóként vagy manipulatívként hat az olvasóra, aki megpróbál elvetni valamit. Az Apple és a Google saját mobil tervezési irányelvei pontosan ezért határoznak meg minimális érintési célpont méreteket, és ezek követése ésszerű alapvonal a natív platform alkalmazásokon kívül is.

Űrlapok: kevesebb mező, natív beviteli típusok#

Ha az előoldal vagy az mögötte lévő ajánlati lépés bármilyen információt gyűjt, minden további mező lemorzsolódási pontot jelent mobilon, ahol a gépelés lassabb és hibásabb, mint asztali gépen. Használja a megfelelő beviteli típust minden mezőhöz (numerikus billentyűzet telefonszámokhoz, e-mail billentyűzet e-mail mezőkhöz), hogy a telefon saját billentyűzete segítse a látogatót, ahelyett, hogy karaktereket kellene keresnie egy általános billentyűzeten. Ha egy mezőt későbbre tud halasztani a tölcsérben, ahelyett, hogy az előoldalon kérné, tegye meg.

Földrajzi és nyelvi részletek, amelyek kifejezetten a mobil oldalakat buktatják el#

A pénznemszimbólumok, dátumformátumok és telefonszám-formátumok geónként eltérőek, és ha rosszul vannak, gyorsabban bizalmatlannak tűnnek kis képernyőn, mint nagyon, mivel a látogatónak kevesebb türelme van egy ismeretlen formátum értelmezésére, miközben az ajánlatot is olvassa. Ha ugyanazt az előoldal sablont futtatja több geo szinten, lokalizálja ezeket a részleteket megfelelően, ahelyett, hogy mindenhol egy geo konvencióját használná alapértelmezésként.

A hálózat által injektált UI kezelése az oldal tetején#

Számos natív hálózat saját elemeket renderel az Ön tartalma köré vagy fölé – egy szponzorált címke, egy bezáró vagy vissza gomb, néha egy natív stílusú komment vagy elköteleződési widget, amelyet a hálózat vezérel. Tervezze az oldalát úgy, hogy feltételezi, hogy ez az átfedés létezik, ahelyett, hogy csak tiszta előnézeti környezetben tesztelne, mivel egy CTA vagy címsor, amely pontosan ott van, ahol a hálózat saját UI eleme renderelődik egy valódi eszközön, gyakorlatilag láthatatlan az olvasó számára. Ellenőrizze, hogy az oldala hogyan néz ki a hálózat valódi feedbeni renderelésében, nem csak önálló URL-ként, mielőtt véglegesíti az elrendezési döntéseket, amelyek a precíz függőleges elhelyezéstől függenek az oldal teteje közelében.

Annak ellenőrzése, ami már működik a mobil-intenzív hálózatokon#

Egyes hálózatok a gyakorlatban mobilabbak, mint mások, és a nyerő előoldal minták ennek megfelelően eltérőek. Az aktuálisan futó kreatívok és a hozzájuk tartozó nyomon követett landolók áttekintése az OpenAdLibrary natív hirdetésfigyelő eszközén megmutatja, hogy milyen formátum- és elrendezési választások élik túl egy adott hálózaton jelenleg, ahelyett, hogy általános mobil UX tanácsokat alkalmazna, amelyek nem veszik figyelembe, hogy egy adott hálózat közönsége hogyan viselkedik. Az MSN Natív hirdetések: A hirdető útmutatója és a Hogyan működnek a Taboola hirdetések mindkettő lefedi a hálózat-specifikus elhelyezést és közönség viselkedést, amelyek táplálják ezeket az elrendezési döntéseket.

A hozzáférhetőség és a konverzió átfedése nagyobb, mint sokan gondolnák#

Megfelelő színkontraszt a szöveg és a háttér között, olvasható betűméretek nagyítás nélkül, és CTA gombok, amelyek többel is megkülönböztethetők, mint a szín, segítenek a gyengénlátó látogatóknak, de segítenek minden olyan látogatónak, aki a telefont erős napfényben vagy egy régebbi, halványabb kijelzőn olvassa. Kezelje az alapvető hozzáférhetőségi gyakorlatot konverziós inputként, nem pedig különálló megfelelőségi jelölőnégyzetként, mivel az a populáció, amelyet segít, sokkal nagyobb, mint az, amelyikre hivatalosan irányul.

A ténylegesen fontos teszt#

Mielőtt élesítene bármilyen mobil előoldal dizájnt, töltse be egy valódi telefonon korlátozott kapcsolaton keresztül, nem csak egy asztali böngésző mobilszimulátorában. A szimulátorok helyesen adják vissza a nézetablakot, de ritkán reprodukálják a valós betöltési időket, az érintési célpontok pontosságát, vagy hogy egy ragadós elem hogyan viselkedik valós görgetési lendület mellett. Öt perc egy valódi eszközön olyan problémákat tár fel, amelyeket hetek asztali iterációja teljesen figyelmen kívül hagy.