В работе компании EastBanc Technologies часто встает задача не просто анализа статистики посещаемости и поведения по географическим, платформенным и демографическим признакам, а по принципу, что делает конкретный пользователь на портале, в мельчайших подробностях. Для нас, как для разработчиков корпоративных систем, эта информация бывает критически важной с точки зрения развития системы.
Например, сейчас у нас в работе есть SharePoint-портал, который используется для дистанционного расчетно-финансового обслуживания контрагентов компании-заказчика. У каждого контрагента имеется несколько пользователей — от 1 до 10. Мы хотели понять, как они обращаются с тем или иным функционалом. Чтобы обрисовать для себя их поведение, мы задействовали средства Google Analytics.
Почему мы не опросили фокус-группу? По нашему опыту, опросы бесполезны, в результате всегда получаешь искаженную информацию, т.к. какой-то процент людей может отделаться отпиской, драматизировать или, наоборот, выставить все в более радужном свете, ну и наконец, просто немотивированно солгать (а что, всякое бывает:)). Точно отслеженная цепочка действий юзера на портале — вот что дает объективную, актуальную, полезную информацию. Также хорошая аналитика помогает по-разному оценивать разные группы контрагентов, среди которых встречаются как крупные предприятия, так и совсем маленькие, и ровнять их под одну гребенку нельзя.
Как известно, Google запрещает сохранять данные, которые могут однозначно идентифицировать пользователя.
Цитируем пользовательское соглашение:
7.PRIVACY. You will not (and will not allow any third party to) use the Service to track or collect personally identifiable information of Internet users, nor will You (or will You allow any third party to) associate any data gathered from Your website(s) (or such third parties' website(s)) with any personally identifying information from any source as part of Your use (or such third parties' use) of the Service. You will have and abide by an appropriate privacy policy and will comply with all applicable laws relating to the collection of information from visitors to Your websites. You must post a privacy policy and that policy must provide notice of your use of a cookie that collects anonymous traffic data.
Для преодоления этих ограничений и расширения данных для более разностороннего анализа Джастин Кутрони, Analytics Evangelist в Google, предлагает добавить ID пользователя в Google Analytics.
По сути, предлагается идентифицировать пользователя неким уникальным GUID, затем с помощью Data Query Feed выгрузить данные в свою систему, сопоставить взаимно однозначное соответствие с пользователями и строить аналитику своими силами.
Большое и главное «но» такого решения – сложно, дорого и неудобно. Очевидно, что реализовать что-то подобное Google Analytics для просмотра отчетов на своей стороне непросто, и является попросту неэффективной тратой денег.
Именно поэтому, мы стали искать иной путь, и в итоге получилось следующее:
1. Все контрагенты идентифицируются номером договора или номером в учетной системе, все пользователи приравниваются к нему. Таким образом, можно для идентификации пользователей использовать этот номер, который не является персональными данными.
2. По умолчанию выбирается переменная «visitor».
Любую аналитику теперь можно проводить в разрезе всех юзеров-контрагентов. Для этого на страницах Google Analytics в разделах, предполагающих фильтрацию/группировку/добавление в отображение, необходимо выбрать параметр Мои переменные->Моя переменная (значение 01).
Дополнительно мы разделили пользователей по языку и разделили контрагентов и сотрудников компании-заказчика. Трекинг по языку идет автоматически за счет выбора стандартного способа установки локации пользователя.
Разделение на пользователей на контрагентов и сотрудников компании-заказчика происходит с помощью «маркера пользователя»:
Таким образом, мы смотрим на попытку авторизации пользователя и получаем/не получаем код контрагента. Если не авторизовался, расцениваем как анонима; авторизовался, но не вернулся код агента — как сотрудника; вернулся код контрагента — это контрагент.
3. Добавляется трекинг на уровне страниц. В каждой master page нашего SharePoint-портала мы добавили код, который трекает эту переменную:
4. Добавляется трекинг на уроне WCF-сервисов: к просмотру страниц мы прицепили коды контрагента, но внутри одной страницы контрагент может выполнять много действий. Обращения к WCF идут через специальный слой сервисов. До сих пор нам это давало два преимущества: не нужно копировать громоздкий код по организации ajax-вызовов и можно сделать обработку ошибок в едином стиле за счет обработчика ошибок в базовом классе. То есть код, которому нужны данные, не загрязнен мелкими техническими деталями.
Через эти же сервисы мы разместили и трекинг событий на случай успешного завершения вызова. Все это работает на promises, поэтому внесение этой функциональности в сервиса не потребовало никаких изменений в коде-потребителе.
Мы создали следующие кастомные категории и виды событий внутри категории (это делается по стандарту GA).
Список категорий:
a. MakeToDo
b. Курсы валют
c. Dashboard
d. Платежи
e. Счета.
Список событий, которые мы отслеживаем:
a. Просмотр списка
b. Просмотр объекта
c. Удаление объекта
d. Изменение объекта
e. Загрузка файла
f. Принятие расчетного документа
g. Аннулирование/восстановление счета.
(Напомним, данная система, которую мы рассматриваем в качестве примера, регулирует расчетно-финансовые взаимоотношения между контрагентами и компанией-заказчиком, этим обусловлены названия категорий и событий).
Возьмем для примера одно событие:
5. Для того чтобы посмотреть, какие агенты какие действия и в каком объеме совершались на портале, необходимо зайти в раздел Поведение->События->Карта событий и в левом углу экрана в зеленом выпадающем списке выбрать Мои переменные->Моя переменная (значение 01). Получим примерно следующую картину:
Картинка кликабельная
<
">
Картинка кликабельная
<
>
Аналитика ведется, в первую очередь, по контрагентам. Также отдельными пунктами идут анонимные пользователи и сотрудники компании-заказчика.
Почему нам важно было получить решение, которое позволит точно оценивать, как ведут себя пользователи на портале? Потому что нам важно понимать, используют ли люди, созданные нами интерфейсы, модули, бизнес-процессы так, как это было задумано.
И не забываем о другом важном факторе: на правильную настройку Google Analytics мы потратили очень разумное время и усилия, использовав совершенно стандартные средства. Всё, как мы любим:)
Например, сейчас у нас в работе есть SharePoint-портал, который используется для дистанционного расчетно-финансового обслуживания контрагентов компании-заказчика. У каждого контрагента имеется несколько пользователей — от 1 до 10. Мы хотели понять, как они обращаются с тем или иным функционалом. Чтобы обрисовать для себя их поведение, мы задействовали средства Google Analytics.
Почему мы не опросили фокус-группу? По нашему опыту, опросы бесполезны, в результате всегда получаешь искаженную информацию, т.к. какой-то процент людей может отделаться отпиской, драматизировать или, наоборот, выставить все в более радужном свете, ну и наконец, просто немотивированно солгать (а что, всякое бывает:)). Точно отслеженная цепочка действий юзера на портале — вот что дает объективную, актуальную, полезную информацию. Также хорошая аналитика помогает по-разному оценивать разные группы контрагентов, среди которых встречаются как крупные предприятия, так и совсем маленькие, и ровнять их под одну гребенку нельзя.
Ограничения
Как известно, Google запрещает сохранять данные, которые могут однозначно идентифицировать пользователя.
Цитируем пользовательское соглашение:
7.PRIVACY. You will not (and will not allow any third party to) use the Service to track or collect personally identifiable information of Internet users, nor will You (or will You allow any third party to) associate any data gathered from Your website(s) (or such third parties' website(s)) with any personally identifying information from any source as part of Your use (or such third parties' use) of the Service. You will have and abide by an appropriate privacy policy and will comply with all applicable laws relating to the collection of information from visitors to Your websites. You must post a privacy policy and that policy must provide notice of your use of a cookie that collects anonymous traffic data.
Для преодоления этих ограничений и расширения данных для более разностороннего анализа Джастин Кутрони, Analytics Evangelist в Google, предлагает добавить ID пользователя в Google Analytics.
По сути, предлагается идентифицировать пользователя неким уникальным GUID, затем с помощью Data Query Feed выгрузить данные в свою систему, сопоставить взаимно однозначное соответствие с пользователями и строить аналитику своими силами.
Большое и главное «но» такого решения – сложно, дорого и неудобно. Очевидно, что реализовать что-то подобное Google Analytics для просмотра отчетов на своей стороне непросто, и является попросту неэффективной тратой денег.
Решение
Именно поэтому, мы стали искать иной путь, и в итоге получилось следующее:
1. Все контрагенты идентифицируются номером договора или номером в учетной системе, все пользователи приравниваются к нему. Таким образом, можно для идентификации пользователей использовать этот номер, который не является персональными данными.
2. По умолчанию выбирается переменная «visitor».
Любую аналитику теперь можно проводить в разрезе всех юзеров-контрагентов. Для этого на страницах Google Analytics в разделах, предполагающих фильтрацию/группировку/добавление в отображение, необходимо выбрать параметр Мои переменные->Моя переменная (значение 01).
Дополнительно мы разделили пользователей по языку и разделили контрагентов и сотрудников компании-заказчика. Трекинг по языку идет автоматически за счет выбора стандартного способа установки локации пользователя.
Разделение на пользователей на контрагентов и сотрудников компании-заказчика происходит с помощью «маркера пользователя»:
authenticated = Tools.IsUserIdentified(out agencyCode);
marker = authenticated ? (agencyCode ?? "Работник"):"Анонимный";%>
Инжектим этот маркер в мастер-страницу:
_gaq.push(['_setCustomVar', 1, 'Пользователь', '<%=marker%>', 1]);
Таким образом, мы смотрим на попытку авторизации пользователя и получаем/не получаем код контрагента. Если не авторизовался, расцениваем как анонима; авторизовался, но не вернулся код агента — как сотрудника; вернулся код контрагента — это контрагент.
3. Добавляется трекинг на уровне страниц. В каждой master page нашего SharePoint-портала мы добавили код, который трекает эту переменную:
_gaq.push(['_setCustomVar', 1, 'Пользователь', '<%=marker%>', 1]);
4. Добавляется трекинг на уроне WCF-сервисов: к просмотру страниц мы прицепили коды контрагента, но внутри одной страницы контрагент может выполнять много действий. Обращения к WCF идут через специальный слой сервисов. До сих пор нам это давало два преимущества: не нужно копировать громоздкий код по организации ajax-вызовов и можно сделать обработку ошибок в едином стиле за счет обработчика ошибок в базовом классе. То есть код, которому нужны данные, не загрязнен мелкими техническими деталями.
Через эти же сервисы мы разместили и трекинг событий на случай успешного завершения вызова. Все это работает на promises, поэтому внесение этой функциональности в сервиса не потребовало никаких изменений в коде-потребителе.
Мы создали следующие кастомные категории и виды событий внутри категории (это делается по стандарту GA).
Список категорий:
a. MakeToDo
b. Курсы валют
c. Dashboard
d. Платежи
e. Счета.
Список событий, которые мы отслеживаем:
a. Просмотр списка
b. Просмотр объекта
c. Удаление объекта
d. Изменение объекта
e. Загрузка файла
f. Принятие расчетного документа
g. Аннулирование/восстановление счета.
(Напомним, данная система, которую мы рассматриваем в качестве примера, регулирует расчетно-финансовые взаимоотношения между контрагентами и компанией-заказчиком, этим обусловлены названия категорий и событий).
Возьмем для примера одно событие:
getDocumentsList = function (data)
{
return dispatcher.call(
{
method: ETR.HttpVerb.POST,
data: data,
relativeUrl: serviceRelativePath + '/documentsList'
})
.fail(dispatcher.faultHandler)
.done(function ()
{
ETR.gatc.track(ETR.gatc.categories.JustificationDocuments, ETR.gatc.actions.ListBrowsing);
});
};
5. Для того чтобы посмотреть, какие агенты какие действия и в каком объеме совершались на портале, необходимо зайти в раздел Поведение->События->Карта событий и в левом углу экрана в зеленом выпадающем списке выбрать Мои переменные->Моя переменная (значение 01). Получим примерно следующую картину:
Картинка кликабельная
<
">Что мы получили в итоге:
- Отслеживаем посещение всех страниц расчетно-финансовой системы заказчика.
- Аналитика, среди прочего, ведется в разрезе языков (сейчас их два — русский и английский).
- Аналитика ведется в разрезе контрагентов. Для того чтобы посмотреть историю посещений, заходим в раздел Персонализированный->Переменные, там видим разрез Пользователи. Зайдя в него, видим примерно следующую картинку:
Картинка кликабельная
<
>Аналитика ведется, в первую очередь, по контрагентам. Также отдельными пунктами идут анонимные пользователи и сотрудники компании-заказчика.
Почему нам важно было получить решение, которое позволит точно оценивать, как ведут себя пользователи на портале? Потому что нам важно понимать, используют ли люди, созданные нами интерфейсы, модули, бизнес-процессы так, как это было задумано.
И не забываем о другом важном факторе: на правильную настройку Google Analytics мы потратили очень разумное время и усилия, использовав совершенно стандартные средства. Всё, как мы любим:)
