Web-reklámfelület menedzseralkalmazás

MISKOLCI EGYETEM GÉPÉSZMÉRNÖKI ÉS INFORMATIKAI KAR

MISKOLCI EGYETEM GÉPÉSZMÉRNÖKI ÉS INFORMATIKAI KAR

VILLAMOSMÉRNÖKI INTÉZET AUTOMATIZÁLÁSI ÉS INFOKOMMUNIKÁCIÓS INTÉZETI TANSZÉK

ÁLTALÁNOS INFORMATIKAI TANSZÉK

Web-reklámfelület menedzseralkalmazás Szakdolgozat

Jónás Gergely ST6PTA 3240 Parád Ifjúság utca 17.

Köszönetnyilvánítás

Szeretném megköszönni Dr. Krizsán Zoltánnak, hogy a dolgozatom elkészítése során végig támogatott és rengeteg tanáccsal és nagy türelemmel segítette a munkámat. Továbbá szeretném megköszönni a PRIM11 Kft. –nej, hogy lehetőséget biztosított, a cégnél készített rendszer bemutatására a dolgozatomban.

Web-reklámfelület menedzseralkalmazás

Tartalomjegyzék 1.

Bevezetés ........................................................................................................................ 1

2.

Hirdetések az interneten, piackutatás ........................................................................... 3 2.1. E-mail alapú hirdetések, reklámok ......................................................................... 3 2.1.1. Reklámkampány bérelt listára......................................................................................................... 4 2.1.2. Promóció saját adatbázisra .............................................................................................................. 4 2.1.3. Vásárolt listák ................................................................................................................................. 4 2.1.4. Partnerségi kapcsolatok .................................................................................................................. 4 2.1.5. Direkt e-mail ................................................................................................................................... 4 2.1.6. Autoresponderek ............................................................................................................................. 4

2.2. Webes felületekre épülő hirdetések, reklámok ...................................................... 5 2.2.1. Felugró ablak (pop-up és pop-under) .............................................................................................. 5 2.2.2. Közbülső banner ............................................................................................................................. 5 2.2.3. Hirdetés térképen ............................................................................................................................ 5 2.2.4. Lebegő reklám ................................................................................................................................ 5 2.2.5. Háttérkép reklám ............................................................................................................................ 5 2.2.6. Banner ............................................................................................................................................. 6

2.3. Reklám menedzser rendszerek ................................................................................ 6 2.3.1. Telebanner ...................................................................................................................................... 6 2.3.2. Bannerhirdetések ............................................................................................................................ 7 2.3.3. Google AdSense és AdWords .......................................................................................................... 7

3. Use case diagram .............................................................................................................. 9 3.1. Aktorok ...................................................................................................................... 9 3.2. Use case-k aktoronként .......................................................................................... 10 3.2.1. Látogató ........................................................................................................................................ 10 3.2.2. Tag ................................................................................................................................................ 10 3.2.3. Admin ........................................................................................................................................... 11

3.3. Use case-k leírása .................................................................................................... 12 4. Felhasználói felület tervezése ......................................................................................... 20 5. Fejlesztőeszköz bemutatása ............................................................................................ 27 6. Megvalósítás.................................................................................................................... 31 6.1. Regisztráció ............................................................................................................. 31

I

Web-reklámfelület menedzseralkalmazás 6.2. Céges adatok módosítása........................................................................................ 31 6.3. Partnerek címeinek kezelése .................................................................................. 32 6.4. Hirdetési felület felvitele, módosítása .................................................................... 32 6.5. Hirdetési felületekre vonatkozó trigger ................................................................ 32 6.6. Legjobbkep ............................................................................................................... 33 6.7. Hirdetés felvitele, módosítása ................................................................................ 33 6.8. Megrendel ................................................................................................................ 33 6.9. Megrend táblára vonatkozó trigger ....................................................................... 34 6.10. Megrendelés kérelmezése ..................................................................................... 35 6.11. Megrendelés elfogadása ........................................................................................ 35 6.12. Megrendelés forgalomaktualizálása .................................................................... 35 6.13. Hird_forg tábla töltése .......................................................................................... 36 6.14. Hirdetési felület statisztikáját készítő eljárás ..................................................... 37 6.15. Hirdetés statisztikáját készítő eljárás ................................................................. 38 6.16. Összes és külön-külön hirdetésre és hirdetési felületre vonatkozó statisztika felhasználónként............................................................................................................. 39 6.17. Megjelenések és kattintások számolása .............................................................. 39 7. Az elkészült alkalmazás bemutatása, élő képek mutatása ............................................. 41 7.1. Nyitó képernyő és regisztráció ............................................................................... 41 7.2. Hirdetési felület felvitele ......................................................................................... 43 7.3. Hirdetés felvitele ..................................................................................................... 45 7.4. A megrendelések folyamata ................................................................................... 46 Összefoglalás ....................................................................................................................... 52 Summary ............................................................................................................................. 54 Irodalomjegyzék .................................................................................................................. 56 Melléklet .............................................................................................................................. 57

II


1. Bevezetés A reklámok, a reklámozás nemcsak napjaink, hanem már időtlen idők óta fontos tényező mind az ember mind az állatvilágban is. Gondoljunk csak bele, hogy az állatok is sok esetben „reklámozzák” magukat párválasztás, szaporodás előtt, mikor erejüket, képességeiket firtatják, annak érdekében, hogy az ellenkező nemű egyednek felkeltsék érdeklődését. Az emberek nemcsak ilyen esetekben akarják embertársaik érdeklődését felkelteni, hanem ha valamilyen tárgyat, szellemi terméket szeretnének eladni, használatára rávenni esetleg meggyőzni annak nagyszerűségéről. A reklámokon keresztül értesülhetünk, olyan dolgokról, melyekről eddig nem tudtunk, hogy létezik, esetleg tudhatjuk meg annak pozitív oldalait, ha korábban már találkoztunk vele, viszont mégsem nyerte el tetszésünket, valamilyen oknál fogva. Manapság akármerre járunk, reklámokba botlunk, így például a boltokban, az utcán, a televízióban, különféle rendezvényeken, internetezés közben stb. A reklámok, a kommunikáció egyik nagyon fontos eleme, ugyanis így juttatunk el információt mások számára. A technika fejlődésével, újabb és újabb területek jelentek meg a reklámozás világában, mint a rádiós, televíziós és az interneten fellelhető reklámok egészítették ki a korábban megszokott hirdetőtáblákat, szórólapokat, stb. Az internet rohamos térhódításával, a mára már megszámlálhatatlan weboldalakon fellelhető hirdetési felületekből, jött az ötlet a PRIM11 Kft-nél, egy olyan oldal létrehozására, ahol mind az interneten hirdetési felületekkel rendelkező, mind az interneten hirdetni vágyó meg találja a neki megfelelő igényeit. Az ötlet megfogalmazásakor fontos szempont volt, hogy ne csak találomra választhassa ki a felhasználó, hogy hol szeretne hirdetni, hanem a választást megkönnyítsék az előzetes statisztikák, mint például az előző hirdetésre vonatkozó információk, hogy hányszor jelent meg a kiválasztott oldalon a hirdetés, hány IP címről, hányszor kattintottak rá különböző intervallumokra lebontva. Mivel a különböző oldalaknak különböző a látogatottsága és az sem mindegy, hogy a hirdetés hol jelenik meg egy adott oldalon belül, úgymond mennyire van szem előtt, ezért úgy gondoltuk, hogy a hirdetési felülettel rendelkező felhasználó szabhassa meg mennyi „kreditbe” kerül egy megjelenés a nála hirdetni vágyónak, az adott helyen. További szempont volt még, hogy a médiatulajdonos oldalán ne akármilyen hirdetés jelenhessen meg, hanem a különböző beállításoktól függően ezt ő határozhassa meg. Gondoltunk a kampányszerűen hirdetni vágyó felhasználókra is, miszerint különböző 1

Web-reklámfelület menedzseralkalmazás csoportokat lehet létrehozni, ezáltal meggyorsítva az impulzusszerű marketinget, valamint a részletes keresés biztosítása a hirdetési felületek között is fontos szempont volt. A megjelenésekért járó kreditetek később felhasználhatja a médiatulajdonos saját hirdetéseinek megjelenítésére, vagy kérheti ezek átváltását valódi valutára, melyet így akár ki is utalhat bankszámlájára. Szakdolgozatomban megvizsgálok különböző rendszereket, melyek hasonlóan webes banner elhelyezésre vannak specializálódva. Röviden ismertetem ezen rendszerek működését, előnyeit, hátrányait. Bemutatom a PRIM11 Kft. –nél fejleszett webreklámfelület menedzser alkalmazás funkcióit use case diagram segítségével. A rendszerhez kapcsolódó felhasználói felület tervezését követően, ismertetem az alkalamazott fejlesztőeszközt. A tervezett rendszert implementálom, majd bemutatom annak működését.

2


Hirdetések az interneten, piackutatás Manapság már rengeteg oldal létezik, melyek hirdetések elhelyezésére vannak specializálódva. Ez nem véletlen, ugyanis felismerték, hogy az internet napjaink egyik leghatékonyabb hirdetési lehetősége, ugyanis az elmúlt években rohamosan megnőtt az internet felhasználók száma. 1995 decemberében, körülbelül ~16 millió ember használta az internetet az egész világon. Ez az akkori népesség 0,4%-a volt. 2005 decemberében, már több mint 1 milliárd felhasználója volt az internetnek, ami az akkori népesség ~15,7%-a volt. Mára hozzávetőlegesen 3 milliárd ember használja az internet adta lehetőségeket, ez a népesség ~ 40-41%-a. [1] Az internet felhasználók számának növekedésével megnőtt az interneten hirdetők által elköltött pénzösszeg is. Még 2009-ben az összes reklámköltésnek a 14,4%-át tette ki az internetes reklámokra költött összeg hazánkban, addig ez a szám 2010-re 15,9%-ra, 2011-re pedig 18,8%-ra növekedett. [2] A reklámok célja, hogy elősegítsék az eladó és a vevő közötti adásvétel létrejöttét. Az interneten történő hirdetésnek van egy óriási előnye az összes többi más hirdetési formával szemben, mégpedig az, hogy a vevők és a reklámok között valódi kommunikáció bontakozhat ki. Ha a fogyasztó többet kíván tudni egy termékről, szolgáltatásról, akkor egyszerűen csak rákattint hirdetésre, esetleg azonnal meg is vásárolhatja. [3] A webes hirdetésnek további előnyei közé tartozik, hogy viszonylag olcsón lehet hirdetni rajta, ennek ellenére rengeteg felhasználóhoz eljuthat hirdetésünk. Ha változtatni szeretnénk valamely reklámunk arculatán, akkor azt például a televíziós reklámokkal szemben viszonylag olcsón meg tudjuk tenni. Mivel, ahogyan azt a szakdolgozatomban is kifejtem majd, az érdeklődők számáról, azonnal informálhatja a hirdetés tulajdonosát az internet adta lehetőség. Az online hirdetéseket, reklámokat alapvetően két fő csoportra oszthatjuk: az email alapú és a webes felületekre épülőkre. [3]

2.1. E-mail alapú hirdetések, reklámok A médiatulajdonosok általában üzemeltetnek e-mail hírleveleket, amelyekben aztán reklámfelületet adnak ki. Vannak úgynevezett txt és HTML alapú hírlevelek. Ha txt típusú hírlevélről van szó, akkor szöveges hirdetési lehetőség van, ilyenkor mellékelhetünk egy

3

Web-reklámfelület menedzseralkalmazás linket, ami a kívánt oldalra navigálja a felhasználót. HTML alapú e-mailek esetében, pedig minden olyan lehetőség adott hirdetésünk elhelyezésére, amelyekkel a webes felületek esetében találkozhattunk (pl.: bannerek). [4]

2.1.1. Reklámkampány bérelt listára Ha egy cég a reklámját, még célzottabban szeretné a célcsoportjához eljuttatni, akkor az e-mail listák „bérlése” a megoldás. A listát nem kapjuk meg fizikailag, hanem a listatulajdonos küldi ki helyettünk az e-maileket, annak a célcsoportnak melyet mi kiválasztottunk. [4]

2.1.2. Promóció saját adatbázisra Amennyiben rendelkezünk, saját adatbázissal hírlevelünk folytán, küldhetünk a hírlevelek mellett, direkt e-mail reklámokat. [4]

2.1.3. Vásárolt listák Lehetőség van úgynevezett e-mail listák vásárlására. Nem természetes személyek esetében, nincs különösebb megkötés, viszont ellenkező esetben a listával kereskedni, csak akkor lehet, ha a listán szereplő személy ehhez hozzájárult. [4]

2.1.4. Partnerségi kapcsolatok Üzleti partnereink, akik ugyancsak rendelkeznek e-mail listákkal, szintén partnereink lehetnek a reklámkampányunkban. Fontos, hogy ha a listában szereplő partnerek üzleti folyamatokban kapcsolódnak valamely céghez, akkor az első e-mail üzenet mindenképpen engedélykérés legyen a további e-mailek küldéséről, különben jogosan spamnek nyilváníthatják leveleinket. [4]

2.1.5. Direkt e-mail Leginkább a nyomtatott direkt marketingre hasonlító eszköz, amellyel a direkt kiválasztott célközönségnek küldjük ki reklámüzeneteinket. Direkt e-maileket küldhetünk saját vagy bérelt listára is. [4]

2.1.6. Autoresponderek Ilyesféle üzenetet, akkor szoktunk kapni, ha például rendelünk valamit az interneten és visszaigazolásként egy e-mailt kap a felhasználó, melyben a vásárlását erősítik meg, esetlegesen további információkat közölnek benne. Másik jellemző példája, ha valami

4

Web-reklámfelület menedzseralkalmazás tanfolyamra iratkozunk fel és a megadott e-mail címünkre ezután meghatározott időközönként fognak érkezni az informáló e-mailek. [4]

2.2. Webes felületekre épülő hirdetések, reklámok Ezen hirdetések előnye az e-mail alapú reklámozással szemben, hogy nincsen szükségünk különböző e-mail listákra, hiszen a felhasználó böngészés közben találkozik a hirdetésünkkel. Számos eszköz és módszer létezik online reklámok megjelenésére, a legnépszerűbb típusok a következők:

2.2.1. Felugró ablak (pop-up és pop-under) A felugró ablak féle hirdetéseknél a hirdetés egy felugró ablakban jelenik meg, ha megnyitunk egy oldalt. A pop-up fél felugró ablakok, közvetlenül az olvasott tartalmat megjelenítő böngésző ablak előtt, a pop-under, pedig mögötte jelenik meg. Ezek, főleg a pop-up féle felugró ablak használata kevésbé ajánlott, annak ellenére, hogy biztosan látja a felhasználó, mivel ezek sok felhasználót idegesíthetnek. [5]

2.2.2. Közbülső banner A közbülső bannerek akkor jelennek meg, ha az egyik oldalról átkattintunk egy másikra. Általában a felhasználó bezárhatja őket. Érdemes nagyon megfontoltan használni őket, számos felhasználót irritál, ha túl sokáig, bezárhatatlanul jelennek meg. [5]

2.2.3. Hirdetés térképen Különböző online térképalkalmazásokon (pl.: Google Maps) elhelyezett hirdetések. [5]

2.2.4. Lebegő reklám A lebegő reklám egy rétegen jelenik meg néhány másodpercig az oldal felett. A felhasználó többnyire bezárhatja az ilyen fajta reklámokat. Általában DHTML- (Dynamic Hypertext Markup Language – a HTML egyik kiterjesztése) vagy Flash-alapúak. Az animáció gyakran egy bannerbe húzódik vissza. [5]

2.2.5. Háttérkép reklám A háttérkép típusú reklámok módosítják a megtekintett oldal hátterét.

5


2.2.6. Banner A banner a weboldalon reklámcélból megjelenített kép vagy animált kép. A statikus banner általában GIF- vagy JPG-formátumban készül, de a banner állhat Flashanimációból, videóból, JavaScript-, Ajax- vagy jQuery-alkalmazásból is. A felhasználó gyakran interakcióba léphet a bannerrel, s esetenként különböző tranzakciókat is végrehajthat. [5] A PRIM11 Kft. által fejlesztett, a szakdolgozatomban bemutatott, reklám menedzseralkalmazás, bannerek elhelyezésével foglalkozik.

2.3. Reklám menedzser rendszerek Rengeteg banner elhelyezéssel foglalkozó oldal van már manapság. Találunk közöttük olyat, ahol szinte semmibe nincs beleszólásunk a regisztrációt követően azon téren, hogy hol jelenjen meg hirdetésünk és olyan is, ahol szinte minden kis apró részletet be lehet állítani. Ezek közül választottam ki párat.

2.3.1. Telebanner A http://telebanner.hu/ címen elérhető bannercserélgetős oldal a legegyszerűbb rendszerek közé tartozik a vizsgált témában. Igaz, már több mint 12 éve a piacon vannak elmondásuk szerint, de a működési leírásból kiderül, hogy nem fejlesztenek az újonnan felmerülő igények irányába. 1. Működési elv: A rendszerben, csak olyan felhasználók hirdethetnek, akik rendelkeznek saját weboldallal. Ez azért fontos kikötés, mert a bannerek cserélgetős módszer alapján jelennek meg. Az én hirdetésem megjelenik valamelyik másik a rendszerbe regisztrált oldalon, cserébe az én oldalamon is meg kell jelennie valakinek a hirdetésének. A felhasználók pontokat kapnak, ha egy hirdetés megjelenik az oldalukon, viszont fizetnek, ha az ő hirdetésük jelenik meg valahol. A pontok elszámolását a rendszerben töltött időtől függően változtatják, ami azt jelenti, hogy például, akinek a regisztrációja még kevesebb, mint 3 hónapja történt, annak 2 pontot kell fizetni egy megjelenéséért a bannerének, viszont 1 pontot kap a saját oldalán való hirdetés megjelenéséért. Az 1:1 –es arány a rendszerben töltött 9. hónap után érhető el. [6] 2. Előnyök: a. Ingyenes. 3. Hátrányok: 6

Web-reklámfelület menedzseralkalmazás a. Ha a rendszerbe való regisztrációt követően elfogy az ajándék 1000 pontunk, addig nem jelenik meg sehol a hirdetésünk, még a saját oldalunk által nem szerzünk pontokat. b. Nem tudjuk szabályozni, hogy milyen oldalakon jelenjen meg hirdetésünk. c. Nem tudjuk szabályozni, hogy milyen hirdetések jelennek meg a mi oldalunkon, így akár konkurens hirdetések is megjelenhetnek.

2.3.2. Bannerhirdetések A http://bannerhirdetesek.hu/ a közismert lap.hu –s oldalakon helyezi el hirdetésünket. A reklámfelületeken 214*200 px vagy 214*100 px méretű hirdetéseket lehet elhelyezni. 1. Működési elv: A hirdetni vágyó kiválasztja melyik lap.hu –s oldalon szeretne hirdetni, majd ír egy email-t a kapcsolatfelvételnél megadott e-mail címre. A hirdetési felületet időszakra lehet kibérelni, melyeket hónapokban mérnek. A különböző lap.hu –s oldalaknak eltérő lehet a tarifája. [7] 2. Előnyök: a. Ki tudjuk választani, melyik oldalon, ezáltal melyeik lap.hu –s témakörnél szeretnénk hirdetni. 3. Hátrányok: a. Igazából semmi automatizmus nincs benne, mivel a megrendelés emailen keresztül történik. b. Előre nem tudjuk, hogy a pénzünkért cserébe hányszor jelenik meg hirdetésünk. c. Csak lap.hu –s oldalakon tudunk hirdetni.

2.3.3. Google AdSense és AdWords A Google által kifejlesztett hirdetési rendszer. A Google AdSense rendszerébe a weboldallal rendelkező felhasználók tudnak regisztrálni. A Google AdWords-be pedig azok, akik hirdetni szeretnének. Az AdSense-be regisztrált tagok oldalán, az oldal témájával kapcsolatos hirdetések fognak megjelenni. Van pár fontos irányelv, melyeknek megsértése a rendszerből való kitiltás jelentheti, ilyen például, hogy nem lehet saját hirdetési felületre kattintani, másokat megérni, hogy kattintsanak rá, 3 hirdetési egységnél, 3 linkegységnél és 2 keresőmezőnél nem lehet egy oldalon többet elhelyezni stb. 7

Web-reklámfelület menedzseralkalmazás 1. Működési elv: A hirdetőket a Google toborozza az AdWords szolgáltatásán keresztül, nekünk, mint honlap tulajdonosoknak csak annyi a dolgunk, hogy beillesztünk egy kódot az oldalunkba. Az így szerzett hirdetési bevételen a Google osztozik a reklámot megjelenítő honlap tulajdonossal. A bevétel nagysága alapvetően két dologtól függ: az oldal látogatottságától és ezáltal az átkattintási aránytól, illetve a választott kulcsszavaktól. Ennek a hirdetési rendszernek a lényege, hogy a hirdetők kulcsszavakra licitálnak, ezért amikor a honlap tulajdonosok megjelenítik a hirdetéseket, az oldalon szereplő kulcsszavakhoz fog igazodni a hirdetések tartalma. Ezt nevezik kulcsszóra optimalizálásnak. [8] [9] 2. Előnyök: a. Rengeteg beállítási lehetőség van a hirdetők számára, többek között, hogy milyen kulcs szavakra jelenjen meg hirdetése, milyen oldalakon esetleg földrajzi területeken, országokban, megyékben, városokban, mennyit hajlandó fizetni egy kattintásért stb. b. A hirdetési felülettel rendelkezők is meghatározott hirdetéseket fognak találni az oldalukon, ezáltal növelve annak tartalmi részét. c. Csak kattintásért kell fizetni. d. Nincs minimális költési kötelezettség. e. Rendkívül sok hirdető és médiatulajdonos. 3. Hátrányok: a. Nem feltétlen tudjuk, hol fog megjelenni hirdetésünk. b. A kulcsszóra optimalizálásos versenyeztetési módszer hátránya, hogy ha egy adott szóra más többet licitált, akkor az ő hirdetése fog megjelenni. c. Az felület tulajdonos oldalán az oldal tartalmának megfelelő hirdetések jelennek, meg ami sok esetben kedvezőtlen lehet a konkurens hirdetések miatt.

8


3. Use case diagram Ebben a fejezetben összefoglalom a rendszer és a környezete kapcsolatát, továbbá a rendszer funckionális működését. Ezt a use case (használai eset) diagram segítségével teszem. A use case diagram három építőelemet tartalmaz: használati eset (use case), aktor, kapcsolat. A használati eset megadja egy felhasználó által látható/igényelhető, a rendszer által megvalósított funkciót, funkció csoportot. Az aktor a rendszerrel kapcsolatba lépő személyek, külső rendszereket azonosítja, akik/amelyek a rendszer szolgáltatásait igénybe vehetik. A kapcsolat az aktorok és a use case-ek közötti viszonyrendszert definiálja. [10] A use case diagramról bővebben a [10] oldalon.

3.1. Aktorok

1. ábra

Három aktort különböztetünk meg (1. ábra): 1. Látogató 2. Tag 3. Admin A látogató aktor a nem bejelentkezett, azonosítatlan felhasználó. Az admin aktor, a tag aktor őse, tehát rendelkezik mindazon tulajdonságokkal, jogosultságokkal, melyekkel a tag is, és még további tulajdonságokkal, jogosultságokkal.

9


3.2. Use case-k aktoronként

3.2.1. Látogató

2. ábra

A 2. ábrán látható a látogató aktorhoz tartozó használati eset modell.

3.2.2. Tag

3. ábra

A tag aktornak jelentősen bővülnek az elérhető funkciói a rendszerben (3. ábra). Bizonyos használati esetek extend kapcsolatban állnak egymással.

10

Web-reklámfelület menedzseralkalmazás Extend kapcsolatnak nevezzük azt, ha egy használati eset egy másik funkció végrehajtását igényli. A bővítő használati eset kiegészíti az alap funkciót, vagy valamilyen kivételes esetet kezel. [10] Ilyen kapcsolat a 3. ábrán például az új felület felvitele és a felület módosítása használati esetek közötti kapcsolat. Ahhoz, hogy egy felületet módosítani tudjunk, előbb fel kell vinni, tehát teljesül az extend kapcsolatra vonatkozó definíció. A tag használati esetei között még felfedezhetünk include kapcsolatokat is. Ilyen például a felhasználó saját adatainak módosítása és a kötelező adatok megadása használati eset. Az include kapcsolatokra jellemző, hogy az ’A’ használati eset végrehajtásakor, ’B’ mindig végrehajtódik. Ezt akkor alkalmazzuk, ha ki szeretnénk hangsúlyozni, hogy ’A’ használati eset milyen résztevékenységekből áll össze. [10]

3.2.3. Admin

4. ábra

A 4. ábrán láthatóak az admin aktor használati esetei. Észrevehető, hogy ezek karbantartási funkciók.

11


3.3. Use case-k leírása 1. Regisztráció: A regisztrációt követően a felhasználó be tud jelentkezni. Előfeltételek: Nincs. Utóhatások: Elérhetőek a tag funkciók. Szokásos működés: A felhasználó kitölti a regisztrációs űrlapot. Alternatív esetek: A jelszó és a jelszó megint nem egyezik meg. A jelszó nincs minimum 8 karakter hosszú. Érvénytelen email cím formátum. Foglalt e-mail cím. Kivételes esetek: Nincs. 2. Fórum nyitása: A felhasználó új fórum témát hoz létre. Előfeltételek: A felhasználó be legyen jelentkezve. Utóhatások: Az összes bejelentkezett felhasználónak látszódik az új fórum téma. Szokásos működése: A felhasználó kitölti az új fórum létrehozásához szükséges űrlapot. Alternatív esetek: Nem tölt ki minden kötelező mezőt az űrlapon. Kivételes esetek: Nincs. 3. Hozzászólás: A felhasználó az általa kiválasztott fórum témához hozzászól. Előfeltételek: A felhasználó be legyen jelentkezve. Legyen aktív fórum téma. Utóhatások: A felhasználó hozzászólása megjelenik az összes azonosított felhasználó számára az előzőlegesen kiválasztott fórum témánál. Szokásos működése: A felhasználó kiválasztja a fórum témát, majd megírja a hozzászólását. Alternatív esetek: A felhasználó nem ír szöveget és úgy próbálja elküldeni a rendszer számára a hozzászólást. Kivételes esetek: Nincs. 4. Saját adatok módosítása: A felhasználó módosítja a saját adatait. Előfeltételek: A felhasználó be legyen jelentkezve. 12

Web-reklámfelület menedzseralkalmazás Utóhatások: Megváltoznak a felhasználó által módosított adatok. Szokásos működése: A felhasználó megváltoztatja a saját adatait. Alternatív esetek: Kötelezően kitöltendő adatok hiánya. Foglalt e-mail cím. Nem megfelelő e-mail cím formátum. Kivételes esetek: Nincs. 5. Új felület felvitele: A felhasználó regisztrálja a rendszerbe, az általa birtokolt hirdetési felületet. Előfeltételek: A felhasználó be legyen jelentkezve. Utóhatások: Elbírálás alá kerül a hirdetési felület az adminok által. A felhasználónak megjelenik a felvett felületek között a felvett hirdetési felület. Szokásos működése: A felhasználó kitölti az új hirdetési felület felvitelére szolgáló űrlapot. Alternatív esetek: Kötelezően kitöltendő anyagok hiánya. Kivételes esetek: Nincs. 6. Beérkezett kérelmek kezelése: A felhasználó a saját hirdetési felületeire beérkező kérelmeket tudja elbírálni, vagyis jóváhagyhatja a hirdető hirdetésének megjelenését a hirdetési felületén, vagy pedig visszautasíthatja a megrendelést. Előfeltételek: A felhasználó be legyen jelentkezve. Utóhatások: A felhasználó döntésétől függően megjelenik, vagy nem jelenik meg hirdetés az oldalán. Ha megjelenik a hirdetés, akkor megjelenések számától és az ártól függően kreditek íródnak fel a virtuális számláján. Szokásos működés: A felhasználó a beérkezett kérelmeket elbírálja. Alternatív esetek: Nincs. Kivételes események: Nincs. 7. Új hirdetés felvitele: A felhasználó regisztrálja a rendszerbe a hirdetését. Előfeltételek: A felhasználó be legyen jelentkezve. Utóhatások: A hirdetés megjelenik a saját hirdetések között. Szokásos működés: A felhasználó kitölti az új hirdetés regisztrálásához szükséges űrlapot. Alternatív esetek: Kötelezően kitöltendő anyagok hiánya. Kivételes események: Nincs.

13


8. Felület megrendelése: A felhasználó a saját hirdetései közül az általa kiválasztott hirdetéshez, megkeresi a listából a számára szimpatikus hirdetési felületet és megrendelési kérelmét továbbítja a médiatulajdonosnak. Előfeltételek: A felhasználó be legyen jelentkezve. Utóhatások: A megrendelési kérelem továbbítódik a médiatulajdonosnak. A megrendelés darabszámától és az 1 darab megjelenés árától függően a hirdető virtuális számlája meg lesz terhelve. Az előrendelt megrendelések között megjelenik az újonnan felvitt megrendelés a hirdető számára. Szokásos működés: A felhasználó kiválasztja a hirdetését. A hirdetéshez kiválaszt egy hirdetési felületet a listából. Megadja, hogy hány megjelenésre szeretné megvásárolni a hirdetési felületet. Alternatív esetek: Kötelező adatok kitöltésének hiánya. Nincs elegendő kredit a megrendeléshez. Kivételes esetek: Nincs. 9. Levélküldés: A felhasználók a rendszerben regisztrált tagoknak üzenetet tudnak küldeni. Előfeltételek: A felhasználó be legyen jelentkezve. Utóhatások: A küldött üzenet megjelenik a kimenő üzenetek között a felhasználó fiókjában. A címzettnek új bejövő üzenete lesz. Szokásos működés: A felhasználó kitölti a levélküldés űrlapot. Alternatív esetek: Kötelező adatok kitöltésének hiánya. Kivételes események: Nincs. 10. Beérkezett levelek kezelése: A felhasználó a beérkező üzeneteket megtekintheti. Előfeltétel: A felhasználó be legyen jelentkezve. Utóhatás: A megtekintett levelek olvasott stádiumba kerülnek mind a felhasználó postafiókjában, mind a feladó postafiókjában. Szokásos működés: A felhasználó elolvassa a számára küldött üzenteteket. Alternatív esetek: Nincs. Kivételes esetek: Nincs.

14


11. Kifizetés: A felhasználó a virtuális számlájáról kifizeti a kreditjeit. Előfeltétel: A felhasználó be legyen jelentkezve. Utóhatás: A felhasználó virtuális számlája meg lesz terhelve a kifizetett összeggel. Szokásos működés: A felhasználó kitölti a kifizetéshez szükséges űrlapot. Alternatív esetek: Nincs elegendő fedezet a virtuális számlán. A kötelező adatok kitöltésének hiánya. Kivételes esetek: Nincs. 12. Befizetés: A felhasználó befizet a virtuális számlájára. Előfeltételek: A felhasználó be legyen jelentkezve. Utóhatások: A felhasználó virtuális számláján jóvá lesz írva a befizetett összeg Szokásos működés: A felhasználó kitölti a befizetéshez szükséges űrlapot. Alternatív esetek: A kötelező adatok kitöltésének hiánya. A felhasználó a minimum befizetési összegtől kevesebbet akar befizetni. Kivételes esetek: Az átutalás nem érkezik meg. 13. Szolgáltatások karbantartása: A felhasználó a rendszerben használt szolgáltatásokat tudja felvenni, módosítani és törölni. Előfeltételek: A felhasználó be legyen jelentkezve. Utóhatások: A rendszerben használt szolgáltatások megváltozása a művelettől függően. Szokásos

működés:

Az

admin

jogosultsággal

rendelkező

felhasználó

karbantartja a szolgáltatásokat. Alternatív esetek: Kötelező adatok kitöltésének hiánya. Kivételes esetek: Nincs. 14. GY.I.K. karbantartása: A gyakran ismételt kérdések felvitele, módosítása és törlése. Előfeltételek: A felhasználó be legyen jelentkezve. Utóhatás: A rendszerben használt GY.I.K.-ek megváltozása a művelettől függően. Szokásos működés: A felhasználó karbantartja a GY.I.K.-et. 15

Web-reklámfelület menedzseralkalmazás Alternatív esetek: Kötelező adatok kitöltésének hiánya. Kivételes esetek: Nincs. 15. Hírek karbantartása: Híreket lehet felvinni, módosítani, törölni. Előfeltételek: A felhasználó be legyen jelentkezve. Utóhatások: A művelettől függően új hír megjelenése, meglévő hír megváltozása, vagy hír törlődése. Szokásos működés: A felhasználó karbantartja a híreket. Alternatív esetek: Kötelező adatok kitöltöttségének hiánya. Kivételes esetek: Nincs. 16. Fix szótárak karbantartása: A rendszerben használt szótárak karbantartása. Előfeltételek: A felhasználó be legyen jelentkezve. Utóhatások: A rendszerben használt szótárak megváltozása a művelettől függően. Szokásos működés: A felhasználó karbantartja a fix szótárakat. Alternatív esetek: A kötelező adatok kitöltöttségének hiánya, Kivételes esetek: Nincs. 17. Fórum karbantartása: A fórumok felvitele, módosítása, törlése. Előfeltételek: A felhasználó be legyen jelentkezve. Utóhatások: A rendszerben használt fórumok változása a művelettől függően. Szokásos működés: A felhasználó karbantartja a fórumokat. Alternatív esetek: A kötelező adatok kitöltöttségének hiánya. Kivételes esetek: Nincs. 18. Hirdetések karbantartása: A felhasználó a rendszerbe felvitt hirdetéseket tudja módosítani, vagy törölni. Előfeltételek: A felhasználó be legyen jelentkezve. Utóhatások: A kiválasztott hirdetés adatainak megváltozása. Szokásos működés: A felhasználó a kiválasztott hirdetést módosítja vagy törlni. Alternatív esetek: Kötelező adatok kitöltöttségének hiánya. Kivételes esetek: Nincs. 19. Kapcsolatok karbantartása: A rendszerben használt kapcsolatok felvitele, módosítása, törlése. 16

Web-reklámfelület menedzseralkalmazás Előfeltételek: A felhasználó be legyen jelentkezve. Utóhatások: A rendszerben használt kapcsolatok megváltozása a művelettől függően. Szokásos működés: A felhasználó karbantartja a kapcsolatokat. Alternatív esetek: Kötelező adatok kitöltöttségének hiánya. Kivételes esetek: Nincs. 20. Hirdetési felületek karbantartása: A felhasználó a rendszerben felvett hirdetési felületeket tudja módosítani, törölni. Itt van lehetőség az új hirdetési felületek engedélyezésére, hogy utána megjelenjenek a listákban. Előfeltételek: A felhasználó be legyen jelentkezve. Utóhatások: A kiválasztott hirdetési felület adatainak megváltozása, vagy a felület törlődése a rendszerből. Szokásos működése: A felhasználó elvégzi az általa kívánt műveletet a hirdetési felületen. Alternatív esetek: Kötelező adatok kitöltöttségének hiánya. Kivételes esetek: Nincs. 21. Felhasználók karbantartása: A felhasználó a rendszerbe regisztrált userek adatait tudja módosítani. Előfeltétel: A felhasználó be legyen jelentkezve. Utóhatások: A kiválasztott felhasználó adatainak megváltozása. Szokásos működése: A felhasználó módosítja a kívánt user adatait. Alternatív esetek: A kötelező adatok kitöltöttségének hiánya. Kivételes esetek: Nincs. 22. Alapképek karbantartása: A felhasználó a rendszerben használt alapképeket tudja feltölteni, melyek akkor jelennek meg a hirdetési felületeknél a beágyazott kód hatására, ha nincs jelenleg futó megrendelés a felülethez. Előfeltételek: A felhasználó be legyen jelentkezve. Utóhatások: A rendszerben használt alapképek megváltozása. Szokásos működés: A felhasználó karbantartja az alapképeket. Alternatív esetek: A kötelező adatok kitöltöttségének hiánya. Kivételes esetek: Nincs.

17


23. Elfelejtett jelszó: A rendszerben regisztrált felhasználó elfelejti a jelszavát és akkor jelszó emlékeztetést kér, melyet e-mailben kap meg. Előfeltételek: Regisztráció. Utóhatások: A felhasználó a regisztrált e-mail címére megkapja a jelszavát. A felhasználó be tud jelentkezni. Szokásos működés: A felhasználó elfelejti a jelszavát, majd jelszó emlékeztetést kér. Alternatív esetek: Nem létező felhasználót ad meg. A kötelező adatok kitöltöttségének hiánya. Kivételes esetek: Rossz email cím lett megadva az adatoknál. 24. Felület módosítása: A felhasználó a saját a rendszerben regisztrált hirdetési felületeit tudja módosítani. Előfeltétel: A felhasználó be legyen jelentkezve. Legyen már regisztrált felülete. Utóhatások: A kiválasztott hirdetési felület adatainak megváltozása. Szokásos működése: A felhasználó módosítja a saját hirdetési felületét. Alternatív esetek: A kötelező adatok kitöltöttségének hiánya. Kivételes esetek: Egy admin a módosítás közben törli a felületet. 25. Hirdetés módosítása: A felhasználó a saját korábban felvett hirdetéseit tudja módosítani. Előfeltételek: A felhasználó be legyen jelentkezve. Legyen már regisztrált hirdetése. Utóhatások: A kiválasztott hirdetés adatainak megváltozása. Szokásos működése: A felhasználó kitölti a módosításhoz szükséges űrlapot. Alternatív esetek: A kötelező adatok kitöltöttségének hiánya. Kivételes esetek: Egy admin a módosítás közben törli a hirdetést. 26. Felhasználó azonosítása: A felhasználó be akar jelentkezni a rendszerbe. Előfeltételek: Regisztráció Utóhatások: Tag funkciók elérése.

18

Web-reklámfelület menedzseralkalmazás Szokásos működés: A felhasználó megadja a bejelentkezéshez szükséges adatokat. Alternatív esetek: Helytelen jelszó. Elfelejtett jelszó. Kivételes esetek: Nincs.

19


4. Felhasználói felület tervezése A felhasználói felület az elsődleges kapcsolódási pont a felhasználó és a rendszer között, ezért rendkívül nagy figyelmet kell fordítani a szoftverfejlesztés, ezen részére is. Egy alapjában remek ötletet magában hordozó szoftver felhasználóinak számát jelentősen befolyásolhatja negatív irányba, ha a felület, mellyel a felhasználó találkozik bonyolult és nem átlátható, így a felhasználói felület nem csak esztétikai kérdés. [11] A felhasználó felület félretervezése több negatív következményt is vonhat maga után: A felhasználó nem éri el a rendszer bizonyos részeit, funkcióit, mert nem találja, nem veszi észre. A felület felépítéséből adódóan, valamilyen hibát követ el és nem az történik, amit ő szeretne, ez miatt feszülté, csalódottá válhat és elpártol a szoftvertől. Ezek tipikusan fennálló veszélyek, verziófrissítésnél, melyek akár súlyos anyagi vonzattal is járhatnak. [11] A felhasználó felületnek számos megjelenítési formája lehet: 1. Egyszerű ablakos, vastagkliens alkalmazás, mint például az Office vagy Skype. 2. Web-es rendszerek, mint például webshop-ok, vagy a tárgyalt rendszer. 3. Mobiltelefonok, PDA-k megjelenítési megoldásai (Alkalmazások, játékok). 4. Pixelgrafikus alkalmazásokról (OpenGL, DirectX programok). A felhasználó felület tervezésénél fontos, hogy a tervező ne a saját képességeihez tervezze a rendszert, ne legyen egyszerre túl sok információ egy adott felületen és rendszerproblémákról figyelmeztető üzeneteket el kell rejteni a felhasználók elől, mert megijedhetnek tőle. Fontos tehát, hogy a tervezésnél figyelembe vegyük az átlagos emberi képességeket, ne kelljen zseninek lenni egy rendszer használatához. A felülettervezésnek hat fontosabb elve van, melyek a következők: 1. Felhasználói jártasság: a. Olyan kifejezéseket és fogalmakat kell használni, melyet a legtöbb felhasználó ismer. b. Ne

azért

döntsünk

egy

felület

mellett,

mert

az

könnyen

implementálható. 2. Konzisztencia: a. A felületnek a hasonló funkciókat, hasonló módon kell megjelenítenie. Például: Menük.

20


3. Minimális meglepetés: a. A rendszer ne okozzon meglepetéseket a felhasználónak, mert a user felépít magában egy működési elvet, és ha ebben váratlan meglepetés következik be, az ingerülté teheti. 4. Visszaállíthatóság: a. A felületnek rendelkeznie kell olyan funkciókkal, amelyek lehetővé teszik a hibázás utáni visszaállítást. i. Ártalmas tevékenységek megerősítése pl.: törlés. ii. Visszavonási lehetőségek biztosítása: visszaállítja a rendszert a tevékenység bekövetkezése előtti állapotba. iii. Ellenőrzési pontok készítése. A rendszer állapotának mentése bizonyos időközönként. 5. Felhasználói útmutatás: a. Hiba esetén tájékoztatni kell a felhasználót az általa elkövetett hibáról, például űrlap kitöltésénél, valamely kötelező adat hiánya. b. Súgó 6. Felhasználó sokféleség: a. Gondolni kell a felhasználó csoportokra is. Regisztrált tagoknak többletfunkciója lehet. [11] A felhasználó felülettervezésnek három fő szakasza van: 1. Felhasználók elemzése: a. ilyen feladatokat végeznek b. milyen munkakörnyezetben dolgoznak c. milyen egyéb rendszereket használnak munkájuk során 2. Prototípuskészítés: a. A felhasználó felület terve alapján prototípust kell készíteni. 3. Felhasználók értékelése: a. A felhasználóktól kapott információk kiértékelése (a rendszer használata közben keletkezett tapasztalatok). A rendszerhez tartozó felhasználó felület megtervezésekor, tehát fontos figyelembe vennünk a rendszer funkcióit és a felhasználók nézőpontját is. Bármely funkciót könnyen és egyszerűen elérhessen a felhasználó. A fejlesztés lépéseként először csak papír alapú terveket érdemes készíteni. Ennek előnye, hogy gyors és olcsó. Ezeket érdemes 21

Web-reklámfelület menedzseralkalmazás megmutatni a végfelhasználóknak, akiktől a begyűjtött tapasztalatokat a prototípusok elkészítéséhez felhasználhatjuk. Érdemes a munkába bevonni grafikust, tervezőt mely költséges lehet, de később megtérülhet az ára és nem bukhatunk annyit vele, mintha egy rosszul megtervezett és összeállított felhasználó felületet társítunk a rendszerhez, szoftverhez. [11] A reklámnagyker egy olyan webes rendszer, aminek alapja a különböző statisztikák kimutatása. Fontos volt a felület megtervezésekor, hogy a végfelhasználók egyszerűen tudják kezelni a rendszert, annak bonyolultsága ellenére. Figyelembe kellet venni, hogy bizonyos funkciók csak a rendszerbe regisztrált tagok számára elérhetőek és olyanok is amelyek, csak az admin jogosultsággal rendelkezők számára érhetőek el. A változó információk (menüpontokhoz tartozó tartalmak) megjelenítésére egy fix helyet kellett megadni, hogy ne zavarja össze a felhasználót és mindig tudja, hogy mire számítson. Alapvető felépítése egy weboldalnak, hogy van benne header rész, egy fő munkaterület, és egy lábléc, melyeket további egységekre bonthatunk. (5. ábra)

5. ábra – Felülettervezés, oldal szerkezeti felépítése

Az 5. ábrán a header részhez tartozó egységek háttérszínét szürkével, a fő munkaterülethez tartozó egységek háttérszínét fehérrel és a footerhez tartozó egység háttérszínét narancssárga színnel jelöltem. Látható a fő egységek további alegységekre való bontása. Mivel nem akartuk, hogy az oldalt először látogató felhasználót egyszerre sok információ zavarja, ezért a nyitóképernyő így épül fel, viszont ha elkezd böngészni a felhasználó az oldal tartalmai között, vagy bejelentkezik, akkor a fő munkaterület bal oldalán is 22

Web-reklámfelület menedzseralkalmazás megjelenik egy plusz sáv, melyben további információk, tartalmak megjelenítésére van lehetőség. A rendszerben szereplő menüpontok közül a hirdetési felületek, saját hirdetések és a saját felületek a legfontosabbak, így ezeket részletezném és ezen belül is csak a „Fő munkaterület” szöveggel megjelölt részt (5. ábra). Hirdetési felületeket böngészve rengeteg potenciális felületet találhatunk, ezért érdemes szűkítési lehetőségeket biztosítani a userek számára.

6. ábra - Hirdetési felületek megjelenítése

A fontosabb információk látszódnak csak a felületekről, de a bővebb információk elérésére is biztosítunk lehetőséget. A részletek gombra kattintva, egy lenyíló panelben jelennek meg a további információk. A lenyíló panel minden felülethez külön tartozik, és rögtön alatta nyílik meg, így egyértelműen látható, melyik felülethez tartoznak az ott megjelenő adatok. A lenyíló panelben egy további funkció érhető el a rendszerben regisztrált felhasználó számára, mégpedig a csoporthoz rendelés. Itt kényelmesen kiválaszthatja a kívánt csoportot, melyhez a felületet hozzá szeretné rendelni. A saját felületek menedzselésére megalkotott sablonnál, gondoltunk arra, hogy bizonyos stádiumokra és folyamatokra szétosszuk a user felületeit, ezáltal megkönnyítve a dolgát, 23

Web-reklámfelület menedzseralkalmazás így egy menüsort építettünk be a fő munkaterület tetejére. A felületek egymás alatt jelennek meg. Minden felületről kiírjuk a fontosabb információkat, valamint felületenként biztosítjuk ugyanazokat a funkciókat, melyeket a felületekről informáló boksz alá kötöttünk be közvetlenül. Innen elérhetjük a teljes adatlapját, módosíthatjuk felugró ablakon az alap adatait, megtekinthetjük és kezelhetjük a hozzá tartozó képeket, forgalmi és statisztikai adatokat kaphatunk az adott felületről. (7. ábra)

7. ábra - Saját felületek menedzselése

24

Web-reklámfelület menedzseralkalmazás Az adatlap gombra kattintva, a 8. ábrán látott felülethez jut a felhasználó, ahol a felülethez tartozó megrendelések között böngészhet, mely megrendeléseket szétbontottunk kérelmezett, folyamatban lévő és lezárt stádiumúakra. A felületről informáló boksz maradt ugyanaz, mint az előző képernyőn, annyi különbséggel, hogy alul már csak 4 funkció érhető el, mivel értelemszerűen jelenleg az ötödikben vagyunk. A megrendelésekről a fontosabb információk fel vannak tüntetve és lehetőség van a forgalmi és statisztikai adatok megtekintésére. Jól láthatóan, itt minden a felülethez tartozó funkciót el tudunk érni.

8. ábra - Hirdetési felület adatlapja

A forgalmi és statisztikai adatokról nyújtott információkat, egy felugró panelen keresztül kaphatja meg a felhasználó. A felugró panelek megtervezésénél, fontos szempont volt, hogy jól láthatóan elkülönüljön a háttértől, informálja a felhasználót, hogy milyen tartalommal, esetleg űrlappal találja magát szemben, és hogy biztosítjuk a visszatérést az eredeti képernyőhöz egy kattintással. Ezért a felugró panelek, a képernyő közepén egy kerettel ellátva jelennek meg. 25

Web-reklámfelület menedzseralkalmazás A saját hirdetések menedzselésénél is a hirdetési felületekhez hasonlóan, azt az elvet követtük, hogy a kezelés megkönnyítése érdekében bizonyos, funkciókra és stádiumokra válogassuk szét a hirdetéseket. Egy felső vezérlő menüsorral valósítottuk meg (9. ábra). Az összes hirdetésünkre vonatkoznak a menüpontok, tehát ha a folyamatban lévő megrendeléseket választjuk, minden folyamatban lévő megrendelésünk megjelenik, de ha egy adott hirdetés adatlapjára megyünk, és ott választjuk a folyamatban lévő megrendeléseket, akkor ott csak az adott hirdetésre vonatkozóan jelennek meg az ilyen státuszban lévő megrendeléseink.

9. ábra - Saját hirdetések menedzselése

Az egyes stádiumoknál, úgy alakítottuk ki a felületet, hogy az minél kisebb lehetőséget adjon a felhasználónak a hibázásra, így például egy megrendelésnél, a folyamat, még a feladástól a lezárásig megtörténik, csak olyan funkciókat enged, amely vagy a következő stádiumba, vagy az előzőbe történő visszalépést engedélyezi.

26


5. Fejlesztőeszköz bemutatása A PRIM11 Kft-nél, egy egyedileg kifejlesztett programmal dolgoznak. A program neve Vezinf. A program Delphiben lett elkészítve. A weben megjelenő, különböző elemekből, lehet vele felépíteni a kívánt oldalt. Grideket, groupboxokat, képeket, szövegeket, flash elemeket (kódok, scriptek), sablonokat (10. ábra), formokat, frameket, stílusokat, menüstruktúrákat,

felhasználókat,

felhasználói

csoportokat

tudunk

létrehozni.

10. ábra – Vezinf

Ezeket viszonylag kedvünk szerint kombinálhatjuk, például egy sablonban lehet egy grid, ugyanakkor egy grid része lehet egy sablon és ezt akár több szinten keresztül is egymásba tudjuk ágyazni. Sablon része lényegében bármi lehet: szöveg, grid, groupbox, flash elem, másik sablon, kép, sortörés, lenyíló panel. Ezekre az elemek többféle funkciót tudunk bekötni, akár bizonyos feltételtől függően is. Ilyen funkciók például: másik sablon hívása, menüpont hívása, lenyíló panel le-felnyitása, valamilyen eljárás futtatása, sablonok újraolvasása stb. Sablon elemenként tudjuk szabályozni a megjelenésre vonatkozó stílust, ha valami linkről van szó, továbbá elemeként a link stílust, hogy milyen legyen a link típusa (_blank,_self stb.), magasságát szélességét az elemnek, esetleges hint feliratokat. Mivel a rendszer alapvető lényege, hogy szinte bármi lehet bármi része szinteken át, így a fejlesztés meggyorsítása érdekében létre lett hozva egy elemre ugrik funkció, aminek segítségével sablonokra, gridekre, groupboxokra, flash elemekre, közvetlenül tudunk ugrani, azaz egyből a kiválasztott grid szerkesztőjében leszünk, ha ezt a funkciót 27

Web-reklámfelület menedzseralkalmazás választjuk, nem kell keresgetnünk. Egy sablonhoz megadhatunk úgynevezett háttér adattárat, melyet a rendszer akkor kérdez vagy futtat le attól függően, hogy lekérdezésről vagy eljárásról van-e szó, mikor a sablont a rendszer megjeleníti a weben. Különböző adatbázisokat, táblákat view-kat, eljárásokat tudunk a kívánt projekthez felvenni. A rendszer lényege, hogy minden egyes elemet, ami a megjelenéshez kapcsolódik egy külön úgynevezett vezérlő adatbázisban tárolja, tehát egy adatbázis használ maga a rendszer, ami a megjelenésért felelős, és egy külön adatbázisban vannak azok a táblák, eljárások, view k, triggerek, generátorok, amik magához az adott feladat, jelen esetben a reklámmenedzser megvalósításához szükségesek. A felhasználó csoportokhoz különböző menüpontokat rendelhetünk, így szabályozva a jogosultság kérdését. Ezekhez a csoportokhoz pedig hozzárendelhetjük a rendszert használó usereket. A menüpontokhoz megadhatunk négyszintű struktúrát, melyeknek megjelenését is szabályozhatjuk, gondolok itt arra, hogy simán megjelennek például egymás alatt, vagy pedig egy lenyíló menü részeként. A rendszerben használt CSS stílusokat, például a submit gombok stílusa, a felvitelüket követően, rögtön alkalmazni tudjuk bármely gomb esetében. Lehetőség van különböző a böngészőkhöz különböző stílusokat beállítani, és úgynevezett stíluslapokat létrehozni, melyekkel ugyanazon oldal más megjelenést kap a kiválasztott stíluslaptól függően. A groupboxok létezhetnek önállóan is (például egy regisztrációs űrlap) vagy gridhez kötve (A saját képeink kezelésére szolgáló groupbox). A gridekhez tartozhatnak különböző szűkítési elemek, melyekkel bizonyos feltételek szerint szűrhetjük az adott lekérdezést. A grideknél megadhatjuk a megjelenés sorrendjét meghatározó order by záradékot, vagyis záradékokat, melyekhez select stílust tudunk rendelni. Az oldal megjelenését a Web formok, azon belül a Web framek határozzák meg. Minden Web form, egy, vagy több Web frame-ből épül fel. Az oldalakat táblázatokból építi fel a rendszer, viszont jelenleg folyamatban van a DIV-es megjelenésre történő átállás. DIV-eket már most is lehet beszúrni például egy sablon elemeként (tehát egy táblázat valamely cellájába), de a fő cél az, hogy a kornak megfelelően a rendszert átállítsuk teljesesen DIV-es megjelenésűvé. Az aktuális projektben használt fix kiírásokat a Web szövegek közé tudjuk felvenni, mely szövegeket

később

lefordítva

28

a

rendszer

Web-reklámfelület menedzseralkalmazás többnyelvűsíthető.

11. ábra - Vezinf, gridek

Maga a Vezinf a vezérlő adatbázis különböző tábláival dolgozik, azokban hoz létre új rekordokat, módosítja, a már meglévőket, esetleg törli az általunk kiválasztottat. A webes megjelenésért, mi, hogy jelenjen meg, pedig egy motor a felelős, amit arra a szerverre kell feltelepíteni, ahol a kiválasztott oldal tárolódik és a vezérlő adatbázis különböző rekordjaiból állítja össze a kívánt oldalt. A megjelenítés menetéről a cég kérésére részletesebb információt nem írok le. A megjelenítő motor és a Vezinf is folyamatos fejlesztés alatt áll az újabb és újabb igények felmerülésével párhuzamosan. A cégnél a Firebird relációs adatbázis-kezelőt választották az adatok tárolására. A Firebird nyílt forráskódú adatbázis-kezelő, mely teljesen ingyenes. Főbb jellemzői: 1. Tárolt eljárások és a triggerek teljes támogatása. 2. Az ACID követelményeinek teljesen megfelelő tranzakció-kezelés. 3. Külső kulcsok támogatása. 4. Minimális többlet-terhelés. 5. Kidolgozott nyelv a tárolt eljárások és triggerek programozására. 6. Külső függvények támogatása. 7. Használatához elegendő csupán telepíteni, nem kell rengeteg beállítási procedúrát végigcsinálni.

29

Web-reklámfelület menedzseralkalmazás 8. Sokféle módon lehet csatlakozni adatbázishoz: native/API, dbExpress driver-ek, ODBC, OLEDB, .Net provider, JDBC native type 4 driver, Python modul, PHP, Pearl, stb. 9. Több kisegítő eszköz létezik hozzá, mint például grafikus kezelőfelület, adatbázis tükröző programok. 10. Beépített adatbázis kezelési lehetőség, ideális megoldás CD katalógusok, egy felhasználós alkalmazások elkészítéséhez. 11. Támogat minden jelentősebb operációs rendszert, mint például a Windows-t, a Linux-ot, a Solaris-t, vagy a MacOS-t. Mivel dinamikusan fejlődik, ezért évente jelenik meg hozzá új verzió, és az egyre terjedő felhasználói körnek köszönhetően remek fórumok vannak, ahol szinte bármilyen felmerülő problémánkra megoldást találhatunk. [12] A fejlesztő program tüzetes megismerése után, ami körülbelül 3 hónap intenzív tanulást jelent, rendkívül gyorsan és hatékonyan tud a felhasználó megrendeléseket teljesíteni. A program használatához elengedhetetlen a CSS ismerete. A különböző eljárások és triggerek, valamit a megfelelő tábla struktúra létrehozásához pedig adatbázis-kezelési és programozási ismeret szükséges.

30


6. Megvalósítás Mivel, a szakdolgozat terjedelme nem teszi lehetővé az összes kód ismertetését, ezért az általam érdekesebbnek és a főbb eljárások közé tartozó kódok közül kiemeltem pár darabot.

6.1. Regisztráció A rendszer használatához, hogy hirdetéseinket, hirdetési felületeinket fel tudjuk venni feltétlenül szükséges beregisztrálnunk. A regisztráció során kötelező megadni a vezetéknevet, keresztnevet, a login nevet, a jelszót kétszer, egy becenevet és az email címünket. A regisztráció során ellenőrizzük, hogy a két jelszó megegyezik-e, amennyiben nem a regisztrációs eljárás nem fut tovább és értesíti a felhasználót, hogy a megadott jelszavak nem egyeznek meg. További kikötés a jelszavakra, hogy minimum 8 karakter hosszú legyen és tartalmazzon kis- és nagybetűket, valamint számokat egyaránt. Email cím ellenőrzésnél vizsgálva van, hogy korábban regisztrált-e már be valaki a megadott email címmel és hogy alapvető email cím formátumnak megfelel-e a beírt cím, azaz van e benne kukac és a kukac után pont. Ezt még később lehetne tovább javítani. A felhasználó- és becenévre is egyediséget vizsgáló feltétel van a regisztrációs eljárásban. Ha a felhasználó ezeknek a feltételeknek eleget tevő adatokat ad meg, akkor a felhasználó regisztrálva lesz a vezérlő adatbázisban, azaz innentől kezdve a felhasználó a nevével és a jelszavával be tud jelentkezni. A regisztráció sikerességéről kap egy email, a megadott email címre, melyben szerepel a login neve és a jelszava.

6.2. Céges adatok módosítása Ez az eljárás két részre lett bontva, mégpedig aszerint, hogy az adott partner már létezik-e vagy sem, ha létezik, akkor update utasítás megy végbe, ha pedig még nem létező partner (nincs ilyen kóddal partner a partnerek táblába), akkor pedig insert utasítás van kiadva a partnerek táblára. Az itt változtatott, címre vonatkozó adatok, a partnerek_cim táblába is insert-álódnak vagy update-elődnek az előző feltételtől függően. Ha új partnerről van szó, akkor a befizetesek táblába beírunk egy új sort, mely az adott partnerre vonatkozó bónusz összeget fogja tárolni. Ezt az összeget, akkor fogja megkapni az adott felhasználó, ha már rendelkezik elfogadott hirdetési felülettel és értelemszerűen megadta a céges adatait. Erről a trigger-ről, ami ezt állítja, később fogom megadni a leírást.

31


6.3. Partnerek címeinek kezelése Ezt az eljárást három részre bontottuk, attól függően, hogy az adott partnernek hány darab bejegyzése van a partnerek_cim táblába. Ha még nincs a partnerhez tartozó cím bejegyzés, akkor bármelyik címre vonatkozó adat megadásánál, legyen az székhely adat, számlázási adat, postázási adat, mind a három típusú címhez, ugyanazokat az adatok írjuk bele a partnerek_cim táblába. Ha egy típusú cím már meg van adva, akkor további három részre bontjuk ezt az elágazást, attól függően melyik típusú címet szeretnénk módosítani vagy megadni. Ha a postázási adatokat szeretnénk megadni, akkor insertálunk egy ’T’ típusú rekordot a partnerek_cim táblába az eljáráshoz beérkező adatokkal, valamint egy számlázási adatok rekordot, melynek típusa ’P’. Ha a számlázási adatokat szeretnénk megadni, de még csak a székhely adatok vannak kitöltve, akkor a partnerek_cim táblába két új rekordot viszünk fel. Egyet a megadott adatokkal insertálunk ’P’ típussal, és egyet a székhely adatokat lekérdezve ’T’ típussal. Ha pedig a székhely adatokat szeretnénk módosítani, aminek a típus jele ’S’, akkor updateljük a partnerhez tartozó székhely típusú rekordot, majd insertálunk az újonnan megadott adatokkal egy ’T’ és egy ’P’ típusú rekordot a partnerek_cim táblába. Ha pedig korábban már mind a három típusú cím meg volt adva, akkor pedig a felhasználó által kiválasztott típusú címet updateljük.

6.4. Hirdetési felület felvitele, módosítása Hirdetési felület felvitelénél és módosításánál egy eljárás fut le. Az eljárás elején megvizsgáljuk, hogy az adott felület létezik-e már, tehát hogy az eljárásba érkező felület kód benne van-e már az eup_part_tet táblába. Ha nincs, akkor insertálunk egy rekordot, ha pedig már létezik, akkor updateljük az eup_part_tet táblát a kiválasztott felületet azonosító rekordnál. Itt van egy plusz feltétel vizsgálat, miszerint, ha a host mező értéke megváltozik, akkor a felületet újra engedélyezni kell valamely admin jogosultsággal rendelkező felhasználónak, aki leellenőrzi, hogy valóban létezik-e a megadott hirdetési felület a beírt url-en.

6.5. Hirdetési felületekre vonatkozó trigger Az eup_part_tet táblára vonatkozó triggernek két feladata van. Az egyik az úgynevezett fantomkép meghatározása, vagyis annak a képnek megadása, ami akkor jelenik meg, ha a hirdetési felülethez nincs aktív megrendelés. Ezt a legjobbkep eljárás adja vissza, melynek működését később fogom kifejteni. A trigger másik feladata a bónusz kredit jóváírása, aminek feltétele, hogy ki legyenek töltve a céges adatok és legyen egy 32

Web-reklámfelület menedzseralkalmazás elfogadott stádiumú hirdetési felülete a felhasználónak. A trigger ezen részébe való belépésének a feltétele, hogy az aktuális hirdetési felület új és régi stádiuma ne egyezzen meg. Ha ezt teljesül megkeressük a felület tulajdonosának azon befizetesek táblába insertált rekordját ahol a szlaszam=’Bonusz’ és az ehhez tartozó befizetés stádiumot változóba mentjük. Ha, létezik ilyen a felhasználóhoz tartozó rekord, ahol a befizetés stádiuma egyenlő ’T2’-vel, azaz számlázott (még nem rendezett), és az aktuális felülethez tartozó stádium elfogadott státuszúra lett állítva, akkor a partner megkapja a 20000 bónusz kreditet. Melyet jóvá is írunk a virtuális számláján, majd a bónuszt jelentő befizetések rekord stádiumát átállítjuk rendezett státuszúra, így egy esetleges újbóli elfogadott státuszú felületnél nem íródik újabb bónusz kredit jóvá a felhasználónak.

6.6. Legjobbkep A legjobbkep eljárás megadja, hogy egy hirdetési felület számára a felvitt alapképek közül, melyik az, amelyik a magasság és szélesség értékeinek megfelelően legjobban illeszkedik az adott felületre. Ez a kép akkor jelenik meg, ha nincs a felülethez aktív megrendelés. Az eljárásnak két bemenő paramétere van, a felület magassága és szélessége. Az eljárás ebből egy aranyszámot képez. Ezt aranyszámot viszonyítja a rendszerbe felvett alapképek arányaihoz. Sorba veszi az összes alapkép arányát, és ha a minimum eltéréstől talál kedvezőbbet, akkor az új fantomkép kódját tároló változóba ennek az alapképnek a kódja kerül be. Az eljárás kimenő paramétere a legjobban illeszkedő fantomkép kódja.

6.7. Hirdetés felvitele, módosítása Hirdetés felvitelére és módosítására egy eljárást használunk, melyben eldöntjük, hogy új hirdetés felviteléről, vagy pedig már létező módosításáról van szó. A döntés alapját az eljárás egyik bemenő paramétere képzi, méghozzá a felülethez tartozó egyedi kulcs. Ha már létezik ilyen azonosítóval regisztrált felület, akkor updateről van szó, ellenben pedig insertről.

6.8. Megrendel A megrendel eljárás, akkor fut le, ha egy felhasználó el szeretné helyezni hirdetését valamelyik hirdetési felületen. Kiválasztja a számára szimpatikus felületet, majd a megrendelés gombra kattint. Az eljárásnak három bemenő paramétere van a hirdetés kódja, a hirdetési felület kódja és a mennyiség, tehát, hogy hány darab megjelenést szeretne a hirdető megvásárolni a médiatulajdonos weboldalán. Az eljárás elején lekérdezünk a

33

Web-reklámfelület menedzseralkalmazás kiválasztott felülethez tartozó egy megjelenéshez tartozó egységárat, ami azért fontos, mert ha a hirdetőnek nincs elegendő kredit a virtuális számláján (ezt is lekérdezzük), akkor a megrendelés kezdeményezése sikertelen lesz és erről a megrendelőt is tájékoztatjuk. Itt vizsgálunk egy további eshetőséget, mégpedig azt, hogy van-e olyan megrendelés, ahol a hirdető, az általa kiválasztott médiatulajdonosnál szeretne hirdetni és a megrendelés még előrendelt (’E’) vagy kérelmezett (’K’) stádiumban van. Ha van ilyen megrendelés, akkor a fedezet meglétét kicsit másképp számoljuk, mivel nem egyszerűen csak darab * ár szorzatnak kell kisebbnek lennie a hirdető aktuális kreditjénél, hanem az aktuális megjelenésre vonatkozó árat szorozzuk meg, a már korábban leadott megrendelésünk megjelenéseinek számával, és a most leadott megrendelésünk megjelenéseinek számának összegével, melyből kivonjuk a korábbi megrendelésre vonatkozó ár és darab szorzatot. Képlettel:

Ha ilyen esetben teljesül a feltétel, tehát van elég fedezetünk, akkor a korábbi megrendelést sztornózzuk, stádiumát ’X’ -re állítjuk, a hirdető kreditjeit megnöveljük a korábbi megrendelés darab * ár szorzattal. Létrehozunk egy rekordot a megrend táblába, ahol a két megrendelés megjelenés darabszámának összege lesz az új megjelenés szám és az ár az aktuális felület ár lesz. Ha nincs korábbi megrendelés a két felhasználó között a feltételnek megfelelően, akkor csak simán beszúrunk egy új sort a megrend táblába. A hirdető kreditjeinek összegét pedig megterheljük a feltételektől függően. Ezek a megrendelések előrendelt (’E’) stádiummal kerülnek rögzítésre. Ez azért fontos, mert ilyenkor még a médiatulajdonos számára nem jelenik meg a megrendelés, ehhez az előrendelt megrendeléseknél a hirdetőnek kérelmeznie (stádiumváltás ’K’-ra) kell a megrendelést.

6.9. Megrend táblára vonatkozó trigger A megrend táblára vonatkozó before update trigger-nek két feladata van. Az egyiket akkor kell végrehajtania, ha az adott megrendelésnél a hátralévő megjelenések száma egyenlő nullával és a megrendelés stádiuma egyenlő ’F’, azaz folyamatban lévő megrendelésről van szó. Ha ez a feltétel teljesül, akkor az aktuális megrendelés rekordhoz tartozó médiatulajdonos kreditjeihez hozzáadjuk a megrendelésben rögzített megjelenés szám és az egy megjelenésre vonatkozó szám szorzatának 80%-át. A szóban forgó megrendelésnél pedig a megrendelés stádiumát ’L’-re, vagyis lezártra állítjuk, és beírjuk a hirdető felület tulajdonosának jóváírt összeget a fizetve mezőbe, valamint a maradék 20%34

Web-reklámfelület menedzseralkalmazás ot a fizetve1 mezőbe. Rögzítjük még a jutalék százalékát és a lezárás dátumát. A másik feladat akkor hajtódik végre, mikor egy megrendelés stádiuma előrendelt stádiumból kérelmezett stádiumra állítódik. Ilyenkor megvizsgáljuk, hogy a megrendelésben szereplő hirdetési felület elbírálási típusához mi van beállítva. Ez három féle lehet: Minden megrendelésnél elbírál, csak ha új hirdető van, akkor kell elbírálni és automatikus engedélyezés. Automatikus engedélyezés típusnál lép életbe a trigger, ugyanis ilyenkor nem kell a felhasználónak külön engedélyezni a megrendelést a felületén, hanem ezt a trigger megteszi helyette, így a megrendelés rögtön életbe léphet.

6.10. Megrendelés kérelmezése Ez az eljárás abszolút nem bonyolult, hiszen csak egy stádiumváltás van benne, de ez elengedhetetlen a megrendelések kezdeményezésétől a lezárásiéig lévő folyamatban.

6.11. Megrendelés elfogadása A megrendelés elfogadásának akkor van szerepe, hogy az aktuális felülethez nem az automataengedélyezés van beállítva. Ilyenkor muszáj elfogadnia a megrendelést, ha szeretné, hogy hirdetési felületén megjelenjen a hirdető hirdetése.

6.12. Megrendelés forgalomaktualizálása A megrendelés forgalmának aktualizálásának nagyon fontos szerepe van a rendszer működését tekintve, ugyanis a statisztikai adatok egy részét ez képzi, vagy pedig az ebből képzett adatokból képez további statisztikát más eljárás. A megrend_forgakt eljárásnak egyetlen bemenő paramétere van a megrendelés egyedi azonosítója. Az eljárás elején lekérdezzük az aktuális megrendeléshez tartozó utolsó statisztika készítés időpontját, a megrendelés stádiumát és a lezárásának időpontját. Ha a megrendelés folyamatban van, akkor a datum2 értéke az aznapi dátummal lesz egyenlő, ha pedig nem folyamatban levő megrendelésről van szó, akkor a záró dátumhoz adunk hozzá egy napot és ez lesz az értéke a datum2 paraméternek. A datum2 értéke azért fontos, mert a megrend_forg táblába addig insertálunk új rekordokat, még ezt az időpontot el nem érjük. Statisztikát akkor készít az eljárás, ha a datum1 értéke null, vagy a datum1 nem egyenlő datum2-vel. Ha datum1 értéke null, akkor az azt jelenti, hogy még nem készült hozzá statisztika, ha pedig datum1 és datum2 egyenlő, akkor már a megrendeléshez volt aktualizálva az aktuális dátumon. Tehát,

ha

valamelyik

feltétel

teljesül,

akkor

a

megrend_forg

tábla

aktuális

megrendeléséhez tartozó maximális dátumot adjuk értékül a datum1 paraméternek plusz

35

Web-reklámfelület menedzseralkalmazás egy napot hozzáadva. Ha ez az érték null lenne, akkor a megrendelés dátumát adjuk értékül datum1-nek. Mivel a datum1 értéke nemcsak magát a dátumot tartalmazza, hanem az időt is, ezért sima dátummá alakítjuk. Indítunk egy ciklust, ami addig megy még a datum1 értéke kisebb, mint a datum2 értéke. Lekérdezzük a cikluson belül, hogy az aktuális naphoz hány megjelenés tartozik összesen és hogy ez hány IP címről jött létre. Mindezt a forgalom táblából tudjuk meg. Van egy forgalom_clikk tábla, ahol pedig a hirdetési felületre történő kattintások szerepelnek. Innen is lekérdezzük az aktuális naphoz tartozó klikkelések számát, valamint, hogy ez hány IP címről történt meg. Ezeknél a lekérdezéseknél természetesen az aktuális megrendeléshez tartozó rekordokat kérdezzük, mely feltétel a lekérdezés where záradékában szerepel is. Ezt a négy értéket a megrend_forg táblába rögzítjük a megrendelés sorszámával és a vizsgált dátummal együtt. Ezután hozzáadunk egy napot a datum1 értékéhez és mindent azt addig csináljuk, még a datum1 értéke kisebb, mint a datum2. A ciklusból kilépve updateljük a megrend tábla aktuális rekordját az elmúlt három nap, az elmúlt 2 nap és az utolsó nap megjelenéseivel és a felületre kattintás számával.

6.13. Hird_forg tábla töltése A

hird_forg

táblát

töltő

eljárás

nagyban

hasonlít

a

megrendelés

forgalomaktualizálásához. Egyetlen bemenő paramétere van a hirdetési felület azonosítója. Az eljárás elején lekérdezzük az utolsó statisztikázás dátumát, melyet a datum1 paraméterben tárolunk el. Az eljárás while ciklusában itt is addig megyünk, még a datum1 értéke kisebb, mint a datum2 értéke. A datum2 az aktuális dátummal lesz egyenlő. Az eljárás lényegi részébe való belepés feltétele, hogy vagy még ne legyen statisztikázva a hirdetési felület, tehát null legyen az értéke, vagy pedig az utolsó statisztikázás dátuma ne legyen egyenlő a napi dátummal. Ha ez a feltétel teljesül, akkor a datum1 paraméter új értéket vesz fel, méghozzá a hird_forg táblából a felülethez tartozó utolsó dátumot hozzáadva egy napot. Ez jelzi, hogy mely dátumtól kezdve kell nézni a hirdetési felület statisztikáját. Ha ez az érték null, akkor a hirdetés felvitelének időpontját kapja értékül. Ezután ciklus keretein belül, addig kérjük le a forgalom és forgalom_clikk táblából a felülethez tartozó napi összes megjelenést, azt hogy hány IP címről jelent meg és ugyanezek a felületre történő kattintással, még a datum1 értékét folyamatosan egy nappal növelve el nem érjük az aktuális dátumot. A lekért count értékeket az aktuális hirdetési felület kódjával és a lekérésre vonatkozó dátummal insertáljuk a hird_forg táblába.

36


6.14. Hirdetési felület statisztikáját készítő eljárás Minden hirdetési felülethez tartozik külön statisztika, melynek adatait a hirdetési felületeket tartalmazó táblában tárolunk. Az eljárás bemenő paramétere egy felületet azonosító kód. Az eljárás elején lekérdezzük a felülethez tartozó utolsó statisztikázás időpontját és tizenkét darab egyéb mező értéket, melyek tárolják a következő statisztikai adatokat: 1. st1 = Az utolsó 30 napra vonatkozó felület megjelenések számát, mely megrendeléshez köthető. 2. st1a = Az utolsó 30 napra vonatkozó kattintások számát, mely megrendeléshez köthető. 3. st2 = Az utolsó 7 napra vonatkozó megjelenések számát, mely megrendeléshez köthető. 4. st2a = Az utolsó 7 napra vonatkozó kattintások számát, mely megrendeléshez köthető. 5. st3 = Az előző napra vonatkozó megjelenések számát, mely megrendeléshez köthető. 6. st3a = Az előző napra vonatkozó kattintások számát, mely megrendeléshez köthető. 7. sr1 = Az utolsó 30 napra vonatkozó felület megjelenések száma, mely a hirdetési felületre vonatkozik. 8. sr1a = Az utolsó 30 napra vonatkozó kattintások számát, mely a hirdetési felületre vonatkozik. 9. sr2 = Az utolsó 7 napra vonatkozó felület megjelenések száma, mely a hirdetési felületre vonatkozik. 10. sr2a = Az utolsó 7 napra vonatkozó kattintások száma, mely a hirdetési felületre vonatkozik. 11. sr3 = Az előző napra vonatkozó megjelenések száma, mely a hirdetési felületre vonatkozik. 12. sr3a = Az előző napra vonatkozó kattintások száma, mely a hirdetési felületre vonatkozik. Itt fontos megjegyezni, hogy a megrendelésre és a felületre vonatkozó statisztikai adatok hiába, hogy mind köthető a felülethez, ezek eltérhetnek egymástól, ugyanis van olyan, mikor nincs aktuális megrendelés egy felülethez és a hirdetési felületre vonatkozó 37

Web-reklámfelület menedzseralkalmazás hat, statisztikai adatból azon idő alatt történő megjelenések és kattintások száma is nyomon követhető. Ha az utolsó statisztikázás dátuma nem null vagy ez a dátum megegyezik az aktuális dátummal, akkor nem kell frissíteni a statisztikát. Amennyiben ez frissítésre szorul, akkor először aktualizáljuk az összes olyan megrendelést, ahol a hirdetési felület az éppen aktuális bemenő paraméterrel megegyezik a megrend_forgakt eljárás meghívásával, melynek működését korábban leírtam. Azon megrendelések sorba vételénél a for select where záradékában megadjuk a dátumra és stádiumokra vonatkozó feltételt, ezzel is tehermentesítve a rendszert. A felülethez tartozó megrendelések aktualizálása utána a hirdetési felület forgalmát is aktualizáljuk a hird_forgakt eljárás segítségével. Erre vonatkozó leírást az előző pontban találhatjuk. Az aktualizálások után updateljük a 12 statisztikai adatot az előzőekben leírt feltételek szerint és a statisztikázás dátumát a felülethez tartozó rekordban. Az eljárásnak kilenc output paramétere van, melyek a visszaadják 30, 7 és utolsó napra vonatkozóan a megrendeléshez és a felülethez tartozó megjelenést, kattintást és a kattintás / megjelenés hányadosát százalékban.

6.15. Hirdetés statisztikáját készítő eljárás A hirdetésre vonatkozó statisztikát készítő eljárás bemenő paramétere az aktuális hirdetés azonosítója. Az eljárás elején lekérdezzük a következő adatokat: 1. datum_st = az utolsó statisztikázás dátuma. 2. st1 = Az utolsó 30 napra vonatkozó megjelenések száma. 3. st1a = Az utolsó 30 napra vonatkozó kattintások száma. 4. st2 = Az utolsó 7 napra vonatkozó megjelenések száma. 5. st2a = Az utolsó 7 napra vonatkozó kattintások száma. 6. st3 = Az előző napra vonatkozó megjelenések száma. 7. St3a = Az előző napra vonatkozó kattintások száma. Ha a statisztikázás dátuma nem null vagy ez a dátum egyenlő a mai nap dátumával, akkor nem kell frissíteni a hirdetéshez tartozó statisztikákat. Ellenkező esetben, sorba vesszük az összes olyan megrendelést, ahol a hirdetés kódja megegyezik az aktuális hirdetés kódjával és a forráskódban továbbá megadott feltételek teljesülnek, majd az így kapott megrendelésekre meghívjuk a megrend_forgakt eljárást. Ezután az eljárás updateli a korábban említett hét lekérdezett mező értékét a megrend_forg táblából a feltételeknek megfelelő értékekkel. Az eljárás visszaadott paraméterei tartalmazzák a 30, a 7 és az utolsó napra vonatkozóan a megjelenések, a kattintások és a kattintás / megjelenés hányadost százalékban megadva. 38


6.16. Összes és külön-külön hirdetésre és hirdetési felületre vonatkozó statisztika felhasználónként Az eljárásnak két bemenő paramétere van, egy kód és egy típus. Ha a típus 1, akkor a lekérdezés egy hirdetésről készít összefoglaló statisztikát. Ha a típus 2, akkor egy hirdetési felületről készít összefoglaló statisztikát. Ha a típus 3, akkor az egy felhasználóhoz tartozó összes hirdetési felületről készít statisztikát, ha pedig a típus 4, akkor az egy felhasználóhoz tartozó összes hirdetésről. Így látható, hogy a másik bemenő paraméter vagy egy felületet, vagy pedig egy felhasználót azonosít. Minden egyes típuson belül három lekérdezés van, ahol a lezárt, a folyamatban lévő és a kérelmezett (plusz előrendelt) stádiumú rekordokra vagyunk kíváncsiak. Mindegyik stádiumnál lekérdezzük a megrendelések számát, a megjelenések számát, a még tervezett megjelenések számát, az eddigi megjelenések után mozgósított kreditek összegét, a hátralévő megjelenések után lévő kreditek összegét, és hogy hányszor klikkeltek a felületre vagy hirdetésre. Az eljárás még a visszaadás előtt összeállít egy összesen értéket is soronként, majd táblázatos formában visszaadja az eredményül kapott értékeket.

6.17. Megjelenések és kattintások számolása Ebben az alpontban fejtem ki az egész rendszer lelkét. Ahhoz, hogy a médiatulajdonos felületén a rendszer számolni tudja a megjelenéseket és kattintások, illetve, hogy a hirdetések megjelenjenek a kívánt helyre egy az alábbi iframet kell beilleszteni: <iframe align="top" width="120" height="240" marginwidth="0" marginheight="0" hspace="0" vspace="0" frameborder="0" scrolling="no" src="http://www.reklamnagyker.hu/let.php?id=69"/>

A width és height értékekhez az idézőjelek közé a rendszerben a felület felvitelnél megadott szélesség és magasság értékeket kell megadni. Az id= értéknél, pedig a felület kódját, ami a felület egyedi azonosítója, melyet a felület adatlapján lát a tulajdonos. Ez az iframe minden egyes megjelenésnél meghívja a let.php fájlt. A let.php fájlnak 3 féle kimenetele lehet, attól függően, hogy a get vagy post mit tartalmaz. 1. Tartalmazza az ’id’ szöveget. 2. Tartalmazza a ’sorsz’ szöveget. 3. Nem tartalmazza egyiket sem. Ha tartalmazza az ’id’ szöveget, akkor a let.php-n belül meghívjuk a szamol eljárást, melynek első bemenő paramétere a felület azonosítója második pedig a lekérdezett IP cím. Ebben az esetben tudjuk, hogy sima megjelenésről van szó. A szamol eljárás lekérdezi a 39

Web-reklámfelület menedzseralkalmazás felülethez tartozó, folyamatban lévő megrendelés egyedi azonosítóját, a hirdetés egyedi azonosítóját, annak típusát, kép vagy flash kódját és a linkjét. Ezután lekérdezi a felülethez tartozó alapképet, ami ugye akkor jelenik meg, ha nincs aktív megrendelés, valamint a felület magasságát és szélességét. Insertál a forgalom táblába, a forráskódban látható paraméterek szerint, majd updateli a megrend táblát, ahol csökkenti a hátralévő megjelenések számát eggyel és az utolsó megjelenés dátumához beállítja az aktuális időbélyeget. Itt értelemszerűen, ha nem volt a felülethez tartozó, folyamatban lévő megrendelés, akkor egy rekordot sem fog updatelni, mivel az egyedi megrendelés azonosító null lesz, mint a hirdetési felület típusa is, és ha ez null, akkor a ’sorsz’ visszaadott érték 0 lesz egyéb esetben pedig a típustól függően vagy a kép kódja, vagy pedig a flash elem kódja. A visszatérési értékekből a let.php összeállítja a megjelenítendő kép/flash elem url-jét, típustól függően. Flash elem esetében, még meghív egy glob_flashment függvényt, ami visszaadja a flash elem beillesztendő szövegét. Az elemekre attól függetlenül, hogy van e hozzá megrendelés vagy nincs, a let-php-t a kattintáskor a kérésben található ’sorsz’ szöveggel hívja meg. Különbség annyi, hogy ha van folyamatban lévő megrendelés a felülethez, akkor a ’sorsz=’ mögött a megrendelés egyedi azonosítója szerepel ellenkező esetben pedig, -1. Ha a ’sorsz’ szöveg szerepel a kérésben, akkor a szamol_clikk eljárást hívja meg a let.php. Ennek az eljárásnak három bemenő paramétere van: a megrendelés azonosítója, az IP cím és a hirdetési felület azonosítója. Egy visszatérési értéke van, melyet a let.php fel is használ, és ez pedig, a hirdetés linkje, azaz, hogy hova mutat. Ha a megrendelés sorszáma 1, amint előbb írtam ez akkor lehetséges, ha olyankor kattintunk a felületre mikor nincs hozzá folyamatban lévő megrendelés, akkor a rendszer webes felületére linkel át, ellenkező esetben pedig a megrendeléshez tartozó hirdetés linkjét adja vissza. A szamol_clikk eljárás még insertál egy sort a megrend_forg táblába a beérkező adatokat felhasználva majd updateli megrend tábla clikk mezőjét, úgy hogy az előző értékét megnöveli eggyel. A harmadik esetet tekintve, mikor se az ’id’, se a ’sorsz’ szöveget nem tartalmazza a kérés, akkor egyszerűen csak kiírjuk, hogy ’nincs’. Az egész rendszer lelkét adó forgalom és forgalom_clikk táblák felöltése tehát, így működik.

40


7. Az elkészült alkalmazás bemutatása, élő képek mutatása Az alábbiakban bemutatom a fejlesztett rendszer főbb pontjainak működését, a regisztrációtól kezdve, egy hirdetési felület rendszerben történő felvitelének lépését, egy hirdetés

felvitelét

és

egy

megrendelési

folyamatot.

A

weboldal

elérhető

a

http://www.reklamnagyker.hu címen.

7.1. Nyitó képernyő és regisztráció Az oldalra látogató felhasználót a 12. ábrán látható felület fogadja. A fő munkaterületen egy rövid leírást olvashat, mely tájékoztatja a rendszer működéséről a usert.

12. ábra - Nyitófelület

A jobb oldali, korábban a felülettervezéskor információs sávnak jelölt részen, egy, az oldalt saját magát hirdető reklámot láthatunk, ami fix, nem tartozik a rendszerbe regisztrált kiadható felületek közé, mint azt majd későbbi példában láthatjuk. Alatta a hat legfrissebben regisztrált hirdetési felület címe látható. Az információs sáv harmadik és egyben utolsó része, a legutóbbi híreket tartalmazza. A látogatók számára még a kapcsolatok, vendégkönyv és a gyakran ismételt kérdések menüpont érhető el. A rendszer érdemi részének használatához regisztráció szükséges. Ezt a jobb felső sarokban történő regisztráció gombra kattintva teheti meg a felhasználó, úgy hogy az űrlapon lévő adatokat kitölti. Itt minden adat kitöltése kötelező és a megszorításoknak is eleget kell tennie a regisztrálni kívánt felhasználónak. Ezeket a megszorításokat a regisztrációs eljárás 41

Web-reklámfelület menedzseralkalmazás ismertetésében

már

részleteztem.

A

regisztrációs

űrlap

a

13.

ábrán

látható.

13. ábra - Regisztrációs űrlap

A regisztrációt követően bejelentkezett stádiumban lesz a felhasználó, akinek a Főoldal/Adatlapom menüpontra kattintva meg kell adni a céges adatokat, hogy később amennyiben felvesz egy hirdetési felületet, megkapja a 20000 bónusz kreditet. A főoldal menüpontot kivéve az összes többi menüpontnál a bal oldalt is megjelenik egy információs sáv, illetve a jobb oldalt lévő sáv tartalma is megváltozik. A jobb oldaliban három darab, hirdetési felületet láthatunk, melyeket akár meg is lehet rendelni hirdetésünk elhelyezése céljából. A bal oldali sávban pedig legfelül a virtuális számlánk egyenlegét kreditben és ennek egyenértékű forint összegét. Alatta hét darab ikont láthatunk, melyek bizonyos funkciók azonnali elérését teszik lehetővé. Ezek a funkciók a következők: legfrissebb hírek, hirdetési felület csoportok, előrendelt rendelések, még kérelmezni kell, engedélyre váró hirdetések, elbírálás alatt alá hirdetések, új beérkezett levelek, és letiltott hirdetők. Minden ikon alatt található egy szám is, amely azt jelzi, hogy az adott gyorsfunkcióhoz mennyi elem tartozik. A fő munkaterületen megadhatjuk az adatainkat. A módosít gombra kattintva felugró panelen nyílik erre lehetőségünk. A legfelső az úgynevezett kapcsolattartó résznél a regisztrációval kapcsolatos adatainkat módosíthatjuk. Utána jönnek a cégadatok és a cégadatokhoz tartozó három féle cím. Székhely, számlázási és postázási címek adhatóak meg. Ezek kapcsolatáról és kitöltéséről az 6.3. pontban tettem említést. Legalul a képek módosításnál a profilunkhoz tartozó képeket vihetjük fel. A 42

Web-reklámfelület menedzseralkalmazás képek közül, ha szeretnénk egyet profilképként kijelölni, van rá lehetőségünk és ilyenkor az adatlap bal felső sarkában ez a kép fog megjelenni. Az adatlapom almenüponthoz tartozó képernyőt a 14. ábrán lehet látni.

14. ábra – Adatlap

7.2. Hirdetési felület felvitele Hirdetési felület felvitelére a Főoldal/Saját felületek menüpontnál a felvitel gombra kattintva van lehetőség. A felvitelnél minden adat megadása kötelező, melyet egy felugró panelban tehetünk meg (15. ábra).

15. ábra - Hirdetési felület felvitele

43

Web-reklámfelület menedzseralkalmazás Még a felületünket valamelyik admin nem ellenőrzi, addig a felvett felületek között találjuk meg a hirdetési felületünket. A felvételt követően láthatjuk a felületünket azonosító egyedi kódot, mely mindenképpen szükséges, ahhoz hogy az iframe kódhoz a felületet azonosító részhez be tudjuk írni. Erről korábban a megjelenések és kattintások számolása című alpontban tettem említést, leírást. A 16. ábrán piros keretben látható a felülethez tartozó egyedi azonosító.

16. ábra - Felvett felületek

Én az iframe kódot a http://p0001.prim11.hu/ címen található oldal láblécében helyeztem el. Az elhelyezést követően a forgalom gombra kattintva a felugró panelen rögtön láthatóvá vált, hogy milyen IP címről és mikor jelent meg a hirdetési felület (17. ábra).

44


17. ábra - Felület forgalmi adatai

7.3. Hirdetés felvitele Hirdetés felvitelére a Főoldal/Saját hirdetések menüpont alatt a felvitel gombra kattintva van lehetőség. Meg kell adnunk az űrlapon található információkat (18. ábra).

18. ábra - Hirdetés felvitele

A felvitelt követően megadhatjuk, a hirdetéshez tartozó képet, vagy flash elemet a hirdetés adatlapján az elem gombra kattintva (19. ábra). Ezt az elemet fogja a rendszer a hirdetési felületre beilleszteni, ameddig még van hátra megvásárolt megjelenésünk. A hirdetéshez tarozó összefoglaló statisztikát a hirdetés adatlapján tekintheti meg a 45

Web-reklámfelület menedzseralkalmazás felhasználó. A 19. ábrán látható, hogy egy hirdetés adatlapján tudunk megrendelést kezdeményezni a megrendel gombra kattintva, és azt is, hogy a hirdetéshez tartozó megrendeléseket különböző stádiumban tudjuk megtekinteni, az előrendelt, kérelmezett, aktív és lejárt gombokra kattintva.

19. ábra - Hirdetés adatlapja

Kapcsolódó szavakat és csoportokat vihetünk fel a hirdetéseinkhez azon adatlapjukon.

7.4. A megrendelések folyamata Ha már felvittük hirdetésünket és beállítottuk hozzá a kívánt képet, vagy flash elemet, akkor válasszuk ki a nekünk szimpatikus hirdetési felületet. A bemutatóban az általam birtokolt hirdetési felületen fogom elhelyezni az előzőleg felvitt hirdetést. A 20. ábrán látható, hogy a kiválasztott hirdetés adatlapján a megrendel gombra kattintva megjelennek a rendszerben regisztrált hirdetési felületek. Itt a különböző felületeket az általunk létrehozott csoportokhoz hozzá tudjuk rendelni, ezek a csoportok megkönnyítik a kampányszerű hirdetést.

46


20. ábra - Megrendelés folyamatának első lépése

A kiválasztott hirdetési felületnél a megrendel gombra kattintva, egy felugró panelen meg tudjuk adni, mennyi megjelenést szeretnénk megvásárolni a hirdetési felület tulajdonosától. Ha olyan számot adunk meg, amire nincs elég fedezetünk, akkor erről a rendszer tájékoztatja a felhasználót (21. ábra).

21. ábra - Megrendelési folyamat (nincs elegendő kredit a megrendelés kezdeményezéséhez)

Ha van elég fedezetünk a megrendelés kezdeményezéshez, akkor egy üzenet tájékoztat minket arról, hogy a megrendelésünk rögzítésre került és az előrendelt megrendelések között tudjuk leadni a kérelmet a felület tulajdonosa felé, vagy ha 47

Web-reklámfelület menedzseralkalmazás meggondoljuk magunkat, lehetőség van a visszavonásra. Ilyenkor a lefoglalt kreditek visszaíródnak a virtuális számlára. A 22. ábrán látható, hogy egyetlen gombnyomással tudjuk a kérelmet elküldeni a felület tulajdonosának, vagy visszavonni azt. A megrendelés adatai is nyomon követhetőek már ebben a szakaszban.

22. ábra - Megrendelés kérelmezése

A bal információs sávban látható, hogy a két fogaskerék ikon alatt megjelent egy 1es szám. Ez jelzi a felhasználó számára, hogy van egy megrendelése, amit még kérelmeznie kell. A gyorselérés ikonok felett látható, hogy a 20000 kreditből, amit az első elfogadott felület után kapott a felhasználó, le lett vonva a megrendelésben meghatározott 250 kredit (Levonás = megjelenés szám * ár = 50 * 5 = 250). A kérelmezést követően, a hirdető számára a megrendelés az engedélyre várakozó megrendelések között fog szerepelni, addig, amíg a felület tulajdonosa jóvá nem hagyja a megrendelést. Ha a médiatulajdonosnak, a hirdető által kiválasztott felületén, az elbírálás típusához automatikus engedélyezés van beállítva, akkor rögtön az aktív megrendelések közé kerül a megrendelés az 6.9.-es pontban tárgyalt trigger segítségével. A felület tulajdonos, a kérelmet elfogadhatja vagy visszautasíthatja, nem automatikus engedélyezés esetén. A bal információs sávban a sárga lakat és a lila óra alatt is megjelent egy egyes szám, ami jelzi számunkra, hogy van egy engedélyre várakozó hirdetés valamelyik felületünkön és azt, hogy az egyik megrendelésünk elbírálás alatt van. Ez a két szám, azért lett mindkét helyen egyszerre egyes, mert ugye a példában a saját hirdetési felületemen helyezem el a

48

Web-reklámfelület menedzseralkalmazás hirdetésemet. A felület tulajdonos számára látható kérelem elbírálása és a gyorsikonok értékeinek megváltozása a 23. ábrán látható.

23. ábra - Kérelmezett megrendelések kezelés

A megrendelési kérelmet elfogadva a hirdetés rögtön megjelenik a hirdetési felületen (24. ábra).

24. ábra

Amint azt a 25. ábrán láthatjuk a folyamatban lévő megrendeléseknél a megrendeléshez tartozó információk között a hátralévő darab szám csökkent, így a megrendelő és a médiatulajdonos is láthatja, mennyi megjelenés van még vissza a 49

Web-reklámfelület menedzseralkalmazás megrendelésből. Az is kiolvasható az adatok közül, hogy mikor jelent meg utoljára a hirdetés. A forgalmi adatokat böngészheti a felhasználó, mikor milyen IP címen jelent meg a hirdetése. Mivel a megrendelés adatainál az alsó kis bokszban az utolsó 3 nap statisztikáját láthatja a felhasználó, ezért nincsenek még értékelhető adatok.

25. ábra - Folyamatban lévő megrendelés

A napi zárás után, vagy ha elfogy, a megrendelt megjelenés szám már láthatjuk az napra vonatkozó megjelenések és kattintások számát, valamint ezek arányát (26. ábra). A megrendelés befejeztével, újra az alapkép jelenik meg a hirdetési felületen, ha a felület tulajdonosa nem fogadott el újabb kérelmet a folyamatban lévő megrendelés alatt. A 26 ábrán látható, hogy a felület tulajdonosának jóváírták a megjelenésekért járó díjat. Az alap 250 kreditből, viszont csak 200 kreditet kapott meg, ez pedig azért van, mert a megrendelés végösszegéből a rendszer csak 80%-ot ír jóvá a médiatulajdonosnak, a maradék 20% pedig a rendszer tulajdonosáé lesz. A statisztika gombra kattintva napi lebontásban, azt is megtekinthetjük, hogy hány IP címen jelentek meg hirdetéseink, és hány IP címről kattintottak rá és persze ezek aránya is százalékban.

50


26. ábra

Mind a megrendelő, mind a médiatulajdonos a megrendelés bármely szakaszában megszakíthatja a megrendelés folyamatát. Ha már folyamatban lévő megrendelésről van szó, akkor a megszakítás pillanatáig történik az elszámolás, azaz annyi kredit lesz jóváírva a felület tulajdonosának, ahány megjelenés történt addig és persze ennek is csak a 80%-a. A hátralévő darabszám megjelenésének az árát, teljes egészében visszakapja a hirdető. Így zajlik egy megrendelés a kezdetektől az elszámolásig. Látható, hogy folyamatosan nyomon követhető, hogy hol tart a megrendelési folyamat. A gyorsikonok alatt található számok, pedig jelzik a felhasználónak, ha a valamely felületével vagy hirdetésével történt valami.

51


Összefoglalás Szakdolgozatomban az online hirdetési lehetőségekkel foglalkoztam, ezen belül is főként a webes felületekre épülő, banneres hirdetési rendszerekkel. Amint az a kutatómunkámból is kiderült, manapság egyre több vállalkozás, cég él az internetes hirdetési lehetőségekkel, melynek egyik fő oka, hogy az emberek körülbelül 40%-ához lehet eljuttatni így a hirdetéseket. Megvizsgáltam a piacon lévő, erre szakosodott rendszereket, melyből azt a következtetést vontam le, hogy rengeteg lehetőség van arra, ha hirdetni szeretnénk, esetleg rendelkezünk kiadható felülettel weboldalunkon és ezt szeretnénk bérbe adni. A szolgáltatók által nyújtott kínálat, nagyon széles skálán mozog. Az egészen egyszerű bannercserélgetős rendszerektől kezdve, találhatunk olyan, erre specifikálódott szolgáltatót is, ahol a beállítási lehetőségünk szinte minden apró részletre kiterjedhet. A rendszer tervezésekor meghatározott funkciókat nagy többséggel sikerült megvalósítani, működtetni. Így a felhasználó különböző statisztikát nyerhet ki a hirdetési felületekről, megrendelésekről. Ezenkívül a tervnek megfelelően létrehoztuk, hogy a user be tudja állítani egy adott hirdetési felület megjelenítési egységárát. A médiatulajdonos dönt arról, hogy mely hirdetések jelenhetnek meg az ő oldalán, melyet a program segítségével beállíthat. A felhasználó a kampányszerű hirdetések megkönnyítése érdekében különböző csoportokat hozhat létre, melyekbe hirdetési felületeket tud felvinni. A hirdetni vágyó számára megteremtettük a különböző szűkítési lehetőségekkel a részletes keresést. A felület tulajdonosa a megrendelésekből származó bevételéből el tudja helyezni saját hirdetéseit, viszont a banki átutalás lehetőségének biztosítása még nem történt meg. A rendszerek vizsgálata után, bebizonyosodott számomra, hogy rengeteg továbbfejlesztési lehetőség rejlik az általam bemutatott, a PRIM11 Kft. által készített reklámmenedzser alkalmazásban. Mivel egyre inkább a kattintásokért járó fizetések felé kezd elmenni a piac, így egy plusz lehetőségként a rendszerbe lehetne építeni, hogy a megrendelés az kattintás vagy megjelenés számon teljesüljön-e. Az elhelyezendő kódot a weboldalon, jelenleg a felhasználónak kell átírnia, hogy az, az ő felületét azonosítja. Ezt mindenképpen szükségesnek látom továbbfejleszteni, hogy a felvett hirdetési felületekhez, külön-külön a rendszer megadja a beillesztendő kódot, melyet a felhasználónak mindenféle változtatás nélkül, csak be kelljen illeszteni a weboldalán az általa gondolt helyre, ezzel is 52

Web-reklámfelület menedzseralkalmazás tovább egyszerűsítve a rendszer használatát. A jelenlegi és a kulcsszóra optimalizálásos versenyeztetési módszert meg lehetne egy idejűleg valósítani a rendszerben, méghozzá úgy, hogy a felhasználó beállíthatná egy adott hirdetési felülethez vagy hirdetéshez, hogy melyik típusú módszerrel kíván élni. Így, a rendszerbe regisztrált hirdetések és hirdetési felületeket két csoportra lehetne osztani. Tovább bonyolítván a dolgot, egy újfajta megoldása lehetne a probléma megközelítésének, hogy ha a két rendszert kevernénk, oly módon, hogy ha egy felülethez nincs aktív (jelenlegi rendszert működését figyelembe véve) megrendelés, akkor a kulcsszóra optimalizálásos versenyeztetési módszert alkalmaznánk az adott hirdetési felületre. Összességében elmondható, hogy az internet térhódításának köszönhetően, egyre nagyobb szerepet kapnak az online hirdetésre szakosodott rendszerek, viszont egy jó ötlet felvirágoztatásához szükség van a rendszer megismertetésre a célközönséggel, melynek legjobb módja, ha reklámozzuk azt.

53


Summary My thesis is about online advertising possibilities, especially with web-based banner advertising systems. As it turns out from my research nowadays more and more companies use advertising possibilities on the net. One of the reasons why they do so is that advertisements can be available this way for about 40% of people. I have examined systems on market specialized on it and it came out that there are plenty of possibilities for advertising or websurfaces to let. There is a variety of choice provided by the supporter. You can find not only the simplest banner changing systems, but also specialized supporters where the available settings can cover all particular details. Most of the functions I set when the system planned are realized and working, so users can retrieve different statistics of the advertising area and the orders. In addition we generated a function so the user can set up the unit price of the advertising area. The owner can decide which ads can show up on the ebsite and these can be set by the program. The user can generate different kind of groups and advertising areas can be set up in order to make the campaign-like ads easier. We generated detailed finders with many kind of shortlisted opportunities for the advertisers. From the income of the orders the owner can set up his/her own ads but providing money transfers via internet bank are not available yet. After thoroughly examining these systems it has been clarified that there can be a lot of possibilities of development in ad manager application written by PRIM 11 Ltd. As market is going on the way of getting paid after clickings it can be built in the system as an add-on whether the order should be fulfilled depending on the number of clickings or display. The code which must be placed on the website is has to be rewritten by the user at the moment to identify his own websurface. I definitely think it is necessary to develop this process in order to give the insert code separately for the ad surfaces. This way the user can insert it in the website without any changes. It makes the process even simpler. The current and the competitive keyword optimalization method could be implemented in the system at the same time in the following way: the user can set the type of method he wants to use for a specific advertisement surface or advertisement. This way the registered ad surfaces and advertisements can be divided into two groups. There can be a new approach of mixing the two systems which would make it possible to use the competitive keyword optimalization method for the specific ad surface if there is not any active order for the surface. 54

Web-reklámfelület menedzseralkalmazás To sum it up: due to the spreading of the internet, systems specialized on online advertising are becoming more and more popular, however a good idea will be successful if it is introduced to the group of people (users) aimed and the best way to do so is to advertise it.

55


Irodalomjegyzék [1]

Internet growth statistics. http://www.internetworldstats.com/emarketing.html

[2]

Magyar Reklámszövetség - Tanulmányok, elemzések. http://www.mrsz.hu/study.php?cmssessid=Tb319e817f45867742698052e695907b0 df91bd3b81dd24f6ab9ad36e4590322

[3]

Robbin Zeff, Brad Aronson. Reklám az interneten. 2000.

[4]

Nebojsa, Damjanovich. E-mail marketing. 2003.

[5]

Ingyenes informatikai tananyagok kisvállalkozásoknak. http://source.smepro.eu/hu/konyv/3-online-reklamok

[6]

Telebanner. http://telebanner.hu/tb/tbh?szabaly

[7]

Bannerhirdetések. http://bannerhirdetesek.hu/

[8]

Google AdSense. https://support.google.com/adsense/answer/1261929?hl=hu&ref_topic=1261918

[9]

Google AdWords. https://support.google.com/adwords/answer/1704410?hl=hu

[10]

Dr. Mileff Péter Szofvertechnológia, Unified Modeling Language I. rész. http://users.iit.uni-miskolc.hu/~mileff/szt/folia/SWtech_UML_1_print.pdf

[11]

Dr. Mileff Péter Szofvertechnológia, Felhasználói felületek tervezése http://users.iit.uni-miskolc.hu/~mileff/szt/folia/SWENG_5.pdf

[12]

Firebird 2 perces ismertető. http://www.firebirdnews.org/docs/fb2min_hu.html

Linkek utoljára ellenőrizve: 2014. május 12.

56


Melléklet 1. CD melléklet:  Forráskódok  Szakdolgozat

57

Web-reklámfelület menedzseralkalmazás

Recommend Documents