31 Марта 2015 в 00:10

Go Analytics! 2015: Практика передачи данных о реальных продажах через Measurement Protocol

1 7352

На прошедшей 19 марта конференции Go Analytics со-основатель Onlinetours Константин Победкин представил доклад «Практика передачи данных о реальных продажах через Measurement Protocol».

Свое выступление Константин начал с того, что представил схему работы системы аналитики Onlinetours:

1.JPG

Она предоставляет полную историю взаимодействия клиента с сайтом, дает подробную картинку продаж в разных разрезах (поведение/источники рекламы/продуктовые характеристики) и полную картину по эффективности продуктов (в зависимости от страны/отеля/поставщика и пр.).

При разработке системы аналитики команда ставила перед собой следующую цель — получить полную и актуальную информацию по продажам в Universal Analytics, а именно:

  • Количество заказов и сумму денег, которая была реально заработана.
  • Полная история взаимодействия пользователя с сайтом до момента покупки.

Изначально была сделана попытка передавать информацию о покупке по факту загрузки thank you page, но возникли некоторые сложности:

  • Ввод данных карты производится на странице банка, поэтому пользователи не всегда возвращаются на сайт. И, следовательно, thank you page не всегда появляется.
  • Заказ можно оплачивать частями. Это вызывает несколько загрузок thank you page для одного заказа.
  • Оставался вопрос с оплатой курьеру или в офисе. Заказ мог быть не оплачен.

Следующим шагом на пути решения проблемы сбора аналитики стала работа с Measurement Protocol.

2.png

По сравнению с предыдущим вариантом здесь было несколько очевидных плюсов:

  • Информация о транзакции отправляется по факту поступления оплаты с CRM.
  • Нет проблем с офлайн-способами оплаты, потому что факт оплаты фиксируется в CRM, а уже после этого происходит отражение транзакции в Google Analytics.
  • Транзакция проводит в Google Analytics один раз вне зависимости от того, сколько по ней было сделано платежей.

Однако при анализе первых результатов были обнаружены некоторые несостыковки в отчетах. Например, более 70% было совершено новыми пользователями в первой сессии. И это странно, потому что выбор тура — сложный процесс, обычно занимающий несколько дней. Большая часть покупок была привязана к нескольким уникальным gacid. И снова вопрос: зачем клиенту покупать несколько туров в неделю?

В итоге были выявлены следующие типовые ошибки:

  • gacid/userID не передается в CRM.
  • Передается gacid/userID не того пользователя, который совершает транзакцию.
  • Неправильно выбран момент передачи gacid/userID в CRM.

Для решения этих проблем была настроена передача возвратов GA через Measurement Protocol (при возврате проводится новая транзакция с отрицательной суммой и количеством заказов с теми же свойствами, что и основная транзакция). Также была подключена система колл-трекинга, которая по звонку может отдавать gacid в CRM. Это позволяет получить всю историю взаимодействия пользователя с сайтом по заказам, оформленным со звонка.

Бизнесу эта дает:

  • Точное понимание эффективности рекламных кампаний.
  • Возможность отслеживания различных показателей эффективности по многим каналам.
  • Более полное понимание пользователей.
  • Возможность проведения правильных A/B-тестов.
  • Возможность оценки влияния любого нововведения на результат.

1 комментарий
Подписаться 
Подписаться на дискуссию:
E-mail:
ОК
Вы подписаны на комментарии
Ошибка. Пожалуйста, попробуйте ещё раз.
Поделиться 
Поделиться дискуссией:
  • Сергей
    больше года назад
    Это всё хорошо.
    А как быть если пользователь заказал товар через интернет-магазин, данные отправляются в CRM, а следом в GA. Менеджер связался с ним. И пользователь просит добавить в заказ ещё один товар или изменить заказ, естественно сумма транзакции в CRM обновляется и передаётся в GA. Но при передачи в GA транзакции она плюсует предыдущую сумму.
    -
    0
    +
    Ответить
    Поделиться

Отправьте отзыв!
X | Закрыть