Ищем проблемы с конверсией сайта в Google Spreadsheets

Привет! Меня зовут Дмитрий Окунев, я работаю product-менеджером в финтех-компании ID Finance. Это первый пост в блоге компании. Здесь мы будем делиться опытом, в том числе и международной экспертизой. Поехали.

В большинстве онлайн-бизнесов конверсия сайта — краеугольный камень превращения лида в клиента. Мы в ID Finance делаем огромное количество изменений, которые могут отражаться на CR как в положительную, так и отрицательную сторону, поэтому без постоянного, буквально ежедневного трекинга эффективности конверсионной воронки работать было бы проблематично.
Есть много разных подходов к измерению конверсии своего сайта, мы для подобного трекинга разработали свой формат дэшборда, который основан на ежедневной автоматизированной выгрузке воронки из Google Analytics. Почему именно такой способ?

• Google Analytics — сессионная аналитика, нас же в большинстве случаев интересуют пользователи, т.е. уникальные clientID. Эти данные проще всего получить, запросив метрику users из GA.
• Дэшборд в нашем случае — это обычный Google Spreadsheet файл, которым легко можно делиться, задавать права разным пользователям, а чтение его не требует большого опыта работы с аналитикой.
• Данные отчета подходят для периодических отчетов перед стейкхолдерами, они легко считываются и обновляются, по ним сразу видны конверсионные изменения в продукте.
• Гибкий формат отчета позволяет, помимо мониторинга CR, выполнять ряд других задач: быстро находить проблемные места пользовательского флоу, замерять AB-тесты, проверять гипотезы, проводить быстрые расчеты на данных и т.д.

Зачем это нужно?

История знает крайне мало случаев, когда продукт с первой итерации начинает конвертировать входящий трафик в клиентов так эффективно, как хотелось бы. Капканы расставляем мы сами: неэффективный и сложный UX, большое количество форм для заполнения, баги, количество которых растет с каждой поставкой — со всем этим можно и нужно работать. Но чтобы понимать, с чем работать, проблемы предварительно нужно: a) локализовать, b) постоянно мониторить, ведь как продукт, так и качество трафика постоянно меняются. Имея под рукой инструмент для отображения текущей ситуации, можно быстро принимать решения по улучшению, отслеживать проблемы, реализовывать дополнительный трекинг (если они затрагивают пользовательский флоу).

Сейчас каждый из наших проектов (компания работает в восьми странах под четырьмя брендами) содержит собственный отчет, каждый из которых содержит 10-15 дэшбордов, покрывающих все основные юзкейсы как для новых, так и для повторных клиентов, включая мобильное приложение.

Как это работает?

Любую воронку на сайте можно описать как последовательность некоторых действий пользователя. Google Analytics дает возможность описать эту последовательность в виде сегмента.
Сами сегменты делятся на условия и последовательности, а также задаются областью действия: пользователи (users) или сессии (sessions). Для получения нужной группы пользователей можно задавать пересечения (наложить условие на последовательность). К примеру, если мы хотим получить картину по воронке клиентов только с мобильных устройств, при этом участников определенной вариации AB-теста.

Google Analytics предоставляет специальный Core Reporting API для доступа к нужным нам данным. Ознакомиться с ним можно по ссылке ^[1]. Подробно останавливаться на синтаксисе запросов мы здесь не будем — документация Google будет в любом случае куда более исчерпывающей.

Вот лишь несколько примеров сегмента, который можно запросить в Core Reporting API:

1. 1) Получить список всех пользователей с мобильных устройств, бывших на странице /registration/step1:

   users::condition::ga:deviceCategory==mobile;ga:pagePath==/registration/step1

2. 2) Получить список пользователей, бывших на странице /registration/step1, а затем на странице /registration/step2:

   users::sequence::ga:pagePath==/registration/step1;->>ga:pagePath==/registration/step2

Нетрудно догадаться, что если мы хотим посмотреть на конверсию перехода со страницы /registration/step1 на /registration/step2, а затем со второй на третью и так далее, нам надо последовательно сделать запрос на шаг 1, затем на шаг 1 и шаг 2, и так до победного конца. Для этого мы используем небольшой скрипт, о котором написано чуть ниже.

Наш Spreadsheet

Путем множества экспериментов, мы пришли к следующему формату дэшборда — для каждого проекта создается свой Google Spreadsheet документ с набором интересующих нас воронок и парой страниц на конфигурацию.

Вот он в своем исходном состоянии (плюс простой пример). Ссылка ^[2].

Файл в read-only режиме, поэтому проще всего скопировать его к себе и все эксперименты проводить оттуда.

Структура файла:

Лист ‘Funnels’ содержит описания всех сегментов, в нашем случае воронок, описывающих различный пользовательский флоу. К примеру, там обязательно будет описан флоу заполнения анкеты для нового клиента, все способы для повторных (у них может быть несколько точек входа), воронка для предодобренных клиентов и.т.д.

Параметры данного листа:

• Reference Segment — референсный сегмент. Сюда можно внести, например, всех клиентов с первой сессией на сайте. Данный сегмент не будет склеиваться в последовательность и запрашивается отдельно. Он опционален.
• Additional user condition for Funnel — дополнительный параметр пользователя, который можно наложить на воронку (например, вариация AB-теста, ее для этого нужно записывать в GA, например, в один из Custom Dimensions)
• Additional session condition for Funnel — дополнительный параметр сессии, который можно наложить на воронку (например, ga:source==google;ga:medium==cpc — только пользователи из контекстной рекламы Google).
• Sequence type — users или sessions. Тип последовательности, который будет запрошен, пользователи или сессии. По умолчанию будет запрашиваться users.
• Funnel steps — то, ради чего мы собрались. Здесь последовательно вносим все шаги воронки, которые нас интересуют. Шагом может быть любой тип обращения (hit), в нашем случае это события (event) и просмотры страниц (pageview).

К примеру, заполнение новой анкеты будет выглядеть так:

При выгрузке отчета все строки из правого столбца будут объединены через символы ‘->>’, что в синтаксисе GA означает нестрогую последовательность действий (каждый следующий шаг ищется после предыдущего, но не обязательно сразу). Отчет поддерживает также формат последовательности “следует сразу за”, для этого в начале нужной строки нужно установить символы ‘->’. То есть, строка ‘ga:pagePath=~^Q/secure/registration/step4E’ говорит скрипту выгружать количество пользователей, которые за данный период были на URL /secure/registration/step4, а перед этим на /secure/registration/step3, но не обязательно подряд. Строка же ‘->ga:pagePath=~^Q/secure/registration/step4E’ заставит скрипт искать строгую последовательность, где пользователь посетил шаг анкеты 3 и сразу после перешел на шаг 4 (подразумевается, что никаких других обращений, включая события, между ними тоже не отправлялось).

Лист ‘Configuration’ — здесь мы храним конфигурации отчетов. Каждый отчет выгружается и сохраняется в отдельный лист документа.

Параметры листа:

• Run ? — доступны варианты Periodic и Once. Первый вариант выбираем, если хотим делать периодичный апдейт отчета. В этом случае в соответствующий лист при выполнении будет добавлена одна строка сверху с новыми данными, соответствующими выбранному периоду. Once — для однократного прогона. В этом случае лист будет перезаписан целиком, поэтому нужно быть осторожным с выбором данного параметра. Новый отчет лучше создавать в режиме ‘Once’, после чего просто переключать в ‘Periodic’, если требуется продолжить выгрузку по таймеру.
• View (Profile) ID — ID представления из Google Analytics, откуда выгружаем данные. Записывается в формате ‘ga:XXXXXXXXX’.
• Start/End Date — за какой период выгружаем данные. Будет проигнорирован при повторных прогонах отчета Periodic — он будет отталкиваться от дат в самой выгрузке.
• Period Type — доступны варианты ‘daily’ — ежедневно, ‘WoD’ — скользящее окно в 7 дней (мы используем в отчетах для кейсов, когда трафика мало, и ‘daily’ показывает большую волатильность), ‘WoW’ — календарная неделя, ‘Whole Period’ — получить данные за весь период одной строкой (с отчетами ‘periodic’ по понятным причинам не совместим).
• High precision? — уровень семплирования данных. Подробнее про него почитать можно, например, тут ^[3]. По умолчанию ‘yes’, лучше так и оставить.

Строки ниже, вплоть до ‘Funnels’, содержат данные ответа GA, тут заполнять ничего не нужно.

Funnels — здесь выбираем одну или несколько воронок с листа ‘Funnels’, на основе которых будет выгружаться отчет.

Скрипт для выгрузки

Идем в Tools — Script Editor. Вот небольшой скрипт для выгрузки данных:

Скрипт довольно долго не обновлялся и на него все еще есть множество планов по улучшению. К примеру, если время выгрузки превышает 5 минут, скрипт может остановиться, выдав ошибку — необходимо продолжать выгрузку с этого момента новым запросом.

Мы выкладываем его “как есть”, вы можете воспользоваться им, доработать его по своему вкусу или написать свой собственный.

Чтобы запускать скрипт, предварительно необходимо дать ему разрешение на доступ в ваш профиль Google Analytics и открыть доступ к GA API в Google Cloud Console. При первом прогоне скрипта вы получите ошибку со ссылкой в строке ‘Last Run Status’ листа ‘Configuration’, перейдите по ссылке и включите доступ к API. При необходимости можно там же увеличить квоты на запросы API, если текущих будет недостаточно.

Основные кейсы, которые мы решаем с его помощью — периодическая и разовая выгрузка определенных отчетов — покрываются функциями ‘runPeriodicReports’ и ‘runOneOffReports’. Для запуска ‘Periodic’ отчета используем функцию ‘Current Project’s Triggers’, где выбираем ‘runPeriodicReports’ и периодичность запуска.

Пример использования

Предположим, нам интересно, как менялась воронка анкеты новых клиентов в течение месяца. Для этого создадим нужную последовательность на листе ‘Funnels’. Пусть это будет последовательность, описанная выше — назовем ее ‘new clients’.

Теперь создадим конфигурацию отчета, который выгрузит нам данные по воронке ‘new clients’. Для этого выберем период с 10.01.2018 по 31.01.2018, зададим период выгрузки ‘daily’ и периодичность ‘once’.

Теперь идем в ‘Tools’ — ‘Script Editor’, выбираем ‘runOffReports’ (т.к. мы выбрали периодичность выгрузки ‘Once’, и кликаем ‘Run’.

У нас создастся новый лист, на котором через некоторое время появятся данные: число пользователей на каждом этапе воронки.

Разделим каждый следующий шаг на предыдущий простейшей формулой и переведем результат в проценты, чтобы получить конверсию в процентах. Добавим также агрегированную конверсию, пусть это будет значение decision (наша ‘thank you page’) / s1 — то, как работает наша анкета от начала до конца. Это будет полезно отделу маркетинга.

Построим графики.

Видно, что 26.01 на очередной поставке мы улучшили конверсию ближе к концу воронки. Низковата конверсия на первом шаге воронки — место, где происходит создание пользователя в БД. Это может быть и структура трафика (много нецелевых клиентов), и проблемы UI.

Иногда картина бывает менее приятной.

Видно, что какие-то изменения ухудшили нашу конверсию в нескольких местах. Есть смысл посмотреть записи сессий, дать задачу QA поискать баги, а возможно и задуматься о том, насколько правильные изменения мы внесли в этих местах продукта.

Если полученный отчет нас устраивает, выставим в ‘Current Project Triggers’ периодичность запуска в ежедневную (выставим время запуска ночью, чтобы утром уже было на что посмотреть), и переведем его на листе ‘Configuration’ в режим ‘Periodic’. С этого момента наш график будет обновляться в ежедневном режиме.

Заключение

Данным способом можно не только получить ежедневные графики конверсии. Мы используем его для быстрой оценки AB-тестов, поиска проблем с трафик-партнерами и некоторых других задач. Конечно, одним им ограничиваться не стоит, и уж точно не стоит отказываться смотреть на цифры в вашей базе данных в пользу этого отчета, но для поиска узких мест вашей воронки и мониторинга его смело можно применять.

Если вы используете собственные нестандартные решения для трекинга конверсии, делитесь в комментариях — будем рады обсудить!

Чуть-чуть о нас

Финтех-холдинг ID Finance специализируется на data science и кредитном скоринге. Как приложение нашей экспертизы в области сбора и анализа данных, а также построения скоринговых моделей, компания запустила собственные финансовые сервисы под брендами MoneyMan, Solva, Plazo и AmmoPay. Это проекты кредитования физических лиц и микробизнеса, автоматизации POS-кредитов и программы рассрочки. Мы работаем в восьми странах на четырех континентах, включая Европу, Азию и обе Америки. Штаб-квартира компании находится в Барселоне, R&D центр в Минске, а команда data-аналитиков и риск-менеджеров в Москве. Помимо меня в компании работает еще около 600 человек. Может показаться, что мы малоизвестная компания. Но это не совсем так. На Западе нас неплохо знают. О нас, например, пишут Forbes, Business Insider, Finextra, Venture Beat, Crowdfund Insider, The Banker и BBC. Благодаря ребятам из PR мы также публикуемся в русскоязычных медиа: Forbes, VC, Roem, RusBase и др. Несколько раз в месяц мы будем публиковать наши посты, делиться нашими новостями, удачными и не совсем кейсам. Будем на связи!

Автор: IDFinance

Источник ^[4]