Jak skutecznie usuwać reklamy na stronach WWW.

Oczywiście, że przy pomocy Adblock Plus (moje filtry Adblock tutaj, czyli rozszerzenia dla Firefoksa, które właśnie do tego celu zostało stworzone. Chrome też ma jakiś filtr. Pytanie tylko, dlaczego warto reklamy na stronach WWW usuwać.

Oczywiście cały wpis to polemika z tym wpisem, w którym uparcie autor przekonuje, czemu to reklam nie warto blokować.

Zatem, czemu warto je blokować? Po kolei:

  1. Reklamy bez sensu zapychają łącze.
  2. Reklamy bez sensu obciążają komputer, który je odtwarza.
  3. Reklamy spowalniają ładowanie się strony (ważny jest nie tylko czas transmisji i renderowania, ale i czas zapytań DNS).
  4. Reklamy rozpraszają uwagę czytającego.
  5. Reklamy utrudniają (czasem uniemożliwiają) nawigację na stronie.

Blokowanie użytkowników blokujących reklamy nie jest – na dłuższą metę – wykonalne. Jaki problem, by przeglądarka udawała, że reklamę wyświetliła? Teraz to nie jest potrzebne, ale gdyby były, to implementacja jest równie prosta, co wykrywanie blokowania. Niekoniecznie oszczędzi to łącze, ale na pewno pomoże w punktach 4 i 5.

Nadawanie właściwej treści strony cech reklamy? Trzymanie zdjęć w katalogu /ads? Piękny strzał w stopę. Po pierwsze, reklamy można wykrywać także np. po rozmiarze/proporcji (część antywirusów to robi), po drugie, niesłychanie łatwo zarządzać takim śmietnikiem. A jeśli webmaster stworzy schemat nazw odróżniający zdjęcia od reklam, to ludzie, którzy to chcą zablokować mogą go łatwo odgadnąć.

Niepomijalna reklama? W CAPTCHA? Cóż, może się da. Pytanie, kto będzie chciał się z tym męczyć? Zwł. żeby przeczytać denny tekst (patrz niżej).

Trzeba też pamiętać, że wojna „reklamodawch” vs. „użytkownicy” to wojna 1 vs. wielu. Narzędzi do blokowania nie ma – jeszcze – wiele, privoxy, Adblock Plus, wspomniane już niektóre antywirusy, które w ramach ochrony WWW blokują także część reklam…

Prawda jest taka, że nienachalnych reklam nikt nie blokuje. Nie ma to sensu, bo dobrze zrobiona reklama nie spowalnia ładowania strony, nie odrywa od tekstu. Poza tym, blokowanie reklam też kosztuje (coś musi je analizować, ktoś musi zrobić reguły). Problemem są ci, którzy wrzucają nachalne śmieci.

Szczerze mówiąc, nie kojarzę żadnej wartościowej strony z nachalnymi reklamami, dużą ilością reklam, wyskakującymi reklamami itd. Zwykle tego typu rzeczy są na stronach o miernej treści, nastawionych na ilość. Dla mnie jakiekolwiek utrudnianie przez webmastera blokowania reklam na stronie to wyraźny sygnał, że strona jest słaba. Podobnie jak duża ilość reklam na stronie.

Zresztą, sam fakt, że ktoś chciałby narzucać mi co mam/muszę oglądać, napawa mnie niesmakiem. Jeśli koniecznie chcesz zarobić na stronie, zrób normalny płatny dostęp. Jeśli będzie wartościowa, to znajdą się czytelnicy. Jeśli nie – daj ludziom korzystać ze swoich systemów/ekranów/łącz tak, jak mają ochotę.

Tragiczny kod widgetu AdTaily.

Kiedyś, gdy AdTaily startowało (zamknięta beta), a ja miałem piękny i validujący się się XHTML 1.0 Strict na blogu, pierwszą rzeczą, na którą zwróciłem uwagę po zainstalowaniu widgetu, była była niezgodność z XHTML. Małe, a drażni, więc zgłosiłem błąd. Samemu nie udało mi się poprawić – primo, bardzo słabo znam JS, secundo, ok. 20 kB to jednak sporo do przeglądania.

O całej sprawie zapomniałem, aż do wczoraj, gdy niezależnie dwóm osobom (KosciaK i Tomasz Fiedoruk), o których wiedziałem, że powinny mieć umieszczony widget, napisałem, że wszystko fajnie, ale widgetu nie widzę. Winnym okazało się AdTaily, a raczej tragiczny kod ichniego widgetu, ale po kolei…

Pierwszy był KosciaK, u którego zwróciłem na fakt braku widgetu przy okazji wpisu o – ładnym skądinąd – nowym szablonie na blox. Ponieważ u mnie i na kilku innych blogach (bloxowych i nie), na tej samej przeglądarce, widget jest widoczny, myślałem, że chodzi o szablon właśnie, tym bardziej, że jakieś magie z jquery się tam dzieją.

Jakoś po stwierdzeniu, że na Operze widzę, na debianowej wersji Firefoksa, czyli Iceweasel w wersji 3.0.6 nie widzę, na Icecat (czyli w pełni wolnej wersji Firefoksa) 3.5.3 też nie widzę, a z kolei on u siebie widzi, po pobieżnym przyjrzeniu się problemowi, z braku czasu i pomysłów przeszliśmy nad tym do porządku.

Niewiele później zaczęło się na blipie narzekanie na sytuację z reklamami, co skłoniło mnie do stwierdzenia, że ciężko mieć reklamy, jak się nie ma widgetu. Tym razem chodziło o dwie strony, jedną bez fajerwerków w kodzie – jak twierdził autor – oraz, drugą, w której od biedy można by czegoś po stronie kodu szukać. Po stronie kodu strony niczego nie udało się znaleźć, więc podejrzenie padło na system operacyjny, jako jedyną część wspólną.

Po chwili do niedziałających przeglądarek dołączył Konqueror na moim systemie, oraz Iceweasel na systemie kumpla. Z kolei oficjalne buildy Mozilli wyświetlały wszystko jak należy. Także u mnie. Sytuacja bardzo ciekawa, więc postanowiłem zagadkę rozwiązać, tym bardziej, że to może jakiś błąd w Debianie (któraś z bibliotek czy coś takiego).

Po chwili zabawy z diffowaniem plików i kopiowaniem po kawałku oficjalnego builda do katalogu z Icecat okazało się, że „winnym” jest extra user agent. Cudzysłów jak najbardziej uzasadniony, bo tak naprawdę winny jest widget AdTaily. Fragment kodu:

parseFloat(b.substring(a+this.versionSearchString.length+1))},dataBrowser:
[{string:navigator.userAgent,subString:"Chrome",identity:"Chrome"},
{string:navigator.userAgent,subString:"OmniWeb",versionSearch:"OmniWeb/",identity:"OmniWeb"},
{string:navigator.vendor,subString:"Apple",identity:"Safari",versionSearch:"Version"},
{prop:window.opera,identity:"Opera"},
{string:navigator.vendor,subString:"iCab",identity:"iCab"},
{string:navigator.vendor,subString:"KDE",identity:"Konqueror"},
{string:navigator.userAgent,subString:"Firefox",identity:"Firefox"},
{string:navigator.vendor,subString:"Camino",identity:"Camino"},
{string:navigator.userAgent,subString:"Netscape",identity:"Netscape"},
{string:navigator.userAgent,subString:"MSIE",identity:"Explorer",versionSearch:"MSIE"},
{string:navigator.userAgent,subString:"Gecko",identity:"Mozilla",versionSearch:"rv"},
{string:navigator.userAgent,subString:"Mozilla",identity:"Netscape",versionSearch:"Mozilla"}],
dataOS:[{string:navigator.platform,subString:"Win",identity:"Windows"},
{string:navigator.platform,subString:"Mac",identity:"Mac"},
{string:navigator.platform,subString:"Linux",identity:"Linux"}]};

Jak widać, ktoś w AdTaily postanowił wymyślić koło od nowa i napisał własne rozpoznawanie przeglądarki i systemu operacyjnego. Na dodatek niezupełnie działające, bo nie obsługuje – z szybko przychodzących mi do głowy – Iceweasel i Icecat, zapewne także Swiftfox, Arora (nie wiem, jak się przedstawiają). W statystykach pewnie wychodzi, że nikt Konquerora nie używa, bo jeszcze nie widziałem by Konqueror się „KDE” przedstawiał (a z racji tematyki mam trochę wejść od użytkowników Konquerora). Po zmianie ciągu Icecat na Firefox we wspomnianym user agent extra version oczywiście widget wyświetla się tam, gdzie wcześniej się nie wyświetlał.

Zagadką dla mnie pozostanie, czemu pisana jest własna obsługa rozpoznawania przeglądarki (widget o 1kB większy, a i tak nie rozpoznaje wielu przeglądarek), czemu dzieje się to po stronie widgetu (a nie wysyłany jest cały user agent na serwer, jeśli to do celów statystycznych, a nie wyświetlania). O paru skrótach typu „Apple = Safari” nie wypowiadam się, bo zwyczajnie nie znam.

Ewidentnym błędem – jeśli chodzi o wyświetlanie – jest brak fallbacku do jakiegoś sensownego defaultu w przypadku nierozpoznania (a przecież engine przedstawiał się normalnie), nie tylko jest to sprzeczne z działaniem w każdej przeglądarce szerzej o kampanii Anybrowser, ale przekłada się na brak widzialności widgetu na niektórych stronach (ale nie zawsze! u mnie na blogu był widoczny bez problemu) u wszystkich użytkowników Debiana, korzystających z dostępnych domyślnie w dystrybucji przeglądarek. Oraz u wszystkich korzystających z podrasowanych/nietypowych przeglądarek.

Czemu tak było? Czy były inne skutki braku rozpoznania (np. nie zliczanie kliknięć w statystykach kampanii od nie rozpoznanych przeglądarek, gdy widget był widoczny)? Nie mam pojęcia, nie znam na tyle JS, by to wyjaśnić. To JS, więc kod jest dostępny, znających się zachęcam do obejrzenia.

Jakie jest rozwiązanie? Szybkie i brzydkie – dodanie brakujących przeglądarek w widgecie (znowu spuchnie, nadal nie wszystko będzie obsługiwane). Ładne – przepisanie widgetu, który nie tylko ma ww. problem, ale także nie jest widoczny z sieci Orange (mało ludzi zgłaszało to jako bug, więc nie spodziewałbym się w najbliższym czasie poprawienia tego), jest napisany w taki sposób, że jego wywołanie rozwala XHTML 1.0 Strict. Oczywiście rozwiązanie ładne będzie wymagało nakładów finansowych, ale biorąc pod uwagę, że nie jest to pierwsza około JSowa wpadka w ostatnim czasie, może warto nawiązać współpracę z kimś, kto takie rzeczy umie? Przeprojektowanie serwisu teraz będzie łatwiejsze niż później, podobnie zmiany w kodzie widgetu…

Temat (braku) bonusów za wynagrodzenia już poruszyłem na flakerze. Trochę inna tematyka, ale polecam lekturę wpisu No more free bugs. Z mojej strony to ostatni zgłoszony (za free) błąd. Co prawda dla mnie to (i szukanie błędów, co robić pewnie będę nadal, i ogólnie reklamy) zabawa, ale czemu mam odbierać chleb zawodowcom (przynajmniej tym od błędów i kodowania; reklamodawcy niech nie liczą na względy)?

Wpadka AdTaily z logowaniem.

W piątek, 23.10.2009 część użytkowników AdTaily nie mogła zalogować się do portalu (np. w celu zmiany ustawień) – otrzymywali komunikat o błędym haśle. Co więcej, przy próbie przypomnienia hasła, otrzymywali informację, że ich email nie istnieje w bazie danych. Sprawa jest wyjaśniona, ale stanowisko AdTaily nie do końca mi się podoba, stąd moje stanowisko w tej sprawie.

Na początek fakty. Po pierwsze, uruchomiony został osobny, angielski serwer AdTaily (adtaily.eu – dead link). Po drugie, w piątek ludzie z AdTaily byli na prezentacji w UK, dlatego ustawili przekierowanie na jeden dzień (link). Po trzecie, przekierowanie było robione przy pomocy JS, wyłącznie na podstawie obecności języka angielskiego w ustawieniach przeglądarki (link). Po czwarte, część ludzi miała problem z zalogowaniem się do serwisu (czyli awarię). Po piąte, AdTaily nie pofatygowało się, by zamieścić jakąkolwiek informację na swoim blogu czy blipie.

Ponieważ temat jest – przynajmniej dla mnie – za długi na flakera, gdzie wywiązała się dyskusja na ten temat (dead link), przedstawię moje zdanie. Po pierwsze, stawianie osobnych serwerów dla wersji językowych jest złe. Rozumiem argument o problemach z przeliczaniem (o tyle, że trzeba to dorobić i przetestować, z drugiej strony wiele serwisów sobie z tym radzi bez problemu), ale osobny serwer dla każdej wersji językowej to nieporozumienie. Wystarczy pomyśleć o dwóch wersjach: zdublowane maszyny dla 4 języków w wersji z osobnymi serwerami (8 maszyn) i bez niej (2 maszyny). Oczywiście, koszt maszyn to nie wszystko, dochodzą kwestie load balancingu (no właśnie…), i skończonej wydajności pojedynczych maszyn (no właśnie…) ale i tak zapowiadane jest merge’owanie kont – przynajmniej tych występujących na obu serwisach – więc logikę i tak trzeba będzie opracować i zaimplementować.

Konferencja – się zdarza (i bardzo dobrze, trzeba się rozwijać, także na nowe rynki). Podejrzewam, że AdTaily nie było zbytnio do niej przygotowane, jeśli chodzi o np. materiały reklamowe, więc często (tylko?) pojawiało się na nich .com zamiast .eu, stąd pomysł jednodniowego przekierowania. Niegłupie (jedyne w tamtej sytuacji?) rozwiązanie, z kategorii tymczasowych.

Wykonanie przekierowania. Totalnie nieprzemyślany dramat, jak dla mnie:

function redirect_to_english_version() {  if (navigator.language.match(/en/) && (parent.document.URL == 'http://adtaily.com/' || \parent.document.URL == 'http://www.adtaily.com/')) {    window.location = 'http://adtaily.eu'  }}redirect_to_english_version();

Całkowicie pominięty fakt, że angielski jest językiem międzynarodowym, że sporo polskich użytkowników akceptuje także treści angielskie (TBH, chyba więcej angielskich czytam, niż polskich – polska to zaścianek jeśli chodzi o wiedzę, a jeśli chodzi o newsy, to jest 24-72h za resztą świata) i że polscy użytkownicy (na szybko: 1, 2, 3, 4) nie mają czego szukać na osobnym, angielskim serwisie. Inna sprawa, wiedzenie lepiej, czego user chce i podstawianie innego serwisu na podstawie wersji językowej to bzdura. Rozumiem, podstawić przetłumaczoną treść czy serwować z innej lokalizacji geograficznej…

Śmiem twierdzić, że skutki przekierowania nie zostały (dokładnie) przemyślane. Gdyby zostały, to – mam nadzieję – pojawiła by się choćby krótka wzmianka na blogu i/lub blipie. O takiej perwersji jak ingerencja w kod i dodanie jednej linii tekstu przy komunikacie z błędem logowania nie wspominam.

Wyszło jak wyszło (dla mnie brak możliwości logowania to awaria, a podejście „przekierowanie tylko na dziś” jest nieprofesjonalne), szkoda tylko, że niektórzy AFAIK dość blisko związani z AdTaily, będący w kraju, znający sytuację i rozwiazanie, nie mogli jakiegoś oficjalnego info wrzucić.

Ze swojej strony mam nadzieję, że było warto (i dla twórców i dla userów) i że na przyszłość będzie to bardziej przemyślane i przyjaźnie dla userów zrobione.

Bo takie akcje IMHO nie wpływają dobrze na – i tak nienajlepszy (to akurat zdanie osoby, której poleciłem serwis; nie chciałbym się publicznie na ten temat rozpisywać) – wizerunek serwisu. Brak „skopaliśmy, przepraszamy” też nie.