HackForData #3 — команда-победитель Super Magic Data

Участники команды:

• Рыжков Максим
• Семикин Артур
• Лосев Сергей
• Бродский Илья

Команда создала целых четыре BI-системы. Далее участники подробно рассказывают о каждой из них.

Автор: Илья Бродский

Целевая аудитория:

• Интернет-маркетологи
• Веб-аналитики
• Руководство

Основная задача аналитики бизнеса — найти причины роста или падения ключевых бизнес-показателей, найти точки роста, улучшить то, что работает плохо и усилить существующие сильные стороны.
В данной работе мы анализируем интернет-магазин с настроенной электронной коммерцией Яндекс.Метрики.

В работе использовались обычный API Яндекс.Метрики и Logs API Яндекс.Метрики.

Проблематика

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

Решение

В первую очередь, был проведен анализ простейших показателей:

• Мы посмотрели на зависимость доходов и посещений по месяцам, доходу и конверсиям в покупки по месяцам; выявили, что, несмотря на падение посещаемости, у нас почему-то росла конверсия, а вместе с ней и количество покупок и, как следствие, доход.
• Посмотрели распределение трафика по источникам в зависимости от месяца, увидели интересное изменение поисковой и e-mail рекламы.
• Посмотрели на распределение покупок по городам в зависимости от размера города.

Далее интереснее. Подключившись к Logs API (спасибо команде Яндекс.Метрики за помощь и консультацию в 3 часа ночи, кстати впервые в жизни видел, как разработчик по своей воле работает в ночь с пятницы на субботу), обойдя некоторые трудности, связанные с особенностью хранения сырых данных (да-да, не все так просто, если пользователь в одну сессию сделал несколько транзакций на разные суммы, а таких примеров в любом интернет-магазине куча), сделали следующие вещи:

Небольшое лирическое отступление или что же такое Logs API и почему это вроде как круто
Работая в любой из двух всем известных систем аналитики, мы сталкиваемся с агрегированными данными (несколько измерений (dimensions) — несколько столбцов (метрик) — и вперед анализировать!), но в этом случае за нас, как за аналитиков, уже многое решили не спросив, а именно:
– за нас выбрали модель атрибуции;
– за нас посчитали показатели (а, может быть, мы хотели другие?);
– за нас построили уже отчеты, думая, что нам так будет удобнее;
– нам не дали возможность связать данные с другими системами (это, конечно, лукавство в какой-то степени, никто этого запрещать не будет, но как, простите, качественно связать данные из CRM с агрегированными данными из системы веб аналитики?);
– ну, или если созданный отчет устраивает вас полностью, но вы боитесь слова "сэмплинг" или слова "погрешность", то Logs API создан именно для вас.
Для этого Яндекс.Метрика дала возможность выгрузить сырые данные — гигантская таблица, где каждая сессия в отдельной строке или каждый хит в отдельной строке, для совсем извращенцев (зачеркнуто) профессиональных аналитиков.

Итак, продолжим: взломав (зачеркнуто) приконнектившись к Logs API, мы сделали следующее:

• Отчет по цепочкам конверсий (аналог отчета в Google Analytics, который очень любят менеджеры по интернет-рекламе, говоря, что он расширяет сознание (зачеркнуто) понимание об источниках трафика, приносящих конверсии). В него добавили не только цепочки, по которым были транзакции, но еще и цепочки, по которым транзакций не было, и посчитали конверсии по ним. Удивительно, что некоторые цепочки с 50-60 % вероятностью конвертируют в транзакцию;
  
  
• Когортный анализ. Сделан полностью на DAX. Интересно видеть зависимость молодости когорты от принесенных денег в первые и последующие месяцы;
  

Автор: Максим Рыжков

Целевая аудитория:

• Руководство
• Инвесторы
• Интернет-маркетологи

У каждого бизнеса должна быть своя "Лакмусовая бумажка" — дашборд/ инфопанель, бросив один взгляд на которую можно понять, все ли в порядке или на что-то нужно обратить внимание.
Данный дашборд выполняет именно такую задачу — оперативно показывать основные метрики юнит-экономики в разрезе по товарным категориям и источникам трафика.

Пример системы в облаке

Оперативный дашборд, в котором мы можем фильтровать данные по дате (1), выбирать определенные товарные категории (3) и видеть изменение доли категорий в выбранном временном промежутке(4).
В основной таблице (2) два уровня метрик:

1-ый уровень — конверсионный.
Видим воронку и конверсию шага: количество пользователей, просмотревших товар, количество пользователей, добавивших товар в корзину, количество пользователей совершивших покупку.
CV1 — конверсия из Просмотра товара в Добавление его в корзину;
CV2 — конверсия из корзины в покупку.

2-ой уровень — уровень сессий и метрик по пользователю.
AOV — средний чек категории;
RPV — выручка на каждое посещение;
ARPU — сколько в среднем мы зарабатываем с каждого уникального посетителя;
ARPPU — сколько в среднем нам приносить каждый платящий.

Просто поменяв измерения на входе, мы можем получать другой отчет. Например, по источникам трафика, по товарам, по utm-меткам.

Автор: Сергей Лосев

Целевая аудитория:

• Интернет-маркетологи
• Специалисты по контекстной рекламе
• Веб-аналитики

Как правило, в разные дни недели на сайт заходят люди с разной степенью заинтересованности в покупке. Для одних сайтов конверсия может быть выше в начале недели, для других — в середине, для третьих — в конце. Если основной источник трафика у вас платный, то есть смысл повышать ставку в более конверсионные дни и понижать, когда конверсия низкая (ибо зачем переплачивать за слабомотивированную аудиторию?). Но как понять, в какие дни повышать, а в какие понижать? И на сколько? Ведь у каждого бизнеса своя аудитория, и у каждой из них свой паттерн поведения.

Пример

Скажем, в понедельник только начинается рабочая неделя, и решение о покупке можно немного отложить. Ближе к среде человек начинает задумываться, что пора бы, наконец, сделать заказ, чтобы до конца недели покупку успели доставить, и делает заказ. Другой же всё тянет-тянет и понимает, что вот уже пятница наступила, всё равно ни сегодня, ни в выходные ничего не привезут, и откладывает покупку до воскресенья, когда можно в спокойной обстановке принять взвешенное решение. И совершенно по-другому может складываться ситуация для других сайтов — для их аудиторий может быть важно совершить покупку в самом начале недели. Или в середине. Или в конце.

Решение

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

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

В таком случае воспользуемся не количеством конверсий, а количеством безотказных страниц (или количеством НЕ отказов) — т.е. разницей между количеством визитов и количеством отказов. Тогда визитов без отказов будет намного больше, что сузит confidence interval и позволит принять более правильное решение.

И хотя изменения корректировок ставок будут минимальными (единицы процентов), решение будет более обоснованным. Таким образом, если решение принимается по конверсиям, корректировки по дням недели будут выглядеть так:

Т.е. в ПН ставку необходимо повысить на +14%, во ВТ понизить на -6% и т.д. Если же данных по конверсиям недостаточно для принятия решения, используем корректировки, рассчитанные по отказам:

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

Аналогичным образом считаются корректировки ставок для аудиторий различного пола и групп возраста — запрос к API делается не с группировкой по дням недели, а с группировкой по полу (ym:s:gender) или возрастному интервалу (ym:s:ageInterval). Причем, это можно сделать грубо на уровне кампаний, а также более точно — на уровне групп объявлений. Понятное дело, что ручная корректировка ставок нужна лишь для быстрой оценки ситуации и оперативного внесения изменений в наиболее затратные кампании, т.к. это не потребует привлечения разработчиков. В долгосрочной же перспективе необходимо подключать программистов, которые, основываясь на изложенных выше примерах, разработают скрипт, который будет регулярно получать данные из Метрики и вносить изменения для всех кампаний и групп объявлений.

Пример системы в облаке

Автор: Артур Семикин

Целевая аудитория:

• Интернет-маркетологи
• Специалисты по контекстной рекламе
• И другие неравнодушные к дополнительной прибыли бизнеса=)

Клиенты часто задаются вопросом — стоит ли подключать контекстную рекламу по собственным брендовым запросам? Универсального ответа нет, но есть универсальный тест. Он поможет понять, как поступать конкретно в вашем случае. Это тест по каннибализации трафика, на выходе которого вычисляется значение ITR (incremental traffic ratio). Это доля добавленных сеансов, которую принес контекст.

Например, если ITR=80%, это означает, что брендовый контекст «съел» у SEO всего 20% трафика, а 80% кликов были новыми, дополнительными. А значит, в казну посыпалось новое, дополнительное золото=)

Для проведения теста необходимо собрать брендовую рекламную кампанию в Яндекс.Директе, в настройках кампании выставить временной таргетинг приемом «Шашечки»:

Далее необходимо собрать статистику по «Визитам» в Яндекс.Метрике отдельно по часам с включенным и выключенным контекстом.

И здесь начинается самая долгая и муторная работа. Выделять эти данные вручную — худшее, что может произойти за вашу карьеру аналитика. Я знаю, о чем говорю, сам так жестил. До тех пор, пока наша хакатон-команда не сказала "Хватит это терпеть!".

Мы решили автоматизировать сбор статистики, расчет результатов и статистической достоверности при помощи Microsoft Power BI.
Всю работу можно было разбить на 3 этапа:

1. Подключение к API Яндекс.Метрики и выгрузка "сырых данных";
2. Обработка полученных данных на стороне PowerQuery;
3. Расчет результатов и статистической достоверности на стороне DAX.

1. Подключение к API Яндекс.Метрики и выгрузка "сырых данных"

На первом этапе мы воспользовались 2-мя коннекторами к API Метрики, написанными Сергеем Лосевым (знай наших!) и Максом Уваровым. Первый коннектор помог с выгрузкой статистики по визитам с органической выдачи Яндекс по брендовым запросам клиента:

В коннекторе к органическому трафику есть статические параметры: dimensions, metrics, limit, а также фильтр на searchEngineRoot=='yandex'.
Динамические параметры подставляются в каждом вашем случае индивидуально:

1 – Номер счетчика 2 – Даты начала и окончания теста 3 – Фильтр ym:s:searchPhrase=@ , в котором вы указываете ваши брендовые запросы (или корни, их образующие). Например, ym:s:searchPhrase=@'Эльдорад'

Коннектор к трафику Яндекс.Директ вызывается через функцию PQYM, динамическими являются параметры:

2 – Номер счетчика
3 – Даты начала и окончания теста
4 – ClinetID Яндекс.Директа

ВАЖНО: на скриншоте вы можете видеть, что за трафик с Яндекс.Директ здесь принимаются клики, а не визиты, как это было в случае с органикой. Что не совсем корректно. Но в нашем случае это — вынужденная мера, вызванная тех. проблемами на стороне счетчика клиента (даже Юра был бессилен(= ). Я верю, что вам судьба уготовила счетчики без таких провалов в данных, и вы сможете в поле metrics вызвать не ym:ad:clicks, а ym:ad:visits.

2. Обработка полученных данных на стороне PowerQuery

На этапе обработки запросов мы путем несложных махинаций получаем колонку ContextCondition, которая говорит о том, была ли включена или выключена контекстная реклама в данный час данного дня (помните про принцип шашечек, на котором базируется этот тест?)

Далее мы, ссылаясь на запрос Brand_organic, разбиваем его на 2 таблицы. В первой содержатся агрегированные по дням данные о часах с включенным контекстом, во второй — с выключенным.

Статистика о трафике с Яндекс.Директ приводится к тому же виду, что и "органическая".

3. Расчет результатов и статистической достоверности на стороне DAX

Связав через List.Dstes таблицы Brand_organic_c_off, Brand_organic_c_on и Brand_context получаем панорамную статистику текущего теста:

Искомое значение IRT вычисляется по формуле:

IRT = Добавленные визиты / Визиты с контекста, где

Добавленные визиты = Визиты с контекста + Визиты с органики в часы с включенным контекстом

Таким образом, для расчета ITR нам нужны промежуточные вычисляемые метрики.

Ну что ж, все необходимые данные есть, супер, огонь, давайте считать ITR:

Победа — полученный ITR составил 43% при критическом значении 3% (т.е. с 40% "запасом").

Критическое значение — это точка, в которой мы "выходим в 0". Ведь брендовые клики пусть и дешевые, но не бесплатные.

minITR рассчитывается индивидуально для каждого клиента из системы уравнений:

бренд CPC * X = Z доход с 1 бренд клика * X * minITR = Z, где

X — количество кликов с бренд-РК;
Z — доход с бренд-РК.

Полученный ITR=43% — число крайне чудесное и позитивное. Оно говорит о том, что при подключении брендового контекста на данном клиенте 43% контекст-кликов являются новыми, добавленным. Что, в свою очередь, означает новую, добавленную прибыль! Осталось проверить статистическую значимость нашего теста. Ведь золотые мешки нашего бренд-трафика на деле могут оказаться всего лишь черными пакетами погрешности и слез (а какие метафоры начинаете использовать вы на 25-ый час без сна?=))

Для проверки рассчитаем доверительный интервал по формуле:

confidence interval = X +- (1,96 * Standard Deviation/(n^0,5)), где

X — матожидание,
Standard Deviation — стандартное отклонение (сигма),
n — размер выборки.

Для реализации заводим все необходимые вычисляемые метрики:

На всякий случай, держите DAX-формулы:

AVERAGE() — матожидание;
COUNT() — размер выборки;
STDEV.P() — стандартное отклонение.

Рассчитали. CI = 37% – 46%. Окончательно выдохнули — даже если ориентироваться по нижней границе ДИ, "запас" относительно критического ITR составляет 34%.

Вот и все. Скачивайте, пользуйтесь. Заводите свои тесты, подставляйте свои параметры. Получайте значения ITR и дополнительные деньги. Любите жизнь и надевайте зимой вторые штаны=) Если мы выкатим какой-нибудь апдейт (в планах — проще и элегантнее реализовать 2-ой этап с обработкой запросов) — обязательно поделимся в группе про Power BI и Excel.