Theorist Dec 5 2010 at 13:11

Интеграция оффлайн статистики с Google Analytics

5 min

12K

Задача – получение точных данных об источниках конверсий в Интернет-магазине, чтобы иметь представления о реальной отдаче из разных рекламных каналов и их взаимодействии:

SEO (Яндекс, Google, Rambler, Mail);
Контекстная реклама (Яндекс.Директ, Google Adwords, Бегун);
Системы выбора товаров (Яндекс.Маркет, Price.ru и т.п.);
Прочие источники переходов (сайты партнеров, различные агрегаторы трафика).

Проблемы онлайн-статистики

Всем известны проблемы онлайн-статистики, поэтому перейду сразу к сути – любые пусть даже самые хорошие системы сбора данных не позволяют учесть оффлайн-конверсии. Пока пользователь совершает какие-то действия в онлайн, мы все о нем знаем, но как только дело доходит до телефона, наши счетчики сразу теряют его из виду. В различных областях интернет-торговли общение с продавцом по телефону играет разную роль, но в нашем случае это важно. Сразу оговорюсь, что речь идет об Интернет-магазине керамической плитки, где, в принципе, сложно продавать онлайн, т.к. покупателю необходим непосредственный зрительный и тактильный контакт с товаром и консультации продавца. Поэтому в нашем случае учет оффлайн-конверсий является необходимостью. Для этих целей мы разработали собственную систему учета посетителей – Хамелеон. Принцип ее работы не нов, на рынке уже представлены довольно большое количество подобных инструментов и систем. Мы хотим рассказать лишь о том, как синхронизировать собранные у себя данные с данными Google Analytics (GA) и, собственно, для чего это вообще нужно.
И для начала необходимо рассмотреть вторую часть проблем, а именно, проблемы, связанные со сбором и обработкой данных об оффлайн-конверсиях. Во-первых, нужно рассказать какие есть методы отслеживания:

Подмена номера телефона

Для каждого источника трафика свой номер. У метода есть свои ограничения и недостатки:

Ограниченное количество телефонных номеров не позволяет сделать неограниченное количество источников и провести по ним учет. Например, учет по ключевым фразам из поиска;
Сравнительная сложность организации, т.е. тут вам не обойтись одним PHP-программистом, придется подключать специалистов другой специализации;
Как следствие высокая стоимость установки.

Купоны на скидку

Когда посетителю предлагается распечатать некий купон с номером для получения скидки, здесь:

Собственно сами скидки – их могло и не быть и, наоборот, если у вас есть политика и общая система скидок с продаж, например, накопительного характера, вряд ли вам захочется усложнять ее за счет купонных;
Никому не охота заниматься распечатыванием, лень или просто нет принтера;
Портит наше юзабилити – если место на страницах сайта четко распланировано, если все лежит там, где надо и мы стараемся лишний раз не отвлекать пользователя, то купон (а он должен быть отчетливо видим) будет лишним.

Раздача ID каждому пользователю

Когда каждый пришедший на сайт посетитель получает свой ID и видит его либо возле номера телефона, либо возле товара, проблемы:

Иногда пользователь выписывает номера телефонов нескольких сайтов для обзвона всех подряд, конечно же, без ID;
Человеческий фактор в виде продавца на телефоне:

Есть еще некоторые способы учета посетителей, но они либо не точны, либо это интерпретации вышеперечисленных методов, поэтому остановлюсь на основной тройке.

Система учета оффлайн-конверсий Хамелеон

Мы, в конечном итоге, выбрали последний метод учета, т.к. в нашем случае он подошел больше, назвали собственную систему Хамелеон и научили его следующим нехитрым действиям:

Определять url источника перехода на сайт;
Ключевую фразу, по которой пользователь нашел ссылку на наш магазин;
Нумеровать посетителей и отдавать каждому свой ID (показывается под изображением каждого товара);
Записывать каждому посетителю в Cookie его ID для запоминания;
Сохранять данные (что, когда, на какую сумму заказал) о покупателях – тех, кто совершил покупку с сайта;
Вводить данные о покупках самим продавцом, когда покупатель оформляет покупку по телефону.

Про то, как вообще строится подобная система и с какими проблемами мы столкнулись, я опишу в следующей статье, конечно, если эта будет кому-нибудь интересна.
И вот дальше выяснилось следующее – для всех трех методов (с подменой, купонами или ID) существует общий ворох проблем, которые сильно мешают адекватно оценивать расходы на рекламу и вносят высокую степень погрешности в достоверность данных.
Вот некоторые из них:

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

Согласитесь, достаточно для того, чтобы испортить всю собранную статистику…
Поэтому мы решили найти какой-то способ слежения за пользователем, который позволил бы нам ответить на все вышеперечисленные вопросы, метод получения полной статистики о наших покупателях. Поскольку мы маленькая компания, в штате которой всего 6 человек, мы не можем позволить себе разработку большой системы статистики, какой как GA или Liveinternet. Помимо этого нам бы не хотелось обременять себя хранением огромных массивов статистических данных, которые мы могли получить. Да и создавать велосипед заново тоже не лучший выход, поэтому мы решили выбрать и воспользоваться чужими наработками в области статистики и интегрировать их с нашим Хамелеоном. Для этих целей был выбран GA.

Интеграция: Хамелеон & Google Analytics

Дальше нам понадобилось лишь взять базовый метод передачи данных, и вот тут мы совершили ошибку, вместо использования пользовательских переменных _trackPageview, мы взяли учет событий _trackEvent. Этот метод хоть и похож, но имеет одно очень важное отличие – он создает событие, т.е. если пользователь попадает на сайт и мы фиксируем событие, то GA учтет его как переход внутри сайта, что не будет являться отказом. После выяснения этой особенности мы изменили подход и начали передавать данные в GA, используя пользовательские переменные через _trackPageview.
Для этого в самом коде GA (стандартное отслеживание) перед pageTracker._trackPageview(); прописываем формирование переменной:

pageTracker._setCustomVar(1, 'id', '3456', 2); 

pageTracker._trackPageview();

Для асинхронного кода отслеживания:

_gaq.push(['_ setCustomVar', 1, 'id', '3456', 2]); 

_gaq.push(['_trackPageview']);

Спецификация данного метода:
_setCustomVar(index, name, value, opt_scope)

Параметры

Int index – Позиция, использованная для пользовательской переменной. Возможные значения: 1-5, включительно.
String name – Имя пользовательской переменной.
String value – Значение пользовательской переменной.
Int opt_scope – Область действия, использованная для пользовательской переменной. Возможные значения: 1 для уровня посетителя, 2 для уровня сеанса и 3 для уровня страницы.

Результат

Таким образом, Хамелеон, у нас раздает всем пользователям свой уникальный ID, записывает его в Cookie и отправляет в Google Analytics. А мы в конце каждого месяца получаем таблицу с покупками у нас на сайте со списком ID каждого покупателя и заходим для анализа их поведения в Analytics. Там мы можем:

Сгруппировать всех своих покупателей в один сегмент, ну например, – «покупатели октябрь»;
Проверить общие характеристики выбранного сегмента и сравнить с остальными данными;
Получить информацию о том, как наши покупатели шли к своей цели, начиная от входа на сайт и заканчивая выбором товара.
И т.д

Вот как это выглядит на экране у нас:
Это пути по сайту конкретного покупателя, мы создали сегмент, включающий пользователя только с конкретным ID. К слову, можно взять все ID всех покупателей за определенный период и сравнить их поведение с поведением остальных посетителей.
Итак, он трижды заходил к нам на сайт в период с 17.11.2010 по 20.11.2010, просмотрел всего 6 страниц и провел на сайте 5 с половиной минут.