Ну смотрите, идеально должно быть так: продакт прорабатывает фичу, описывает продуктовое видение, заказывает макеты у дизайнера и обсуждает их с ним. Дальше макеты и вижн передается в отдельной задаче аналитику данных, и этот умнейшний товарищ, глядя на макеты, проходит своим опытным взглядом и покрывает все необходимое в интерфейсе списком событий.
На выходе у аналитика получается такая табличка, в которой описано название события, параметры события, смысл этого события. Дальше эта табличка отдается в задаче на разработку, и разработчик пишет код, чтобы из интерфейса отправлялись нужные события на бекенд, и из бекенда куда там дальше надо (в какой-нибудь брокер событий, например)
Пример очень простенький
Событие 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
DFR Lab sent the image through Microsoft Azure's Face Verification program and found that it was "highly unlikely" that the person in the second photo was the same as the first woman. The fact-checker Logically AI also found the claim to be false. The woman, Olena Kurilo, was also captured in a video after the airstrike and shown to have the injuries. The gold standard of encryption, known as end-to-end encryption, where only the sender and person who receives the message are able to see it, is available on Telegram only when the Secret Chat function is enabled. Voice and video calls are also completely encrypted. Artem Kliuchnikov and his family fled Ukraine just days before the Russian invasion. However, the perpetrators of such frauds are now adopting new methods and technologies to defraud the investors. The regulator said it had received information that messages containing stock tips and other investment advice with respect to selected listed companies are being widely circulated through websites and social media platforms such as Telegram, Facebook, WhatsApp and Instagram.
from pl
