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?!
• Drodzy blogerzy dodający swoje strony do Blogboksa…

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
• Prezentacja o Analytics z World Usability Day Tour 2009

„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:

• 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% :-)
• Wpadka Google Analytics

Kilka miesięcy temu kupiłem sobie netbooka Asus Eee PC 1000HE, co zresztą opisałem na swoim prywatnym blogu. Sprzęt mnie tak zachwycił, że po raz pierwszy w życiu opublikowałem recenzję na portalu Ceneo.pl. Wszystko poszło bez problemów, choć zdziwiłem się, że nie mogę się zalogować, aby na przykład w przyszłości swój tekst uaktualnić.

Dzisiaj o recenzji sobie przypomniałem i postanowiłem sprawdzić, co się z nią dzieje. Wszedłem na stronę produktu w Ceneo, który to serwis uruchomił niedawno nową wersję. Oto, co zobaczyłem:

Pisząc recenzję pracowicie wyliczałem powody dla których kupiłem netbooka. Wypowiedź podzieliłem na krótkie akapity. A nowe Ceneo całkowicie zignorowało moją pracę. Przy wyświetlaniu tekstu zapomniano o przełamaniu linii, czyli o wstawieniu znaczników XHTML odpowiadających nowym liniom. To, że w bazie tekst jest podzielony na wiersze i akapity, widać nawet w kodzie:

Jak wiadomo, przeglądarki wyświetlając tekst, ignorują nowe wiersze, dodatkowe spacje i inne tzw. białe znaki. O formatowanie tekstu trzeba zatroszczyć się na poziomie kodu XHTML.

W języku PHP znajduje się nawet dedykowana funkcja nl2br, której jedynym zadaniem jest wstawienie znaczników przełamania (<br />) w miejscu nowych wierszy. Tak więc błąd w Ceneo można prawdopodobnie naprawić jedną linijką kodu. Właściwie poprawniej jest zamieniać na <br /> tylko pojedyncze przełamania wierszy, a podwójne już na akapity. Ale to też załatwia jednolinijkowa funkcja…

Jak wspomniałem na początku, błąd ten spotykam nagminnie. Opinie użytkowników, o które tak pieczołowicie zabiegamy powinny wyglądać maksymalnie czytelnie i estetycznie. A tutaj mamy blok tekstu wyrzucany na ekran bez jakiejkolwiek obróbki. Jeśli to krótkie wypowiedzi – żaden problem. Nikt nie wymaga przełamania linii w wypowiedziach z Blipa. Ale im dłuższe – tym trudniej czytać.

Inne ciekawostki

Inna sprawa, że to nie jedyne dyskusyjne rozwiązanie webdeveloperów Ceneo. Po co na przykład wstawiać obrazek pros.gif w powyższym fragmencie kodu, skoro ikonkę ilustrującą nagłówek „Zalety produktu” można dołożyć za pośrednictwem CSS? Umieszczenie tekstu alternatywnego „zalety” sprawi, że użytkownik czytnika usłyszy „Zalety. Zalety produktu”, tak jakby strona Ceneo się jąkała.

Dodajmy do tego na przykład całą masę wspólnego kodu Javascript umieszczoną na każdej stronie, co zwykle wyrzuca się do zewnętrznych plików. Po co dodawać dodatkowe kilobajty razy setki tysięcy odsłon stron Ceneo miesięcznie?

Okazuje się, że określenie „Beta” nie jest przypadkowe, strona Ceneo wymaga wielu optymalizacji przed ostatecznym uruchomieniem. Szkoda tylko, że wyłączono już starą wersję, która nawiasem mówiąc, wyżej opisanego błędu z przełamaniem nie nie miała.

Aktualizacja z 26.10.

Dzisiaj zauważyłem, że błąd został poprawiony, ale … poprawiony został źle! Bo jedno przełamanie wiersza zastąpione zostało nie przez jeden, a przez dwa tagi <br />. W efekcie tekst jest teraz bardzo rozstrzelony. :-)

Podobne artykuły:

• Trudny termin: afordancja [i recenzje na godi.pl]
• Nic nowego: 3 stare zasady dotyczące ikon
• Sirius.pl – czy to jest jeszcze sklep internetowy?
• Kolejnych 5 porad – dokumenty: i ładne i użyteczne
• Edytory WYSIWYG i złe nawyki … developerów

Kiedyś w epoce Webalizera i Analoga, które operowały na logach serwera, wystarczyło program zainstalować – i tyle. Podawał co był w stanie. Niektórzy z takich narzędzi wyciskali całkiem sporo, bo dało się je konfigurować w dużym zakresie.

Potem nadeszła generacja statystyk wstawianych jako kod JavaScript i od tego czasu mamy problemy. Bo kod statystyk trzeba wstawić do kodu witryny.

Instalacja

Wstawienie kodów często nie ogranicza się do copy/paste. Każdy system statystyk ma swoje odrębne reguły:

1. w obrębie danego serwisu
2. na przestrzeni kilku serwisów.

Wyobraźmy sobie, że mamy:

• Google Analytics: kod w całym serwisie taki sam, z dość poważnymi wyjątkami: strony transakcyjne, strony gdzie mierzymy dodatkowe kliknięcia czy zdarzenia. Jeśli mamy różne serwisy, to w kodzie zmienia się często tylko numer… Czy developer przyklejając ten kod do nowego szablonu będzie pamiętał o numerze?
• Google Website Optimizer: kody niemal zawsze zależą od konkretnego badania, przy czym trzeba pilnować, aby nie gryzły się z Analyticsem.
• Gemius Traffic: jakie kody wygenerowaliśmy dla różnych rodzajów stron w słynnym drzewku, takie musimy na odpowiednich stronach umieścić.
• Gemius Heatmap czy ClickDensity - czyli programy do clickmap: kod zwykle w całym serwisie taki sam, ale jego konfiguracja może różnić się między różnymi serwisami dla tego samego konta.

Czy można to jakoś uprościć technicznie? Pewnie tak, np. przez systemy szablonów w CMS-ach. Rozwiązanie już jednak każdy musi przygotować samodzielnie.

Konfiguracja

Ale to nie wszystko. Nasz dział marketingu planuje jakąś promocję. Dodają przez CMS artykuł lub stawiają minisite i puszczają na niego silną kampanię zewnętrzną. A potem przychodzą do nas pytać, „jak poszło”. Dobrze, jeśli chociaż podstawowe kody są na takim minisajcie. Ale takich rzeczy jak ustawienia celi, ewentualne filtry czy śledzenie pobrań plików w Analyticsie już nie zainstalujemy. Drzewka w Gemiusie też nie poprawimy wstecz. Nie mówiąc już o ewentualnych testach różnych wariantów.

Jak nad tym zapanować, gdy mamy nie dwa lub trzy, ale na przykład 30 serwisów?

Jeśli masz duży serwis lub wiele serwisów, które utrzymuje więcej niż jedna osoba – musisz stworzyć jakieś procedury zarządzania kodami statystyk. Każda zmiana w strukturze serwisu oraz każda akcja marketingowa powinna przechodzić przez sito statystyk – czy aby nie trzeba czegoś zmienić. Do tego regularna kontrola jakości – czy kody dalej są i działają, czy coś się dziwnego nie pojawiło, czy aby producent nie zmienił zasad ich działania?

Prowadzi to też do wniosku, że analityki nie da się robić z doskoku, że powinna być ku temu oddelegowana konkretna osoba – 1/4 czy 1/8 etatu nie jest wcale zawyżonym czasem na takie działania. Mówię tu tylko o utrzymaniu, a nie analizie!

Firmy oceniając możliwości zakupu statystyk komercyjnych, lub skorzystania z darmowych nie biorą pod uwagę kosztu ich utrzymania.  Avinash Kaushik pisze w swojej (genialnej i wartej każdej złotówki) książce o regule 10/90. Na każde 100 złotych wydanych na analitykę 10 złotych powinno pójść na narzędzia, a 90 złotych na ludzi.

Bez ludzi, bez ich czasu i wiedzy, nasz system statystyk pozostanie wyłącznie zabawką.

Podobne artykuły:

• Wszystko albo nic, rzecz o uprawnieniach dostępu
• Analiza świeżości odwiedzin w Google Analytics
• Google usuwa Netsprint i Interię (ze statystyk)
• Prezentacja o Analytics z World Usability Day Tour 2009
• Nowy skrypt Google Analytics – ga.js

1. Zajrzyj do statystyk wyszukiwania w Twoim serwisie i weź 10 najpopularniejszych fraz, które wpisywali użytkownicy.
2. Wpisz te frazy do wyszukiwarki.
3. Wpisz te same frazy do Google z opcją przeszukiwania Twojej witryny (site:www.twojadomena.pl).
4. Dla każdej z fraz porównaj, które wyniki są bardziej odpowiednie z punktu widzenia użytkownika. Możesz się wspomóc statystykami odsłon wyników – jeśli jesteś w stanie prześledzić, co ludzie robią PO wyszukiwaniu.

Wyniki tego prostego ćwiczenia będą często zaskakująco niekorzystne na rzecz naszego serwisu. Czasami aż w 8 przypadkach na 10, najlepiej pasujące wyniki zobaczymy właśnie w Google.

Stąd wniosek pierwszy: może czasami nie ma sensu zajmować się tworzeniem własnej wyszukiwarki, skoro dałoby się wykorzystać Google?

Dlaczego tak się dzieje? To przecież jasne. W wielu serwisach mechanizm indeksacyjny wyszukiwarki lub po prostu zapytanie SQL do bazy przeszukuje po prostu treść poszczególnych stron i na podstawie jakiegoś algorytmu pokazuje najbardziej dopasowane wyniki. No, na tej płaszczyźnie z guglem nie wygramy. Wniosek drugi: Nie wolno skupić się wyłącznie na wyszukiwaniu pełnotekstowym. To przecież specjalizacja Google. Jeśli jedyne co Twoja wyszukiwarka robi to przeszukiwanie treści, to właściwie zawsze będzie gorsza od Google.

Ale z drugiej strony – dlaczego Google, które opiera się przecież niemal wyłącznie na analizie treści oraz linków ma być mądrzejsze od nas, którzy wiemy wszystko o naszym serwisie i jego użytkownikach?

Od czego zacząć?

Zacznę od warunku wstępnego, który wziął się z obserwacji u jednego ze swoich klientów. Firma zdecydowała się na wdrożenie mechanizmu wyszukiwawczego pewnego polskiego dostawcy. Mechanizm działał świetnie – ale momentami zwracał niesamowite śmieci – bo bazy do przeszukania były duże, a wybranie najlepszego dokumentu z kilkudziesięciu tysięcy bywa trudne. Dlaczego tak się stało? Proces wdrażania wyszukiwarki potraktowano wyłącznie jako projekt informatyczny. Mowa była o formatach wymiany treści, generowaniu stron wyników, specyfikacji API i innych tajemniczych dla laika sprawach. To, jak właściwie tworzyć (i oceniać) inteligencję tej wyszukiwarki pozostało na uboczu.

Dlatego warunkiem wstępnym będzie umieszczenie wyszukiwarki w procesie projektowania skierowanego na użytkownika czy klienta. Nic dobrego nie wyjdzie z projektu, na który patrzymy tylko od strony kodu.

Zanim podejmiemy jakiekolwiek działania, musimy jeszcze raz wrócić do porównania i powiedzieć – czy opłacałoby się nam mieć wyniki takie same lub lepsze niż Google? Innymi słowy – czy użytkownik z naszymi wynikami trafi tam gdzie powinien, czy nie? Pamiętajmy po to, że nie robimy wyszukiwarki idealnej, która wygra z Google pod względem skuteczności – ona ma tylko pokazać klientowi, to co uznamy za potrzebne.

6 strategii na wyprzedzenie Google

1. Wykorzystaj metadane, których Google nie potrafi rozróżnić. Im więcej tych pól, których wartość możesz ważyć, tym większa możliwość pokazania wyników, które są bardziej dopasowane. Dobrze jest skorzystać nie tylko z możliwości odróżnienia tych pól, ale też z powiązań, które mogą istnieć między nimi. Masz tagi? To pomyśl, jak możesz skorzystać z nich w wyszukiwarce.

Przydatną właściwością jest popularność (np. liczba odsłon, ocena) każdej ze znalezionych pozycji. To przecież robi właśnie Google – zlicza linki. My linków nie liczymy, ale mamy dokładniejsze dane na temat popularności, bo dotyczące poruszania się po naszym serwisie.

2. Dostosuj wyniki do profilu użytkowników. Łatwo powiedzieć. Ale jeśli na przykład w sklepie mamy mechanizmy rekomendacji na podstawie zachowania użytkownika, to dlaczego ich nie wykorzystać również przy wyszukiwarce?

3. Stwórz jakiś system sugestii. Dla kilkudziesięciu popularnych fraz jesteś w stanie z palca określić, co jest najważniejsze, na jaką stronę użytkownik powinien trafić przede wszystkim. Jak już to określisz, to zastanów się jak to można zautomatyzować. :-) Czasami sugestie da się oprzeć np. na mechaniźmie tagowania – co się na przykład stanie, jeśli tagom przypiszemy różne typowe zapytania i jako wyniki sugerowane pokażemy najpopularniejsze wyniki dla tych tagów? Warto sprawdzić. Warunkiem w tym przypadku (i w ogóle przy poważnym wykorzystywaniu tagów) jest to, że mamy odpowiednio wiele tagów szczegółowych.

4. Dawaj możliwości filtrowania i zawężania wyszukiwania. Niewielu ludzi korzysta z wyszukiwarki zaawansowanej. Częściej skorzystają z opcji, które pojawią się tam gdzie się ich spodziewają – na długiej liście wyników. Również możliwość sortowania daje nam wielką przewagę nad Googlem. Co nasi użytkownicy chcą (albo powinni) zobaczyć na początku?

5. Łącz dwa tryby poszukiwania informacji – wyniki wyszukiwania i przeglądanie. Klasyczne rozwiązanie to np. pokazywanie drzewa kategorii do których należą wyniki wyszukiwania – doskonale sprawdza się to w serwisach aukcyjnych.

6. Dostosuj wygląd wyników wyszukiwania. Pokazuj w wynikach to, co jest klientom potrzebne, a nie standardowe „tytuł artykułu i skrót treści”. Z tym jest już całkiem nieźle w serwisach e-commerce, które nauczyły się, że strony wyników muszą sprzedawać. Bywa całkiem źle w wielu serwisach informacyjnych, albo tam, gdzie przeszukiwane są różne bazy danych, np. w polskich bibliotekach cyfrowych.

A jaki jest Twój sposób na poprawę wewnętrznej wyszukiwarki?

Podobne artykuły:

• Gazeta.pl i szkolne błędy wyszukiwarki
• Nowy komputronik.pl i wyszukiwarka która zawodzi
• Niebezpieczne skutki używania OR
• Google usuwa Netsprint i Interię (ze statystyk)
• Stronę Windows Live lepiej odwiedzać Firefoksem

co.mments will be shutting down Jan 11, 2009. It’s been a wonderful ride, unfortunately regular upkeep, and our friendly spammers, have turned it into a chore. I need the time and energy to focus on other things, so sadly, I’m going to shutdown the site by the end of this week. Thank you all for your support, Assaf

Są inne narzędzia, jak coComment, ale co.mments było najprostsze – dodawałem stronę z komentarzami do serwisu, a potem wszystkie nowe komentarze widziałem w pojedynczym kanale RSS. Dlaczego o tym piszę? Dwie przyczyny – po pierwsze: link do co.mments był na każdej stronie z tego bloga, prawdę mówiąc nie śledziłem czy ktoś z tego korzystał. Po drugie – oto przykład, że istnieje w sieci sporo narzędzi, które – jak się okazuje stworzyła i utrzymywała jedna osoba; gdy ta osoba nie ma już czasu i siły, narzędzie upada, a jego użytkownicy muszą szukać innych.

Podobne artykuły:

• Domenowa wyobraźnia
• Relatywne utrapienia
• Firefox, wojny robotów, zwykli ludzie i blogi
• O zarządzaniu kodami statystyk
• Nowy skrypt Google Analytics – ga.js

Muszę jednak przyznać, że to klient miał rację, z tym, że jego pomysły wyprzedziły trochę swój czas. Bo dziś WordPress jest używany we wszystkich możliwych rolach i nikt go już nie ogranicza do blogów.

Oto nowaagencja.pl, uruchomiony dzisiaj serwis agencji interaktywnej Pride&Glory. Strona na WordPress.

Oto ebiznes.pl, istniejący od 10 lat serwis informacyjny. Ostatni poważny redesign serwisu – i WordPress, z szablonem, który może kupić sobie każdy za 70 dolarów.  Zastanawiam się na ile to jest przemyślana decyzja, a na ile po prostu ograniczanie budżetu. I niestety nie ustrzeżono się błędów, np. zagubiono komentarze do wszystkich artykułów ze starego serwisu.

Źródło sukcesu WP? Chyba właśnie ta prostota. Nagle okazuje się, że wielu serwisom wystarczy prosta organizacja: strony i artykuły  podzielone według kategorii i tagów. A bogactwo wtyczek i łatwość edycji szablonów pozwala zbudować na tej bazie całkiem poważne struktury.

Tą prostotą WP wygrywa prawie z każdym gotowym CMS-em. Rok temu próbowałem dla celów prywatnych postawić prostą stronę na CMS Etomite, który ponoć należy do prostszych i łatwiejszych w obsłudze. Coś mi wyszło, ale po paru godzinach się poddałem, bo dostosowanie tego czegoś do moich wymagań stawało się coraz bardziej odległe.

Prostota jest też zagrożeniem. Domyślne szablony WordPressa przygotowano dla blogów. Blogów – a zatem, zgodnie z ich genezą, dzienników internetowych. To, że mamy szablony podane na tacy może sprawić, że pójdziemy na łatwiznę i nie będziemy wiele w nich zmieniali. Ale są to rozwiązania, sprawdzające się na zwykłym blogu, którego czytamy chronologicznie. Nie musi to działać  w serwisie, który powinien zapewniać równie łatwy dostęp do wszystkich artykułów.

Od paru tygodni w wolnych chwilach rzeźbię nowy szablon niniejszego bloga. Czasami staję przed jakąś typową funkcją, np. stroną kategorii i widzę, że w domyślnym kształcie jest zupełnie nieużyteczna dla kogoś, kto odwiedza ją po raz pierwszy. Bo po co komuś nowemu układ chronologiczny i pokazanie wszystkich artykułów po kolei? To jednocześnie narusza strefę komfortu, w ramach której wszystko jest jakoś zorganizowane, a ja powinienem wywrócić to do góry nogami i zacząć bez wordpressowych obciążeń.

Podobne artykuły:

• Polska data – plugin WordPress
• Relatywne utrapienia
• O zarządzaniu kodami statystyk
• Captcha – nie używaj!
• Konta i profile Google Analytics