Когда речь заходит о фреймворках для метрик, всегда на ум приходит North Star Metric, AAARR и еще гугловский HEART. Но все они пытаются дать «волшебную таблетку» и не учат выбирать метрику именно для своей задачи. В итоге продукты начинают развиваться по чужим, непродуманным метрикам и гордо называть это data-driven подходом.

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

В рамках этого фреймворка работа с любой метрикой делится на 4 этапа: Goal (цель), Action (Действие), Metrics (Метрика) и Evaluation (Оценки). Его можно вписать внутрь NSM, AAARR и любых других систем метрик, потому что он универсален и просто помогает структурно думать. Расскажу, как с ним можно работать на основе простого, но реального примера. Побуду сейчас в роли продакта, а не аналитика.

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

Мой основной продукт — сервисный кабинет. Напрямую он не монетизируется, но экономит деньги компании и имеет некоторые репутационные задачи (у конкурентов есть и у нас должно быть). ❗️Его цель для себя я оцениваю так: он должен нравиться пользователям.

👩🏻‍💻 Action. Второй этап — действие. Пытаюсь понять, по какому действию я бы узнала, что кабинет клиентам нравится. Я снова не думаю о том, смогу ли я это посчитать. Просто пытаюсь понять, как я вижу, что моя цель достигнута. Идеально было бы, если бы пользователи мне сами хвалили мой продукт. Факт использования продукта в этом случае не будет индикатором — часть клиентов использует его исключительно из-за отсутствия для них альтернатив.

📈 Metric. Третий этап — метрика. Собрав в голове первых 2 этапа, я иду к аналитикам и задаю вопрос: «У меня есть продукт, цель его — нравиться пользователям. Понять, что он им нравится, я б смогла, если б они мне сказали. Такое оцифровать в метрику можно?» А они отвечают: «Легко, для этого же есть CSAT (показатель удовлетворенности). Внедряй опрос и считай». Супер, метрику выбрали. Многие тут и останавливаются ⛔️ А дальше просто считают, растят показатель, собирают отчеты. Но самое интересное впереди.

🔎 Evaluation. Последний этап — оценка. Я начинаю оценивать выбранную метрику с точки зрения возможных проблем. Все ли захотят проходить опрос CSAT? А та часть, которая пройдет, будет ли репрезентативной? Смогу ли я доверять данным? Вопросов без ответов может стать так много, что я вернусь на предыдущий этап и откажусь от CSAT. Или даже переосмыслю и цель своего продукта, и действие, которое показывает ее достижение.

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

Этот подход помогает избежать серьезных проблем:

• выбор метрики происходит от самого продукта. А не потому, что на курсах сказали, что всем надо использовать AAARR и считать ретеншн. При таком подходе маловероятно, что вы работаете «ради цифры», всеми способами бесцельно повышая ретеншн или MAU — в то время как цель продукта совсем в другом;
• продакт или аналитик не стопорится в самом начале, сталкиваясь с «аналитическим параличом», примеряя десятки метрик на свой продукт и пытаясь выбрать самую классную.
• он показывает, что работа с метрикой не заканчивается, когда вы на созвоне со стейкхолдерами ее согласовали. Метрику нужно регулярно вытаскивать на свет и разглядывать. Возможно, ее что-то искажает, или продукт её уже перерос. Это не страшно, просто проходим GAME заново 😉