Марио ТрендафиловПроектът е приключил.
Новият сайт е онлайн.
Checkout-ът е преработен.
Категориите са преструктурирани.
SEO промените са внедрени.
Автоматизацията работи.
Как разбираме дали проектът е успешен?
Тук понякога се появява неприятна пауза.
След седмици или месеци работа започваме да търсим показател, който да ни каже какво сме постигнали.
Посещенията са се увеличили.
Страниците изглеждат по-добре.
Някой показател в Lighthouse е по-висок.
Нова функционалност се използва.
Conversion rate се е променил.
Всичко това може да бъде полезна информация.
Но ако едва след внедряването решаваме как изглежда успехът, имаме сериозен проблем.
Често можем да намерим число, което се е подобрило.
Това не означава, че сме променили правилното нещо.
Затова измерването не започва след проекта.
Започва преди него.
С въпроса:
По какво ще разберем, че тази промяна действително работи?
„Направихме го“ не е резултат
Има естествена склонност да измерваме проекта чрез изпълнението му.
Новият сайт е пуснат навреме.
Новият модул работи.
Всички планирани страници са готови.
Миграцията е приключила.
Това са важни показатели за изпълнение.
Но те казват дали сме свършили работата.
Не казват дали работата е постигнала причината, заради която сме я започнали.
Ако целта е била хората да намират по-лесно подходящ продукт, фактът, че сме създали нови филтри, не доказва, че вече го правят.
Ако целта е била да намалим ръчната работа, фактът, че сме внедрили автоматизация, не доказва колко работа действително е отпаднала.
Ако целта е била да получаваме повече качествени запитвания, увеличението на трафика не доказва това.
Така се връщаме към фундаменталната разлика между:
това, което сме направили
и
това, което сме променили.
Измерването започва от целта
Да приемем, че бизнесът казва:
„Искаме нов checkout.“
Ако останем на това ниво, измерването също ще бъде неясно.
Можем да гледаме скоростта.
Броя стъпки.
Натисканията на бутоните.
Времето за попълване.
Всички те могат да имат значение.
Но защо изобщо променяме checkout-а?
Да приемем, че реалната цел е:
повече от потребителите, които започват checkout, да могат успешно да завършат поръчката без ненужно затруднение.
Това вече променя начина, по който мислим за измерването.
Основният въпрос става:
По какъв наблюдаем резултат бихме разбрали, че това се случва по-често?
Едва оттам можем да избираме подходящи показатели.
Не обратното.
Показателят трябва да следва промяната, а не наличния dashboard
Това звучи очевидно, но на практика често правим обратното.
Отваряме Analytics.
Виждаме какво вече измерваме.
И избираме от наличните числа.
Sessions.
Users.
Engagement.
Conversion rate.
Revenue.
Clicks.
Impressions.
После се опитваме да свържем някое от тях с проекта.
Понякога това е достатъчно.
Но понякога най-важният сигнал изобщо не се измерва.
Тогава правилният въпрос не е:
„Кой KPI да използваме?“
А:
„Каква информация трябва да имаме, за да разберем дали целта се подобрява?“
Ако тази информация липсва, част от подготовката на проекта може да бъде именно създаването на начин да я наблюдаваме.
Един показател не е достатъчен, ако подобрението създава нов проблем
Да се върнем към checkout-а.
Представете си онлайн магазин, при който има основания да смятаме, че процесът създава ненужно затруднение.
Формата е дълга.
Има полета, чиято необходимост не е очевидна.
Методите за доставка се показват сравнително късно.
При грешка част от съобщенията не са достатъчно ясни.
Решаваме да го преработим.
Лесно е да кажем:
„Ще направим checkout-а по-лесен.“
Но това не е достатъчно за измерване.
Преди промяната трябва да уточним какво очакваме да стане различно.
Например:
по-голяма част от потребителите, които започват checkout, да го завършват успешно.
Това ни дава основен сигнал, който можем да следим.
Но трябва да зададем и втори въпрос:
Какво не трябва да се влоши, докато постигаме този резултат?
Да приемем, че след промяната checkout completion rate се подобри.
На пръв поглед имаме успех.
Но ако сме премахнали стъпка или поле, което е предотвратявало грешен адрес или неподходящ избор на доставка, може едновременно да се увеличат:
грешните поръчки;
необходимите ръчни корекции;
контактите с обслужването;
неуспешните доставки.
Основният показател се подобрява, но друга част от системата започва да плаща цената.
Затова при важна промяна трябва да знаем две неща:
Какъв резултат искаме да подобрим?
и
Какво не трябва да влошим, докато го правим?
Не е необходимо всяка промяна да бъде следена с 30 KPI.
Колкото повече показатели наблюдаваме без ясна причина, толкова по-лесно е да изгубим основния въпрос.
Трябват ни толкова сигнали, колкото са необходими, за да разберем:
получихме ли желаната промяна и каква цена платихме за нея?
Conversion rate не е универсалният отговор
При онлайн магазините conversion rate естествено получава голямо внимание.
И с основание.
Но сам по себе си той не може да бъде цел на всяка промяна.
Ако променим информационна страница, която трябва да помогне на хората да разберат сложен продукт, директната покупка може да не е единственото разумно измерване.
Ако работим по органичната архитектура на сайта, резултатите могат да се появят по различен начин и в различен времеви хоризонт.
Ако автоматизираме административен процес, conversion rate може въобще да няма отношение към целта.
Ако подобрим продуктовите данни, част от стойността може първо да се появи в по-добро управление на каталога, а после в клиентския интерфейс.
Следователно не търсим „най-важния KPI на онлайн магазина“.
Търсим правилния сигнал за конкретната промяна.
Времето също е част от измерването
Не всички резултати се появяват веднага.
Ако коригираме техническа грешка в checkout, ефектът може да бъде видим сравнително бързо.
Ако променяме SEO архитектура, трябва да приемем, че търсачките и потребителското поведение няма да реагират по същия график.
Ако променим продуктова структура, част от резултата може да зависи от това колко продукти вече са обработени по новия модел.
Ако променим вътрешен процес, хората може първо да трябва да свикнат с него.
Затова „ще видим дали работи“ не е достатъчен измервателен план.
Трябва да знаем и:
кога би било разумно да очакваме сигнал.
Иначе рискуваме да обявим бавна промяна за неуспешна твърде рано или да чакаме прекалено дълго решение, което очевидно не работи.
Преди промяната ни трябва отправна точка
Ако искаме да кажем, че нещо се е подобрило, трябва да знаем спрямо какво.
Това не означава непременно сложен експеримент.
Но означава поне да разбираме текущото състояние достатъчно добре.
Как се държи процесът сега?
Какъв е нормалният диапазон?
Има ли сезонност?
Има ли промени в трафика?
Променя ли се продуктовият микс?
Имало ли е паралелни кампании или други промени?
Тук лесно навлизаме в по-дълбокия въпрос как данните трябва да бъдат интерпретирани — тема, която заслужава собствен анализ.
За бизнес решението обаче е достатъчен един принцип:
Не можем да оценим промяната, ако нямаме разумна отправна точка.
Измерването може да покаже, че сме сгрешили
Това е една от най-полезните му функции.
Не да докаже, че проектът е успешен.
А да ни позволи да разберем, когато не е.
Ако предварително сме казали какъв резултат очакваме и той не се появи, имаме нова информация.
Може решението да е изпълнено лошо.
Може причината да е била друга.
Може ефектът да е по-слаб от очакваното.
Може друга част от системата да го ограничава.
Тогава не трябва да защитаваме проекта само защото вече сме инвестирали време в него.
Трябва да се върнем към анализа.
Грешната хипотеза е полезна, когато системата ни позволява да разберем, че е грешна.
Най-опасното измерване е това, което започва с желания извод
Представете си, че сме направили голям редизайн.
Инвестирали сме време, бюджет и много вътрешна енергия.
След пускането показателят, който е трябвало да се подобри, не се променя осезаемо.
Но organic traffic е малко по-висок.
Някои страници се зареждат по-бързо.
Потребителите посещават повече страници.
Лесно е да изберем показателя, който изглежда най-добре, и да кажем:
„Проектът беше успешен.“
Може и да е бил.
Но ако причината за редизайна е била друга, тези числа не отговарят на въпроса, заради който проектът е започнал.
Когато критерият за успех се избере след резултата, измерването лесно се превръща в оправдание.
Когато се избере преди промяната, то се превръща в проверка.
Как бих формулирал измерването преди проект
Не започвам с огромен списък от KPI.
Започвам с няколко въпроса.
Каква промяна очакваме?
Не какво ще направим, а какво трябва да стане различно.
Кой наблюдаем резултат най-добре би показал, че това се случва?
Това е кандидатът за основен сигнал.
Какво не трябва да се влоши?
Тук определяме защитните сигнали.
Какво е текущото състояние?
Без отправна точка сравнението е слабо.
Кога очакваме промяната да стане видима?
Не всички ефекти имат еднакъв хоризонт.
Какво бихме заключили, ако очакваният резултат не се появи?
Последният въпрос е особено важен.
Той ни принуждава да приемем още преди проекта, че решението може да не сработи.
Измерването е част от самото решение
Ако не можем да обясним по какво ще разберем, че дадена промяна работи, има голяма вероятност самата цел още да не е достатъчно ясна.
Може да се окаже, че нямаме необходимите данни.
Че следим удобен показател вместо важния.
Или че предложената промяна няма достатъчно ясна връзка с резултата, който търсим.
Затова въпросът:
„По какво ще разберем, че работи?“
трябва да бъде зададен преди:
„Кога ще бъде готово?“
Извършената промяна не е доказателство за постигнат резултат.
Измерването трябва да ни позволи да разберем дали сме подобрили това, заради което проектът е започнал — включително когато отговорът е „не“.