Какие метрики отслеживания эффективности мобильных приложений важны и почему

Метрики фичи

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

Примерами кастомных метрик могут быть:

• Количество кликов на кнопку Купить
• Время просмотра видео
• Количество совершенных покупок через конкретную функцию

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

Пользовательский retention

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

К примеру, удержание на следующий день (1-Day Retention) показывает процент пользователей, которые вернулись в приложение на следующий день после установки, а удержание на неделю (7-Day Retention) – процент пользователей, которые продолжают пользоваться приложением спустя неделю с момента установки.

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

Выводы

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

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

Продуктовые метрики

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

Кастомные показатели

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

Доля пользователей, которые воспользовались фичей

Рассчитывается как количество пользователей, которые воспользовались фичей, поделенное на общее количество пользователей.

Конверсия в целевое действие из фичи

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

Доля пользователей вернувшихся в фичу — retention для фичи.

Этот список можно продолжать бесконечно, так как всё зависит от конкретного приложения и его наполнения.

Технические метрики

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

Test Coverage

Плотность покрытия программного кода тестами — это процент кода, который проверили в ходе тестирования. Например, если этот показатель равен 78%, значит, 78% всего, что написали программисты, было проверено в ходе теста. У компании по разработке программного обеспечения метрика помогает понять.

Скорость загрузки страниц

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

ER-диаграмма

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

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

Если с ней что-то не так, возможно:

### Использование зрелого фреймворка

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

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

Хороший фреймворк дает следующие преимущества:

### Проверка дублирования кода

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

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

## Точность (Accuracy)

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

Пример: Предположим, у нас есть 100 объектов, из которых 95 принадлежат классу A, а 5 — классу B. Если наша модель классифицирует все объекты как класс A, точность будет равна 95%, хотя модель совершенно не учитывает объекты класса B.

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

MSE = (1/n) * ∑(ypred — ytrue)^2

## Какие метрики качества используются для оценки алгоритмов машинного обучения

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

Метрики качества алгоритмов машинного обучения

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

Коэффициент корреляции Пирсона

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

Значение данного коэффициента может варьироваться от -1 до 1, где:

• -1 означает полную обратную корреляцию
• 1 — полную прямую корреляцию
• 0 — отсутствие корреляции.

Метрики монетизации приложения

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

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

Средний доход на пользователя

Рассчитывается как общий доход, поделенный на количество пользователей.

Средний доход с одного платящего пользователя

Рассчитывается как общий доход, поделенный на количество платящих пользователей. Помимо систем аналитики, метрику можно посмотреть в App Store Connect.

Средний чек

Рассчитывается как общий доход, поделенный на количество покупок.

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

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

Конверсия в повторные покупки

Рассчитывается как количество повторных покупок, поделенное на количество покупателей.

Что делать дальше

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

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

Если вам нужно создать мобильное приложение, в Purrweb можно обратиться за разработкой программного обеспечения на заказ. Мы всегда готовы проконсультировать по любому вопросу — пишите!

Точность (Precision) и Полнота (Recall)

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

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

F1 = 2 * (Precision * Recall) / (Precision + Recall)

Как интерпретировать метрики?

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

Для примера возьмем приложение, где есть рекламная монетизация. На LTV влияют метрики: CTR (кликабельность баннеров рекламной монетизации), retention rate (возвращаемость пользователей) и длина сессии. Каждая из них может разбиваться на более простые метрики. Важно понимать, как можно повлиять на каждую метрику и что привело к тому, что LTV изменился.

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

Разберем два изменения метрик на примере.

Первый пункт — LTV вырос на 3%. Какие выводы из этого можно сделать? Представим, что 2 недели назад была добавлена фича: она помогла подрастить retention. Вторая причина — подключение пользователей из нового платного канала, они лучше монетизируются, тем самым повышая retention.

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

Пользовательские метрики

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

Customer Satisfaction Score

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

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

Это может быть важно для:

Net Promoter Score

Метрика NPS рассчитывается по ответу на вопрос «насколько вы порекомендуете сервис друзьям и знакомым?». Обычно предлагается оценить вероятность по десятибалльной шкале.

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

NPS дает понять, как много пользователей:

Retention Rate

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

Показатель возвращаемости нужен, чтобы:

Conversion Rate

Метрика разработки программного обеспечения показывает, сколько людей среди посетителей приложения совершили целевое действие. Это может быть подписка, покупка, клик по нужной кнопке — в качестве целевого действия можно выбирать то, что нужно в рамках конкретного анализа. Коэффициент конверсии рассчитывается в процентах. Скажем, всего на странице за день было 200 человек, из них 20 кликнули на нужную кнопку — выходит конверсия 10%.

У этой метрики одно назначение — понять, насколько привлекателен CTA-элемент для аудитории.

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

Adoption Rate

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

По метрике видно:

Как работать с метриками?

Мы разобрали метрики, которые чаще всего используются для оценки эффективности мобильного приложения. А как с ними работать? Для этого применяют фреймворки. Самые популярные — это AARRR или Pirate Metrics, HEART и North Star Metric.

Pirate Metrics (AARRR)

Метрики, которые берутся за основу в этом фреймворке помогают оптимизировать пользовательский опыт и измерить конверсии на каждом этапе. Цель Pirate Metrics — перевести потенциальных клиентов с одного этапа на другой: от привлечения (Acquisition) до желания рекомендовать (Referral).

Фреймворк AARRR не требует технических знаний, поэтому его легко использовать и опытным маркетологам, и новичкам-стартаперам.

Работать с этим фреймворком можно по следующему принципу: постановка цели на каждом этапе — выбор гипотез — подбор метрик, которые помогут оценить работу.

Pirate Metrics включает следующие этапы и метрики:

HEART

HEART позволяет «конвертировать» важные для бизнеса показатели в исчисляемые метрики, за которыми можно наблюдать в динамике.

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

North Star Metric (NSM)

Необходимо выбрать одну основную метрику (NSM), по изменению которой будет приниматься решение о достижении успеха или провале. Хорошая метрика North Star должна отражать стратегию и нести ценность для пользователя. На изменение этой метрики влияют и другие показатели. Основная цель при работе с данным фреймворком — внести вклад в метрику NSM.

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

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

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

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

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

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

Customer Journey Map для работы с метриками

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

Первый этап на CJM — это привлечение пользователя, затем он устанавливает приложение (install), дальше попадает в мобильное приложение и проходит онбординг (activation). После этого пользователь возвращается в мобильное приложение (retention) и решает свои задачи с помощью продукта, далее юзер монетизируется (monetization). В конце концов он влюбляется в ваш продукт, становится лояльным, рекомендует приложение друзьям (loyal).

Мы рассмотрим основные метрики, которые применимы к мобильному приложению, на основе CJM.

Обсудить стратегию продвижения

Маркетинговые метрики приложения

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

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

Показывает число уникальных пользователей, которые видели мобильное приложение. Можно посмотреть в Google Play Console — это посетители страницы приложения (пользователи, которые зашли на страницу приложения), в App Store Connect есть два показателя: показы (пользователь увидел иконку приложения в выдаче стора) и просмотры (пользователь зашел на страницу приложения).

Количество кликов. Уникальные переходы по клик-ссылке или агрегированная статистика из рекламных платформ. Метрика настраивается в системах трекинга и аналитики.

Конверсия из просмотра/показа в установку. Можно посмотреть в Google Play Console (из просмотра страницы в установку), App Store Connect (из показа иконки приложения в установку) или системах аналитики.

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

Менеджерские метрики

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

Burn Rate

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

График представляет собой кривые, идущие вниз: они показывают динамику решения задач. По шкале X отмечают количество дней до окончания спринта или до релиза. По шкале Y — число задач. Одна из линий графика демонстрирует то, как быстро планировалось выполнить работу. Вторая линия — то, как работа идет на самом деле. Диаграмма может выглядеть, например, так:

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

По диаграмме сгорания задач смотрят:

Хотите разобраться, чем полезна диаграмма сгорания задач на примере реального проекта? Читайте наш кейс:

Flow Efficiency

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

Например, если над задачей работали 3 дня, а еще 2 она «висела» в ожидании, когда разработчик для нее освободится, формула эффективности потока будет: 3/(2+3) *100%.

Эта метрика разработки программного обеспечения служит, чтобы:

Team Velocity

метрика разработки программного обеспечения демонстрирует, какой объем работы команда способна выполнить за спринт. Для вычисления показателя производительности в продуктовых командах используют стори поинты (story points) — с их помощью каждой задаче в бэклоге назначают вес в зависимости от ее сложности. Если вы работаете со студией, вместо стори поинтов оценка идет в часах: так всем проще и понятнее.

Сумма всех стори поинтов или всех часов за спринт — это и есть производительность.

Метрику используют, чтобы:

Среднее количество багов за спринт

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

Вот что можно увидеть по количеству багов за спринт:

Продуктовые метрики приложения

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

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

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

Затраты на привлечение пользователя. Рассчитывается как бюджет на привлечение, поделенный на количество пользователей.

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

Пожизненная ценность клиента. Это основная метрика, по которой можно судить, какую выручку принес каждый пользователь за период своей «жизни» в приложении.

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

Есть несколько способов расчета:

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

Рассчитывается как количество пользователей, вернувшихся в приложение в день N, делить на количество пользователей, установивших приложение (день установки — нулевой день), умножить на 100.

Например, у нас приложение с раскрасками, и мы решили узнать, как часто пользователи возвращаются в него. День установки считается нулевым днем — retention 100%. В первый день вернулось 50% пользователей, во второй — 25%, в 3 день — 75%, в 4 день — 0%, в 5 день — 25%, а в 5 день — 50%. Эти данные позволяют увидеть, в какой день пользователи возвращаются чаще или реже, найти причины и принять меры, чтобы замотивировать юзеров использовать приложение.

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

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

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

Разница Rolling Retention и N-day Retention

N-day Retention используется чаще Rolling Retention. Но бывают случаи, когда Rolling Retention намного удобнее. Например, для приложений, которые подразумевают редкое использование: сервисы бронирования авиабилетов и отелей.

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

Индекс потребительской лояльности. Метрика отражает приверженность клиентов к приложению, удовлетворенность от его использования.

Реализовывается через опросник, состоящий из одного или нескольких пунктов, каждый из которых оценивается по шкале от 0 (не нравится/не работает) до 10 (готов рекомендовать/всё понравилось). Вопросы формируются индивидуально, на основе предлагаемого продукта. Можно задать и один вопрос: насколько вы готовы порекомендовать приложение своим друзьям/знакомым/коллегам?

Отвечающих делят на несколько категорий:

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

Показатели ниже 20% — плохой результат, от 20% до 40% — средний результат, 40-70% — неплохо, но останавливаться на таком результате не стоит. Показатели от 70% и выше — хороший результат.

Как рассчитать метрики приложения?

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

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

Площадь под ROC-кривой (Area Under the ROC Curve, AUC-ROC)

ROC-кривая — это график, который показывает зависимость между чувствительностью (Recall) и специфичностью (1 — False Positive Rate) при различных порогах классификации. Площадь под ROC-кривой (AUC-ROC) является количественной характеристикой качества бинарной классификации и может принимать значения от 0 до 1. Чем выше значение AUC-ROC, тем лучше работает модель.

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

Список основных метрик для мобильного приложения

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