Хабр, привет!
Меня расстраивает несправедливость в мире IT: для новичков-разработчиков есть куча пошаговых инструкций, о там, как разработать API или мобильное приложение. Хочу немного уровнять баланс вселенной, поэтому я написал небольшой гайд для аналитиков для составления документации.
В прошлой статье я представил шаблон, а теперь заполнил его для фичи «Экспресс-доставка товара в маркетплейсе». Моя цель – показать, как можно вести документацию и как правильно заполнять этот шаблон.
Всем привет! Меня зовут Дмитрий Миргород, и уже более 11 лет я работаю в digital-маркетинге.
В современных условиях гиперконкуренции и высокой динамики рынка, эффективность бизнеса во многом определяется способностью компаний принимать взвешенные и основанные на данных решения. Именно поэтому все больше организаций, стремящихся к росту и развитию, обращают пристальное внимание на концепцию сквозной аналитики.
Сквозная аналитика представляет собой комплексный подход к управлению бизнесом. В отличие от фрагментарных данных, которые дают традиционные инструменты веб-аналитики, сквозная аналитика обеспечивает совокупный сбор данных, позволяющий получить полную картину эффективности всех маркетинговых, продающих и клиентских процессов.
В данной статье мы рассмотрим, что представляет собой сквозная аналитика, какие возможности она предоставляет и как её внедрение может повысить эффективность и рентабельность бизнеса.
В сфере заказной разработки мобильных и веб-приложений встречаются разные способы организации работ и комбинации команд подрядчиков. Есть множество факторов, от которых это зависит: специфика проекта, области компетенций и квалификация подрядчиков, бюджет, сроки и еще куча подобных моментов. Единого стандарта нет и быть не может. Но есть часто встречающиеся комбинации, и одна из них: бэк на одном подрядчике, фронт – на другом.
Как раз об этой комбинации мы и хотим рассказать. Так что в этой статье поделимся собственным опытом и порефлексируем.
А чтобы картинка не получилась однобокой, сделаем мы это вместе: точку зрения команды бэкенда расскажет Наташа, системный аналитик (SA) компании Интаро, взглядом фронтенда поделится Лиза, аналитик (BA) компании Surf.
Привет! Меня зовут Полина, я руковожу A/B‑платформой в СберМаркете. В этой статье я расскажу о нескольких нюансах экспериментирования, которые возникают на разных этапах — от дизайна и сплитования до подведения итогов. Если их не учитывать, нам приходиться с осторожностью относиться к результатам или вовсе проводить эксперимент заново. К ним относятся Sample Ratio Mismatch, корректное пересечение тестов, взаимодействие нескольких экспериментальных механик и другое. Разберем как эти критерии обнаружить, найти причину и что делать с экспериментом дальше.
Рад представить вам свой первый проект, как мне думается, достаточно интересная работа, если рассматривать её как первый pet project.
Из-за санкций зарегистрировать аккаунт разработчика в App Store становится если не наказанием, то как минимум испытанием. Прочитайте эту инструкцию, прежде чем приступить к созданию Apple Developer. Рассказываем про нюансы с регистрацией и оплатой лицензии юридического лица.
Привет, Хабр!
Меня зовут Денис, я Ведущий Продуктовый Аналитик из МТС. Давайте сегодня поговорим про грейды в аналитике. Чем они отличаются? Расскажу, как можно быстро повышать свой грейд.
В целом, в разных компаниях разное понимание того, чем должен обладать тот или иной грейд. Однако, есть основные пункты, которые повторяются во многих командах, про них мы сегодня и поговорим.
Хабр, привет!
В начале своего пути я далеко не сразу смог понять, кто же такие эти ваши требования, как их писать и как они должны выглядеть? Предлагаю взглянуть на мое видение идеальной доки, покрывающие все аспекты проекта. Данный шаблон охватывает все аспекты проекта: бизнес-анализ, системный анализ и продуктовую аналитику.
Идеальная документация должна выполнять две основные функции...
Всем привет! Делюсь очередным выпуском нашей рубрики «Открытый микрофон», тема этого выпуска — «Как написать свою первую спецификацию на REST API».
Спикером стала Мария Яковлева. Маша — ведущий аналитик Платформы Сфера, НОТА (Т1 Консалтинг). В интернете много описаний особенностей архитектурного стиля REST, но мало информации о том, как аналитику начать создавать качественные спецификации на REST-методы. Маша поделилась своим опытом и, что особенно ценно, ошибками, допущенными в работе. А ещё Маша систематизировала их, чтобы уберечь вас от них)
Ниже предлагаю расшифровку трансляции, ссылку на сам выпуск оставлю в конце статьи.
Привет, Хабр!
A/B тестирование позволяет принимать обоснованные решения о том, какие функции или изменения наилучшим образом способствуют улучшению пользовательского опыта и повышению конверсии. Однако, несмотря на кажущуюся простоту проведения таких экспериментов, существует ряд подводных камней, которые могут серьезно исказить результаты. Один из самых заметных и опасных — это так называемая проблема peeking или подглядывания. Эта проблема возникает, когда аналитики и маркетологи начинают слишком рано анализировать данные теста, не дожидаясь его завершения. Такое поведение может привести к неверным выводам и решениям, которые, в свою очередь, могут нанести ущерб бизнесу.
В статье рассмотрим, что такое проблема подглядывания в контексте A/B тестирования как ее решить.
Всем привет! Меня зовут Вадим, и я QA-инженер в IT-компании Intelsy. С техническим заданием, и в частности с требованиями, лично я имею дело постоянно, поэтому собрал полезную для начинающих и продолжающих специалистов информацию по требованиям к IT-продукту, их видам, техникам и метрикам тестирования требований. На эту инфу стоит ориентироваться не только аналитикам и тестировщикам, но и остальным членам команды.
Привет, я работаю продуктовым аналитиком и мои задачи, в большей степени, связаны с анализом пользовательского поведения в продукте.
Пожалуй, чаще всего, мне приходится работать с разного рода исследованиями. В отдельную категорию можно выделить исследования интерфейсных решений, отдельных фичей или механик продукта. Это могут быть как новые релизы, так и старые фичи, до которых у команды раньше не дотягивались руки. Основной вопрос в таких задачах звучит примерно так: "Нравится ли юзерам то, что мы сделали, и приносит ли это нам деньги?"
Чем больше подобных задач я переделывал, тем яснее вырисовывались общие паттерны такого анализа. В итоге у меня сформировался небольшой “фреймворк”, который помогает наметить план детального исследования и не сложно адаптируется под разные продукты с разной спецификой.
Тут я расскажу о нём в общих чертах.
Kid-tech 一 это технологические решения и сервисы для детей. Одними из первых это направление начали развивать банки, увидевшие не только рыночную потребность, но и способ удерживать существующих клиентов, сохранять на их счетах больше средств, а также выстраивать долгосрочные отношения с детьми как новыми клиентами.
Детский банкинг быстро стал специализированным направлением, в котором правила и требования к продукту пока что формируются «на ходу». Разберемся, что нужно учесть при разработке банковского продукта, чтобы ему могли доверять и дети, и родители.
Всем привет! Меня зовут Вячеслав Назаров, я лид аналитики промо в СберМаркете. В этой статье я расскажу, как оценивать маркетинговые кампании, если провести A/B- тесты нельзя. Еще обсудим логику в Propensity Score Matching (PSM), и то, какую пользу инструмент может принести вашему бизнесу. А в конце статьи покажу, как достаточно просто можно развернуть такую штуку у себя.
По мотивам Adidas Running (ex. Runtastic)
Как я бы проектировал это интересное, но малоизвестное у нас приложение в роли архитектора.
Предыстория
Рынка систем электронных соревнований (в 2012 г) нет, но есть огромный интерес к спортивному образу жизни и к соревнованиям. В США не менее 50 миллионов (!) человек (это примерно 15% всего населения) хотя бы раз в неделю выходят на пробежку.
Адидас имеет объем продаж 20–30 млрд долл. в год.
Основной рынок – США, остальные страны – второстепенные рынки.
Текущий информационный мир полон не только возможностей, но и ограничений. Если вы работает в B2B и B2G, то не раз встречались с NDA от заказчика. Я расскажу о своем опыте в сфере аутсорсинг‑разработки: как выгодно пользоваться этим документом.
Привет! Меня зовут Ульяна Баисламова. Я старший продуктовый аналитик в команде B2b и оффлайн-опыта в СберМаркете.
Закрытие продукта (End-Of-Life, EoL) — естественная часть жизненного цикла сервиса или проекта, которая не обязательно связана с его несостоятельностью. В предыдущем материале мы с моим коллегой Андреем Максимовым рассказывали о том, как оценивать продукт на старте, что такое unit-экономика и какие инструменты помогают контролировать разработку в условиях, когда проект является стартапом.
Теперь хочется поговорить о критериях, которые необходимы, чтобы взвешенно принять решение о том, стоит ли инвестировать в развитие продукта и, если нет, как с минимальными потерями закрыть его, сохранить выручку и перераспределить освободившиеся ресурсы для других задач.
Статья будет полезна руководителям, аналитикам, продакт-оунерам, менеджерам проектов и всем, кто интересуется или связан с внедрением чего-то нового в маркетинге и разработке.
В предыдущих статьях статья 1, статья 2, статья 3 мы рассмотрели основные подводные камни автоматизации и анализу АБ тестов, привели подробный обзор статей по этой теме, а так же рассмотрели типичные задачи аналитика данных. В контексте АБ-тестов одним из ключевых аспектов является механизм разделения на группы, который в терминологии специалистов часто называется сплитовалкой.
Может показаться, что задача элементарная - сгенерировать случайное целое число каждому пользователю с вероятностью 1/n, где n - число групп в АБ тесте. Но на практике, особенно для высоконагруженных сервисов, таких как Ozon, возникает множество архитектурных и платформенных сложностей. В данной статье мы сконцентрируемся на основных принципах деления на группы, принятых в индустрии.
Привет, Хабр! Меня зовут Настя Рыбкина, я бизнес-аналитик в Спортмастер Лаб.
В бизнес-анализ я пришла около 1,5 года назад со сменой профессии, и, честно скажу, было нелегко разобраться поначалу, с чего стоит начать обучение, да просто чем вообще занимается бизнес-аналитик, чем он отличается от системного, потому что многие интерпретируют эти роли по-своему, и как ворваться в эту профессию.
Эта тема всегда актуальна, особенно для тех, кто на пороге смены карьеры или в поиске себя, поэтому мы с коллегами решили провести прямой эфир в "Со-обществе" Спортмастера на тему образования и карьеры для бизнес- и системных аналитиков, куда в качестве гостей позвали наших друзей, основателя STENET school Егора Марюшко и автора и лектора курсов для системных аналитиков Иннокентия Бодрова. Оба наших гостя помимо преподавательской деятельности несут миссию по созданию комьюнити для бизнес-, системных аналитиков, архитекторов и не только, где создают ламповую атмосферу, делятся своим опытом, рекомендуют книги, ресурсы и отвечают на любые вопросы подписчиков.
Всем привет! Я работаю продуктовым аналитиком уже чуть больше двух лет. Мой путь начинался со стартапа и сейчас уже почти год я работаю в так называемом бигтехе. В общем, в познании я немного преисполнился и успел осознать все свои ошибки на первой работе в качестве аналитика. Сразу скажу, эта статья не претендует на премию по технической сложности, она больше для тех, кто впервые оказался в продуктовой команде и не знает, как с этим быть. Итак, приступим.
В чём проблема работать аналитиком в стартапе? Когда это твоя первая работа – примерно во всём.
