Wczoraj na oficjalnym blogu Google Analytics opisano proces zamówienia w pewnym brytyjskim serwisie e-commerce. Źle zainstalowany kod Analytics sprawił, że przychody sklepu były niższe o 100 tysięcy funtów miesięcznie. O co chodziło? Kod wyglądał następująco:

Doświadczone oko zauważy, że jest to typowy kod Analytics „pierwszej generacji” wykorzystujący skrypt urchin.js, który w 2007 został zastąpiony przez ga.js, a niedawno przez kod asynchroniczny. Ten stary kod nadal działa, kłopoty serwisu polegały jednak na tym, że gdy dochodziło do płatności, wchodziło się na stronę z bezpiecznym połączeniem (https). No a kod wczytywany był nadal ze zwykłego połączenia (http). Większość przeglądarek połknie takie zestawienie bez skargi. Wyjątkiem jest IE 8, który domyślnie wyrzuca takie  ostrzeżenie:

Komunikat jest dość zawiły, ale może przestraszyć: strona zawiera elementy, które nie zostały przesłane bezpiecznie, co może wpłynąć na bezpieczeństwo całej strony. Klikniesz dalej? Podasz tej firmie numer swojej karty?

No i potwierdziło się: wśród użytkowników IE 8 do płatności przeszło zaledwie 6%, podczas gdy przy innych przeglądarkach było to 28%. W kroku następnym – płatność potwierdziło 57% użytkowników IE 8 oraz 76% użytkowników innych przeglądarek. Gdy poprawiono ten błąd i wstawiono nowy kod, miesięczne zamówienia użytkowników IE 8 wzrosły z 18 tysięcy funtów do 128 tysięcy. Sześćset procent!

Wiemy z tego przypadku, że warto aktualizować kod Analytics na swoich stronach. Ale najważniejsze – jak wykrywać takie sytuacje? Podczas prezentacji „Meandry analityki” pokazywałem, że niektóre błędy w instalacji Analytics zobaczymy w samych statystykach. Najczęściej nie bezpośrednio – czasami poprzez konsekwencje, które owocują „dziwnymi” wynikami i które dopiero trzeba zinterpretować.

W przypadku opisanym wyżej sposób wykrycia problemów jest bardzo prosty:

1. Tworzymy segmenty dla użytkowników IE 8 oraz dla wszystkich którzy nie używają IE 8
2. Porównujemy konwersję

Tak to wyglądało dla opisywanego serwisu:

Jeśli jest jakaś istotna (statystycznie) różnica, wtedy możemy wejść głębiej. W artykule omówiono m.in. segmentację lejka celów, z której będzie wynikało, na którym etapie użytkownicy IE 8 mają problem. Jeśli w serwisie macie miejsce, w którym przechodzi się do połączenia bezpiecznego, warto sprawdzić.

Pytanie może powstać – co jeśli nie mierzymy konwersji i nie mamy lejka celów? Można np. skorzystać ze statystyki „Content –> Exit Pages” i porównać na których stronach opuszczają serwis użytkownicy IE 8, a na których inni. Pamiętajmy jednak, że istotna różnica nie musi oznaczać błędu technicznego, może wynikać po prostu z innego profilu użytkownika przeglądarki.

Podobne artykuły:

• Wpadka Google Analytics
• Nowy skrypt Analytics wychodzi naprzeciw obciążonym serwisom
• Nowości z działki Google Analytics
• El Monito w panelu Google Analytics
• Asynchroniczny kod Analytics – już oficjalnie

I dziś (12 lipca 2010) do późnych godzin wieczornych można ją ściągnąć za darmo. Wystarczy na stronie promocji podać swój e-mail. Przesłany zostanie link, pod którym ściągamy paczkę z plikami PDF, ePUB oraz MOBI. Warto zauważyć, że pliki nie są zabezpieczone DRM, przez co firma zyskuje mój jeszcze większy szacunek.

Krótko o książce: „jQuery: Novice to Ninja” (autorzy: Earle Castledine, Craig Sharkie) to zbiór przykładów, na których można nauczyć się biblioteki jQuery. Jak wyjaśnia wstęp do książki: jest to proste i potężne narzędzie do manipulacji elementami strony oraz zarządzania zapytaniami AJAX. I jeszcze: Integralną częścią jQuery jest jQuery UI – zestaw ładnie wyglądających kontrolek i widżetów (takich jak akordeony, zakładki i dialogi).

W czasie gdy biblioteka wchodziła na rynek (okolice 2006) właściwie kończyłem przygodę z programowaniem, ale chyba się tego trochę poduczę. Wydaje mi się, że jQuery jest idealne dla ludzi, którzy tylko zajmują się interfejsem (HTML/CSS), bo pozwala osiągać niesamowite efekty kosztem paru linijek kodu.

Tzn. koszt czasami jest – w dziedzinie wydajności. Biblioteki jQuery obecnie ładuje każdy większy serwis, czasami tylko po to, aby wykorzystać jeden prosty efekt… A załadowanie takiej biblioteki obciąża i łącza i przeglądarki.

Cytując jeszcze raz wstęp: jQuery jest narzędziem, które pozwala poprawić użyteczność stron i stworzyć lepsze user experience. Wszystko przez te gotowe zestawy kontrolek. Dlatego tematem powinni się zainteresować również projektanci interfejsu, nawet jeśli sami nie kodują. Książkę warto przejrzeć, aby zorientować się, jakie efekty bogatej interakcji można uzyskać.

Podobne artykuły:

• Dobry programista PHP poszukiwany
• Wpadka Google Analytics
• Dwie niezbędne (!) książki o wzorcach projektowych
• Trzy lektury na koniec sierpnia
• Efekt Rydzyka

Wczoraj, 19 maja 2010 na blogu Google Analytics pojawiło się ogłoszenie, że nowy kod stał się domyślny dla Analytics. Gdy będziemy zakładali w Analytics nowy profil, ten nowy kod będzie już jedynym sugerowanym.

Niestety, nowy kod jest znacznie bardziej skomplikowany od istniejącego i już raczej nie da się go wpisywać z palca. :-)

Wpis na blogu zachęca także do migracji dotychczasowych użytkowników. Na stronach Google Code przygotowano instrukcję i przykłady migracji.

Czy warto od razu zabrać się do zmiany kodu? Wydaje mi się, że trzeba być z tym ostrożnym. Podobnie jak przy migracji z urchin.js do ga.js, która nastąpiła w roku 2007, zmienić trzeba nie tylko główny kod, ale też wszystkie odwołania do Analytics – jeśli np. śledzimy różne zdarzenia. Zmienia się też sugerowana lokalizacja kodu – ma być jak najwyżej, a nie w stopce.

Jeśli zaś chodzi o dotychczasowy kod: ga.js – który w terminologii Google nazywa się teraz „tradycyjnym”, nie widziałem żadnej informacji, o tym żeby był przestarzały, albo ograniczał działanie jakichś nowych funkcji. Wydaje się więc, że podstawowa cecha nowego kodu to po prostu asynchroniczne wczytywanie i większa wydajność. Jeśli nie mamy z tym problemu, można jeszcze z migracją poczekać.

Jednocześnie warto wybrać się 27 maja na szóstą edycję SEMcamp, na której Mariusz Gąsiewski opowie dokładniej o śledzeniu asynchronicznym.

Podobne artykuły:

• Nowy skrypt Analytics wychodzi naprzeciw obciążonym serwisom
• O tym jak zły kod Analytics może kosztować grube pieniądze
• Google Analytics Individual Qualification na 97% :-)
• Nowy skrypt Google Analytics – ga.js
• Google nierychliwie wprowadza dowody certyfikacji GAIQ

Odwiedziłem dziś stronę mBanku korzystając z bardzo starego linku: http://info.mbank.com.pl/ekonto.html. Oto, co między innymi zobaczyłem:

Szczególnie rozczulił mnie banner o treści „Typi non habent?” :-)

Obecny adres strony eKonta jest następujący: http://info.mbank.com.pl/indywidualny/rachunki/osobiste/eKONTO/ - a to na co wszedłem pozostało jako sierotka z poprzedniej wersji, a może tylko link przygotowany do pokazania layoutu świątecznego? Kto wie.

Strony nie ma w Google, owszem, ale linki do niej mogą wciąż być na komputerach ludzi. Poza tym, tutaj w zasadzie jest to niegroźne, ale można sobie wyobrazić sytuację, gdy taki mock-up zostanie upubliczniony i wykorzystany przeciwko firmie.

Niestety dziś, gdy adresy w ramach serwisu są niemal zawsze przepisywane i w ten sposób „wirtualne”, trudno odnaleźć takie sierotki. Najlepszym sposobem byłoby trzymanie bazy wszystkich opublikowanych adresów (czy też wzorców adresów) i regularne sprawdzanie, czy dla adresów nieaktualnych istnieją właściwe przekierowania i czy nie pojawiają się takie właśnie kwiatki.

Sposobem budżetowym może być przejrzenie bookmarków (choćby i publicznych na delicious.com). Możemy też poszukać, czy na dysku nie mamy zapisanej jakiejś pojedynczej strony z naszego serwisu sprzed paru lat. Jeśli strona została zapisana przy pomocy przeglądarki (Plik-Zapisz jako) i wybrano „strona www – kompletna”, to przynajmniej w IE oraz FX będziemy w pliku HTML zapisane linki bezwzględne do pozostałych stron. Poklikajmy w te linki, które prowadzą do naszego obecnego serwisu i zobaczmy co się stanie. Jeśli będą błędy 404, albo sierotki podobne do powyższego przykładu, warto coś z nimi zrobić.

Podobne artykuły:

• O tym jak mBank partnerom swoim handlować nie daje
• Nowy skrypt Google Analytics – ga.js
• Nowości z działki Google Analytics
• Bójmy się CSS?!
• Domenowa wyobraźnia

Przyznaję że zwlekałem z napisaniem tej notki, na kilka z tych konferencji warto zapisywać się parę miesięcy wcześniej, bo wtedy są niższe ceny. Z drugiej strony obecne kursy walut trochę to niwelują.

Warszawa: 15-16 kwietnia

IA Summit, czyli pierwszy polski zjazd architektów informacji zacznie się już w najbliższy czwartek. O tym „szczycie” pisałem już w osobnym artykule. Teraz warto tylko dodać, że w związku z narodową żałobą organizatorzy nie zmienili programu, odwołali jednak bankiet, który miał towarzyszyć spotkaniu.

Lizbona, 12-14 maja

UX Lx: User Experience Lisbon, to 3 dni w Lizbonie poświęcone różnym aspektom UX. Poświęcę mu trochę więcej, bo sam się wybieram na ponad tydzień do stolicy Portugalii. Nie wiem co bardziej przeważyło, aspekt edukacyjny czy turystyczny :-) ale jestem przekonany, że wyjazd otworzy mi trochę nowych horyzontów.

Główny dzień konferencyjny potrwa aż 10 godzin, a występować będzie sama galeria sław. Nielsen (ale chyba tylko powita online, bo nie wyobrażam sobie wystąpienia przez 5 minut :), Krug, Spool, Wroblewski, Merholz. Niemal każdy z występujących ma w dorobku jakąś znaną książkę. Będzie też Eric Reiss, którego zobaczymy już niedługo na IA Summit. Koszt samej konferencji to 295 euro, członkowie UPA, IA Institute albo IXDA dostają 15% zniżki (podpowiedź: do IXDA można się zapisać bezpłatnie, albo poszukać kodu w archiwum dyskusji).

Wcześniej dwa dni warsztatów, na które można zapisać się osobno, płatnych trochę więcej niż sama konferencja. Ja wybrałem Jareda Spoola (o projektowaniu dla serwisów z bogatą treścią) i Petera Merholza (o strategii i planowaniu produktów), można też pouczyć się zdalnych testów usability, albo przejść podstawowy tutorial testowania z samym Stevem Krugiem.

Jeśli ktoś z czytelników się wybiera do Lizbony (poza paroma osobami o których wiem), poproszę o kontakt na priv. :-)

Londyn, 19-21 maja

UX London to jedna z regularnych konferencji organizowanych przez Nielsen Norman Group. Znaczy: nazwiska, znaczy: drogo. 1100 funtów za 3 dni, a jeśli zarejestrowałeś się w zeszłym roku, to mogłeś zapłacić jedynie 900 funtów. Nie zapomnijmy o podatku VAT, który do tych cen NIE był wliczony.

Mimo tego gdy odwiedziłem dziś stronę konferencji, okazuje się, że wszystkie miejsca są wyprzedane, można jedynie dołączyć do listy oczekujących.

Monachium, 24-28 maja

Usability Professionals Association to zrzeszenie skupiające 2400 specjalistów z całego świata. Głównie ze Stanów (1300 osób), ale także trochę z Europy, m.in. 16 osób z Polski, w tym ja. Co roku organizują swoją konferencję – zawsze była po drugiej stronie Atlantyku, ale tym razem po raz pierwszy w Europie. I bardzo się waham czy nie pojechać, choć Lizbona nadwyręży mój edukacyjny budżet.

Dlaczego warto pojawić się w Monachium? Program konferencji oszałamia. Około 100 różnych wystąpień, często na bardzo szczegółowe tematy. Przykłady? Tworzenie ikon dla publiczności międzynarodowej. Sposoby określania czytelności. Ocena interfejsów dotykowych. Projektowanie dla szczęścia… :-) W porównaniu do Lizbony część tematów jest bardziej zaawansowana.

Konfrencja w  Monachium trwa 3 dni (do tego jeszcze warsztaty), każdy dzień po 360 euro, całość 660 euro. Nienależący do UPA płacą odpowiednio 440 i 880 euro. Nie jest tanio. Ale taka okazja może się nie powtórzyć.

Poznań, 25 maja

Wracamy do Polski. Konferencja SparkUP 2010 odbędzie się w Poznaniu i spojrzenie na cenę pozwala odetchnąć po tym co widzieliśmy w Londynie i Monachium. Za 244 złote mamy okazję wziąć udział w 2 ścieżkach tematycznych: pierwsza poświęcona UX, a druga technologiom internetowym. W każdej pięć sesji, np. w ścieżce o UX posłuchamy o przyszłości mobilnego UX (Andy Ribot), projektowaniu perswazyjnym (Andy Budd, którego miałem już okazję oglądać w Warszawie – warto), albo o modelach mentalnych (Marek Kasperski). W drugiej ścieżce będzie o jQuery, RIA, a we wprowadzającej sesja Bruce Lawson z Opera Software opowie o HTML 5.

Trochę szkoda, że to się zazębia, bo osobiście chętnie bym poszedł i na Budda i Lawsona. Ale nie wiem czy osobiście dotrę, choć to spotkanie, odbywające się w niedzielę jest zdecydowanie warte odwiedzin. :-)

Berlin, 29-30 maja

UX Camp Europe, to impreza, która odbędzie się na zupełnie innych zasadach. Formuła barcampowa – za bilety się nie płaci, ale trzeba współuczestniczyć. Miałem się na to wybrać, niestety liczba uczestników jest limitowana i można się załapać tylko na listę rezerwową.

Warszawa, 29 maja

Zacząłem i zakończę Warszawą – 29 maja na PJWSTK odbędzie się już V edycja konferencji Kansei. O poprzednich edycjach parokrotnie już pisałem, na pewno i tym razem będzie kilka wystąpień, którymi warto się zainteresować. I jak co roku – za darmo.

A Ty na które spotkania się wybierasz? Zapraszam do komentowania.

Podobne artykuły:

• World Usability Tour 2009
• IA Summit w Warszawie – już w kwietniu
• Dwa spotkania klubowe w październiku i jedna książka
• Przypominam o Kansei (i nie tylko)
• Grill IT oraz Projektowanie Uniwersalne

Ludzie klikają na kanał, zapisują się i adres kanału trafia gdzieś do czeluści ich czytnika. Co stanie się jeśli zmienimy na przykład domenę i zmieni się też adres kanału RSS?

To zmiana znacznie groźniejsza niż w przypadku adresu zwykłej strony. Jeśli wejdę na zły URL w przeglądarce, zobaczę błąd 404 – i będę wiedział, że muszę poszukać nowego adresu, na przykład przejść na stronę główną. Nie jest to wygodne, ale przynajmniej o tym wiem! A w przypadku zmiany adresu RSS – zależy to od czytnika. A może nasz czytnik nie powie ani słowa o tym, że kanału już nie ma i będzie utrzymywał nas w przekonaniu, że na blogu już nikt nie pisze! Tak właśnie robi Google Reader.

Jeśli zmienia się adres serwisu, wystarczą zwykłe przekierowania 301. Oczywiście jak przy każdych przekierowaniach, konieczne jest, byśmy mieli kontrolę nad starym adresem czy domeną. Ale tu też znajduje się pułapka. Jeśli człowiek dodał subskrypcję adresu X – to dopóki sam nie zmieni go na Y, jego czytnik będzie korzystać z przekierowania. A to oznacza, że jeśli za dwa lata skasujemy przekierowanie, które wprowadziliśmy dziś, to … i tak stracimy część naszych czytelników, która korzystała ze starych adresów. Nie zapomnijmy też o różnych serwisach, które po internecie wyświetlają nagłówki z naszych kanałów.

Może więc lepiej napisać ludziom: słuchajcie – to jest ostatni wpis, zmieńcie subskrypcję? Wiele osób go nie zauważy. Jeśli jesteśmy w stanie to zrobić (a wiemy że przekierowanie nie pozostanie w nieskończoność) – uzupełniajmy więc każdy wpis na „starym” kanale o prośbę dotyczącą nowego. Ale wtedy też dylemat: część czytników pokazuje tylko tytuły wpisów, przenosząc od razu na naszą stronę. W którym miejscu pokazać więc komunikat? Może dopiero po przejściu na stronę? Nie ma tu idealnych rozwiązań.

Idealne by było, gdyby czytniki same rozpoznawały przekierowania i aktualizowały adresy, ale jak dotąd tego nie robią.

Z tego co napisałem wynika jedno: nigdy nie powinniśmy tracić kontroli nad adresem kanału RSS, na przykład nie powinniśmy korzystać z dostawców, którzy oferują kanał we własnej domenie. O przekierowaniach i powiadomieniach trzeba też pamiętać przy każdej reorganizacji serwisu – na przykład zmieniamy kategorie, wtedy automatycznie zmieniają się kanały RSS z nimi powiązane. O przekierowaniu dla kategorii pamiętasz – a o RSS?

Problemy wynikające z braku kontroli widać na przykładzie FeedBurnera, którego powszechnie używa się do zliczania statystyk. W trakcie swojego istnienia zafundował on kilka adresowych zmian. Wszystkie blogi które z adresami w rodzaju feeds.feedburner.com/WebauditBlog musiały pewnego dnia przenieść się na feeds2.feedburner.com/WebauditBlog. Kilka miesięcy później Feedburnera kupił Google, więc nastąpiło przeniesienie na kolejną domenę pod Google. Stary adres ma działać „tak długo jak będzie to możliwe”, ale nie na zawsze.

Całe szczęście FB oferuje też inne rozwiązanie czyli MyBrand. Możemy sobie ustawić, że czytnik klienta będzie zawsze widział nasz kanał (generowany przez FB) pod adresem we własnej domenie, np. feeds.webaudit.pl/WebauditBlog. Wymaga to oczywiście stworzenia aliasu w konfiguracji naszej domeny, ale jest relatywnie proste – i mamy pewność, że nigdy ten adres nie wymknie się nam spod kontroli.

PS: Przy okazji doniosę o tym, że zgodnie z obowiązującą modą założyłem „fan page” WebAudit na Facebooku. W ten sposób nowe wpisy na blogu można śledzić przez RSS, e-mail, a także przez w Facebooka. W odróżnieniu od mojego osobistego konta na, strona WebAudit zawierać będzie przede wszystkim sprawy związane z firmą i blogiem, mogą się tu więc zapisać także osoby, które nie chcą czytać o tym ile pączków wczoraj zjadłem. :-)

Podobne artykuły:

• Domenowa wyobraźnia
• Google usuwa Netsprint i Interię (ze statystyk)
• Małe a cieszy, czyli gdzie umieszczać adres strony?
• Bójmy się CSS?!
• Typi non habent, mBanku? Pamiętajmy o sierotkach

Popatrzmy na ogłoszenie z 1 grudnia. O najważniejszych dwóch nowościach było głośno: chodzi o śledzenie asynchroniczne, a także o nowy mechanizm definiowania zmiennych. Pisałem o tym, ja, pisały też blogi branżowe – temat zmiennych omówił dość szczegółowo Mariusz Gąsiewski.

Ale zmian bywa więcej. Na przykład inne są teraz metody określające czas trwania cookies dla pojedynczej sesji (domyślnie 30 minut) czy użytkownika (2 lata). Niewielka, ale dość ciekawa rzecz, z polskiego punktu widzenia to usunięcie ze śledzenia dwóch wyszukiwarek: Interii (błędnie opisanej jako Intera) oraz Netsprinta.

Co oznacza usunięcie? Że po 1 grudnia nie zobaczymy już nowych wejść z tych wyszukiwarek w statystykach „search engines”, a także nie zobaczymy słów kluczowych, z których wchodzono. Same wejścia nie znikną, ale zobaczymy je jako strony odsyłające (referring sites).  Podkreśliłem, że chodzi o „nowe wejścia”, bo możemy wciąż widzieć ruch pozyskany z tych wyszukiwarek wcześniej. Niech więc nikogo nie zdziwi, że jednak jakieś wejścia zobaczy.

Jak to działa?

Skąd Google wie o tym, że szukamy i zna słowo kluczowe? Wyciąga to z adresu, z którego ktoś wchodził na stronę (czyli referera).

Na przykład, jeśli wejdę do Google i wpiszę: audyt sklepów internetowych, wtedy adres wygląda tak: http://www.google.pl/search?hl=pl&q=audyt+sklepów+internetowych&btnG=Szukaj&lr=&aq=f&oq=. Dla Google liczą się dwa elementy:

• nazwa domeny – bez końcówki domenowej: w tym przypadku „google” .
• nazwa zmiennej, za którą następuje wyszukiwane hasło: w tym przypadku „q”.  Oczywiście adres musi być podany w ten sposób, że będzie tam ciąg znaków: q=fraza. Mówiąc technicznie, wyszukiwarka musi działać w trybie GET, który wszystkie zmienne z formularza wyrzuca do adresu strony.

Aby Google wiedział, które wyszukiwarki ma śledzić i skąd wyciągać słowa kluczowe, korzysta on z tabeli, w której znajdują się popularne wyszukiwarki z całego świata. Można je zobaczyć w samym kodzie GA. Najpierw nazwa domeny, następnie zmiennej, pod którą można znaleźć zapytanie.

about:terms
alice:qs
alltheweb:q
altavista:q
aol:encquery
aol:q
aol:query
ask:q
baidu:wd
bing:q
cnn:query
daum:q
ekolay:q
eniro:search_word
google:q
images.google:q
kvasir:q
live:q
lycos:query
mama:query
mamma:query
msn:q
mynet:q
najdi:q
naver:query
netscape:query
onet:qt
ozu:q
pchome:q
rambler:word
search:q
sesam:q
seznam:q
szukacz:q
terra:query
virgilio:qs
voila:rdata
wp:szukaj
yahoo:p
yam:k
yandex:text

Z polskich zostały: Szukacz, WP i Onet.

Jeśli chcemy dodać swoją wyszukiwarkę – parę tych parametrów musimy wstawić do kodu Analytics przed wywołaniem metody _trackPageview. Kod musi być na każdej stronie naszego serwisu.

pageTracker._addOrganic(„nazwa wyszukiwarki”,”nazwa zmiennej”);
pageTracker._trackPageview(); // zliczenie odsłony musi nastąpić po konfiguracji wyszukiwarek

Dygresja: wpadka z Google Images

Jest to mechanizm niestety trochę dziurawy.

Na przykład mimo tego, że widzimy w zestawieniu „images.google” – Google nie zlicza słów kluczowych z images.google.pl, bo sama strona wysyła jako stronę odsyłającą adres przekierowania w którym nie ma „q=”!  Tak czy inaczej, jeśli chcemy wyciągnąć słowa kluczowe dla obrazków, trzeba w tym celu stosować dodatkowe filtry, na przykład opisany na blogu SEO Insights.

Analytics sobie nie radzi, a darmowe BBClone, którego używam na co dzień do śledzenia pojedynczych sesji – owszem. Gdzie tu logika? Dla mnie to jest niepojęte, jak Google może psuć swój własny produkt. Koniec dygresji. :-)

Dlaczego usunięto Interię?

W tym momencie, gdy na stronie głównej interia.pl wpiszemy do wyszukiwarki jakieś hasło, widzimy adres: http://google.interia.pl/szukaj/?q=usability&s=Szukaj&sg=1 – prawdopodobnie więc słowa te łapią się pod regułę „google:q”.

Jeśli ktoś osobno chciałby mierzyć wejścia z google.interia.pl, musi skorzystać z kodu:

pageTracker._addOrganic(„google.interia”,”q”);

Zresztą nie wiem jak to jest do końca z tymi adresami, bo zdarzają się wejścia też z takich adresów: http://google.interia.pl/szukaj,q,wikimedia%20polska,w,sw,p,3 – tego Analytics nie jest w stanie rozpoznać (brak „q=”) i dlatego google.interia.pl widzimy czasami w statystykach strona odsyłających, a nie wyszukiwarek. Można to wyciągnąć poprzez utworzenie osobnego filtra – podobnie jak w przypadku Google Images. Ale liczba takich wejść nie jest duża i nie są istotne statystycznie.

Dlaczego usunięto Netsprint?

To wyjaśnić trochę trudniej, choć może łatwiej, jeśli popatrzy się na statystyki – wejść z samej wyszukiwarki Netsprintu było zawsze mało i ostatnio coraz mniej. Na tym blogu nie ma jej wcale,  a na serwisach z milionami wejść zaledwie kilka. Być może właśnie dlatego usunięto Netsprint – bo jest coraz bardziej zmarginalizowany. Zresztą w rankingu Gemiusa nie łapie się nawet do pierwszej dziesiątki.

Niemniej, jeśli ktoś jeszcze kibicuje Netsprintowi, może – podobnie jak wyżej – dodać obsługę tej wyszukiwarki ręcznie:

pageTracker._addOrganic(„netsprint”,”q”);

Podobne artykuły:

• Nowy skrypt Google Analytics – ga.js
• Nowości z działki Google Analytics
• Konta i profile Google Analytics
• Domenowa wyobraźnia
• Asynchroniczny kod Analytics – już oficjalnie

„W zasadzie nie, ale trochę tak”, odpowiadam, bo jednak skrypt GA musi się załadować, a każde wywołanie kodu śledzącego oznacza też krótkie połączenie z serwerem Google.

Jest kilka tricków, które mogą pomóc. Na przykład przechowywanie kodu lokalnie, tak by w przypadku padu serwerów GA (co się zdarza) wczytywanie strony nie trwało w nieskończoność.

W serwisie Google Code pojawiło się dziś rozwiązanie, które ma zmniejszyć obciążenie strony. Jest to nowy kod Google Analytics, który komunikuje się z serwerami Google w sposób asynchroniczny. Jeśli dobrze zrozumiałem wyjaśnienie na blogu GA: Analytics nie będzie zajmować „kolejki”, w której ładują się inne obiekty (np. biblioteki Javascript), a raczej poczeka, aż będzie czas na komunikację.

Na podanej wyżej stronie Google Code znajduje się cały kod oraz opis jego instalacji. Pojawił się dzisiaj, jeszcze go nie testowałem, więc nie wiem czy są z nim jakieś kłopoty.

Dwie ważne rzeczy:

• Google dotąd zalecał umieszczanie kodu na samym dole sekcji BODY – właśnie po to, aby nie spowalniał ładowania innych elementów. Teraz kod ma znaleźć się na samym dole sekcji HEAD.
• Prawidłowe działanie może wymagać przepisania innych kodów śledzących na stronie – więcej w szczegółowej instrukcji.

Pamiętać jednak trzeba, że to rozwiązanie specjalne i w fazie beta, więc jeśli bardzo nie potrzebujemy, nie ma sensu tego instalować.

Podobne artykuły:

• Asynchroniczny kod Analytics – już oficjalnie
• Nowości z działki Google Analytics
• Nowy skrypt Google Analytics – ga.js
• 5 powodów, aby pokochać Google Analytics
• Google Analytics Individual Qualification na 97% :-)