UI/UX — это вроде про интерфейсы. UX-исследования синонимичны маркетинговыми. UX копирайтеры разбираются с болями и ценностями аудитории для написания «буковок». UX-стратегия — что то из разряда продуктового менеджмента. А UX-маркетинг — это вообще что? Вся это новомодная терминология идет под эгидой, довольно, абстрактного понятия «Пользовательский опыт», с чем и предлагаю разобраться в данной статье.
Март принес с собой проблему: у некоторых клиентов начали подвисать страницы, на которых монолитный js был разделен на чанки. На таких страницах в основном бандле содержится минимум для отрисовки первого экрана, а остальные чанки мы загружаем отложено. Однако из-за неправильной приоритизации скриптов пользователи лишились некоторых функций нашего сайта. Поток жалоб множился, саппорт разрывался, маркетинг страдал больше обычного.
А сейчас немного остановимся и познакомимся: меня зовут Даша, я инженер по тестированию на платформе web в Иви. И я расскажу вам, как мы внедряли тестирование GTM в пайплайн разработки команды.
Сегодня мы рассмотрим простой базовый фреймворк для дизайна сплит-теста, который можно удобно использовать продуктовым аналитикам в своей работе. Разберем использование этого фреймворка, его теоретическую и математическую основу, и также поговорим о продуктовых аспектах заведения A/B-тестов — когда продакту и аналитику заводить A/B-тест не нужно. Вам понадобятся: представления о продуктовых метриках, знания python, первичные представления о математической статистике и чуточку воображения.
Привет. Я занимаюсь продуктовой аналитикой уже довольно давно, и так получилось, что чаще всего в работе мне прилетают именно продуктовые рисёрчи. Иногда нужно разобраться с какой-то фичей, которую никто никогда не изучал, иногда это моделирование перед какими-то изменениями, иногда просто раскопка какой-то проблемы.
По мере моего развития, я экспериментировал с разными подходами к таким задачам, пытался выработать удобный фреймворк, учась на предыдущих ошибках. Читал книги по теме и внедрял интересные идеи из опыта авторов.
Тут я хочу поделиться порядком действий, если хочешь — чек-листом, как я провожу аналитические исследования.
Получилось объёмно, и много где идеи очень простые. Но, как это обычно бывает, на некоторые этапы просто нет времени или желания, а в итоге может пострадать вся суть работы. Наливай чай, бери попкорн — приятного чтения.
Так получилось, что за всё время, что я использую в работе R, мне не доводилось рендерить markdown-файлы в формат PDF. Иногда я хранил наработки просто в фалах .R, а исследования оформлял в Google Docs, накидывая туда скринов из viewer-а. Иногда это был рендер в .html, с интерактивной графикой, или проекты Shiny в облаке Posit. Да мало ли вариантов.
Но в связи с некоторыми изменениями в форматах хранения аналитических артефактов, судьба привела меня к PDF.
“Дело-то не хитрое, просто меняем формат вывода в markdown” — подумал я. Однако всё оказалось не так просто: и тексты и ggplot не видят кириллицу, движок xelatex не находит кастомные шрифты, LaTeX вообще всё бесит.
Каждая проблема отдельно худо-бедно гуглится или решается через chatGPT, но намного больше информации как посадить markdown-PDF на китайский, чем на кириллицу.
Рассмотрим на примере классического markdown, а в конце реализация для Quarto.
Задача оценки нововведений в онлайн и мобильных приложениях возникает повсеместно. Один из наиболее надёжных и популярных способов решения этой задачи - двойной слепой рандомизированный эксперимент, также известный как АБ-тест.
На тему АБ-тестирования доступны как статьи на Хабре, так и целые книги (неполный список литературы в конце). В основе АБ-теста лежит следующая идея - случайно разделить пользователей на две или более группы, в одной из которых исследуемая функциональность выключена, а в других - включена. Затем можно сравнить метрики и сделать выводы.
Привет, Хабр!
Сегодня мы поговорим о временных рядах, и как мы можем работать с ними, используя ЯП R. Временные ряды позволяют понять динамику процессов, изменяющихся со временем, и предсказывать тенденции.
Сразу признаюсь: на старте у нас было всего 10 событий, которые мы могли отслеживать. И показывали они нам то, что мы и так знали.
Расскажу, как мы разогнались до 700 уникальных событий и выстроили систему разметки, которая стала фундаментом аналитики в нашем каршеринге; а ещё покажу все аспекты жизненного цикла события: от идеи и технической реализации до попадания в отчёт и получения инсайтов.
Сегодня мы продолжим погружение в тему оптимизации CRM маркетинга при рассылке промо-предложений и рассмотрим опыт применения RFM-сегментации для решения этой задачи в рамках сервиса доставки еды и продуктов питания Delivery Club, ныне присоединившегося к группе компаний крупного e-com сервиса.
Продолжаем нырять в тему АБ и разбираться как считают тесты в большинстве продуктовых команд, где нет отдельного АБ-департамента.
Если ты еще не видел, то глянь вот здесь про дизайн тестов, как принять гипотезу от менеджера и привести ее в формат документации.
Примеры будут на R, но если ты питонист, можешь найти эти темы у меня в ТГ, там версия для Python тоже присутствует.
А теперь про сам тест.
Поговорим про документацию АБ-тестов.
Я работал в разных компаниях продакт аналитиком, все они, естественно, проводят много экспериментов. У каждой команды свои методы и любимые критерии, но сейчас не об этом. Их все объединяла одна особенность -- нелюбовь к документированию дизайна теста.
В первый раз, когда я с этим столкнулся, я накидал базовый шаблон, по которому можно было бы понять, спустя время, а что вообще хотели сделать и что получилось. Со временем этот шаблон дополнялся и расширялся, потом сокращался и так кругами. Сейчас он в том формате, который я здесь покажу. На мой взгляд, оптимальный набор документируемых сведений.
Будет полезно как новичкам в тестированиях, так и командам, у кого документация тестов в приоритетах где-то рядом с деплоем в пятницу вечером. Приятного прочтения!
Этот невыдуманный рассказ о разработке моей командой на заказ необычного водного трекера (приложение ЗОЖ-тематики), который впоследствии стал своего рода пинком для проекта помасштабнее. Я расскажу о различных нюансах разработки, а также о том, до чего эволюционировала в итоге сама концепция. Быть может, начинающие IT-предприниматели или команды, которым интересен опыт своих коллег почерпнут из этой личной истории что-то для себя.
Приветствую! Меня зовут Громова Алена и я основатель компании мобильной разработки, существующей на рынке с 2018 года. До получения от компании-партнера заказа на водный трекер мы уже успели поработать в различных отраслях разработки. Уже были тогда в нашем портфолио маркетплейс, приложение для охраны больших периметров, блогерское приложение под многомиллионную аудиторию, но нигде еще не попадались столь нестандартные креативные задачи. Я расскажу об этом опыте (и не только об этом).
Всем привет! Меня зовут Сережа Казарян из команды CX-аналитики AI-центра Тинькофф. Мы используем ML-инструменты, чтобы кластеризовывать обращения клиентов, анализировать нотификации и ошибки, с которыми сталкиваются пользователи. Мы переводим их в понятные actionable-инсайты для бизнеса. Каждый день работаем над тем, чтобы клиенту стало приятнее и лучше.
Но как же измерить, что клиенту стало лучше? Один из очевидных ответов — замерить retention клиента. Но есть нюанс: созревание этой метрики может достигать нескольких месяцев или даже лет. Менее очевидный вариант — замерять лояльность клиента. Но определить, кто такой лояльный клиент, и научиться различать степень его лояльности — отдельная наука, которая может занять много времени и требовать итеративной поддержки.
Помогает концепция ага-момента. В интернете мало статей на эту тему, а еще меньше — с графиками и подсказками по практической реализации. Поэтому поделюсь своим пониманием этой концепции и расскажу, как мы находили метрику ага-момента в Тинькофф. Это был командный проект, и спасибо моим классным коллегам, что у нас все получилось. Ну а теперь — поехали!
Привет, Habr! Меня зовут Оля Плюта, я продуктовый аналитик маркетплейса Uzum Market. В этой статье я расскажу об иерархических деревьях ltree в PostgreSQL. Статья вводная, поэтому я постаралась сделать её максимально понятной и наглядной.
Собрали готовый чек-лист для разработчиков и веб-студий. Проанализировали лучшие статьи за год по разработке приложений на habr и vc.ru. А потом собрали вопросы, по которым эти статьи написаны.
Анализ конкурентов — это когда мы оглядываемся вокруг и смотрим, с кем мы делим рынок, чем они на нас похожи, что делают. Мы ищем удачные решения у конкурентов, подрезаем рабочие практики, анализируем успехи и ошибки.
К концу статьи вы узнаете:
1. Почему копировать — не лучшая затея;
2. Что делать, если конкурентов нет;
3. На что смотреть в чужих продуктах;
4. Зачем рассказывать пользователям о сильном конкуренте;
5. Как не стать унылой копией конкурентов.
Привет! Мы тут решили запустить очередной One Week Offer, на этот раз — для системных аналитиков и аналитиков данных, с 7 по 10 ноября. Если вам интересно — до 3 ноября зарегистрируйтесь на лендинге, и с вами свяжутся.
Почему нам нужны системные аналитики
Сейчас в SM Lab работает более 2000 человек, которые с нуля написали и запустили более 320 сервисов и систем. Аналитиков у нас сейчас — порядка 200 человек. Так что, как вы понимаете, работы для желающих ещё много, скучно не будет.
Работать можно как из офисов (пока можем предложить Москву, Санкт-Петербург, Краснодар, Липецк, Новосибирск, Екатеринбург и Воронеж), так и из дома, если вам больше по душе удалёнка, или же вашего города нет в списке.
Сложные заказчики и клиенты — это всегда “геморрой”, много нервов и проблем на всех стадиях проекта. Коммуникационный аспект в нашей работе всегда занимает существенное место. Отчасти, это из-за специфики, мы чаще создаем приложения для спорта и нередко сталкиваемся с непростой коммуникацией, как на этапе обсуждения проектов, так и в процессе реализации. Когда приходишь на этот рынок — начинаешь бороться за заказы, т.к. они часто “жирные” в финансовом плане, клиентами разбрасываться не приходится, особенно в начале пути. Это пост — попытка классифицировать тяжелых заказчиков и обобщить наш опыт работы с ними. Рассказать, что стоит делать в ситуациях, когда отказываться от сотрудничества не хочется, но коммуникация оставляет желать лучшего, и как не попасть в сложную ситуацию с конкретными типами сложных клиентов.
Как понять, будет ли прибыльным продукт, который ты хочешь запустить? Стоит ли вообще брать фичу в разработку? Как заранее предсказать эффект от неё? Такие вопросы часто встают перед менеджерами продукта и продуктовыми аналитиками. А особенно остро они звучат, когда вы разрабатываете фичу с нуля и у вас крайне мало данных, на которые можно опереться.
Привет! Меня зовут Андрей Максимов. Я руковожу группой продуктовых аналитиков в СберМаркете. Моя команда отвечает за опыт пользователей в офлайне и мы сталкиваемся с вопросами, заданными выше, если не каждый день, то уж каждую неделю точно.
Универсального ответа на них не существует, но я попробую дать наиболее исчерпывающий — тот, который основан на Unit-экономике. Именно такой подход мы выстроили внутри своей команды, им я и хочу поделиться в этой статье. Ещё дам удобный шаблон для расчёта экномики продукта и объясню, как им пользоваться.
Дисклеймер: цифры, которые я привожу ниже, конечно же, изменены (NDA никто не отменял), но на ход рассуждений это не повлияет.
