Go Analytics! 2015: Практика передачи данных о реальных продажах через Measurement Protocol
На прошедшей 19 марта конференции Go Analytics со-основатель Onlinetours Константин Победкин представил доклад «Практика передачи данных о реальных продажах через Measurement Protocol».
Свое выступление Константин начал с того, что представил схему работы системы аналитики Onlinetours:
Она предоставляет полную историю взаимодействия клиента с сайтом, дает подробную картинку продаж в разных разрезах (поведение/источники рекламы/продуктовые характеристики) и полную картину по эффективности продуктов (в зависимости от страны/отеля/поставщика и пр.).
При разработке системы аналитики команда ставила перед собой следующую цель — получить полную и актуальную информацию по продажам в Universal Analytics, а именно:
- Количество заказов и сумму денег, которая была реально заработана.
- Полная история взаимодействия пользователя с сайтом до момента покупки.
Изначально была сделана попытка передавать информацию о покупке по факту загрузки thank you page, но возникли некоторые сложности:
- Ввод данных карты производится на странице банка, поэтому пользователи не всегда возвращаются на сайт. И, следовательно, thank you page не всегда появляется.
- Заказ можно оплачивать частями. Это вызывает несколько загрузок thank you page для одного заказа.
- Оставался вопрос с оплатой курьеру или в офисе. Заказ мог быть не оплачен.
Следующим шагом на пути решения проблемы сбора аналитики стала работа с Measurement Protocol.
По сравнению с предыдущим вариантом здесь было несколько очевидных плюсов:
- Информация о транзакции отправляется по факту поступления оплаты с CRM.
- Нет проблем с офлайн-способами оплаты, потому что факт оплаты фиксируется в CRM, а уже после этого происходит отражение транзакции в Google Analytics.
- Транзакция проводит в Google Analytics один раз вне зависимости от того, сколько по ней было сделано платежей.
Однако при анализе первых результатов были обнаружены некоторые несостыковки в отчетах. Например, более 70% было совершено новыми пользователями в первой сессии. И это странно, потому что выбор тура — сложный процесс, обычно занимающий несколько дней. Большая часть покупок была привязана к нескольким уникальным gacid. И снова вопрос: зачем клиенту покупать несколько туров в неделю?
В итоге были выявлены следующие типовые ошибки:
- gacid/userID не передается в CRM.
- Передается gacid/userID не того пользователя, который совершает транзакцию.
- Неправильно выбран момент передачи gacid/userID в CRM.
Для решения этих проблем была настроена передача возвратов GA через Measurement Protocol (при возврате проводится новая транзакция с отрицательной суммой и количеством заказов с теми же свойствами, что и основная транзакция). Также была подключена система колл-трекинга, которая по звонку может отдавать gacid в CRM. Это позволяет получить всю историю взаимодействия пользователя с сайтом по заказам, оформленным со звонка.
Бизнесу эта дает:
- Точное понимание эффективности рекламных кампаний.
- Возможность отслеживания различных показателей эффективности по многим каналам.
- Более полное понимание пользователей.
- Возможность проведения правильных A/B-тестов.
- Возможность оценки влияния любого нововведения на результат.
![]() ![]() ![]() |
Друзья, теперь вы можете поддержать SEOnews https://pay.cloudtips.ru/p/8828f772 Ваши донаты помогут нам развивать издание и дальше радовать вас полезным контентом. |
![]() ![]() ![]() |
Случилось что-то важное? Поделитесь новостью с редакцией.
-
Это всё хорошо.
А как быть если пользователь заказал товар через интернет-магазин, данные отправляются в CRM, а следом в GA. Менеджер связался с ним. И пользователь просит добавить в заказ ещё один товар или изменить заказ, естественно сумма транзакции в CRM обновляется и передаётся в GA. Но при передачи в GA транзакции она плюсует предыдущую сумму.































