<\/p>\n<\/p>\n
В системах сквозной аналитики ключевую роль играет правильная модель атрибуции. Без нее данные невозможно интерпретировать, и их ценность для бизнеса невелика. При этом важно понимать, что любая модель напрямую зависит от качества данных.<\/p>\n
Частая проблема с сырыми данными в том, что информация об одном клиенте дублируется или, напротив, противоречит друг другу в разных источниках.<\/p>\n
Кроме того, что предобработка данных — база для аналитика, без правильного объединения персональных данных в принципе сложно отследить клиентский путь. Значит, нужно настраивать процессы объединения неоднородных персональных данных.<\/p>\n
Сегодня в любом клиентском бизнесе воронки регистрации устроены таким образом, что клиенты попадают в базу множеством способов — часто через маркетинговые каналы, которых всегда много (рассылки, реклама, соцсети). В каждом таком канале может быть ссылка на форму подписки, регистрацию на платформе или чат, и один клиент часто проходит все эти этапы. Сразу же образуется путаница в идентификации, которая сильно влияет на качество данных и результаты аналитики, если ее не лечить.<\/p>\n
Мы столкнулись с этой проблемой, работая с одним из наших клиентов, и решили ее, создав сквозной идентификатор. Это уникальный номер, который присваивается реальному клиенту и дублируется во все источники, где есть данные об этом клиенте, тем самым избавляя от путаницы.<\/p>\n
Мы разрабатывали кастомную систему сквозной аналитики для эдтех-стартапа Refocus. Данные каждого студента в системы Refocus попадали из нескольких источников и были записаны несколько раз — как минимум при регистрации на курс, при первом входе на образовательную платформу и при входе в чат сопровождения.<\/p>\n
В нашем случае мэтчинг был важнее всего по трем источникам из тринадцати:<\/p>\n
Остальные источники, с которыми мы работали, либо не содержали данных студентов (например, цифры эффективности работы sales-менеджеров были завязаны на данных сотрудников и трекались через другие системы), либо дублировали информацию из указанных трех.<\/p>\n
В Discord и Thinkific данные попадали напрямую, от студентов при регистрации в системах, а затем подтягивались в amoCRM. Основные причины несовпадения клиентских данных как у Refocus, так и в похожих случаях — человеческий фактор (опечатки), наличие у людей более чем одного телефона или адреса почты и ограничения самих платформ, с которых приходят данные: разный заданный формат полей и их количество.<\/p>\n
Часть этих факторов может решаться корректировкой самой клиентской воронки. Правда, не все платформы позволяют одинаково настроить вводные поля, а просьбы вводить данные в конкретном формате не всегда работают и не страхуют от ошибок. Плюс, задача аналитиков — получить чистые данные в любом случае.<\/p>\n
Данные в Refocus мы подгружали в хранилище в BigQuery напрямую из интересующих нас источников (рекламных кабинетов, LMS и т. д.), используя Python. В дальнейшем на этих данных строились дашборды в Tableau.<\/p>\n
Обнаружить проблему несложно — при создании хранилища и дальнейшей выгрузке данных из него мы в любом случае чистим датасет от дубликатов и несовпадений.<\/p>\n
Поля, в которых возникали ошибки и для которых нам важен был мэтчинг, чтобы правильно отследить клиентский путь:<\/p>\n
Поначалу, пока количество студентов Refocus было относительно небольшим, достаточно было скриптов, которые объединяли данные по одному из этих полей. В полученных таблицах в Tableau проводился поиск строк с пустым значением в соответствующем поле — и вот видно всех студентов, чьи данные не сошлись.<\/p>\n
Количество таких строк было в пределах пары десятков, и трекать и объединять их было несложно вручную. Это делалось прямо в первоисточниках сотрудниками Refocus, которые могли поправить опечатки и ошибки у себя в системах. После этого наш код выгрузки в хранилище перезапускался и тянул уже чистые данные. Если после этого что-то не сходилось, то наши аналитики правили информацию на уровне базы данных.<\/p>\n
Но при росте компании в какой-то момент число студентов, потерянных при мэтчинге, могло достигать сотни за месяц. Пока ошибка обнаружится, данные поправят в источниках, а мы перезапустим код выгрузки, могло пройти несколько часов — а это критичный интервал. Да и перезапускать выгрузку каждый день ради нескольких несовпадений — неэффективно. Стало понятно, что масштаб проблемы требует более точного и универсального решения.<\/p>\n
Вообще, в такой ситуации возможны несколько вариантов. Можно бесконечно править скрипты мэтчинга, учитывая новые и новые случаи и создавая костыли. А можно, например, настроить алерты в оркестраторе процессов (в нашем случае — Airflow), которые позволят моментально узнавать о появившемся несовпадении и объединять “потерянные” клиентские сущности по паре за раз. Но это все еще неполная автоматизация, и она только ускоряет, а не упрощает процесс.<\/p>\n
Руководствуясь соображениями эффективности, мы предложили ввести сквозной идентификатор — одно значение ID, присваиваемое одному клиенту после автоматической интеграции его данных из разных источников.<\/p>\n
Чтобы понять масштаб проблемы, мы начали с того, что создали таблицы несовпадающих персональных данных. Для этого мы использовали скрипты на Python. Эти скрипты объединяли данные из разных источников и создавали из них большую сводную таблицу. Для того, чтобы свести данные о студенте в одну сущность, использовался мэтчинг по адресу электронной почты. Мы попробовали мэтчить по имени, фамилии, телефону (который сначала надо было привести к одному формату!) и почте, и именно последний вариант показал самую высокую точность. Возможно, дело в том, что из всех данных почта имеет самый однородный формат, поэтому остается учитывать только опечатки.<\/p>\n
Например, нам нужно было мэтчить данные для создания дашборда по возвратам, о которых информация объединялась как раз из наших трех основных источников. В ранней версии скрипта данные отбирались таким образом:<\/p>\n
WITH snapshot_ AS (\r\n SELECT DISTINCT s.*,\r\n IFNULL(ae.name, ap.name) as contact_name,\r\n ap.phone, ae.email,\r\n split(replace(trim(lower(ae.email)),' ',''),'@')[OFFSET(0)] as email_first_part,\r\n ai.thinkific_id, ai.intercom_id, ac.student_id\r\n FROM (\r\n SELECT *,\r\n ROW_NUMBER() OVER(PARTITION BY lead_id ORDER BY updated_at DESC) as num_,\r\n FROM `Differture.amocrm_leads_snapshot`\r\n ) s\r\n LEFT JOIN (\r\n SELECT DISTINCT lead_id, contact_id, name, email,\r\n ROW_NUMBER() OVER(PARTITION BY lead_id ORDER BY contact_id) as num1_\r\n FROM `Differture.amo_emails`\r\n ) ae using(lead_id)\r\n LEFT JOIN (\r\n SELECT DISTINCT lead_id, contact_id, name, phone,\r\n ROW_NUMBER() OVER(PARTITION BY lead_id ORDER BY contact_id) as num2_\r\n FROM `Differture.amo_phones`\r\n ) ap using(lead_id)\r\n LEFT JOIN `Differture.amo_contact_thinkific_intercom_match` ai using(lead_id)\r\n LEFT JOIN `Differture.AmoContacts` ac on cast(ae.contact_id as string)=ac.amo_id\r\n WHERE (num_=1 or num_ is null) and (num1_=1 or num1_ is null) and (num2_=1 or num2_ is null)\r\n and s.pipeline_id in (4920421,5245535) and s.status_id=142 and lower(s.lead_name) not like '%test%'\r\n )<\/code><\/pre>Как можно заметить, идея сквозного идентификатора здесь уже присутствует — фигурирует student_id<\/tt>. На самом деле, в этой версии скрипта это графа из AmoContacts — таблицы, в которой хранятся только данные из amoCRM. Никаких джойнов по student_id<\/tt> пока не происходит. А происходят по email_first_part<\/tt>, адресу почты до символа @:<\/p>\nselect distinct * from th_amo_ds_rf\r\n left join calendly ce using(email_first_part)\r\n left join typeform_live tfl on email_first_part=tf_email_first_part\r\n left join typeform tf using(email_first_part)\r\n left join csat using(email_first_part)<\/code><\/pre>Первым шагом по практическому введению идентификатора была таблица students_main_info<\/b>, созданная в BigQuery in-house специалистом Refocus. К сожалению, у нас нет доступа к коду, который использовался для присвоения идентификатора. Зато мы можем показать вид этой таблицы:<\/p>\n\n\n\nstudent_full_name<\/td>\n string<\/td>\n<\/tr>\n \nstudent_email<\/td>\n string<\/td>\n<\/tr>\n \nstudent_country_id<\/td>\n string<\/td>\n<\/tr>\n \nstudent_country_name<\/td>\n string<\/td>\n<\/tr>\n \nstudent_courses_ids<\/td>\n array<\/td>\n<\/tr>\n \nstudent_courses_names<\/td>\n array<\/td>\n<\/tr>\n \nstudent_cohort_id<\/td>\n string<\/td>\n<\/tr>\n \nstudent_cohort_name<\/td>\n string<\/td>\n<\/tr>\n \ncohort_community_manager_name<\/td>\n string<\/td>\n<\/tr>\n \ncohort_community_manager_email<\/td>\n string<\/td>\n<\/tr>\n \nstudent_onboarding_live_session_id<\/td>\n string<\/td>\n<\/tr>\n \nstudent_onboarding_live_session_time<\/td>\n string<\/td>\n<\/tr>\n \nstudent_onboarding_live_session_zoom_url<\/td>\n string<\/td>\n<\/tr>\n \namo_contact_id<\/td>\n string<\/td>\n<\/tr>\n \nintercom_contact_id<\/td>\n string<\/td>\n<\/tr>\n \nthinkific_student_id<\/td>\n string<\/td>\n<\/tr>\n \ndiscord_user_id<\/td>\n string<\/td>\n<\/tr>\n \ndiscord_user_discord_id<\/td>\n string<\/td>\n<\/tr>\n \ndiscord_guild_id<\/td>\n string<\/td>\n<\/tr>\n \ndiscord_channel_id<\/td>\n string<\/td>\n<\/tr>\n \ndiscord_roles<\/td>\n string<\/td>\n<\/tr>\n<\/table>\n<\/div>\nВ students_main_info хранились данные из нужных источников с общим идентификатором в первой строке, и объединение проходило через сравнение этого поля.<\/p>\n
При этом поле student_id<\/tt> использовалось пока не везде; также использовались другие поля этой таблицы — например, thinkific_student_id<\/tt> или discord_user_id<\/tt>.<\/p>\n
После выгрузки и мэтчинга данных с помощью students_main_info студентов, которые потерялись при объединении, стало меньше, чем при первой схеме мэтчинга. Так мы убедились, что движемся в верном направлении. Тем не менее, использование одной таблицы, которая содержит больше десятка полей обо всех имеющихся персональных данных, не очень эффективно. Данные в ней уже обработаны скриптом специалиста Refocus, и если надо сверить их с сырыми источниками или ввести новый критерий отслеживания, все придется менять на бэкенде.<\/p>\n
Что получилось в итоге<\/h2>\n
После теста сквозного идентификатора через одну большую таблицу мы продолжили улучшать структуру данных на бэке. Вместо students_main_info усилиями специалиста Refocus появилась подробная сеть более мелких таблиц, которые могут обращаться друг к другу и лежат в одном хранилище с нашими таблицами сырых данных.<\/p>\n
Вот так выглядела схема соотношения этих таблиц:<\/p>\n
<\/p>\n
А вот так выглядела основная таблица Students:<\/p>\n
<\/p>\n
В ней-то и находились основные персональные данные студентов с присвоенным идентификатором, и к ней можно было обращаться для мэтчинга из остальных источников.<\/p>\n
Остальные таблицы выглядели похоже: всегда было поле с идентификатором и информация о какой-то характеристике студента — когорта, курс, роль в дискорде и так далее.<\/p>\n
Финальный код, написанный нашими аналитиками, объединял данные при выгрузке из хранилища, и больше не опирался на ненадежный мэтчинг через имейл.<\/p>\n
Сначала он отбирал собранные нами данные из amoCRM (amocrm_leads_snapshot)<\/tt> и объединял их с контактной информацией клиентов. Затем в таблицу добавлялось поле student_id<\/tt> и отбирались данные, которые понадобятся нам дальше.<\/p>\nWITH snapshot_ AS (\r\n SELECT DISTINCT s.*,\r\n ac.name as contact_name, ac.phone, ac.email,\r\n split(replace(trim(lower(ac.email)),' ',''),'@')[OFFSET(0)] as email_first_part,\r\n ac.intercom_id, ac.student_id\r\n FROM (\r\n SELECT *,\r\n ROW_NUMBER() OVER(PARTITION BY lead_id ORDER BY updated_at DESC) as num_,\r\n FROM `Differture.amocrm_leads_snapshot`\r\n ) s\r\n LEFT JOIN (\r\n select cast(al.amo_id as INT64) as lead_id, cast(ac.amo_id as INT64) as contact_id,\r\n ac.name, emails as email, phone, student_id, ic.intercom_id,\r\n ROW_NUMBER() OVER(PARTITION BY al.amo_id ORDER BY ac.amo_id) as num1_\r\n from `Differture.AmoContacts` ac\r\n left join `Differture.AmoLeads` al on al.amo_contact_id=ac.id\r\n left join `Differture.IntercomContacts` ic using(student_id)\r\n , unnest(ac.emails) emails\r\n ) ac using(lead_id)\r\n WHERE (num_=1 or num_ is null) and (num1_=1 or num1_ is null)\r\n and s.pipeline_id in (4920421,5245535) and s.status_id=142 and lower(s.lead_name) not like '%test%'\r\n )<\/code><\/pre>Теперь при создании общей таблицы о возвратах с данными из amo, Thinkific и Discord объединение проходило через student_id:<\/p>\n
th_amo_ds_rf as (\r\n select distinct * except (channel_id, channel),\r\n ifnull(channel_id, 'Not in discord') as channel_id,\r\n ifnull(channel, 'Not in discord') as channel\r\n from thinkific_amo_refunds\r\n full outer join discord using(student_id)\r\n )<\/code><\/pre>Когда объединенные таблицы данных студентов были созданы, получить таблицы несовпадений можно было простой строкой кода в Tableau:<\/p>\n
<\/p>\n
Пустое значение поля student_id означает, что мэтча не случилось — где-то информация расходилась слишком сильно и не подтянулась в таблицы с идентификатором. Раньше, до введения идентификатора, поиск был таким же, но обращался к полям почты, телефона или имени-фамилии.<\/p>\n
Ниже можно увидеть таблицу, где данные из Thinkific не совпадали с amoCRM после перехода на Student ID. В этом случае студент есть в LMS, значит, на курсе учится — но его либо нет в системе учета, либо данные в ней разнятся с LMS.<\/p>\n
<\/p>\n
А вот таблица, где данные из Discord не совпадали с amoCRM. Все так же, как выше — студент есть в чатах сопровождения, но не ищется по своим данным в amoCRM.<\/p>\n
<\/p>\n
Оба скриншота показывают количество несовпадений примерно за месяц. Как видно по этим таблицам, количество несовпадений уменьшилось с 80-90 до пары десятков — примерно на 75%. Это позволило сократить количество перезапусков кода выгрузки вручную и уменьшить затраты времени и технических ресурсов на поддержание системы.<\/p>\n
Выводы<\/h2>\n
Сквозной идентификатор — эффективное решение проблемы мэтчинга персональных данных. Он позволяет максимально автоматизировать процесс отслеживания и устранения несовпадений или дубликатов клиентских сущностей при выгрузке данных для анализа. В случаях, когда объем данных в системе невелик, а у компании нет возможности выделить ресурсы на реализацию такого решения, можно воспользоваться и другими вариантами. Например, алерты в оркестраторе процессов хорошо справятся в ситуации, когда объединить данные — вопрос ручного запуска одного скрипта раз в неделю. Но сквозной идентификатор — наверное, самое универсальное из доступных решений, которое покроет большинство ошибок и заметно уменьшит погрешность в качестве данных.<\/p>\n",
"date_published": "2024-09-16T17:57:31+03:00",
"date_modified": "2024-09-16T17:57:05+03:00",
"image": "http:\/\/test.leftjoin.ru\/pictures\/students.png",
"_date_published_rfc2822": "Mon, 16 Sep 2024 17:57:31 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "148",
"_e2_data": {
"is_favourite": false,
"links_required": [
"system\/library\/highlight\/highlight.js",
"system\/library\/highlight\/highlight.css",
"system\/library\/highlight\/highlight.js",
"system\/library\/highlight\/highlight.css",
"system\/library\/highlight\/highlight.js",
"system\/library\/highlight\/highlight.css",
"system\/library\/highlight\/highlight.js",
"system\/library\/highlight\/highlight.css"
],
"og_images": [
"http:\/\/test.leftjoin.ru\/pictures\/students.png",
"http:\/\/test.leftjoin.ru\/pictures\/image-2.png",
"http:\/\/test.leftjoin.ru\/pictures\/filter.png",
"http:\/\/test.leftjoin.ru\/pictures\/unnamed.png",
"http:\/\/test.leftjoin.ru\/pictures\/discord.png"
]
}
},
{
"id": "147",
"url": "http:\/\/test.leftjoin.ru\/all\/kak-pereverstka-pomogaet-prevratit-horoshiy-dashbord-v-otlichny\/",
"title": "Как переверстка помогает превратить хороший дашборд в отличный",
"content_html": "
<\/p>\n
В кастомных системах сквозной аналитики конечный продукт, с которым взаимодействует пользователь — дашборды. Он не видит хранилище, витрины данных, скрипты, а дашборды видит каждый день, поэтому важно сделать их не только функциональными, но и понятными. Не всегда удается сразу нащупать оптимальный вариант, и полезно вести работу поэтапно.<\/p>\n
Дело в том, что в современных BI-тулах, которые мы используем — в частности, в популярном Tableau — возможности кастомизации гораздо шире, чем может себе представить сотрудник, мигрирующий с excel-таблиц. Часто пользователь просто не знает, каким вообще может быть дашборд и как составить ТЗ.<\/p>\n
В итоге дашборд содержит огромное количество данных, но возможность их продуктивно использовать спрятана за фильтрами, визуальной сложностью, долгой загрузкой.<\/p>\n
Именно такая ситуация сложилась у нас в процессе работы с образовательным стартапом Refocus.<\/p>\n
Один из главных их дашбордов — обзор SLA (Service Level Agreement).<\/b> Его пользователи — руководители отдела продаж и сейлз-менеджеры. Именно здесь их интересует прежде всего скорость обработки входящих лидов в зависимости от ряда факторов, от источника лида до региона.<\/p>\n
Нормативное значение этого показателя для Refocus — 15 минут, значит, там, где он выше, есть потенциал для оптимизации процессов и роста выручки.<\/p>\n
Мы работаем над дашбордами итеративно:<\/b> интервью с пользователем — прототип — фидбэк — следующая версия — фидбэк, и так далее. Но в случае с SLA после утверждения финальной версии остались нерешенные аналитиками функциональные проблемы.<\/p>\n
У заказчика было желание оптимизировать дашборды и бюджет на это, так что мы предложили общую переверстку и подключили к проекту датавиз-эксперта.<\/p>\n
Версия 1: с чем мы работаем<\/h2>\n
Первая версия SLA-дашборда, которой некоторое время пользовался клиент, выглядела так:<\/p>\n
<\/p>\n
В фокусе три графика:<\/p>\n
\n- Скаттерплот по времени ответа<\/b> с момента получения лида.<\/li>\n
- Гистограмма по медианному времени ответа.<\/b><\/li>\n
- Гистограмма по средней длительности первого звонка<\/b> с лидом.<\/li>\n<\/ol>\n
Справа — 15 фильтров, от региона и гранулярности до имени сотрудника, работавшего с лидом.<\/p>\n
Сверху — много текста, поясняющего тонкости работы с фильтрами по времени.<\/p>\n
Задача<\/h2>\n
Представьте, что ваш технический бэкграунд испарился, и вы на месте пользователя: о чем вам говорят эти графики? Сколько кликов вам нужно совершить, чтобы оценить перформанс подчиненных в вашем отделе? Чтобы сравнить SLA для лидов из разных источников? Ясен ли текст-легенда?<\/p>\n
А главное — есть ли у вас понимание, как сделать понятнее и что сказать исполнителю проекта?<\/p>\n
У аналитиков в этой области может быть слепая зона — нам-то на картине выше все понятно. А в прямые задачи датавиз-спеца входит проинтерпретировать запрос пользователя в контексте существующего функционала и создать визуализацию на стыке предпочтений заказчика и здравого смысла.<\/p>\n
Важно определить и причины этих проблем. Иногда ошибки — просто неудачная попытка выполнить запрос заказчика. Конечно, всегда можно отмести «плохой» запрос и сделать, как правильно — но тогда можно потерять важные для заказчика функции.<\/p>\n
Проблемы этого дашборда:<\/b><\/p>\n\n- Основной график — скаттерплот с SLA для всех лидов — выстроен на логарифмической шкале по оси Y без возможности переключиться на линейную. Есть сомнения, что все сейлз-менеджеры, глядя на дашборд, понимают, как работает логарифмическая шкала.<\/li>\n
- При выборе гранулярности по неделям масштаб позволяет показать распределение точек на оси X по дням — но они распределены случайно с помощью функции RANDOM().<\/li>\n
- Ось Y не синхронизирована между графиками, поэтому сложно оценить связь всех трех значений.<\/li>\n
- Невозможно сравнить медианный SLA по следующим параметрам: курс, источник лида, команда, сейлз-менеджер — все они расположены в фильтрах. Сравнение требует скриншотов разных отображений или нескольких вкладок с одним дашбордом.<\/li>\n<\/ul>\n
Установленные причины:<\/b><\/p>\n\n- Логарифмическая шкала: заказчик, который являлся только одним из юзеров дашборда, попросил реализовать логарифмическую шкалу, чтобы смотреть на значения SLA, близкие к нулю. Видимо, это было релевантно для целей именно его отдела.<\/li>\n
- Рандомное распределение по оси X: попытка сделать график проще и красивее, потому что скаттерплот уже перегружен информацией, и оценить распределение значений внутри недели — не приоритет.<\/li>\n
- Неэффективные фильтры: до ввода дашборда заказчик не знал, какие именно сравнения окажутся ему полезны.<\/li>\n<\/ul>\n
Итог — невозможно оценить общую картину SLA в компании в отдельно взятый период, а значит и корректировать процессы и стратегии продаж.<\/p>\n
Решение<\/h2>\n
Наш датавиз-специалист рисовал макеты карандашом на бумаге, а после утверждения переносил в Tableau: аналитический функционал и UX-дизайн для готового дашборда можно оптимизировать и без специальных тулов. Здесь хорошо ориентироваться на заказчика: если ему приятнее смотреть на файл в Figma — замечательно. Все понятно и на бумаге — отлично.<\/p>\n
Предложенные изменения:<\/b><\/p>\n\n- Фильтры справа сделать бар-чартами вместо выпадающих меню, чтобы разбивку по категориям было сразу видно.<\/li>\n
- Реорганизовать дашборд в соответствии с принципами дизайна, учитывающими движение глаз человека слева-направо, сверху-вниз.<\/li>\n
- Добавить линейную ось на скаттерплот, сделать именно ее форматом по умолчанию. Оставить возможность переключиться на логарифмическую ось.<\/li>\n
- Нормализовать шкалу X, убрав рандомное распределение точек.<\/li>\n<\/ul>\n
Версия 2: рабочая версия после переверстки<\/h2>\n
<\/p>\n
Что поменялось:<\/b><\/p>\n\n- В левой части дашборда появилась таблица-фильтр по командам и сейлз-менеджерам. По ней можно оценить показатели работы отдельных сотрудников и отделов и получить общее представление о том, как обстоят дела с SLA в компании — а именно это изначальное назначение дашборда.<\/li>\n
- В центральной части дашборда остался скаттерплот с SLA по всем лидам, только теперь формат отображения оси (линейная или логарифмическая) можно переключить.<\/li>\n
- Фильтры курсов, источников лидов и категорий превратились в кликабельные бар-чарты в правой части экрана. Они позволяют сразу визуально оценить медианный SLA по этим параметрам.<\/li>\n
- Все глобальные фильтры по категориям, которые нет необходимости сравнивать между собой, оказались в верхней части дашборда, там же — фильтр по дате. Теперь пространство экрана организовано эффективнее.<\/li>\n<\/ul>\n
Фидбэк:<\/b><\/p>\n\n- Потерялся график по средней длительности первого звонка.<\/li>\n
- На центральном графике исчезли отсечки с медианным SLA.<\/li>\n
- Не подписаны столбцы в таблице слева.<\/li>\n
- Центральный скаттерплот очень долго загружается при первом открытии дашборда, так как Tableau пытается вывести все лиды из датасета — по умолчанию ни один фильтр не применяется и никак не ограничивает количество информации для отображения.<\/li>\n
- Необходимы мелкие правки по оформлению и тултипам.<\/li>\n<\/ul>\n
Версия 3: доработки и брендирование<\/h2>\n
<\/p>\n
Что поменялось:<\/b><\/p>\n\n- В таблице слева появились подписи столбцов — теперь половина информации о работе отделов понятна при первом взгляде на дашборд.<\/li>\n
- Центральный скаттерплот теперь отображается только после выбора фильтра по команде или конкретному сейлзу — это снижает нагрузку на хранилище и сильно ускоряет загрузку графика.<\/li>\n
- Добавились отсечки с медианным SLA за конкретный период (месяц, неделю или день в зависимости от выбранной гранулярности).<\/li>\n
- Вернулся график с длительностью первого звонка.<\/li>\n
- Ось времени всех трех графиков теперь синхронизирована — не нужно сверять единицы измерения, чтобы выявить общие тренды.<\/li>\n<\/ul>\n
Когда функционал доработан и утвержден, вводится брендирование<\/b> по корпоративным гайдлайнам. Они у Refocus выглядели так:<\/p>\n
<\/p>\n
Обзор функционала<\/h2>\n
Итоговый дашборд стал гораздо проще в использовании и настройке, а функционал стал интуитивно понятен.<\/p>\n
Так выглядит финальный дашборд при открытии, пока не выбран ни один фильтр:<\/p>\n
<\/p>\n
А так, если выбрать сейлз-менеджера из таблицы слева:<\/p>\n
<\/p>\n
Использование фильтров справа (например, отобразить только лидов, пришедших с вебинаров):<\/p>\n
<\/p>\n
Тултипы со ссылкой на первоисточник на скаттерплоте с лидами (время в них отображается в минутах при выборе любой шкалы):<\/p>\n
<\/p>\n
Наконец, переключение между линейной и логарифмической шкалами:<\/p>\n
<\/p>\n
Этот кейс отлично демонстрирует важность чуткой работы с заказчиком. Всегда важен баланс между экспертностью и ориентацией на пользователя. Конечно, стоит показывать ему разные возможности и предлагать оптимальные с технической точки зрения решения. Но не менее важно доверять клиенту и разбираться в причинах его запросов, чтобы сделать по-настоящему полезно и красиво. Скажем, вдруг он просит логарифмическую шкалу не потому, что не подумал о других, а потому, что без нее в его отделе не обойтись? Внимание к таким моментам — огромный плюс к компетенциям аналитика.<\/p>\n",
"date_published": "2024-09-04T15:44:06+03:00",
"date_modified": "2024-09-04T15:43:37+03:00",
"image": "http:\/\/test.leftjoin.ru\/pictures\/1-32.png",
"_date_published_rfc2822": "Wed, 04 Sep 2024 15:44:06 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "147",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": [
"http:\/\/test.leftjoin.ru\/pictures\/1-32.png",
"http:\/\/test.leftjoin.ru\/pictures\/2-31.png",
"http:\/\/test.leftjoin.ru\/pictures\/3-27.png",
"http:\/\/test.leftjoin.ru\/pictures\/image-1.png",
"http:\/\/test.leftjoin.ru\/pictures\/0oblogka.png",
"http:\/\/test.leftjoin.ru\/pictures\/final.png",
"http:\/\/test.leftjoin.ru\/pictures\/leads.png",
"http:\/\/test.leftjoin.ru\/pictures\/web.png",
"http:\/\/test.leftjoin.ru\/pictures\/tip.png",
"http:\/\/test.leftjoin.ru\/pictures\/log.png.jpg"
]
}
},
{
"id": "112",
"url": "http:\/\/test.leftjoin.ru\/all\/zemfira-tableau\/",
"title": "Анализ альбомов Земфиры: дашборд в Tableau",
"content_html": "
![](\"http:\/\/test.leftjoin.ru\/pictures\/zemfira.png.jpg\")
<\/a><\/p>\nВ марте мы опубликовали исследование «Python и тексты нового альбома Земфиры: анализируем суть песен<\/u>»<\/a>, в котором при помощи Word2Vec-модели проанализировали близость песен альбома «бордерлайн» и получили самые близкие слова по духу альбома — ими оказались «пламень», «гореть», «тоска», «печаль», «сердце», «солнце» и другие.<\/p>\nМы продолжили работу над альбомами Земфиры и проанализировали семь из них, а затем результаты собрали в один дашборд и опубликовали его в Tableau Public<\/a>. Посмотрите, что получилось.<\/p>\nЗаглавная страница — общий анализ семи альбомов Земфиры. Переключиться на конкретный альбом можно по нажатию на его иконку внизу страницы. Для каждого альбома представлена матрица семантической близости песен, облако слов и топ схожих слов для альбома.<\/p>\n",
"date_published": "2021-07-08T13:56:12+03:00",
"date_modified": "2021-07-08T13:43:32+03:00",
"image": "http:\/\/test.leftjoin.ru\/pictures\/zemfira.png.jpg",
"_date_published_rfc2822": "Thu, 08 Jul 2021 13:56:12 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "112",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": [
"http:\/\/test.leftjoin.ru\/pictures\/zemfira.png.jpg"
]
}
},
{
"id": "101",
"url": "http:\/\/test.leftjoin.ru\/all\/coinkeeper-data-bot\/",
"title": "Бот для преобразования данных из Coinkeeper",
"content_html": "
\n![\"\"](\"http:\/\/test.leftjoin.ru\/pictures\/@2x-copy.png.jpg\")
\n<\/div>\nCoinkeeper<\/a> — кроссплатформенное приложение для учёта финансов. Внутри можно выпустить виртуальную банковскую карту Visa с бесплатным годовым обслуживанием, которая будет присылать уведомления, если вы тратите больше, чем запланировали. Помимо уведомлений, приложение ведёт историю трат и позволяет выгрузить сводный отчёт в формате csv. Данные, которое выгружает приложение ещё не готовы к анализу и выглядят так:<\/p>\n\n![\"\"](\"http:\/\/test.leftjoin.ru\/pictures\/1-27.png\")
\n<\/div>\nАзат Шарипов сделал скрипт обработки данных в пригодный для Tableau вид и подготовил Tableau Public книгу<\/a>, а Рома Бунин<\/a> в рамках своего проекта «Переверстка» переработал дашборд<\/a>.<\/p>\nМы решили тоже поучаствовать, и с нашей стороны Елизавета Мазурова сделала чат-бота<\/a>.<\/p>\nЧат-бот крутой! Помимо того, что он может как и прежде отдавать обратно .csv-файл, он позволяет автоматизировать рутину по обновлению отчета через Google-таблицы. Как, наверное, многие помнят, Tableau Public может работать на гугл-таблицах или csv файлах, но не разрешает подключение к данным. Бот умный: он создаст за вас гугл-таблицу и когда вы повторно отправите ему новый файл обновит ее.<\/p>\n
Использование бота<\/h2>\n
![\"\"](\"http:\/\/test.leftjoin.ru\/pictures\/2-26.png\")
\n<\/div>\n![\"\"](\"http:\/\/test.leftjoin.ru\/pictures\/3-22.png\")
\n<\/div>\n![\"\"](\"http:\/\/test.leftjoin.ru\/pictures\/4-13.png\")
\n<\/div>\n![\"\"](\"http:\/\/test.leftjoin.ru\/pictures\/5-14.png\")
\n<\/div>\n![\"\"](\"http:\/\/test.leftjoin.ru\/pictures\/6-14.png\")
\n<\/div>\n![\"\"](\"http:\/\/test.leftjoin.ru\/pictures\/7-8.png\")
\n<\/div>\n![\"\"](\"http:\/\/test.leftjoin.ru\/pictures\/8-9.png\")
\n<\/div>\n![\"\"](\"http:\/\/test.leftjoin.ru\/pictures\/9-8.png\")
\n<\/div>\n",
"date_published": "2021-03-09T17:28:36+03:00",
"date_modified": "2021-03-09T17:13:54+03:00",
"image": "http:\/\/test.leftjoin.ru\/pictures\/0@2x.jpeg",
"_date_published_rfc2822": "Tue, 09 Mar 2021 17:28:36 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "101",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": [
"http:\/\/test.leftjoin.ru\/pictures\/0@2x.jpeg",
"http:\/\/test.leftjoin.ru\/pictures\/@2x.png-1.jpg",
"http:\/\/test.leftjoin.ru\/pictures\/@2x-copy.png.jpg",
"http:\/\/test.leftjoin.ru\/pictures\/1-27.png",
"http:\/\/test.leftjoin.ru\/pictures\/2-26.png",
"http:\/\/test.leftjoin.ru\/pictures\/3-22.png",
"http:\/\/test.leftjoin.ru\/pictures\/4-13.png",
"http:\/\/test.leftjoin.ru\/pictures\/5-14.png",
"http:\/\/test.leftjoin.ru\/pictures\/6-14.png",
"http:\/\/test.leftjoin.ru\/pictures\/7-8.png",
"http:\/\/test.leftjoin.ru\/pictures\/8-9.png",
"http:\/\/test.leftjoin.ru\/pictures\/9-8.png"
]
}
},
{
"id": "91",
"url": "http:\/\/test.leftjoin.ru\/all\/radial-pie-v-tableau\/",
"title": "Radial pie в Tableau",
"content_html": "