Русский
Русский
English
Статистика
Реклама

Аналитика данных

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

24.03.2021 12:04:07 | Автор: admin
image

Возможно, прочитав эту статью, вы поймаете себе на мысли, что я пишу о банальных вещах, которые всем известны. Но за 10 лет я сменила всего лишь 3 IT-компании, в двух из которых эти банальные практики не использовались в полной мере, от этого процесс разработки ПО сильно страдал. Помимо моего личного опыта, на написание статьи меня подвигли рассказы знакомых аналитиков, которые работают в сфере IT и практически все сталкиваются с проблемами организационного и коммуникационного характера, которые нужно и можно решать.

Последние 3 года я работаю системным аналитиком в группе компаний InfoWatch и в этой статье я хочу поделиться с вами практиками работы с требованиями, которые мы используем. Компания занимается разработкой Enterprise-продуктов для снижения рисков информационной безопасности, защиты и анализа корпоративных данных. К таким продуктам выдвигаются высокие требования, касающиеся их надёжности, производительности, отказоустойчивости, а так же требования для сертификации. В силу особенностей рынка информационной безопасности наши решения не являются облачными, а устанавливаются on-site у клиента. Поэтому мы работаем в режиме выпуска больших релизов несколько раз в год. Чтобы прийти к назначенной цели и сократить сроки релиза, мы работаем по принципам, заложенным в методологии Agile. Для старта разработки мы не готовим абсолютно детальные системные требования, а начинаем с высокоуровневого описания самых важных аспектов новой функциональности. То есть, принимаем решения, которые больше всего влияют на объем и сложность доработок и дают команде разработки необходимую информацию для старта работ по проектированию архитектуры и написанию кода (для небольших фич). Затем, по ходу разработки, постепенно детализируем требования и доводим их до уровня детализации, достаточного для написания подробных тест-кейсов. Такой подход позволяет не тратить много времени на старт работ и снизить риски того, что требования придется значительно перерабатывать, если выявятся какие-то новые технические ограничения.

Если ваш процесс разработки схож с нашим, или вы хотите перейти к такому комбинированному процессу, скорее всего, вам подойдут описанные ниже практики. Но даже если у вас другой процесс, есть вероятность, что представленные практики окажутся для вас полезными. В любом случае, предлагаю вам ознакомиться с ними, особенно, если вы работаете системным аналитиком в IT-компании.

Требования к разрабатываемому продукту основная зона ответственности системного аналитика. Практики, описанные ниже, направлены на упрощение работы с требованиями и, как следствие, на упрощение процесса разработки продукта:

  • документирование и версионирование;
  • оповещение об изменениях;
  • ревью;
  • митинги/собрания/статусы;
  • обсуждение/решение открытых вопросов;
  • протоколирование обсуждений;
  • валидация нового функционала;
  • презентация нового функционала.

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


image

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

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

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

Мы используем Confluence это удобный инструмент, который можно немного подкрутить под себя. О нашем опыте использования Confluence подробно рассказывает мой коллега в своей статье Как мы используем Confluence для разработки требований к продукту. Интересно то, что у многих IT-компаний этот инструмент есть, но не все используют его для документирования требований к продукту.

Оповещение об изменениях в требованиях


image

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

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

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

  • реализация может не соответствовать требованиям;
  • ожидаемый результат тестирования может не соответствовать требованиям и реализации;
  • документация может не соответствовать реализации.

До недавнего времени наша команда аналитиков оповещала всех заинтересованных об изменениях в требованиях следующим образом: после внесения изменений в требования, оставляли комментарий к задаче, отправляли письмо, которое содержит ссылку на задачу, ссылку на требования и краткое описание изменений. В конце прошлого года мы автоматизировали этот процесс: доработали issue-tracker (используем JIRA) и теперь после внесения изменений в требованиях мы в задаче, в рамках которой эти изменения были внесены, нажимаем кнопку Оповестить об изменениях, выбираем заинтересованные команды и делаем краткое описание изменений:

Скриншот 1
image

Письмо, которое автоматически генерируется после нажатия на кнопку Отправить оповещение, имеет следующее представление и содержит всю необходимую информацию:

Скриншот 2
image

Помимо письма в задаче остается комментарий с аналогичной информацией.

Ревью новых требований


image

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

Для этого мы так же доработали issue-tracker, добавили отдельный тип задачи Ревью, которая запускается ответственным аналитиком по каждой фиче на всех руководителей команд. Руководители самостоятельно или, делегируя своим подчиненным, делают вычитку требований, задают вопросы или вносят уточнения через комментарии и согласовывают внесенные изменения.

Скриншот 3
image

Митинги/собрания/статусы


image

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

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

Обсуждение/решение открытых вопросов


image

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

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

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

Протоколирование обсуждений


image

Для всех абсолютно привычно и обязательно фиксировать обсуждения решений с заказчиком, в виде ТЗ, которое неоднократно вычитывается до запятой и согласовывается всеми заинтересованными сторонами. Я хочу обратить внимание на то, что помимо официальной документации в разработке ПО, письменная фиксация договоренностей может быть полезна не только в рамках общения заказчик разработчик, но и внутри компании/команды.

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

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

Валидация нового функционала


image

Под валидацией понимается проверка реализованного функционала на соответствие бизнес требованиям. До начала функционального тестирования, ответственный за фичу аналитик проводит валидацию: проверяет, реализован ли основной сценарий и соответствует ли поведение системы ожиданиям. Это важная практика, которую необходимо использовать именно до передачи функционала на тестирование, так как если основной сценарий не выполняется, то нет смысла проверять другие кейсы. Для выполнения валидации прописывается приемочный сценарий, содержащий шаги, которые необходимо выполнить и ожидаемую реакцию системы, чтобы в конечном итоге решить бизнес задачу, ради которой функционал разрабатывался. В рамках валидации можно выявить, в первую очередь, невыполнение основного сценария, неудобство пользовательского интерфейса, а так же грубые функциональные дефекты. Если основной сценарий выполняется, то считается, что фича прошла валидацию и может быть передана на тестирование. Тестирование уже более детально, в соответствии с тест-кейсами выполняет проверку реализованного функционала.

Презентация нового функционала


image

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

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

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

Если у вас есть вопросы или вы хотите поделиться своим опытом, пожалуйста, оставляйте свои комментарии.

Автор: Венера Аббясова AbbyasovaVenera

* Все картинки для статьи взяты из открытого доступа в сети Интернет.
Подробнее..

Поиск автовладельцев в Instagram от хвостов китов до автомобилей

06.08.2020 08:23:05 | Автор: admin

image


К нам в рекламную группу Dentsu Aegis Network часто приходят компании-рекламодатели с запросом изучить и проанализировать их целевую аудиторию. И сделать это необходимо быстро и точно. Предположим, у нас есть клиент из автопрома, который хочет найти владельцев авто, а потом узнать их интересы, пол, возраст в общем, раскрасить аудиторию. Логично было бы сделать социологическое исследование, но это займет несколько недель. А если у клиента очень дорогие авто стоимостью выше 2,5 млн рублей? Много ли таких владельцев наберется для исследования? А для фокус-группы?


Хорошим способом найти нужного человека остается социальная сеть. Это место, где пользователь оставляет о себе много полезной информации, а если даже информации нет, то можно попробовать собрать её с помощью черной магии. Да, все верно, тут на помощь приходит data science.


Будем решать задачи поступательно. Давайте подумаем, как найти автовладельца в социальной сети.


  1. Провести текстовый анализ постов
    Казалось бы, здесь все просто. Написал помыл свою зайку/ласточку или вечерние покатушки, и мы нашли нужного человека. Но потом выясняется, что часть примеров нерелевантна, а чистить приходится руками.
  2. Поискать в хэштегах
    Тоже вариант, но не соответствующих запросу аккаунтов еще больше: попадается и коммерция, и ребята, которые тюнингуют старые машины, и дрифтеры. А мы ищем владельцев авто за 2,5 млн рублей здесь и сейчас.
  3. Найти пост с фотографией того авто, которое нам нужно и определить модель
    Затем нужно придумать эвристику, которая с большой вероятностью бы говорила, что владелец этого аккаунта в соцсети также является владельцем нужной нам машины.

Мы пробовали все варианты, но остановились на последнем.


Первый подход к снаряду


Итак, нам необходима модель, которая бы определяла марку и производителя авто. Но сколько марок и производителей мы хотим охватить? Здравый смысл подсказывает, что можем взять наших клиентов, их основных конкурентов и на этом остановиться. Около 100 различных марок автомобилей более чем достаточно. Каждая марка автомобиля будет являться отдельным классом в модели.


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


А что если у нас появится новый клиент из нового сегмента? Будем добирать еще 50-100 марок? Да, есть компании, которые идут именно таким путем, новая проблема это новая модель. В итоге получается зоопарк различных моделей. Мы решили, что на обучение новой модели у нас просто нет времени, поэтому сделаем все сразу.


Небольшая, но важная подготовка датасета


Если мы хотим что-то более универсальное, то в таком случае напрашивается подход обучения без учителя: система должна обучаться спонтанно, без привлечения экспериментатора. Для такого подхода собирать данные проще берем из интернета все картинки по релевантному запросу. Благодаря тому, что многие поисковые инструменты позволяют фильтровать контент по лицензии, можно быть спокойными за соблюдение авторских прав.
Сначала данные:
Оказалось, что многие поисковые инструменты под запросом автомобиль могут понимать вот это:
image


Технически это, конечно, автомобили, но не совсем те, которые нужны нам.
Гораздо хуже, когда результат такой:
image


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


Существующие подходы в компьютерном зрении

image
Источник
Object detection это технология, связанная с компьютерным зрением и обработкой изображений, которая позволяет находить объекты определенного класса на изображениях и видео.


В качестве архитектуры взяли retinanet, так как уже был готов весь пайплайн, нужно только подложить разметку. Для разметки воспользовались инструментом CVAT (подробнее мы рассказывали на pycon19) и всей командой потратили несколько часов на это веселое занятие. За это время удалось разметить несколько тысяч картинок, что позволило обучить модель с mAP ~ 0.97.


С какими сложностями мы столкнулись при подготовке набора данных? Первое, что хочется отметить это отсутствие автолюбителей в нашей команде, из-за чего иногда возникали споры по поводу сложных случаев, например, когда кузов авто визуально едва ли отличим на разных моделях. Хорошим примером могут послужить Lexus RX и Lexus NX.
image


Гораздо сложнее, когда кузов один и тот же, а названия автомобилей разные. Такое случается, когда бренд по разному себя позиционирует на разных рынках. Примеры Chevrolet Spark и Ravon R2:
image


Autoencoder


Приступаем к выбору модели. Первое что пришло нам на ум, это автоэнкодеры.


Автоэнкодер

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


  • Энкодер сжимает входные данные в скрытое пространство (latent space).
  • Декодер восстанавливает входные данные из скрытого пространства.

Прелесть автоэнкодера в том, что он обучается без учителя. А скрытое пространство может помочь кластеризовать данные.


С помощью автоэнкодеров кластеризуют даже Trading Card Game карточки, например, Magic the Gathering, так что появилось желание сделать кластеризацию автомобилей именно через этот инструмент. К сожалению, получилось неудачно: время потратили, а результат не оправдал ожиданий. Стали думать дальше.


Semantic Embeddings


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


Идея подробно:

Иерархия классов представляет собой направленный ацикличный граф $G = (V, E)$ с множеством вершин $V$ и множеством ребер $EVV$, что определяет гипонимические связи между семантическими понятиями. Другими словами, ребро $(u,v)E$ означает что $v$ является подклассом $u$. Тогда классы являются вершинами такого графа $C={c_{1},...,c_{n}}V$. Пример графа представлен ниже:



Авторы использовали меру непохожести $d_{G}:CC R$, рассчитываемую по формуле $d_{G}(u,v) =\frac{height(lcs(u,v))}{max_{wV}height(w)}$, где под высотой имеется в виду самый длинный путь от текущей вершины до листа. $lcs$ двух вершин это ближайший предок к этим двум вершинам. Так как $d_{G}$ ограничено между 0 и 1, авторы определили меру семантической близости между двумя семантическими понятиями как $s_{G}(u,v) = 1 d_{G}(u,v)$.
Рассмотрим граф из рисунка выше, его высота равняется 3, $inline$lcs("dog","cat")="mammal"$inline$, а $inline$lcs("dog","trout")="animal"$inline$, тогда $inline$s_{G}("dog","cat") = 1 d_{G}("dog","cat")=1-1/3=2/3$inline$, а $inline$s_{G}("dog","trout")=1-2/3=1/3$inline$. Таким образом, кошка и собака в представленной модели более близки семантически друг к другу, чем собака и форель.
Цель авторов посчитать вектора единичной длины $(c_{i})^n$ для всех классов $c_{i}, i=1,...,n$, так, чтобы скалярное произведение векторов соответствующих классов было равно мере их похожести:

$$display$$_{1 i,j n}:(c_{i})^T(c_{j}) =s_{G}(c_{i},c_{j})$$display$$


$$display$$_{1 i n}:(c_{i})= 1$$display$$



Собирать такой датасет показалось слишком долгим и дорогим процессом, ведь помимо сбора релевантных фотографий необходимо думать над грамотной иерархией классов по текстовым запросам. Но авторы предлагают вариант без иерархии, с поддержкой датасета Stanford Cars, который имеет 196 различных классов автомобилей и по 80 фотографий на каждый (почти то, что нам нужно, да?). Результат на stanford cars оказался лучшим, чем все то, что было до этого. Но на наших данных повторить успех не удалось. Понять, что на это повлияло плохая разметка, шум в данных или что-то еще не удалось, так как время на эксперименты закончилось, а проект был отложен на неопределенный срок.


Примерно так чувствовала себя наша нейросеть на тот момент:

Siamese Networks или от китов к машинам


Спустя 9 месяцев снова родилась необходимость в определении модели авто по фото. На этот раз у нас была возможность привлечь команду асессоров, чтобы собрать более качественный датасет. А самое главное, появилось понимание, какие марки авто нам нужны точно и какие необходимо добавить, чтобы иметь задел на будущее. Вместе с более качественной разметкой пришла идея использовать metric learning подход, например, сиамские сети c triplet loss.


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



Было привлекательно, что решение представляло из себя всего одну модель, а не целый зоопарк, как это бывает на kaggle. Из интересных особенностей, которые могли быть использованы у нас: на вход к 3 стандартным RGB каналам подаются маски. Поэтому размер входа составляет 512х256х4.


В первом подходе мы решили обучить модель без использования масок и получили на валидации mAP = 0.89. Такой результат с самого старта нас очень обрадовал. Но прогнав модель на отложенной выборке из живой среды обитания результат оказался плачевен.


И снова похожие ошибки:

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



Что поступало на вход, и это ещё очень удачный пример:



Очевидно, что нужно было что-то сделать с обучающим набором данных. Мы решили оставить всё как есть, но использовать более сильную аугментацию. Для этого использовали пакет albumentations. Он поддерживает bounding boxы и maskи, имеет множество готовых преобразований: помимо стандартных flip-crop-rotate еще и различные distortionы.


К более сильной аугментации решили сразу добавить маски. Для предсказания масок использовали фейсбуковский detectron. Мотивацией послужило наличие модели для сегментации изображений, обученной на датасете COCO, в котором присутствует класс авто. И наличие пайплайна под детектрон, потому что он уже был использован в команде. А еще мы любим копаться в гите facebookresearch.


Обучив модель на дополненных данных с новой аугментацией, мы смогли получить mAP ~ 0.81. Это сильно хуже предыдущего результата, но зато модель получилась более жизнеспособная.


Эвристики


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


  • Пользователь сфотографировался с автомобилем на фоне.
  • Авто могло оказаться на фоне случайно.
  • Автолюбитель выкладывает фотографии его любимых марок. Тут может быть случай и многих различных марок, и одной единственной.
  • Мы попали в профиль автодилера, автомастерской или автоблогера.
  • ...
  • И десятки других вариантов.

Как понять, что две фотографии одного и того же автомобиля являются одним и тем же автомобилем? Можно определить цвет автомобиля. Но с цветом имеются свои проблемы, так как даже зеленый цвет при определенном освещении выглядит серым. Кажется, что если мы научились отличать несколько сотен моделей авто друг от друга, то с цветом проблем возникнуть не должно. Поэтому мы взяли пайплайн для retinanet и обучили еще одну нейронную сеть на определение 16 цветов.


Чтобы найти владельца искомого авто с высокой вероятностью, оказалось достаточным зафиксировать определенный период времени, к примеру, в полгода или год, и оставлять только тех пользователей, у которых внутри этого периода не так много различных марок авто. При этом искомая марка должна встречается не менее определенного количества раз и быть одного и того же цвета.


Заключение и применение модели


Мы научились находить владельцев определенных авто по их постам. Что нам для этого понадобилось: нейронная сеть для первичной чистки данных; 5 человек, помогающих с разметкой; нейронная сеть для создания масок; нейронная сеть для определения марки автомобиля; нейронная сеть для определения цвета автомобиля. Почему бы теперь не применить результат в бою?


Попробуем найти владельцев BMW с большим количеством подписчиков:



Фотография BMW M5. Источник.



Ещё один пример BMW M5 от того же автора. Источник.



BMW 3 серии. Источник.



BMW M3. Источник.


Зачем нам искать владельцев BMW с большим количеством подписчиков, которые часто постят свой автомобиль? Например, они могут стать амбассадорами бренда.


Статья начиналась с того, что мы хотим найти автовладельцев конкретной марки, для того, чтобы рассказать кто они с точки зрения интересов, пола и возраста. Давайте протестируем этот подход на Audi:



Источник.



Источник.



Источник.


С определением пола и возраста по профилю в социальной сети всё более-менее понятно. Могут возникнуть вопросы, как определять интересы по профилю. Для этой цели мы пользуемся алгоритмом определения пересекающихся сообществ, описанным нашей командой в прошлом году. Посмотрим что получается:


Распределение по полу:
image


Распределение по возрасту:
image


Топ-10 верхнеуровневых интересов:
image


Спустимся на два уровня ниже в категорию Спорт и активных отдых:
image


Кажется, что Audi преимущественно не женский автомобиль. Разберемся почему же у нас выходит 57% женщин? Согласно исследованию brand analytics, распределение мужчин и женщин в инстаграме соотносится как 25:75. Учитывая этот факт, можно сделать перевзвес наших данных и получить более натуральное распределение по полу среди автовладельцев Audi. По этой причине при анализе социальной сети необходимо учитывать её специфику.


Что ещё мы можем узнать про автовладельцев?


Например, откуда они:
image


И куда они путешествуют:
image


Что можно сделать еще?


Здесь можно выделить два направления: улучшение текущего решения и новые подходы. Гипотезы для улучшения модели:


  • В первую очередь хотелось бы ещё раз пройтись по датасету. Как известно, есть прямая взаимосвязь между качеством моделей машинного обучения и данных, которые они используют.
  • Mixup аугментация. Смысл её в том, чтобы с разными весами смешать две картинки в одну. Веса при этом должны давать в сумме единицу. Сложность заключается в том, что для такой аугментации нужны несколько картинок. В то время как пакет albumentation работает с одной картинкой на вход. Делать самописное решение или добавлять стороннее для проверки гипотезы на тот момент показалось нецелесообразным.
    Пример:
    image
    Источник
  • Попробовать другие архитектуры нейронных сетей. Тут всё просто мы взяли решение первого места. Но ведь можно попробовать более простые архитектуры, потерять немного в качестве, но сильно выиграть в скорости. Ведь мы не на kaggle, и нам не так важны сотые и тысячные значения в метрике качества.
  • Добавить задачу определения цвета автомобиля в нейронную сеть определяющую марку и модель автомобиля. Иногда оказывается, что добавление дополнительного выхода в нейронную сеть для решения ещё одной проблемы повышает и качество метрики, и обобщающую способность.

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


image
Источник


Благодарим за внимание и надеемся что этот материал будет полезен и интересен читателям Хабра!


Статья написана при поддержке моих коллег Артёма Королёва, Алексея Маркитантова и Арины Решетниковой.


R&D Dentsu Aegis Network Russia.

Подробнее..

Перевод Бонус работы аналитиком данных Как я нашел свой новый дом в Дублине

26.02.2021 02:16:46 | Автор: admin
Наш сегодняшний перевод посвящен Data Science. Аналитик данных из Дублина рассказал, как искал себе жилье на рынке с высоким спросом и низким предложением.



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

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

Когда мы с женой решили приобрести новый дом в Дублине, я сразу увидел возможность использовать знания!

Содержание статьи:

  • Высокий спрос, низкое предложение
  • В поисках данных
  • От идеи к инструменту
  • Основные данные
  • Улучшение качества данных
  • Google Data Studio
  • Некоторые подробности реализации (а потом переходим к самому интересному)
  • Геокодирование адресов
  • Расчет времени, которое объект недвижимости находится на рынке
  • Анализ
  • Выводы
  • Заключение

Данные ниже получены не путем скрапинга (scraping), а были сгенерированы с помощью этого скрипта.

Высокий спрос, низкое предложение


Чтобы понять, с чего всё началось, можно ознакомиться с моим личным опытом покупки недвижимости в Дублине. Должен признать, что это было непросто: на рынке очень высокий спрос (благодаря отличным экономическим показателям Ирландии в последние годы), а жилье стоит крайне дорого. Согласно отчету Евростата, в 2019 году в Ирландии была самая высокая стоимость жилья по сравнению с ЕС (на 77% выше среднего показателя по ЕС).



Что означает эта диаграмма?

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

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

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

Думаю, что многим людям по всему миру знакома эта ситуация, так как, скорее всего, в крупных городах дела обстоят так же.

Как и все, в поисках недвижимости мы хотели найти идеальный дом в идеальном районе по доступной цене. Давайте посмотрим, как аналитика данных помогла нам в этом!

В поисках данных


В любом Data Science проекте есть этап сбора данных, и для этого конкретного случая я искал источник, содержащий информацию обо всем жилье, доступном на рынке. В Ирландии это два типа сайтов:

  • веб-сайты агентств по продаже недвижимости,
  • агрегаторы.

Оба варианта являются очень полезными и значительно облегчают жизнь продавцам и покупателям. К сожалению, пользовательский интерфейс и предлагаемые фильтры не всегда позволяют наиболее эффективно извлечь необходимую информацию и сравнить разные объекты недвижимости. Далее перечислены некоторые вопросы, на которые сложно найти ответ с помощью поисковых систем, наподобие Google:

1. Сколько времени займет дорога на работу?

2. Сколько объектов недвижимости находится в том или ином районе? На классических веб-сайтах можно сравнивать районы города, но они обычно охватывают несколько квадратных километров. Это недостаточный уровень детализации, чтобы понять, например, что слишком высокое предложение на конкретной улице говорит о каком-то подвохе. На большинстве специализированных сайтов есть карты, но они не настолько информативны, как хотелось бы.

3. Какие удобства есть рядом с домом?

4. Какая средняя запрашиваемая цена по группе объектов недвижимости?

5. Как давно жилье выставлено на продажу? Даже если эта информация имеется, она не всегда надежна, так как риелтор мог удалить объявление и разместить его заново.

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

От идеи к инструменту


Основные данные


Первым шагом стало написание скрапера (scraper) для сбора базовой информации:

  • необработанный адрес объекта недвижимости,
  • текущая цена продавца,
  • ссылка на страницу с объектом недвижимости,
  • основные характеристики, такие как количество комнат, количество ванных комнат, рейтинг энергоэффективности,
  • количество просмотров объявления (если доступно),
  • тип объекта недвижимости (дом, квартира, новостройка).

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

Улучшение качества данных


При выборе жилья моим главным аргументом в пользу покупки является удобная дорога на работу, для меня это не больше 50 минут на всю дорогу от двери до двери. Для этих расчетов я решил использовать Google Cloud Platform:

1. С помощью API геокодирования (Geocoding API) я получил координаты широты и долготы, используя адрес объекта недвижимости.

2. С помощью API направлений (Directions API) я рассчитал время, необходимое чтобы добраться от дома до работы пешком и на общественном транспорте. Примечание: На велосипеде получается примерно в 3 раза быстрее, чем пешком.

3. С помощью API мест (Places API) я получил информацию об удобствах вокруг каждого объекта недвижимости. В частности, нас интересовали аптеки, супермаркеты и рестораны. Примечание: Places API очень дорогие: с базой данных, содержащей 4,000 объектов недвижимости, вам потребуется выполнить 12,000 запросов, чтобы найти информацию по трем видам удобств. Поэтому я исключил эти данные из окончательного дашборда.

Помимо географического расположения, меня интересовал еще один вопрос: как долго объект недвижимости находится на рынке? Если недвижимость не продается слишком долго это тревожный звоночек: возможно, что-то не так с районом или самим домом, либо запрашиваемая цена слишком высока.

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

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

Google Data Studio


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



Некоторые подробности реализации


Честно говоря, реализация была довольно простой, и здесь нет ничего нового или особенного: просто набор скриптов для сбора данных и некоторые базовые преобразования Pandas. Разве что стоит отметить взаимодействие с Google API и расчет времени, в течение которого недвижимость находилась на рынке.

Данные ниже получены не путем скрапинга (scraping), а были сгенерированы с помощью этого скрипта.

Давайте рассмотрим необработанные данные.

Как я и ожидал, файл содержит следующие столбцы:

  • id: Идентификатор объявления.
  • _address: Адрес объекта недвижимости.
  • _d_code: Код района Дублина. Каждый район Дублина имеет кодовое обозначение в формате D<число>. Если <число> четное, значит дом расположен на южном берегу Лиффи (река, пересекающая город), а если число нечетное на северном.
  • _link: Ссылка на исходную страницу, где было размещено объявление.
  • _price: Запрашиваемая цена объекта недвижимости в евро.
  • type: Тип недвижимости (дома, квартиры, новостройки).
  • _bedrooms: Количество комнат (спален).
  • _bathrooms: Количество ванных комнат.
  • _ber_code: Код, обозначающий рейтинг энергоэффективности: чем ближе к букве А, тем лучше рейтинг.
  • _views: Количество просмотров объявления (если доступно).
  • _latest_update: Когда объявление было обновлено или создано (если доступно).
  • days_listed: В этом столбце показан результат вычисления разница между датой, когда я собирал данные, и датой в столбце _last_update.

Геокодирование адресов


Суть в том, чтобы перенести все это на карту и задействовать возможности геолокализованных данных. Чтобы сделать это, давайте посмотрим, как получить широту и долготу при помощи Google API.

Для этого вам потребуется учетная запись в сервисе Google Cloud Platform, а затем вы можете воспользоваться руководством по ссылке, чтобы получить ключ API и включить соответствующий API. Как я писал ранее, для этого проекта я использовал Geocoding API, Directions API и Places API (так что вам нужно будет включить эти конкретные API при создании ключа API). Ниже фрагмент кода для взаимодействия с Google Cloud Platform.

# The Google Maps libraryimport googlemaps# Date time for easy computations between datesfrom datetime import datetime# JSON handlingimport json# Pandasimport pandas as pd# Regular expressionsimport re# TQDM for fancy loading barsfrom tqdm import tqdmimport timeimport random# !!! Define the main access point to the Google APIs. # !!! This object will contain all the functions neededgeolocator = googlemaps.Client(key="<YOUR API KEY>")WORK_LAT_LNG = (<LATITUDE>, <LONGITUDE>)# You can set this parameter to decide the time from which # Google needs to calculate the directions# Different times affect public transportDEPARTURE_TIME = datetime.now# Load the source datadata = pd.read_csv("/path/to/raw/data/data.csv")# Define the columns that we want in the geocoded dataframegeo_columns = [               "_link",                "lat",                "lng",                "_time_to_work_seconds_transit",                "_time_to_work_seconds_walking"               ]# Create an array where we'll store the geocoded datageo_data = []# For each element of the raw dataframe, start the geocodingfor index, in tqdm(data.iterrows()):    # Google Geo coding    _location = ""    _location_json = ""    try:        # Try to retrieve the base location,         # i.e. the Latitude and Longitude given the address        _location = geolocator.geocode(row._address)        _location_json = json.dumps(_location[0])    except:        pass    _time_to_work_seconds_transit = 0    _directions_json = ""    _lat_lon = {"lat": 0, "lng": 0}    try:        # Given the work latitude and longitude, plus the property latitude and longitude,        # retrieve the distance with PUBLIC TRANSPORT (`mode=transit`)        _lat_lon = _location[0]["geometry"]["location"]        _directions = geolocator.directions(WORK_LAT_LNG,               (_lat_lon["lat"], _lat_lon["lng"]), mode="transit")        _time_to_work_seconds_transit = _directions[0]["legs"][0]["duration"]["value"]        _directions_json = json.dumps(_directions[0])    except:        pass    _time_to_work_seconds_walking = 0    try:        # Given the work latitude and longitude, plus the property latitude and longitude,        # retrieve the WALKING distance (`mode=walking`)        _lat_lon = _location[0]["geometry"]["location"]        _directions = geolocator.directions(WORK_LAT_LNG, (_lat_lon["lat"], _lat_lon["lng"]), mode="walking")        _time_to_work_seconds_walking = _directions[0]["legs"][0]["duration"]["value"]    except:        pass              #  This block retrieves the number of SUPERMARKETS arount the property    '''    _supermarket_nr = 0    _supermarket = ""    try:        # _supermarket = geolocator.places_nearby((_lat_lon["lat"],_lat_lon["lng"]), radius=750, type="supermarket")        _supermarket_nr = len(_supermarket["results"])    except:        pass    '''     #  This block retrieves the number of PHARMACIES arount the property    '''    _pharmacy_nr = 0    _pharmacy = ""    try:        # _pharmacy = geolocator.places_nearby((_lat_lon["lat"],_lat_lon["lng"]), radius=750, type="pharmacy")        _pharmacy_nr = len(_pharmacy["results"])    except:        pass    '''    #  This block retrieves the number of RESTAURANTS arount the property    '''    _restaurant_nr = 0    _restaurant = ""    try:        # _restaurant = geolocator.places_nearby((_lat_lon["lat"],_lat_lon["lng"]), radius=750, type="restaurant")        _restaurant_nr = len(_restaurant["results"])    except:        pass    '''    geo_data.append([row._link, _lat_lon["lat"], _lat_lon["lng"], _time_to_work_seconds_transit,                     _time_to_work_seconds_walking])    geo_data_df = pd.DataFrame(geo_data)    geo_data_df.columns = geo_columns    geo_data_df.to_csv("geo_data_houses.csv", index=False)


Расчет времени, которое объект недвижимости находится на рынке


Давайте внимательно рассмотрим данные:



Как вы можете видеть на этой выборке, количество просмотров объектов недвижимости не отражается в количестве дней, в течение которых объявление было активным: например, дом с id = 47 имеет ~ 25 тысяч просмотров, но появилось оно в тот день, когда я загружал данные.

Однако эта проблема характерна не для всех объектов недвижимости. В приведенном ниже примере количество просмотров более сопоставимо с количеством дней, в течение которых объявление было активным:



Как мы можем использовать информацию, приведенную выше? Легко! Мы можем использовать второй набор данных в качестве обучающей выборки для модели, которую мы можем затем применить к первому набору данных.

Я протестировал два подхода:

1. Берем сопоставимый набор данных и вычисляем среднее количество просмотров в день, затем применяем это значение к первому набору данных. Данный подход не лишен здравого смысла, но в нем есть следующая проблема: все объекты недвижимости объединены в одну группу, при этом вполне вероятно, что объявление о продаже дома стоимостью 10 миллионов евро наберет меньше просмотров в день, поскольку такой бюджет доступен узкой группе людей.

2. Обучаем модель Random Forest на втором наборе данных и затем применяем ее к первому набору.



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



Анализ


Дамы и господа, представляю вашему вниманию итоговый дашборд. Если вы хотите покопаться в нем, перейдите по ссылке.

Примечание: К сожалению, модуль Google Maps не работает при встраивании в статью, поэтому мне пришлось использовать скриншоты.


https://datastudio.google.com/s/qKDxt8i2ezE

Карта является самой важной частью дашборда. Цвет пузырей зависит от цены дома /квартиры, и расцветка учитывает только доступные объекты недвижимости (соответствующие настройкам фильтров в правом верхнем углу); размер пузырей указывает на расстояние до работы: чем он меньше, тем короче дорога.

Графики позволяют анализировать, как меняется запрашиваемая цена в зависимости от некоторых характеристик (например, типа здания или количества комнат), а в диаграмме разброса сопоставляется расстояние до работы и запрашиваемая цена.

И наконец, таблица с необработанными данными (DL RF расшифровывается как Days Listed Random Forest и показывает количество дней, в течение которых объявление было активным, модель Random Forest).

Выводы


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

Набор данных включает около 4, 000 домов и квартир: конечно, мы не можем просмотреть их все, поэтому наша задача определить подгруппу записей, содержащую один или несколько объектов недвижимости, которые мы готовы рассмотреть к покупке.

Для начала нам нужно уточнить критерии поиска. Для примера представим, что мы ищем недвижимость, соответствующую следующим характеристикам:

1. Тип объекта недвижимости: Дом.
2. Количество комнат (спален): 3.
3. Расстояние до работы: меньше 60 минут.
4. Рейтинг энергоэффективности: A, B, C, или D.
5. Цена: от 250 до 540 тысяч евро.

Давайте применим все фильтры, кроме цены, и посмотрим на карту (отфильтровывая только то, что дороже 1 миллиона и дешевле 200 тысяч евро).



В целом запрашиваемая цена на недвижимость на юге от Лиффи намного выше, чем на севере, за некоторыми исключениями на юго-западе города. Даже внешние районы на севере, то есть северо-восток и северо-запад, кажутся менее дорогими, чем северная часть города по центру. Одна из причин такого ценообразования заключается в том, что главная трамвайная линия в Дублине (LUAS) пересекает город с севера на юг по прямой (есть еще одна линия, которая идет с запада на восток, но она не проходит по всем деловым районам).

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

Ситуация становится еще более интересной, если установить фильтр цены в соответствии с нашим бюджетом (не забывайте, что на карте выше показаны дома с 3 спальнями, а дорога на работу занимает менее 60 минут, а на карте ниже добавлен только фильтр по цене):



Давайте сделаем шаг назад. Мы имеем общее представление о тех районах, которые нам по карману, но теперь предстоит самое сложное поиск компромиссов! Хотим ли мы подобрать более бюджетный вариант? Или же мы рассмотрим лучший дом, который можно купить на наши заработанные большим трудом сбережения? К сожалению, аналитика данных не может дать ответ на эти вопросы, это деловое (и сугубо личное) решение.

Предположим, мы выбрали второй вариант: отдаем предпочтение качеству дома или района, а не более низкой цене.

В таком случае нам нужно рассматривать следующие варианты:

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

2. Дом, расположенный в скоплении дорогой недвижимости если все остальные объекты недвижимости рядом с определенным домом дорогие, это может означать, что район пользуется высоким спросом. Это просто дополнительное примечание, но мы могли бы количественно оценить это явление с помощью пространственной автокорреляции (например, рассчитав Индекс I Морана).

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

Давайте более подробно рассмотрим, какие есть предложения в этом районе:



Мы уже сократили наши варианты с 4,000 до менее 200, а теперь нам нужно получше разбить точки и сравнить кластеры.

Автоматизация поиска в кластере не дополнит этот анализ значительно, но давайте все равно применим алгоритм DBSCAN. Мы используем DBSCAN, потому что некоторые группы могут быть неглобулярными (например, метод k-средних не сработает должным образом на этой базе данных). В теории нам нужно вычислить географическое расстояние между точками, но мы будем использовать евклидову систему, так как она дает хорошее приближение:

import pandas as pdfrom sklearn.cluster import DBSCANdata = pd.read_csv("data.csv")data["labels"] = DBSCAN(eps=0.01, min_samples=3).fit(data[["lat","lng"]].values).labels_print(data["labels"].unique())data.to_csv("out.csv")




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



Мы отказываемся от районов с более низкими ценами, так как для нас в приоритете максимальное качество жилья и удобная дорога на работу в рамках нашего бюджета, поэтому можно исключить кластеры 2, 3, 4, 6 и 9. Обратите внимание, что кластеры 2, 3 и 4 расположены в одних из самых бюджетных районах северного Дублина (вероятно, это связано с менее развитой инфраструктурой общественного транспорта). В кластере 11 представлены дорогие варианты, расположенные далеко от работы, поэтому его мы тоже можем исключить.

Если посмотреть на более дорогие скопления, номер 7 является одним из лучших с точки зрения расстояния до работы. Это Драмкондра, красивый жилой район на севере Дублина; несмотря на то, что он не очень удобно расположен относительно трамвайной линии, по нему проходят автобусные маршруты; в кластере 8 цены на жилье и расстояние до работы такие же, как и в Драмкондре. Еще один кластер, который стоит проанализировать, это номер 10: кажется, что он находится в районе с более низким предложением, а это означает, что люди здесь, вероятно, редко продают жилье, к тому же у этого района довольно удобное расположение относительно маршрутов общественного транспорта (при условии, что все районы имеют одинаковую плотность населения).

И наконец кластеры 1 и 5, расположенные рядом с парком Феникс, крупнейшим огороженным общественным парком.


Кластер 7


Кластер 8


Кластер 10


Кластер 1


Кластер 5

Отлично! Мы нашли 26 объектов недвижимости, которые стоит посмотреть прежде всего. Теперь мы можем тщательно проанализировать каждое предложение и, в конечном итоге, организовать просмотр с риелтором!

Заключение


Мы начали поиск, практически ничего не зная о Дублине, а в итоге хорошенько разобрались, какие районы города особенно востребованы при покупке жилья.

Заметьте, мы даже не смотрели фотографии этих домов и ничего о них не читали! Просто взглянув на хорошо организованный дашборд, мы сделали несколько полезных выводов, к которым мы не смогли бы прийти в самом начале!

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

1. Мы не интегрировали в исследование набор данных об удобствах (тот, что мы составили с использованием Places API). При наличии большего бюджета для облачных сервисов мы могли бы легко добавить эту информацию в дашборд.

2. В Ирландии публикуется много интересных данных на сайте статистической службы: например, можно найти информацию о количестве звонков в каждый участок полиции по кварталу и по типу преступления. Таким образом, мы могли бы узнать, в каких районах наблюдается наибольшее количество краж. Так как можно получить данные переписи для каждого избирательного участка, мы могли бы также рассчитать уровень преступности на душу населения. Обратите внимание, что для таких расширенных функций нам потребуется соответствующая геоинформационная система (например, QGIS) или база данных, которая может обрабатывать географические данные (например, PostGIS).

3. В Ирландии имеется база данных с предыдущими ценами на жилье, которая называется Residential Property Register (Реестр жилой недвижимости). На их сайте зафиксирована информация о каждом объекте жилой недвижимости, приобретенном в Ирландии начиная с 1 января 2010 года, включая дату продажи, цену и адрес. Сравнив текущие цены на дома с прошлыми, можно понять, как со временем менялся спрос.

4. Расценки на страхование жилья во многой степени зависят от местоположения дома. Приложив некоторые усилия, мы могли бы выполнить скрапинг сайтов страховых компаний, чтобы интегрировать в наш дашборд их модель факторов риска.

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

Благодаря этому инструменту мы с женой сэкономили себе (и риелтору) время: 4 раза сходили на просмотр, предложили свою цену 3 продавцам, и один из них принял наше предложение.
Подробнее..

Как мы управляем проектами развития аналитической отчётности

22.05.2021 12:06:36 | Автор: admin

Привет, Хабр! Меня зовут Владимир, я бизнес-аналитик в офисе данных Ростелекома и занимаюсь развитием отчётности. Компания делает ставку на развитие data-driven культуры. Спрос на данные и аналитику со стороны бизнеса растёт, и соответственно развивается экосистема управления данными, в том числе организационная структура и бизнес-процессы.

К концу 2019 года объём задач отчётности очень сильно вырос и это стало своеобразным нагрузочным тестированием для наших процессов. Стало понятно, что работать по-старому и соблюдать SLA нам становится все сложнее. Были нужны новые правила игры, соблюдение которых сделает управление типовыми задачами проще, планирование более предсказуемым, а выполнение обязательств реалистичным даже в условиях, когда рост команды сильно ограничен, а рост количества заявок безграничен.

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

Введение

Нужно бежать со всех ног, чтобы только оставаться на месте, а, чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!, писал Льюис Кэрролл ещё во времена викторианской Англии. А сто лет спустя принципом Черной королевы назвали эволюционную гипотезу, сравнивающую борьбу за выживание с гонкой вооружений. Чем быстрее перемены окружающей среды, тем важнее скорость адаптации. Для организаций это правило работает так же: чтобы оставаться на плаву, нужно быстрее приспосабливаться к изменениям конкурентов, учиться и эффективнее перестраивать процессы.

Индустрия телекома и особенно управление данными бурно растут вместе со спросом на услуги, но этот же рост, вместе с возможностями, создает и множество проблем. Это особенно важно, когда деятельность организации разнообразна и содержит много специфики, из-за которой сложнее применять чужой опыт. Из-за этого приходится чаще импровизировать и вместо общепринятых хороших практик (почему в этом случае best practices скорее хорошие, а не лучшие рекомендую почитать у Романа Журавлева) искать альтернативы, оптимальные для конкретной ситуации.

Ситуация

Чтобы выбрать оптимальное решение, нужно знать условия, для которых оно предназначено, так что начну с обзора.

В корпоративном центре Ростелекома все профильные направления, работающие с отчётностью, объединены в Офис Данных. Это более двух сотен сотрудников в Москве и регионах, которые занимаются развитием платформы управления данными, работают в направлении глубокого анализа и развитии аналитической отчётности.

Направление обширно: отчёты используют данные нескольких сотен систем-источников, запросы поступают от всех подразделений компании, в которых свои особенности, бизнес-процессы и действующие регламенты. География бизнеса вся страна, разделенная на семь макрорегиональных филиалов, каждый из которых не так давно был отдельной компанией. Значение отчётности и требования к качеству аналитики растут, так как бизнес использует данные для принятия ежедневных управленческих решений и данные становятся важной частью операционных процессов компании.

Развитие отчётности организовано так: за сегментами бизнеса закреплены постоянные команды из 10-30 аналитиков и разработчиков, из которых формируют рабочие группы для отдельных задач. Различий в бизнес-процессах сегментов много и каждый раз в них разбираться непродуктивно. У разработчиков с этим проще, но всё равно хочется сохранять сработавшиеся команды. Командой сегмента руководит фронт-менеджер, который объединяет роль ресурсного менеджера для команды и аккаунт-менеджера для заказчика.

Обычно в работе у фронт-менеджера есть 10-12 задач, с каждой задачей на различных этапах может работать от 2 до 5 человек. Длительность таких задач от нескольких недель до полугода (это очень грубая оценка, чтобы показать масштабы). По каждой доработке требуется создать артефакты: комплект документов, которые будут использоваться сопровождением для работы над инцидентами, и отчётность в JIRA по объёмам трудозатрат, срокам работ и загруженности ресурсов, которая позволяет анализировать эффективность процессов.

Чтобы задача проходила маршрут и не буксовала, ей нужен владелец, погруженный в предмет и заинтересованный в её своевременном выполнении. Раньше этим занимались фронт-менеджеры, но к концу 2019 года объём задач вырос настолько, что на управление отдельными задачами у них уже не оставалось времени. У фронтов основные обязанности взаимодействие с бизнес-заказчиками, маршрутизация поступающих запросов и управление командой, а управление отдельными задачами можно делегировать, иначе будет как на картинке.

Поиск решения

По сути, мы выбирали между двумя вариантами: набрать выделенных исполнителей на роль РП или организовать совмещение этой роли кем-то из команды. Для этого нужно было разобраться, каким задачами РП будет управлять, в чём это управление будет заключаться и какие активности нужно координировать. Это позволило определить необходимые для наших РП навыки и оценить, с каким объемом задач один РП сможет работать параллельно. Отдельный важный вопрос как появление нового руководителя скажется на остальных членах команды.

Мы поняли, что в нашем случае многие классические компетенции руководителя проектов окажутся невостребованными: например, не требуется управлять бюджетом или поставщиками, проекты будут выполняться по одному и тому же регламенту, а предметная область всегда будет ограничена отчётностью для конкретного бизнес-сегмента. Задачи чаще всего типовые, но требуют погружения в предметную область, понимания процесса разработки и содержания работ на всех этапах.

Мы сделали вывод, что РП с небольшим количеством задач обойдется неоправданно дорого и будет недогружен, а в большем объёме задач не будет успевать разобраться, и его руководство будет ограничено чисто административными функциями. С другой стороны, добавление к небольшой команде выделенного РП заметно усложнит коммуникации придётся ещё одного начальника держать в курсе вопросов, которыми он непосредственно не занимается.

Расходы на команду увеличатся, но проблему это не решит. Исходя из этого, от выделенных исполнителей в роли РП мы отказались. С другой стороны, аналитики уже:

  • погружены в предметную область, как никто другой;

  • участвуют в выполнении задачи на всех этапах;

  • выполняют интегрирующую роль для команды.

С этой перспективы идея совместить руководство проектом с ролью аналитика (бизнес или системного) стала выглядеть логичной.

Реализация

Дальше мы проектировали и документально оформляли процесс, совмещали с уже существующими операционными процессами, о некоторых из которых уже рассказывали мои коллеги (статьи на Хабре: раз, два). В общем процесс разработки приобрел вид:

Документацию составили в формате методики управления, скорее даже инструкции. Где-то брали собственные наработки, где-то транслировали рекомендации PMBoK на наше организационное окружение. Писали так, чтобы документа было достаточно для выполнения роли РП, и чтобы его мог использовать человек без опыта проектного управления.

Затем, дополнив документ всей сопутствующей мишурой вроде шаблонов, провели обучение и в начале 2020 года запустили процесс в пилотном режиме. Работа ещё не завершена, по части согласованности процессов ещё многое нужно сделать, но определенные выводы уже можно сделать.

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

К плюсам принятого решения можно отнести:

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

  2. На коммуникации внутри команды времени тратим не больше, чем тратили раньше;

  3. Материалы задач легче использовать повторно, сроки в целом стали более прогнозируемыми.

Трудности:

  1. Есть нестыковки с операционными процессами, особенно в нетиповых ситуациях, но это ожидаемо продолжаем шлифовать;

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

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

аналитика даёт больше плюсов, чем создает неудобств.

Вместо эпилога

Минуточку, управление работами по задаче Вы там что, открыли для себя дверь роль менеджера проекта и повесили на бизнес-аналитика?. Короткий ответ Да, ответ по существу длиннее Сначала мы оценили все, что нам нужно от роли, упростили её соответственно задачам и подготовили всё необходимое, чтобы даже начинающий РП мог её выполнять.

Важнее не название роли, а наполнение. Называть можно как кому привычнее Руководителем проекта, тех. лидом или как-то ещё это вопрос удобства и выбранного глоссария.

P.S. Только не миниРП, пожалуйста :)

Подробнее..

Аналитика возраста воздушного флота российских авиакомпаний

01.04.2021 16:06:37 | Автор: admin

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

Мотивация, планирование, выборка

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

Для начала хочется обозначить, что будем подразумевать под российскими авиакомпаниями те, которые есть в официальном списке эксплуатантов. В исследовании были отобраны топ российских авиакомпаний - Аэрофлот, Алроса, Аврора, Азимут(Azimuth), АзурЭйр(AzurAir), ИрАеро, НордСтар(NordStar), НордВинд(NordWind), Икар(PegasFly), Победа(входит в группу Аэрофлот), РэдВинг(RedWings), Россия(Rossiya), РоялФлайт (RoyalFlight), S7(АК Сибирь), СмартАвиа(SmartAvia), Уральские авиалинии(UralAirlines), Ютэйр(Utair), Якутия(Yakutia), Ямал(Yamal). Данная выборка охватывает 85% авиапарка российских авиакомпаний. В этот список не попала авиакомпания ГазпромАвиа у которой имеется большой авиапарк, но причина исключения - это отсутствие возраста в большинстве данных, что не представлялось возможным определить среднее значение, но модели авиапарка у компании очень разнообразны и интересны, но об этом позже.

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

Инструменты аналитики

В нашем исследовании будем применять стандартные инструменты для этого - язык программирования python с библиотеками numpy, pandas для анализа данных, библиотеки plotly для визуализации результата, и инструмент Тableau для дашборда, google sheets для первоначальной обработки и наш любимый brain.

Процесс обработки данных

Итак, наш исследуемый датафрейм содержит 7 переменных(колонок) и 834 строки. Посмотреть его можно тут.

Посмотрим гистограмму и посмотрим распределение данных.

Давайте сразу же посмотрим среднее значение и медиану возраста всей выборки. Получается среднее(mean) = 10.61 лет, медиана(median) = 9.0 лет.

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

Код
ages = data.groupby(by='airlines').age.describe()ages.sort_values(by='count', ascending=False)
Описательные статистики значений возраста, количество воздушных судов в разрезе каждой авикомпании.Описательные статистики значений возраста, количество воздушных судов в разрезе каждой авикомпании.

Из представленного результата мы видим, что топ-5 авиакомпаний с наибольшим количеством авиапарка это:

самый молодой флот у авиакомпаний:

Азимут (Azimuth) - среднее(mean) 2,9 лет, медиана(медиана) 3 года;

Победа - среднее(mean) 3,5 лет, медиана(медиана) 3 года;

Аэрофлот - среднее(mean) 5,1 лет, медиана(медиана) 5 лет;

S7 - среднее(mean) 9,5 лет, медиана(медиана) 9 лет,

Поговорим и о старичках флота, которые трудятся, как мы можем заметить это:

АзурЭйр (AzurAir) - среднее(mean) 20,3 года, медиана(медиана) 20 лет, минимальное значение - 13 лет, максимальное значение 30 лет.

Теперь отсортируем наиболее часто повторяющийся тип авиалайнеров и выведем топ-10 из них.

Код
data.type.value_counts().to_frame('count').head(10)
Количество часто встречающихся авиалайнеровКоличество часто встречающихся авиалайнеров

Как можно видеть пятёрка наиболее часто встречающиеся судов это:

Airbus A320

Sukhoi Superjet 100

Boeing 737

Airbus A321

Топ-3 производителей авиалайнеров выглядит так:

Среди типов авиалайнеров был обнаружен Boeing 737 MAX, эксплуатация которых была приостановлена по решению международных воздушных организаций. Такие авиалайнеры были замечены у компаний S7, NordStar, UralAirlines, Utair,

Boeing 737 MAX

и один единственный новый авиалайнер Airbus A350-941 с регистрационным номером VQ-BFY в Аэрофлоте :)

Airbus A350-941

кстати, по сводке flightradar24 данный авиалайнер частенько летает маршрутом Москва - Майами(США) - Москва :)

А в завершении нашего исследования, как и говорил ранее, давайте поговорим о воздушном флоте авиакомпании ГазпромАвиа :) Итак, что мы имеем вернее они имеют, а имеют они 50 единиц флота в который входят такие разнообразные и интересном марки и модели как:

Airbus Helicopter H135 - 5 единиц;

Airbus Helicopter H155 - 1 единица;

Dassault Falcon 900 - 6 единиц;

Dassault Falcon 7X - 5 единиц;

Dassault Falcon 8X - 2 единицы;

и вот эта интересная модель Let L410UVP-E20 Turbolet

В завершении хочется напомнить, что вся представленная информация основываются на полученных данных с сервиса flightradar24, поэтому, возможно часть воздушного флота не попала в выборку, а часть была внесена сервисом с ошибками, всё может быть, но общее представление о возрасте флота российских авиалиний думаю получен ;)

И конечно же на десерт красивый dashboard на Tableau, который можно посмотреть тут.

Всем всего хорошего, ваш konstatic :)

Подробнее..

Развитие BI-систем тренды и движение в сторону ABI. Взгляд со стороны визуализации

04.05.2021 16:09:09 | Автор: admin

Почему привычные нам BI-системы меняются? Куда движется их развитие, какие технологии сейчас внедряются, как можно улучшить аналитику для бизнеса? В этой статье мы коснемся этих вопросов и постараемся ответить, чего следует ожидать в ближайшем будущем от систем бизнес-аналитики.

Заметка от партнера IT-центра МАИ и организатора магистерской программы VR/AR & AI компанииPHYGITALISM.

Кратко о BI-системах и их преимуществах

BI-системы используются в большинстве сфер, поэтому этот термин широко известен в бизнес-сообществе. На пользовательском уровне BI-системы это программное обеспечение, которое помогает работать с данными, анализировать и обрабатывать большие объемы информации. Принцип их работы построен на загрузке всех имеющихся данных в единое хранилище, где информация обрабатывается, а затем появляется в виде готовых интерактивных отчетов и презентаций.

Рис.1. Преобразование данных в аналитику в BI-системахРис.1. Преобразование данных в аналитику в BI-системах

BI-системы собирают всю информацию в одном месте для удобной аналитики и помогают выявлять закономерности и тренды. Загружая в BI-систему данные о рынке мы получаем более полное представление о ситуации, а, значит, и лучшую аналитику.

Рис 2. Для каких задач внедряют BI-системыРис 2. Для каких задач внедряют BI-системы

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

Рис 3. Преимущества BI-системРис 3. Преимущества BI-систем

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

Рис.4. Объем рынка BI-системРис.4. Объем рынка BI-систем

Расширяются границы их применения для стратегического и тактического планирования.

Рис 5. BI-системы как часть бизнесаРис 5. BI-системы как часть бизнеса

Внедрение BI-систем становится все более нужным и прибыльным для компаний.

Рис 6. Эффекты от внедрения BI-систем для компанийРис 6. Эффекты от внедрения BI-систем для компаний

Рынок BI-систем развивается в сторону кроссплатформенности и внедрения новых подходов к аналитике. Именно поэтому важно понимать, какие тренды сейчас есть.

Тренды в развитии BI-систем: эволюция до ABI

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

Современная бизнес-аналитика устроена по-другому: она интерактивна и доступна. Доступ к данным можно предоставить любому, пользователь может сам найти ответы на вопросы, кликая на интерактивные визуализации: графики, карты, таблицы или диаграммы.

Рис.7. Интерактивность современных BI-системРис.7. Интерактивность современных BI-систем

За все время настолько изменилось представление о BI-системах, что большинство специалистов называют используемые self-service BI-системы (такие как Tableau, Power BI или Qlik Sense) просто BI-системой, хотя различия тут есть в традиционных системах в аналитику были вовлечены IT-специалисты, а в self-service пользователи сами выполняют всю работу, без обращения к IT.

Рис.8. Разница между традиционной и self-service BI-системамиРис.8. Разница между традиционной и self-service BI-системами

Появление ABI-систем

Эволюция BI-систем не стоит на месте, появляются новые подходы к аналитике, а данных становится все больше именно поэтому возникла новая концепция Augmented Business Intelligence, которую выделили Gartner.

Рис.9. Эволюция аналитики в BI-системы и в Augmented Business IntelligenceРис.9. Эволюция аналитики в BI-системы и в Augmented Business Intelligence

Augmented Business Intelligence это модель партнерства людей и искусственного интеллекта, которая ориентирована на совместное взаимодействие машины и человека для улучшения аналитики, принятия решений, подготовки данных и получения инсайтов.

Рис.10. Инновационность ABI-системРис.10. Инновационность ABI-систем

ABI это новая ступень развития BI-платформ, так как в ней есть сразу несколько преимуществ. В ней объединяется не только привычная аналитика и таблицы, но и также новые технологии: от дополненной и виртуальной реальности до решений с компьютерной графикой и 3D.

Рис.11. Отличия BI-системы от ABI-системы и ее преимуществаРис.11. Отличия BI-системы от ABI-системы и ее преимущества

Становится очевидным, что BI-системы эволюционируют, они меняются вместе с обществом, наукой и человеком, и есть ряд трендов, которые свидетельствуют о движении в сторону простой, понятной, удобной и быстрой аналитики.

Рис.12. Тренды в развитии BI-системРис.12. Тренды в развитии BI-систем

Тремя основными тенденциями бизнес-аналитики на 2020 год являются управление качеством данных (MD/DQ), DataViz и внедрение self-service BI-систем, и особое место занимает внедрение data-driven подхода в культуру компаний. Мы стараемся внедрять все эти подходы в наше решение с BI-системой для Ingrad, и хотели бы побольше рассказать о самых интересных, на наш взгляд.

Развитие предиктивной аналитики

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

В этом контексте также говорят о концепции DIKW: Data-Information-Knowledge-Wisdom.

Рис.13. Концепция DIKWРис.13. Концепция DIKW

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

BI-системы в этом случае выступают инструментом достижения верхушки пирамиды благодаря визуализации мы можем быстро проанализировать любые данные и информацию для получения знаний. Чтобы получить мудрость мы должны видеть всю ситуацию в пространстве, и здесь может помочь визуализация данных (Data Visualization) и 3D-технологии.

Визуализация данных (Data Visualization, DataViz)

Наше потребление информации становится больше визуальным во всем информационном шуме мы неосознанно обращаем больше внимания на изображения и видео, иногда пролистываем большие тексты.

Рис. 14. Визуальное потребление информацииРис. 14. Визуальное потребление информации

Именно поэтому и существует визуализация данных (Data Visualization) ряд инструментов наподобие графиков, таблиц, диаграмм и схем, которые представляют информацию наглядно.

Рис.15. Инструментарий DataVizРис.15. Инструментарий DataViz

Донести информацию с помощью инфографики намного проще и быстрее, чем с помощью текста, но мы хотели бы отметить, что и здесь есть простор для развития, а именно уход в 3D.

Мы все привыкли к 2D-инфографикам, и, да, они прекрасно справляются со своей задачей, но информацию можно донести и более эффективными способами. Во многих случаях 3D-визуализации позволяют передать больше информации об объекте.

Рис.16. Преимущества 3D-визуализацииРис.16. Преимущества 3D-визуализации

Мы считаем, что 3D визуализация данных это не просто тренд, а необходимость для некоторых сфер (AEC, например). Для девелопера на рынке российской недвижимости мы разработали BI-систему аналитики с 3D визуализацией данных, которая намного более эффективна благодаря интерактивности и наглядной демонстрации данных на карте.

Рис.17. Пример 3D визуализации данных на карте для визуализации данных в проекте с IngradРис.17. Пример 3D визуализации данных на карте для визуализации данных в проекте с Ingrad

3D в BI-системах может использоваться и для визуализации объектов например, BIM-модели зданий помогают быстро получать нужную аналитику и информацию о строительном объекте.

Рис.18. Пример интерактивных BIM-моделей зданийРис.18. Пример интерактивных BIM-моделей зданий

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

Data Storytelling

Одним из главных трендов, который был выделен исследованием Dresner это data storytelling. Чтобы человек лучше запомнил и воспринял суть информации и сообщения, он должен пережить опыт. Наблюдая за развитием ситуации в реальном времени, мы невольно попадаем в раскрытие какой-либо истории.

Похожая ситуация наблюдается и с данными если мы хотим донести важные сведения, мы должны сконцентрировать все внимание пользователя на них. Именно поэтому в интерактивных презентациях и BI системах мы все чаще встречаемся с визуальными анимированными эффектами, которые фокусируют взгляд на нужной информации.

Рис. 19. Фокусирование внимания пользователя на данных с помощью анимацииРис. 19. Фокусирование внимания пользователя на данных с помощью анимации

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

Рис.20. Феномен data storytellingРис.20. Феномен data storytelling

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

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

Наш BI-инструмент ориентирован на использование руководителем компании для бизнес-аналитики, маркетингового и конкурентного анализа, на презентацию финансовой отчетности топ-менеджменту или совету директоров, и в нем мы объединили тренды и технологии.

Рис.21. Уникальные черты и roadmap разработанной кроссплатформенной BI-системы для IngradРис.21. Уникальные черты и roadmap разработанной кроссплатформенной BI-системы для Ingrad

За какими технологиями нужно следить, чтобы быть в курсе развития BI-систем?

  • Искусственный интеллект и машинное обучение для создания системы предиктивной аналитики, расшифровки данных и выявления тенденций

  • 3D-технологии для внедрения новых инструментов Data Visualization, показа большего числа данных, в том числе с привязкой к географии

  • XR для совместной работы и визуализации аналитики в интерактивном иммерсивном формате.

Заключение

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

Проследив эволюцию BI-систем, тренды и прогнозы развития, которые делают крупные исследовательские компании, выделим целый ряд трендов:

  • MD/MQ Data management

  • Внедрение data-driven культуры в работу

  • Внедрение self-service BI систем

  • Data Visualization

  • Data Storytelling

  • Развитие ABI систем

  • Аналитика в real time

  • Data warehouse modernization

  • Data governance

  • Предиктивная аналитика

  • Внедрение моделей машинного обучения

  • Cloud BI

  • Самостоятельная работа с данными

  • BI-системы для мобильных устройств

  • Добавление и совершенствование уведомлений в BI-системах

Можно сделать вывод, что общая тенденция в развитии BI-систем это уход в сторону упрощения аналитики и предоставления быстрого и полного взгляда на проблему для любого заинтересованного человека (включая тех, кто может не разбираться в аналитике).

Бизнес-аналитика становится проще и доступнее, и развитие технологий только способствует этому.

Источники
Подробнее..

Перевод 6 причин, по которым вам следовало бы отказаться от гистограмм

12.05.2021 14:11:23 | Автор: admin

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

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

И нетрудно догадаться почему. Гистограммы весьма интуитивно наглядны: любой поймет их с первого взгляда. Более того, они объективно представляют реальность, не так ли? А вот и нет.

Гистограмма может ввести в заблуждение и привести к ошибочным выводам даже на простейшем наборе данных!

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

  1. Они слишком сильно зависят от количества интервалов.

  2. Они слишком сильно зависят от максимума и минимума переменной.

  3. Они не дают возможности заметить значимые значения переменной.

  4. Они не позволяют отличить непрерывные переменные от дискретных.

  5. Они делают сравнение распределений сложным.

  6. Их построение затруднено, если в памяти находятся не все данные.

Ладно, я понял: гистограммы не идеальны. Но есть ли у меня выбор? Конечно есть!

В конце статьи я порекомендую другой график, называемый CDP, который минует эти недостатки.

Итак, что же не так с гистограммой?

1. Она слишком сильно зависит от количества интервалов.

Чтобы построить гистограмму, вы должны сначала определить количество интервалов, также называемых корзинами (bins). Для этого существует множество различных практических методов (вы можете ознакомиться с их обзором на этой странице). Но насколько критичен этот выбор? Давайте возьмем реальные данные и посмотрим, как меняется гистограмма в зависимости от количества интервалов.

Переменная представляет собой максимальную частоту сердечных сокращений (ударов в минуту), полученную у 303 людей во время некоторой физической активности (данные взяты из набора данных UCI по сердечным заболеваниям: источник).

Как изменяется гистограмма при изменении количества интервалов. [Рисунок автора]Как изменяется гистограмма при изменении количества интервалов. [Рисунок автора]

Глядя на верхний левый график (который мы получим по умолчанию в Python и R), у нас сложится впечатление хорошего распределения с одним пиком (модой). Однако если бы мы рассмотрели бы другие варианты гистограммы, мы получили бы совершенно другую картину. Разные гистограммы одних и тех же данных могут привести к противоречивым выводам.

2. Она слишком сильно зависит от максимума и минимума переменной.

Даже после того, как количество интервалов установлено, интервалы зависят от положения минимума и максимума переменной. Достаточно, чтобы один из них немного изменился, и все интервалы также изменятся. Другими словами, гистограммы не являются надежными.

Например, давайте попробуем изменить максимум переменной, не меняя количество интервалов.

Как меняется гистограмма при изменении максимального значения. [Рисунок автора]Как меняется гистограмма при изменении максимального значения. [Рисунок автора]

Отличается только одно значение, а весь график получается другим. Это нежелательное свойство, потому что нас интересует общее распределение: одно значение не должно так влиять на график!

3. Не дает возможности заметить значимые значения переменной.

Если в общем, то когда переменная содержит некоторые часто повторяющиеся значения, нам конечно нужно об этом знать. Однако гистограммы этому препятствуют, поскольку они основаны на интервалах, а интервалы скрывают отдельные значения.

Классическим примером является случай, когда отсутствующим значениям массово присваивается 0. В качестве примера давайте рассмотрим набор данных переменной, состоящий из 10 тысяч значений, 26% из которых нули.

Те же данные, разная ширина интервала. На левом графике невозможно обнаружить высокую концентрацию нулей. [Рисунок автора]Те же данные, разная ширина интервала. На левом графике невозможно обнаружить высокую концентрацию нулей. [Рисунок автора]

График слева это то, что вы получаете по умолчанию в Python. Глядя на него, вы не заметите скопление нулей, и вы даже можете подумать, что эта переменная имеет плавную динамику.

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

4. Не позволяет отличить непрерывные переменные от дискретных.

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

Возьмем переменную Возраст (Age). Вы можете получить Возраст = 49 лет (когда возраст округлен) или Возраст = 49,828884325804246 лет (когда возраст рассчитывается как количество дней с момента рождения, деленное на 365,25). Первая дискретная переменная, вторая непрерывная.

Слева непрерывная переменная. Справа дискретная переменная. Однако на верхних графиках они выглядят одинаково. [Рисунок автора]Слева непрерывная переменная. Справа дискретная переменная. Однако на верхних графиках они выглядят одинаково. [Рисунок автора]

Тот, что слева, непрерывен, а тот, что справа, дискретен. Однако на верхних графиках (по умолчанию в Python) вы не увидите никакой разницы между ними: они выглядят совершенно одинаково.

5. Сложно сравнивать распределения.

Часто бывает необходимо сравнить одну и ту же переменную в разных кластерах. Например, в отношении данных UCI о сердечных заболеваниях, приведенных выше, мы можем сравнить:

  • все население (для справки)

  • люди моложе 50 страдающие сердечными заболеваниями

  • люди моложе 50 НЕ страдающие сердечными заболеваниями

  • люди старше 60 лет страдающие сердечными заболеваниями

  • люди старше 60 и НЕ страдающие сердечными заболеваниями.

Вот что мы получили бы в итоге:

Сравнение гистограмм. [Рисунок автора]Сравнение гистограмм. [Рисунок автора]

Гистограммы основаны на областях, и, когда мы пытаемся провести сравнение, области в конечном итоге перекрываются, что делает эту задачу практически невыполнимой.

6. Сложно построить, если в памяти находятся не все данные.

Если все ваши данные находятся в Excel, R или Python, построить гистограмму легко: в Excel вам просто нужно кликнуть по иконке гистограммы, в R выполнить команду hist(x), а в Python plt.hist(х).

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

| INTERVAL_LEFT | INTERVAL_RIGHT | COUNT |

|---------------|----------------|---------------|

| 75.0 | 87.0 | 31 |

| 87.0 | 99.0 | 52 |

| 99.0 | 111.0 | 76 |

| ... | ... | ... |

Но получить ее с помощью SQL-запроса не так просто, как кажется. Например, в Google Big Query код будет выглядеть так:

WITHSTATS AS (  SELECT     COUNT(*) AS N,    APPROX_QUANTILES(VARIABLE_NAME, 4) AS QUARTILES  FROM    TABLE_NAME),BIN_WIDTH AS (  SELECT    -- freedman-diaconis formula for calculating the bin width    (QUARTILES[OFFSET(4)]  QUARTILES[OFFSET(0)]) / ROUND((QUARTILES[OFFSET(4)]  QUARTILES[OFFSET(0)]) / (2 * (QUARTILES[OFFSET(3)]  QUARTILES[OFFSET(1)]) / POW(N, 1/3)) + .5) AS FD  FROM     STATS),HIST AS (  SELECT     FLOOR((TABLE_NAME.VARIABLE_NAME  STATS.QUARTILES[OFFSET(0)]) / BIN_WIDTH.FD) AS INTERVAL_ID,    COUNT(*) AS COUNT  FROM     TABLE_NAME,    STATS,    BIN_WIDTH  GROUP BY     1)SELECT   STATS.QUARTILES[OFFSET(0)] + BIN_WIDTH.FD * HIST.INTERVAL_ID AS INTERVAL_LEFT,  STATS.QUARTILES[OFFSET(0)] + BIN_WIDTH.FD * (HIST.INTERVAL_ID + 1) AS INTERVAL_RIGHT,  HIST.COUNTFROM   HIST,   STATS,   BIN_WIDTH

Немного громоздко, не правда ли?

Альтернатива: график кумулятивного распределения.

Узнав 6 причин, по которым гистограмма не является идеальным выбором, возникает естественный вопрос: Есть ли у меня альтернатива? Хорошие новости: существует лучшая альтернатива, которая называется График кумулятивного распределения (Cumulative Distribution Plot - CDP). Я знаю, что это название не такое запоминающееся, но гарантирую, оно того стоит.

График кумулятивного распределения это график квантилей переменной. Другими словами, каждая точка CDP показывает:

  • по оси x: исходное значение переменной (как в гистограмме);

  • по оси y: сколько наблюдений имеют такое же или меньшее значение.

Давайте посмотрим на пример с переменной максимальной частотой пульса.

График кумулятивного распределения максимальной частоты сердечных сокращений. [Рисунок автора]График кумулятивного распределения максимальной частоты сердечных сокращений. [Рисунок автора]

Возьмем точку с координатами x = 140 и y = 90 (30%). По горизонтальной оси вы видите значение переменной: 140 ударов сердца в минуту. По вертикальной оси вы видите количество наблюдений, у которых частота сердцебиение равна или ниже 140 (в данном случае 90 человек, что означает 30% выборки). Следовательно, у 30% нашей выборки максимальная частота сердцебиения составляет 140 или менее ударов в минуту.

Какой смысл в графике, показывающем, сколько наблюдений равно или ниже заданного уровня? Почему не просто равно? Потому что в противном случае результат зависел бы от отдельных значений переменной. И это не сработает, потому что каждое значение имеет очень мало наблюдений (обычно только одно, если переменная непрерывна). Напротив, CDP полагаются на квантили, которые более стабильны, выразительны и легко читаются.

Вдобавок CDP намного полезнее. Если задуматься, вам часто приходится отвечать на такие вопросы, как у скольких из них от 140 до 160? Или у скольких из них больше 180?. Имея перед глазами CDP, вы можете дать немедленный ответ. С гистограммой это было бы невозможно.

CDP решает все проблемы, которые мы видели выше. Фактически, по сравнению с гистограммой:

1. Не требует пользовательского выбора. Для одного набора данных, существует только один возможный CDP.

2. Не страдает от выпадающих значений. Экстремальные значения не влияют на CDP, поскольку квантили не меняются.

3. Позволяет определять значимые значения. Если существует концентрация точек данных на каком-то конкретном значении, это сразу видно, поскольку будет вертикальный сегмент, соответствующий значению.

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

5. Упрощает сравнение распределений. На одном графике легко сравнить два или более распределения, поскольку это просто кривые, а не области. Кроме того, ось y всегда находится в диапазоне от 0 до 100%, что делает сравнение еще более простым. Для сравнения, это пример, который мы видели выше:

Сравнение распределений в CDP. [Рисунок автора]Сравнение распределений в CDP. [Рисунок автора]

6. Его легко построить, даже если у вас нет всех данных в памяти. Все, что вам нужно, это квантили, которые можно легко получить с помощью SQL:

SELECT   COUNT(*) AS N,  APPROX_QUANTILES(VARIABLE_NAME, 100) AS PERCENTILESFROM  TABLE_NAME

Как построить график кумулятивного распределения в Excel, R, Python

В Excel вам нужно построить два столбца. Первый с 101 числом, равномерно распределенными от 0 до 1. Второй столбец должен содержать процентили, которые могут быть получены по формуле: =PERCENTILE(DATA, FRAC), где DATA - это вектор, содержащий данные, а FRAC - это первый столбец: 0,00, 0,01, 0,02, 0,03,, 0,98, 0,99, 1. Затем вам просто нужно построить график по этим двум столбцам, разместив значения переменной на оси x.

В R это делается в одну строчку:

plot(ecdf(data))

В Python:

from statsmodels.distributions.empirical_distribution import ECDFimport matplotlib.pyplot as pltecdf = ECDF(data)plt.plot(ecdf.x, ecdf.y)

Спасибо за внимание! Надеюсь, эта статья оказалась для вас полезной.

Я ценю отзывы и конструктивную критику. Если вы хотите поговорить об этой статье или других связанных темах, вы можете написать мне в Linkedin.


Перевод материала подготовлен в рамках онлайн-курса "Machine Learning. Basic". Всех заинтересованных приглашаем на день открытых дверей курса, где можно будет узнать все подробности об обучении и пообщаться с преподавателем.

- Узнать подробнее о курсе "Machine Learning. Basic"

- Смотреть онлайн-встречу "День открытых дверей"

Подробнее..

Обзор основных функций Google BigQuery и примеры запросов для маркетинг-анализа

15.07.2020 16:21:33 | Автор: admin
Google BigQuery это быстрое, экономичное и масштабируемое хранилище для работы с Big Data, которое вы можете использовать, если у вас нет возможности или желания содержать собственные серверы. В нем можно писать запросы с помощью SQL-like синтаксиса, стандартных и пользовательских функций (User-defined function).

В статье я расскажу про основные функции BigQuery и покажу их возможности на конкретных примерах. Вы сможете писать базовые запросы, и опробовать их на demo данных.

Что такое SQL и какие у него диалекты


SQL (Structured Query Language) язык структурированных запросов для работы с базами данных. С его помощью можно получать, добавлять в базу и изменять большие массивы данных. Google BigQuery поддерживает два диалекта: Standard SQL и устаревший Legacy SQL.

Какой диалект выбрать, зависит от ваших предпочтений, но Google рекомендует использовать Standard SQL из-за ряда преимуществ:
  • Гибкость и функциональность при работе с вложенными и повторяющимися полями.
  • Поддержка языков DML и DDL, которые позволяют менять данные в таблицах, а также управлять таблицами и представлениями в GBQ.
  • Скорость обработки больших объемов данных выше, чем у Legasy SQL.
  • Поддержка всех текущих и будущих обновлений в BigQuery.

Подробнее о разнице между диалектами вы можете узнать в справке.

По умолчанию запросы в Google BigQuery запускаются на Legacy SQL.
Переключиться на Standard SQL можно несколькими способами:
  1. В интерфейсе BigQuery в окне редактирования запроса выберите Show Options и снимите галочку возле опции Use Legacy SQL
  2. Перед запросом добавьте строку #standardSQL и начните запрос с новой строки

С чего начать


Чтобы вы смогли потренироваться запускать запросы параллельно с чтением статьи, я подготовила для вас таблицу с demo-данными. Загрузите данные из таблицы в ваш проект Google BigQuery.

Если у вас еще нет проекта в GBQ, создайте его. Для этого понадобится активный биллинг-аккаунт в Google Cloud Platform. Понадобится привязать карту, но без вашего ведома деньги с нее списываться не будут, к тому же при регистрации вы получите 300$ на 12 месяцев, который сможете потратить на хранение и обработку данных.

Функции Google BigQuery


При построении запросов чаще всего используются следующие группы функций: Aggregate function, Date function, String function и Window function. Теперь подробнее о каждой из них.

Функции агрегирования данных (Aggregate function)


Функции агрегирования позволяют получить сводные значения по всей таблице. Например, рассчитать средний чек, суммарный доход за месяц или выделить сегмент пользователей, совершивших максимальное количество покупок.

Вот самые популярные функции из этого раздела:
Legacy SQL Standard SQL Что делает функция
AVG(field) AVG([DISTINCT] (field)) Возвращает среднее значение столбца field.В Standard SQL при добавлении условия DISTINCT среднее считается только для строк с уникальными (не повторяющимися) значениями из столбца field
MAX(field) MAX(field) Возвращает максимальное значение из столбца field
MIN(field) MIN(field) Возвращает минимальное значение из столбца field
SUM(field) SUM(field) Возвращает сумму значений из столбца field
COUNT(field) COUNT(field) Возвращает количество строк в столбце field
EXACT_COUNT_DISTINCT(field) COUNT([DISTINCT] (field)) Возвращает количество уникальных строк в столбце field

С перечнем всех функций вы можете ознакомиться в справке: Legacy SQL и Standard SQL.

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

#legasy SQL
SELECT  AVG(revenue) as average_revenue,  MAX(revenue) as max_revenue,  MIN(revenue) as min_revenue,  SUM(revenue) as whole_revenue,  COUNT(transactionId) as transactions,  EXACT_COUNT_DISTINCT(transactionId) as unique_transactionsFROM  [owox-analytics:t_kravchenko.Demo_data]

#standard SQL
SELECT  AVG(revenue) as average_revenue,  MAX(revenue) as max_revenue,  MIN(revenue) as min_revenue,  SUM(revenue) as whole_revenue,  COUNT(transactionId) as transactions,  COUNT(DISTINCT(transactionId)) as unique_transactionsFROM  `owox-analytics.t_kravchenko.Demo_data`

В итоге получаем такие результаты:

Проверить результаты расчетов вы можете в исходной таблице с demo данными, используя стандартные функции Google Sheets (SUM, AVG и другие) или сводные таблицы.

Как видим из скриншота выше, количество транзакций и уникальных транзакций отличается. Это говорит о том, что в нашей таблице есть 2 транзакции, у которых дублируется transactionId:


Поэтому, если вас интересуют именно уникальные транзакции, используйте функцию, которая считает уникальные строки. Либо вы можете сгруппировать данные с помощью выражения GROUP BY, чтобы избавиться от дублей перед тем, как применять функцию агрегации.

Функции для работы с датами (Date function)


Эти функции позволяют обрабатывать даты: менять их формат, выбирать необходимую часть (день, месяц или год), смещать дату на определенный интервал.

Они могут вам пригодится в следующих случаях:
  • При настройке сквозной аналитики чтобы привести даты и время из разных источников к единому формату.
  • При создании автоматически обновляемых отчетов или триггерных рассылок. Например, когда нужны данные за последние 2 часа, неделю или месяц.
  • При создании когортных отчетов, в которых необходимо получить данные в разрезе дней, недель, месяцев.

Функции для работы с датами, используемые чаще всего:

Legacy SQL Standard SQL Что делает функция
CURRENT_DATE() CURRENT_DATE() Возвращает текущую дату в формате %ГГГГ-%ММ-%ДД
DATE(timestamp) DATE(timestamp) Преобразует дату из формата %ГГГГ-%ММ-%ДД %Ч:%M:%С. в формат %ГГГГ-%ММ-%ДД
DATE_ADD(timestamp, interval, interval_units) DATE_ADD(timestamp, INTERVAL interval interval_units) Возвращает дату timestamp, увеличивая ее на указанный интервал interval.interval_units.
В Legacy SQL может принимать значения YEAR, MONTH, DAY, HOUR, MINUTE и SECOND, а в Standard SQL YEAR, QUARTER, MONTH, WEEK, DAY
DATE_ADD(timestamp, interval, interval_units) DATE_SUB(timestamp, INTERVAL interval interval_units) Возвращает дату timestamp, уменьшая ее на указанный интервал interval
DATEDIFF(timestamp1, timestamp2) DATE_DIFF(timestamp1, timestamp2, date_part) Возвращает разницу между двумя датами timestamp1 и timestamp2.
В Legacy SQL возвращает разницу в днях, а в Standard SQL в зависимости от указанного значения date_part (день, неделя, месяц, квартал, год)
DAY(timestamp) EXTRACT(DAY FROM timestamp) Возвращает день из даты timestamp. Принимает значения от 1 до 31 включительно
MONTH(timestamp) EXTRACT(MONTH FROM timestamp) Возвращает порядковый номер месяца из даты timestamp. Принимает значения от 1 до 12 включительно
YEAR(timestamp) EXTRACT(YEAR FROM timestamp) Возвращает год из даты timestamp

Список всех функций в справке: Legacy SQL и Standard SQL.

Рассмотрим на demo данных, как работает каждая из приведенных функций. К примеру, получим текущую дату, приведем дату из исходной таблицы в формат %ГГГГ-%ММ-%ДД, отнимем и прибавим к ней по одному дню. Затем рассчитаем разницу между текущей датой и датой из исходной таблицы и разобьем текущую дату отдельно на год, месяц и день. Для этого вы можете скопировать примеры запросов ниже и заменить в них название проекта, набора данных и таблицы с данными на свои.

#legasy SQL
SELECT    CURRENT_DATE() AS today,    DATE( date_UTC ) AS date_UTC_in_YYYYMMDD,    DATE_ADD( date_UTC,1, 'DAY') AS date_UTC_plus_one_day,    DATE_ADD( date_UTC,-1, 'DAY') AS date_UTC_minus_one_day,    DATEDIFF(CURRENT_DATE(), date_UTC ) AS difference_between_date,    DAY( CURRENT_DATE() ) AS the_day,    MONTH( CURRENT_DATE()) AS the_month,    YEAR( CURRENT_DATE()) AS the_year  FROM    [owox-analytics:t_kravchenko.Demo_data]

#standard SQL
SELECT  today,  date_UTC_in_YYYYMMDD,  DATE_ADD( date_UTC_in_YYYYMMDD, INTERVAL 1 DAY) AS date_UTC_plus_one_day,  DATE_SUB( date_UTC_in_YYYYMMDD,INTERVAL 1 DAY) AS date_UTC_minus_one_day,  DATE_DIFF(today, date_UTC_in_YYYYMMDD, DAY) AS difference_between_date,  EXTRACT(DAY FROM today ) AS the_day,  EXTRACT(MONTH FROM today ) AS the_month,  EXTRACT(YEAR FROM today ) AS the_yearFROM (  SELECT    CURRENT_DATE() AS today,    DATE( date_UTC ) AS date_UTC_in_YYYYMMDD  FROM    `owox-analytics.t_kravchenko.Demo_data`)

После применения запроса вы получите вот такой отчет:


Функции для работы со строками (String function)


Строковые функции позволяют формировать строку, выделять и заменять подстроки, рассчитывать длину строки и порядковый номер индекса подстроки в исходной строке.

Например, с их помощью можно:
  • Сделать в отчете фильтры по UTM-меткам, которые передаются в URL страницы.
  • Привести данные к единому формату, если название источников и кампании написаны в разных регистрах.
  • Заменить некорректные данные в отчете, например, если название кампании передалось с опечаткой.

Самые популярные функции для работы со строками:
Legacy SQL Standard SQL Что делает функция
CONCAT('str1', 'str2') или'str1'+ 'str2' CONCAT('str1', 'str2') Объединяет несколько строк 'str1' и 'str2' в одну
'str1' CONTAINS 'str2' REGEXP_CONTAINS('str1', 'str2') или 'str1' LIKE %str2% Возвращает true если строка 'str1' содержит строку str2.
В Standard SQL строка str2 может быть записана в виде регулярного выражения с использованием библиотеки re2
LENGTH('str' ) CHAR_LENGTH('str' )
или CHARACTER_LENGTH('str' )
Возвращает длину строки 'str' (количество символов в строке)
SUBSTR('str', index [, max_len]) SUBSTR('str', index [, max_len]) Возвращает подстроку длиной max_len, начиная с символа с индексом index из строки 'str'
LOWER('str') LOWER('str') Приводит все символы строки 'str' к нижнему регистру
UPPER(str) UPPER(str) Приводит все символы строки 'str' к верхнему регистру
INSTR('str1', 'str2') STRPOS('str1', 'str2') Возвращает индекс первого вхождения строки 'str2' в строку 'str1', иначе 0
REPLACE('str1', 'str2', 'str3') REPLACE('str1', 'str2', 'str3') Заменяет в строке 'str1' подстроку 'str2' на подстроку 'str3'

Детальнее в справке: Legacy SQL и Standard SQL.

Разберем на примере demo данных, как использовать описанные функции. Предположим, у нас есть 3 отдельных столбца, которые содержат значения дня, месяца и года:

Работать с датой в таком формате не очень удобно, поэтому объединим ее в один столбец. Чтобы сделать это, используйте SQL-запросы, приведенные ниже, и не забудьте подставить в них название своего проекта, набора данных и таблицы в Google BigQuery.

#legasy SQL
SELECT  CONCAT(the_day,'-',the_month,'-',the_year) AS mix_string1,  the_day+'-'+the_month+'-'+the_year AS mix_string2FROM (  SELECT    '31' AS the_day,    '12' AS the_month,    '2018' AS the_year  FROM    [owox-analytics:t_kravchenko.Demo_data])GROUP BY  mix_string1,  mix_string2

#standard SQL
SELECT  CONCAT(the_day,'-',the_month,'-',the_year) AS mix_string1FROM (  SELECT    '31' AS the_day,    '12' AS the_month,    '2018' AS the_year  FROM    `owox-analytics.t_kravchenko.Demo_data`)GROUP BY  mix_string1


После выполнения запроса мы получим дату в одном столбце:


Часто при загрузке определенной страницы на сайте в URL записываются значения переменных, которые выбрал пользователь. Это может быть способ оплаты или доставки, номер транзакции, индекс физического магазина, в котором покупатель хочет забрать товар и т. д. С помощью SQL-запроса можно выделить эти параметры из адреса страницы.

Рассмотрим два примера, как и зачем это делать.
Пример 1. Предположим, мы хотим узнать количество покупок, при которых пользователи забирают товар из физических магазинов. Для этого нужно посчитать количество транзакций, отправленных со страниц, в URL которых есть подстрока shop_id (индекс физического магазина). Делаем это с помощью следующих запросов:

#legasy SQL
SELECT  COUNT(transactionId) AS transactions,  checkFROM (  SELECT    transactionId,    page CONTAINS 'shop_id' AS check  FROM    [owox-analytics:t_kravchenko.Demo_data])GROUP BY  check

#standard SQL
SELECT  COUNT(transactionId) AS transactions,  check1,  check2FROM (  SELECT    transactionId,    REGEXP_CONTAINS( page, 'shop_id') AS check1,    page LIKE '%shop_id%' AS check2  FROM    `owox-analytics.t_kravchenko.Demo_data`)GROUP BY  check1,  check2

Из полученной в результате таблицы мы видим, что со страниц, содержащих shop_id, отправлено 5502 транзакции (check = true):

Пример 2. Допустим, вы присвоили каждому способу доставки свой delivery_id и прописываете значение этого параметра в URL страницы. Чтобы узнать, какой способ доставки выбрал пользователь, нужно выделить delivery_id в отдельный столбец.
Используем для этого следующие запросы:

#legasy SQL
SELECT  page_lower_case,  page_length,  index_of_delivery_id,  selected_delivery_id,  REPLACE(selected_delivery_id, 'selected_delivery_id=', '') as delivery_idFROM (  SELECT    page_lower_case,    page_length,    index_of_delivery_id,    SUBSTR(page_lower_case, index_of_delivery_id) AS selected_delivery_id  FROM (    SELECT      page_lower_case,      LENGTH(page_lower_case) AS page_length,      INSTR(page_lower_case, 'selected_delivery_id') AS index_of_delivery_id    FROM (      SELECT        LOWER( page) AS page_lower_case,        UPPER( page) AS page_upper_case      FROM        [owox-analytics:t_kravchenko.Demo_data])))ORDER BY  page_lower_case ASC

#standard SQL
SELECT  page_lower_case,  page_length,  index_of_delivery_id,  selected_delivery_id,  REPLACE(selected_delivery_id, 'selected_delivery_id=', '') AS delivery_idFROM (  SELECT    page_lower_case,    page_length,    index_of_delivery_id,    SUBSTR(page_lower_case, index_of_delivery_id) AS selected_delivery_id  FROM (    SELECT      page_lower_case,      CHAR_LENGTH(page_lower_case) AS page_length,      STRPOS(page_lower_case, 'selected_delivery_id') AS index_of_delivery_id    FROM (      SELECT        LOWER( page) AS page_lower_case,        UPPER( page) AS page_upper_case      FROM        `owox-analytics.t_kravchenko.Demo_data`)))ORDER BY  page_lower_case ASC

В результате получаем в Google BigQuery такую таблицу:


Функции для работы с подмножествами данных или оконные функции (Window function)


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

С помощью оконных функций вы можете агрегировать данные в разрезе групп, не используя оператор JOIN для объединения нескольких запросов. Например, рассчитать средний доход в разрезе рекламных кампаний, количество транзакций в разрезе устройств. Добавив еще одно поле в отчет, вы сможете легко узнать, к примеру, долю дохода от рекламной кампании на Black Friday или долю транзакций, сделанных из мобильного приложения.

Вместе с каждой функцией в запросе необходимо прописывать выражение OVER, которое определяет границы окна. OVER содержит 3 компоненты, с которыми вы можете работать:
  • PARTITION BY определяет признак, по которому вы будете делить исходные данные на подмножества, например PARTITION BY clientId, DayTime.
  • ORDER BY определяет порядок строк в подмножестве, например ORDER BY hour DESC.
  • WINDOW FRAME позволяет обрабатывать строки внутри подмножества по определенному признаку. Например, можно посчитать сумму не всех строк в окне, а только первых пяти перед текущей строкой.

В этой таблице собраны оконные функции, используемые чаще всего:
Legacy SQL Standard SQL Что делает функция
AVG(field)
COUNT(field)
COUNT(DISTINCT field)
MAX()
MIN()
SUM()
AVG([DISTINCT] (field))
COUNT(field)
COUNT([DISTINCT] (field))
MAX(field)
MIN(field)
SUM(field)
Возвращает среднее значение, количество, максимальное, минимальное и суммарное значение из столбца field в рамках выбранного подмножества.

DISTINCT используется, если нужно посчитать только уникальные (неповторяющиеся) значения
'str1' CONTAINS 'str2' REGEXP_CONTAINS('str1', 'str2') или 'str1' LIKE %str2% Возвращает true если строка 'str1' содержит строку str2.
В Standard SQL строка str2 может быть записана в виде регулярного выражения с использованием библиотеки re2
DENSE_RANK() DENSE_RANK() Возвращает номер строки в рамках подмножества
FIRST_VALUE(field) FIRST_VALUE (field[{RESPECT | IGNORE} NULLS]) Возвращает значение первой строки из столбца field в рамках подмножества.

По умолчанию строки с пустыми значениями из столбца field включаются в расчет. RESPECT или IGNORE NULLS определяет, включать или игнорировать строки со значением NULL
LAST_VALUE(field) LAST_VALUE (field [{RESPECT | IGNORE} NULLS]) Возвращает значение последней строки из столбца field в рамках подмножества.

По умолчанию строки с пустыми значениями из столбца field включаются в расчет. RESPECT или IGNORE NULLS определяет, включать или игнорировать строки со значением NULL
LAG(field) LAG (field[, offset [, default_expression]]) Возвращает значение предыдущей строки по отношению к текущей из столбца field в рамках подмножества.

Offset определяет количество строк, на которое необходимо смещаться вниз по отношению к текущей строке. Является целым числом.

Default_expression значение, которое будет возвращать функция, если в рамках подмножества нет необходимой строки
LEAD(field) LEAD (field[, offset [, default_expression]]) Возвращает значение следующей строки по отношению к текущей из столбца field в рамках подмножества.

Offset определяет количество строк, на которое необходимо смещаться вверх по отношению к текущей строке. Является целым числом.

Default_expression значение, которое будет возвращать функция, если в рамках текущего подмножества нет необходимой строки

Список всех функций вы можете посмотреть в справке для Legacy SQL и для Standard SQL: Aggregate Analytic Functions, Navigation Functions.

Пример 1. Допустим, мы хотим проанализировать активность покупателей в рабочее и нерабочее время. Для этого необходимо разделить транзакции на 2 группы и рассчитать интересующие нас метрики:
  • 1 группа покупки в рабочее время с 9:00 до 18:00 часов.
  • 2 группа покупки в нерабочее время с 00:00 до 9:00 и с 18:00 до 00:00.

Кроме рабочего и нерабочего времени, еще одним признаком для формирования окна будет clientId, то есть на каждого пользователя у нас получится по два окна:
Подмножество (окно) clientId DayTime
1 окно clientId 1 Рабочее время
2 окно clientId 2 Нерабочее время
3 окно clientId 3 Рабочее время
4 окно clientId 4 Нерабочее время
N окно clientId N Рабочее время
N+1 окно clientId N+1 Нерабочее время

Давайте на demo данных рассчитаем средний, максимальный, минимальный, и суммарный доход, количество транзакций и количество уникальных транзакций по каждому пользователю в рабочее и нерабочее время. Сделать это нам помогут запросы, приведенные ниже.

#legasy SQL
SELECT  date,  clientId,  DayTime,  avg_revenue,  max_revenue,  min_revenue,  sum_revenue,  transactions,  unique_transactionsFROM (  SELECT    date,    clientId,    DayTime,    AVG(revenue) OVER (PARTITION BY date, clientId, DayTime) AS avg_revenue,    MAX(revenue) OVER (PARTITION BY date, clientId, DayTime) AS max_revenue,    MIN(revenue) OVER (PARTITION BY date, clientId, DayTime) AS min_revenue,    SUM(revenue) OVER (PARTITION BY date, clientId, DayTime) AS sum_revenue,    COUNT(transactionId) OVER (PARTITION BY date, clientId, DayTime) AS transactions,    COUNT(DISTINCT(transactionId)) OVER (PARTITION BY date, clientId, DayTime) AS unique_transactions  FROM (    SELECT      date,      date_UTC,      clientId,      transactionId,      revenue,      page,      hour,      CASE        WHEN hour>=9 AND hour<=18 THEN 'рабочее время'        ELSE 'нерабочее время'      END AS DayTime    FROM      [owox-analytics:t_kravchenko.Demo_data]))GROUP BY  date,  clientId,  DayTime,  avg_revenue,  max_revenue,  min_revenue,  sum_revenue,  transactions,  unique_transactionsORDER BY  transactions DESC

#standard SQL
SELECT  date,  clientId,  DayTime,  avg_revenue,  max_revenue,  min_revenue,  sum_revenue,  transactions,  unique_transactionsFROM (  SELECT    date,    clientId,    DayTime,    AVG(revenue) OVER (PARTITION BY date, clientId, DayTime) AS avg_revenue,    MAX(revenue) OVER (PARTITION BY date, clientId, DayTime) AS max_revenue,    MIN(revenue) OVER (PARTITION BY date, clientId, DayTime) AS min_revenue,    SUM(revenue) OVER (PARTITION BY date, clientId, DayTime) AS sum_revenue,    COUNT(transactionId) OVER (PARTITION BY date, clientId, DayTime) AS transactions,    COUNT(DISTINCT(transactionId)) OVER (PARTITION BY date, clientId, DayTime) AS unique_transactions  FROM (    SELECT      date,      date_UTC,      clientId,      transactionId,      revenue,      page,      hour,      CASE        WHEN hour>=9 AND hour<=18 THEN 'рабочее время'        ELSE 'нерабочее время'      END AS DayTime    FROM      `owox-analytics.t_kravchenko.Demo_data`))GROUP BY  date,  clientId,  DayTime,  avg_revenue,  max_revenue,  min_revenue,  sum_revenue,  transactions,  unique_transactionsORDER BY  transactions DESC


Посмотрим, что получилось в результате, на примере одного из пользователей с clientId=102041117.1428132012. В исходной таблице по этому пользователю у нас были следующие данные:


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


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

Для этого используем следующие запросы:

#legasy SQL
SELECT  date,  clientId,  DayTime,  hour,  rank,  revenue,  lead_revenue,  lag_revenue,  first_revenue_by_hour,  last_revenue_by_hourFROM (  SELECT    date,    clientId,    DayTime,    hour,    DENSE_RANK() OVER (PARTITION BY date, clientId, DayTime ORDER BY hour) AS rank,    revenue,    LEAD( revenue, 1) OVER (PARTITION BY date, clientId, DayTime ORDER BY hour) AS lead_revenue,    LAG( revenue, 1) OVER (PARTITION BY date, clientId, DayTime ORDER BY hour) AS lag_revenue,    FIRST_VALUE(revenue) OVER (PARTITION BY date, clientId, DayTime ORDER BY hour) AS first_revenue_by_hour,    LAST_VALUE(revenue) OVER (PARTITION BY date, clientId, DayTime ORDER BY hour) AS last_revenue_by_hour  FROM (    SELECT      date,      date_UTC,      clientId,      transactionId,      revenue,      page,      hour,      CASE        WHEN hour>=9 AND hour<=18 THEN 'рабочее время'        ELSE 'нерабочее время'      END AS DayTime    FROM      [owox-analytics:t_kravchenko.Demo_data]))GROUP BY  date,  clientId,  DayTime,  hour,  rank,  revenue,  lead_revenue,  lag_revenue,  first_revenue_by_hour,  last_revenue_by_hourORDER BY  date,  clientId,  DayTime,  hour,  rank,  revenue,  lead_revenue,  lag_revenue,  first_revenue_by_hour,  last_revenue_by_hour

#standard SQL
SELECT  date,  clientId,  DayTime,  hour,  rank,  revenue,  lead_revenue,  lag_revenue,  first_revenue_by_hour,  last_revenue_by_hourFROM (  SELECT    date,    clientId,    DayTime,    hour,    DENSE_RANK() OVER (PARTITION BY date, clientId, DayTime ORDER BY hour) AS rank,    revenue,    LEAD( revenue, 1) OVER (PARTITION BY date, clientId, DayTime ORDER BY hour) AS lead_revenue,    LAG( revenue, 1) OVER (PARTITION BY date, clientId, DayTime ORDER BY hour) AS lag_revenue,    FIRST_VALUE(revenue) OVER (PARTITION BY date, clientId, DayTime ORDER BY hour) AS first_revenue_by_hour,    LAST_VALUE(revenue) OVER (PARTITION BY date, clientId, DayTime ORDER BY hour) AS last_revenue_by_hour  FROM (    SELECT      date,      date_UTC,      clientId,      transactionId,      revenue,      page,      hour,      CASE        WHEN hour>=9 AND hour<=18 THEN 'рабочее время'        ELSE 'нерабочее время'      END AS DayTime    FROM      `owox-analytics.t_kravchenko.Demo_data`))GROUP BY  date,  clientId,  DayTime,  hour,  rank,  revenue,  lead_revenue,  lag_revenue,  first_revenue_by_hour,  last_revenue_by_hourORDER BY  date,  clientId,  DayTime,  hour,  rank,  revenue,  lead_revenue,  lag_revenue,  first_revenue_by_hour,  last_revenue_by_hour

Результаты расчетов проверим на примере уже знакомого нам пользователя с clientId=102041117.1428132012:


Из скриншота выше мы видим, что:
  • Первая транзакция была в 15:00, а вторая в 16:00.
  • После текущей транзакции в 15:00 была транзакция в 16:00, доход которой равен 25066 (столбец lead_revenue).
  • Перед текущей транзакцией в 16:00 была транзакция в 15:00, доход которой равен 3699 (столбец lag_revenue).
  • Первой в рамках окна была транзакция в 15:00, доход по которой равен 3699 (столбец first_revenue_by_hour).
  • Запрос обрабатывает данные построчно, поэтому для рассматриваемой транзакции последней в окне будет она сама и значения в столбцах last_revenue_by_hour и revenue будут совпадать.


Выводы


В этой статье мы рассмотрели самые популярные функции из разделов Aggregate function, Date function, String function, Window function. Однако в Google BigQuery есть еще много полезных функций, например:
  • Casting functions позволяют приводить данные к определенному формату.
  • Table wildcard functions позволяют обращаться к нескольким таблицам из набора данных.
  • Regular expression functions позволяют описывать модель поискового запроса, а не его точное значение.

Пишите в комментариях, есть ли смысл писать так же подробно и о них.
Подробнее..

Кондиционер или вентилятор? Анализируем жаркие продажи на маркетплейсах

20.05.2021 14:22:33 | Автор: admin

В России аномально жаркая весна. Вы же на забыли, что на дворе все еще последний весенний месяц? Это, самой собой, должно было вызвать ажиотажный спрос на сезонные летние товары - товары для отдыха, дачи и позиции, которые помогают пережить майский зной.

И вот, вчера, аналитики AliExpress Россия подтвердили это предположение. За май спрос на вентиляторы и кондиционеры на площадке вырос в 1,5 и 2 раза по сравнению с этим же периодом 2020 года. Мы посмотрим на мнение экспертов и проанализируем продажи на других отечественных маркетплейсах, чтобы узнать какая климатическая техника и товары в почете у россиян. Заодно выясним, чем в народе спасаются от жары - вентиляторами, кондиционерами или чем-то более инновационным?

Али дует, али кроет

У экспертов AliExpress Россия уже все подсчитано. Лидером продаж среди вентиляторов на площадке стали USB-вентиляторы. Не гиганты, занимающие половину квартиры, а компактные модели с низким уровнем шума. Средняя цена такого устройства - 899 рублей.

С кондиционерами все примерно также. Россияне чаще выбирают на маркетплейсе не громоздкие сплит-системы, а компактные модели с водяной системой охлаждения. Устройства с USB привлекают внимание покупателей больше других, а стоят в среднем 970 рублей.

Озонируем воздух

Взглянем на те же категории товаров с позиции маркетплейса Ozon. Правда ли именно эти товары популярны среди россиян или среди климатической техники встречаются и другие герои? С помощью сервиса аналитики SellerFox смотрим на объемы продаж и выручки за последние 30 дней года. Первым делом идем в категорию "Климатическая техника".

Данные объема продаж, выручки и средней цены продажи товаров категории "Климатическая техника" маркетплейса Ozon, период с 19.04 - 19.05.21, данные сервиса аналитики маркетплейсов SelerFoxДанные объема продаж, выручки и средней цены продажи товаров категории "Климатическая техника" маркетплейса Ozon, период с 19.04 - 19.05.21, данные сервиса аналитики маркетплейсов SelerFox

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

Анализ категории Климатическая техника маркетплейса Ozon, период с 19.04 - 19.05.2021, данные сервиса аналитики SellerFoxАнализ категории Климатическая техника маркетплейса Ozon, период с 19.04 - 19.05.2021, данные сервиса аналитики SellerFox

В битве кондиционеров и вентиляторов побеждили увлажнители воздуха. В топе популярных товаров по количеству заказов, вся первая пятерка состоит из этого оборудования. Стоимость лидеров колеблется от 1 000 до 10 000 рублей. У топа продаж за 30 дней сразу 534 заказа и 343 138 рублей выручки.

Модель, стоимостью около 10 000 рублей, заказывали чуть реже, но за счет высокой стоимости товара, выручка продавца достигла значения в 2689272рублей. Это суммарный показатель по итогам 266 заказов.

Первый вентилятор, который встречается в топе вовсе не похож на привычное всем устройство - в лидеры выбилась встраиваемая вытяжная модель. Средняя стоимость ее продажи 3 260 рублей. Товар заказали за месяц 236 раз, что принесло продавцу общую выручку в 769 000 рублей. Что

Анализ категории Климатическая техника маркетплейса Ozon, период с 19.04 - 19.05.2021, данные сервиса аналитики SellerFoxАнализ категории Климатическая техника маркетплейса Ozon, период с 19.04 - 19.05.2021, данные сервиса аналитики SellerFox

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

Маркет жарких цен

На Яндекс.Маркет ситуация вообще странная. Спрос на климатическую технику с приходом мая сначала восстановил апрельские значения и подрос, а после праздников свалился вниз.

Данные по объему продаж, выручке и средней стоимость продажи товаров категории Климатическая техника маркетплейса Яндекс.Маркет, период с 19.04 - 19.05.2021, данные сервиса аналитики SellerFoxДанные по объему продаж, выручке и средней стоимость продажи товаров категории Климатическая техника маркетплейса Яндекс.Маркет, период с 19.04 - 19.05.2021, данные сервиса аналитики SellerFox

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

Анализ категории Климатическая техника маркетплейса Яндекс.Маркет, период с 19.04 - 19.05.2021, данные сервиса аналитики SellerFoxАнализ категории Климатическая техника маркетплейса Яндекс.Маркет, период с 19.04 - 19.05.2021, данные сервиса аналитики SellerFoxАнализ категории Климатическая техника маркетплейса Яндекс.Маркет, период с 19.04 - 19.05.2021, данные сервиса аналитики SellerFoxАнализ категории Климатическая техника маркетплейса Яндекс.Маркет, период с 19.04 - 19.05.2021, данные сервиса аналитики SellerFox

У лидера по объему продаж - метеостанции Xiaomi всего 60 заказов и 23 100 рубле месячной выручки. Впрочем, кондиционеры на Яндекс.Маркет тоже заказывают. Все они стали лидерами по объему принесенной выручки, но лишь за счет свой высокой стоимости. Продажи устройств измеряются даже не десятками, а штуками.

Анализ категории Климатическая техника маркетплейса Яндекс.Маркет, период с 19.04 - 19.05.2021, данные сервиса аналитики SellerFoxАнализ категории Климатическая техника маркетплейса Яндекс.Маркет, период с 19.04 - 19.05.2021, данные сервиса аналитики SellerFox

Если же загадывать "что раньше?" - "курица или яйцо",то тут вопрос решается просто. Кондиционеры среди пользователей Яндекс.Маркета популярнее. Хотя популярность эта крайне надуманная.

Анализ категории Климатическая техника маркетплейса Яндекс,Маркет, период с 19.04 - 19.05.2021, данные сервиса аналитики SellerFoxАнализ категории Климатическая техника маркетплейса Яндекс,Маркет, период с 19.04 - 19.05.2021, данные сервиса аналитики SellerFox

Ультрафиолетовые продажи

Приближаемся к витринам Wildberries. Что видим? Продажи климатической техники здесь всегда стабильно высокие. Они проседали в первые дни мая, но сейчас вновь набрали обороты.

Данные по объему продаж, выручке и средней стоимость продажи товаров категории Климатическая техника маркетплейса Wildberries, период с 19.04 - 19.05.2021, данные сервиса аналитики SellerFoxДанные по объему продаж, выручке и средней стоимость продажи товаров категории Климатическая техника маркетплейса Wildberries, период с 19.04 - 19.05.2021, данные сервиса аналитики SellerFox

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

Анализ категории Климатическая техника маркетплейса Wildberries, период с 19.04 - 19.05.2021, данные сервиса аналитики SellerFoxАнализ категории Климатическая техника маркетплейса Wildberries, период с 19.04 - 19.05.2021, данные сервиса аналитики SellerFoxАнализ категории Климатическая техника маркетплейса Wildberries, период с 19.04 - 19.05.2021, данные сервиса аналитики SellerFoxАнализ категории Климатическая техника маркетплейса Wildberries, период с 19.04 - 19.05.2021, данные сервиса аналитики SellerFoxАнализ категории Климатическая техника маркетплейса Wildberries, период с 19.04 - 19.05.2021, данные сервиса аналитики SellerFoxАнализ категории Климатическая техника маркетплейса Wildberries, период с 19.04 - 19.05.2021, данные сервиса аналитики SellerFox

У лидера продаж - ультразвукового увлажнителя - по итогам месяца 642 заказа и 1 686 811 рублей выручки. За ним стройной колонной выстроилась техника всех мастей: погодная станция с 515 заказами и выручкой в 142 129 рублей, тепловентилятор с 293 заказами и 252 240 рублями в копилке. А дальше, смотрите сами, весь свет и цвет увлажнителей воздуха. У ближайшего кондиционера, попавшего на первую страницу аналитической выдачи 141 328 рублей выручки и 120 заказов. Он, как и прописал AliExpress - компактный и водяной.

Ни холодно ни жарко

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

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

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

Подробнее..

Сколько зарабатывает Аналитик данных обзор зарплат и вакансий в России и за рубежом в 2020

25.09.2020 20:20:19 | Автор: admin

Привет, Хабр! 28 сентября, Skillfactory запускает новый поток курса Data Analyst, поэтому мы решили сделать широкий обзор рынка вакансий, которые предлагают сегодня компании.

Действительно ли профессия аналитика данных может приносить до 300к/наносек? Какие умения требуют работодатели от аналитиков и что вообще нужно знать, чтобы стать востребованным и высокооплачиваемым спецом? Какие возможности для роста предлагает рынок сегодня?

Мы проанализировали 450 вакансий на должность аналитика данных в России и за рубежом и собрали результаты в этой статье.

Кто такой аналитик данных и что он должен знать


Прежде чем анализировать вакансии, разберемся, что делает Data Analyst в компании. В IT-сфере есть три направления специальностей по работе с данными: Data Analyst, Data Engineer и Data Scientist.

Data Analyst собирает информацию, обрабатывает ее и интерпретирует ее на человеческий язык. По сути, он переводит статистику и big data в понятные и наглядные выводы, которые можно использовать для развития конкретного проекта или бизнеса в целом.

Результат работы аналитика данных это основа для принятия любых бизнес-решений.

Data Engineer работает больше не с самими данными, а с их инфраструктурой: базами данных, хранилищами и системами обработки. Инженер данных определяет, как анализировать данные, чтобы они были полезными для проекта. Если обобщить, то Data Engineer налаживает конвейер обработки данных.

Data Scientist занимается стратегической работой с информацией. Именно он создает системы прогнозирования, моделирования и динамического анализа, внедряет алгоритмы автоматизации и обучения.

Главная сложность в том, что границы между этими тремя специальностями довольно размыты. Большинство компаний не видят разницы, поэтому часто в вакансиях Data Analyst встречаются требования, которые больше подходят специалистам Data Engineer или Data Scientist.

В основном это обусловлено спецификой рынка. Если в IT-компаниях знают, что Data Analyst, Data Engineer и Data Scientist это в идеале три разных специалиста или даже три разных подразделения, то в продуктовых компаниях и производствах часто об этом даже не задумываются.

Что требуют работодатели от аналитика данных


Мы проанализировали свыше 450 вакансий на позицию аналитика данных, открытых в августе-сентябре 2020 года.

Во многих случаях требования к специалистам очень отличаются. Как мы писали выше, границы между Data Analyst, Data Engineer и Data Scientist стерты, поэтому часто бывает, что в заголовке вакансии пишут Аналитик данных, а фактически вакансия полностью соответствует Инженеру данных.

Но мы смогли выделить набор хард и софт скилов, которые работодатели указывают в большинстве вакансий на должность аналитика данных.

Хард скилы


Python с библиотеками для анализа данных Pandas и NumPy. Это мастхэв, его знание хотя бы на базовом уровне требуют 83% компаний в отрасли. Знание R, JavaScript и других ЯП требуют нужны всего лишь 17% работодателям.

Интересно, что в 2013 году по результатам опроса Data Analyst и Data Scientist язык R в аналитике данных был куда популярнее его использовали 61% специалистов.

SQL практически во всех вакансиях требуется знание SQL и навыки работы с реляционными базами данных. Чаще всего требуют умение писать запросы и оптимизировать их.

Навыки работы с NoSQL системами управления базами данных вроде MongoDB, CouchDB или Apache Cassandra работодатели требуют довольно редко примерно в 9% вакансий.

Power BI, Qlik, Tableau. Большинство компаний не требует знаний какой-нибудь конкретной программы визуализации данных. Обычно они указывают одну из трех на выбор или пишут системы визуализации данных без указания конкретной.

В целом специалисты могут сами выбирать, что именно им удобнее использовать. Принципиальной позиции у абсолютного большинства работодателей нет.

Опыт работы с Agile, Scrum, Kanban. Почти в половине вакансий работодатели указывают, что дополнительным плюсом будет умение соискателя работать с гибкими методологиями создания продуктов.

То есть, важно не только то, что делает аналитик данных в рамках своей специальности, но и то, как он это делает.

Но несмотря на то что многие указывают это в вакансии, ключевым требованием опыт работы с Agile не является. Да, соискателю придется потратить время, чтобы привыкнуть работать в таком формате, но, по мнению компаний, это не критично.

Excel и Google Sheets. Как ни странно, но в трети вакансий требуется знание электронных таблиц. В основном это нужно продуктовым и консалтинговым компаниям, которые довольно слабо пересекаются с диджитал-разработкой, или же относительно небольшим проектам, где весь отдел аналитики состоит из нескольких человек.

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

Многие компании отдельно выделяют высокий уровень математической подготовки. Но здесь нужно понимать, что Data Analyst, в отличие от Data Scientist, использует довольно ограниченные математические инструменты, поэтому не нужно быть гением математики. Большинство задач аналитика данных вписываются в рамки базовых знаний статистики, теории вероятностей, математического анализа и линейной алгебры.

Высшее образование в области математики пригодится, но при должном усердии все необходимые функции можно изучить и самому. Но для Data Scientist глубокое знание математики уже считается критичным. Если вы планируете расти из Data Analyst в Data Scientist, то математику нужно будет подтянуть.

По основным хард скилам это все. Остальные встречаются реже, чем в 10% вакансий, поэтому их можно списать на индивидуальные особенности работы в отдельных компаниях.

Софт скиллы


В целом они практически совпадают для всех специальностей, которые работают с данными:

  • Критическое мышление
  • Аналитический склад ума
  • Умение правильно излагать и доносить информацию
  • Ответственность и внимание к деталям
  • Бизнес-мышление
  • Готовность принимать решения и брать ответственность за результат
  • Многозадачность
  • Чувство юмора

Интересно то, что многие считают профессию аналитика данных малообщительной. Аналитик кажется нердом, который работает только с цифрами, а не с людьми.

На самом деле, все немного иначе. Аналитик данных действительно много времени проводит над анализом, но ему также важно уметь донести выводы руководителям компании или отдела. Навыки выступления перед публикой и грамотного подбора аргументации очень пригодятся. Ведь от того, насколько правильно ЛПРы поймут результаты аналитики, будут зависеть их дальнейшие действия в развитии компании или конкретного проекта.

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

Обязательный английский часто приятно отражается на зарплате. Вакансии, которые предлагают работу на международных проектах, гарантируют денежную компенсацию в 1,3-2 раза больше, чем русскоязычные.

Зарплата и другие плюшки для аналитика данных


Теперь перейдем к самому интересному к зарплате. Мы проанализировали открытые вакансии на сайтах HH.ru и Хабр Карьера.

Больше всего вакансий для аналитиков данных по состоянию на 12.09.2020 открыто в Москве (241) и в Санкт-Петербурге (74). Для сравнения, во всей остальной России актуально всего 99 вакансий на эту должность.

Интересно, что только 20% компаний указывают уровень заработной платы в самом объявлении. Остальные 80% предпочитают обсуждать денежное вознаграждение в личной беседе с соискателем.

Разброс зарплат довольно большой. Зависит он не только от опыта соискателя, но и от географии. К примеру, аналитик-стажер в Перми получает 25 000 рублей, а Data Analyst в московском офисе международной компании зарабатывает 200 000 рублей.

В Москве средняя зарплата аналитика данных составляет 134 000 рублей. На нее вполне может рассчитывать хороший специалист с опытом от 2 лет.

Стажеры и Junior-спецы получают от 60 000 рублей. Есть небольшое количество вакансий, которые предлагают ниже этой суммы (8%), но они в основном предлагают работу не на полный день либо с ограниченной загрузкой в неделю.



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

Руководители отделов аналитики и Senior-спецы могут рассчитывать на зарплату от 170 000 рублей. Есть даже вакансии, которые предлагают больше 250 000 рублей в месяц. Да, для них требуется опыт больше 5 лет в аналитике и большой пул компетенций, но такие вакансии есть. Так что вполне ясно, куда можно расти.

В качестве дополнительных плюшек и мотиваторов часто указывают возможность корпоративного обучения, медицинскую страховку и даже корпоративные пенсионные программы. Некоторые компании предлагают релокацию в Европу или США после определенного количества лет, проработанных в компании.

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

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

Аналитики данных востребованы в любом крупном и среднем бизнесе, особенно в тех проектах, которые относятся к диджитал и IT. Финтех-банки, диджитал-агентства, продуктовые компании, которые налаживают онлайн-систему продаж, консалтинговые проекты.

Среди вакансий есть представители бизнеса практически всех сфер: от медицины до тяжелой промышленности. Так что профессия очень востребованная.

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

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

Максимальная зарплата аналитика данных, на которую может рассчитывать специалист в регионах, 100 000 рублей. Но чтобы получать больше, необязательно переезжать в Москву. Можно без особых проблем найти удаленные вакансии формально работать в столице, а жить в родном городе. Многие компании идут навстречу соискателю, в котором заинтересованы.

Мы также провели сравнительный анализ вакансий из Украины и Беларуси.

Средняя зарплата аналитика данных в Украине порядка 20 000 гривен (53 000 рублей). В столице есть вакансии с оплатой в 2-2,5 раза выше, но их выставляют преимущественно международные компании с филиалами в Киеве.

Абсолютно та же ситуация и в Беларуси. Средние размер заработной платы аналитика данных составляет 2800 белорусских рублей (81 000 рублей), Но разброс зарплат очень большой. В Гомеле, к примеру, аналитик с опытом от года получает в среднем 1100 белорусских рублей (31 000 российских рублей), а в Минске специалист может зарабатывать вплоть до 10 000 (287 000 российских рублей).

Откуда прийти в профессию и куда расти аналитику данных


Есть мнение, что попасть в касту аналитиков можно только с исключительными знаниями математики. Но это не так.

В аналитику обычно уходят Junior- и Middle-разработчики на Python. Если вдобавок есть базовые знания SQL вообще отлично. В таком случае разобраться со всеми особенностями работы будет намного проще.

Также можно начать карьеру непосредственно с аналитика. Выбирайте один из десятков доступных курсов и вперед. Высшую математику знать необязательно. Для Data Analyst уровня Junior и Middle нужно только знание инструментов работы с данными. А в большинстве случаев хватит и школьных знаний математики.

Возможностей роста для специалиста аналитики данных тоже хватает. Три самых очевидных: Data Mining Specialist, Data Engineer, Data Scientist. Первый работает непосредственно с поиском данных для аналитики, второй разрабатывает инфраструктуры данных, а третий прогнозированием и стратегией.

Еще один возможный вариант BI-аналитика. Визуализация данных аналитики это отдельный скил, и многие крупные компании ценят сотрудников, которые умеют не только анализировать информацию, но и доходчиво предоставить выводы руководству.

Специально для материала, мы попросили дать комментарий о необходимых навыках для роста в BI-аналитике,Александра Царёва, основателя компании SmartDataLab, лидера образовательного курса BI SkillFactory и Сергея Земскова руководителя направления Power BI/DWH SmartDataLab и преподавателя Bootcamp SkillFactory.

В обзоре указаны мастхэв компетенции, но если вы хотите и дальше расти как Аналитик данных, вам понадобится быть в курсе ETL и изучить:
Так называемый золотой треугольник Microsoft: SSRS, SSIS, SSAS;
Иметь представление о других промышленных ETL, например, KNIME;
Литературу по архитектуре данных, например, книгу Билла Инмона Методология Кимбалла;
Также нужно хотя бы в первом приближении понимать, что такое Informatica, GreenPlum, Pentaho, чем они друг от друга отличаются и как работают.
Быть в курсе, что такое SAP Web Analytics и другие новые BI решения от SAP, хотя сейчас отмечается переход с этих решений на Power BI (который, по исследованию проведенному в июле-августе телеграм каналом вакансий и фриланса в BI/DWH BI HeadHunter, в топе по запросу от работодателей).

Это солидный пласт знаний, но он сделает вас уберспецом.

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

Не путайте бизнес-аналитика с системным аналитиком. Бизнес-аналитик проводит анализ данных и интерпретирует их, с точки зрения бизнеса то есть, показывает, где и как компания может больше заработать, где теряются деньги и клиенты. Его работа направлена, чтобы увеличить прибыль и сократить потери. Системный аналитик же работает с организацией рабочего процесса и постановкой задач. Его работа сделать, чтобы команда работала более эффективно и результативно.

В вакансиях на сайтах работы часто смешивают понятия. Даже встречаются предложения вроде Бизнес/системный аналитик. Не надо так. Это два разных направления.

Также аналитику данных можно уйти полностью в разработку на Python, но этот вариант выбирает сравнительно небольшое количество специалистов.

Аналитик данных это перспективная и востребованная профессия. И чтобы стать Data Analyst, не нужно быть Перельманом и уметь решать теорему Пуанкаре хватит школьных знаний математики и упорства в освоении инструментов аналитика.

Совсем недавно мы запустили первый в России Онлайн-буткемп по Data Analytics, включающий в себя 5 недель обучения, 5 проектов в портфолио, оплачиваемая стажировка для лучшего выпускника. Это суперинтенсивный формат для самых целеустремленных: учиться нужно фултайм. Зато в итоге выход на работу уже через 13 месяца.

image

Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя онлайн-курсы SkillFactory:



Подробнее..

Data Analyst или Data Scientist кем бы вам хотелось быть?

10.07.2020 16:05:35 | Автор: admin
Каково находиться в каждой из этих ролей, рассказывает Matt Przybyla, автор статьи, опубликованной в блоге towardsdatascience.com. Предлагаем вам ее перевод.


Фото с сайта Unsplash. Автор: Christina @ wocintechchat.com

Мне довелось поработать и профессиональным аналитиком данных (Data Analyst), и исследователем данных (Data Scientist). Думаю, было бы полезно поделиться опытом по каждой должности, указывая ключевые различия в повседневных задачах. Я надеюсь, что моя статья поможет определиться, что подходит именно вам. А тем, кто уже работает, возможно, после прочтения захочется изменить свою должность. Некоторые начинают аналитиками данных, а затем переходят в исследователи. Не так популярен, но не менее интересен путь от исследователя на невысоких позициях до аналитика на позиции сеньора. Обе должности имеют свои особенности и требуют определенных умений, о которых необходимо знать, прежде чем сделать следующий большой шаг в профессиональном развитии.

Ниже я, опираясь на свой опыт, расскажу, что такое быть аналитиком данных и исследователем данных, и подробно отвечу на наиболее частые вопросы о каждой позиции.

Data Analyst


Если вы хотите описывать данные за прошедший период или текущий момент и презентовать стейкхолдерам ключевые результаты поиска, полную визуализацию изменений и тенденций, значит, вам подходит позиция аналитика данных. У упомянутых должностей есть общие черты, которые я описывал в другой статье, охватывающей сходства и различия между необходимыми для этих позиций навыками. Сейчас же я хочу показать, как роль аналитика данных в сравнении с ролью исследователя данных ощущается. Очень важно понимать, чего ждать этим специалистам в их повседневной работе. Аналитик будет взаимодействовать с разными людьми, много общаться и поддерживать высокий темп выполнения задач выше, чем требуется от исследователя данных.

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

Ниже вы найдете ответы на самые частые вопросы о том, с чем сталкиваются аналитики данных.

  • С кем придется работать?

В основном со стейкхолдерами компании, которые запрашивают обобщение данных, визуализацию выводов и отчеты по результатам. Общение, как правило, устное или через цифровые каналы: электронную почту, Slack и Jira. По моему опыту, вам предстоит тесно взаимодействовать с человеческой и аналитической составляющими бизнеса, а не инженерной и производственной.

  • Кому предоставляются результаты?

Вероятнее всего, вышеупомянутым стейкхолдерам. Однако если у вас есть менеджер, вы отчитываетесь перед ним, а он уже передает данные стейкхолдерам. Не исключен и вариант, когда вы собираете пул запросов, составляете по ним отчет и презентуете стейкхолдерам. Для составления отчетов у вас могут быть такие инструменты, как Tableau, Google Data Studio, Power BI и Salesforce, которые обеспечивают легкий доступ к данным, например к файлам CSV. Другие инструменты требуют больше технических усилий составления расширенных запросов к базам данных с помощью SQL.

  • Какими будут темпы работы над проектом?

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

Data Scientist


Исследователи данных довольно сильно отличаются от аналитиков данных. Они могут использовать одинаковые инструменты и языки, но исследователю приходится работать с другими людьми, над более крупными проектами (такими как создание и внедрение модели машинного обучения) и тратить на это больше времени. Аналитики данных обычно работают над своими проектами самостоятельно: например, использовать панель Tableau для презентации результатов может и один человек. Исследователи данных вправе привлекать нескольких инженеров и менеджеров по продукту для эффективного выполнения бизнес-задач с использованием правильных инструментов и качественных решений.

  • С кем придется работать?

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

  • Кому предоставляются результаты?

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

  • Какими будут темпы работы над проектом?

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

Заключение



Фото с сайта Unsplash. Автор: Markus Winkler

Аналитики и исследователи данных пользуются одинаковыми инструментами, такими как Tableau, SQL и даже Python, но профессиональные задачи у них могут быть очень разными. Повседневная деятельность аналитика данных включает больше собраний и личного взаимодействия, требует прокачанных софт-скиллов и быстрого выполнения проектов. Работа исследователя предполагает более долгие процессы, общение с инженерами и менеджерами по продуктам, а также построение прогностических моделей, осмысляющих новые данные или явления в их развитии, тогда как аналитики фокусируются на прошлом и текущем состоянии.

Надеюсь, статья была интересной и полезной. Спасибо за внимание!
Подробнее..

Перевод Бизнес-аналитика в управлении рисками Некоторые последние достижения (2014 год)

24.04.2021 16:07:19 | Автор: admin

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

Я не согласился с этим высказыванием так как, на мой взгляд, менеджмент создает систему метрик бизнес-аналитики с целью видеть векторы развития предприятия и скрытые проблемы, приводящие к снижению итоговых результатов. И если с помощью метрик вектора развития сложно конкретизировать, то кризисные явления идентифицируются достаточно надежно, при качественном исследовании исторических данных. То есть проявляется явная функция пространства метрик, показывающая зоны, в которые предприятию предпочтительно не попадать и система бизнес-метрик является инструментом риск-менеджмента. В настоящий момент технологии монетизации мероприятий риск-менеджмента хорошо отлажены. Так же ресурс Reports and Data прогнозирует объем рынка анализа рисков к 2026 в объеме 65 млрд. долл.

Посерфил обнаружил в сети, что существует всего лишь один университет, у которого есть программа обучения по данному курсу в The Hong Kong University of Science and Technology и нижепредставленную статью. После таких результатов мне стало ясно, что тема исследована слабо и причина в том, что риск-менеджмент отдельное направление с достаточно широким диапазоном и риски в операционной деятельности предприятия - подраздел этих мероприятий.

Чтобы читатель мог представить широту задач даю ссылку на статью об инструментах в этой области The 19 Best Risk Management Software of 2021.

После переведенной статьи изложил свои размышления о том, как сделать набор бизнес-метрик инструментом риск-менеджмента.

Business intelligence in risk management: Some recent progresses (2014 год)

Предисловие

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

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

1. Введение

Мы очень рады видеть завершение этого специального выпуска по информационным наукам: Бизнес-аналитика в управлении рисками. Риски существуют во всех аспектах нашей жизни и могут означать разные вещи для разных людей, хотя в негативном плане они всегда в целом причиняют большой потенциальный ущерб и неудобства для заинтересованных сторон. Например, недавние риски стихийных бедствий включают террористические акты, приведшие к отравлению газом в японском метро, терракту 11 сентября 2001 г., взрывам транспортных систем Испании и Великобритании, а также вирус атипичной пневмонии, нарушающий общественную и деловую деятельность, в частности в Азии.

Совсем недавно вирус H1N1 обострил осведомленность о системе реагирования во всем мире, а глобальный финансовый кризис привел к рецессии во всех аспектах экономики (59).

Для управления рисками, с которыми сталкивается организация, требуются комплексные подходы, и иногда эффективные стратегии принятия рисков могут включать в себя новые бизнес-концепции, такие как управление корпоративными рисками. Большинство инструментов бизнес-аналитики использовалось для улучшения управления рисками, и инструменты управления рисками выигрывают от подходов бизнес-аналитики. Например, модели искусственного интеллекта, такие как нейронные сети и метод опорных векторов, широко используются для создания системы предварительного предупреждения, для мониторинга финансового состояния компании (38, 2, 36). Агентно-ориентированные теории используются в управлении рисками цепочки поставок (27, 34). Модели бизнес-аналитики также полезны для хеджирования финансовых рисков путем включения рыночных рисков, кредитных рисков и операционных рисков (59). Исследование инструментов бизнес-аналитики в области управления рисками полезно как практикам, так и академическим исследователям.

В этом выпуске мы представляем статьи, посвященные последним достижениям в использовании бизнес-аналитики для управления.

2. Риски и управление рисками

Все человеческие усилия связаны с неопределенностью и риском. В области производства продуктов питания наука добилась больших успехов в генетическом управлении. Но есть опасения по поводу некоторых манипуляций, связанных с различными взглядами, преобладающими во все мире. В Соединенных Штатах генетическое управление обычно рассматривается как способ получения качественных и продуктивных источников пищи более надежным способом. Тем не менее, существуют серьезные возражения против биоинженерных продуктов питания в Европе и Азии. Появились некоторые естественные болезни, например, коровье бешенство, с которыми очень трудно бороться. Степень достигнутого контроля часто оспаривается. В Европе существует строгий контроль над биоинженерией, но даже тогда произошел скандал по свиноводству, связанный с опасными кормами и запрещенными лекарствами (57). Риски, связанные с биоинженерией, являются важными факторами в пищевой цепочке (50, 14). Генетическое картирование предлагает огромный прорыв в мире науки, но сопряжено с политическими рисками в применении к управлению человеческими ресурсами (37).

Даже применение информационных технологий для лучшего управления рисками в оказании медицинской помощи сопряжено с рисками (54). Использование компьютерного управления применялось к летающим самолетам, но не всегда работало (13). Риски можно рассматривать как угрозы, но бизнес существует, чтобы справляться с рисками (45). В разных дисциплинах используются разные способы классификации рисков. Чтобы объяснить уроки управления рисками из кредитного кризиса, Jorion (26) классифицировал риски на: известные - известные, известные - неизвестные и неизвестные - неизвестные. Фактически это основано на степени риска и аналогично тому, что обсуждали Olson and Wu (45).

Мы предлагаем следующую общую классификацию рисков: отраслевые и качественные.

- Финансовые риски отраслевого кластера, в основном включают в себя всевозможные риски, связанные с финансовыми секторами и финансовыми аспектами в других секторах. Они включают, но не ограничивают рыночный риск, кредитный риск, операционный риск и риск ликвидности. Нефинансовые риски, включающие риски из источников, не связанных с финансами. К ним относятся, но не ограничиваются ими, политические риски, репетиционные риски, биоинженерные риски и риски стихийных бедствий.

- Качественные риски могут иметь четыре свойства: неопределенность, динамика, взаимосвязь и зависимость, а также сложность. Первые два свойства были широко признаны в межвременных моделях из областей поведенческих решений и поведенческой экономики (3); последние два свойства хорошо изучены в финансовых дисциплинах. Существование риска требует применения различные распределения теории вероятностей для моделирования рисков. Этот подход может быть датирован 1700-ми годами, что привело к созданию моделей событий Бернулли, Пуассона и Гаусса, а также общих распределений Парето и общих распределений экстремальных значений для моделирования экстремальных событий. Динамика рисков в основном предполагает использование теории стохастических процессов в управлении рисками. Это можно отнести к 1930-м годам, когда были разработаны Марковские процессы, броуновские движения и процессы Леви. Взаимосвязь и зависимость рисков имеет дело с корреляцией между факторами риска. Строятся различные функции связки, а также используются преобразования Фурье. Сложность риска требует дальнейшего управления за счет использования различных моделей, основанных на науке о сложности, таких как подходы к моделированию на основе агентских моделей.

Управление рисками можно определить как процесс идентификации, анализа и принятия или уменьшения неопределенности при принятии инвестиционных решений.

Управление рисками - это управление неопределенностью возможного сценария событий. Традиционное управление рисками сосредоточено на рисках, связанных с физическими или юридическими причинами, такими как стихийные бедствия или пожары, несчастные случаи, смерть и судебные иски. Управление финансовыми рисками имеет дело с рисками, которыми можно управлять с помощью имеющихся финансовых инструментов. Самая последняя концепция, управление рисками предприятия, предоставляет инструмент для повышения ценности систем, как коммерческих, так и коммунальных, с систематической точки зрения. Исследование операций (OR) всегда полезно для оптимизации управления рисками.

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

3. Различные точки зрения и инструменты

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

3.1. Системы раннего предупреждения

Во многих работах рассматривалась ценность систем раннего предупреждения как средства контроля риска. Krstevska (30) приводит их использование в макроэкономических моделях с учетом специфики экономики Македонии. Ряд моделей был реализован с помощью компьютерных систем. Flores (15) рассматривал раннее предупреждение в страховании с помощью стохастической оптимизации. Castell and Dacuycuy (9) анализировали механизмы макроэкономического и финансового надзора. Hua (23) рассмотрел методы, используемые для раннего предупреждения в сфере недвижимости. В рамках промышленного применения Xie et al. (61) описал процедуру выявления логистических рисков для малых и средних предприятий.

3.2. Анализ рисков на основе нейронных сетей

Нейронные сети - это инструменты искусственного интеллекта, которые оказались очень полезными для выявления закономерностей в сложных структурах данных, особенно тех, которые связаны с нелинейными отношениями. Schneidewind (51) представил результаты работ по применению нейронных сетей для оценки надежности программного обеспечения, цель которых заключалась в снижении риска провала проекта. Jin and Zhang (25) представили другое приложение, демонстрирующее ценность моделей искусственных нейронных сетей в проектах, в данном случае в проектах, предполагающих государственно-частное партнерство. К отраслевым приложениям относятся банки, использующие модели искусственных нейронных сетей для анализа приложений кредитных карт (62), что позволяет банкам более эффективно контролировать свои риски после пузыря 2008 года. Модели нейронных сетей также были объединены с приложениями для тестового майнинга, такими как Groth и Muntermann (20), где модель применялась к финансовому риску, в дейтрейдинге. (12) применили модели искусственных нейронных сетей для управления риском дефолта малых предприятий в Италии.

3.3. Принятие решений на основе рисков

Использование компьютерных средств для принятия решений на основе риска широко изучается в области информационных систем в качестве систем поддержки принятия решений с 1970-х годов (28,56) Warenski (58) использовал искусственный интеллект для другого применения анализа кредитного риска, в данном случае демонстрируя финансовое моделирование в целлюлозно-бумажной промышленности. Otim et al. (46) представили недавний анализ, специально посвященный оценке стоимости и риска инвестиций в информационные технологии. Такие инвестиции включают в себя сложный набор заинтересованных сторон, что приводит к необходимости учитывать политику организации. Kozhikode and Li (29) изучали роль политического плюрализма в экспансии коммерческих банков в Индии, включая рассмотрение управления рисками. Принятие отраслевых решений включает не только множество заинтересованных сторон, но и множество критериев (44), отчасти обусловленных самим существованием этих многочисленных заинтересованных сторон. Silvestri et al. (53) представили методику многокритериальной оценки рисков для анализа рисков в области безопасности производства. Lakemond et al. (32) дали метод учета риска при разработке продукта, позволяющий на ранней стадии оценить риск и другие проблемы.

3.4. Анализ рисков на основе игр

Nash создал одну из самых плодотворных работ в теории игр (42), изучив роль конкурентной стратегии. Эта хорошо изученная область является одной из основных направлений в менеджменте промышленными рисками. Zhao and Jianq (63) рассмотрели модель полной информационной игры без взаимодействия, которая рассматривает множество возникающих рисков в среде управления проектами. Merrick and Parnell (39) расширили теоретико-игровые модели, включив в них вероятностный анализ рисков в контексте борьбы с терроризмом. Их применение включало в себя экранирование контейнеров для радиологических материалов. Lin et al. (35) использовали теорию игр для моделирования вертикальной дифференциации в онлайн-рекламе, обнаружив, что более высокий уровень дохода от рекламы может привести к снижению цен на услуги. Теория игр также применялась Gnyawali and Park (19) к управлению рисками малых и средних предприятий.

3.5. Определение кредитного риска

Основная задача финансового сектора в управлении рисками - оценка вероятности дефолта. Gurny и Tichy (21) представили скоринговую модель для банков США с использованием линейного дискриминантного анализа. Chen et al. (11) предложили другое исследование, в данном случае с использованием методологии Six Sigma DMAIC для снижения финансового риска.

Wu and Olson (60) продемонстрировали, как прогностические системы оценки использовались для управления крупными банковскими рисками кредитоспособности. Caracota et al. (8) предоставили скоринговую модель для малых и средних предприятий, ищущих банковский кредит. Poon (48) проанализировал эффективность кредитного скоринга финансируемых государством предприятий (Freddie Mac и Fannie Mae), показывая, как скоринг кредитного бюро приводит к поддержке противоположных стратегий избегания риска и скупого инвестирования.

3.6. Data mining в управлении рисками предприятия

Data mining стал очень популярным средством применения инструментов статистического и искусственного интеллекта для анализа больших массивов данных. Среди множества приложений для управления рисками Shiri et al. (52) применили инструменты интеллектуального анализа данных к корпоративным финансам, включая выявление мошенничества в управлении, оценку кредитного риска и прогнозирование результатов деятельности компании. Jans et al. (24) сосредоточили свое исследование интеллектуального анализа данных на устранении риска внутреннего мошенничества, обнаружив, что инструменты интеллектуального анализа данных дают лучшие результаты, чем одномерный анализ. Holton (22) также обратился к профессиональному мошенничеству, применив интеллектуальный анализ текста для поддержки аудита мошенничества. В других отраслях Nateghi et al. (43) применили методы data mining для более точного прогнозирования отключений электроэнергии, особенно, связанных с ураганами. Ghadge et al. (17) проанализировали приложения для интеллектуального анализа текста для поддержки управления рисками в цепочках поставок. Два исследования специально посвящены использованию интеллектуального анализа данных для снижения риска профессиональных травм. (5, 41)

3.7. Агентно-ориентированное управление рисками

Искусственный интеллект часто реализуется с помощью агентных систем, в которых компьютеры имитируют людей, принимающих решения. Этот подход был применен к управлению рисками в цепочках поставок Smeureanu et al. (55) с конкретным исследованием риска банкротства компании-партнера. Giannakis and Louis (18) также рассмотрели управление рисками в цепочке поставок с помощью агентских моделей, в данном случае исследуя риски, присущие как спросу на ресурсы, так и их предложению в период экономических спадов. Агенты также были специально применены к имитационным моделям, что позволяет использовать имитационные модели для анализа более сложных проблем. Caporale et al. (7) представили оптимальную модель финансовых рынков в условиях кризиса, сочетающую моделирование и теорию игр через агентов. Родственным подходом является оптимизация роя частиц, которая была применена Chang Lee et al. (10) для управления проектными рисками и Kumar et al. (31) для разработки более надежных конструкций цепочек поставок. Было обнаружено, что этот подход позволяет моделировать более сложные ситуации. Mizgier et al. (40) прикладное агентно-ориентированное моделирование цепочек поставок, моделирующее риск банкротства фирм-участников саморазвивающихся сетей.

3.8. Анализ инженерных рисков на основе инструментов оптимизации

Инструменты оптимизации имеют фундаментальное значение для инженерных усилий по разработке более совершенных систем. (4) Существование неопределенности нарушает некоторые из требуемых допущений для многих моделей оптимизации. Наличие риска подразумевает наличие неопределенности, что затрудняет разработку моделей оптимизации. Однако были представлены модели оптимизации инженерных систем. Ahmadi and Kumar (1) представили модель, учитывающую повышенную вероятность отказа механических систем из-за старения. Buurman et al. (6) ввел основу для динамического стратегического планирования инженерных систем с использованием анализа реальных вариантов, обнаружив, что этот подход имеет значительные преимущества перед статическим проектированием. Popovic et al. (49) применили комплексную оптимизацию к системам обслуживания, связанным с риском.

3.9. Управление знаниями и data mining для управления рисками стихийных бедствий в промышленности

Управление знаниями - это очень широкая область исследования, развивающаяся от систем поддержки принятия решений, экспертных систем и искусственного интеллекта до интеллектуального анализа данных и бизнес-аналитики. Управление знаниями также включает в себя рассмотрение того, как неявные знания в организациях могут быть зафиксированы в компьютерных системах, таких как аргументация на основе конкретных случаев. Несколько статей можно найти в применении управления знаниями к управлению промышленными рисками. Folino et al. (16) использовали сеточные технологии в геонауках посредством интеллектуального анализа данных для анализа и управления стихийными бедствиями, такими как оползни, землетрясения, наводнения и лесные пожары. Их система предназначалась для оказания помощи в предотвращении стихийных бедствий и реагировании на них. Li et al. (33) сосредоточились на прогнозировании стихийных бедствий с использованием знаний предметной области и пространственных данных для разработки байесовской сети.

4. Краткое содержание статьи

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

В статье Динамическое моделирование рисков в проектах сопровождения ERP с помощью FCM, написанной Cristina Lopez and Jose Salmeron, изучаются риски в проектах планирования ресурсов предприятия (ERP). В частности, они построили нечеткие когнитивные карты (FCM) рисков обслуживания ERP. Главное преимущество FCM заключается в их способности моделировать сложные явления на основе мнений экспертов. Этот инструмент моделирует неопределенность и связанные с ней события, имитируя человеческое мышление. Предлагаемый инструмент специально моделирует результаты проекта технического обслуживания ERP и восприятие рисков, а также их скрытые взаимодействия. Авторы показывают, что FCMS позволяют разрабатывать упражнения по прогнозированию с помощью моделирования. Таким образом, специалисты-практики будут оценивать совместное влияние рисков обслуживания ERP на результаты проекта. Предлагаемый инструмент поможет специалистам-практикам более эффективно и проактивно управлять рисками проекта сопровождения ERP.

В статье Hybrid Kansei-SOM Model using Risk Management and Company Assessment for Stock Trading, авторами Hai Pham, Eric Cooper, Thang Cao и Katsuari Kamei, представлен новый метод торговли акциями с использованием оценки Kansei, интегрированной с самоорганизующейся моделью карты для совершенствования системы биржевой торговли. Предлагаемый подход направлен на объединение нескольких экспертных решений, достижение наибольшей доходности инвестиций и снижение потерь за счет работы со сложными ситуациями в динамичной рыночной среде. Оценка Kansei и модели нечеткой оценки применяются для количественной оценки чувствительности трейдера в отношении торговли акциями, рыночных условий и факторов фондового рынка с неопределенными рисками. В оценке Kansei групповая психология и чувствительность трейдеров измеряются количественно и представляются нечеткими весами. Наборы данных Kansei и фондового рынка визуализируются SOM вместе с совокупными экспертными предпочтениями для того, чтобы найти потенциальные компании, соответствующие торговым стратегиям в нужное время и исключающие рискованные акции.

Авторы апробируют предложенный подход в ежедневных биржевых торгах на фондовых рынках HOSE, HNX (Вьетнам), NYSE и NASDAQ (США). Авторы показывают, что новый подход применения оценки Kansei повышает возможности получения инвестиционной отдачи и снижает потери. Авторы также показывают, что предложенный подход работает лучше, чем другие современные методы, при работе с различными рыночными условиями.

В статье Модель анализа рисков безопасности для информационных систем: причинно-следственные связи факторов риска и анализ распространения уязвимости, авторами которой являются Nan Feng, Harry Jiannan Wang, and Minqiang Li, разработана модель анализа рисков безопасности для выявления причинно-следственных связей между факторами риска и анализа, сложность и неопределенность распространения уязвимости. В предложенной модели разработана байесовская сеть (BN) для одновременного определения факторов риска и их причинно-следственных связей на основе знаний из наблюдаемых случаев и экспертов в предметной области. Авторы проводят анализ распространения уязвимостей безопасности, чтобы определить путь распространения с наибольшей вероятностью и наибольшей подверженностью риску на пути. Оптимизация муравьиной колонии используется в SRAM для установления структуры BN и определения путей распространения уязвимостей и их вероятностей. SRAM позволяет организациям создавать планы упреждающего управления рисками безопасности для информационных систем.

В статье Calibration of the Agent-based Continuous Double Auction Stock Market Scaling Analysis, авторами которой являются Yuelei Li, Wei Zhang, Yongjie Zhang, Xiaotao Zhang, and Xiong, предлагается метод калибровки для фондового рынка с непрерывным двойным аукционом (CDA) и использованием агентов. масштабного анализ на основе работы Pasquini and Serva. (47) Авторы разрабатывают и строят фондовый рынок CDA, основанный на агентах, и используют тот же торговый механизм, что и китайский фондовый рынок. Авторы также проводят масштабный анализ абсолютной доходности, как на искусственных, так и на реальных фондовых рынках и показывают корреляции волатильности в виде степенных законов на всех рынках, где показатель степени не является уникальным, и все такие показатели следуют многомасштабному поведению.

5. Заключительные замечания

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

Благодарности

Приглашенные редакторы хотели бы поблагодарить всех рецензентов, включая Patrick Paulson, Karl Leung, Colin Johnson, Daniel Zeng, Guo H. Huang, Chuen-Min Huang, Ching Huei Huang, Xiaoding Wang, Chichen Wang, Guixiang Wang, Cheng Wang, Magnus Johnsson, Guangquan Zhang, Futai Zhang, and David Mercie.

Мы благодарим редактора W. Pedrycz, редактора специального выпуска P. P. Wang и руководителей журнала за их многочисленные ценные предложения и усилия по выпуску этого специального выпуска. Второй автор также признателен за поддержку исследований в виде гранта NSC 101-2410-H-004-010-MY2.

References

1 A. Ahmadi, U. Kumar, Cost based risk analysis to identify inspection and restoration intervals of hidden failures subject to aging, IEEE Transactions on Reliability 60 (1) (2011) 197209.

2. E. Alfaro, N. Garcia, M. Gamez, D. Elizondo, Bankruptcy forecasting: an empirical comparison of AdaBoost and neural networks, Decision Support Systems 45 (1) (2008) 110122.

3. M. Baucells, F.H. Heukamp, Probability and time tradeoff, SSRN working paper, 2009. http://ssrn.com/abstract=970570

4. Y. Ben-Haim, Doing our best: optimization and the management of risk, Risk Analysis: An International Journal 32 (8) (2012) 13261332.

5. M. Bevilacqua, F.E. Ciarapica, G. Giacchetta, Data mining for occupational injury risk: a case study, International Journal of Reliability, Quality & Safety Engineering 17 (4) (2010) 351380.

6. J. Buurman, S. Zhang, V. Babovic, Reducing risk through real options in systems design: the case of architecting a maritime domain protection system, Risk Analysis: An International Journal 29 (3) (2009) 366379.

7. G.M. Caporale, A. Serguieva, H. Wu, Financial contagion: evolutionary optimization of a multinational agent-based model, Intelligent Systems in Accounting, Finance & Management 16 (1/2) (2009) 111125.

8. R.C. Caracota, M. Dimitriu, M.R. Dinu, Building a scoring model for small and medium enterprises, Theoretical & Applied Economics 17 (9) (2010) 117128.

9. M.R.F. Castell, L.B. Dacuycuy, Exploring the use of exchange market pressure and RMU deviation indicator for early warning system (EWS) in the ASEAN+3 region, DLSU Business & Economics Review 18 (2) (2009) 130.

10. K. Chang Lee, N. Lee, H. Li, A particle swarm optimization-driven cognitive map approach to analyzing information systems project risk, Journal of the American Society for Information Science & Technology 60 (6) (2009) 12081221.

11. Y.C. Chen, S.C. Chen, M.Y. Huang, C.L. Tsai, Application of six sigma DMAIC methodology to reduce financial risk: a study of credit card usage in Taiwan, International Journal of Management 29 (2012) 166176.

12. F. Ciampi, N. Gordini, Small enterprise default prediction modeling through artificial neural networks: an empirical analysis of Italian small enterprises, Journal of Small Business Management 51 (1) (2013) 2345.

13. D. Dalcher, Why the pilot cannot be blamed: a cautionary note about excessive reliance on technology, International Journal of Risk Assessment and Management 7 (3) (2007) 350366.

14. A.L. Fletcher, Reinventing the pig: the negotiation of risks and rights in the USA xenotransplantation debate, International Journal of Risk Assessment and Management 7 (3) (2007) 341349.

15. C. Flores, Management of catastrophic risks considering the existence of early warning systems, Scandinavian Actuarial Journal 2009 (1) (2009) 3862.

16. G. Folino, A. Forestiero, G. Papuzzo, G. Spezzano, A grid portal for solving geoscience problems using distributed knowledge discovery services, Future Generation Computer Systems 26 (1) (2010) 8796.

17. A. Ghadge, S. Dani, R. Kalawsky, Supply chain risk management: present and future scope, International Journal of Logistics Management 23 (3) (2012) 313339.

18. M. Giannakis, M. Louis, A multi-agent based framework for supply chain risk management, Journal of Purchasing & Supply Management 17 (1) (2011) 2331.

19. D.R. Gnyawali, B. Park, Co-opetition and technological innovation in small and medium-sized enterprises: a multilevel conceptual model, Journal of Small Business Management 47 (3) (2009) 308330.

20. S.S. Groth, J. Muntermann, Intraday market risk management approach based on textual analysis, Decision Support Systems 50 (4) (2011) 680691.

21. P. Gurny, T. Tichy, Estimation of future PD of financial institutions on the basis of scoring model, in: 12th International Conference on Finance & Banking: Structural & Regional Impacts of Financial Crises, 2009, pp. 215228.

22. C. Holton, Identifying disgruntled employee systems fraud risk through text mining: a simple solution for a multi-billion dollar problem, Decision Support Systems 46 (4) (2009) 853864.

23. Y. Hua, On early-warning system for Chinese real estate, International Journal of Marketing Studies 3 (3) (2011) 189193.

24. M. Jans, N. Lybaert, K. Vanhoof, Internal fraud risk reduction: results of a data mining case study, International Journal of Accounting Information Systems 11 (1) (2010) 1741.

25. X.H. Jin, G. Zhang, Modelling optimal risk allocation in PPP projects using artificial neural networks, International Journal of Project Management 29 (5) (2011) 591603.

26. P. Jorion, Risk management lessons from the credit crisis, European Financial Management 15 (5) (2009) 923933.

27. N. Julka, R. Srinivasan, I. Karimi, Agent-based supply chain management-1: framework, Computers & Chemical Engineering 26 (12) (2002) 17551769.

28. P.G.W. Keen, M.S. Scott Morton, Decision Support Systems: An Organizational Perspective, Addison-Wesley, Reading, MA, 1978.

29. R.K. Kozhikode, J. Li, Political pluralism, public policies, and organizational choices: banking branch expansion in India, 19482003, Academy of Management Journal 55 (2) (2012) 339359.

30. A. Krstevska, Early warning systems: testing in practice, IUP Journal of Financial Risk Management 9 (2) (2012) 722.

31. S.K. Kumar, M.K. Tiwari, R.F. Babiceanu, Minimisation of supply chain cost with embedded risk using computational intelligence approaches, International Journal of Production Research 48 (13) (2010) 37173739.

32. N. Lakemond, T. Magnusson, G. Johansson, et al, Assessing interface challenges in product development projects, Research-Technology Management 56 (1) (2013) 4048.

33. L. Li, J. Wang, H. Leung, C. Jiang, Assessment of catastrophic risk using Bayesian network constructed from domain knowledge and spatial data, Risk Analysis: An International Journal 30 (7) (2010) 11571175.

34. W. Liang, C. Huang, Agent-based demand forecast in multi-echelon supply chain, Decision Support Systems 42 (1) (2006) 390407.

35. M. Lin, X. Ke, A.B. Whinston, Vertical differentiation and a comparison of on-line advertising models, Journal of Management Information Systems 29 (1) (2012) 195236.

36. P. Lin, J. Chen, FuzzyTree crossover for multi-valued stock valuation, Information Sciences 177 (5) (2007) 11931203.

37. K.S. Markel, L.A. Barclay, The intersection of risk management and human resources: an illustration using genetic mapping, International Journal of Risk Assessment and Management 7 (3) (2007) 326340.

38. D. Martens, B. Baesens, T. Van Gestel, J. Vanthienen, Comprehensible credit scoring models using rule extraction from support vector machines, European Journal of Operational Research 183 (3) (2007) 14661476.

39. J. Merrick, G.S. Parnell, A comparative analysis of PRA and intelligent adversary methods for counterterrorism risk management, Risk Analysis: An International Journal 31 (9) (2011) 14881510.

40. K.J. Mizgier, S.M. Wagner, J.A. Holyst, Modeling defaults of companies in multistage supply chain networks, International Journal of Production Economics 135 (1) (2012) 1423.

41. S. Murayama, K. Okuhara, J. Shibata, H. Ishii, Data mining for hazard elimination through text information in accident report, Asia Pacific Management Review 16 (1) (2011) 6581.

42. J. Nash, Equilibrium points in n-person games, Proceedings of the National Academy of Sciences 36 (1) (1950) 4849.

43. R. Nateghi, S.D. Guikema, S.M. Quiring, Comparison and validation of statistical methods for predicting power outage durations in the event of hurricanes, Risk Analysis: An International Journal 31 (12) (2011) 18971906.

44. D.L. Olson, Decision Aids for Selection Problems, Springer, NY, 1996.

45. D.L. Olson, D. Wu, Enterprise Risk Management Models, Springer, 2010.

46. S. Otim, K.E. Dow, V. Grover, J.A. Wong, The impact of information technology investments on downside risk of the firm: alternative measurement of the business value of IT, Journal of Management Information Systems 29 (1) (2012) 159194.

47. M. Pasquini, M. Serva, Multiscale behaviour of volatility autocorrelations in a financial market, Economics Letters 65 (3) (1999) 275279.

48. M. Poon, From new deal institutions to capital markets: commercial risk scores and the making of subprime mortgage finance, Accounting, Organizations & Society 34 (5) (2009) 654674.

49. V.M. Popovic, B.M. Vasic, B.B. Rakicevic, G.S. Vorotovic, Optimisation of maintenance concept choice using risk-decision factor A case study, International Journal of Systems Science 43 (10) (2012) 19131926.

50. L.A. Reilly, O. Courtenay, Husbandry practices, badger sett density and habitat composition as risk factors for transient and persistent bovine tuberculosis on UK cattle farms, Preventive Veterinary Medicine 80 (2-3) (2007) 129142.

51. N. Schneidewind, Applying neural networks to software reliability assessment, International Journal of Reliability, Quality & Safety Engineering 17 (4) (2010) 313329.

52. M.M. Shiri, M.T. Amini, M.B. Raftar, Data mining techniques and predicting corporate financial distress, Interdisciplinary Journal of Contemporary Research in Business 3 (12) (2012) 6168.

53. A. Silvestri, F. De Felice, A. Petrillo, Multi-criteria risk analysis to improve safety in manufacturing systems, International Journal of Production Research 50 (17) (2012) 48064821.

54. D.H. Smaltz, R. Carpenter, J. Saltz, Effective IT governance in healthcare organizations: a tale of two organizations, International Journal of Healthcare Technology Management 8 (1/2) (2007) 2041.

55. I. Smeureanu, G. Ruxanda, A. Diosteanu, C. Delcea, L.A. Cotfas, Intelligent agents and risk based model for supply chain management, Technological & Economic Development of Economy 18 (3) (2012) 452469.

56. R.H.J. Sprague, E.D. Carlson, Building Effective Decision Support Systems, Prentice-Hall, Englewood Cliffs, NJ, 1982.

57. G. Suder, D.W. Gillingham, Paradigms and paradoxes of agricultural risk governance, Internat Journal of Risk Assess Manage 7 (3) (2007) 444457.

58. L. Warenski, Relative uncertainty in term loan projection models: what lenders could tell risk managers, Journal of Experimental & Theoretical Artificial Intelligence 24 (4) (2012) 501511.

59. D. Wu, D.L. Olson, Introduction to the special section on optimizing risk management: methods and tools, Human and Ecological Risk Assessment 15 (2) (2009) 220226.

60. D. Wu, D.L. Olson, Enterprise risk management: coping with model risk in a large bank, Journal of the Operational Research Society 61 (2) (2010) 179190.

61. K. Xie, J. Liu, H. Peng, G. Chen, Y. Chen, Early-warning management of inner logistics risk in SMEs based on label-card system, Production Planning & Control 20 (4) (2009) 306319.

62. M. Yazici, Combination of discriminant analysis and artificial neural network in the analysis of credit card customers, European Journal of Finance & Banking Research 4 (4) (2011) 110.

63. L. Zhao, Y. Jiang, A game theoretic optimization model between project risk set and measurement, International Journal of Information Technology & Decision Making 8 (4) (2009) 769786.

Размышления переводчика

Естественно понятно, что за созданием пространства метрик BI-Аналитики обращаются компании, которым сложные информационные системы управления не очень-то подходят, так как операционные процессы хорошо просматриваемые и менеджменту достаточно отслеживать определенный набор индикаторов.

Когда указанные компании обращаются к BI-аналитику, то предоставляют все данные, которые они мониторят и других данных нет. На основе имеющихся данных BI-аналитик создает пространство метрик.

Это пространство может не только отслеживать текущие значения, но и также в ретроспективе. Простой ответ менеджмента на вопрос: Какие периоды в прошлой своей деятельности Вы считаете напряженными, кризисными? дают интервалы на которых, отследив показания метрик, можно с помощью скоринговых инструментов вычленить критические значения метрик. Далее привязываем полученные граничные значения к текущему мониторингу по принципу: нормально - зеленый, опасно - красный и пользователь получает работающий инструмент с детализацией участков, требующих обратить на них внимание.

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

Обратимся к прогнозу Reports and Data где объем рынка анализа рисков к 2026 в объеме 65 млрд.долл.

Чтобы представить в сравнении этот объем, скажу, что они прогнозируют:

- объем рынка автомобильных шин на 2028 год в объеме 118,09 млрд.долл.;

- объем рынка альтернативных двигателей для автомобилей на 2027 год в объеме 541,53 млрд.долл.

Подробнее..

Как построить прогнозную модель для маркетолога в SAP Analytics Cloud без привлечения датасайнтистов

17.12.2020 14:07:58 | Автор: admin

Сегодня популярность проектов data science очень высока и бизнес понимает их важность и значимость. Рынок наполнен специалистами в этой области, которые умеют добиваться впечатляющих результатов. Но такие проекты нередко бывают дорогостоящими, и не всегда для простых задач нужно привлекать профессионалов в этой области. Создание некоторых прогнозов вполне по силам самим бизнес-пользователям. Например, специалисты из отдела маркетинга могут прогнозировать отклик на маркетинговые кампании. Это становится возможным при наличии инструмента, позволяющего за несколько минут построить прогноз и легко интерпретировать результаты с точки зрения бизнес-смысла.

SAP Analytics Cloud (SAC) облачный инструмент, совмещающий в себе функции BI, планирования и прогнозирования, он также оснащен множеством функций расширенной аналитики: интеллектуальными подсказками, автоматизированным анализом данных и возможностями автоматического прогнозирования.

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

Функциональность Smart Predict ориентирована на бизнес-пользователя и позволяет строить прогнозы высокой точности без привлечения специалистов Data Science. Со стороны пользователя системы прогноз происходит в черном ящике, но в реальности это, конечно же, не так. Алгоритмы прогнозирования в SAC идентичны алгоритмам модуляAutomated Analytics инструмента SAP Predictive Analytics. Об алгоритмах, лежащих в основе этого продукта, есть множество материалов, мы предлагаем прочитать эту статью. На вопрос: Получается, Automated Analytics переехал в SAP Analytics Cloud? - мы отвечаем - Да, но пока только частично. Вот какая разница и сходство в функциональных возможностях инструментов (рис.1)

SAP Analytic Cloud в настоящее время предлагает 3 прогнозных сценария:

Классификация. В данном случае предполагается бинарная классификация: предсказываются значения целевой переменной, которая может иметь только два значения -да и нет или 0 и 1. Примерами сценария классификации могут быть:

Прогноз оттока клиентов, где целевая переменная предсказывает, уйдет клиент или нет.

Прогноз склонности клиента к покупке с целевой переменной, прогнозирующей будет ли клиент покупать предложенный ему товар или нет.

Выявление мошенничества с целевой переменной, указывающей, была ли транзакция или требование мошенническим, или нет.

Регрессия. Предсказывает числовое значение целевой переменной в зависимости от переменных, описывающих ее. Примеры регрессионных сценариев:

Количество клиентов, посещающих магазин в обеденное время.

Выручка от каждого клиента в следующем квартале.

Цена продажи подержанных автомобилей.

Прогнозирование временного ряда. Предсказывает значение переменной с течением времени с учетом дополнительных описательных переменных. Примеры сценария прогнозирования временных рядов:

Выручка по каждой продуктовой линейке в течение следующих нескольких кварталов.

Количество велосипедов, арендованных в городе в течение следующих нескольких дней.

Командировочные расходы в ближайшие несколько месяцев.

В процессе прогнозирования мы будем работать с тремя типами датасетов: тренировочным, прикладным и результирующим (рис. 2)

Процесс прогнозирования в SAP Analytics Cloud осуществляется в несколько простых этапов. Мы рассмотрим его на примере прогнозирования оттока клиентов интернет-магазина. Для начала нам необходимо загрузить в систему тренировочный датасет из системы-источника или excel файла. Также SAP Analytics Cloud позволяет прогнозировать в режиме Live (избегая загрузки данных в облако) на таблицах SAP HANA. В этом случае для пользователя SAC процесс остается неизменным, но построение прогноза происходит на стороне SAP HANA с использованием библиотеки Automated Predictive Library (APL).

Наш тренировочный датасет имеет следующие поля:

Customer ID

Уникальный ID каждого клиента

Usage Category (Month)

Количество времени, проведенное клиентом на портале в текущем месяце

Average Usage (Year)

Среднее количество времени, проведенное клиентом на портале за прошедший год

Usage Category (previous Month)

Количество времени, проведенное клиентом на портале за прошедший месяц

Service Type

Флаговая переменная, указывающая тип сервиса клиента: премиум или стандарт

Product Category

Категория продукта интернет-магазина, наиболее часто заказываемая клиентом

Message Allowance

Флаговая переменная, указывающая, давал ли клиент согласие на получение сообщений

Average Marketing Activity (Bi-yearly)

Среднее число маркетинговых предложений для клиента за последние 2 года

Average Visit Time (min)

Среднее количество времени, проведенное клиентом на портале за каждый визит

Pages per Visit

Среднее число страниц интернет-магазина, посещаемых клиентом за один визит

Delta Revenue (Previous Month)

Разница между выручкой от данного клиента за предыдущий и текущий месяц

Revenue (Current Month)

Выручка от данного клиента в текущем месяце

Service Failure Rate (%)

Доля случаев, когда пользователь сталкивался с ошибками в работе портала

Customer Lifetime (days)

Количество дней с момента регистрации

Product Abandonment

Число продуктов, которые были помещены клиентом в корзину, но не оплачены за последний квартал

Contract Activity

Флаговая переменная, указывающая, отказался ли данный пользователь от услуг интернет-магазина. Целевая переменная, которую мы будем прогнозировать.

Следующим шагом построение прогноза будет выбор сценария прогнозирования.

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

После этого мы создаем прогнозную модель и выбираем заранее подготовленный датасет, как источник данных для обучения. У пользователя также есть возможность редактировать метаданные. Далее мы выбираем целевую переменную, ее мы будем прогнозировать. В нашем случае это переменная Contract Activity, идентифицирующая отток клиентов. Также мы можем исключить некоторые переменные, если понимаем, что они никак не повлияют на формирование прогноза. Например, в нашем случае точно можно исключить Customer ID. Это может ускорить процесс выполнения прогноза, но их сохранение не мешает процессу моделирования.

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

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

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

Прогностическая сила (KI) указывает на долю информации в целевой переменной, которую могут описать другие переменные модели (объясняющие переменные). Гипотетическая модель с прогностической силой 1,0 является идеальной, поскольку позволяет объяснить 100% информации целевой переменной, а модель с прогностической силой 0 является чисто случайной.

Достоверность прогноза (KR) показывает способность модели достичь той же производительности, когда она применяется к новому набору данных, имеющему те же характеристики, что и обучающий набор данных. Приемлемой считается достоверность прогноза не менее 95%.

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

Кроме этого, на рисунке ниже мы видим кривую производительности AUC ROC. Ось X показывает, какой процент от общей выборки составляют положительные цели; ось Y представляет их верно идентифицированный процент, который обнаружил алгоритм. Здесь необходимо пояснить, что положительными целями в данном случае считается целевая группа, а именно клиенты, отказавшиеся от услуг интернет-магазина.

Зеленая кривая олицетворяет некую идеальную модель с максимально возможным процентом обнаруженной цели. Например, если 25% общей выборки будут составлять ушедшие клиенты, то идеальная модель правильно классифицирует все 25% таких клиентов.

Красная кривая показывает минимальный процент обнаруженной цели, полученный случайной моделью. То есть случайно взяв 10% населения, вы бы определили 10% клиентов.

Синяя кривая показывает процент обнаруженной цели с использованием нашей модели. Например, если 10% выборки составляют ушедшие клиенты, мы обнаруживаем примерно 75%. Чем ближе синяя линия подходит к зеленой, тем лучше модель. Чем больше расстояние между красной и синей линиями, тем больше лифт модели.

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

Например, посмотрим более подробную аналитику по предиктору Average Visit Time, показывающему среднее количество времени, которое клиент проводит на портале интернет-магазина. По умолчанию предлагается отследить влияние этого фактора на столбчатой диаграмме, но также существует возможность настройки различных типов визуализации.

Мы видим, что клиенты, проводившие на страницах интернет-магазина от 10 до 22 и от 1 до 3 минут, имеют наибольшую склонность отказаться от услуг. Напротив, покупатели, находящиеся на портале от 3 до 7 и от 7 до 10 минут, показывают наименьшую вероятность уйти. Результаты выглядят волне логично: уходят те, кто проводили на сайте или слишком мало, или слишком много времени. Подобный анализ можно провести по всем ключевым предикторам.

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

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

На выходе мы получаем датасет с прогнозными значениями целевой переменной, на основе которого может быть легко сформирована модель данных. Она, в свою очередь, может являться источником данных для построения аналитической отчетности в SAC. Например, для этого кейса мы использовали интеллектуальную функцию Smart Discovery и получили автоматических дашборд на спрогнозированных данных.

Таким образом, прогнозирование легко вписывается в процесс анализа данных в SAC. С недавних пор функционал прогнозирования в решении также может быть легко интегрирован в процесс планирования.

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

Кроме того, в процессе создания отчетов пользователи также могут использовать прогностические функции, например, автоматический прогноз. Он позволяет продлить график временного ряда.

Алгоритм выполнения такого прогноза описан здесь, линейная регрессия или тройное экспоненциальное сглаживание. Результаты прогноза видны ниже, рядом с графиком факта появляется пунктирная линия прогноза и доверительный интервал.

Также прогноз можно добавлять в таблицы и использовать оттуда данные, например, как базу для будущего плана.

Таким образом, процесс прогнозирования в SAP Analytics Cloud достаточно прост и максимально ориентирован на бизнес-пользователя, но дает возможность получения прогностических моделей высокого качества для решения типовых бизнес-задач.

Данный инструмент является stand-alone решением и может стать частью мультивендорной архитектуры. Интеграция SAP Analytics Cloud с решениями SAP нативна. Кроме того, существует стандартный бизнес контент для различных индустрий и линий бизнеса. Отчеты могут быть дополнены прогнозными и плановыми данными, а также обогащены функциями расширенной аналитики.

Автор Анастасия Николаичева, архитектор бизнес-решений SAP CIS

Подробнее..

Российский селлер сравнил между собой сервисы внешней аналитики маркетплейсов. Кому из них доверять?

17.02.2021 16:08:10 | Автор: admin

На днях, надругойнебезызвестной вам площадке появился большой сравнительный анализ сервисов внешней аналитики маркетплейсов. Автор постарался разобраться в преимуществах и недостатках каждого и выдал свою оценку. Она, конечно, субъективная, поскольку у каждого продавца собственные ресурсы и требования к работе маркетплейсов. Но как основу для рассуждений материал взять можно - в нем сразилось 20 сервисов аналитики. Чтобы вы не убегали с Хабра и с позволения автора, мы разместим здесь выдержки из его обзора,. Вдруг вы найдете для себя что-то полезное или убедите других, что лучший сервис должен выглядеть чуть иначе.

Зачем нужны сервисы аналитики?

Пандемия сильно повлияла на российский сегмент e-commerce и пошатнула его в сторону стремительного развития. Чтобы не заниматься погрузкой из пустого в порожнее, продавцам пришлось изучать рынок и потребности покупателей. Одни были очевидны: например, антисептики весной 2020 года были топом продаж - для этого не нужно выстраивать сложные графики. Другие запросы покупателей не всегда ясны. Например, мы изучали топ продаж детских игрушек на OZON и обнаружили, что плюшевый Тоторо и кукла Гарри Поттера приносят продавцу по 15 миллионов рублей в неделю. Вот как бы вы догадались?

Чтобы это узнать нужно тонко разбираться в определенной сфере: например, знать, что ДжоанРоулинг готовит к выходу новую книгу и фанаты скоро сорвутся с цепей. Другой вариант - использовать сервисы внешней аналитики маркетплейсов, которые наглядно показывают какие товары пользуются спросом. Они же помогают понять - взрывной ажиотаж - следствие начавшейся распродажи или новый тренд. И если поначалу существовала всего пара таких сервисов аналитики, то с ростом популярности маркетплейсов они просто заполонили рынок.

Как их оценивать?

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

HunterSales/LookFor.sale/MarketGuru/Mayak/MoneyPlace/MPStats/MScout/RetailTool/SellerFox/Shopstat/Sloy/Stat4Market/WBExpert/WonderSell /MarketVision/Pi-Data/Whisla/MPHelp/Adapter/AYO

За каждый пункт в сравнении селлер решил выставлять баллы: по 10-бальной системе для наиболее важных характеристик и по 5-бальной системе для менее важных пунктов. Все результаты сведены в таблицы - увидите их в нужное время.

Часть сервисов на момент написания статьи находятся на бета-тестировании... поэтому такие сервисы я тоже включу в таблицу сравнения, для наглядности, но баллы выставлять не буду.Также сервис WonderSell имеет только лэндинг - основной функционал через телеграм-бота; Mayak имеет лэндинг, расширение браузера и телеграм-бота, но не имеет непосредственно сайта для работы с ним; AYO имеет только лэндинг - отчёты по товарам предоставляются по запросу в ручном режиме. По ним тоже не буду выставлять баллы.

Можно всё попробовать?

Критерий наличия полноценного тестового периода, автор анализа почему-то поставил на второе место. Не согласимся. Все-таки много важно разобраться в работе сервиса еще до оплаты. Он может не отвечать запросам селлера, сильно ограничивать временные рамки для поиска или анализировать данные ненужных площадок.

Мы ставим наличие тестового периода на первое место - для нас именно это важный шаг при выборе системы аналитики. А еще мы полностью согласны с автором материала - цитата ниже. Так что "тест" - всему голова.

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

С тестовым периодом все оказалось просто. Самый долгий доступ (14 дней) готов предоставить сервис MarketVision. За ним следом встает MarketGuru, предоставляющий клиентам 7 демо-дней. У всех остальных конкурентов предложение ограничивается сроком от 1-3 дней. Еще 3 проекта находятся на тестировании и доступ к ним полностью бесплатный, но и вопросов к работе таких систем возникать не может - ошибки имеют место быть.

Лучший или дешёвый?

Стоимость подписки особенно важна начинающим продавцам и небольшим предпринимателям. Сначала хочется заработать, а после уже после тратить десятки тысяч на всякие сервисы.Сравнить стоимость подписки на разные сервисы - хорошее решение. При этом автор решил поставить всех участников в равные весовые категории и оценивать только стоимость 30-дневного тарифа. Для некоторых систем это потолок, у других продолжительность подписки может доходить до 1 года.

Видно, что тут на первом месте оказался Stat4Market с ценой подписки всего в 870 рублей в месяц. На другой стороне, с 30-ти дневным тарифом за 7 900 рублей остановился HunterSales. Золотую середину заняли сразу два игрока - MoneyPlace и SellerFox. Тут месячная подписка обходится клиентам в 4 тысячи рублей. Разница между стоимостью сервисов всего 9 рублей.

Про сервисы, которые находятся на тестировании я уже говорил ими Вы можете пользоваться бесплатно... В основном, тарифы растянуты на 1,3 и 6 месяцев. В некоторых сервисах они отличаются по возможностям анализа того или иного параметра и по количеству дней, за которое Вы можете получить информацию.

Что должен анализировать сервис?

Понятно, что информацию, удающуюся собраться с маркетплейсов. Но у каждого продавца своя задача. Например, кто-то торгует только на Wildberries и хочет анализировать конкурентов по площадке. С другой стороны, если у него будет возможность отслеживать статистику продаж того же OZON, он сможет спланировать своевременный выход на его склады.

В основном, как Вы видите, большинство сервисов анализируют только один маркетплейс WildBerries, меньшая часть 2 и более. AliExpress анализируют только 2 сервиса, Яндекс.Маркет и Lamoda по одному.

Очевидно, что самыми интересными на рынке пока являются сервисы, которые анализируют данные сразу всех маркетплейсов. Если цена у таких сервисов приемлемая, то их покупка - хороший вклад в будущее.

Возможности для самоанализа

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

7 сервисов из рассматриваемых нами имеют функционал для внутренней аналитики. В некоторых из них он откровенно слабый для галочки. Еще 3 сервиса сообщают о том, что в скором времени такой функционал у них появится.

...остановился на промежуточном значении в баллах: за наличие внутренней аналитики выставлял 7 баллов, за информацию о её появлении в будущем 2 балла.

Начало летоисчисления

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

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

На первом месте по данному показателю MPStats, они собирают данные с января 2020 года, 10 баллов. Далее WBExpert май 2020 и замыкает тройку SellerFox и MarketVision июль 2020 года. Часть сервисов предоставляет данные за последние 30 дней они получают по 2 балла, так как такие данные пригодятся не для всех случаев, а это основной функционал сервиса аналитики и парсинга. MPHelp даёт показывает информацию всего лишь за 7 дней, Pi-data в тестовом тарифе тоже за 7 дней, по основному тарифу на мой запрос ответа не поступило.

Мы только спросить

Для малого и среднего бизнеса анализ маркетплейсов - важная часть ведения бизнеса на первых этапах. Но для них же оплата дополнительных сервисов - дополнительная финансовая нагрузка. Именно поэтому многие продавцы просто не могут позволить себе покупку дорогих сервисов и модулей, а значит не могут и масштабироваться. Хорошее решение - тарифы, предоставляющие доступ к сервисам на короткий период. А значит - дешевые.

Показатель, наряду с ценой тоже очень важный, поэтому 10 баллов я поставил сервисам HunterSale и MPHelp. Они дают возможность оплатить 24 часовой доступ, пусть и достаточно дорогой. 7 баллов получил SellerFox за 3-х и 14-ти дневные доступы к сервису. А 5 баллов я поставил LookForSale за семидневный дневный доступ. У всех остальных есть возможность оплаты только 30-дневного периода, поэтому - 3 балла.

Поддержим молодых и неопытных

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

Для оценки я пользовался следующими способами: либо смотрел историю вопросов пользователей и ответов на них службы поддержки у сервисов, которые имеют телеграммной-чаты и прикидывал примерное время ответа; либо писал в телеграм-боты поддержки, телеграм-аккаунты лиц, указанных на сайте как служба поддержки и в формы обратной связи, установленные на сайтах.

Спам - не результат аналитики

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

Так как этот показатель очень субъективный и многим легко спутать спам с рекламой, а также из-за того, что этот показатель никак не влияет на качество работы сервисов аналитики, то он проходит вне конкурса за него я не выставлял баллы.

Заработать на своих

Реферальная программа - тренд современности. Приведи друга и получи пончик в подарок. Подключи приятеля и получи бонус на карту. Какие еще варианты вам знакомы? Можно, например, подключиться к реферальной программе сервисов внешней аналитики и заработать сверх того, что принесут вам данные графиков и диаграмм. Будем плюсовать в карму разработчикам, использующим такой подход?

Оценивался мною также по 5-бальной шкале. Если реферальная программа есть 5 баллов, нет 0 баллов. Конечно, можно было бы углубиться в этот параметр и рассмотреть в рамках него такие факторы как финансовые и временные условия, а также минимальная сумма вывода денег с баланса.

Выгружать на склад или данные?

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

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

Визуализируй это

Визуализация наше всё. Кому как, но мне очень нравится работать с данными, представленными в визуальном виде с помощью различных графиков и диаграмм. Поэтому ввёл и этот параметр для сравнения сервисов. Оценивал также по 5-бальной шкале. Без учёта проработанности самих графиков и диаграмм.

Автор отметил, что среди анализируемых сервисов, ему пришлось выделить MSCout и поставить по данному критерию баллов. Просто потому, что сам сервис не предоставляет пользователям тестового периода и получить данные для просмотра и анализа ему не удалось.

О, мой бот

Последнее на что обратил внимание автор - дополнительный функционал сервисов, позволяющий удобно управлять анализируемыми данными в мобильном приложении, через телеграм-бота или прямо на сайте маркетплейса. Оказывается такой зверь встречается, но пока крайне редко.

Сводный анализ

По итогам сравнения сервисов, автор объединил данные в итоговую таблицу. Тут все наглядно. Если не верите в подсчеты, можете сами суммировать показатели.

Если вглядываться в цифры неудобно, сложим и прочитаем за вас. Итоговый топ сервисов по мнению одного селлера-аналитика получился таким:

1 местоSellerFox

2 местоMPStats

3 местоMoneyPlace

Я по максимуму, старался быть объективным, но у каждого из Вас может быть своё мнение по распределению баллов: кому-то важна цена, кто-то пользуется сервисом из-за наличия в нём внутренней аналитики. Для кого-то никакого значения не будут иметь диаграммы и графики, а кому-то не нужна реферальная программа. Поэтому и удельный вес каждого параметра у каждого может быть свой.

Для нас материал оказался полезным. И даже если не присматриваться к тройке сервисов-победителей, саму методику сравнения, которую создал автор мы плюсуем. Ему удалось рассмотреть огромное количество сервисов внешней аналитике в одном материале, а значит упростить жизнь селлерам, которые вряд ли найдут время на самостоятельно изучение каждого.

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

Если захотите задать вопросы автору всех этих таблиц и цифр - пишите. Мы передадим. А если у вас есть свои вопросы к сервисам аналитики и в материале упущены данные о суперкрутом сервисе или функции - пишите. Будем рады узнать еще больше.

Не самим же считать всё, в конце концов.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru