Отслеживание конверсий, которые выполняются НЕ в Интернете

Пользователи, которые нажимают на объявления Google (или переходят по другим источникам рекламы), не обязательно совершат покупку в Интернете. Они могут заказать товар по телефону или купить его в обычном магазине. Импорт офлайн-конверсий позволяет выяснить, как такие действия клиентов связаны с вашей рекламой.

Для чего это нужно?

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

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

При попадании на ваш сайт, посетителю присваивается уникальный идентификатор «CID». Нам нужно связать его с информацией о клиенте, которая у вас есть, и сохранить.

Когда клиент совершает покупку по телефону, вы фиксируете этот идентификатор, а также детальную информацию о транзакции. Полученные данные импортируем в Google Analytics Universal при помощи Measurement Protocol.

Примеры:

1) Услуга «Обратный звонок».

На вашей целевой странице пользователи могут воспользоваться услугой «Обратный звонок». К оператору заявка «Обратный звонок» должна приходить уже с уникальным «CID». Уникальный «CID» можно получить из cookie пользователя (Рис.1.1.).

Рис.1.1 – уникальный идентификатор посетителя «ClientID»

Ваши продавцы анализируют информацию о продажах и периодически направляют нам данные о клиентах, совершивших покупки, в том числе их идентификаторы «CID», а также дату и время каждой сделки. Затем мы загружаем данные в аккаунт Google Analytics Universal при помощи Measurement Protocol. Через несколько часов вы сможете узнать, какие ключевые слова и запросы позволяют привлекать клиентов и увеличивать продажи.

Так вы сможете сэкономить время и в полной мере реализовать свои инвестиции в рекламу.

2) Уникальный код на странице товара.

На карточке товара необходимо выводить уникальный номер. Т.к. уникальный идентификатор посетителя состоит из большого количества символов (Рис.1.1.), его не обходимо сократить. Для этого можно использовать перевод полученного значения в другую систему исчислений, из 10-и ричной в 36-и ричную.

В таком случае, значение «1398152272» будет выглядеть так: N4F974

Сервис для тестирования смены системы исчислений: http://numsys.ru/

Пример реализации (рис. 1.2.):

Рис.1.2. – вывод «CID» на карточке товара

Задача оператора состоит в получении от пользователя уникального номера, отображенного в коде товара. Затем схема полностью аналогична предыдущей ситуации (указанной в примере №1). Все данные о совершенной покупке оператор передает вместе с уникальным идентификатором.

После получения информации мы преобразуем сокращенный идентификатор в его первичный вид и загружаем данные в аккаунт Google Analytics Universal при помощи Measurement Protocol.

Указанный пример на Рис.1.2. не является единственным способом реализации. 

Основная задача стоит перед маркетологом! 

Именно маркетологу необходимо продумать в каком месте страницы вывести уникальный идентификатор. Возможно, это будет дополнительное поле «Промо-код» или другое поле с поощрение за озвученный оператору код (фантазиям маркетолога нет придела ). А основная задача оператора под любым предлогом зафиксировать уникальный код!

Изменения кода сайта.

1) Выше был указан способ конвертации уникального идентификатора в другую систему исчисления. В данном случае работа для программистов минимальная и заключается в выводе уже преобразованного кода в нужном месте на сайте.

Способ преобразования системы измерения в другую не является единственным. 

2) К указанному на Рис.1.1. уникальному идентификатору в таблице соответствия можно присваивать более короткое цифирное значение (генерировать по определенному правилу на основе данных cookie пользователя – Рис.1.1.) и выводить его в контенте сайта (Рис. 1.3). 

Рис.1.3. – вывод «CID» на карточке товара

В таком случае необходимо в собственной базе данных вести таблицу соответствий, у которой будет свой срок жизни.

Преимущества: 

• можно выдавать более короткие цифирные значения;

• можно избежать букв в уникальном коде, оставив только цифры.

Недостатки:

• трудоёмкость для программистов (время на реализацию, внесение доработок в собственную БД, создание нового поля в БД, запись в БД значение соответствия).

Формат отчета.

Как было указанно в начале ТЗ, клиента должен предоставлять файл с данными по офлайн продажам для последующей загрузки в Google Analytics Universal.

Формат может быть любым! Это может быть документ *.XLS или постоянно обновляющийся файл *.XML или *.CSV. Формат подачи информации и обновление файла – по индивидуальной договоренности с клиентом.

Данные которые должны быть предоставлены обязательно:

• уникальный идентификатор (полученный от посетителя);

• номер транзакции;

• сумма транзакции;

• название товара;

• стоимость товара.

Обратите внимание, что необходимо сначала передать данные о транзакции, а затем о каждом товаре!

Что получаем в итоге?

На рис.1.4. теперь можно просмотреть реальный путь клиента до совершения конверсии. А именно, мы видим что пользователь сделал переход на наш сайт с естественной выдачи сайта в поисковой системе Yandex, после чего два раза заходил на сайт вручную вводив его название в адресной строке браузера, НО конверсия была совершена после телефонного звонка!

Рис.1.4. – реальный путь к кноверсии

До изменений, по отслеживанию офлайн продаж, эта цепочка событий не попала бы в наш отчет. Пользователя мы потеряли бы на втором звене нашей цепочки, а канал «yandex / organic» считали бы не эффективным.

Но на этом еще не все! Наверняка интересно, а какой запрос способствовал первому попаданию пользователя на сайт?

И на этот вопрос можно получить ответ рис.1.5.:

Рис.1.5. – ключевой запрос для CID по каналу

Используйте данный функционал для сбора достоверных данных и оптимизации вашего бизнеса!