Ну смотрите, идеально должно быть так: продакт прорабатывает фичу, описывает продуктовое видение, заказывает макеты у дизайнера и обсуждает их с ним. Дальше макеты и вижн передается в отдельной задаче аналитику данных, и этот умнейшний товарищ, глядя на макеты, проходит своим опытным взглядом и покрывает все необходимое в интерфейсе списком событий.
На выходе у аналитика получается такая табличка, в которой описано название события, параметры события, смысл этого события. Дальше эта табличка отдается в задаче на разработку, и разработчик пишет код, чтобы из интерфейса отправлялись нужные события на бекенд, и из бекенда куда там дальше надо (в какой-нибудь брокер событий, например)
Пример очень простенький
Событие Like Смысл события – пользователь поставил "лайк" посту Параметры события double_tap – лайк поставлен двойным кликом по меда-изображению в посте icon_click – лайк поставлен кликом на иконке "сердечко" под постом
Как, например, нам может помочь это событие?
Ну, например, я хочу узнать, как много юзеров ставят лайк двойным кликом по фотке, и тут может окзаться, например, что пользователи ВК не знают про этот жест. Или же наоборот ставят его чаще всего.
Какие решения могут возникнуть в результате таких измерений?
Например, мы можем решить, что иконка "сердечко" нам не нужна, все равно все ставят лайк дабл-тапом. Мы выпилим сердечко, очистим место под фоткой. Или же мы узнаем, что люди не делают дабл-тап и запустим какой-то легкий онбординг, чтобы сообщить юзерам о том, как работает дабл-тап.
Проблемы с этим всем
Очень часто аналитик занят, и продакт описывает события сам. Делает это как понял, как умеет. Разработчик понимает требования продакта на свой лад. В итоге мы получаем, что какие-то события вроде бы есть, и смысл их вроде бы похож на тот, что был запрошен продактом. Но аналитик потом приходит и плюется. А собирать то все это в отчеты потом как раз аналитику!
Или же аналитик у нас не очень опытный, он не понимает, как покрыть событиями сценарий так, чтобы сделать это оптимально и достаточно и не наследить лишнего мусора в брокер событий (иными словами, не надо, чтобы трекалось все подряд!). Тогда аналитик приходит к продакту и говорит, расскажи, а что вы считать-то хотите. А продакт на момент запуска не знает до конца, что ему может понадобиться в данных. Обычно мы знаем про какие-то основные цели на запуске, но потом, как правило, сталкиваемся с чем-то новеньким в процессе теста, и вот это бывает непредсказуемо. Опытный продакт может многое предугадать, но не все!
Как это решается?
Опытный и классный аналитик в команде – это счастье для продакта. С таким надо обниматься и ходить в бары. Повышать ему зарплату, хвалить и лелеять. Потому что аналитик – это правая рука продакта. В идеале, хороший аналитик смотрит на макеты и сразу видит, что надо покрыть событиями. Ему даже не надо все продуктовые метрики знать и не надо точного ТЗ типа "что будем змерять". Он просто знает, как покрывать событиями UX. В дальнейшем могут возникнуть доп. запросы и всякие заковыристые штуки, но базу хороший аналитик должен уметь покрыть.
Как вам пост? Поставьте 🔥, если полезно. А то я что-то теряю мотиваицю такие предметные практичные посты писать.
Ну смотрите, идеально должно быть так: продакт прорабатывает фичу, описывает продуктовое видение, заказывает макеты у дизайнера и обсуждает их с ним. Дальше макеты и вижн передается в отдельной задаче аналитику данных, и этот умнейшний товарищ, глядя на макеты, проходит своим опытным взглядом и покрывает все необходимое в интерфейсе списком событий.
На выходе у аналитика получается такая табличка, в которой описано название события, параметры события, смысл этого события. Дальше эта табличка отдается в задаче на разработку, и разработчик пишет код, чтобы из интерфейса отправлялись нужные события на бекенд, и из бекенда куда там дальше надо (в какой-нибудь брокер событий, например)
Пример очень простенький
Событие Like Смысл события – пользователь поставил "лайк" посту Параметры события double_tap – лайк поставлен двойным кликом по меда-изображению в посте icon_click – лайк поставлен кликом на иконке "сердечко" под постом
Как, например, нам может помочь это событие?
Ну, например, я хочу узнать, как много юзеров ставят лайк двойным кликом по фотке, и тут может окзаться, например, что пользователи ВК не знают про этот жест. Или же наоборот ставят его чаще всего.
Какие решения могут возникнуть в результате таких измерений?
Например, мы можем решить, что иконка "сердечко" нам не нужна, все равно все ставят лайк дабл-тапом. Мы выпилим сердечко, очистим место под фоткой. Или же мы узнаем, что люди не делают дабл-тап и запустим какой-то легкий онбординг, чтобы сообщить юзерам о том, как работает дабл-тап.
Проблемы с этим всем
Очень часто аналитик занят, и продакт описывает события сам. Делает это как понял, как умеет. Разработчик понимает требования продакта на свой лад. В итоге мы получаем, что какие-то события вроде бы есть, и смысл их вроде бы похож на тот, что был запрошен продактом. Но аналитик потом приходит и плюется. А собирать то все это в отчеты потом как раз аналитику!
Или же аналитик у нас не очень опытный, он не понимает, как покрыть событиями сценарий так, чтобы сделать это оптимально и достаточно и не наследить лишнего мусора в брокер событий (иными словами, не надо, чтобы трекалось все подряд!). Тогда аналитик приходит к продакту и говорит, расскажи, а что вы считать-то хотите. А продакт на момент запуска не знает до конца, что ему может понадобиться в данных. Обычно мы знаем про какие-то основные цели на запуске, но потом, как правило, сталкиваемся с чем-то новеньким в процессе теста, и вот это бывает непредсказуемо. Опытный продакт может многое предугадать, но не все!
Как это решается?
Опытный и классный аналитик в команде – это счастье для продакта. С таким надо обниматься и ходить в бары. Повышать ему зарплату, хвалить и лелеять. Потому что аналитик – это правая рука продакта. В идеале, хороший аналитик смотрит на макеты и сразу видит, что надо покрыть событиями. Ему даже не надо все продуктовые метрики знать и не надо точного ТЗ типа "что будем змерять". Он просто знает, как покрывать событиями UX. В дальнейшем могут возникнуть доп. запросы и всякие заковыристые штуки, но базу хороший аналитик должен уметь покрыть.
Как вам пост? Поставьте 🔥, если полезно. А то я что-то теряю мотиваицю такие предметные практичные посты писать.
BY Продукт, IT и жизнь / Александра Кочанова
Warning: Undefined variable $i in /var/www/group-telegram/post.php on line 260
The Dow Jones Industrial Average fell 230 points, or 0.7%. Meanwhile, the S&P 500 and the Nasdaq Composite dropped 1.3% and 2.2%, respectively. All three indexes began the day with gains before selling off. What distinguishes the app from competitors is its use of what's known as channels: Public or private feeds of photos and videos that can be set up by one person or an organization. The channels have become popular with on-the-ground journalists, aid workers and Ukrainian President Volodymyr Zelenskyy, who broadcasts on a Telegram channel. The channels can be followed by an unlimited number of people. Unlike Facebook, Twitter and other popular social networks, there is no advertising on Telegram and the flow of information is not driven by an algorithm. But the Ukraine Crisis Media Center's Tsekhanovska points out that communications are often down in zones most affected by the war, making this sort of cross-referencing a luxury many cannot afford. In 2018, Russia banned Telegram although it reversed the prohibition two years later. WhatsApp, a rival messaging platform, introduced some measures to counter disinformation when Covid-19 was first sweeping the world.
from sa
