Коллтрекинг и аллитерирующиеся продажи

Изучаем коллтрекинг

Мы очень любим передовые технологии. Скоро год, как мы познакомились с коллтрекингом (call tracking). Это такая технология, которая показывает каждому посетителю на сайте уникальный номер рекламного телефона и привязывает этого посетителя к рекламной кампании. Таким образом, к тривиальному для нас и для вас (поскольку этот опыт уже описывался в статьях о подключении Google Analytics и Яндекс.Метрики к QlikView) анализу добавляется факт телефонного контакта с клиентом (не только входящего, но и исходящего, ибо в продвинутых системах коллтрекинга имеется возможность заказа обратного звонка).

На самом деле эта технология появились еще в прошлом веке. Кооператор давал объявление в газету «Из рук в руки», указывая телефон тещи, а в газету «Все для вас» свой, а потом смотрел, кто продал больше. Уже тогда он мониторил эффективность вложений в рекламу.

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

  • 20% клиентов покупают раз в неделю,
  • 50% клиентов покупают в течении месяца,
  • 90% в течении квартала.

Возникает идея растянуть воронку продаж на вторые, третьи и т.п. сделки, подтянув всю историю продаж. Таким образом, можно решать задачу нахождения глобального максимума прибыли в вопросе выбора рекламной кампании, а не поиска локального экстремума в конверсии до 1-й покупки. Кстати, факт нажатия кнопки «купить» не гарантирует продажу, а тем более оплату.

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

Тренируемся

Дано:

  • Есть поставщик, которая предоставляет услуги коллтрекинга. Дабы не считать этот пост рекламой, называть его не буду, а интересующиеся могут подсмотреть его домен в строках подключения.
  • Есть история звонков, переплетенная с рекламными кампаниями. Более того, на сайте поставщика прекрасно описан REST API (https://ru.wikipedia.org/wiki/REST), позволяющий забирать интересующие нас данные.

Тестируем подключение:

Пробуем подключиться к ним из QlikView по http. Ан нет, не получается. Сервер возвращает ошибку «111406 Not acceptable». Расследование показало, что QlikView (11.20SR11, а также QlikSense 2.01) не заполняет параметр Accept в GET запросе. Отдающий сервер не может самостоятельно принять ответственное решение о выборе формата, и вместо того, чтобы выполнить свою работу в формате по умолчанию,  бодро рапортует об ошибке. Кого-то мне это напоминает… Печалька.

Покупать прекрасный продукт QVSource Коннектор, где этой проблемы нет, который поддерживает json, умеет работать с Эдвардз и Google Analytics, подключается к социальным сетям, варит кофе, не позволяет бюджет.  

Диагностируем:

Для диагностики используем утилиту curl. С ней API REST прекрасно взаимодействует и отдает нужные нам данные.

Ошибка возникает только в последних командах при запросе данных в HTML и в «пустом» формате.

Вот пример получения данных из QlikView с помощью wget

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

Реализуем 

В REST API появилась недокументированный (?) параметр запроса accept, в который мы и запихнем непередаваемые QlikView данные для запроса. В нашем случае это accept=application/xml

Что значит: хотим получить данные в формате XML. Json экономнее, но QlikView пока с ним не дружит.

Новый код, без использования внешних утилит:

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

Рефлексируем

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

Требуйте отстоя пены!

Не всегда с первого раза удается привычными инструментами добиться результата. В описанном случае и данные: вот они, да не уцепишь. Вроде и подсекли, а рыбка-то сорвалась, кто же даст права на исполнение безокошечного wget на сервере?!

Пробуйте!

В процессе коммуникации с поставщиком данных самым сложным было объяснить, что это не его ошибка, ибо он сразу выставлял несколько линий техподдержки для обороны. И можно было бы сослаться на RFC, но ради результата пришлось закусить удила.

Закусывайте!

Для полноценной интеграции пришлось пообщаться на стороне поставщика и с поддержкой, и с продавцами, и с директором по маркетингу, и даже с генеральным директором. Нами было предложено несколько направлений решения этой задачи, в ходе обсуждения поставщик сам выбрал наиболее приемлемое со своей стороны: изменение API REST.

Общайтесь! 

Как обычно, исходники на GitHub

А чему вас научило последнее разработанное вами приложение QlikView?

B3

.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Подпишись на Data-Daily!

Введите email и будьте в курсе!

Подпишись!