Skocz do linków, Skocz do treści

O tym jak zły kod Analytics może kosztować grube pieniądze

14 lipca 2010 9:32. Autor: Robert Drózd. 5 komentarzy

Dziś krótki przypadek z cyklu „nieprawdopodobne, a jednak prawdziwe” oraz „będzie o czym mówić na prezentacjach”.

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:

Stary kod Analytics z wykorzystaniem urchin.js

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:

IE 8 ostrzega o treści, która nie była dostarczona w sposób zaufany

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:

Konwersja IE 8: 0,38%, konwersja innych użytkowników 2,5%

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:

Być może zainteresują Cię następujące artykuły:

Zapisz się na kanał RSS bloga i dołącz do ponad 1500 czytelników RSS.

Zostań fanem WebAudit na Facebooku.

Komentarze czytelników

Śledź komentarze do tego artykułu: format RSS
  1. kissdesign

    I gdzie ten tytułowy poniesiony koszt? Widoczne ktoś w końcu porównał dane księgowe z danymi z Analyticsa i zastąpił stary kod.

  2. Robert Drózd

    Koszty utraconych możliwości to też koszty. :)

  3. bobik

    Nagłówek rodem z faktu.

  4. Qadamo

    @bobik
    hmm..tytuł może nie do końca oddający treść..ale do „zabił ją siekierą i uciekł” jeszcze bardzo daleko;))

Komentarze z innych blogów

  1. Ergonomia logowania na portalach Social Lending > Social Lending w Polsce

    […] ostatnio artykuł o tym, jak źle przygotowana funkcja w sklepie doprowadziła do dość dużych strat (brak przychodu to też strata). Polecam też przykład z rodzimego […]

Zostaw komentarz

W komentarzu można (choć nie trzeba) używać podstawowych znaczników XHTML. Komentarze zawierające w podpisie słowa kluczowe mogą zostać potraktowane jako spam i usunięte.