WebAudit Blog

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:

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.