15 апреля 2015 года в Киеве прошла третья ежегодная конференция по аналитике Analyze! 2015. Мероприятие было призвано помочь специалистам отрасли осознанно влиять на эффективность проекта путем изменений на сайте и с помощью аналитики зарабатывать больше. Докладчики рассказывали о том, как с помощью инструментов аналитики хорошие проекты становятся успешными.
В программе конференции прозвучал доклад Романа Рыбальченко - основателя проекта Roma.net.ua, директора по маркетингу интернет-магазина Intimo, сооснователя Клуба интернет-маркетологов. Свое выступление Роман посвятил аналитике вне Google Analytics на основе баз данных.
С точки зрения специалиста, не все можно и нужно анализировать в сервисе Google Analytics. Существуют базы данных, которые гораздо полнее и интереснее.
Основные проблемы внутри GA случаются, когда что-то не успели внедрить, мало данных, что-то внедрили не корректно, когда мешают лимиты и семплирование или не получается построить отчет. Бывает, что Dimensions «не дружит» с Metrics. Кроме того, когда возникает какая-то идея, на нее невозможно быстро получить ответ. Enhanced Еcommerce – хорошая вещь, но он внедряется несколько месяцев. Пока программисты учатся правильно настраивать UserID, ClientID, проходит много времени. То же касается Measurement Protocol. Кроме того, многие сталкивались с такой проблемой, когда данные были собраны с ошибками. И в GA, к сожалению, нет кнопки ctrl + z. Если данные собраны неправильно, пересчитать их нет возможности. Все это приводит к внешним источникам данных:
- базам данных о товарах, заказах и клиентах (CMS, ERP, CRM),
- рекламным аккаунтам (Google Adwords, Яндекс.Директ),
- статистике сервиса (MailChimp, Youtube, Google Webmaster, Яндекс.Вебмастер),
- веб-аналитике (Google Analytics, Яндекс.Метрика).
Сначала эти данные нужно очистить, так как не все они пригодны к обработке. Следует отфильтровать:
- ненужные сегменты (например, опт или розница),
- телефонные заказы, проведенные сотрудниками через свой аккаунт, и тестовые (обычно в них e-mail содержит домен сайта; также следует проверить топ-100 клиентов по количеству заказов, так как в него зачастую попадают технические аккаунты),
- статусы заказов (отмененные и незавершенные),
- период времени.
Самый простой пример: программист настраивает в базе данных поле, в которое полгода по умолчанию записывается единица вместо нуля, обозначающая какой-то статус отмены. Соответственно, при получении «сырых данных» их нужно просмотреть. Это нельзя автоматизировать, а значит, придется делать вручную. На выходе получатся данные, которые можно представить в виде пересечения кругов:
Теперь можно начинать работу с этими данными.
Обычно данные выгружаются в Excel, где следует применить автофильтр и очистить данные, исключив неправильные, пустые ячейки и «жирафов». Роман Рыбальченко рассказал, что средний рост животных в Африке вместе с жирафами составляет около 2 метров, а без них – всего полтора. В данном контексте «жирафы» - очень нетипичные потребители, данные по которым могут сильно исказить картину при анализе. Это могут быть сотрудники исследуемой компании, оптовые клиенты или посредники. После такой ручной проработки данных стоит поставить задачу программисту о такой же автоматической очистке, чтобы не тратить на это время постоянно.
Что можно сделать, чтобы «сырые» данные собирались более корректно:
- валидация на входе (пользователю представляется поле «телефон», в которое вводятся только цифры, причем начальные +380 уже введены),
- внести признак «сотрудник» в базу данных,
- завести «тестовую» причину отмены заказа (для программистов и внутренних тестов),
- продумать «склейку» профилей по номеру телефона, адресу доставки, ФИО, чтобы отличать, например, 5 заказов от одного клиента или от разных,
- внесенные вручную исправления следует импортировать в базу данных,
- ввести в процесс обработку новых ошибок коллегами.
Следующий шаг – обогащение данных:
- самый простой и быстрый способ - в GA выгрузить номера заказов и их источники в свою систему, где уже известно, выполнен ли заказ, и какую прибыль он принес (ключ – номер заказа в e-commerce);
- IP даст информацию о городе, регионе, стране (по базе GeoIP);
- имя и отчество – пол;
- адрес – расстояние (по API карт);
- товары в заказе, если речь идет об одежде, – размер человека;
- соцсеть – интересы, чекины, друзья;
- школа и друзья – возраст;
- товар – характеристики, отзывы (по API Яндекс.Маркета).
В качествен примера Роман Рыбальченко привел российский сервис dadata.ru, который исправляет ошибки и опечатки в контактных данных пользователя, а также определяет его пол, к номеру телефона подтягиваются данные о часовом поясе, в некоторых случаях с помощью использования стороннего ресурса можно узнать даже метраж квартиры пользователя. Этот сервис можно использовать специалистам по email-маркетингу для определения пола пользователей.
Правда, этот сервис не работает с украинскими именами, их следует обработать вручную. Существуют также аналоги этого сервиса: iqdq.ru, iqsystems.ru, kladr-api.ru. Особо отличился обогащением данных украинский сервис Лун.ua: он показывает, сколько рядом с заданным домом школ, магазинов, аптек, зеленых зон, промышленных предприятий и так далее, формируя с помощью этих данных рейтинг дома. Таким образом можно изучать комфортность жилья перед его съемом. Существуют аналогичные сервисы, подтягивающие информацию из Foursquare и отображающие близлежащие кафе, рестораны и т.д.
Следующий этап – доработка структуры базы данных. Чем дальше, тем больше аналитика перемещается в базу данных:
- разнесение полей: поле ФИО делится на три отдельных - для фамилии, имени и отчества,
- отдельные поля для разнообразных параметров,
- организация структурированного ввода данных,
- связь по API с другими сервисами типа Яндекс.Карты.
После доработки понадобится следующий инвентарь:
- доступ к SQL базе данных или ее копии с правами только на чтение,
- простой трехчасовой курс по SQL for marketers,
- Excel и 4-7 ГБ оперативной памяти на ноутбуке или в облаке Microsoft Azure,
- надстройки: Power Pivot, Power Query.
После теоретической части своего доклада Роман Рыбальченко рассказал, какие задачи ему приходилось решать, используя вышеизложенные технологии.
Кейс 0. Анализ базы данных, использование когорт и Life Cycle Grid (LCG). Процесс был сложный, так как в базе данных клиента было 170 тысяч строк. Потребовалось настроить виртуальную машину для быстрой обработки этих данных и настроить экспорт, что заняло значительное количество времени.
Какие поля нужны, чтобы построить когортный анализ?
- номер заказа;
- Id клиента или его e-mail;
- дата заказа;
- статус заказа;
- сумма заказа;
- порядковый номер заказа данного клиента;
- источник заказа.
Также понадобились дополнительные вычисляемые поля, которые можно получить с помощью программистов:
- количество заказов;
- количество выполненных заказов;
- дата первого и второго заказа;
- количество дней между первым и вторым заказом;
- год и месяц текущего заказа;
- год и месяц первого заказа,
- количество месяцев и дней с момента первого заказа.
Получив такие данные в виде файла Excel или таблицы csv, можно приступать к когортному анализу и построить LCG, а также структуру по месяцам и статусам и исполняемость заказов в разрезах (например, в зависимости от региона).
Данные помогли определить:
- Точки для роста количества пользователей, сделавших заказ. Ими являются пользователи, посетившие сайт, но не осуществившие покупку, а также заказчики, совершившие всего одну покупку.
- Диапазоны для e-mail-маркетинга для определения периодичности рассылки разного рода писем: между покупкой и оплатой, между заказами, между покупкой и отменой. Например, так можно рассчитать момент, когда стоит предложить клиенту ссылку, чтобы повторно вовлечь его в покупки.
- Проблемы с наличием товара в регионах и актуальностью.
- Проверили бизнес-модель по оттоку клиентов.
- Вероятность повторной покупки в зависимости от количества уже совершенных заказов.
Кейс 1. Анализ прибыли по источнику в CRM. Программист написал скрипт, который, аналогично старой версии GA, при заходе пользователя на сайт вешает его в cookies и записывает все параметры, использованные в пометке ссылок:
Дальше эта информация собирается в базу и создается соответствующий скрипт на извлечение данных:
Скрипты создаются с применением теории комбинаторики. Информация хранится в табличном виде, откуда ее можно экспортировать в Excel и анализировать.
Следует сохранять данные об источнике заказа и источнике регистрации, это поможет проанализировать прибыль по источникам.
Потом отчет получил удобную форму с возможностью выбора нужных параметров:
На выходе получается информативная удобная таблица, с помощью которой можно подсчитать реальную рентабельность инвестиций в рекламу:
В таком процессе много ручных операций, но это можно сделать быстро и, как следствие, оперативно принимать важные для бизнеса решения: оптимизировать рекламные источники по прибыли.
Кейс 2. Реанимация ремаркетингом в социальных сетях. Специалисты по e-mail маркетингу часто сталкиваются с тем, что клиенты отписываются от рассылок и их больше нельзя потревожить. Есть определенное количество людей, которые оформляли заказ по телефону, не оставляя свой адрес электронной почты. Кроме того, в базе пользователей есть слабый сегмент, который ничего не покупал в течение полугода-года. Чтобы снова вовлечь их, специалисты экспортировали из MailChimp данные об отписавшихся пользователях, а также обратили внимание на тех, кто не оформлял заказы более Х дней или оформил заказы по телефону. Эту информацию можно легко получить с помощью несложного запроса:
Далее специалисты выгрузили эти телефоны в Facebook и Вконтакте и запустили по ним ремаркетинг, показывая пользователям соответствующие объявления. В результате такого простого запроса средняя стоимость заказа составила 96 грн, а конверсия оказалась в 2,5 раза выше, чем в среднем по сайту. Простые курсы SQL for marketers помогут научиться быстро создавать такие запросы и обходиться без помощи программистов.
Кейс 3 Роман Рыбальченко посвятил анализу отмен заказов в разрезах. Докладчик настоятельно рекомендует завести в базе данных возможность фиксировать причины отмены заказов.
В данной ситуации выгрузка данных в Excel и анализ потребовали более сложного запроса:
В результате анализа удалось сделать следующие выводы:
- В регионе Х у отмененных заказов средний чек выше на 24%, что означает потерю больших заказов.
- В регионе Х в 2 раза чаще отмена по причине «нет в наличии». Ситуация требует работы с остатками и сайтом.
- Менеджер N в полтора раза чаще прочих отменяет заказы по причине «не дозвонился». В такой ситуации следует провести соответствующую работу с персоналом.
Кейс 4. Анализ баз данных также может помочь определить, на каких позициях выгодно крутить контекстную рекламу. Для этого нужно создать каноническую таблицу в Excel (убрать итоги, вписать заголовки), выгрузить данные из AdWords и построить сводные таблицы. В таблице понадобятся вычисляемые поля, дополнительные вычисления, фильтры и представление данных. Таблица покажет стоимость оформленного заказа в зависимости от того, на какой позиции крутилось объявление.
На первый взгляд кажется, что стоит находиться на первой позиции, так как стоимость оформленного заказа – 20 долларов. Но если отфильтровать из таблицы данные по брендовой кампании, когда бизнес рекламировался по названию, то получится, что лучше крутиться на 2-3 позиции.
Дальше эти данные можно смотреть в разрезах и делать соответствующие выводы.
Роман рассказал, что нельзя выгружать bounce rate, следует использовать количество bounce. Для полей, которые вычисляются как «что-то поделить на что-то», нужно выгружать «сырые данные» и делить уже их. Подсчет среднего CTR таким образом некорректен: если по одному ключевому слову этот показатель составляет 5%, а по второму – 25%, то средний CTR не будет равен 15%, так как по этим ключевым словам могло быть разное количество показов.
Кейс 5. Какая форма подписки на сайте дает больше покупателей? На сайте в разных местах были созданы несколько разных форм подписки. Данные по ним обирались в MailChimp, а затем анализировались. Выяснилось, что одна форма подписки дала 1800 подписчиков и 456 заказов. Другая форма - 850 подписчиков и 350 заказов. Эта форма менее агрессивная и дает меньше подписчиков, но количество заказов сопоставимо с данными другой формы.
Когда еще нужны сводные таблицы?
- При сегментации по полу, возрасту и интересам в КМС,
- При выборе оптимального типа соответствия,
- При исследовании влияния дополнительных слов в запросе (купить, обзор, Киев, магазин),
- При группировке по категориям, когда компании разбиты регионально.
Примеры применения SQL-запросов и сводных таблиц:
- Выгрузка специалистам поисковой оптимизации брендов с большим количеством SKU в наличии.
- Анализ ширины экрана для определения требований к мобильной версии.
- Анализ длины названия городов для доработки дизайна.
В заключение своего доклада Роман Рыбальченко предложил слушателям список полезных ссылок и сервисов:
- https://import.io/
- http://webscraper.ua/
- http://words.co/
- http://laborare.info/all/notepad-ppc/ (win)
- CSV Converter (mac)
- Google Refine.