Ну смотрите, идеально должно быть так: продакт прорабатывает фичу, описывает продуктовое видение, заказывает макеты у дизайнера и обсуждает их с ним. Дальше макеты и вижн передается в отдельной задаче аналитику данных, и этот умнейшний товарищ, глядя на макеты, проходит своим опытным взглядом и покрывает все необходимое в интерфейсе списком событий.
На выходе у аналитика получается такая табличка, в которой описано название события, параметры события, смысл этого события. Дальше эта табличка отдается в задаче на разработку, и разработчик пишет код, чтобы из интерфейса отправлялись нужные события на бекенд, и из бекенда куда там дальше надо (в какой-нибудь брокер событий, например)
Пример очень простенький
Событие 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
But Telegram says people want to keep their chat history when they get a new phone, and they like having a data backup that will sync their chats across multiple devices. And that is why they let people choose whether they want their messages to be encrypted or not. When not turned on, though, chats are stored on Telegram's services, which are scattered throughout the world. But it has "disclosed 0 bytes of user data to third parties, including governments," Telegram states on its website. Overall, extreme levels of fear in the market seems to have morphed into something more resembling concern. For example, the Cboe Volatility Index fell from its 2022 peak of 36, which it hit Monday, to around 30 on Friday, a sign of easing tensions. Meanwhile, while the price of WTI crude oil slipped from Sunday’s multiyear high $130 of barrel to $109 a pop. Markets have been expecting heavy restrictions on Russian oil, some of which the U.S. has already imposed, and that would reduce the global supply and bring about even more burdensome inflation. These entities are reportedly operating nine Telegram channels with more than five million subscribers to whom they were making recommendations on selected listed scrips. Such recommendations induced the investors to deal in the said scrips, thereby creating artificial volume and price rise. In this regard, Sebi collaborated with the Telecom Regulatory Authority of India (TRAI) to reduce the vulnerability of the securities market to manipulation through misuse of mass communication medium like bulk SMS. But because group chats and the channel features are not end-to-end encrypted, Galperin said user privacy is potentially under threat.
from ua
