A Yahoo Web Analytics vége?

2012. június 15. 11:22 - Deli Norbert - HD

 

yahoo web analytics.JPGEzen a héten - egy blogbejegyzésben - jelentette be a Yahoo, hogy webanalitika szolgáltatását október végétől leállítja a nagyközönség számára. Bár a Yahoo! Store felhasználóknak továbbra is nyújtják a szolgáltatást, de valószínű, hogy azt a részt is le fogják állítani idővel.

A Yahoo Web Analytics  - a néhány tucatnyi - ingyenes, cookie alapú webanalitikai eszközök egyike volt, amely a Google Analytics után és a Piwik mellett a legtöbb felhasználóval rendelkezett. 

A piacról való eltűnése/kilépése még inkább egyeduralkodóvá teszi a Google eszközét az ingyenes megoldások között. 

A Yahoo Web Analytics története

Az eszköz története magyar sikersztoriként indult, hiszen a 2001-ben alapított és a 2008. áprilisában bekövetkezett felvásárlásig a magyar alapítók kezében lévő IndexTools-ra épült teljes mértékben.

A magyar fejlesztőket megtartották és azóta is Budapesten volt az eszköz fejlesztési részlege, amely otthont ad az évente 1-2 alkalommal megrendezésre kerülő Web Analytics Wednesday nevű szakmai esteknek.

A felvásárlás nagyon hasonlított a Google - Urchin fúzióhoz. Egy szakmailag elismert, de fizetős webanalitikai szolgáltatót vett meg egy óriáscég. A felvásárlás után a fejlesztői gárda megmarad, a marketing gépezet átalakítja az eszköz felületét/kinézetét, saját nevet ad neki, majd ingyenesen teszi rövid időn belül újra elérhetővé.

A Yahoo-IndexTools beolvadás bár 3 évvel követte a Google Analytics létrejöttét, de az induláskor olyan lehetőségeket nyújtott, amit a Google csak évekkel később vezetett be.

Ilyen volt például:

  • • az egyéni riportok, egyéni irányítópultok létrehozása
  • • az utólagos adat szegmentási lehetőség
  • • a PPC kampányok részletesebb elemzése

 

Tehát 5 évvel ezelőtt még minden esélye megvolt a Web Analytics-nek a sikerre, hogy akár legyőzze a Google Analytics-et is. 

A Google minősített tanácsadói hálózatát lemásolva külső szolgáltatókat vontak be az eszköz terjesztésében, akik az - ingyenesség miatt kevés háttér támogatást nyújtó - anyacég mellett professzionális szolgáltatásokat nyújtanak a mérés beállítások, a riportolás és az oktatás területén.

 

A piaci szerepe az elmúlt időszakban

 Egy 2009-es összehasonlításban még 1,5-szer jobbnak hozták ki a Yahoo eszközét, mint az aktuális Google verziót. 

Mindössze a cég irányából érkező háttér támogatás és az automatikus riasztások területén volt jelentősen jobb a Google eszköz, 18 vizsgálati pontban viszont a Yahoo volt jobb.

yahoo web analytics6.JPG

Sajnos a technikai/tudásbeli előnyt nem sikerült kamatoztatni, az Analytics folyamatos fejlesztések és verzió váltások során ledolgozta hátrányait. 

A Forrester, az egyik legnagyobb amerikai piackutató cég, 2011. negyedik negyedévre vonatkozó Web Analytics jelentésében még szerepel a Yahoo terméke, a Google Analytics mellett egyetlen ingyenes eszközként.

De a 80 elemzési kritériumban már olyan kevés pontot ért el, hogy az utolsó helyen ajánlották használatát. Szinte az összes lehetőséghez kapcsolódó kritériumban a leggyengébben teljesített.

Magyarországon a Web Analytics-nek kevés felhasználója volt, hiszen a Yahoo PPC rendszerében való hirdetés vagy a Merchant nevű E-kereskedelmi szolgáltatása használata kellett hozzá.  

Eltűnése ezért inkább annak az üzenete, hogy a Google Analytics szinte egyeduralkodóvá vált az ingyenes webanalitikai szolgáltatások területén.

Szólj hozzá!

Mennyire látható az oldalam tartalma? - Újdonság

2012. június 13. 14:55 - Deli Norbert - HD

Egy látogató hirdetéssel való elérése utáni első lépés az, hogy a látogató találkozik a tartalmunkkal a landoló oldalon. Elfelejtjük, hogy ez a lépés elsőként technikai tényezőkön múlik, amelyek meghatározzák, hogy tényleg azt és olyan formában látják, ahogy azt mi akarjuk.

A landoló oldal tartalma - mit és milyen formában nyújtunk - csak ezen tényezők után következik:

  • • mennyi látható a tartalmunkból az első (görgetés nélkül látható) képernyőn
  • • a felhasználó által használt böngészőben úgy néz ki a tartalom, ahogy terveztük
  • • milyen gyorsan töltődik be a látható tartalom

 Minél többet, minél részletesebben tudunk a fenti tényezőkből, annál nagyobb a valószínűsége, hogy a landoló oldalon töltött idő, a visszafordulások arány értékeket az oldal tényleges tartalma befolyásolja és nem a technikai tényezők.

Ebben a bejegyzésben az első technikai tényezőhöz kötődő Analytics lehetőséget nézzük meg, a másik kettővel egy következő bejegyzésben foglalkozunk.

Mennyi tartalom látható az "első képernyőn"?

A mobil-, táblaeszközök térnyerése előtt elegendő volt a honlapunk tartalmát a szinte egyeduralkodó 1024x768-as képernyő felbontáshoz optimalizálni. 5-6 évvel ezelőtt a felhasználók több, mint 60%-a ezen felbontást használva böngészett, a kisebb felbontás használata már elhanyagolható arányúra csökkent.

De a nagyobb méretű monitorok, a 16:9-es képernyőjű notebook-ok és a kisebb felbontású mobileszközök elterjedése miatt fokozatosan csökkent az 1024x768 felbontás használata, mára külföldön már a második helyre csúszott vissza az 1366x768-as képernyőméret mögött, de itthon is már nagyon közel vagy egymáshoz a két méret használata (de még tartja első helyét).

Eddig a Google Analytics keretein belül nem volt lehetőség arra, hogy megnézzük adott felbontások mellett mennyi látható az első képernyőből. Ennek megnézéséhez Google egy "labor" eszközt adott, http://browsersize.googlelabs.com/

Böngésző mérete riport

2012. június elején viszont a Tartalom riportcsoport, Oldalon belüli elemzés nevű riportját egészítette ki egy Böngésző mérete nevű gombbal, illetve hozzá kapcsolódóan 6 beállítási lehetőséggel.

Első lépésként kapcsoljuk be a Böngésző mérete gombot, mert alapértelmezetten nincsen megjelenítve.

Második lépésként a "keréktárcsa" gomb alatt adjuk meg, hogy a tartalmunk a képernyő melyik részére van rendezve. Ezt fontos jól megadni, hiszen ez alapján rendezi a rendszer az eredményeket.

bongeszo meret2.PNG

Érdemes a másik két gombot kikapcsolni a riport megtekintésekor, mert csak zavarják az átláthatóságot.

Két lehetőségünk van az adatok megtekintésére: vagy egy csúszka segítségével megadjuk, hogy azt a területet akarjuk látni, amelyet a látogatók X%-a is lát. Itt még annyi beállításra van lehetőség, hogy internetes átlag, webhely átlag vagy az adott al-oldal látogatói által használt képernyőméretekben nézze ezt az X%-ot. Válasszuk a webhely átlag opciót, mert másik két "szűrő" torz eredményeket adhat.

Ha ezt a megjelenítési módot választjuk, akkor fehérítve látjuk a megadott %-nak megfelelő minimum képernyőfelbontásban látható első képernyőnyi területet, minden más halvány rózsaszín színű.

Látványosabb és könnyebben használható, ha bekapcsoljuk a Minden százalékosztály megjelenítése lehetőséget. Ilyenkor különböző színárnyalatok jelzik, hogy a látogatók hány százaléka mekkora területet lát a tartalmunkból. Nagy hátránya a riportnak, hogy nincsen beépített kicsinyítésre lehetőség. De Chrome böngészőben például jól használható erre a CTRL és a - billentyűkombináció.

Íme egy példa a saját honlapunkról, hogy a felhasználók mekkora része mit lát a nyitóoldal tartalmából:

bongeszo meret3.PNG

A példánál látszódik, hogy a webhely látogatóinak 80%-a nem látja az első képernyőjén a közösségi oldalaink linkjeit, ezért ezen tartalmakat fentebb kell elhelyeznünk.

Hasonlóan átalakításra szorul a Kapcsolat al-oldalunk, mivel az ott megjelenő térképet a látogatók 80%-a csak félig látja, így fentebb kell kerüljön.

bongeszo meret4.PNG

 

Mire használható ez a riport?

Hogy a kulcsoldalaink felépítését, tartalmának sorrendjét/kialakítását tekintsük át olyan szemmel is, hogy a bejövő látogatók mit látnak az első képernyőjükön, ami miatt tovább maradnak a landoló oldalon vagy megnéznek más al-oldalainkat is.

Mekkora részt tekinthetünk már mérvadónak a százalékosztályok között?

100%-ot semmiképp, hiszen a legtöbb magyar honlapnál is már legalább 2-3%-a a látogatóknak mobil eszközről érkezik, amelyek felbontása (még?) elmarad egy asztali PC vagy notebook kijelző felbontásától. 

Ha a lehető legtöbb felhasználónak nagy biztonsággal ugyanazt a tartalom mennyiséget akarjuk mutatni, akkor válasszuk a 90%-os arányt. Így bár lesznek látogatók, akik kevesebbet látnak első képernyőként, de a döntő többség azt látja, amit mi akarunk.

Mindenkinek jó elemzést és átalakítást!

Szólj hozzá!

Kísérletek a Google Analytics-ben - Újdonság

2012. június 04. 11:42 - Deli Norbert - HD

 A webanalitika nem csak abból áll, hogy helyes adatgyűjtés után elemzéseket végzünk az adatokkal, minél többet megtudni honlapunkról és látogatóinkról.

A webanalitika helyes folyamatát a következő folyamatábra adja meg:

Az utolsó két lépés technikai hátterét a Google-nél a Webhely-optimalizáló program nyújtotta. Valószínűleg túlságosan kevesen használták ezt az eszközt, azért a Google úgy döntött június elején, hogy 2012. augusztusától megszünteti ezt a programot, mint egyedi terméket.

Ezzel párhuzamosan viszont az alapelemeit átemeli a Google Analytics felületére a Tartalom riportcsoport alá, Kísérletek néven.  (Az angol nyelvű verziót használók a Content csoporton belül Experiments néven találják).

 Technikai háttér, változások

A Google Analytics rendszerbe való implementálás során egyrészt egyszerűsítettek, másrészt szűkítettek a Webhely-optimalizáló felületéhez képest.

Az egyik fontos szűkítés az, hogy csak az A/B tesztelés lehetőségét emelik át, a Többváltozós (Multivariáns) tesztelést kihagyják az induláskor. Vagyis csak teljesen különböző URL-en lévő tartalmakat tudunk tesztelni, nem lesz lehetőség arra, hogy adott oldalnak csak egyes részelemeivel végezzünk tesztelést.

A másik szűkítés, hogy egy tesztelésen belül csak 5 változatot használhatunk, szemben a Webhely-optimalizáló-ban jelenleg nyújtott 50+ változattal. Illetve egy profilon belül egyszerre 12 teszt futhat, amely könnyen megkerülhető a profil "lemásolásával".

Az egyszerűsítés pedig az lesz, hogy a Webhely-optimalizáló által használt három szkript - vezérlő, nyomkövetési, konverziós - közül csak a vezérlőszkript marad meg, e miatt kell új kódot elhelyezni a honlapunkban a már jelen lévő Analytics mérőkód mellé.

De fontos változás a kódnál, hogy minden egyes teszt egyedi vezérlőszkript kódot kap, ez korábban úgy nézett ki, hogy csak 1 ilyen kódot kellett generálni és elhelyezni a honlapban.

2 jelentősebb újítás is lesz:

  • • Az elindított tesztek automatikusan leállnak az indulás után 3 hónappal.
  • • A rosszul teljesítő teszt változatra automatikusan egyre kevesebb forgalmat fog irányítani, így óvva meg minket attól, hogy egy az alapnál rosszabb verziót tesztelve jelentős konverziós visszaesést szenvedjünk el. 

 

Az új riportfelület bemutatása

A felület használata előtt létre kell hoznunk egy új kísérletet, aminek az eredményeiről fogunk adatokat kapni.

A kísérlet létrehozása lényegében 2 lépésből áll, először meg kell adni az alapértelmezett URL-t, majd a tesztelni kívánt változatok URL-jeit. Mindegyiket el kell nevezni, lehetőleg olyan módon, hogy már a nevéből tudjuk később, hogy miben térnek el az alap verziótól: 

 

 A második lépés pedig az, hogy milyen konverziós célt akarunk javítani. Célként beállítható az Analytics-ben megadott URL alapú cél illetve esemény. Sem a Látogatás időtartalma, sem az oldal/látogatás alapú Analytics cél, sem pedig az e-kereskedelmi tranzakció nem adható meg Kísérlet célként.

 

 Ezután már nincs más dolgunk, mint a kapott vezérlőszkript kódot elhelyezzük az alapértelmezett oldalunk forráskódjába.

A kísérlet elindulása után 1 nappal már kapunk adatokat, de figyelni kell arra, hogy a rendszer csak 14 nap futás utáni adatok alapján hirdet győztes verziót, amely szignifikánsabb jobb eredménye miatt legyőzheti az alapértelmezett oldalunkat vagy pedig ha az adat azt mutatják, hogy egyik tesztelt verzió sem lett sokkal jobb a jelenleg használtnál. 

content experiment - 5.PNG

A Webhely-optimalizáló ilyen formában történő tovább örökítése a Google Analytics-ba egyértelműen a kezdő tesztelők felé való nyitás, hiszen az induláskor várható szűkítések és a 3 hónapos tesztidő korlát miatt nagyobb mérvű tesztelést nem lehet elvégezni így.

De a Google azt ígéri, hogy minél előbb próbálják a szűkítéseket megszüntetni, hogy az új riport tényleg rendelkezzen a Webhely-optimalizáló minden lehetőségével.

 

További információk

Szólj hozzá!

Hogyan növeljük az adatgyűjtés biztonságát?

2012. május 25. 13:50 - Deli Norbert - HD


adatgyujtes biztonsaga.png

Sajnos egyik webanalitika mérési eszköz/megoldás sem 100%-os, hiszen nagyon sok technikai tényező befolyásolja; egyre több féle eszközt (és ezeken más programnyelvben írt tartalmakat) kell nyomon követni; a saját tartalom is egyre többfélébb. 

Valamint mind a szerver-, mind a felhasználó oldali mérésnél van a működési elvből következő hátrány, ami miatt egyes látogatói adatok eleve nem mérődnek.

És akkor még nem is beszéltünk a figyelmetlenségről, ami gyakran megjelenik, mondjuk a honlap új verziójára történő átálláskor.  Vagy az egyes látogatók viselkedési szokásairól, akik például a szerintük túl lassú tartalommegjelenítés miatt gyorsan elhagyják a honlapot, így nem tudjuk őket nyomon követni. 

 A minél jobb adatgyűjtés pedig a webanalitika Alfája, hiszen csak a (megbízhatóan) mért adatot tudja a rendszer megmutatni nekünk, ami alapján következtetéseket vonhatunk le.

Legalább a következő 10 dolgot tegyük meg azért, hogy a Google Analytics adatgyűjtése minél inkább hiba nélküli lehessen a saját keretein belül: 

1. Használjuk az aszinkron Google Analytics követőkódot!

Egy újonnan induló mérésnél a rendszer már ezt a fajta követőkódot adja, hogy helyezzük el, de a régóta futó Analytics fióknál gyakran felmerülő probléma, hogy a ga.js vagy a még régebbi urchin követőkódot használják az adatgyűjtéshez.

Az aszinkron (vagy async) kódot a Google 2009. decemberében vezette be. A legnagyobb előnye a korábbi követőkódokhoz képest, hogy az oldal tartalmának betöltésével párhuzamosan (szinkronban) fut le, nem pedig a betöltési folyamat egy lépéseként.

Tehát nem lassítja a betöltési időt, ami gyakran látogató- és ebből adódóan adatvesztéshez vezet.

Hogy honnan tudjuk, hogy jelenleg az async kódot használjuk honlapunkon? Keressünk rá az oldalunk forráskódjában a _gaq.push szóra, ami a "hívófüggvénye" a kódnak. 

Azon túl, hogy gyorsabb és biztosabb adatgyűjtést biztosít ez a követőkód, van jó pár olyan riport, amelyhez ez ad adatot, mint például a Webhelysebesség.

 

 2. A HTML kód head részébe tegyük a követőkódot!

A régebbi követőkódoknál a Google is a HTML kód body részének végébe javasolta elhelyezni a kódot, mert így nem lassította a tartalom betöltését. De az aszinkron futás miatt már a head rész végére javasolja berakni. 

Ez azért jobb, mert így gyorsabban elkezdődik a mérés és több látogatásról lesz információnk. 

 

 3. A honlap programnyelve és felépítése alapján válasszuk a követőkódot

A rendszer segít nekünk ebbe. Ha több al-domain-t vagy több felső szintű domain használunk, akkor a követőkódot ezek alapján kérjük le. Illetve ha dinamikus vagy PHP tartalmunk van, akkor is kell apróbb módosítást csinálnunk. 

 

4. Mérjünk minden oldalon belüli cselekvést!

Ez igazából sok hiba forrása is lehet, de az adatgyűjtés szempontjából nagyon fontos. Itt arra is kell gondolni, hogy ne csináljunk olyat, hogy csak a domain-ünk egy részét mérjük és egyes al-oldalak kihagyunk a mérésből. Mérjünk minden al-oldalt, később ezt még szétbonthatjuk szűrők/szegmensek használatával. 

Alapértelmezetten a rendszer az oldalon belüli cselekvésekről nagyon részletes adatokat szolgáltat csak az alap követőkód használatával. De például az e-kereskedelem méréséhez; a fájltöltések méréséhez; az űrlapok kitöltéséhez; a kimenő linkek méréséhez már módosítani/bővíteni kell a kódokat; a belső kereső használatának mérése nem külön kóddal történik (ha megjelenik URL paraméterként a keresési szó), figyeljük azért a beállításnál erre is.

 

 5.  A mobil tartalmakat, alkalmazásokat teljesen külön mérjük

Az okostelefonok használói egyre növekvő arányba generálják a látogatásokat, a nagyon sokáig egyeduralkodó asztali gép-notebook páros mellett. Ha ezt kihasználva akár mobilra optimalizált honlap verziót, akár mobil applikációt készítünk, akkor a követőkód generálásakor ezek alapján kérjük le a kódot.

Figyeljünk arra, hogy ezen adatok gyűjtése mindig dedikált profilba történjen. 

 

 6. Vegyük figyelembe az Analytics határait

Erről egy korábbi bejegyzésben már írtam, a határai közül az adatgyűjtésnél a munkamenet (látogatásonként) max. 500 mért cselekvést és a havi max. 10 millió oldalmegtekintésre kell figyelnünk.

Utóbbi ritkán jön össze egy magyar honlapnál, jelenleg a Webaudit alapján csak az Origo.hu, az Index.hu és a Hasznaltauto.hu rendelkezik havi 10 milliónál több oldalmegtekintéssel. Az előbbi viszont könnyebben össze jöhet, hiszen az 500 cselekvésbe oldalmegtekintés, esemény és tranzakció is bele számít. 

Ha tehát sok cselekvést akarunk mérni, akkor előbb derítsük ki, hogy a felhasználók mekkora része érheti ezt el, illetve próbáljuk meg a kevésbé fontos dolgokat csak időszakos mérni. 

 

7. Mérjünk minden fizetett online kampányt!

Az utm URL címkéket tudatosan és konzekvensen használjuk online megjelenéseinknél, legyen szó akár affiliate,  email, banner, stb. marketing megjelenésről. 

Az URL-készítő eszközt is használhatjuk, tegyük is meg mindig. Így nem csak egy URL címünk lesz látogatói forrásként, hanem mi szabhatjuk meg, hogy milyen információkat és hogyan akarunk letárolni a marketing kampányainkról a későbbi elemzésekhez.

Ne feledjük el letesztelni az így kapott paraméterezett URL-eket, hogy tényleg az akart tartalmat jelenítik meg, nem pedig 404-es eredmény oldalt adnak. 

 

8. Mindig, mindig legyen egy szűrő nélküli profilunk, amiben minden adat megtalálható!

A kezdő felhasználók szokták leginkább az a hibát véteni, hogy egyetlen profilban mérik a honlap adatait, de ott valamiért használnak egy szűrőt, ami vagy módosítja vagy szűkíti a mért adatokat. 

Majd 1-2 hónap után veszik csak észre, hogy a szűrő miatt olyan adatok vesztek el, amiket már nem lehet szegmensekkel kinyerni. 

Tehát mindig legyen egy olyan profilunk, amiben semmilyen szűrőt nem használva rendelkezésre áll az összes mért adat. Egy ilyet elkészíteni kb. 3-5 perc, viszont egy biztos adatforrást kapunk így, amin már tudunk később is szegmenseket alkotva adatokat kinyerni. 

A saját forgalmunkat viszont szűrjük ki minden más profilban, legyen szó akár a tartalmat feltöltő belső munkatárs látogatásairól, akár a fejlesztő teszt látogatásairól, akár a külsős marketing cég által generált forgalomról. 

 

9. Állítsunk be riasztásokat a fontos mérések ellenőrzésére!

Az eddigi pontok alapján beállítottuk a méréseket, tudatosan címkézzük az online marketing forrásainkat. Elkezdődik az adatgyűjtés, elemezzük az adatainkat. De mindig előfordulhat olyan esemény, ami miatt vagy kikerül/megváltozik a méréshez szükséges kód vagy mondjuk megváltozik a célként mért oldalunk URL-je. 

Erről minél előbb értesülnünk kell, hogy be tudjunk avatkozni, helyreállítva az adatgyűjtést. 

Az Egyéni figyelmeztetések pont erre valók, amellyel ha nem is napon belül, de a következő napon e-mail értesítést kaphatunk fontos adatgyűjtési hibákról. 

Legalább a következő eseményekre állítsunk be ilyen riasztást:

  • • nem mér az alap követőkód - legtöbbször ez a 0 látogatásszámot jelenti
  • • nulla célelérés/tranzakció történt - kikerült az e-kereskedelmi kód, változott a cél URL (nyilván ha egyébként sincs mindennap ilyen esemény, akkor 1 hetes időtávot nézzünk)
  • • kulcsoldalak látogatottsága nullázódik - lehet, hogy a legtöbb oldalunkban benne a követőkód, de pont a legfontosabb al-oldalból került csak ki, ezért erre is csináljuk riasztást
  • • fontos látogatói forrás forgalma nullázódik - lehet, hogy leállt a marketing tevékenységünk itt, de lehet hogy kikerültek a 4. pontban említett utm URL címkék

Előfordulhat, hogy ezek a riasztások tévesnek bizonyulnak, mert mondjuk tényleg leállt a fizetett hirdetésünk és ezért nullázódott az onnan jövő forgalom. De inkább kapjunk feleslegesen napi 3-4 levelet, minthogy több nap vagy akár hét adata vesszen el olyan hiba miatt, amiről ha azonnal értesültünk volna, akkor kijavíthattuk volna az adatgyűjtést.

 

10. Vizsgáljuk felül legalább 3 havonta a mérést

Fontos! Ezt még a haladóbb felhasználók is kihagyják a webanalitika tevékenységek közül. 

Az online világ rendkívül képlékeny, gyorsan változik. Feltűnnek új látogatói források, mint mondjuk a Pinterest; változik a felhasználók látogatói szokása (akár eszközt, akár tevékenységet nézünk); de változik a honlapunk tartalma is.

Valamint a Google is kihoz 2-3 havonta egy újdonságot, amihez kapcsolódóan érdemes esetleg új méréseket alkalmazni.

Mindezen változások szükségessé teszik, hogy legalább 3 havonta - ha nagy látogatottságú oldalról beszélünk, akkor akár havonta - vizsgáljuk felül a mérésünket, a következő elemeket:

  • • minden élő al-oldalunkat mérjük-e (pl.: az observepoint.com vagy a WASP programok végigmennek minden al-oldalunkon és megmondják, hogy ott van-e mérőkód)
  • • vizsgáljuk felül a szűrőinket (bővítsük például a közösségi oldalak szűrőt az új oldalakkal)
  • • minden üzletileg fontos cselekvést mérünk-e
  • • minden tartalmat/tartalmi elemet mérünk-e
  • • a legutóbbi beállítás óta megjelent Analytics újdonságokat kihasználjuk-e
  • • minden fizetett forrásról van részletesebb információnk
  • • minden fontos látogatói forrásra rendelkezünk profillal/szegmenssel

 

A fenti 10 teendő tényleg hozzásegít minket, hogy lehetővé tegyük a Google Analytics-nek a lehető legalaposabb adatgyűjtést, így megadhatja nekünk az elemzésekhez szükséges adatokat.

1 komment

A not provided probléma

2012. május 22. 15:06 - Deli Norbert - HD

A keresőkből - akár fizetett, akár organikus részéből - jövő forgalom legnagyobb előnye, hogy a Google Analytics kulcsszó szintű információkat ad róla.
Ha tudjuk, hogy mondjuk az üvegpohár szóra jövők jobban konvertálnak, mint a bögre szóra jövők, akkor mind a keresőoptimalizálásban, mind a keresőhirdetésekben nagyobb hangsúlyt fordíthatunk az üvegpohár szóra, hiszen többet megér jobb pozícióban megjelenni rá.

A Google organikus forgalomra vonatkozó ezen információ egy része "tűnik" el a "not provided probléma" miatt. A not provided az organikus (SEO) forgalom azon részének "összefoglaló neve" a Google Analytics-ben, amely az SSL titkosítás miatt nem tartalmaz kulcsszó szintű adatokat.

SSL titkosított keresések pedig a bejelentkezett felhasználóknál történik, amit a Google előbb 2011. márciusában vezetett be az angolszász országokban, majd 2011. decemberétől világ szinten is.
Ehhez hozzá jön még az, hogy a Mozilla Firefox böngészőbe épített kereső a Google kereséseknél már alapértelmezetten SSL titkosított találati oldalra visz minket, függetlenül attól, hogy be vagyunk-e jelentkezeve a Google fiókunkba.

A keresések/SEO forgalom mekkora részét érint ez?

Ez az érték honlaponként változó értékű, 5%-tól akár 70%-80%-ig terjedhet. 

Az ügyfeleink között mérések tapasztalatai alapján az mondható, hogy 2012. márciusában lett igazán jelentős mértékű a not provided forgalom a SEO forgalmon belül, ez 16%-ot jelentett. Áprilisban ez még tovább nőtt - 22%-ra -, május első felében elérve a 25-26%-ot.

Vagyis az organikus forgalomból jövő látogatók közül minden 4.-ről nem rendelkezünk kulcsszó szintű adattal. 

Amikbe bele kell törödni:

- Fogadjuk el, hogy amíg a Google nem változtat a háttér technikai megoldásán, nem fogjuk tudni kinyerni a kulcsszó szintű adatokat a not provided forgalomból, csak minimálisan.

- Hiába használunk más webanalitikai eszközt, azok sem adják vissza ezen információkat, mert a Google nem jeleníti meg őket, így nem tudja kinyerni más eszköz sem.

Hogy hozhatjuk ki a legtöbbet mégis a helyzetből?

Négy dolog van, amelyek elvégzése után részben ki tudjuk nyerni az adatokat.
De sajnos becslésekbe/feltételezésekbe kell bocsátkoznunk, így a korábbi paradicsomi állapot - hogy szinte minden SEO forgalomról volt kulcsszó szintű adatunk is - már nem érhető el újra.

A legjobb, ha rendelkezünk egy csak SEO forgalmat tartalmazó profillal, a biztonság kedvéért. Ha ilyenünk nincsen jelenleg, akkor hozzunk létre egyet a következő szűrő használatával:

  not provided szuro2.PNG

 

Ezen profilba dolgozzunk, hogy ne legyen semmilyen adatvesztés, rendelkezzünk a szűretlen adatokkal is.

1. Rendeljük hozzá a kulcsszó pozíciós adatokat a SEO szavakhoz.

Egy egyszerű szűrővel hozzá tudjuk adni a szavakhoz, hogy mely pozícióban megjelenve jött rájuk forgalom.
A tapasztalataink alapján ez az organikus szavak 70-80%-ánál visszaad helyezés információkat.

notprovided-szuro1.png

2. Szedjük szét a kereső forgalmat domain szintűre.

A találati lista a szerint is változik, hogy milyen domain című Google/Google motorra futó keresőt használunk, így hasznos lehet a pontosításban, hogy éppen melyik domain címről jött a keresés. 

A következő szűrővel tudjuk megtenni ezt a bontást:

notprovided-szuro2.png

Az A mező szűrési feltétele a következő: http://([^/]*)

 

3. Az elemzéseknél használjunk Céloldal másodlagos dimenziót.


Ezzel képet kapunk, hogy a not provided szavak mely al-oldalunkra hoztak látogatókat. 

 notprovided-szuro3.PNG

  

3+1. Nyerjünk ki minden releváns adatot!

A Google Analytics-ben nagyon jó személyre szabott riportokat tudunk összeállítani, amit mi is nagyon kedvelünk. DE! Jelenleg csak 2 db dimenziót tudunk használni egyszerre, így nem tudjuk egy riportban látni a pozíciós-domain-landoló oldal adatokat.

Tehát vagy 1 egyéni jelentésen belül 2-3 munkalapot alakítunk ki és így a következő adatokat kapjuk:

 not provided - meres pelda3.png


Az egyéni jelentések fiókhoz kötődnek, így a következő linkre kattintva (és a Google Analytics fiókba belépve) mindenki elmentheti magának és használhatja a SEO profiljára:

https://www.google.com/analytics/web/permalink?type=custom_report&uid=zpRmuWM7RZGKoX6py4upBw

A másik megoldás, hogy használunk egy Google Analytics API-t használó Excel bővítményt, mi az Excellent Analytics-et preferáljuk, amelyben már 3 dimenzió is összehozható, pont ami nekünk kell most.


A beállítások utáni eredmény a következő excel tábla:

not provided - meres pelda4_1.png

Ha alaposak akarunk lenni, akkor nem csak a landoló URL-t, hanem a landoló oldal címsorát és meta leírását is berakjuk a táblázatba, ezt kapva:

not provided - meres pelda5.png


Itt jön a becslés/feltételezés rész!

4. Hogyan becsüljük meg, hogy mégis milyen szavakat rejt a not provided "csoport"!

 

Rendelkezünk tehát azon adatokkal, amiket ki tudtunk nyerni. Tudjuk, hogy milyen keresőben, milyen pozícióban jelentünk adott szóra, milyen oldalra érkezett a látogató, annak mi a címsora és a meta leírása. Illetve rendelkezünk még a látogatások különböző mutatóival. 

A keresőoptimalizálás során fontos, hogy nyomon kövessük azon szavakra a helyezésünket, amik vagy sok és/vagy értékes látogatókat hoznak honlapunkra. Ilyenkor heti/napi rendszerességgel nyomon követjük a TOP10-30 kulcsszavunk helyezését a találati listán. 

Erre a néhány tucat (de nagyon fontos) szóra megvannak a helyezés adataink, amiket összevethetünk a 3 pontban leírt teendők eredményeivel, így legalább a főszavakra kinyerhetjük a szószintű adatokat.

De a többi szónál, hogy mégis milyen konkrét kulcsszóra jöttek ezen látogatások, csak becsülni tudunk. 

Ha nem éppen nagyon aktív keresőoptimalizálás/honlap átalakítás folyik és nem érintett minket akár pozitív, akár negatív helyezésekkel valamelyik idei Google algoritmus váltás, akkor a ki tudunk indulni a múltbeli adatokból is.

És nagy segítséget nyújt az a tény is, hogy ha egy szó X%-át adja nem not provided SEO forgalomnak, akkor elég valószínű, hogy a not provided forgalom hasonló arányt adja. 

Láthattuk, hogy a not provided probléma miatt "eltűnő" adatokat részben vissza tudjuk nyerni, amíg nem ez a fajta forgalom fogja adni a SEO forgalom nagyobbik részét, addig ez a lehetőség fenn áll. 

Sajnos ahogy egyre több vonalon vezetik be az SSL titkosított találati listákat, ebből a kisebbségből a többség lesz, ami már tényleg nehezen elemezhető teszi az organikus forgalmat (legalábbis kulcsszó szinten).

not provided adatkinyerést mindenkinek!

 

Szólj hozzá!
süti beállítások módosítása