ANDRON ALEXANYAN

Как UX влияет на удержание 🤑 Одна из важнейших вещей в любом онлайн-бизнесе - UX, то есть насколько пользователю удобно и интуитивно понятно пользоваться вашим продуктом. И не важно - это сервис заказа продуктов или онлайн-казино. Можно очень долго упарываться в retention и повышение среднего чека, делать всякие триггерные рассылки, качать реферальность и много еще чего, но если твой UX ужасен, то с каждой минутой использования пользователь будет все меньше теплых чувств испытывать к вам. И когда fuck-эмоций станет слишком много, он просто закроет сайт / удалит приложение и больше никогда не вернется к вам. Например, вчера, когда я готовился к вебинару по продуктовым метрикам, я искал кейсы разных топ-компаний - как они влияли на метрики вовлеченности. И нашел офигенный сайт, где в формате комиксов подробно разобраны разные составляющие UX (например, онбоардинг, активация аккаунта, работа с корзиной и т.д.). И каждый комикс - подробный разбор каждого кусочка UX-а с описанием: что сделано круто, что неправильно, как это влияет на эмоции человека и на продуктовые метрики. Офигенный пример - всем известный провал ковидных времен, социальная сетка Clubhouse. Ребята супер вирально взлетели, а потом также быстро все про них забыли. Почему так получилось (помимо объективных причин, что голосовой формат - довольно узкая история) - ребята подробно рассказали в этом комиксе, всем крайне рекомендую посмотреть! Отдельный респект этой команде growth.design за проделанную работу. Даже не представляю, как они вывезли производство такого количества комиксов с такой глубокой продуктовой проработкой. Считаю, что это заслуживает шеринга вашим друзьям и коллегам, чтобы как можно больше людей это увидели! Предлагаю запилить прям отдельную рубрику - если этот пост наберет 100 реакций черепов-огонечков 🔥, я сделаю подробный разбор одного из комиксов в текстовом формате здесь!

Когда на стриме обсуждали синдром самозванца и буст в карьере аналитика, я упомянул, что мы активно расширяем продуктовую линейку новыми курсами и симуляторами. Поэтому, если вам интересно стать автором уроков, практических заданий или поучаствовать еще в каком-то формате, прикрепляю ссылочку на форму. Там несколько вопросов - просто заполните ее и мы с вами свяжемся! https://forms.gle/XU89t4rAbEjs6EHS6 Спойлер: интересны специалисты разных уровней в области продуктовой аналитики, BI и DE. Стек инструментов супер вариативный - от Superset до Hadoop. Так что гоните синдром самозванца и давайте поработаем! 🔥🤑

Гайз, подъехала запись стрима 🔥 Без лица, но может оно и к лучшему 😁

Народ, мы стратовали, подключайтесь!

Друзья, по техническим причинам стрим проведем прямо в канале в 12:00, так что скоро увидимся, не переключайтесь 👋

Почему все аналитики - бесполезные сотрудники для компании? 🔥 Да потому что, очевидно, это не правда. Просто сами компании из-за сложных и неповоротливых процессов извращают процесс аналитики и он иногда играет им во вред. Ниже 3 конкретных примера, которые я увидел в 3 разных компаниях (которые вы точно знаете), общаясь с хедами их аналитиков. Затягивание процессов Вместо того, чтобы быстро катануть новую фичу в прод и замерить результаты по принципу "необходимо и достаточно", чтобы сделать выводы, компания полгода ждет, пока обновится A/B платформа. В результате - фича уже менее актуальна, стоимость разработки и поддержания выросла на 6 мес, за счет проведенной аналитики сэкономили в 10 раз меньше. Все создали видимость работы и навели суету. Классный результат. У кого усы длинней Т.к. аналитики оторваны от контекста, они зачастую думают не о задачах бизнеса, а у кого усы длинней. Ну точнее так: продуктовые - у кого сплитование точней, инженеры - у кого кафка длинней и хадуп толще, биайщики - у кого дэшик изящней. Все что угодно, только не про деньги. Да и менеджеры начинают играть в эти игры - вместо "мой отдел аналитики из 10 человек сделал вот такой офигенный результат, начинается: "а у меня сто тыщ аналитиков, прикинь, а ты лох, у тебя меньше". Хаос в данных Со временем, если на старте не сделали нормальную культуру сбора и хранения данных, энтропия только увеличивается. В итоге получается интересный эффект - чем больше аналитиков ты нанимаешь и чем больше работаешь, тем менее твоя аналитика точная (хотя должно быть наоборот). 💬 Ребят, а вообще, давайте соберемся и поболтаем) В комментарии задают много вопросов и еще не на все я успел ответить. Пора исправлять! Предлагаю в четверг, 4 июля, в 12:00 по Мск собраться в онлайне и провести Q&A-сессию: поотвечаю на ваши вопросы про аналитику, карьеру, перспективы, внедрение, можно какие-то хардовые темы обсудить. Чтобы записаться на веб, залетайте по ссылке - там без регистрации, смс и спама 👉 ссылка на вебчик Накидывайте вопросов в комментарии 👇

3 приема для борьбы с грязными данными 😝 Мне частенько приходится работать с данными, где на уровне аналитического хранилища "на вебинаре были люди, но по базе такого вебинара не было" или "человек купил курс, которого нет в бд". Чтобы такого не происходило, есть ряд хороших практик, которые нужно соблюдать, чтобы поддерживать данные в чистоте. Использовать типизацию в скриптах Все ваши скрипты в ETL-пайплайнах должны быть типизированы. Вы должны сходу, смотря на функцию, понимать - какой тип данных она принимает и какой возвращает. Например, что она возвращает число, а не строку. Иначе встречаются приколы - даты строкой, числовые ID строкой и так далее. А потом сиди и думай - почему не находится запись с id=100. А потому что в БД id="100". Я, кстати, и сам грешен - как правило, не делаю этого. А вот разработчики в моей команде - жесткие красавчики, делают это каждый раз. Аж завидую иногда их коду. А они смеются, что я лошара) Максимально все валидировать До того, как складывать данные в БД, их нужно всячески валидировать и чистить на уровне питон-скрипта. Например, приводить все телефоны к единому формату, а почты - к единому регистру. А еще проверять, что возраст в диапазоне Х/Y, пол - один из предложенных вариантов и так далее. Причем первично валидировать желательно еще на фронтенде (например, чтобы на сайте нельзя было ввести почту без собачки @). Потом дополнительно - в скриптах. Чем больше валидации, тем лучше - пусть она даже дублируется. На опыте - все равно какая-нибудь дичь пролезет в прод. Сделать отдельный дашборд с корнер-кейсами Прикольный хак, который не требует много времени и года разработки системы data quality, но позволит быстро увидеть косяки в данных, если они возникнут. Просто сделайте отдельный мини-дашборд, куда будете выводить все данные, которые потенциально могут сломаться. Можно даже просто в виде карточек с числами. Например: * Число дней, в которые была активность от пользователей, но нет информации о логине в этот день * Число продаж, где себестоимость больше розничной цены * Число пользователей, у которых почта указана без собачки или не ловеркейсом 💬 Вообще, конечно, инженерия данных - супер важный этап (и один из самых сложных). Одно дело запилить систему, которая будет собирать данные и в 100 раз сложней - чтобы эта система не дублировала данные, ничего не затирала, корректно обрабатывала изменения старым числом и т.д. Кстати, мы в Simulative сейчас делаем несколько новых курсов-симуляторов (расскажу про это позже) и ищем ребят, кто хочет приложить руку к их созданию. Если вы шарите в Spark, Hadoop, Airflow и вообще дата-инжиниринге - напишите мне в лс, поболтаем)

Кстати, давайте наберем на пост 100 реакций с лягухой-рокстаром 😎и как только мы завершим набор в Симулятор - я поделюсь результатами и расскажу - почему мы решили больше не набирать на него людей, прям с конкретными цифрами и расчетами))

Как-то я делал пост про то, что не надо быть «выгружателем табличек», типа это не круто. Круто делать выводы, преисполняться инсайтами и заниматься прочими важными вещами. Каюсь - немного переборщил. Грамотно собирать данные с 100500 источников, чистить их, ничего не терять по пути, а потом выгружать те самые таблички быстро под конкретный запрос бизнеса - супер важный навык. Не будете уметь этого - не из чего будет бэдтрип инсайты ловить) В последние несколько месяцев мы работаем сразу с несколькими компаниями, в которых настраиваем аналитику. Так вот огромная часть каждого проекта - сбор данных. Ниже несколько кейсов, с какими штуками мы столкнулись по пути, где чисто за счет знания Python мы сделали то, что ребята не могли сделать инхаус долгое время. Сбор данных с рекламных систем 🟢 Большая боль любого онлайн бизнеса - есть куча статистики по рекламе ВК, в Нельзяграмме, в Яндексе и других сетках. Но вся эта статистика находится внутри рекламных кабинетов и выгружать ее оттуда приходится ежедневно ручками, заполняя миллионы таблиц. Мы запарились и написали модули на Python, которые скачивают данные по API со всех этих площадок в нужном нам формате и готовят их к загрузке в базу. Теперь ты каждый день можешь приходить на работу и видеть заполненные отчеты, а не тыкать палочкой рекламщиков, чтобы они внесли данные. Плюс в любой момент можно посмотреть на данные в нужном разрезе - достаточно написать пару строк кода (или даже воспользоваться конструктором отчетов). Интеграция по API с внешними источниками 🟢 Лично мы (и не только мы) используем кучу разных сторонних сервисов - AmoCRM, Bizon, Teleboss, Bothelp и прочее. Сложность в том, что они между собой НИКАК не связаны. Соответственно, если Петя оставил заявку и провалился в AmoCRM, потом залетел в телеграм-бота, а потом пришел на вебинар в Bizon - для тебя это 3 совершенно разных Петра. А по факту-то Петя один и тот же. Но есть плюс - у каждого сервиса есть апишка, и с помощью Python вполне можно настроить сбор данных со всех источников и их консолидацию. Там тоже возникают свои сложности, но никакого rocker science в этом нет. Работа с 1С через Python 🟢 Мы даже в такое залезли)) Сначала мы хотели подключаться к 1С и с помощью SQL-запросов вытаскивать нужную инфу. Посмотрели, поняли, что это не очень классная идея и пошли иным путем. Настроили ежедневные выгрузки нужной инфы из 1С в csv-файлики, забираем их питоном с FTP, чистим и складываем в свое хранилище. Такой сценарий будет актуален примерно для 95% компаний из РФ, т.к. 1С у нас - база, а вменяемые отчеты там делать почти невозможно. Заключение 🟢 Короче, я к чему это. Инсайты инсайтами, а работать ручками и питонячими скриптами работать с данными - никто не отменял. Это надо уметь делать и причем очень хорошо. Все, что я описал выше - никакой магии в этом нет, достаточно иметь крепкую базу в Python и попрактиковаться делать аналогичные вещи - дальше пойдет, как по маслу. Кстати, в эту тему напоминаю, что мы продолжаем набор на Симулятор по Python. Осталось только 8 мест, дальше набор будет закрыт - скорее всего, больше набирать на него не будем. В нем вы с нуля получите все необходимые знания, чтобы делать проекты, которые я описал выше и похожие на них. Кроме того, итоговый проект в модуле по Python - в чистом виде кейс про интеграцию по API с внешними источниками. А дополнительно в Симуляторе есть модуль по автоматизации - научитесь настраивать работу скриптов по расписанию, чтобы все данные забирались и обрабатывались автоматически с утра без вашего участия, пока вы еще нежитесь в постельке)) А еще допом вы получите запись мастер-класса, где мы полностью разобрали задачу интеграцию с Bizon по API - про этот кейс я тоже сегодня писал. Короче, если вам нужно что-то оптимизировать / автоматизировать / собирать-чистить данные или вы просто работаете / планируете стать аналитиком - Симулятор Python вам отлично зайдет.