Magento indexelés: alapok, előnyök és a hibák elkerülése

Magento indexelés jelentése

Definició 1:

 

Az indexelés az a folyamat, amikor a Magento átalakítja a termék, kategória stb. adatokat a legjobb lekérdezési sebesség elérés érdekében.

 

Definició 2:

Az adatok letárolása a MySQL adatbázis számára, hogy a legjobb indexekből álljon elő az SQL lekérdezés.

 

Mi történne, ha nem lenne indexelés a Magento-ban?

Az itt felsorolt példák mindegyike szemlélteti, hogy jelentős teljesítménybeli javulást eredményeznek a Magento indexek. Már egy termék esetén is érdemes bekapcsolni az indexelést annak ellenére, hogy egy termék esetén nem olyan számottevő a sebességnövekedés.

  1. Az árak a terméklistában betöltődési időben számolódnának a kosár ár szabályok és a felhasználó csoport alapján
  2. A raktárkészlet kiszámítása a konfigurálható és a kötegelt termékek esetén csak a termék kollekció betöltődése után valósulna meg
  3. A „layered navigation” valós időben generálódna a több száz termékjellemző alapján
  4. Egy kategória összes gyerek kategóriájában a termékek rekurzívan kérdeződnének le.

 

Szakmai zsargon az indexelésben

Még mielőtt bemutatnám a Magento Indexelés menetét fontos tisztázni néhány alapfogalmat.

  • Indexed data (indexelt adat) – Az az adattömb, amely alapján a felhasználói felület megjelenítése történik
  • Indexer – Adattömb létrehozására alkalmas eljárás
  • Index event (index esemény) – Az a pillanat, amely a forrás adat megváltoztatásakor történik
  • Index process (index folyamat) – Az az időszak, amikor az indexer fut
  • Main controller – Feladatokat ad át az index folyamatnak

 

Magento Indexelési folyamat

Az alábbi ábrán látható a Magento Indexelési folyamata:

 

 

magento indexelési folyamat

 

Magento eseménnyel (Magento event) és manuálisan is el lehet indítani az indexelést. Indexelés közben a felhasználói felületen az adatok az EAV táblákból lesznek kiolvasva, ezért nem ajánlott csak indokolt esetben az újraindexelést.

 

Magento Indexelés részletes bemutatása

A katalógus és termék indexelés alapból ki van kapcsolva mind a Magento CE mind a Magento EE esetén. A bekapcsolásához System -> Configuration -> CATALOG -> Catalog -> Frontend -> Use Flat Catalog Category és Use Flat Catalog Category lists legördülőknél a YES-t kell választani.

A mentés után a Magento notification area-ban jelzi, hogy újraindexelés szükséges.

 

magento indexelés bekapcsolás

A Magento notification area közvetlenül az adminban, közvetlenül a menü alatt látható.

 

Magento indexelés futtatási lehetőségek

 

1) Magento admin

Válasszuk adminban a System -> Index management menüpontot. Kattintsunk a Select All linkre, az Actions opciónál a Reindex Data legyen kiválasztva, majd kattintsunk a Submit gombra

 

magento indexelés futtatás admin

 

2) Shell script

Indítsunk egy terminált, majd navigáljunk Magento gyökérkönytárába és adjuk ki az alábbi parancsot:

php shell/indexer.php –reindexall

 

Magento indexelés futtatás shell script

 

Lehetőségünk van csak egy indexet is futtatni ha –-reindex <indexer> paraméterrel futtatjuk az indexer.php-t. Például, ha katalógus url-eket szeretnénk újraindexelni, akkor futtassuk az alábbi parancsot:

php shell/indexer.php — reindex catalog_url

 

Magento indexelés futtatás shell script

 

Ha az info paramétert adjuk meg az indexernek, akkor egy listát fogunk kapni az összes indexről és az indexek kódjairól

 

Magento indexelés futtatás shell script

 

+1 módszer: php kódból

Futtassuk a teljes újraindexeléshez az alábbi kódot:

<?php
/* @var $indexCollection Mage_Index_Model_Resource_Process_Collection */
$indexCollection = Mage::getModel('index/process')->getCollection();
foreach ($indexCollection as $index) {
    /* @var $index Mage_Index_Model_Process */
    $index->reindexAll();
}

Ha csak egy indexet szeretnék frissíteni, akkor az alábbi kód is elég:

<?php
$process = Mage::getModel('index/indexer')->getProcessByCode('catalog_product_price');
$process->reindexAll();
}
catalog_product_price helyett írjuk be azt az index nevet, amelyet szeretnénk frissíteni.

Magento index táblából való olvasás gyorsítása

Lehetőségünk van a MySQL tábla indexeket raknunk az index táblákra. Ezt megcsinálhatjuk manuálisan is, mondjuk phpMyAdminból, de egy esetleges újraindexelés során már nem leszsznek meg azok az indexek, mert minden újraindexelésnél törli és létrehozza a Magento az index táblákat. Ennél picit precízebb megoldásra van szükségünk.

Az alábbi példában a termék indexre teszünk indexeket.

Hozzunk létre egy modult, amelynek a config.xml-jében iratkozzunk fel a catalog_product_flat_prepare_indexes eseményre az alábbi módon:

<catalog_product_flat_prepare_indexes>
    <observers>
        <aion_catalog_product_flat_prepare_indexes>
            <type>singleton</type>
            <class>aion_catalog/observer</class>
            <method>catalogProductFlatPrepareIndexes</method>
        </aion_catalog_product_flat_prepare_indexes>
    </observers>
</catalog_product_flat_prepare_indexes>

A fenti xml részletből látszik, hogy az Aion_Catalog_Model_Observer osztály catalogProductFlatPrepareIndexes metódusa fog meghívódni termék újraindexelés előtt. Ilyenkor már létrejött a tábla, nekünk csak annyi a feladatunk, hogy rátegyük az új indexeket a táblára:

/**
 * Add indexes to product flat table
 *
 * @param Varien_Event_Observer $observer observer
 *
 * @return void
 */
public function catalogProductFlatPrepareIndexes(Varien_Event_Observer $observer)
{
    /** @var Varien_Object $indexesObject */
    $indexesObject = $observer->getIndexes();
    /** @var array $indexes */
    $indexes = $indexesObject->getIndexes();
 
    /**
     * Ezekre a mezőkre teszünk indexeket a gyorsabb lekérdezések érdekében
     */
    $addFields = array(
        'upload_date', 'news_to_date', 'special_price', 'special_from_date', 'special_to_date'
    );
 
    foreach ($addFields as $field) {
        $indexes['IDX_'.strtoupper($field)] = array(
            'type' => Varien_Db_Adapter_Interface::INDEX_TYPE_INDEX,
            'fields' => array($field)
        );
    }
 
    $indexesObject->setIndexes($indexes);
}

Az $addFields tömböt kiegészíthetjük más jellemzőkkel is. Ügyeljünk arra, hogy nem minden oszlop típusra lehet tenni indexet.

 

Indexeléskor jelentkező hibák

Előfordulhat, hogy az Index Management menüpontban sokáig a processing státusszal van egy-egy index. Ez azt jelenti, hogy var/locks mappában lévő index_process_*.lock fájlokat a php nem tudta lezárni. A legegyszerűbb mód a hiba javítására a lock fájlok törlése.

Egy másik gyakori eset, amikor a flat tábla sérül meg és emiatt nem hajtható végre az indexelés. Ilyen esetben nyugodtan lehet törölni a sérült flat táblát, mert újraindexelésnél ellenőrzi a Magento, hogy létezik-e az a tábla és ha nem, akkor létrehozza.

Az oszlopok mérete MySQL-ben 4096 oszlopra van maximalizálva, de ez gyakorlatban jóval kevesebb. Függ attól is, hogy az egyes oszlopok hány karaktert tudnak tárolni. Ebből adódóan az index tábláknál is előfordulhat az, hogy nem tud létrejönni a tábla. Ez a hiba eléggé alattomos, mert az adminban csak az látszik, hogy nem indexelhető újra a tábla, de a magyarázatot már a szerver beállításokban kell megtalálni.

Ha ilyen hibába futunk bele, mindig át szoktuk nézni a jellemzőket, hogy biztos mindegyik kell-e a flat táblákba. Ha le tudjuk csökkenteni a jellemzők számát, illetve a méretét (pl. text helyett varchar-t használni), könnyen ki tudjuk iktatni ezt a hibát is.

Sajnos a legalattomosabb hiba az, amikor félbeszakad az indexelési folyamat. Ez olyan esetekben fordul elő, amikor kevés a memória, futási idő limit a webszerveren. Védekezni ellene csak úgy lehet, ha megnöveljük a php által használható memóriát és a futási időt is magasabbra vesszük.

Még egy lehetséges megoldás az indexelés parancssorból való indítása, amire a „Magento indexelés futtatási lehetőségek” második pontjában tértem ki (2. shell script).

 

Magento indexelés hátrányai

Nem szeretnék senkit se összezavarni, a Magento indexelés nagyon hasznos eleme a Magentonak. Ezzel egy időben ismernünk kell a hátrányait is. Íme néhány hátránya:

  1. Adatot dupláz. Mivel az adminban az EAV-s adatstruktúrába íródnak az adatok, de frontenden az index táblákból vannak kiolvasva, ezért minden termék adat kétszer szerepel az adatbázisban. Ha nem figyelünk az újraindexelésre, akkor könnyen eshetünk abba a hibába, hogy felhasználói felületen mást látunk mint az adminban.
  2. Erőforrás igényes. Nagyon sok server erőforrást használ a Magento indexelés, mivel rengeteg helyről olvas ki adatokat.
  3. Könnyen bele tudunk ütközni a MySQL oszlop maximumba. Erről az esetről az Indexeléskor jelentkező hibák alatt már írtam.

 

Végszó

Remélem, hogy a fenti cikkben sikerült bemutassam a Magento indexelésben rejlő lehetőségeket és segítséget is tudtam nyújtani az esetleges előforduló gyakori hibák megoldásában. Amennyiben akad valamilyen problémája, szívesen válaszolunk a kérdésekre és segítünk azt közösen megoldani. Cikkünket frissíteni fogjuk ezekkel a kérdések megválaszolásával.

 

 

Bigcommerce vs. Magento: Válaszd a jobbat cégednek

Miről lesz szó pontosan?

  • Árak, költségek – eltérő konstrukciók
  • Megjelenés, dizájn
  • Telepítés és használat
  • Funkciók – ahol szoros a verseny
  • Marketinglehetőségek
    • SEO
    • Közösségi média
    • E-mail marketing
    • Promóciós lehetőségek
  • Testreszabhatóság
  • Support és közösség
  • Összegezve – kinek mi a jó?

 

Árak, költségek

A Magento CE egy nyílt forráskódú, ingyenesen elérhető, telepíthető rendszer – a Magento esetében nagyobb költségek inkább akkor merülhetnek fel, ha komolyabban szeretnénk a saját képünkre szabni a webáruházat, ha új funkciókat, megjelenést akarunk és így tovább. Létezik egy kifejezetten nagyvállalatokra szabott csomag is, amelyre évi 18 ezer dollárért fizethetünk elő, ez az Enterprise Edition, ez azonban semmiképpen sem a kisebb webboltok, kezdő e-kereskedők megoldása.

A Bigcommerce esetében nem találunk ingyenes opciót, e téren tehát hátrányban van a rendszer. Legkisebb, Standard csomagjuk havonta 30 dollárba kerül, nagyvállalati, szintén Enterprise nevet viselő tervük pedig személyre szabott árakat tartalmaz.

A Magento esetében alapból nem kell fizetnünk a tranzakciók után (természetesen az online fizetési szolgáltatás, amelyet használunk, már határozhat meg díjat, ennek azonban a Magento-hoz nincs köze), míg a Bigcommerce esetében ezt nem kerülhetjük el. Kezdőcsomagjuk, a Standard esetén 2,9% + $0,30 fizetendő vásárlásonként, míg az Enterprise verzióban 2,2% + $0,30.

 

bigcommerce vs magento árak

 

Az online fizetési megoldások terén jelentős eltérést nem tapasztalhatunk, mind a két rendszer több tucat helyi és globális fizetési lehetőség integrációjára nyújt lehetőséget, azzal tehát nagy valószínűséggel nem lesz gondunk, hogy ezeket beépítsük a webshopba.

Hoszting szolgáltatásra mind a két esetben el kell különítenünk a büdzséből egy adott összeget, s hogy milyen erős hosztingra lesz szükségünk, azt természetesen az üzlet határozza meg.

 

Megjelenés, dizájn

A Bigcommerce számos ingyenes template-et kínál, hogy színesebbé tegyük a webáruházat, ezek jellemzően könnyedén megtekinthetőek és telepíthetőek. Reszponzív, okoseszközökre optimalizált témákat is találunk ezek között, ami igen nagy előny a keresőoptimalizálás és a felhasználói élmény szempontjából, érdemes ugyanakkor vigyázni, mert alapvetően nem minden megjelenés ilyen.

 

Bigcommerce- vs Magento intro oldal

 

A dizájn a Magento esetében kényesebb kérdés. Itt is találhatunk ingyenes témákat, és a Magento rendszere már alapvetően mobilbarát is, ugyanakkor ha ki akarunk emelkedni a tömegből, akkor szükségünk lesz valamilyen egyedi fejlesztésre.

Tekintve, hogy a Magento egy különösen komplex rendszernek számít, az egyedi fejlesztést csakis szakemberekkel érdemes elkészíttetni. Ez természetesen igénybe veheti a büdzsét, a tapasztalatok szerint ugyanakkor megéri, mivel sok olyan funkciót, megoldást nyerhetünk általa, amelyekhez egyébként nem volna hozzáférésünk.

Fizetős template-eket magától értetődően mindkét rendszerhez találhatunk, ezekkel bővíthetjük a funkcionalitást, a teljes személyre szabhatóság azonban valóban egyedi megoldásokat követelhet, amelyeket nem találunk meg a letölthető témák között.

 

Telepítés és használat

A rendszerek telepítése egyik esetben sem különösebben bonyolult. A Magento webáruháza mondhatni percek alatt telepíthető és élesíthető, bár tény, hogy ezt követően még komoly finomhangolásra lehet szükség ahhoz, hogy a kívánt módon üzemelő webáruházat építsünk fel. A Bigcommerce kis előnyben van, létezik ugyanis gyorstelepítési lehetőség (Quicklaunch), amely gyorsan végigvezet a folyamaton.

Ahogyan a legtöbb e-kereskedelmi rendszer, úgy a mindennapi használat, az egyszerűség terén a Bigcommerce is legyűri a Magento-t.

A Bigcommece kezelőfelülete rendkívül egyszerű és intuitív, a kezdőknek sem okoz különösebb nehézséget, hogy a számukra fontos funkciókat megtalálják.

A Magento már más tészta, a kezelés komolyabb felkészültséget kíván meg, ez ugyanakkor elsősorban a komplexitás, a rengeteg különféle funkció miatt van: a Magento annyiféle választási lehetőséget és opciót kínál fel, hogy óhatatlanul szükségünk lesz némi rutinra a kezeléséhez. Ehhez viszont rengeteg oktatóanyagot, tutorialt is találunk online, amelyek segíthetnek az adminisztrációs felületen eligazodni.

 

Funkciók

Ez az a szempont, ahol a Magento általában tönkreveri a konkurenciát. A rendszer ugyanis gyakorlatilag tetszés szerint testre szabható: mindent úgy állíthatunk be, hogy a webáruházban a legjobb felhasználói élményt biztosítsuk.

Akárhány terméket és termékkategóriát létrehozhatunk, amiben még nem volna semmi különleges, ugyanakkor megtehetjük azt is, hogy a termékek tulajdonságait szabadon átalakítjuk: teljesen mindegy, hogy mit árulunk, megszabhatunk bármilyen attribútumot, a profi szűkítő keresés segítségével pedig a felhasználók gyorsan megtalálhatják a számukra tökéletes lehetőségeket.

A Magento lehetőséget ad arra is, hogy szinte minden tevékenységről jelentéseket készítsünk és tekintsünk meg, rendkívül gazdag adatbázisokat hozhatunk létre a segítségével: tanulmányozhatjuk a felhasználók viselkedését, a vásárlói szokásokat, azt, hogy mely termékek vagy éppen termékcsoportok telesítenek jobban és így tovább.

 

bigcommerce vs magento webáruház

 

A Bigcommerce nem sokkal marad le, a nem nyílt forráskódú rendszerek között a legkomolyabb lehetőségeket biztosítja a webmesterek számára. Itt is lehetőségünk van a szűrőkkel történő keresésre, a rendszer adatokat biztosít analitika céljából a tartalmakról, marketingről, vásárlókról és termékekről.

A termékek menedzselése igen egyszerű a rendszerben, és már a Magento-val vetekszik, mivel szintén rengeteg lehetőséget tartogat. Egyedi beállításokat használhatunk például az ár megadásánál, termékeket kapcsolhatunk össze, egyedi mezőket hozhatunk létre, sőt, akár videókat is mellékelhetünk, nem csak képeket az egyes árukhoz.

A két rendszerben közös az, hogy a fejlesztők a nagyobb igényű webáruházakra gondoltak elsősorban, amikor megalkották őket: az akár több ezer terméket árusító, részletes termékleírásokkal és gazdag tulajdonságokkal ellátott webáruházakra, melyek nagy forgalmat bonyolítanak. Aki tehát első webáruházát akarja elindítani, mindössze néhány egyszerű termékkel, annak egy másik rendszer lehet a legmegfelelőbb választás.

 

Marketinglehetőségek

SEO

A Magento rendkívül jól keresőoptimalizálható, többek között metainformációkat adhatunk meg az egyes termékekről, termékkategóriákról, egyedi URL-ekkel, amelyek mind segítenek abban, hogy jobb helyezést érjünk el a keresőkben. A Google Content API-hoz is hozzáférést kapunk, és megtekinthetjük a keresőkifejezéseket, amelyeket célközönségünk használ. Természetesen Google sitemap is elérhető a rendszerhez. Hátránya annyi, hogy a szűkítő keresésnél a rendszer minden egyes alkalommal számos egyedi oldalt generál le.

E téren a Bigcommerce se marad le, a sitemap és a robots.txt sem hiányzik belőle, megváltoztathatjuk az URL-eket, metainformációkat és így tovább. E téren gyakorlatilag döntetlen az eredmény a két rendszer között.

 

Közösségi média

A Magento e téren nem igazán száll versenybe, nem találunk beépített lehetőségeket a rendszerben, ugyanakkor a bővítmények és egyedi fejlesztések segítségével bőven ráerősíthetünk a közösségi marketingre.

A Bigcommerce ellenben már alapból tartalmaz ilyen lehetőségeket, a SocialShop program segítségével Facebookon keresztül is végezhetjük az árusítást, aktiválhatjuk a megosztás gombot is, ugyanakkor más szolgáltatásokhoz, mint a Twitter vagy a Pinterest már nincs ilyen direkt kapcsolat (bár ez a hazai piacon kevésbé jelentős szempont).

 

E-mail marketing

Egyik platform sem kínál alapból túl sokat e téren, a Magento viszont a limitált lehetőségekkel is nyer. A rendszerben ugyanis találunk egy felületet, ahol integrálhatjuk létező hírlevél-szolgáltatásunkat (amilyen például a MailChimpé) és láthatjuk a fleiratkozókat, menedzselhetjük őket, leveleket küldhetünk ki nekik. Ellenben a Bigcommerc-nél az integrációt követően sem küldhetünk ki leveleket, viszont létrehozhatunk opt-in formokat, üdvözlő e-maileket és jelölőnégyzeteket.

 

Promóciós lehetőségek

A Bigcommerce lehetőséget ad különféle árakciókra, limitált idejű promóciókra, illetve integrálhatjuk az árösszehasonlító oldalakat is, így segítve a vásárlókat a legmegfelelőebb termék meglelésében. A Magento ennél többet ad, elképesztően gazdag lehetőségeink adódnak.

A felhasználók összeállíthatnak kívánságlistát, az egyes felhasználói csoportok számára különféle árakat határozhatunk meg, cross- és upsell promóciókat hozhatunk létre (esetenként ehhez további bővítmények telepítésére is szükség lehet), ajánlhatunk releváns termékeket vagy olyanokat, melyeket gyakran vásárolnak az adott áruval együtt, sőt, akár csomagban kínálhatjuk őket és így tovább. E téren tehát erősen a Magento felé hajlik a méreg nyelve.

 

Testreszabhatóság

Nem először említjük: a Magento egyik legnagyobb erőssége éppen az, hogy a legapróbb részletekig hozzáidomíthatjuk saját speciális igényeinkhez – lévén nyílt forráskódú szoftver, több lehetőségünk is van erre. A hatalmas és lelkes fejlesztői közösség például bővítmények, egyedi kiegészítők százait kínálja online, ingyenes és fizetős opciók egyaránt vannak.

 

Bigcommerce vs Magento ce verzió

 

Dönthetünk viszont úgy is, hogy teljesen egyedi megoldásokat akarunk alkalmazni: ebben az esetben profi Magento fejlesztőcsapattal érdemes dolgozni, mert kiemelkedően jó eredményeket érhetünk el – ugyanakkor ehhez azért némi büdzsére is szükségünk lesz.

A Bigcommerce ellensúlyként egy rendkívül változatos appstore-t tud felmutatni, ahol azért jó eséllyel találunk olyasmit, amire szükségünk van, ám mivel nem nyílt forráskódú rendszerről beszélünk, ezért nyilván korlátozottabbak is a lehetőségeink.

 

Support és közösség

A Magento fejlesztőitől közvetlenül is kérdezhetünk, ha bármi gond adódna, az igazi erősség azonban ez esetben a fejlesztői közösség. Számos különféle fórumon több ezer, a Magento rendszerében jártas profinak tehetjük fel kérdéseinket, ha probléma adódna, vagy ha valamire csak kíváncsiak vagyunk.

 

Magento fejlesztő közösség

 

A Bigcommerce-nél ilyen közösség értelemszerűen nincsen, ám a fizetős szolgáltatással együtt napi 24 órás supportot is kapunk telefonon, e-mailben vagy chat-en.

A Magento rengeteg oktatóanyagot és tutorialt biztosít, a neten nagyon sok ilyet találhatunk, míg a Bigcommerce saját blogján igyekszik megválaszolni a leggyakoribb kérdéseket és bemutatni a rendszer működését.

 

Összegezve

A Magento egy már kipróbált rendszer, amely kifejezetten alkalmas nagyobb forgalmú és kínálattal bíró webáruházak alapjaként. Sok világmárka használja hivatalos webáruháza alapjául, és összességében a piacon is szép, 25-30 százalékos részesedést mutathat fel már évek óta.

Nagymértékben testreszabható és alapvetően rendkívül sok lehetőséget tartogat, amelyek kiismerése azonban időbe telhet – ehhez viszont bőséges segítséget találhatunk.

A Bigcommerce egy szintén korrekt rendszer, amelynek a használata, telepítése egyszerűbb. Több téren is alulmarad a funkciók számában és változatosságában, azonban kevésbé komplex is, éppen ezért jobban ajánlott olyanoknak, akik kevésbé profik a webáruházak üzemeltetésében.

Az ár is szerepet játszhat a választásban: míg a Magento CE ingyenes, a fejlesztésre alkalmanként költeni kell, a Bigcommerce pedig a havidíjért cserébe egy stabil rendszer és supportot nyújt, ugyanakkor az egyedi fejlesztésekre itt nincs opció.

A Magento nagyobb szabadságot biztosít és szabadabb kezet ad a profiknak, ennek azonban meg is kéri az árát, míg a BIgcommerce inkább „biztonsági játékos”, a kevésbé szabad szellemek számára jó választás lehet.

 

Vásárlók kezelése Magento adminban (gyakorlati útmutató)

Tartalom

Vásárlók menedzselése

 

Vásárlói lista

Az adminban menjünk a Customers –> Manage Customers menüre.

 

menu kezelés

 

Itt láthatjuk a vásárlók listáját.

A lista elemei (alap esetben, angol nyelven):

  • ID: vásárlói azonosító
  • Name: a vevő teljes neve
  • Email: a vásárló email címe, amivel be tud lépni az áruházba
  • Group: vásárlói csoport
  • Telephone: telefonszám
  • ZIP: irányítószám
  • Country: vevő országa (ha üres, akkor az azért van, mert még nem tartozik hozzá cím)
  • State/Provice: megye
  • Customer Since: mióta vásárló, vagyis a regisztráció időpontja
  • Website: melyik website-hoz tartozik (ez akkor jelenik meg, ha több website-unk van a shopban)
  • Action: műveletek (módosítási gomb)

 

A listában való keresést (szűrést) a következőképp kell elvégezni:

 

grid keresés

 

Be kell írni a keresett szót (számot) a lista tetején levő beviteli mezőkbe, majd a jobb oldalon lévő Search gombra kell kattintani. Sorrendezni a listában szereplő oszlopnevekre kell kattintani (ha van olyan, amire nem lehet kattintani, akkor az nem szűrhető). Ha szeretnénk újból a teljes szűretlen listát látni, akkor a Reset Filter gombot kell megnyomni. A lista felett látjuk a lapozót. Mellette ki tudjuk választani, hogy egy oldalon mennyi vásárlót jelenítsen meg.

Grid lapozó

 

A vásárlói listát ki is tudjuk exportálni csv-ben vagy Excel xml formátumban. Ez a lista tetején, középen található. Ki kell választani az Export to-nál a formátumot, majd az Export gombot kell megnyomni. Itt mindig az aktuális szűrt listát exportálja ki (ha szűretlen a lista, akkor az összes felhasználót). Tömeges műveletekre is van lehetőség, ezeket a jobb oldalon levő Actions lenyílóból tudjuk kiválasztani.

Grid Massactions

 

Ki kell választani a vásárlókat (akikre leszeretnénk futtatni az eseményt) az első oszlopban lévő jelölőnégyzet bekapcsolásával, majd ezután válasszuk ki a műveletet, majd nyomjuk meg a Submit gombot.

 

Vásárló létrehozása

Vásárlók létrehozását a jobb oldalon lévő Add New Customer gombbal kell kezdeni.

A létrehozás első lépésekor csak kettő fület látunk, az Account Information-t és az Addresses-t.

Account Information fülön a következőket kell kitölteni:

Account Information

  • Associate to Website: itt adjuk meg, hogy melyik website-hoz rendeljük a felhasználónkat.
  • Group: itt kell beállítani, hogy melyik vásárlói csoportba tartozzon a felhasználó
  • Prefix: Vásárló név előtag (nem kötelező)
  • First Name: Keresztnév (magyar webáruházakban vezetéknévnek szokták általában használni, ehhez előfeltétel, hogy a fordítási csomagban át legyen írva)
  • Middle Name/Initial: Középső név (nem kötelező)
  • Last Name: Vezetéknév (ugyanúgy, mint a first name-nél, ezt pedig keresztnévnek használják magyar áruházakban)
  • Suffix: név utótag (nem kötelező)
  • Email: email cím, ezzel jelentkezik be a vásárló
  • Date of Birth: születési dátum (nem kötelező)
  • Tax//Vat Number: Adószám (nem kötelező)
  • Gender: a vásárló neme (nem kötelező)
  • Send Welcome Email: ha bekapcsoljuk, akkor üdvözlő emailt küld a vásárló email címére
  • Send From: melyik bolt nézetből küldje ki az emailt (többnyelvű oldalnál használatos)

 

Password Management

  • Password: ide írjuk a jelszót
  • Send Auto-Generated Password bekapcsolásával generálni fog random jelszót, amit el is küld az email címre, ilyenkor a Password mezőt figyelmen kívül hagyja.

új AcInTab

 

Addresses fülön:

Új címet az Add New Address gomra kattintva lehet létrehozni.

Az kitöltendő mezőket ugyanúgy kell kitölteni, mint az account information fülön, e mellet vannak új mezők:

  • Company: cégnév (nem kötelező)
  • Street Address: utca, házszám
  • City: város
  • Country: ország
  • State/Province: megye (nem kötelező)
  • Zip/Postal Code: irányítószám
  • Telephone: ez a címhez tarozó telefonszám
  • Fax: fax (nem kötelező)
  • VAT number: adószám (nem kötelező)

Az űrlap mellett további címet (címeket) tudunk hozzáadni.

A címek listában található kettő jelölőnégyzet, amivel be tudjuk állítani, hogy melyik legyen az alapértelmezett számlázási (Billing) ill. szállítási (Shipping) címünk.

 

Edit CustomerviewTab

 

Ezután mentsük el a felhasználót a Save gombok egyikével.

 

Vásárló adatok áttekintése és módosítása

Vásárló módosításához kattintsunk az Edit gombra. Ekkor a bal oldalon látni fogunk jó pár fület. Mindegyiket leírom, hogy mi található rajtuk, ill. mit tudunk ott módosítani. Az Account Information és Addresses füleken vannak módosítható adatok, a többi valójában információk kijelzése.

 

Customer View

Itt egy általános áttekintő található a felhasználóról.

Personal information:

  • Last logged in: utolsó bejelentkezési dátum (ha Never, akkor még soha nem jelentkezett be)
  • Confirmed email: jóváhagyva az email vagy sem (ez csak akkor érdekes, ha be van állítva, hogy regisztráció után küldjön megerősítései emailt)
  • Account Created on: regisztráció dátuma
  • Account Created in: hol lett létrehozva a vásárló (admin vagy valamelyik bolt nézet lesz itt kiírva)
  • Customer Group: melyik vásárlói csoporthoz tartozik
  • Default Billing Address: ki lesznek írva az alapértelmezett számlázási cím adatai (feltéve, hogy van ilyen)

Sales Statistics: Itt lesz kiírva, hogy mennyi összegben vásárolt a webshopon.

Recent Orders: az 5 legfrissebb rendelést mutatja.

Shopping Cart: itt az aktuális bevásárlókosár tartalmát írja ki.

Wishlist: a vásárló kívánságlistájának a tartalmát mutatja.

 

Edit Customer rendeles Tab

 

Account Information:

Ezt a vásárló létrehozásánál részleteztem.

Addresses:

Ezt a vásárló létrehozásánál részleteztem.

Orders:

Itt találhatók a vásárló által leadott rendelések

Edit Customer WishlistTab

Billing Agreements:

Itt a számlázási megállapodások listája szerepel (ez a funkció lehetővé teszi, hogy bizonyos fizetési módoknál be tudjon állítani adatokat, így megkönnyítve a vásárlást, mivel nem kell mindig újra és újra megadni a fizetési adatokat, ehhez a fizető rendszerrel kell megállapodni (ezt most itt nem részletezném jobban).

Recurring Profiles (Beta):

Ez az előfizetéses vásárlások listája, részletesebben a Magento terméktípusok és termékek beállítása – Minden, amit tudnod kell c. cikkben tárgyaljuk.

Shopping Cart:

A vásárló aktuális kosár tartalma. Itt az admin felhasználó törölni tud a kosárból, a lista jobb oldalán lévő Delete gombbal.

Wishlist:

Itt a felhasználó kívánság listájában szereplő termékek vannak.

 

Edit Customer hirlevel Tab

 

Newsletter:

Itt a kiküldött hírlevelek jelennek meg (feltéve, hogy fel van iratkozva)

 

Edit Customer termék vélemény ProducreviewsTab

 

Product Reviews:

Itt a felhasználó által írt termék vélemények szerepnek (az elfogadott, függő és elutasított is).

Edit Customer termék vélemény-ProducreviewsTab

Product Tags:

Itt jelennek meg a vásárló által írt termék címkék.

Edit Customer ProducttagsTab

Vásárló törlése

Vásárlót törölni lehet a listában a tömeges műveletnél (fentebb van részletezve), vagy a vásárló módosításánál a Delete Customer gombra kattintva. Ebben az esetben a rendeléseknél természetesen minden adat megmarad a vásárlóról (tehát a vásárlásai nem vesznek el).

 

 

Vásárlói csoportok kezelése

Vásárlói csoport lista

Vásárlói csoport listát az adminban a Customers -> Customer Groups menüre kattintva hozhatunk létre.

vásárlók kezelés csoport Group Menu

Itt láthatjuk a vásárlói listát, alapból 4 csoport létezik:

  • General – ez van a legtöbbször használva
  • NOT LOGGED IN – ez akkor van használva és kijelezve, ha engedélyezve van a vendég vásárlás az oldalunkon, és ilyenkor a vendég vásárló ebbe a csoportba kerül.
  • Retailer – kiskereskedő
  • Wholesale – nagykereskedő

 

vásárlók kezelés csoport Group List

Miért vannak vásárlói csoportok, és miért használjuk ezeket?

Azért, mert megtörténik, hogy egy adott vásárlói csoportnak más árazást szeretnénk beállítani, vagy adott csoport kapjon kedvezményeket adott termékekre stb.

 

Vásárlói csoport létrehozása és módosítása

A lista jobb oldalán lévő Add New Customer Group gombra kell kattintani.

Ha módosítani akarunk, akkor kattinstunk a listában lévők valamelyikére.

Az űrlapon megkell adni:

Group Name: a csoport neve (pl. AionHill vásárlók)

Tax class: adóosztály

 

Add Group

 

Vásárlói csoport törlése

Válasszunk ki egy törölni kívánt csoportot a listából, majd nyissuk meg úgy, mint amikor módosítani akarjuk, ezután a jobb oldalon lévő Delete Customer Group gombra kattintva tudjuk törölni a csoportot. Azok a vásárlók, akik ehhez a csoporthoz tartoztak, átkerülnek az alapértelmezett csoportba, ami alap esetben a General.

 

 

Vásárlókhoz tartozó rendszer beállítások kezelése

Menjünk az System –> Configuration menüre.

Ott menjünk a Customers tabon belül a Customer Configuration linkre.

 

kezelés beállítás Settings CustomerConfTab

 

A bal felső sarokban tudjuk állítani, hogy melyik website-hoz, bolthoz vagy bolt nézethez akarjuk a beállításokat elvégezni.

Ott a következőket lehet beállítani:

Online Customers Options

  • Online Minutes Interval: ha üresen hagyjuk, akkor alap 15 percenként frissül a Customers –> Online Customers menüben található lista.

Settings CustomerConfTab Online

Account Sharing Options

  • Share Customer Accounts: itt kell beállítani, hogy a vásárlóink tudjanak-e vásárolni a website-ok között (pl. van 3 website-unk és ha website-ra van állítva ez az érték, akkor mind a 3 website-ra külön-külön kell regisztrálnia, hogy tudjon vásárolni, viszont ha global-ra van állítva, akkor mind a 3 website-on 1 felhasználói fiókjával tud vásárolni).

Settings CustomerConfTab Account

Create New Account Options

  • Enable Automatic Assignment to Customer Group: Engedélyezzük-e, hogy automatikusan a vásárlót egy csoporthoz hozzárendelje. Ha igen-t állítunk, akkor újabb mezők jelennek meg, ahol be kell állítani, hogy az adószám ellenőrzése után milyen vásárlói csoportba kerüljön a felhasználó.
  • Default Group: itt adjuk meg, hogy melyik az alapértelmezett csoport, ide kerül be a felhasználó regisztráció után, illetve ha törli az admin az egyik csoportot, az abban lévő vásárlókat ide teszi át.
  • Default Value for Disable Automatic Group Changes Based on VAT ID: úgy, mint az első beállítás, ez is kapcsolódik az adószám ellenőrzéséhez
  • Show VAT Number on Frontend: Megjelenítsük-e az adószámot a frontenden, ez is kapcsolódik az adószám ellenőrzéséhez
  • Default Email Domain: alapértelmezett küldő email domainje, ez csak akkor van használva, ha az adminisztrátor adminfelületen ad le rendelést és nem tölti ki az email címet.
  • Default Welcome Email: alapértelmezett üdvözlő email sablon
  • Email Sender: email feladó
  • Require Emails Confirmation: Ha igenre állítjuk, akkor regisztráció után emailben kap egy megerősítő linket, amire kattintva lesz aktív a felhasználói fiókja
  • Confirmation Link Email: Megerősítő email sablonja
  • Welcome Email: üdvözlő email sablon
  • Generate Human-Friendly Customer ID: ha igenre van állítva, akkor szebb azonosítót generál a felhasználóhoz. Ezt általában egyedi fejlesztésekhez érdemes használni.

CustomerConfTab CreateNew

Password Options

  • Forgot Email Template: elfelejtett jelszó email sablonja
  • Remind Email Template: ez az admin felhasználó által módosított jelszó emlékeztető, amit kiküld a vásárlónak
  • Forgot and Reminder Email sender: a kettő fenti pont küldője
  • Recovery Link Expirateion Period: elfelejtett jelszóban kiküldött jelszó változtató link érvényességi ideje napokban kifejezve.
  • Require admin user to change user password: ha igenre van állítva, akkor ha módosítani szeretnénk adminban a vásárló jelszavát, akkor meg kell adni a mi (admin) jelszavunkat.

Settings CustomerConfTab Password

Name and Address Options

  • Number of Lines in a Street Address: hány sort mutasson a cím bevitelekor
  • Show Prefix: kijelezze-e (és regisztrációkor bekérje-e) a név előtagot (optional = nem kötelező, required = kötelező megadni)
  • Prefix Dropdown Options: pontos vesszővel elválasztva fel kell sorolni az név előtag választási opciókat (pl. dr;mr),ha üresen hagyjuk, akkor a felhasználó fogja beírni.
  • Show Middle Name (initial): kijelezze-e a középső nevet, igen-re állítva megadhatja, de nem kötelező
  • Show Suffix: kijelezze-e a név utótagot
  • Suffix Dropdown Options: ugyanaz, mint a Prefix Dropdown Options-nál csak az útótagra vonatkozik
  • Show Date of Birth: kijelezze-e a születési dátumot
  • Show Tax/VAT Number: kijelezze-e az adószámot
  • Show Gender: kijelezze-e a vásárló nemét

név és cím

Login Options

  • Redirect Customer to Account Dashboard after Logging in: bejelentkezés után átirányítsa-e a felhasználót a vásárlói irányítópulthoz

Settings CustomerConfTab Login

Address Templates

  • Text: cím sablon szöveg, ami az emailekben, nyomtatott nézetekben jelenik meg.
  • Text One Line: ez a sablonszöveg a rendelési folyamatban jelenik meg
  • HTML: ez több helyen is megjelenik (adminban a rendeleseknél, adminban a vásárló módosításánál, frontenden a vásárló címjegyzékében)
  • PDF: ez a számlázási, szállítási és jóváírási pdf-ben jelenik meg
  • Javascript Template: js templatekben (adminban, amikor új címet adunk hozzá a vásárlóhoz)

Settings CustomerConfTab Address

CAPTCHA

  1. Enable CAPTCHA on Frontend: engedélyezzük-e a biztonsági kódot, ha igen akkor a következő mezők jelennek meg:
    • Font: betűtípus
    • Forms: válasszuk ki, hogy melyik űrlapokban jelenjen meg
      • Create User: regisztrációkor
      • Login: bejelentkezéskor
      • Forgot password: elfelejtett jelszónál
      • Checkout as Guest: vásárlás vendégként résznél
      • Register during Checkout: vásárlás közbeni regisztrációnál
    • Displaying Mode: kijelzés típusa, vagyis hogy mikor jelenjen meg a CAPTCHA
      • Always: állandóan
      • After number of attempts to login: több sikertelen bejelentkezés után, ha ezt az opciót választjuk, akkor a következő mező jelenik meg:
        • Number of Unsuccesfill Attempts: hány próbálkozás után jelenjen meg, ha 0-t írunk be, akkor állandóan megjelenik

 

  • CAPTCHA Timeout (minutes): kód lejáratának ideje, percben kifejezve
  • Number of Symbols: hány karakterből álljon a kód (pl. 4-5 = ilyenkor 4 vagy 5 karakter lesz)
  • Symbols Used in CAPTCHA: milyen szimbólumok legyenek használva (Ide soroljuk fel a karaktereket, amikből szeretnék, hogy generálja a kódot a rendszer. Használhatjuk az a-tól z-ig (nagy betűket is) és 0-9 számokat (pl. ABCDEFGHJKMnpqrstuvwxyz23456789)
  • Case Sensitive: kis-nagybetű érzékeny, ha igen, akkor pontosan ugyanazt a kódot kell beírnunk, mint amit generál (pl. AaY1, ha nem-re van állítva, akkor ebben a példában elfogadja az aay1 kódot).

Settings CustomerConfTab Captcha

 

Vásárlói adó osztályok kezelése

Első lépésként menjünk az adminban a Sales –> Tax -> Customer Tax Classes menüre.

CustomerTax Menu

Itt láthatjuk a meglévő vásárlói adóosztályokat, alap esetben egy darab van benne, méghozzá a Retail Customer.

Új vásárlói adóosztály létrehozásához menjünk a jobb oldalon lévő Add New gombra.

Az űrlap nagyon egyszerű, csak meg kell adni az osztály nevét, és utána elmenteni.

CustomerTax CreateTaxClass

Felmerül a kérdés, hogy ezt hol használjuk?

A vásárlói csoportoknál megadhatjuk, hogy az adott csoport melyik vásárlói adóosztályhoz tartozzon. Miért hasznos?

Azért, mert ahány ország annyi adószabály (sőt pl. Amerikában államonként is eltér).

Az adószabályoknál pedig beállítjuk, hogy az adott szabály melyik vásárlói csoportra érvényes.

Ehhez a Sales –> Tax -> Manage Tax Rules menüre kell kattintani.

Ahol létrehozunk, vagy módosítunk egy adott szabályt, majd ott beállítjuk, hogy melyik vásárlói csoportra vagy csoportokra érvényes.

CustomerTax TaxRulesEdit

Megj.: Ebben a részben nem részletezem tovább az adó kezelést, mert túl hosszú lenne. Ebben a témában külön cikket publikálunk majd.

 

Vásárlói vélemények és címkék kezelése

 

Vásárlói vélemények

A vásárlói véleményeket három helyen lehet megtalálni:

  1. Catalog -> Review and Ratings -> Customer Reviews -> All Reviews

Itt megtalálható az összes vélemény

  1. Catalog -> Review and Ratings -> Customer Reviews -> Pending Reviews

Itt megtalálható az összes el nem fogadott vélemény

  1. Customers -> Manage Customers -> Edit

Valamelyik felhasználót módosítva a Product Reviews fülön, az adott felhasználó által írt véleményeket találjuk.

Hogyan fogadjuk el a véleményeket?

A fentebb említett menük egyikén (ha nem tudjuk, melyik felhasználó írta, akkor ajánlott a második pontban található menüre menni).

Itt láthatjuk a nem elfogadott (Pending) véleményeket.

Ha többet szeretnénk egyszerre elfogadni, akkor a bal oldalon ki kell választani a jelölőnégyzet segítségével a véleményeket, majd a jobb oldali Actions lenyílóból válasszuk az Update Status-t, és állítsuk Approved-ra (illetve amilyen állapotra szeretnénk, Approved – elfogadott, Pending – várakozik, Not Approved – letiltott).

CustomerReview PedingReviews MassUpdate

Ha egyesével szeretnénk módosítani (Elfogadni stb.), akkor az Edit linkre kell menni, majd a Statust a megfelelőre kell állítani, és elmenteni. Itt át is írhatjuk a hozzászóló nevét, véleményét.

CustomerReview PedingReviews Edit

Vásárló által címkézett termékek

Ezt is ugyanúgy, mint a véleményeket, több helyen lehet megtalálni

  1. Catalog -> Tags -> All Tags

Itt megtalálható az összes címke

  1. Catalog -> Tags -> Pending Tags

Itt megtalálható az összes el nem fogadott címke

  1. Customers -> Manage Customers -> Edit

Valamelyik felhasználót módosítva a Product Tags fülön, az adott felhasználó által írt címkéket találjuk.

Hogyan fogadjuk el a címkéket?

Ugyanúgy kell, mint a véleményeket (fentebb kifejtve).

Ha egyesével szeretnénk módosítani (Elfogadni stb.), akkor kattintsunk a címke sorára, majd a Statust a megfelelőre kell állítani és elmenteni. Itt át is írhatjuk a címkét, megnézhetjük, hogy melyik termékre lett rátéve (admin és vásárló által), mely felhasználók tették rá.

33-vasarlok_kezeles-CustomerTags_Edit_Tag

Ezt a címke módosító űrlapot a felhasználó módosításánál a Product Tags részből is el lehet érni.

 

Vásárlókhoz tartozó jelentések kezelése

A vásárlói jelentések a következő helyen találhatók meg:

Reports –> Customers menüben almenüként:

  1. New Accounts: új vásárlók száma az adott időszakra
  2. Customers by orders total: vásárlók az adott időszakra vonatkozó összesített rendelési összege
  3. Customers by number of orders: vásárlók az adott időszakra vonatkozó összesített rendelési darabszáma (vagyis, hogy hányszor vásárolt, ez nagyon hasonló, mint a 2-es pont)

CustomerReport Menu

Mind a 3-nál ugyanúgy kell frissíteni az adatokat.

Hogyan kell lekérni (frissíteni) a jelentéseket?

Első lépésként válasszuk ki az egyik menüpontot.

Az adott oldalon ki kell választani (vagy beírni):

  • From: mettől kezdve (dátum)
  • To: meddig
  • Show By:
    • Day – napokra szétbontva
    • Months –havonta szétbontva
    • Year – évente szétbontva
tips Itt egy példa:

Kiválasztottam a New Accounts menüpontot. Majd ott beírtam, hogy 01/1/2016-tól, 03/31/2016-ig, és havi bontásban mutassa. Ezután a Refresh gombot kell megnyomni. Eredmény:

35CustomerReport NewAccountReport

Láthatjuk, hogy januári és februári hónapra nem volt új vásárló, viszont a márciusira már 5 felhasználó van.

 

Ezzel be is fejeztem a vásárlói funkciók adminban való bemutatását. Remélem, tudsz belőle meríteni saját webáruházad fejlesztéséhez, hatékonyabb működéséhez. Kérdéseidet, észrevételeidet kommentben megadhatod, illetve egyéb magento-val kapcsolatos információért is felkereshetsz bennünket.

 

osCommerce vs. Magento: kinek melyiket érdemes választani?

 

Az alábbiakban sorra vett kérdések:

  • Árak
  • Telepítés és használat
  • Testreszabhatóság
  • Megjelenés, dizájn
  • Frissítések, közösségek, support
  • Előnyök és hátrányok: összegzünk
    • A Magento tömören
    • Az osCommerce tömören
    • Ítélet – a végső döntéshez

 

Árak

A Magento és az osCommerce egyaránt nyílt forráskódú rendszerek, tehát nem kell fizetni azért, hogy letöltsük és telepítsük őket. Emellett abból a szempontból is előnyös ez, hogy a fejlesztők szabadon dolgozhatnak rajtuk, bővítményeket és különféle átalakított változatokat hozva létre.

Amivel mindenképpen számolnunk kell, az a hoszting szolgáltatás ára – ez mind a két esetben attól függ, hogy milyen forgalommal tervezünk, milyen komoly webáruházat akarunk üzemeltetni, így itt nincs különbség.

 

magento-oscommerce-koltsegek

 

Létezik persze a Magento-nak fizetős változata is, a nagyvállalati igényekre tervezett Enterprise Edition, amely évente 18 ezer dollárért vehető igénybe, ezt azonban értelemszerűen már inkább világmárkák számára találták ki. A Community Edition használata teljesen ingyenes.

Könnyebbség lehet, hogy az osCommerce egyszerűbb rendszer, egyedi fejlesztéseket is könnyebb hozzá készíteni – ha a Magento-t teljesen át akarjuk alakítani úgy, hogy az megfeleljen az igényeinknek (illetve célpiacunk igényeinek), akkor nagy valószínűséggel szükségünk lesz a szakértő fejlesztők segítségére, erre pedig pénzt kell áldoznunk. Az egyedi fejlesztések persze hosszú távon megérik a befektetést, ám a büdzsével akkor is számolnunk kell.

 

A Magento, ill. osCommerce telepítése és használata

A Magento webáruház életre keltése bonyolult folyamat, maga a telepítés ugyanakkor különösebb nehézségekkel nem jár. Az osCommerce telepítése szintén egyszerű.

A használatban megmutatkozik, hogy a Magento komplexebb rendszer: komolyabb igényekre tervezték, nagyobb forgalmú áruházaknak, rengeteg különféle lehetőséggel és opcióval. Ennek következményeképp maga a kezelőfelület is sokkal bonyolultabb, kiismerni magunkat rajta megkíván némi rutint.

 

magento, oscommerce online értékesítés

 

Ezt némileg ellensúlyozza, hogy rengeteg oktatóanyag áll rendelkezésre, amelyből elsajátíthatjuk a mesterfogásokat, illetve egy igen méretes és lelkes közösségtől kérdezhetünk – de ez utóbbiról nemsokára bővebben is szólunk.

Az osCommerce ennél jóval felhasználóbarátabb, még azok is viszonylag könnyen megtanulhatják használni, akik korábban még soha nem menedzseltek webáruházat.

A Magento nagy erőssége az, hogy segítségével egyszerre több webshopot is menedzselhetünk egyszerre ugyanarról az adminisztrációs felületről. Az osCommerce nem kínál ilyen lehetőséget. Egy olyan vállalkozás tehát, amely egyszerre több vásárlói csoportot céloz meg, amely különféle termékeit külön akarja értékesíteni, a két lehetőség közül egyértelműen a Magento-val jár jobban.

 

Testreszabhatóság

A Magento verhetetlen ebben a kategóriában. Nagyszámú olyan funkciót tartalmaz, amelyek más e-kereskedelmi rendszereknél nem, vagy csak különféle (sokszor fizetős) bővítmények formájában állnak rendelkezésre.

A promóciós lehetőségek, így például a kuponakciók mindenképpen említést érdemelnek, mivel ezek segítségével igen hatékonyan növelhetőek az eladások a webshopon belül: összeköthetünk és együtt ajánlhatunk bizonyos termékeket, a felhasználók adott csoportjaira szabott akciókat hozhatunk létre, időkorlátos leárazásokat vezethetünk be, egyes termékcsoportokat promotálhatunk és így tovább. A felhasználóknak lehetőséget biztosíthatunk arra is, hogy összehasonlítsák az egyes termékeket.

 

magento-egyedi-megoldasok

 

A termékek kereshetősége is kiemelkedő, ugyanis a Magento rendszerében tökéletesen szabadon adhatjuk meg az egyes árucikkek attribútumait. Olyan tulajdonságokat hozunk létre, amilyeneket csak akarunk, így bármilyen termékválasztékhoz, még a legvegyesebbhez is gond nélkül alkalmazkodni képes a rendszer.

Az osCommerce ennél jóval gyengébb arzenált vonultat fel: bár egy sor funkciót találunk benne, illetve bővítményekkel is fokozhatjuk a választékosságot, a Magento-t e téren nem képes utolérni. Hiányoznak belőle többek között a kuponakciók, leárazások, ami igen nagy mínusznak tekinthető, ha rugalmas e-kereskedelmi rendszer után kutatunk. Van benne viszont az Amazonéhoz hasonló „mit vásároltak mások” funkció, ami egy kicsit enyhítheti ezt a hiányt.

 

Megjelenés, dizájn

Egy kör, amelyben a Magento győz. A Magento ugyanis gyakorlatilag a legapróbb részletekig átalakítható, testre szabható – persze, lévén komplex rendszer, ehhez profi segítségre lesz szükségünk, megéri viszont energiát és pénzt befektetni ebbe. Nyilván senki sem akarja, hogy a webáruháza ugyanúgy nézzen ki, mint mindenki másé, hogy megkülönböztethetetlen legyen a konkurensektől. Ennek a veszélye még akkor is fennáll, ha a sztenderd megjelenést egy ingyenesen vagy akár fizetősen elérhető sablonra cseréljük. Az egyediség az, ami segít ezt elkerülni.

 

magento oscommerce pluginek

 

Az osCommerce esetében is lehetőségünk van persze arra, hogy a dizájnt módosítsuk, ez azonban a tapasztalatok szerint igen bonyolult, nehézkes feladat.

Tény tehát, hogy akármelyik rendszert választjuk is a kettő közül, mindenképpen fejlesztőt kell majd fogadnunk, hacsak nem vagyunk profik a hasonló rendszerek módosításában, kódolásában, a webdizájnban. Magento fejlesztőt viszont könnyebben találunk.

 

Frissítések, közösségek, support

A Magento modernebb rendszernek számít, mivel általában havonta érkezik hozzá egy újabb rendszerfrissítés (illetve további kifejezetten biztonsági frissítések) és elmondható, hogy a modern igényeknek mindenben megfelel – jól keresőoptimalizálható, reszponzívvá tehető és így tovább. Az osCommerce sem mondható éppen elavult rendszernek, az igaz azonban, hogy frissítések sokkal ritkábban érkeznek hozzá, és a fejlesztői közösség is kisebb intenzitással dolgozik, mint a Magento-nál.

 

magento közösség

 

A Support az osCommerce esetében elsősorban a közösségre építkezik. Vannak persze a platformnak saját fejlesztői is, de a komolyabb problémákhoz már hivatalos oldaluk is azt ajánlja, hogy fogadjunk fel szakembert. Emellett a fórumon is lehetőségünk nyílik megoldást keresni problémáinkra, illetve élőben chatelhetünk a közösség egyes tagjaival.

 

oscommerce támogatás

 

Hasonló a helyzet a Magento esetében is: elérhetjük a vállalat saját szakértőit, az igazi erő azonban a hatalmas és aktív fejlesztői közösségben rejlik.

 

Előnyök és hátrányok: összegzünk

 

A Magento tömören

Olyan rendszer, amelyet nem az első kis webáruházukat néhány tucat termékkel feltölteni kívánók számára terveztek meg, hanem olyan e-kereskedelmi szoftverként, amely a legkreatívabb egyéni igényeket is képes kiszolgálni.

Olyan cégek számára ajánlott, akik már bejáratott piaccal rendelkeznek, kiszámítható rendszeres forgalommal bírnak és biztosan tudnak finanszírozni egy professzionális webáruházat.

Bár bonyolult rendszer, de rendkívüli mennyiségben kínál olyan beállítási lehetőségeket, amelyek mind a felhasználói élmény javítását elősegítik, mind az eladásokat növelhetik.

 

magento community edition

 

A rendszer több tucat fizetési lehetőséget támogat, sem a belföldi, sem a külföldi tranzakciókkal nem akad majd problémánk, az integráció gond nélkül lehetséges, az adatokat pedig természetesen biztonságosan titkosítva tárolja.

Ami gondot okozhat, hogy a kezdő felhasználók számára zavaró lehet az (egyébként jól felépített) kezelőfelület a rengeteg opcióval és beállítási lehetőséggel. A fejlesztés miatt pedig egészen biztosan szakemberhez kell majd fordulnunk – a Magento rendkívül jól bővíthető, ehhez azonban a rendszer beható ismerete szükséges.

 

Az osCommerce tömören

Az osCommerce egy biztosan futó, stabil rendszer, amelyhez rengeteg kiegészítő, bővítmény áll rendelkezésünkre. Régi bevált rendszer, amely egyáltalán nem marad alul a Magento-val szemben úgy, ahogy az ingyenesen elérhető rendszerek többsége, ha komolyabb teljesítményű webáruházra van szükség.

Összességében az osCommerce használatával valószínűleg olcsóbban is jövünk ki, nincsenek viszont benne megfelelő cross- és upsell lehetőségek, promóciós opciók. Lassan is frissül, nehezen átalakítható, és összességében némileg el van maradva a legújabb megoldásoktól.

 

Ítélet

Részrehajlás nélkül mondhatjuk, hogy aki egy kicsit is komolyabb webshopot akar üzemeltetni, és ehhez egy megbízható, biztonságos és ráfordítással ugyan, de átalakítható, testre szabható és rugalmas rendszert keres, annak a Magento a jobb választás. Az osCommerce mára kicsit elöregedett, és főleg olyanoknak jó választás, akik egy egyszerűbb, de azért megbízhatóan működő webáruházat akarnak, és nem vágynak változatos lehetőségekre a forgalom felpörgetéséhez.

 

Magento layout fejlesztés alapok

A layout felépítése

A layout definíciók mindig egy adott modulhoz kapcsolódnak. A modul config.xml fájljában adhatók meg az alábbi módon vásárlói oldalon:

 <frontend>
<layout>
<updates>
<aionmodul module=”Aion_Modul”>
<file>aion_modul.xml</file>
</aionmodul>
</updates>
</layout>
</frontend>

Illetve admin oldalon:

<adminhtml>
<layout>
<updates>
<aionmodul>
<file>aion_modul.xml</file>
</aionmodul>
</updates>
</layout>
</adminhtml>

Az <updates> tagen belüli tag egy egyedi név kell, hogy legyen.

Mindkét esetben látszik, hogy a <file> tagen belül kell meghatározni, hogy mi a neve a layout fájlnak. A layout fájlokat az app/design/frontend/[csomag neve]/[téma neve]/layout, illetve az app/design/adminhtml/[csomag neve]/[téma neve]/layout könyvtárakban kell keresni.

Az XML fájlban az alábbi tagek között kell megadni, hogy milyen layout handler-re vonatkozik az utasítás:

<layout version=”0.1.0″> 

és

</layout>

 

 

Layout handle funkciója

A block definiciók mindig egy jól meghatározott handle-ön belül találhatóak. Egy layout handle több block összeségét jelöli névvel elnevezve. A default layout handle minden oldalhoz hozzáadódik az adott scope-ban. A főoldal az alábbi layout handle-ök alapján épül fel:

  1. default
  2. cms_page
  3. STORE_default
  4. THEME_frontend_rwd_default
  5. cms_index_index
  6. page_two_columns_right
  7. customer_logged_out
  8. cms_menu

 

Valóban, ehhez az oldalhoz is hozzáadódott a default handle. Betöltődik még a cms_page, cms_index_index, cms_menu handle is, amely jól mutatja, hogy a főoldal is egy CMS oldal. Ugyanez a lista egy login oldalon az alábbi módon néz ki:

  1. default
  2. STORE_default
  3. THEME_frontend_rwd_default
  4. customer_account_login
  5. customer_logged_out

 

A 4. handle meghatározza, hogy most jelenleg a customer front name, account controller és login action szolgálja ki az oldalt. A főoldal esetén ez a cms front name, index controller és index action.

 

layout magento szerkezet

Layout elemek elhelyezése a Fradi webshopnál

 

Block-ok funkciója

A fenti példákban érintőlegesen szó esett már a block-okról, de most nézzük meg részletesebben, hogy mik a block-ok Magento-ban. A következő block típusok vannak a Magento-ban:

  • core/template: Ez a block típus a template-ek rendeléséért felelős. A block-ok többsége core/template típusú.
  • page/html: Ez egy core/template-ből származtatott block típus. Ez határozza meg a szülő block-ot, minden más block a page/html „gyereke” (child block).
  • page/html_head: A HTML oldal HEAD részéért felelős block típus. Segítségével a JavaScript, CSS stb. elemeket lehet definiálni.
  • page/html_header: Az oldal fejlécének a megjelenítéséért felelős. Itt van beállítva a webáruház logója, felső linkek (top links) stb.
  • page/template_links: Ez a block típus link listák létrehozására alkalmas. A linkek alapértelmezetten a fejlécben és a láblécben vannak megjelenítve a page/template_links block segítségévével.
  • core/text_list: Néhány oldalelem (content, left sidebar, right sidebar) a core/text_list segítségével van megjelenítve. Amikor ezek a block típusok kirenderelődnek, akkor az összes gyerek eleme is automatikusan kirenderelődik. Még egy fontos tulajdonsága a core/text_list típusú block-nak, hogy nincs template-je.
  • page/html_wrapper: Ez a block típus más elemek beburkolására alkalmas. Alapból a <div> taget használja.
  • page/html_breadcrumbs: Ezzel a block típussal a breadcrumb-okat lehet megjeleníteni az oldalakon.
  • page/html_footer: A lábléc megjelenítéséért felelős block típus, amiben alapértelmezetten a szerzői jog megnevezése, a lábléc linkek stb. helyezkednek el.
  • core/messages: Ez a block felel az üzenetek megjelenítéséért. Egy üzenet lehet hiba, sikeres vagy megjegyzés típusú.
  • page/switch: Ez a block típus a nyelvválasztási legördülő megjelenítéséért felel.

 

Természetesen ezek a block típusok csupán az alapértelmezett típusok, ettől eltérőek is lehetnek attól függően, hogy az adott dizájn téma vagy modul milyen más típusokat követel meg.

Minden block-nak van kötelezően egy típusa és neve. Nem kötelező a block template és az alias.

Lehet hivatkozni már létező blockok-ra a reference tag-gel. Ha van egy nagyobb block-unk és több layout fájlból szeretnénk elemeket megjeleníteni benne, akkor a reference tag-et kell használnunk. Nézzünk egy példát:

 <reference name=”right”>
<block type=”core/text” name=”right.text”>Bal oldalt megjelenő szöveg</block>
</reference>

 

A „right” nevű block-hoz adtunk egy új right.text nevű block-ot.

Ez a funkció nagyon hasznos, amikor egy meglévő oldalt szeretnénk módosítani a saját modulunkban. Lehetőségünk van már hozzáadott block-ot eltávolítani is. Nézzünk erre is egy példát:

 <reference name=”right”>
<remove name=”right.text” />
</reference>

 

Itt pont a fenti példában létrehozott right.text nevű block-ot távolítottuk el a remove tag-gel.

Ha nem tudjuk, hogy mi a neve az adott block-nak vagy melyik template felelős a megjelenítésért, akkor nagyon hasznos lehet bekapcsolni a template path hint-et. Ezt az adminban a System -> Configuration -> Developer -> Template Path Hints opciót IGEN-re kell állítani. Fontos megjegyezni itt, hogy ennek a beállításnak nincs globális beállítási lehetősége, csak website nézetben lehet beállítani. Ha szeretnénk látni a block-ok osztályát is, akkor ugyanezen a menüpontban az Add Block Names to Hints opciót állítsuk IGEN-re. Éles oldalnál vigyázzunk ezzel a beállítással, mert egy vásárló az alábbi képtől lehet, hogy megijed:

 

magento layout Template Path Hints nézet

 

Bal oldalt a template elérési útvonala, jobb oldalt pedig a block neve látható.

Lehetőségünk van csak nekünk megjeleníteni a template path hint-eket. Ilyen esetben a saját gépünk IP címét írjuk be az Allowed IPs mezőbe a System -> Configuration -> Developer menüpontban.

 

CSS és JavaScript fájlok kezelése layout-ból

Sok esetben szükségünk van külső erőforrás (CSS és JavaScript) behívására az oldalon. Ezt is a layout XML-ből lehet könnyedén elvégezni az alábbi tag-gel:

 <block type=”page/html_head” name=”head” as=”head”>
<action method=”addJs”><script>prototype/prototype.js</script></action>
</block>

<block type=”page/html_head” name=”head” as=”head”>
<action method=”addCss”><stylesheet>css/widgets.css</stylesheet></action>
</block>

Az első példában a prototype.js-t húztuk be a js könyvtárból, a második példában pedig a skin könyvtárból húztuk be a widgets.css fájlt.

 

Layout update használata

Új handle hozzáadása egy meglévő handle-höz az update XML tag-gel történik. Tegyük fel, hogy a cms_index_index layout handle content block-jához szeretnénk egy hello layout handle-t hozzáadni, amit az alábbi módon lehet megtenni:

<cms_index_index>
<update handle=”hello” />
</cms_index_index>

Ilyenkor a <hello> handle összes módosítása a főoldalra (<cms_index_index> handle) is érvényes lehet. Ez jól jön, hogyha több oldalra is ki szeretnénk rakni mondjuk egy kapcsolat formot, mivel nem kell minden egyes oldalba beillesztenünk a kapcsolat form block definicióját, hanem elég egy új handle-be beletenni és azt a handle-t a kívánt oldalakon behívni az update tag-gel (paranccsal).

Jellemző, hogy új design témák esetén a fejlesztők nem a már meglévő layout fájlokra hivatkoznak a local.xml-ben, hanem egy az egyben lemásolják azokat az ő design téma könyvtárukba. Ez a módszer elég rossz és egyáltalán nem javasolt, mert ha kijön egy olyan frissítés, ami a layout fájlokat is érinti, akkor az nem fog érvényesülni, mert az új design témában felül lesz az írva a frissítés előtti állapotra. Belátom, hogy ez a módszer kicsit körülményesebb és nem mindig lehet vele mindent megcsinálni, de erre kell törekedni.

 

Végszó

A fenti példákból is látszik, hogy a layout XML egy központi része a Magento-nak, ezért fontos azt jól ismerni. Remélem, hogy ezzel a rövid bemutatóval hasznos útmutatót tudtam nyújtani minden fejlesztőnek. Amennyiben kérdésed, van ne habozz feltenni, készséggel válaszolunk rá.

 

VirtueMart vs. Magento ‒ Melyik a jobb?

Miről fogunk beszélni?

  • Árak és költségek
  • Telepítés és használat
  • Testreszabhatóság
  • Analitika
  • SEO
  • Közösség és support – hová fordulhatsz?
  • Összegezzük
    • Mit tud a Magento?
    • Mit tud a VirtueMart?
  • VirtueMart vagy Magento? Melyiket használd?

 

magento vs virtuemart

 

A két rendszer között rengeteg alapvető különbséget észlelhetünk, aminek az egyszerű oka az, hogy a Magento eleve e-kereskedelmi rendszernek készült: elsődleges célja az, hogy webáruházakat építsünk rá, azok közül is elsősorban olyanokat, amelyek a nagyobb teljesítményt igénylik, mivel akár több ezer termékkel és nagy forgalommal működnek.

A Joomla! ezzel szemben CMS, vagyis tartalomkezelő rendszerként született (Content Management System). A VirtueMart nem más, mint a Joomla! e-kereskedelmi funkcionalitással felruházott kiegészítője.

Lássuk, hogy a két alapvetően különböző utat bejárt rendszerből melyik lehet a megfelelő egy új webáruház létrehozásához.

 

Árak és költségek

Mindjárt az elején egy olyan szempont, melyben alapvetően semmi különbség a két rendszer között: a Magento és a VirtueMart egyaránt ingyenesen letölthetőek, legalábbis a legegyszerűbb változataik. Ez adott is, hiszen mindkét webáruház szoftver nyílt forráskódú.

 

magento virtuemart ar

 

A Magento esetében alapvetően a Magento Community Edition az, amely a nagyvállalati szint alatt mozgóknak jó választás lehet: ingyenes rendszer, amelyhez ingyenes és fizető bővítményeket egyaránt letölthetünk. A költségek inkább akkor jelentkeznek, ha a rendszer képességeit fejleszteni akarjuk, megjelenését egyedire szabni. Ekkor ugyanis arra lesz szükségünk, hogy harmadik féllel egyedi fejlesztéseket készíttessünk.

A VirtueMart esetében is megtehetjük ezt, illetve léteznek a szoftvernek olyan egyedi, továbbfejlesztett változatai, amelyeket eleve megvásárolható rendszerben kínálnak.

A hoszting szolgáltatás árával mind a két esetben számolnunk kell, illetve megemlítjük még, hogy a Magento-nak létezik egy kifejezetten nagyvállalati igényekre tervezett változata, az Enterprise Edition, amely jelenleg 18 ezer dolláros éves előfizetői díjért cserébe használható.

 

Telepítés és használat

A VirtueMart telepítése és beindítása egyszerű folyamat, amelyet akár a kezdők is viszonylag zökkenőmentesen elvégezhetnek, e téren a tapasztalatok megegyeznek. A Magento telepítése sem különösebben bonyolult, bár igényelhet némi felkészültséget, ugyanakkor a működő webáruház beindítása már zavarba ejtő lehet azok számára, akik hasonló rendszerrel korábban még nem dolgoztak együtt.

A nagy erő ebben az esetben nem nagy felelősséggel, hanem nagy komplexitással jár. A Magento egy rendkívül erőteljes rendszer, amely hatalmas és bonyolult webáruházak létrehozására alkalmas ‒ értelemszerűen a kezelőfelület is tömve van olyan lehetőségekkel, amelyeknek a használatát ki kell tapasztalnunk.

 

Testreszabhatóság

A két rendszerben közös az, ami a legtöbb e-kereskedelmi szoftverből hiányzik: a frontend változatosan testre szabható, saját igényeinkhez formálható. A Joomla! egyszerűbb rendszer lévén előnyben van annyiban, hogy könnyebben lehet megjelenését módosítani, egyszerűbb extra funkciókkal kiegészíteni. A Magento azonban professzionálisabb megoldást nyújt, a shopping cart, vagyis a vásárlási folyamat terén felülmúlja vetélytársát.

A Magento-nál beépített lehetőség, hogy az egyes termékeket, termékkategóriákat szinte bárhogyan módosíthatjuk: számtalan különféle attribútumot rendelhetünk a termékekhez, amelyekre a felhasználók szűréssel kereshetnek rá.

Ennél sokkal fontosabbak a változatos promóciós lehetőségek: megtehetjük, hogy adott időn belül ajánlunk kedvezményeket, hogy pontosabb behatárolt felhasználói csoportok számára kínáljuk ezeket vagy éppen bizonyos termékeket együtt adjunk más áron. Hirdethetjük bizonyos termékek mellett azokat, amelyeket rendszeresen együtt vásárolnak. A lehetőségek száma jóformán több mint amennyit egyetlen webshop ki tud használni.

 

Analitika

A Magento-nál sztenderd, hogy igen részletes jelentéseket hozhatunk létre: tanulmányozhatjuk, hogyan teljesítenek az egyes áruk vagy árucsoportok, hogyan használják webáruházunkat a vásárlók, milyen viselkedésmintákat regisztrálhatunk. A Joomla! ezzel szemben nagyon korlátozott lehetőségeket ad, ahhoz, hogy komolyabb analitikára lehetőségünk nyíljon, különféle bővítményeket kell igénybe vennünk.

 

SEO

A Magento rendszere alapvetően jól optimalizálható, egyedi URl-eket hozhatunk létre és más opcióink is akadnak, ugyanakkor nem tartalomkezelő rendszerről beszélünk ‒ ebben az esetben tehát ez inkább extrának számít. A Joomla!bellenben CMS, így az ennek alapjaira felhúzott VirtueMart is rendkívül jól optimalizálható.

 

magento-virtuemart-seo

 

Ha olyan rendszert akarunk, amely alapvetően jól keresőoptimalizálható, e szempontból döntő különbséget igazából nem találunk. Ha a SEO kiemelten fontos szempont a stratégiánkban, mást is ennek rendelünk alá, akkor a Joomla! felé billen a mérleg nyelve.

 

Közösség és support

Mind a két platform méretes közösségeket tudhat maga mögött: rengeteg fejlesztő foglalkozik azzal, hogy a Magento és a Joomla! rendszereihez különféle kiegészítéseket, bővítményeket készítsen. Ez tehát azt jelenti, hogy ha bármilyen problémánk adódna, bőven van hová fordulnunk, könnyedén találunk olyan platformot, amelyen megtaláljuk a kompetens szakembereket.

Ezzel együtt pedig bővítményeket is könnyen találunk, ingyenes és fizetős kivitelezésben egyaránt – ez mindkét rendszer esetében hasznos, bár a Magento esetében sokszor jobban megéri egyedi fejlesztéseket készíttetni.

 

Összegezzük

 

Mit tud a Magento?

A Magento rendszer modern és folyamatosan fejlődik, hatalmas fejlesztői közösség áll mögötte, amely rengeteg ingyenes és fizetős kiegészítővel szolgál a felhasználók számára. A fejlődés folyamatos, a hivatalos cég is állandón dolgozik azon, hogy a legújabb követelményeknek megfeleltesse a rendszert, emellett pedig profi fejlesztőcsapatot is felfogadhat a webmester, hogy teljes mértékben személyre szabhassa a nyílt forráskódú szoftvert.

 

magento community demo

 

Szintén előnye, hogy sokoldalú: segítségével a frontendet úgy módosíthatjuk, ahogy csak akarjuk, és ezzel a legjobb felhasználói élményt biztosíthatjuk, az adminisztrációs felületen pedig olyan változatos beállítási lehetőségeink adódnak, hogy azzal gyakorlatilag egyetlen más ingyenesen hozzáférhető rendszer sem képes versenyre kelni.

Relatív hátrányokkal is bír természetesen a Magento. Az egyik ilyen például, hogy erős hoszting szolgáltatásra lesz szükség, a Magento ugyanis erőforrás-igényes rendszer. Ez persze különösen akkor igaz, ha nagy termékszámmal és nagy forgalommal dolgozunk, ekkor pedig bármilyen szolgáltatásnál erős hosztingra lenne szükség ‒ a különbség, hogy a Magento bármilyen méretű webshopot könnyeden képes kezelni.

A komplexitás is hátrány lehet, ha kezdő felhasználó fogna bele a webshop létrehozásába. A Magento elképesztő mennyiségű beállítási lehetőséggel, opcióval rendelkezik, a testreszabási lehetőségek, bővítmények, az egyedi fejlesztések pedig még tovább fokozzák ezt. A Magento kezeléséhez tehát gyakorlat szükséges, első webshopként kevéssé ajánlott, mert a rutintalan webmester valószínűleg nehezen ismeri ki magát a rendszerben.

Éppen ezért valószínűleg szükségünk lesz profi segítségre is, fejlesztőkre, akik ideálissá kovácsolják nekünk a Magentót – e munkához pedig büdzsét kell elkülönítenünk.

 

Mit tud a VirtueMart?

Legjelentősebb előnye a Magento-val szemben a Joomla! kiegészítésének, hogy egyszerűbb. Az alacsonyabb szintű tudással bíró felhasználók is viszonylag egyszerűen képesek lehetnek arra, hogy menedzseljék a rendszert, hogy bővítményeket keressenek és telepítsenek. Jellemzően a VirtueMart használatakor nincsen szükség arra, hogy külön fejlesztővel dolgoztassunk, mert az egyszerűbb igényekre már léteznek jól alkalmazható bővítmények, illetve olyan VirtueMart-variánsok, melyek megfelelő funkcionalitással bírnak.

 

virtuemart termékoldal

 

A VirtueMart a tartalomkezelés terén is előnyben van ‒ nem nagy meglepetés ez, hiszen a Joomla! eleve egy tartalomkezelő rendszer. Segítségével a webáruházat könnyedén kiegészíthetjük bloggal, vendégkönyvvel, fórummal vagy más tartalomra fókuszáló felületekkel. Az pedig, hogy a tartalmakat könnyebben jeleníthetjük meg, persze a SEO-ban is segít.

Hátránya, hogy fejlesztése igen lassú ütemben halad, nehezen tartja a lépést, illetve a fejlettebb funkciók hiánya az alap rendszerből. Komolyabb webshop-funkciókhoz akkor férhetünk csak hozzá, ha a VirtueMart továbbfejlesztett, fizetős változatait használjuk, és még ezekhez is jó eséllyel szükségünk lesz különféle bővítményekre.

 

VirtueMart vagy Magento?

Mi a végső ítélet? Az, hogy mind a két rendszer alapvetően jól működik, ám nem ugyanazok igényeit szolgálja ki.

Az Aheadworks idei februári tanulmánya szerint az Alexa adatai alapján legnépszerűbb egymillió oldal e-kereskedelmi piacán a Magento CE 25%-os részesedéssel bír, a nagyvállalati, évi 18 ezer dolláros előfizetéssel igénybe vehető Enterprise kiadás pedig további 4,5%-ossal. A VirtueMart részesedése ezzel szemben mindössze 3,5% ‒ amivel természetesen még mindig az egyik legnépszerűbb rendszernek számít (a hatodik helyen áll).

A VirtueMart egyszerű, könnyen kezelhető és gyors rendszer, sok funkció azonban, amely a Magento-ban sztenderdnek számít, hiányzik belőle. A Magento pedig egy masszívabb, komplexebb, nagyobb energiabefektetést megkívánó rendszer.

Aki tehát egy egyszerű megoldásra vágyik, kisebb méretű webshopot indítanak, aki a tartalompublikáció mellett értékesítene termékeket vagy legelső webshopját indítja, jobban járhat a Joomla! VirtueMarttal.

Aki pedig egy komoly, komplex, a végletekig testreszabható és optimalizálható, professzionális webboltot hozna létre, több száz vagy ezer termékkel, nagy forgalomra tervezve, annak a Magento CE tökéletes választásnak bizonyulhat.

 

Hogyan fejlessz extrém gyors Magento indexelő megoldást?

Az adatbázisban lévő adatoknak egy részét feldolgozatlanul, úgymond nyers formában jelenítjük meg a felhasználónak, más adatokat feldolgozva jelenítünk meg, és vannak adatokat, melyeket egyáltalán nem jelenítünk meg. Az adatokat a lehető legkisebb egységekre bontva kell tárolni. Ez az adatbázis normalizálás egyik alapfeltétele, amely meghatározza, hogy az adatbázis tábla egy oszlopa egy elemi érték legyen.

A normalizált adatbázis következménye a hatékony információ tárolás, viszont ez lassítja a feldolgozást és a megjelenítést. Nem normalizált adatbázis esetén megjelennek az anomáliák, így ebből nem engedhetünk. Viszont a felhasználónak gyorsan szeretnénk megjeleníteni az adatot. Megoldás: az adatokat egy közös táblába szervezzük, melyből feldolgozás nélkül tudjuk az adatok megjeleníteni. A közös adatokat tartalmazó tábla a flat tábla, és az ezt karbantartó eljárás az indexelés. A cikk bemutatja azokat a szemléleteket, melyekkel a Magento keretrendszerét kihasználva gyorsíthatjuk a feldolgozást és megjelenítést, anélkül, hogy engednénk az adatbázis normalizáltságából.

 

A cikk a következő témákat fogja érinteni:

  • A nem normalizált adatbázis anomáliái
  • Indexelővel kapcsolatban támasztott követelmények
  • Eseményvezérelt indexelés
  • Indexelés megvalósítása Magento-ban
  • Konkluzió

 

magento indexelés flat tábla fejlesztő

 

A nem normalizált adatbázis anomáliái

 

Jelen cikkben csak az anomáliák okát és következményeit tárgyaljuk, azoknak a kezelésére nem térünk ki.

A normalizált adatbázis előfeltétele, hogy a tábla minden oszlopa, vagyis egy rekord minden eleme, egyetlen elemi érték legyen. Ne legyenek megegyező sorok, és a sorok sorrendje ne hordozzon információt.

 

Háromféle anomália jelentkezhet nem normalizált adatbázis esetén:

  1. Módosítási
  2. Beírási
  3. Törlési

 

  1. Módosítási anomália akkor jelentkezik, ha egy attribútum több táblában szerepel. Ez esetben módosításkor több helyen kell módosítani, ha ez nem történik meg, akkor az adatbázisunk inkonzisztens lesz.
  2. Beírási anomália akkor keletkezik, ha egy információ hiánya miatt egy sort nem tudunk felvinni. Ennek eredménye információvesztés.
  3. Ha olyan adatokat törlünk, melyekre még szükség lenne, akkor törlési anomáliáról beszélünk. Ez esetben is információvesztés a következmény.

Ahhoz, hogy az anomáliákat elkerüljük, adatbázisunkat normalizálnunk kell adatbázis normálformák szerint.

 

Indexelővel kapcsolatban támasztott követelmények

 

Az indexelő feladata, hogy gyorsítsa az adatok megjelenítését. Viszont, ahogy a fentiekben kiderült, az indexelt tábla nem elemi adatokat tartalmaz, hanem már feldolgozott adatokat. Így már elemi szinten megbukik a normalizáltsági teszten. Ezért bizonyos követelményeket kell vele szemben támasztani.

 

A fő követelményt nagyon egyszerű megfogalmazni:

  • Ha egy flat táblát törlünk rendszerből, akkor az ne okozzon anomáliát.
  • A rendszer flat tábla nélkül is működjön. -> Flat tábla nem a rendszer része.

 

Az első követelményt úgy tudjuk teljesíteni, ha a táblába csak az indexelő eljárás ír, és minden teljes indexelés előtt töröljük a táblát.

Mi van akkor, ha olyan adatot törlünk, amire szükség lett volna?

A válasz triviális. Nem tudunk olyan adatot törölni, a flat tábla nem a rendszer része, csak segít megjeleníteni az adatokat. A rendszernek nélküle is kell tudni működnie.

tips Példa: Összeállítjuk a flat táblát, de közben törlünk egy rekordot, melyre már nem volt szükség. Ekkor a flat táblában szereplő adatok már nem lesznek aktuálisak. Amikor újraindexelünk, lesznek olyan adatok, melyek már nem kellenek. Ha nem töröljük a flat táblát, akkor ellenőriznünk kellene, hogy van-e létjogosultsága az adott értékeknek, ami hosszú és bonyolult folyamat. Az egész tábla törlése és újra felépítése a legjobb megoldás. Ezt a későbbiekben említett egyéb okok is alátámasztják.

A gyorsulás oka, hogy csak azok az adatok szerepelnek a táblában, melyekre szükség van. Viszont ezeket az adatokat karban kell tartani, az igényeknek megfelelően a lehető legfrissebb állapotot biztosítani. A rendszer legfőbb szempontja a gyorsaság és a hatékonyság. Viszont az alrendszerek feladatmegoldási hatékonysága között nagyon nagy eltérések vannak.

 

Általános megoldás:

magento indexelés folyamat flat tábla

1. Indexelési folyamat vázlata

 

Az ábrán a lépések a következők:

  1. PHP lekéri az indexelendő rekordokat. Ezeket több táblából, több modellen keresztül.
  2. Ezután a MySQL elküldi a kért adatokat.
  3. A PHP feldolgozza a rekordokat ciklusok segítségével. Gyakran több egymásba ágyazott ciklussal.
  4. PHP egyenként visszaküldi a rekordokat.
  5. MySQL visszaírja.

Előnye: Egyszerű, átlátható logika.

Hátránya: Nagyon lassú. A flat táblával kapcsolatos követelmények kielégítésére alkalmatlan. Vannak olyan rendszerek, ahol kielégítő teljesítményt nyújt, de használata nem ajánlott.

 

Optimális megoldás:

optimális magento indexelési folyamat flat tábla

2. Indexelés folyamata

 

Optimalizált lépések:

  1. A PHP modellek segítségével összeállítja a flat táblát visszaadó lekérdezést.
  2. MySQL ezt a SELECT-et végrehajtja és beírja a kapott táblát az adatbázisba.

Előnye: Nagyon gyors, esetenként akár 30-szoros gyorsulás. Kiküszöböli a két rendszer közötti kommunikáció veszteséget. Kielégíti a követelményeket.

Hátránya: A lekérdezés gyakran nagyon bonyolult és átláthatatlan. Ritkán előfordulhat olyan eset, amikor a MySQL nem rendelkezik a megfelelő tudással, hogy a feldolgozott adatot elő tudja állítani. Ekkor egy optimalizált hibrid megoldást kell használni, amely feladatfüggő.

 

Eseményvezérelt indexelés

 

Az indexelés folyamatát indíthatjuk manuálisan, esetleg cron segítségével. Ebben az esetben teljes reindexelésre van szükség, hisz nem tudjuk, mely rekordok nem aktuálisak. Dilemmát okoz az is, hogy milyen gyakran fusson a reindex.

A teljes reindex nélkülözhetetlen, hiszen sebesség szempontjából meghatározó, hogy csak a releváns adatok vannak a táblában. Viszont minden egyes módosulás után lefuttatni költséges, és többet veszítünk vele, mint amit nyerünk. Ennek kiküszöbölése érdekében ki kell alakítani olyan folyamatokat, amelyek csak adott sorokat indexelnek. Ez nagyon egyszerű, hiszen a SELECT lekérdezés WHERE feltételében leszűrjük a rekordokat az adott feltétel szerint.

Az adatbázis táblákat úgy alakítjuk ki, hogy a beszúrásnál a MySQL automatikusan tudja, hogy egy rekord új, vagy már létező rekord és csak módosítani kell.

 

Két dolgot kell meghatározni:

  1. Mikor fusson a reindex?
  2. Mely rekordok legyenek reindexelve?

 

Akkor kell futnia a reindexnek, ha egy adat a forrás táblában megváltozik, és azokon a rekordon, melyben az adat van.

Megvalósítás: Eseményeket definiálunk, melyek bekövetkeztekor tudjuk, hogy változtak adatok a forrás táblában. Ha az esemény bekövetkezik, akkor az adott rekordokra lefuttatjuk az indexet.

 

Indexelés megvalósítása Magento-ban

 

Flat tábla kialakítása

A flat táblát úgy kell kialakítani, hogy beszúrásnál a MySQL meg tudja állapítani, hogy új rekorddal vagy egy létező rekorddal van dolga. Erre a megoldás az egyedi index.

config.xml: Meg kell adnunk a táblánk nevét.

<entities>
    <index_table>
        <table>custom_index_table</table>
    </index_table>
</entities>

Regisztráljuk az indexelőt:

<global>
    ......
    <index>
        <indexer>
            <some_key>
                <model>module/model</model>
            </some_key>
        </indexer>
    </index>
    ......
</global>

Code: Installer-ben hozzáadjuk az unique indexet.

$table->addIndex(
    $installer->getIdxName(
        'your_namespace/your_table',
        array(
            'column1',
            'column2',
            'column3',
        ),
        Varien_Db_Adapter_Interface::INDEX_TYPE_UNIQUE
    ),
    array(
        'column1',
        'column2',
        'column3',
    ),
    array('type' => Varien_Db_Adapter_Interface::INDEX_TYPE_UNIQUE)
);

 

Ezzel semlegesítettük, hogy a rekordok többszörösen is szerepeljenek a táblában.

 

Az index folyamat megvalósítása

A tényleges függvényeket egy helper-ben valósítjuk meg.

3 függvényt kell implementálnuk:

  • runReindex($id) – privát
  • reindexAll() – publikus
  • reindexById($id) – publikus

 

Runindex metódus

 

Első körben beállítjuk az adatbázis adatptert:

$resource = Mage::getSingleton('core/resource');
$adapter = $resource->getConnection('core_write');

Ezután lekérdezzük a modellt, melyhez hozzákapcsoljuk (join) a többi táblát:

$collection = Mage::getModel('namespace/model')
    ->getCollection()
    ->removeAllFieldsFromSelect()
    ->removeFieldFromSelect('id');

A SELECT összes oszlopát kivesszük, hogy azt majd az indextáblához tudjuk igazítani. Ezután összekapcsoljuk (join) a táblákat, melyekből még szükség van adatra.

Például ORDER ITEM join:

$collection->getSelect()->joinLeft(
    array('order_item' => Mage::getSingleton('core/resource')->getTableName('sales/order_item')),
    'order_item.order_id = main_table.order_id',
    array()
);

Ezután beállítjuk a flat táblával ekvivalens oszlopneveket és oszlopsorrendet tartó struktúrát.

$columns = array(
    'column1',
    'column2',
    'column3',
);

$collection->getSelect()
    ->columns('wishlist_item.product_id AS column1')
    ->columns('GROUP_CONCAT(customer_id SEPARATOR ",") AS column2')    ->columns('SUM(wishlist_item.qty) AS column3');

Előállítjuk a flat táblát adó lekérdezést:

$select = $collection->getSelect();

Futtatjuk a lekérdezést és beszúrjuk a táblába:

$sql = $adapter->insertFromSelect($select,
    Mage::getSingleton('core/resource')->getTableName('namespace /custom_index_table'),
    $columns,
    Varien_Db_Adapter_Interface::INSERT_ON_DUPLICATE);

$adapter->query($sql);

 

Amint látjuk, a kommunikáció minimális a két alrendszer között. A PHP átadja a flat táblát visszaadó lekérdezést. A MySQL futtatja ezt és beírja az adatbázisba.

 

ReindexById metódus

A SELECT rekordjait le kell szűrni:

$collection->getSelect()->where('id = '.$id); 

 

ReindexAll

Az index táblát ürítjük. Lekérdezzük az összes rekord azonosítóját és meghívjuk a runReindex($id) metódust.

 

Események jelzése

<?php
class Namespace_Model_Model extends Mage_Sales_Model_Order_Item
{
    const ENTITY = 'namespace_model_model';

     /**
      * Before Delete
      */
     protected function _beforeDelete()
     {
         parent::_beforeDelete();

         Mage::getSingleton('index/indexer')->logEvent(
             $this, self::ENTITY, Mage_Index_Model_Event::TYPE_DELETE
         );
     }

     /**
      * Before Save
      */
     protected function _beforeSave()
     {
         parent::_beforeSave();

         Mage::getSingleton('index/indexer')->logEvent(
            $this, self::ENTITY, Mage_Index_Model_Event::TYPE_SAVE
         );
     }

     /*
      * After Save Commit
      */
     protected function _afterSaveCommit()
     {
         parent::_afterSaveCommit();

         Mage::getSingleton('index/indexer')->indexEvents(
             self::ENTITY, Mage_Index_Model_Event::TYPE_SAVE
         );
     }

     /*
      * After Delete Commit
      */
     protected function _afterDeleteCommit()
     {
         parent::_afterDeleteCommit();

         Mage::getSingleton('index/indexer')->indexEvents(
             self::ENTITY, Mage_Index_Model_Event::TYPE_DELETE
         );
     }

 }

Az adat 2 esetben változhat. Módosítás és törlés esetén, így ezekre kell az eseményeket ütemezni. Amint látjuk, a Magento megkülönbözteti az index eseményeket. A programozó belátása a későbbiekben, hogy melyik eseményeket kell figyelnie az indexelőnek.

Ha egy olyan eseményre akar feliratkozni az indexer, amely nincs jelezve, és a Magento magban (core) található, akkor felül kell írni az eredeti osztályt. Ennek az osztálynak az eredeti osztályból kell származnia.

 

Magento Indexer megvalósítás

A modulunk modell könyvtárába létre kell hozni az indexelő osztályt, amely figyeli az eseményeket és futtatja az indexelő folyamatokat. Ennek az osztálynak a Mage_Index_Model_Indexer_Abstract osztályból kell származnia.

class Namespace_Model_Indexer extends Mage_Index_Model_Indexer_Abstract

Következő lépésben fel kell iratkozni az eseményekre, ezt egy osztály tömbbe deklaráljuk:

/**
 * Index matched Entities array
 *
 * @var array
 */
protected $_matchedEntities = array(
    Namespace_Model_Model::ENTITY => array(
        Mage_Index_Model_Event::TYPE_SAVE,
        Mage_Index_Model_Event::TYPE_MASS_ACTION,
        Mage_Index_Model_Event::TYPE_DELETE
    ),
);

 

Kicsit feljebb deklaráltuk a modell eseményeit. A fenti kódból láthatjuk az osztályban található ENTITY konstans funkcióját. Ezzel azonosítjuk a modellt. Meg kell valósítani az absztrakt metódusokat:

/**
 * @return bool
 */
public function isVisible()
{
    return true;
} 

/**
 * Retrieve Indexer name
 *
 * @return string
 */
public function getName()
{
    return Mage::helper('namespace')->__('Custom indexer');
} 

/**
 * Retrieve Indexer description
 *
 * @return string
 */
public function getDescription()
{
    return Mage::helper('namespace')->__('Reorganize custom flat data');
} 

/**
 * Rebuild all index data
 */
public function reindexAll()
{
    Mage::helper('namespace/indexer')->reindexAll();
}

 

Esemény felismerés és kezelés

Ezt a _registerEvent metódus megvalósításán keresztül tudjuk megtenni.

/**
 * Register indexer required data inside event object
 *
 * @param   Mage_Index_Model_Event $event
 */
protected function _registerEvent(Mage_Index_Model_Event $event)
{
    $dataObj = $event->getDataObject();
    if($event->getType() == Mage_Index_Model_Event::TYPE_SAVE){
        $event->addNewData('id, $dataObj->getId());
    }elseif($event->getType() == Mage_Index_Model_Event::TYPE_DELETE){
        $event->addNewData('id, $dataObj->getId());
    }
}

Detektáljuk, milyen esemény történt, és hozzáadjuk az indexeléshez szükséges adatokat. Példánkban a modell azonosítót, mivel ez alapján indexelünk. De az események kezelése lehet egyedi, és igényelhet különböző adatokat.

 

Indexelés futtatás

 A tényleges indexelés a _proccessEvent metóduson keresztül történik.

/**
 * Process event based on event state data
 *
 * @param   Mage_Index_Model_Event $event
 */
protected function _processEvent(Mage_Index_Model_Event $event)
{
    $data = $event->getNewData();
    if(!empty($data['id'])){
        Mage::helper('namespace/indexer')->reindexById((int)$data['id']);
    }
}

 

Összefoglalás

A gyorsaság optimalizálása minden rendszer esetében az elsődleges szempontok között szokott lenni. (Kivéve a banki alkalmazásokat, ahol a biztonság az egyetlen szempont.) A flat táblák a megjelenítés gyorsaságát tudják biztosítani, mellyel már van egy piros pontunk a felhasználónál.

Használatuk összetett entitások esetén javasolt, ahol nagyon sok táblában van az információ. Mivel a szűk keresztmetszetet az adatbázis szegmens okozza, így a problémát itt kell kezelni, és a szegmensek között a kommunikációt minimalizálni kell. A flat táblák használatának előnye a gyorsaság, mellyel elérjük, hogy a felhasználó kényelmesen tudja böngészni oldalunkat, és gyorsan megtalálja, amit keres.

 

Mit kell mérned, ha webáruházat üzemeltetsz, és hogyan javíthatod az eredményeket?

Egy webshop optimalizálására rengeteg alkalom kínálkozik – felkutathatunk best practice-eket, esettanulmányokat, végül azonban minden esetben a saját tapasztalatok, a saját közönségünk viselkedése lesz az, ami alapján eldönthetjük, lesz-e hasznunk egy adott módosításból vagy sem.

 

Miről fogunk beszélni a következőkben?

  • Mire figyeljünk kiemelten az Analyticsben?
    • Közönség – ki látogat, ki vásárol és hogyan?
    • Akvizíciós jelentések, avagy konverziós ciklusok az oldaladon
    • Viselkedés – miért teszi a vásárló, amit tesz?
    • Konverziók – hol, hogyan, és ha nem, miért nem?
  • Miért ne figyeljünk egyszerre mindenre?
  • Tippek, hogy javíthass a számokon
    • Csökkentsd a betöltési időt
    • Minden információt adj meg
    • Adj exkluzív ajánlatokat viselkedés alapján
    • Egyszerűsítsd a végletekig a check-outot
    • Ha valami nem működik, gyorsan szabadulj meg tőle
  • Csak ennyi a dolgod?

 

A legtöbb e-kereskedelmi rendszer kínál valamilyen alapvető lehetőséget arra, hogy adatokat gyűjtsünk, ha azonban komolyabb adatbázist akarunk építeni, akkor a Google Analytics integrálására mindenképpen szükségünk lesz. Az Analytics azonban elképesztően sokféle információt képes számunkra biztosítani, ezekből ki kell válogatnunk azt a néhány mérőszámot, amelyet folyamatosan követünk majd.

 

Mire figyeljünk kiemelten a Google Analyticsben?

 

webaruhaz analitika google analytics

 

Az e-kereskedők számára létfontosságú jelentéseket és mérőszámokat négy főbb csoportba oszthatjuk az Analyticsben. Ezek az alábbiak:

 

Közönség

 

Bármely e-kereskedelemmel foglalkozó oldal számára az első, amit pontosan mérnie kell, az a közönség. A vásárlók életkora, a visszatérők aránya és az ehhez hasonló információk mind itt találhatóak – ahhoz, hogy bármilyen marketingkampányt hatékonyan építhessünk fel, hogy különféle buyer personákra célozhassunk, mindezeket ismernünk kell és hozzájuk igazodni.

Itt találod a demográfiai adatokat. Ismert az, hogy a vásárló kora, neme nagyban befolyásolhatja vásárlási szokásait, ahogyan azt is, hogy egy adott kampányra, üzenetre hogyan reagál, hogy milyen hatékonyan célozható meg adott termékekkel. Ennek megfelelően módosíthatjuk kínálatunkat is – ha azt látjuk, hogy a webáruházat másfajta közönség látogatja, mint amilyenre eredetileg céloztunk, kitalálhatunk olyan akciókat, bevezethetünk olyan termékeket, amelyek a számukra csábítóak.

A Közönség > Demográfiai adatok alatt öt különféle dimenzióhoz férhetünk hozzá, ezek a Kor, Nem, Vonzódási kategóriák, Aktív piaci szegmensek és Egyéb kategóriák.

A földrajzi adatok is fontosak lehetnek adott esetben – egy profi webáruház alkalmazhat például időjárás alapú szegmentációt: esernyőt kínálhatnak olyan helyeken, ahol éppen vihar van, napszemüveget, ahol napsütés és így tovább. Nem hátrány az sem, ha tudjuk, mely városokban, régiókban a legnépszerűbbek a termékeink, hogyan viselkednek az egyes földrajzi szegmensek.

 

Akvizíciós jelentések

Az akvizíciós jelentések komplexebb információkat adnak, az akvizíciós-viselkedés-konverzió-ciklusáról, röviden az ABC-ciklusról tudhatunk meg többet. Ez annyit jelent, hogy tudhatjuk, hogyan szerzünk ügyfeleket, hogyan viselkednek a „megszerzés”, vagyis az akvizíció után az ügyfelek a webhelyen, és milyen konverziós minták kapcsolhatóak hozzájuk.

Ha például használunk AdWords hirdetéseket, akkor ezek adatait integrálhatjuk az Analytics-be, és a vásárló teljes életciklusát végigkövethetjük az első kattintástól a konverzióig.

 

Viselkedés

A viselkedés is rendkívül fontos – innen tudjuk azt például, hogy a látogatók, a vásárlók visszatérnek-e az oldalra. Ha látogatók közül sokan visszatérnek, de kevesen vásárolnak, az azt jelentheti, hogy termékeink vonzók, de konverzióhoz még szükség lehet egy kis lökésre, például személyre szabott kedvezményekre. Ha a visszatérő vásárlók aránya alacsony, akkor meg kell vizsgálnunk, hatékonyan aktiváljuk-e újra őket, milyen e-mail marketing kampányt folytatunk, vannak-e negatív visszajelzések a teljesítéssel kapcsolatban.

 

webáruház analitika látogató viselkedés
Fotó forrása: E-commerce via photopin (license)

 

 

A viselkedési adatokat a Közönség alatt találjuk meg, jóval többről van azonban szó egy egyszerű alpontnál. Láthatjuk, hogyan hat a viselkedésre a betöltési sebesség (a felhasználók nem díjazzák, ha az oldalad lassú, hajalmosak akár már néhány másodperc után elhagyni), a tartalom (mennyi időt töltenek az oldalon, mekkora a lepattanások aránya stb.), azt is, hogyan használják a keresést (milyen kulcsszavakat használnak, mennyire releváns eredményeket kapnak).

 

Konverziók

Ahhoz, hogy konverziós jelentéseket tekinthessünk meg, az Analytics-et össze kell hoznunk a webáruház rendszerével – tekintve, hogy sok különféle fizetési modult, check-out technikát alkalmazhatunk az oldalon. A konverziós jelentéseken belül is számos alkategóriát találunk, például a vásárlói viselkedést, amely elárulja, hogy milyen oldalakat keresnek fel a vásárlók, hogyan használják a keresőt – és innen bányászhatjuk ki a kosárelhagyással kapcsolatos információkat is, amelyek különösen fontosak lehetnek.

 

webáruház analitika konverzió

 

A kosárelhagyás minden webáruházat érintő probléma, azok nagy része ugyanis, akik termékeket helyeznek a kosárba, végül nem fizetik ki, nem rendelik meg azokat. Ennek rengeteg oka lehet: a túl hosszú check-out procedúra, az, hogy előre nem figyelmeztettük őket a kiszállítási árra vagy más félreérhető információt adtunk oldalainkon, vagy éppen az, hogy csak úgymond listát készítenek, amelyet később, ha már ténylegesen vásárolni akarnak, könnyebben megtalálnak. Ha a konverziós jelentésekben figyelemmel kísérjük a számokat, akkor nagyban javíthatunk a konverziós arányon a hibák kijavításával.

Arról is itt kaphatunk információkat, hogyan teljesítenek az egyes termékek – melyek a legnépszerűbbek, melyeket nem vesznek meg látogatóink, milyen úton jutnak el a termékekhez, melyeket veszik meg általában együtt és így tovább. Hogy ez miért fontos, könnyen belátható – a rosszul teljesítő termékek esetében finomíthatunk a marketingen vagy akár a kínálaton, az együtt vásárolt termékeket kínálhatjuk eleve csomagban akár.

 

Miért ne figyeljünk egyszerre mindenre?

 

Azért kell meghatároznunk az aktuálisan legfontosabb mérőszámokat, mert az optimalizálás aprólékos és szakadatlan folyamat. Közönségünk, kínálatunk, oldalunk mindig változik, így sohasem mondhatjuk azt rá, hogy „készen van”, hogy nincsen vele többé dolgunk.

Ha viszont minden egyes adatot be akarunk építeni a stratégiába, ahhoz egész csapatra lesz majd szükségünk – rendkívül komplex terveket kell készítenünk, ezeknek megfelelően elvégezni az oldalon a szükséges módosításokat, és persze mindent letesztelni. Ez rengeteg időt és erőforrást emészt fel, ezért a legjobb, ha a számunkra legkritikusabb pontokat azonosítjuk, és kifejezetten azokra koncentrálunk.

 

webáruház analitika fókusz

 

Naivitás azt hinni, hogy egy nagyvállalat számára, ahol saját online marketinges és fejlesztőcsapat áll rendelkezésre, ez könnyű feladat. Ha egyszerre mindent akarunk, egyszerűen nem leszünk képesek érdemi következtetéseket levonni az irgalmatlan adathalomból.

Így nemcsak a tervezés, elemzés válik reálisan is elvégezhető munkává, a fejlesztőnek is egyszerűbb dolga van, és azt is megtehetjük, hogy egy időben csak néhány A/B tesztet futtatva pontos eredményeket kapjunk az optimalizáció eredményeiről.

 

tips Tippek, hogy javíthass a számokon:

 

Minden weboldal más – tartalma, megjelenése, kínálata, a rendszer funkciói mind befolyásolhatják azt, hogy mennyire sikeres.

Van azonban néhány alapvető irányelv, amelyet követve növelhetjük konverziós arányunkat, közönségtől és a technikai megoldásoktól függetlenül.

 

Csökkentsd a betöltési időt

A vásárlók mindig türelmetlenek, s ez a mobilkorban egyre inkább igaz. Egyre többen és többen vásárolnak mobiltelefonról, tablet gépről, így biztosítanunk kell azt, hogy minden egyes oldalunk villámgyorsan betöltődjön. Ha néhány másodpercnél tovább kell várnia a felhasználónak, otthagy majd minket, és a konkurenshez pártol.

 

webshop analitika oldal betöltési sebesség

 

Minden információt adj meg

A neten minden vállalat meztelen. Az információk ma már könnyen kereshetőek, a felhasználók pillanatok alatt kikérhetik mások véleményét, más platformokon kérdezhetnek rá a termékeinkkel, árainkkal kapcsolatos dolgokra. Arra kell törekednünk, hogy egyáltalán ne maradjanak kérdéseik – intuitív kezelőfelületet adni nekik, amelyen könnyen eligazodnak, és az olyan információkat, mint például a szállítási költség, feltüntetni a termékoldalakon. Soha ne érje őket kellemetlen meglepetés, mert ezzel vásárlókat veszítünk, és a nyilvános visszajelzések révén talán nem is egyesével.

 

Adj exkluzív ajánlatokat viselkedés alapján

 

  • Ha azt látod, hogy valaki el akarja hagyni az oldaladat anélkül, hogy vásárolt volna, dobj elé egy felugró üzenetet, amiben egy, csak akkor és ott érvényes kedvezményt adsz.
  • Ha egy felhasználó rendszeresen vásárol nálad azonos termékeket, küldj neki egy e-mailt és ajánld fel, hogy automatikusan kiküldöd majd neki ezeket, anélkül, hogy rendelnie kellene.
  • Ha valaki telepakolja a kosarát, de nem vásárol, küldj neki e-mailt arról, hogy ezeket a termékeket, valamilyen kedvezménnyel megveheti.

 

A lehetőségek végtelenek, és hála az adatoknak, minden egyes látogatód viselkedését hajszálpontosan követni tudod. Nincs más dolgod, mint hogy egy olyan adatbázist építs, egy olyan rendszert hozz létre, amelyben bizonyos ajánlatokkal automatikusan megkeresed az adott viselkedésmintát mutatókat.

Ha már kiismerted, hogyan használja valaki a keresőt, vagy milyen termékeket néz szívesen, ajánlj neki minden egyes oldalon a preferenciáinak megfelelő termékeket, ha pedig azt látod, hogy csak nézelődik, akkor irányítsd át olyan tartalmaidra, amelyek meggyőzhetik arról, hogy érdemes most és nálad vásárolnia.

 

Egyszerűsítsd a végletekig a check-outot

Mindenképpen olyan módszert alkalmazz, amely a lehető legkevesebb erőfeszítést követeli meg a potenciális vásárlótól a fizetéshez. Ne vezesd át öt különféle oldalon, ne kérj tőle regisztrációt, és ne kérd el még a vércsoportját is. Egy-két oldalban, minden szükséges információt megadva kérd el a fizetéshez és szállításhoz legszükségesebb adatokat, és készen is van.

 

webshop analitika fizetési folyamat

 

Ez emelni fogja a konverziós arányt és javítja a felhasználói élményt. A kosárelhagyók nagy arányban azért nem konvertálnak végül, mert túlságosan sokat követel meg tőlük a webáruház.

Mindenképpen kérd el az e-mail címüket, és innen már simán megy a marketing: a későbbiekben rájuk szabott egyedi ajánlatokkal, tartalmakkal keresheted meg őket – de ezt tényleg hagyd a későbbiekre, és ne akarj mindent azonnal lenyomni a torkukon.

 

Ha valami nem működik, gyorsan szabadulj meg tőle

A kuponok, akciók, ajánlatok, de még a termékek között is lesznek olyanok, amelyeket egész egyszerűen nem szeretnek majd a felhasználók – sőt, akár olyanok is, amelyeket valamiért nem éri meg fenntartanod.

Ezekhez ne ragaszkodj, inkább találj ki folyamatosan újakat. A vásárlói viselkedés alapján korlátlan mennyiségű kreatív vevőszerző módszert találhatsz ki, új és új megoldásokat találhatsz a vásárlások átlagos értékének növelésére, de ez csak akkor fog menni, ha van füled arra, amit az adatok üzennek neked.

 

ÖSSZEFOGLALÁS

 

Leírva talán mindez egyszerűbbnek hathat, ezért is fontos hangsúlyozni, hogy állandó feladatról van szó: az optimalizáció szünet nélküli kell legyen, különben egy jól sikerült átalakítás vagy kampány után azt veszed majd észre, hogy konverziós arányod ismét csökken.

Webáruházadon gyorsan kell tudnod változatni, hogy reagálhass a váratlan helyzetekre is (például egy kiemelten sikeres viral tartalom által az oldalra irányított, korábban el nem ért nagyobb közönség megjelenésére), és minden rendszeredet egyszerre kell idomítanod – tartalmaidat, magát a webáruházat, AdWords reklámjaidat, e-mail kampányodat mind össze kell hangolnod azért, hogy minél többeket érj el, és hogy őket valóban el is juttasd a konverzióig – lehetőleg minél többször.

 

webáruház analitika folyamatos munka

Soha nincs megállás. A webáruház elemzése folyamatos munkát igényel.

<p[/highlighted]