1/ Итак, аналитика :)
Мне кажется, что аналитика — это то немногое, что в том или ином виде есть в любом продукте. Без аналитики жить грустновато (хотя легко сделать аналитику так, что лучше бы ее не было совсем)
2/ Очень упрощенно аналитика состоит из:
- [1] понять, какие данные собирать
- [2] собрать и отправить их в какой-то data lake
- [3] сделать select * from data и радоваться жизни
3/ Наверняка чуваки из серьезных компаний проклянут меня за такие упрощения и будут правы, потому что между 1, 2 и 3 частенько пропасть и человекомесяцы на постройку мостов :)
Я упростил для контекста, расскажу про 1 применительно к эмбеду и гибридным продуктам, и немножко про 3
3/ В веб-сервисах и мобилках со сбором все несложно — есть куча готовых тулов с интеграциями, которые позволяют быстро настроить вообще все что угодно и наблюдать за юзерами со всех возможных углов, делать хитмапы и записывать сессии
4/ Если данные не хочется хранить, то их можно засылать напрямую в GA, MixPanel, FullStory, Amplitude и радоваться жизни (за бабло, конечно).
Но твой продукт это девайс + приложение + облако, и это собирается в непрерывный пользовательский опыт, местами бывает интересно
5/ Проблема 1, есть вот такой флоу:
- юзер открывает приложение
- нажимает кнопку
- кнопка инициирует шеринг контента на девайс
- девайс начинает шарить экран
Мы хотим трекать факт конца стриминга и metadata сессии.
Внимание, вопрос: кто в этом случае должен отправлять event?
6/ Предыдущий вопрос, как и почти все в IT не имеет правильного ответа, и можно делать все что угодно. Если данные отправляет только app, тогда:
- если стриминг прервался по network timeout, мы не узнаем о том, что об этой ситуации думает девайс, потому что на нем сессия могла умереть по любой другой причине (e.g. его ребутнули); мы никогда не замапим эти ребуты на network timeouts и будем думать, что стабильность хромает
- если app крашнулось во время сессии, то мы скорее всего поймаем краш репорт, но ничего не узнаем про саму стриминговую сессию
- не узнаем метаданные девайса (прошивку, платформу, etc.)
7/ Если же данные отправляет только девайс, то мы теряем из виду метаданные приложения (OS, версию приложения, и кучу полезных OS-specific данных)
8/ Получается, что для полноты картины надо либо сделать так, чтобы данные двух участников сессии шарились и отправлялись каким-то одним участником, либо отправлять 2 ивента от лица разных участников и соединять их между собой на будущее
9/ Проблема 2: нет готовых инструментов для сбора. Мы не можем взять JS интеграцию от GA/MixPanel, у нас абсолютно другая природа продукта и стек.
Сам по себе сбор — это просто что-то, что по триггеру положит JSON куда-нибудь в интернет.
Но, как обычно, есть нюансы
10/ Например, мы хотим считать, сколько раз девайс ребутнули.
Проблема в том, что просто триггернув event после команды ребута, легко отправить его в момент, когда ребут в самом разгаре, и доступа в интернет уже нет. Любое решение усложняет логику и его надо написать
Это все можно сделать и решить, и не то чтобы сложно, но не это приходит бесплатно (как бОльшая часть существующих решений аналитики на рынке)
11/ Но есть и то, что упрощает жизнь — девайсы не веб приложения, у них намного меньше контролов и состояний (а следовательно меньше событий, которые полезно анализировать)
Подход такой:
- маленькое количество ивентов с кучей метаданных
12/ Среди прочего мы трекаем boot/reboot/factory reset, стриминговые события, update (success/failure) + раз в день засылаем keep alive, чтобы считать, сколько чего находится онлайн
13/ Самое важное — аналитика по стримингу, особенно по сессиям с плохой оценкой от пользователя, или по сессиям, которые не завершились по инициативе пользователя
Второе самое важное — update failures, потому что они могут доставить юзеру ОЧЕНЬ много боли
14/ Все это жило своей жизнью и жило хорошо; а потом в уравнение добавилась облачная панель управления :) поэтому сейчас мы перестраиваем платформу, чтобы например дать возможность CS проактивно связаться с юзерами, у которых проблемы со стримингом, падают рейты или слабый сигнал