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-тестов.
• Возможность оценки влияния любого нововведения на результат.