Ну смотрите, идеально должно быть так: продакт прорабатывает фичу, описывает продуктовое видение, заказывает макеты у дизайнера и обсуждает их с ним. Дальше макеты и вижн передается в отдельной задаче аналитику данных, и этот умнейшний товарищ, глядя на макеты, проходит своим опытным взглядом и покрывает все необходимое в интерфейсе списком событий.
На выходе у аналитика получается такая табличка, в которой описано название события, параметры события, смысл этого события. Дальше эта табличка отдается в задаче на разработку, и разработчик пишет код, чтобы из интерфейса отправлялись нужные события на бекенд, и из бекенда куда там дальше надо (в какой-нибудь брокер событий, например)
Пример очень простенький
Событие 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
In February 2014, the Ukrainian people ousted pro-Russian president Viktor Yanukovych, prompting Russia to invade and annex the Crimean peninsula. By the start of April, Pavel Durov had given his notice, with TechCrunch saying at the time that the CEO had resisted pressure to suppress pages criticizing the Russian government. "He has kind of an old-school cyber-libertarian world view where technology is there to set you free," Maréchal said. Two days after Russia invaded Ukraine, an account on the Telegram messaging platform posing as President Volodymyr Zelenskiy urged his armed forces to surrender. 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. As a result, the pandemic saw many newcomers to Telegram, including prominent anti-vaccine activists who used the app's hands-off approach to share false information on shots, a study from the Institute for Strategic Dialogue shows.
from no
