Mobiilialoitussivut natiivimainoksille: Suunnittelusäännöt, jotka konvertoivat

Natiivimainosliikenne on valtaosin mobiilia, koska se syntyy sisältösyötteissä, joita ihmiset selaavat puhelimillaan, joten työpöydälle ensin rakennettu ja sitten pienennetty esilaskutussivu menestyy huonommin kuin alusta asti mobiililähtöisesti suunniteltu. Tärkeimmät suunnittelusäännöt ovat sivun paino, peukalolla tavoitettava CTA-sijoittelu, yksipalstainen asettelu ja sen välttäminen, mitä verkoston vaatimustenmukaisuustarkastus pitää interstitiaalina tai pakotettuna vuorovaikutuksena.

Miksi työpöytä-ensin-sitten-sopeuta -lähestymistapa epäonnistuu niin usein#

Tiimit, jotka suunnittelevat esilaskutussivun ensin työpöytämonitorilla, sisällyttävät siihen oletuksia, jotka eivät kestä pienennystä puhelimeen: monipalstaiset asettelut, jotka puristetaan viime hetkellä lukukelvottomaksi yksipalstaiseksi, hero-kuvat, jotka on rajattu leveälle kuvasuhteelle ja menettävät keskipisteensä kapeammalle rajattaessa, sekä CTA-sijoittelu, joka on päätetty sen mukaan, mikä näytti tasapainoiselta suurella näytöllä, eikä sen mukaan, mihin peukalo todella yltää. Mikään näistä ei näy "bugina", jonka huomaisit nopeassa työpöytätarkastuksessa, ne paljastuvat vasta, kun katsot sivua kuten todellinen vierailijasi, minkä vuoksi mobiililähtöinen rakentaminen ensimmäisestä luonnoksesta lähtien ja sitten valinnainen ylöspäin sopeuttaminen työpöydälle tuottaa vähemmän yllätyksiä kuin päinvastainen tapa.

Suunnittele peukalolle, ei hiirelle#

Jokainen tarkkuutta vaativa elementti maksaa konversioita puhelimella. CTA-painikkeiden on oltava riittävän suuria luotettavaa osumaa varten, sijoitettuna sinne, missä peukalo luonnollisesti lepää (näytön ala-keskiosa tai ala-kolmannes toimii paremmin kuin ylös venyttämistä vaativa painike), ja erillään muista napautettavista elementeistä, jotta virheellinen napautus ei lähetä jotakuta sinne, minne et tarkoittanut. Kiinteä CTA-palkki, joka pysyy näkyvissä lukijan vierittäessä pidempää mainosartikkelia, poistaa tarpeen vierittää takaisin ylös, kun lukija on vakuuttunut, ja tämä on sitä tärkeämpää, mitä pidempi sivu on ja mitä enemmän muotoilu nojaa täyteen kertomukseen lyhyen siltasivun sijaan.

Sivun paino on konversiovipu, ei pelkkä tekninen huolenaihe#

Jokainen ylimääräinen lataussekunti mobiiliyhteydessä on mahdollisuus menettää joku, joka klikkasi impulssista sisältösyötteestä eikä kärsivällisyyttä hitaalle sivulle. Pakkaa hero-kuvat aggressiivisesti, vältä automaattisesti toistuvaa videota (joka myös herättää vaatimustenmukaisuustarkastusta useilla verkoilla ja kuluttaa mobiilidataa, johon lukija ei suostunut), viivästä kaikki näytön alapuolinen sisältö ja pidä DOM yksinkertaisena. Tämä kumuloituu verkkotunnus- ja hosting-valintojen kanssa; sivu, joka on hostattu hitaalla, ylikuormitetulla jaetulla palvelimella tai joka reititetään tarpeettoman ylimääräisen uudelleenohjaushypyn kautta, kumoaa hyvän suunnittelutyön ennen kuin yksikään pikseli renderöityy. Hyvä hosting on edellytys hyvälle mobiilisuunnittelulle, ei erillinen huolenaihe, jonka voit korjata myöhemmin.

Asettelu: yksi palsta, pystysuora virtaus, ei sivuttaisia yllätyksiä#

Monipalstaiset asettelut, jotka toimivat työpöydällä, romahtavat tyypillisesti huonosti mobiilissa, ellei niitä ole suunniteltu mobiililähtöisesti. Pysy yhdessä pystysuorassa palstassa: hero-kuva tai otsikkolohko, tukeva teksti lyhyissä kappaleissa, selkeä visuaalinen katkos ennen CTA:ta, sitten joko tarjoussiirtymä tai seuraava sisältölohko. Vältä vaakasuoraa vieritystä kokonaan, se on hämmentävää puhelimella ja harvoin tarkoituksellista, kun sitä tapahtuu.

Mitä välttää, koska verkostot merkitsevät sen#

• Pakotetut interstitiaalit tai ponnahdusikkunat, jotka estävät sisällön ennen aitoa käyttäjän toimintaa. Useimpien natiiviverkkojen toimitukselliset käytännöt pitävät näitä huonona käyttäjäkokemuksena ja yleisenä luovien elementtien hylkäämisen syynä; tarkista kyseisen verkon ajantasainen dokumentaatio ennen minkään interstitiaalikuvion käyttöä.
• Automaattisesti toistuva ääni tai video. Sama perustelu: se yllättää lukijan, kuluttaa heidän dataansa ja herättää tarkastushuomiota.
• Väärennetyt järjestelmän käyttöliittymäelementit (väärennetyt "akku vähissä" -varoitukset, väärennetyt ilmoitusbannerit, väärennetyt sulkemispainikkeet, jotka eivät sulje mitään). Nämä ovat lähellä cloaking-aluetta siinä, miten vaatimustenmukaisuustiimit niitä lukevat, vaikka teknistä cloakingia ei tapahtuisikaan, koska ne harhauttavat lukijaa siitä, mitä he katsovat.
• Tieto haudattu tai piilotettu napautuksen taakse. Sponsorointi- ja mainostietojen on oltava näkyvissä ilman ylimääräistä vuorovaikutusta lukijan puolelta; katso FTC:n tietosäännöt mainosartikkeleille ja natiivimainoksille saadaksesi selville, mitä "näkyvä" tarkoittaa nykyisen ohjeistuksen mukaan.

Typografia ja lukurytmi pienellä näytöllä#

Runko Teksti, joka on miellyttävää lukea työpöytämonitorilla, on usein liian pientä puhelimella, ellei sitä aseteta tarkoituksella mobiilille: riittävän suuri peruskirjasinkoko, jotta lukeminen onnistuu ilman nipistyszoomausta, runsas riviväli ja kappaleet pidettyinä lyhyinä, enintään kolme tai neljä riviä ennen katkoa. Pitkät katkeamattomat kappaleet ovat yksi nopeimmista tavoista menettää mobiililukija kesken sivun, koska ei ole visuaalista lepopaikkaa, joka merkitsisi edistymistä. Jaa pidempi mainosartikkeliteksti alaotsikoilla, lainauslaatikoilla tai asiaankuuluvalla kuvalla muutaman kappaleen välein, sekä vauhdin ylläpitämiseksi että antaaksesi lukijalle syyn jatkaa vierittämistä sen sijaan, että hän poistuisi ensimmäisen teksti-seinän kohdalla.

Kosketuskohteet CTA:n lisäksi#

Ensisijainen CTA saa suunnitteluhuomion, mutta toissijaiset napautettavat elementit ("lue lisää" -linkki, sulkemispainike missä tahansa hylättävässä elementissä, navigointi, jos sivulla on sellaista) tarvitsevat saman peukaloystävällisen koon ja välin. Sulkemispainike, joka on teknisesti olemassa mutta liian pieni luotettavaa napautusta varten, toimii käytännössä olemattomana sulkemispainikkeena ja koetaan turhauttavaksi tai manipuloivaksi lukijalle, joka yrittää hylätä jotain. Applen ja Googlen omat mobiilisuunnitteluohjeet määrittelevät vähimmäiskosketuskoon koot juuri tästä syystä, ja niiden noudattaminen on kohtuullinen perustaso myös natiivialusta-sovellusten ulkopuolella.

Lomakkeet: vähemmän kenttiä, natiivit syöttötyypit#

Jos esilaskutussivu tai sen takana oleva tarjousvaihe kerää tietoja, jokainen lisäkenttä on pudotuskohta mobiilissa, jossa kirjoittaminen on hitaampaa ja virhealttiimpaa kuin työpöydällä. Käytä oikeaa syöttötyyppiä kullekin kentälle (numeronäppäimistö puhelinnumeroille, sähköpostinäppäimistö sähköpostikentille), jotta puhelimen oma näppäimistö auttaa vierailijaa sen sijaan, että pakottaisi heidät etsimään merkkejä yleisnäppäimistöltä. Jos voit siirtää kentän myöhempään suppilon vaiheeseen sen sijaan, että kysyisit sitä itse esilaskutussivulla, tee niin.

Geo- ja kielitiedot, jotka kompastuttavat erityisesti mobiilisivuja#

Valuuttasymbolit, päivämäärämuodot ja puhelinnumeromuodot vaihtelevat geon mukaan, ja niiden virheellisyys vaikuttaa epäluotettavalta nopeammin pienellä näytöllä kuin suurella, jossa vierailijalla on vähemmän kärsivällisyyttä tuntemattoman muodon jäsentämiseen samalla, kun hän yrittää lukea tarjousta. Jos käytät samaa esilaskutussivupohjaa useiden geo-tasojen yli, lokalisoi nämä tiedot oikein sen sijaan, että oletusarvoisesti käyttäisit yhden geon käytäntöjä kaikkialla.

Verkoston injektoiman käyttöliittymän käsittely sivusi päällä#

Useat natiiviverkot renderöivät omia elementtejään sisältösi ympärille tai päälle, sponsoroidun tunnisteen, sulku- tai takaisinpainikkeen, joskus natiivisti tyylitellyn kommentti- tai sitoutumiswidgetin, jota verkko itse hallitsee. Suunnittele sivusi olettaen, että tämä päällekkäisyys on olemassa, sen sijaan että testaisit vain puhtaassa esikatseluympäristössä, koska CTA tai otsikko, joka on sijoitettu juuri sinne, missä verkon oma käyttöliittymäelementti renderöityy oikealla laitteella, on käytännössä näkymätön lukijalle. Tarkista, miltä sivusi todella näyttää verkon todellisessa syötteessä renderöitäessä, ei vain itsenäisenä URL-osoitteena, ennen kuin viimeistelet asettelupäätöksiä, jotka riippuvat tarkasta pystysuorasta sijoittelusta lähellä sivun yläosaa.

Tarkistetaan, mikä jo toimii mobiilipainotteisilla verkoilla#

Jotkut verkot painottuvat käytännössä enemmän mobiiliin kuin toiset, ja voittavat esilaskutussivumallit eroavat vastaavasti. Tarkastelemalla aktiivisia, tällä hetkellä käynnissä olevia luovia elementtejä ja niiden jäljitettyjä esilaskutussivuja OpenAdLibraryn natiivimainosvakoilutyökalussa näet, mitkä muoto- ja asetteluvalinnat todella selviävät tietyllä verkolla juuri nyt, sen sijaan että soveltaisit yleisiä mobiilikäyttäjäkokemusneuvoja, jotka eivät ota huomioon, miten tietyn verkon yleisö käyttäytyy. MSN Natiivimainokset: Mainostajan opas ja Kuinka Taboola-mainokset toimivat käsittelevät molemmat verkostokohtaisia sijoitteluja ja yleisön käyttäytymistä, jotka vaikuttavat näihin asettelupäätöksiin.

Saavutettavuus limittyy konversion kanssa enemmän kuin ihmiset odottavat#

Riittävä värikontrasti tekstin ja taustan välillä, luettavat kirjasinkoot ilman zoomausta ja CTA-painikkeet, jotka ovat erotettavissa muullakin kuin pelkällä värillä, auttavat kaikkia heikkonäköisiä vierailijoita, mutta ne auttavat myös jokaista vierailijaa, joka lukee puhelimen näyttöä ulkona kirkkaassa auringonvalossa tai vanhemmalla, himmeämmällä näytöllä. Kohtele perussaatavuuskäytäntöä konversion syötteenä, ei erillisenä vaatimustenmukaisuuden valintaruutuna, koska väestö, jota se auttaa, on paljon suurempi kuin se väestö, jolle se on virallisesti tarkoitettu.

Testi, joka todella merkitsee#

Ennen kuin julkaiset minkä tahansa mobiilin esilaskutussivun suunnittelun, lataa se oikealla puhelimella rajoitetun yhteyden kautta, ei vain työpöytäselaimen mobiiliemulaattorissa. Emulaattorit saavat näkymäkoon oikein, mutta ne harvoin toistavat todellisia latausaikoja, napautuskohteen tarkkuutta tai sitä, miten kiinteä elementti käyttäytyy todellisessa vieritysvauhdissa. Viisi minuuttia oikealla laitteella havaitsee ongelmia, jotka viikkojen työpöytäpohjainen iterointi jättää täysin huomiotta.