Webissä pääasiallinen tulonlähde ovat mainokset. Mainokset palvellaan useimmiten kolmannen osapuolen palvelimelta. Tekniikka jättää paljon toivomisen varaa. Puhtaasti tekniset ongelmat voidaan onneksi aina ratkaista.
Seuraavassa luetellut ongelmat pohjaavat pääasiassa kokemuksiini nykyään AOL:n omistuksessa olevan saksalaisen ADTECHin Helios IQ -tuotteesta, mutta myös muista yleisistä järjestelmistä.
Standardien puute
Bannerit on toteutettu kukin omalla markup-mössöllään. Mainonnanhallintajärjestelmä tarjoaa omia aataminaikaisia templatejaan, mainostoimisto käyttää toisia yhtä kamalia, ja kaikki lataavat omat kiertotapansa IE:n Eolas-ongelmaan ja Flashin selainyhteensopivasti sivulle liittämiseen.
Tarpeettomia HTTP-pyyntöjä
Sen sijaan, että sivun kaikki bannerikoodi noudettaisiin yhdellä HTTP-kutsulla, jokainen banneripaikka kutsuu mainospalvelinta erikseen ja saattaa saada vastaukseksi vain ohjeet noutaa sisältöä ihan toiselta palvelimelta. Aikaa palaa ja selain odottaa vastausta ennen kuin voi aloittaa seuraavan bannerin kutsumisen. (Kuulemma jossain järjestelmässä tämä ongelma on ratkaistu.)
Ylimääräinen riippuvuussuhde
Tänä web-APIen kulta-aikana mainosten integrointi JavaScriptin avulla kuulostaa hätäratkaisulta. Hidasteleva mainospalvelin, tai hidasteleva yhteys mainospalvelimelle hidastaa sivun latautumista. Käyttäjät syyttävät — aivan aiheesta — itse sivustoa hidastelusta, vaikka mainospalvelin olisikin varsinainen syypää. Mikäli “tagi” on sijoitettu viisaasti, hidastelu ei estä sisällön näyttämistä, mutta vaikka tällaiset kiertokeinot toimivat, niitä ei pitäisi joutua käyttämään eikä varsinkaan itse implementoimaan.
Järjestelmä järjestelmälle
Mainoksia ei voi täysin hallita mainonnanhallinnassa, koska järjestelmä ei ajattele kohdesivustoa kokonaisuutena vaan yksittäisinä banneripaikkoina. Paikkojen ja niiden sisältämien tagien hallinnointiin on isolla sivustolla rakennettava oma järjestelmänsä. Ongelma ratkeaisi sillä, että bannerikoodi lukisi sivun (selkokielisen) URLin ja määrittäisi sen ja järjestelmään syötettyjen URL-sääntöjen mukaan sopivan bannerin. Koko hallinnointi kuitenkin selvästi on mainonnanhallintajärjestelmän tehtävä, eikä sitä pitäisi joutua paikkailemaan omilla virityksillä.
Bannerien koko
Mainosbannerien tiedostokoolle on asetettu rajoituksia, mutta aina näitä ei osata tai viitsitä valvoa. Usein ladattavaa kertyy kohtuuttomasti. Fiksu mainonnanhallintajärjestelmä osaa kertoa mainosta syöttävälle, jos tiedoston koko ylittää asetetut rajat, mutta se ei osaa tehdä mitään, jos mainos palvellaankin toisesta järjestelmästä tuoden vain mainos-tagit omaan mainonnanhallintaan.
Koneen jumittavat tehosteet
Minun koneellani se toimi ihan hyvin.
Varmasti, mutta onko se vähän vanhempi kone, pyörikö samalla viisi muuta yhtä raskasta banneria ja yrititkö samalla tehdä jotain muutakin?
Joku voisi joskus laskea, kuinka monta ydinvoimalaa voisi jättää rakentamatta, jos Flash-bannerit kiellettäisiin tai bannerivelhot opetettaisiin tekemään konetehoja vähän vaativaa animaatiota.
Mikä neuvoksi?
Mainonnanhallinta-ala kaipaa kipeästi standardeja ja innovaatiota. IAB:n mainoskoot ja standardit eivät enää riitä. Tarvitaan yleiskäyttöisiä JavaScript-kirjastoja kaistantarpeen minimoimiseksi, yhteensopivia APEja eri järjestelmien ristiinkäyttämisen mahdollistamiseksi, älykkäämpiä mainonnanhallintajärjestelmiä integrointityön minimoimiseksi ja vaikka mitä.
Mainonnanhallinta 2.0, missä viivyt?
One Reply to “Mainonnanhallinta 2.0”
Comments are closed.