Warning: mkdir(): No space left on device in /var/www/group-telegram/post.php on line 37
Warning: file_put_contents(aCache/aDaily/post/product_and_life/--): Failed to open stream: No such file or directory in /var/www/group-telegram/post.php on line 50 Продукт, IT и жизнь / Александра Кочанова | Telegram Webview: product_and_life/1099 -
Ну смотрите, идеально должно быть так: продакт прорабатывает фичу, описывает продуктовое видение, заказывает макеты у дизайнера и обсуждает их с ним. Дальше макеты и вижн передается в отдельной задаче аналитику данных, и этот умнейшний товарищ, глядя на макеты, проходит своим опытным взглядом и покрывает все необходимое в интерфейсе списком событий.
На выходе у аналитика получается такая табличка, в которой описано название события, параметры события, смысл этого события. Дальше эта табличка отдается в задаче на разработку, и разработчик пишет код, чтобы из интерфейса отправлялись нужные события на бекенд, и из бекенда куда там дальше надо (в какой-нибудь брокер событий, например)
Пример очень простенький
Событие 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
"And that set off kind of a battle royale for control of the platform that Durov eventually lost," said Nathalie Maréchal of the Washington advocacy group Ranking Digital Rights. As the war in Ukraine rages, the messaging app Telegram has emerged as the go-to place for unfiltered live war updates for both Ukrainian refugees and increasingly isolated Russians alike. The S&P 500 fell 1.3% to 4,204.36, and the Dow Jones Industrial Average was down 0.7% to 32,943.33. The Dow posted a fifth straight weekly loss — its longest losing streak since 2019. The Nasdaq Composite tumbled 2.2% to 12,843.81. Though all three indexes opened in the green, stocks took a turn after a new report showed U.S. consumer sentiment deteriorated more than expected in early March as consumers' inflation expectations soared to the highest since 1981. "There are a lot of things that Telegram could have been doing this whole time. And they know exactly what they are and they've chosen not to do them. That's why I don't trust them," she said. After fleeing Russia, the brothers founded Telegram as a way to communicate outside the Kremlin's orbit. They now run it from Dubai, and Pavel Durov says it has more than 500 million monthly active users.
from us
