10 viga, mida ettevõtjad veebilehe tellimisel teevad

Vaid umbes 31% tehnoloogiaprojektidest valmib tähtajaks, eelarve piires ja kokkulepitud mahus. Enamik põhjuseid tekib enne esimest koodirida — kümme kõige sagedasemat viga veebilehe tellimisel ja see, kuidas neid vältida.

Veebilehe arendus on üks neid investeeringuid, mis kas kiirendab ettevõtte kasvu märgatavalt või kujuneb kalliks ja frustreerivaks kogemuseks, mille tulemus jääb ootustele alla, ületab eelarve ja vajab juba mõne kuu pärast ümbertegemist. Valdkonna statistika on tõsine hoiatus — vaid umbes 31% tehnoloogiaprojektidest valmib tähtajaks, eelarve piires ja algselt kokku lepitud mahus. Veebilehe arendusprojektid ei ole selles osas erand, sest veebiarendus kuulub sama statistika alla: ülejäänud projektid, ligikaudu kaks kolmandikku, liigitatakse kas „ohustatuks“ (eelarve või tähtaja ületamine, vähendatud maht) või ebaõnnestunuks. Enamik neist ebaõnnestumistest ei tulene siiski tehnoloogia puudustest ega arendajate oskamatusest — need on inimlike ja organisatsiooniliste tegurite tagajärg, mis tekivad juba enne esimese koodirea kirjutamist. Need on täielikult välditavad, kui tellija teab, milliseid vigu kõige sagedamini tehakse ja kuidas neid ära hoida.

Selles artiklis vaatame kümmet kõige sagedasemat viga, mida ettevõtjad ja organisatsioonid veebilehe tellimisel teevad, ning selgitame iga vea puhul, miks see tekib, mida see kaasa toob ja mida te saate selle vältimiseks teha.

1. Otsustamine ainult hinna järgi

See on ilmselt kõige sagedasem ja kõige kallim viga veebilehe tellimisel — tellija võrdleb mitut pakkumist ja valib odavaima, eeldades, et veebileht on veebileht sõltumata sellest, kes selle teeb, ning et 500 euro ja 5000 euro suuruse pakkumise vahe on üksnes arendaja kasumimarginaal. Tegelikkuses peegeldab see vahe peaaegu alati põhimõttelisi erinevusi arenduse kvaliteedis, koodi puhtuses, turvalisuse tasemes, skaleeritavuses ja müügijärgses toes. Odavaim pakkumine osutub pikas plaanis sageli kõige kallimaks lahenduseks, sest halva kvaliteediga kood tekitab niinimetatud „tehnilise võla“ — probleemide kuhjumise, mis nõuab pidevat parandamist, piirab veebilehe edasiarendamist ja sunnib lõpuks kõike nullist uuesti ehitama.

Odavad pakkumised varjavad sageli märkimisväärseid riske: arendaja võib kasutada tasuta või piraatteemasid, mis sisaldavad turvanõrkusi või varjatud pahatahtlikku koodi; kood võib olla optimeerimata ja struktureerimata, mis teeb hilisema hoolduse ja täiendamise keeruliseks ning kalliks; testimine võib jääda puudulikuks, mistõttu vead tulevad välja alles pärast avaldamist; müügijärgne tugi võib olla minimaalne või olematu, jättes teid abita just siis, kui seda kõige rohkem vajate. Õige lähenemine on hinnata pakkumisi mitte hinna, vaid väärtuse järgi — uurige arendaja portfelli, rääkige varasemate klientidega, kontrollige nende tehtud veebilehtede tehnilist kvaliteeti ja tehke selgeks, mis täpselt on hinna sees ja mis mitte. Sageli ei sisalda „odav“ pakkumine seda, mis „kallis“ pakkumises on iseenesestmõistetav: responsiivset kujundust, SEO baasoptimeerimist, turvaseadistust või veebilehe sisutoimetajate koolitust.

2. Ebaselgelt määratletud nõuded ja eesmärgid

Teine kõige sagedasem viga on projekti alustamine ilma selgelt määratletud nõuete, eesmärkide ja oodatavate tulemusteta — tellija pöördub arendaja poole ja ütleb midagi sellist nagu „mul on vaja kaasaegset ja professionaalset veebilehte“, oskamata öelda, milliseid funktsioone veebileht vajab, kes on sihtrühm, milliseid tegevusi külastajad seal tegema peaksid ja kuidas veebilehe edukust mõõdetakse. Selline ebamäärasus jätab arendajale üle vaid oletada, mida klient soovib, ja need oletused osutuvad sageli valeks. Tulemuseks on pettumus mõlemal poolel ja juba tehtud töö ümbertegemine, mis kulutab lisaaega ja -raha. Just ebamäärasus on mahu paisumise (scope creep) peamine käivitaja — nähtus, mis puudutab enam kui poolt kõigist valdkonna projektidest ja tähendab, et projekti käigus lisandub pidevalt uusi funktsioone ja nõudeid, mida esialgses plaanis ei olnud, kasvatades kulusid 10% kuni 25% ja pikendades sageli ka arendustähtaegu märgatavalt.

Lahendus on panustada aega ja tööd eeluuringufaasi (discovery phase) enne mis tahes arenduse alustamist — selles etapis määratakse konkreetsed ärieesmärgid (näiteks suurendada päringute arvu 30%, viia põrkemäär alla 40%, saavutada keskmine sessiooni kestus üle 3 minuti), luuakse kasutajapersoonad, kaardistatakse kasutajateekonnad, pannakse paika veebilehe struktuur ja funktsionaalsed nõuded ning koostatakse üksikasjalik lähteülesanne, mis on kogu projekti vältel viitedokumendiks. Selline dokument kaitseb mõlemat poolt: tellija teab, mida ta oma raha eest saab, arendaja teab, mida temalt oodatakse, ja iga muudatus, mis väljub dokumendis kokku lepitud mahust, vormistatakse lisatööna eraldi eelarve ja tähtaegadega.

3. Disaini ülehindamine ja tehnika alahindamine

Kolmas viga on ettevõtjate seas eriti levinud: kogu tähelepanu läheb visuaalsele disainile, tehniline pool jäetakse aga kõrvale või alahinnatakse. Arendaja valitakse üksnes selle järgi, kui kaunid näevad välja tema portfoolio veebilehed, ilma et küsitaks koodi kvaliteedi, saidi kiiruse, turvatavade, skaleeritavuse või otsingumootorioptimeerimise kohta. Visuaalne disain ja tehniline arendus on kaks eri distsipliini. Kaunis veebileht, mis laadib kümme sekundit, on rünnakute ees haavatav ja otsingumootoritest leidmatu — see on palju vähem väärt kui visuaalselt lihtsam sait, mis on kiire, turvaline ja hästi optimeeritud.

Uuringud näitavad järjekindlalt, et 53% mobiilikasutajatest lahkub saidilt, mille laadimine kestab üle kolme sekundi. Ka ühesekundiline viivitus lehe laadimisel võib konversioone märgatavalt vähendada: Akamai ja SOASTA uuringu järgi langetab juba 100 millisekundi pikkune viivitus konversioonimäära kuni 7%. Need arvud tähendavad, et saidi jõudlus mõjutab otseselt teie tulu, ja ükski kaunis disain ei korva tehnilise teostuse vigu. Õige lähenemine on hinnata arendajat mitte ainult tema tööde välimuse, vaid ka selle järgi, kui hästi ta oskab oma tehnilist lähenemist selgitada — millist arhitektuuri ta kasutab, kuidas ta tagab saidi kiiruse, kuidas ta läheneb turvaküsimustele ja kuidas ta kavandab saidi skaleerimist, kui ettevõte kasvab ja nõuded muutuvad.

4. SEO jätmine "hiljemaks"

Ettevõtjad peavad otsingumootorioptimeerimist väga sageli millekski, mille saab veebilehele lisada pärast selle valmimist — umbes nagu seinte värvimine pärast maja püstitamist. Tegelikult on tehniline SEO saidi arhitektuuri põhiosa ning selle sissetoomine pärast avalikustamist on tunduvalt kallim, keerukam ja vähem tõhus kui arvestamine sellega juba arenduse algusest peale. URL-i struktuur, lehtede hierarhia, siselinkide arhitektuur, pealkirjade struktuur, struktureeritud andmete märgistus (schema markup), piltide optimeerimine, Core Web Vitalsi mõõdikud ja mobiilikasutuskogemus — kõik need on arenduse käigus palju lihtsam ja odavam korrektselt paika panna kui valmis saidil ümber teha.

Google kasutab mobiiliversiooni eelisindekseerimist (mobile-first indexing): teie sisu hindab ja järjestab Google just saidi mobiiliversiooni järgi. Kui mobiilikogemus on kehv, kannatavad teie positsioonid otsingutulemustes olenemata sellest, kui hea on arvutiversioon. Statista andmetel ulatus mobiilikaubandus 2024. aastal ligikaudu 2,07 triljoni dollarini ning Google'i andmed näitavad, et aastatel 2015–2017 kasvasid ostusooviga mobiiliotsingud fraasiga "minu lähedal" (near me) enam kui viiekordseks. Mobiilioptimeerimine ei ole lihtsalt "tore lisavõimalus", vaid ärivajadus — eriti kohalikele ettevõtetele, kes soovivad kliente oma piirkonnast. Õige lähenemine on kirjutada SEO-nõuded juba hankedokumenti (RFP) arenduse kohustusliku osana, mitte eraldi lisatasu eest ostetava teenusena. Konkreetselt tähendab see, et arendaja peab algusest peale kavandama SEO-sõbraliku URL-i struktuuri, tagama korrektse pealkirjahierarhia (H1, H2, H3), rakendama struktureeritud andmed (schema markup), optimeerima pildid alt-tekstide ja nüüdisaegsete vormingutega, seadistama XML-i saidikaardi ja robots.txt-faili ning tagama, et saidi kiirus vastab Core Web Vitalsi standarditele. Valmis saidil võivad samad muudatused nõuda arhitektuuri põhjalikku ümberehitust.

5. Sisuloome eiramine või selle jätmine viimasele hetkele

Viies viga on üks sagedasemaid põhjusi, miks veebiarendusprojektid venivad: ettevõtjad arvavad, et sisu saab viimasel hetkel "kiiresti kokku kirjutada", ja suunavad kogu tähelepanu disainile ning funktsionaalsusele, samal ajal kui tekstid, pildid ja muud sisuelemendid jäävad kuni projekti lõpuni valmimata. Probleem on selles, et disain ehitatakse sisu ümber, mitte vastupidi. Kui sisu pole valmis, on disainer sunnitud töötama täitetekstiga (lorem ipsum), mistõttu disain ei vasta tegeliku sisu mahule ega struktuurile. Kui päris tekst lõpuks sisse pannakse, võib välimus järsult muutuda — ja mitte paremuse poole.

Sisu valmimise viibimine on üks sagedamini nimetatud projektide venimise põhjuseid ja see on loogiline: kvaliteetne sisu nõuab aega. Tekstid tuleb kirjutada, ettevõtte tooni ja sõnumiga kooskõlla viia ning SEO jaoks optimeerida; pildid tuleb valida või luua nii, et need vastaksid brändi identiteedile ja disaininõuetele. Õige on käsitleda sisuloomet projekti kriitilise tähtsusega etapina, millel on omad tähtajad ja vastutajad ning mis algab paralleelselt disainitööga või koguni enne seda — mitte lisaülesandena, mis tehakse ära „siis, kui aega jääb“. Kui ettevõttel oma inimesi sisu loomiseks ei ole, tuleb see projekti eelarves eraldi reana arvestada ja kaasata professionaalne tekstikirjutaja või sisuspetsialist.

6. Planeerimata hooldus pärast avaldamist

Kuues viga puudutab otseselt hooldust, mida käsitlesime juba artiklis häkitud veebilehtede taastamisest. Paljud ettevõtjad peavad veebilehte ühekordseks tooteks, mis pärast valmimist lihtsalt „töötab“, ega mõtle sellele, mis juhtub pärast avaldamist — kui on vaja turvauuendusi, sisumuudatusi, veaparandusi, jõudluse optimeerimist ja ühilduvust uute brauseriversioonide ja seadmetega. Selline lähenemine on ohtlik, sest hooldamata veebileht on kaitseta veebileht. Sucuri andmetel töötas üle poole häkitud CMS-veebilehtedest nakatumise hetkel aegunud tarkvaraversiooniga, ja laialt tsiteeritud, enam kui kümne aasta vanune Sophose hinnang räägib ligikaudu 30 000 uuest veebilehest päevas, kust leitakse pahatahtlik kood.

Hooldusega tuleb tegeleda juba projekti planeerimise etapis, mitte pärast veebilehe avaldamist, sest see mõjutab nii tehnoloogiavalikut (mõnda platvormi on lihtsam hooldada kui teist), eelarve planeerimist (hoolduskulud tuleb arvestada veebilehe kogu elutsükli eelarvesse) kui ka arendaja valikut (tuleb välja selgitada, kas arendaja pakub ka hooldusteenust ja millistel tingimustel). Ideaalis lisatakse juba lepingusse müügijärgse toe kokkulepe (SLA – Service Level Agreement), mis määrab, millised hooldustööd tehakse, kui sageli, milline on probleemide korral reageerimisaeg ja mis see teenus maksab.

7. Domeeni ja majutuse kontrolli andmine arendajale

Seitsmes viga on üks raskeimate pikaajaliste tagajärgedega vigu ja ometi tehakse seda üllatavalt sageli: ettevõtja laseb arendajal registreerida domeeninime ja osta majutusteenuse arendaja, mitte ettevõtte nimele, kaotades nii kontrolli oma ärikriitiliste digitaalsete varade üle. Kui koostöö arendajaga mingil põhjusel lõpeb — olgu sõbralikult või tüli tagajärjel — võib ettevõtja sattuda olukorda, kus ta ei pääse oma domeenile ligi ega saa veebilehte teise serverisse kolida, või kaotab domeeninime hoopis sootuks, kui arendaja registreeringut ei pikenda.

Domeeninimi ja majutuskonto on teie ettevõtte digitaalsed varad ning need peavad kuuluma teile ja olema teie kontrolli all, samamoodi nagu ettevõtte juriidiline aadress või kaubamärk. Te ei laseks raamatupidajal registreerida ettevõtte juriidilist aadressi tema enda nimele ja samal põhjusel ei tohiks lasta arendajal kontrollida teie digitaalset identiteeti. Õige on registreerida domeeninimi ise usaldusväärse registripidaja juures, osta majutus oma ettevõtte nimele või rentida see partnerilt, kes annab nõudmisel üle konfiguratsiooni ja andmed ning anda arendajale ainult tehniline ligipääs, mida veebilehe ehitamiseks ja ülesseadmiseks vaja läheb, mitte haldusõigused nende ressursside üle. Sama kehtib Google Search Console'i, Google Analyticsi ja teiste analüütika- ning turunduskontode kohta — need tuleb luua ettevõtte nimele ja arendajale antakse piiratud õigustega ligipääs.

8. Testimise ja kvaliteedi tagamise eiramine

Kaheksas viga puudutab testimist: paljud ettevõtjad ei pööra testimisele piisavalt tähelepanu ja võtavad veebilehe vastu ilma põhjaliku kontrollita, uskudes arendaja kinnitust, et "kõik töötab". Tegelikkuses on korralik testimine keeruline ja ajamahukas töö, mis hõlmab palju enamat kui lehitsemist ja paari nupu vajutamist. Puudulik kvaliteedikontroll on üks sagedasemaid põhjuseid, miks veebilehtedel ilmnevad pärast käivitamist vead, mis mõjutavad kasutajakogemust, konversiooni ja isegi turvalisust. Valmis veebilehel on nende parandamine alati kallim ja keerulisem kui siis, kui probleemid oleks avastatud ja kõrvaldatud juba arenduse käigus.

Testimine peaks katma mitut mõõdet. Funktsionaalne testimine kontrollib, kas kõik veebilehe funktsioonid töötavad korrektselt — vormid, otsing, navigatsioon, kasutajate registreerimine, ostukorvi- ja makseprotsess, sisu filtreerimine ja sortimine. Ühilduvustestimine kontrollib, kas veebileht töötab õigesti eri brauserites (Chrome, Firefox, Safari, Edge), operatsioonisüsteemides ja seadmetes (lauaarvutid, tahvelarvutid, erineva ekraanisuurusega nutitelefonid). Jõudlustestimine hindab lehe laadimiskiirust, vastuseaegu ja käitumist koormuse all. Turvatestimine tuvastab võimalikud turvanõrkused, näiteks SQL-i süstimise, XSS-rünnakute võimalused ja vale juurdepääsukontrolli. Ligipääsetavuse testimine kontrollib, kas veebileht on kasutatav ka erinevate puuetega inimestele, vastavalt WCAG standarditele.

Õige lähenemine on näha testimisetapp koos selgelt määratletud vastuvõtukriteeriumidega ette juba lepingus — see tähendab, et dokumenteeritud on, mida täpselt testitakse, millised tulemused on vastuvõetavad ja milline on kord juhul, kui testimine toob probleeme päevavalgele. Ettevõtjal tasub vastuvõtutestimine teha ka ise või sõltumatu spetsialisti abiga, mitte tugineda täielikult arendaja enesehinnangule: arendaja, kes testib omaenda tööd, on nagu õpilane, kes parandab ise oma eksamitööd.

9. Otsuste langetamine komitees ilma ühe vastutajata

Üheksas viga on organisatsiooniline ja iseloomulik eeskätt suurematele ettevõtetele ja organisatsioonidele, kus veebilehe arendusprojekti on kaasatud mitu otsustajat — turundusosakond, müügimeeskond, juhtkond, IT-osakond ja mõnikord isegi juristid — ning igaüks neist osaleb kujunduse ja sisu kinnitamises võrdse hääleõigusega. Selline "komiteedisaini" lähenemine viib peaaegu alati kompromissidest koosneva tulemuseni, mis ei rahulda kedagi: iga otsustaja püüab veebilehele suruda omaenda prioriteete ja soove ning lõpptulemus muutub ülekuhjatuks, ebajärjekindlaks ja ärieesmärkidest lahknevaks.

Uuringud ja valdkonna kogemus näitavad järjekindlalt, et projektid, kus on üks selgelt määratud otsustaja volitusega kujundus, sisu ja funktsionaalsus kinnitada, valmivad kiiremini, püsivad sagedamini eelarves ja annavad paremaid tulemusi kui need, kus otsuseid langetab grupp. See ei tähenda, et teiste kaasatud osapoolte arvamus poleks tähtis — see tähendab, et vaja on selget protsessi, kus kõik osapooled saavad oma seisukoha välja öelda ja tagasisidet anda, kuid lõpliku otsuse teeb üks inimene, kes on selleks volitatud ja vastutab projekti tulemuse eest. RACI-maatriks (Responsible, Accountable, Consulted, Informed) on tõhus tööriist sellise protsessi ülesehitamiseks — see määratleb selgelt, kes vastutab töö tegemise eest, kes on lõplik otsustaja, kellega tuleb nõu pidada ja keda tuleb otsustest teavitada.

10. Intellektuaalomandi ja lepinguliste küsimuste eiramine

Kümnes viga puudutab juriidilist poolt, mida paljud ettevõtjad — eriti väiksemate ettevõtete omanikud — kipuvad eirama või pidama tarbetuks bürokraatiaks: nad alustavad arendajaga koostööd ilma ametliku lepinguta, ilma selgelt määratletud intellektuaalomandi õigusteta ja ilma konfidentsiaalsuslepinguta (NDA), mis võib tekitada tõsiseid probleeme nii projekti ajal kui ka pärast selle lõppu. Selgelt määratletud intellektuaalomandi õigusteta võib ettevõtja sattuda olukorda, kus lähtekood, mille eest ta on maksnud, talle tegelikult ei kuulu, ning arendaja võib sama koodi kasutada teiste klientide juures või isegi keelduda lähtekoodi üleandmisest, kui koostöö enne tähtaega katkeb.

Leping peab selgelt sätestama, et kogu arenduse käigus loodud intellektuaalomand — lähtekood, disainifailid, graafika, andmestruktuurid ja dokumentatsioon — kuulub pärast täieliku tasu laekumist tellijale ning arendajal ei ole õigust seda ilma tellija nõusolekuta muul otstarbel kasutada. Samuti peab leping määrama projekti mahu, tähtajad, maksegraafiku (soovitatavalt seotud vaheetappide valmimisega, mitte ajakuluga), garantiiperioodi, konfidentsiaalsustingimused ja vaidluste lahendamise korra. Kindlate, kinnitatud vaheetappidega seotud maksed (milestone-based payments) motiveerivad arendajat tähtaegadest kinni pidama, mitte lihtsalt ajaperioodiga seotud maksed, ja tagavad, et ettevõtja maksab üksnes tegelikult tehtud töö eest, mitte määramata ajakulu eest; suuremate ja ebastandardsete projektide puhul sobib ka aja- ja materjalikulu põhine mudel nädalase ülempiiriga, kui maht ja ülempiir on kirjalikult fikseeritud.

Konfidentsiaalsusleping (NDA) on eriti oluline siis, kui arendajale avaldatakse töö käigus tundlikku äriteavet — kliendiandmeid, äriprotsesse, hinnapoliitikat või muud konfidentsiaalset teavet, mis konkurendi kätte sattudes võib teie ärile kahju teha. Paljud ettevõtjad peavad NDA-d suurkorporatsioonide tööriistaks, kuid tegelikult on see sama tähtis igale ettevõttele, kes jagab tundlikku teavet väliste partneritega. Pealegi toimib selgete vaheetappide ja vastuvõtukriteeriumidega hästi struktureeritud leping ka projektijuhtimise vahendina — see tagab, et mõlemad pooled on ühel meelel selles, mida tehakse, millal see valmib ja millist tulemust igas etapis oodatakse, ning vähendab märgatavalt arusaamatuste ja konfliktide riski projekti käigus.

Täiendavad vead, mida tasub mainida

Kuigi kirjeldasime kümmet peamist viga, väärib eraldi mainimist veel mitu sagedast puudujääki, sest need võivad veebiarendusprojekti edukust oluliselt mõjutada. Üks neist on liigne toetumine arendaja arvamusele kõigis küsimustes, sealhulgas äristrateegias. Arendaja on tehnoloogiaekspert, kuid ta mõistab teie ärispetsiifikat, sihtrühma ja turudünaamikat harva sama hästi kui teie ise, ning kui delegeerite kõik otsused täielikult arendajale, riskite tehniliselt korraliku, kuid ärilises mõttes ebatõhusa veebilehega.

Teine sage viga on ligipääsetavuse (accessibility) eiramine. Paljud ettevõtjad ei teadvusta endale, et nende veebileht peab olema kasutatav ka erivajadustega inimestele ja et paljudes jurisdiktsioonides on see seadusest tulenev nõue, mitte lihtsalt hea tava. Ligipääsetavuse tagamine juba arenduse käigus on tunduvalt lihtsam ja odavam kui selle lisamine valmis veebilehele, ning see laiendab teie potentsiaalset auditooriumi: ligikaudu 16% maailma elanikest — 1,3 miljardit inimest — elab märkimisväärse puudega.

Kolmas täiendav viga on analüütika ja konversioonide jälgimise juurutamata jätmine. Paljud veebilehed lähevad käiku ilma Google Analyticsi, Google Search Console'i või muude analüütikatööriistade seadistamiseta, mis tähendab, et ettevõtja ei saa hinnata veebilehe tulemuslikkust, tuvastada probleeme ega teha andmepõhiseid otsuseid edasise optimeerimise kohta. Analüütika juurutamine tuleb kirjutada arendusprojekti mahtu kohustusliku nõudena, mitte jätta millekski, mille "teeme hiljem". Ilma analüütikaandmeteta tegutsete sisuliselt pimesi — te ei tea, kui palju külastajaid teie veebileht toob, kust nad tulevad, milliseid lehti nad vaatavad, kus toimub väljalangemine ja kas teie veebileht üldse täidab oma ärilist funktsiooni.

Neljas mainimist vääriv täiendav viga on veebilehe õigusliku vastavuse tagamata jätmine. Paljud uued veebilehed lähevad käiku ilma privaatsuspoliitikata, küpsiseteavituseta, kasutustingimusteta või muude juriidiliste dokumentideta, mis on GDPR-i ja teiste kohalduvate õigusaktide järgi kohustuslikud, ning selline hooletus võib kaasa tuua tõsiseid õiguslikke tagajärgi, sealhulgas trahve kuni 20 miljonit eurot või 4% ettevõtte ülemaailmsest kogu aastakäibest — olenevalt sellest, kumb summa on suurem. Õiguslik vastavus ei ole üksnes formaalne nõue — see on ka usaldussignaal teie külastajatele, mis näitab, et suhtute nende andmekaitsesse ja privaatsusse tõsiselt, ning tänapäeva tarbijad pööravad üha enam tähelepanu sellele, kuidas ettevõtted nende isikuandmeid töötlevad.