А как вы считаете конверсию в регистрации?

Question

[Ренат Абясов]

Коллеги, выручайте! Мы уже всю голову сломали над проблемой грамотного расчета конверсии в регистрации веб-сервиса для массовой аудитории.

Вроде бы все просто — берем Google Analytics, передаем в него событие регистрации, настраиваем цель на это событие. Так мы легко находим абсолютное достигнутых конверсий. А как аналитик считает процент? Вероятно, вычисляет отношение количества регистраций к числу новых пользователей (впервые посетивших сервис).

Но вот не задача — кто такие новые посетители?
Интуиция подсказывает, что это те у кого нет куки аналитика. Ну так ведь периодически кука пропадает (и чем больше у нас пользователей, тем больше доля таких «псевдо-новых» посетителей).

После этого мы стали из всех новых посетителей вычитать тех, кто залогинился.

А потом нас угораздило посчитать все цифры на стороне сервера (правда, количество уникальных визитов взяли из kissmetrics). И получились новые значения. Думаем, что на стороне сервера данные точней (и понятней).

И это мы еще не учти отказы! Ведь если пользователь был на сайте всего несколько секунд, то это значит, что он не целевой. И тут претензия к трафику, а не к сайту (процессу конвертации трафика в регистрации). То есть учет отказов позволит еще точней оценивать влияние изменений сайта на конверсию.

Поэтому мы решили спросить: какое решение удовлетворит следующим запросам:
1) крутится на нашем сервере;
2) имеет механизм вычисления метрик, чтобы можно было указать как считать сложный параметр из простых;
3) строит понятные графики.

Дополнительным плюсом будет умение строить воронки, последовательности конверсий, учет возвратов (когортный анализ).

Answer 1

[Алексей Сундуков]

Каждому посетителю ставим уникальную куку (значение — GUID) на год. При каждом новом открытии страницы обновляем значение еще на год. Естественно если кто-то специально потер свои куки, то он будет засчитан за нового посетителя, но для этого случая ни что не поможет.

Comments

[Ренат Абясов]

С этого все началось. Нельзя быть уверенным, что куки не были потеряны/потерты. И далее — использование сервиса на разных машинах, инкогнито и т.д. Вот вчера один пользователь жаловался, что вынужден каждый раз логиниться в сервисе, несмотря на поставленную галку «Запомнить меня» (там кука на месяц).

А вообще, мы же хотим измерять конверсию новых пользователей в зарегистрированных, а не визиты в регистрации.

[Алексей Сундуков]

Нельзя быть уверенным, что куки не были потеряны/потерты.

Именно. Более того, повлиять или 100% выявить факт потери/затирания невозможно. Поэтому не нужно усложнять задачу и просто забить. Проверка() не прошла, значит это новый посетитель (нельзя его называть пользователем до тех пор, пока он не прошел регистрацию/аутентифика́цию).

Можно попробовать включить в Проверки() JavaScript. В частности, написать JS который будет писать в localStorage. В этом случае можно отследить новичка даже если он затер куку. Только нужно понимать, что такая проверка не будет работать для клиентов с отключенным JS.

Если хотите более точных данных, то как ни крути проверка должно быть многофакторной. Отслеживаем уникальную куку, используем localStorage, привязываемся к IP. В идеале в проверки добавлять поведенческие фильтры. Когда собираем и анализируем статистику действий посетителя от момента входа до времени Х. Когда такая статистика собрана (или логически задана), то новый посетитель поведение которого сильно отличается от этой схемы считается злоумышленником и он не засчитывается как новый посетитель (но засчитывается в счетчик попыток подделки).

От целенаправленной массовой атаки это не спасет, но в относительно нормальных условиях данные можно получить максимально точные.

[Nodge]

alekciy, сбор данных не ограничивается клиентскими технологиями, такими как cookie и javascript. В KissMetrics, например, после входа на сайт можно связать всю сессию посетителя с его аккаунтом. Таким образом, данное посещение не будет считаться новым. И, как следствие, не будет участвовать в расчетах конверсии новых посетителей в пользователей.
Наша же проблема заключается не в том, что нет алгоритмов подсчета (хотя мы можем что-то упускать), а в том, что мы пока не знаем удобного продукта/сервиса, который позволит реализовать эти алгоритмы с минимальными трудозатратами. Не хочется распыляться на 100500 лишних велосипедов во время разработки основного продукта.

[Алексей Сундуков]

сбор данных не ограничивается клиентскими технологиями, такими как cookie и javascript. В KissMetrics

KissMetrics так же использует клиентские технологии. Других вариантов тут нет и быть не может в силу текущей архитектуры интернета.

[Nodge]

Это понятно. Я о том, что помимо сбора «сырых» данных есть еще и постобработка данных на сервере, что позволяет в большинстве случаев восстановить картину, даже если кука была потеряна.

[Алексей Сундуков]

Если посетитель отлючил JavaScript, приём кук и флеш, то ни какая постобработка данных на сервере картину не восстанавливает. Для сервера это каждый раз будет новый посетитель. Но на таких посетителей можно забить, т.к. большая часть людей вообще не представляет, что есть JS, куки и флеш и уж тем более не умеет их отключать. Поэтому мне видится, что стоит использовать KissMetrics и не заморачиваться этим вопросом в данный момент.

[Nodge]

Посетитель, отключивший JavaScript, никогда не станет нашим пользователем, т.к. у нас веб-приложение, а не сайт. Так что да, их не интересно считать, поэтому они никак и не учитываются.
А KissMetrics не покрывает наших задач (почему — есть в вопросе), поэтому и задаем вопрос.

Answer 2

[kevindoth]

может быть поможет справка о куках, которые GA ставит и вот тут еще о времени их жизни