Привет! Меня зовут Даниил Климчук, я работаю в команде, занимающейся SDK для авторизации через сервисы экосистемы VK. В него входит несколько компонентов, а именно авторизация по протоколу OAuth 2.1, кнопка One Tap для авторизации в один клик, шторка с описанием сценария авторизации и поддержка авторизации через Mail и OK.
Представьте: вы придумали новый продукт и уверены, что он совершенно гениален. Вы ждете, что клиенты будут в восторге срывать товар с полок, деньги потекут рекой, а на горизонте наконец замаячит тот самый успешный успех. Но реальность дает пощечину: ваш продукт не покупают. Вы в отчаянии спрашиваете: «Почему?!», а в ответ слышите гору неудобной правды. Клиентам товар не нравится. И вообще, им это не нужно. Больнее всего то, что это можно было предотвратить.
Кастдев, или интервью с клиентами, — это спасательный круг, который убережет вас от провала. И работает это очень просто: нужно только заранее поговорить с клиентом. Дальше разберем подробнее.
Вы выпускаете Flutter-приложение и уверены в его качестве — но знаете ли вы, как им действительно пользуются люди? Где они отваливаются, какие функции игнорируют, а какие вызывают восторг? Без правильно выстроенной аналитики всё это остаётся догадками. В этой статье — не просто про Firebase и Mixpanel, а о том, как построить гибкую, масштабируемую архитектуру аналитики, которая не развалится с ростом проекта. Включая типобезопасность, поддержку нескольких вендоров и раздельные режимы для продакшна и разработки.
В мире успешного успеха, в который мы погрузились, где продакты рапортуют о новых достижениях в метриках, а топ-менеджеры, перечисляют какие преимущества дают их бизнес-функции. Мнение конечного пользователя, кажется, статистически ничтожным.
Я помню времена, когда требования были — понятнее, бюджеты на реализацию — жирнее, а команды — меньше/больше, что позволяло фокусироваться на действительно важных вещах, которые запоминались и западали в душу пользователям.
Их копировали, пересматривали и вводили как эталон.
Данную статью написали Александр Чекунков, Android-разработчик, и Антон Ушаков, аналитик. Мы работаем в СБЕРе и ежедневно взаимодействуем, чтобы превращать бизнес-требования в понятные, логичные и реализуемые решения. В своей работе мы ежедневно сталкиваемся с процессами формирования требований, их обсуждения, реализации и доставки фичи до промышленных стендов. От того, насколько правильно выстроена наша работа, напрямую зависит скорость и качество разработки продукта.
В этой статье мы рассмотрим зоны ответственности обеих ролей и покажем, как, по нашему мнению, должен выглядеть идеальный процесс взаимодействия. Наша цель — помочь командам выстроить прозрачное и продуктивное взаимодействие, избежать типичных ошибок и сделать совместную работу более эффективной.
Продолжаю изучать различные UI/UX/CX кейсы в мобильных приложениях, веб-сайтах и в реальном мире. Дизайнерам и менеджерам по продукту, чтобы вдохновиться и добавить в заметки.
Под катом: Youtube, Glovo, Intsagram, Tiny Glade.
Привет! Это команда Яндекс Практикума. Делимся подборкой от экспертов курсов по анализу данных — материалами, которые помогут погрузиться в контекст бизнеса, узнать, с какими метриками работают аналитики, и научиться рассчитывать эти показатели с помощью Python.
Привет! Я Рома, продуктовый аналитик в ОТП Банке. В этой статье я расскажу о том, как мы в Tribe Digital научились собирать и анализировать данные по маркетинговым кампаниям в мобильном приложении при помощи AppMetrica.
Байесовский подход применен к А/Б-тесту конверсий с 3 группами. Лучшая группа выбирается сравнением апостериорных распределений. Способ применим для других метрик и большего количества вариантов.
В этой статье я поделюсь своей историей: как я в одиночку пробивался в отечественном магазине приложений, сколько заработал и как странным образом Роскомнадзор оказался моим союзником в продвижении стартапа.
Читай дальше — сейчас всё расскажу!
Продолжаю изучать различные UI/UX/CX кейсы в мобильных приложениях, веб-сайтах и в реальном мире. Дизайнерам и менеджерам по продукту, чтобы вдохновиться и добавить в заметки.
Под катом: Кухня на районе, Дзен, Google, Яндекс.Еда.
Генерацию гипотез через дерево метрик считаю одним из самых результативных подходов. Особенно значимым для меня тут является возможность отделить личное мнение от принятия решений. Этакое «я нерепрезентативен» на максималках. Лично для меня это важно ещё и потому, что почти во всех продуктах, над которыми я работала, я сама не являлась core‑пользователем.
На сами метрики мы смотрим фактически с тремя задачами:
Коллеги, всем привет! На связи команда Magnit Tech, меня зовут Михаил, я продуктовый аналитик в команде Foodtech мобильного приложения Магнит. В этой статье мы обсудим, как понять каким образом ваши пользователи доходят до выполнения целевых действий и как выявить в этом пользовательском пути негативные паттерны. А чтобы процесс обсчета пользовательских путей не занимал у вас десятки часов, мы научимся применять для решения этой задачи алгоритмы PrefixSpan и Seq2Pat.
UX-аналитика – это сбор и анализ данных о взаимодействии пользователей с интерфейсом (клики, скроллы, навигация и прочие события). Такие события генерируются в огромных количествах, особенно при большой аудитории приложения. Чтобы эффективно обрабатывать эту информацию, необходима распределённая архитектура, способная масштабироваться под высокий поток событий и обеспечивать отказоустойчивость – т.е. работать надёжно даже при сбоях отдельных компонентов. Также важна возможность обработки данных в реальном времени, чтобы как можно быстрее получать метрики и инсайты об опыте пользователей. В этой статье мы рассмотрим ключевые аспекты такой архитектуры: масштабирование UX-событий, надёжный сбор метрик с устройств (в том числе офлайн), реалтайм-аналитику на основе потоковых технологий (Kafka, Flink, Kafka Streams, ClickHouse) и механизмы гарантированной доставки событий (at-least-once, exactly-once, retry, дедупликация). В результате станет понятно, как правильно спроектированная система UX-аналитики позволяет оперативно находить проблемные места UI, проводить A/B тесты и глубже понимать поведение пользователей.
Я всегда любила схемы и таблички. Если нужно было разобраться в новом проекте/топике/проблеме — я рисовала схему этого. Если нужно было принять решение — делала таблицу. Если я не могла положить что-то в один из этих форматов, значит, нужно было копать тему дальше. В Miro накопилось десятки рабочих пространств. И всегда хотелось сделать основную, самую главную схему для продуктовой команды, которая позволяла бы быстро и чётко возвращать всех к единой цели с единым пониманием — куда, зачем и как именно копаем. Дерево метрик — самый действенный инструмент, который мне попадался.
Что такое дерево метрик и зачем оно нужно?
Дерево метрик — это иерархическая структура, которая связывает бизнес-цель с подчинёнными метриками и действиями, помогая понять, какие показатели влияют на результат и где искать точки роста или проблемы.
Если просто: дерево метрик — это инструмент, который связывает:
