аналитика на кубах

Второй фреймворк продуктовой аналитики больше посвящен процессу разработки продукта и принятию решений. Он не столь строго сформулирован, как первый, но общую идею все же можно вычленить: “a framework that helps to gain clarity and confidence to develop a product while also providing an effective tool to communicate priorities to the team”.

Фреймворк четко связывается с этапами разработки продукта в периоде от концепции до начала оперирования и ключевыми задачами, которые стоят перед аналитиками на этих этапах. Грубо говоря, на какие вопросы должна отвечать аналитика в каждом периоде разработки проекта. Так, при работе с MVP (Minimum Viable Product) в сферу задач аналитиков входят следующие пункты:

- segment analytics (to better target their audience)
- customer journey mapping (touchpoints and interactions customers have with the product throughout their journey)
- core event logging (to identify critical success metrics that align with the product’s objectives)
- experimentation (to test hypotheses and refine the product)

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

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

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

❤6

www.tgoop.com/diceanalytics/105

1.41K viewsMar 22, 2024 at 06:13

Второй фреймворк продуктовой аналитики больше посвящен процессу разработки продукта и принятию решений. Он не столь строго сформулирован, как первый, но общую идею все же можно вычленить: “a framework that helps to gain clarity and confidence to develop a product while also providing an effective tool to communicate priorities to the team”.

Фреймворк четко связывается с этапами разработки продукта в периоде от концепции до начала оперирования и ключевыми задачами, которые стоят перед аналитиками на этих этапах. Грубо говоря, на какие вопросы должна отвечать аналитика в каждом периоде разработки проекта. Так, при работе с MVP (Minimum Viable Product) в сферу задач аналитиков входят следующие пункты:

- segment analytics (to better target their audience)
- customer journey mapping (touchpoints and interactions customers have with the product throughout their journey)
- core event logging (to identify critical success metrics that align with the product’s objectives)
- experimentation (to test hypotheses and refine the product)

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

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

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

BY аналитика на кубах