Аналитика мобильных приложений *

Привет! Я Рома, продуктовый аналитик в ОТП Банке. В этой статье я расскажу о том, как мы в Tribe Digital научились собирать и анализировать данные по маркетинговым кампаниям в мобильном приложении при помощи AppMetrica.

Байесовский подход применен к А/Б-тесту конверсий с 3 группами. Лучшая группа выбирается сравнением апостериорных распределений. Способ применим для других метрик и большего количества вариантов.

В этой статье я поделюсь своей историей: как я в одиночку пробивался в отечественном магазине приложений, сколько заработал и как странным образом Роскомнадзор оказался моим союзником в продвижении стартапа.
Читай дальше — сейчас всё расскажу!

Продолжаю изучать различные UI/UX/CX кейсы в мобильных приложениях, веб-сайтах и в реальном мире. Дизайнерам и менеджерам по продукту, чтобы вдохновиться и добавить в заметки.

Под катом: Кухня на районе, Дзен, Google, Яндекс.Еда.

▍ TL;DR

Генерацию гипотез через дерево метрик считаю одним из самых результативных подходов. Особенно значимым для меня тут является возможность отделить личное мнение от принятия решений. Этакое «я нерепрезентативен» на максималках. Лично для меня это важно ещё и потому, что почти во всех продуктах, над которыми я работала, я сама не являлась core‑пользователем.

На сами метрики мы смотрим фактически с тремя задачами:

Коллеги, всем привет! На связи команда Magnit Tech, меня зовут Михаил, я продуктовый аналитик в команде Foodtech мобильного приложения Магнит. В этой статье мы обсудим, как понять каким образом ваши пользователи доходят до выполнения целевых действий и как выявить в этом пользовательском пути негативные паттерны. А чтобы процесс обсчета пользовательских путей не занимал у вас десятки часов, мы научимся применять для решения этой задачи алгоритмы PrefixSpan и Seq2Pat.

UX-аналитика – это сбор и анализ данных о взаимодействии пользователей с интерфейсом (клики, скроллы, навигация и прочие события). Такие события генерируются в огромных количествах, особенно при большой аудитории приложения. Чтобы эффективно обрабатывать эту информацию, необходима распределённая архитектура, способная масштабироваться под высокий поток событий и обеспечивать отказоустойчивость – т.е. работать надёжно даже при сбоях отдельных компонентов. Также важна возможность обработки данных в реальном времени, чтобы как можно быстрее получать метрики и инсайты об опыте пользователей. В этой статье мы рассмотрим ключевые аспекты такой архитектуры: масштабирование UX-событий, надёжный сбор метрик с устройств (в том числе офлайн), реалтайм-аналитику на основе потоковых технологий (Kafka, Flink, Kafka Streams, ClickHouse) и механизмы гарантированной доставки событий (at-least-once, exactly-once, retry, дедупликация). В результате станет понятно, как правильно спроектированная система UX-аналитики позволяет оперативно находить проблемные места UI, проводить A/B тесты и глубже понимать поведение пользователей.

Я всегда любила схемы и таблички. Если нужно было разобраться в новом проекте/топике/проблеме — я рисовала схему этого. Если нужно было принять решение — делала таблицу. Если я не могла положить что-то в один из этих форматов, значит, нужно было копать тему дальше. В Miro накопилось десятки рабочих пространств. И всегда хотелось сделать основную, самую главную схему для продуктовой команды, которая позволяла бы быстро и чётко возвращать всех к единой цели с единым пониманием — куда, зачем и как именно копаем. Дерево метрик — самый действенный инструмент, который мне попадался. 

Что такое дерево метрик и зачем оно нужно?

Дерево метрик — это иерархическая структура, которая связывает бизнес-цель с подчинёнными метриками и действиями, помогая понять, какие показатели влияют на результат и где искать точки роста или проблемы.

Если просто: дерево метрик — это инструмент, который связывает:

Привет! С вами команда аналитиков «Пятёрочки» X5 Tech. В данной статье мы расскажем про один из классических тестов в статистике — тест Уэлча (Welch's Test). Постараемся максимально раскрыть, когда и где стоит его применять и является ли он, на самом деле, тестом по умолчанию вместо Т‑test-a.

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

Статья рассчитана в первую очередь на проекты с уже настроенной аналитикой, когда результаты собраны, но что делать с ними дальше вы не знаете. Вполне ожидаемо следующим шагом развития станут попытки повлиять на метрики каким-либо образом, естественно так или иначе вам придётся столкнуться с А/Б тестированием. Я попытался выделить общие подходы которые могут быть применимы к инди проектам когда разработка происходит в отсутствие квалифицированных специалистов и ограниченном бюджете. Ради этого придётся существенно пожертвовать точностью самих А/Б тестов, однако лучше хоть что-то чем совсем ничего, верно? В любом случае не нужно это рассматривать как основной подход для принятия решений об изменениях в проекте, а скорее как дополнительное направление для разработки когда других идей не осталось.

Ещё несколько лет назад любое приложение, установленное на устройство с Android, могло без разрешений видеть все остальные приложения.

В 2022 году, с выпуском Android 11, Google удалила этот доступ для разработчиков приложений. Согласно новой политике видимости пакетов, приложения должны видеть другие приложения только в том случае, если те необходимы для их базовой функциональности. Кроме того, разработчики должны явным образом объявлять эти приложения в обязательном для всех приложений Android файле конфигурации AndroidManifest.xml.

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

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

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

GrapheneOS — это операционная система с открытым исходным кодом (FOSS), основанная на проекте Android Open Source Project (AOSP), которая в первую очередь сосредоточена на улучшении конфиденциальности и безопасности. Хотя мы все хотели бы иметь наилучшую безопасность и конфиденциальность, к сожалению, такие улучшения редко приходят без потерь в удобстве и простоте использования. В этой статье мы рассмотрим, как максимально использовать улучшения Graphene и как эти меры влияют на пользовательский опыт, предлагая практические решения.

Эта статья является попыткой объединить информацию и знания о мобильной безопасности и конфиденциальности в рамках проекта GrapheneOS.

Продолжаю изучать различные UI/UX/CX кейсы в мобильных приложениях, веб-сайтах и в реальном мире. Дизайнерам и менеджерам по продукту, чтобы вдохновиться и добавить в заметки.

Под катом: BBVA, Duolingo, Google Photos, Wise, Дзен.

Привет! Я Настя — лид A/B Платформы в Wildberries. На протяжении всего карьерного пути меня интересует тема оценки эффектов. Для этого существуют различные инструменты, в числе которых как A/B-тестирование, так и альтернативные способы, например, различные вариации Causal Inference.

В этой статье я хочу поделиться примером проведения двух квази‑тестов в Wildberries с использованием Синтетического контроля (Synthetic Control), когда не получалось провести A/B‑тест, но все равно хотелось оценить эффект от изменений.

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

Складывается впечатление, что приложения и боты находятся в «слепой зоне», и, в отличие от сайтов, наполнение которых давно регламентировано, они обитают в отдельной вселенной, где работают отдельные правила… Только знаете, в чем правда? В том, что на территории Российской Федерации вселенная одна, а правила едины для всех: их установил Роскомнадзор, он же будет спрашивать с одинаковой строгостью их выполнение.