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

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

Почему мобильное приложение — это база

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

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

Как мы работали раньше и почему ушли от готовых решений

Раньше мы работали с личным кабинетом на SharePoint и нативным мобильным приложением. Оно выполняло базовые задачи, но со временем стало очевидно: архитектура достигла предела масштабируемости, производительность просела, а развивать функционал стало сложно. Требуемую доступность 24/7 оно не обеспечивало.

Снова привет, Хабр!

разоблачение телеграм клиента Telega, что скрывается за оберткой обхода блокировок

В новом дайджесте происходит что-то серьезное: наложенные окна и 37 000 unit-тестов против Gradle, новый Flutter и эксперимент с эмоциональным банкингом, Developer Knowledge API от Google, опасности в Android, подводные камни миграции на Swift и многое другое. Заходите!

Это говорят не слабые дизайнеры.

Это очень распространенная проблема:

• Стартап без аналитики
• Отдел в корпорации, в котором есть только верхнеуровневые метрики или вообще никаких
• Клиент, который просто хотел красиво

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

В общем то решил я как-то попробовать перейти на Linux phone. Но решил сделать это тестово и дешевым способом, купил себе Xiaomi Poco X3 NFC за 5 тыс. руб на Авито, хорошенько потанцевал с бубнами и накатил себе Ubuntu Touch.

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

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

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

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

В AB-тестах нередко возникает желание смотреть на результат по ходу эксперимента: метрики обновляются, решения ждать долго, а если эффект уже очевиден, то зачем тянуть до конца. Но в этом месте легко допустить серьезную ошибку: регулярно пересчитывать обычное p-значение и завершать тест при первом p < 0.05. Такой подход повышает долю ложных срабатываний: иногда статистическая значимость появляется просто из-за случайных колебаний данных, даже когда реального эффекта нет.

В этой статье разбираем, почему так происходит, и что с этим делают в прикладной аналитике. Покажу, как устроено групповое последовательное тестирование (group sequential): вы заранее задаете несколько контрольных точек для подглядывания, а пороги принятия решения подбираются так, чтобы общий уровень ошибки первого рода по всему процессу оставался на заданном уровне alpha.

На простых формулах и наглядных графиках из симуляций сравним наивное подглядывание с корректной процедурой. А затем разберем два самых популярных набора порогов - Pocock и OBrien-Fleming: чем они отличаются, почему один вариант чаще завершает эксперимент раньше, а другой почти не дает принимать решения в начале, и как выбрать подходящий вариант под продуктовый процесс.

АБ-тесты — это дорого. Как проверять гипотезы, если у вас нет времени или трафика. АБ-тестирование давно закрепилось как «золотой стандарт» проверки гипотез. Но у него есть обратная сторона: это дорого, долго и требует огромного трафика для достижения статистической значимости. Иногда бизнес просто не может позволить себе ждать месяц, чтобы узнать, что кнопка «Купить» должна быть синей.

Показана численная близость -значений -теста, -теста и -критерия Манна-Уитни в А/Б-тестах вероятностям лучшей группы байесовских моделей. Соотношения выполняются несмотря на различия в определениях.

Возвращаюсь с первым дайджесте в этом году. В нем про SwiftLint в масштабах компании, Android и ICMP, стабильный Compose Hot Reload и следующие два года в области разработки программного обеспечения, японская игра о скачках, электроналиватор и многое другое. Заходите!

Когда релиз раскатан не на всех, классическая схема "до" и "после" начинает рушиться: метрика растет или падает одновременно из-за сезонности, внешнего фона и изменений в каналах, а не только из-за продукта. При этом AB теста может не быть, но данные по группам есть почти всегда: по гео, сегментам, кластерам, витринам.

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

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

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

Всем привет! Я — Ольга Матушевич, преподаватель онлайн-магистратуры «Дата-аналитика для бизнеса», а в прошлом наставница на курсе «Аналитик данных» в Яндекс Практикуме. И сегодня я расскажу, чем Copilot может помочь аналитику при создании дашбордов в Power BI: как работающему в компании, только приступившей к использованию BI-системы, так и обладателю обширного legacy.

После релиза метрика почти всегда меняется. Иногда это реальный эффект изменения, иногда - сезонность, маркетинг, внешний фон или просто шум. Если AB теста не было, а решение все равно нужно принимать, остается вопрос: как аккуратно оценить влияние релиза по истории метрики и не обмануться простым сравнением до и после.

В статье разбираю практический подход causal impact для случая, когда у нас есть одна метрика во времени и понятная дата изменения. Строим контрфакт (counterfactual) - прогноз того, какой была бы метрика без релиза - и сравниваем его с фактом. На этой основе считаем эффект в абсолютных значениях, накопленный эффект и относительный вклад в процентах.

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

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

Привет, Хабр! Продолжаю обозревать GitHub Actions на примере пет проекта для аналитика.

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

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

Под катом: Revolut, Forest, Airbnb.

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

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

Привет, Хабр!

Я — независимый разработчик, и хочу рассказать о своём open-source проекте ATMO NeuroYoga — мобильном приложении для заботы о нервной системе. Текущая версия 1.4.1 уже доступна и включает упражнения NeuroYoga breathing и интерактивные точки акупрессуры. Но главная цель проекта — ATMO Shield, полностью оффлайн инструмент для непрерывного мониторинга и защиты нервной системы на основе вариабельности сердечного ритма (HRV).

Времена сейчас тяжелые, я как пользователь iPhone, давно чувствую себя неполноценным пользователем смартфона в нашей юрисдикции. А с недавнего времени возглавил команду линуксоидов и потянуло меня на всё линуксовое. Решил, так скажем, стать пингвином. Все началось с того, что выкинул свой макбук, которым пользовался с 2015 года, купил хороший ThinkPad на Ryzen 7 и накатил туда Linux Mint 22.2 и, знаете что, радости моей нет предела, я прям кайфую и пропитываюсь духом опенсорса. Все таки, когда клиентам показываешь преимущества миграции на линукс с мака, есть нотка недоверия к таким ребятам. И для пущей линуксовости, уже второй месяц подумываю пересесть на линуксфон, а еще все это недоверие к корпоратам, подогревает мой интерес. В общем если с тем, как накатить Минт на ноут в целом сложностей нет, то с линуксфоном, не все так просто… погнали разбираться

В новом дайджесте последствия уменьшения приложений и новый шаг в передаче зависимостей Swift, улучшение доступности в Android-приложениях и перформанс, лёгкий и быстрый DI-контейнер, Offline-First приложения, ускорение загрузки экрана, больше рекламы в App Store и многое другое. Заходите!

Всем привет! Меня зовут Тимур, я платформенный Android-разработчик с опытом 5+ лет в ритейле и e-com.

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

Присаживайтесь, наливайте чай/кофе — поехали.