Обновить

Давайте уже относиться к кино как к продукту, а к режиссёру – как к продакт-менеджеру

«И этого типа называют царём Вселенной?!» Сергей Эйзенштейн, 1913
«И этого типа называют царём Вселенной?!» Сергей Эйзенштейн, 1913

Кажется, пора перестать стесняться.

Если зритель – пользователь,
его внимание – ресурс,
первые минуты фильма – онбординг, клиффхэнгер – push-уведомление,
а успех сцены можно проверить по удержанию аудитории, то
режиссёру давно пора выдать Kaiten и квартальные KPI.

В конце концов, теория кино слишком долго всё усложняла.

У Эльзессера1 зритель постепенно обрастал телом, слухом, памятью, взглядом, мозгом. У Брэнигана он умудрялся ещё и думать: строил гипотезы, определял, кто видит и кто знает, пересобирал значение увиденного. Субъективная и объективная камера вообще к камере не относилась. 

К нашему зриетльскому пользовательскому счастью, IT позволило наконец избавиться от этой гуманитарной избыточности. Теперь мы точно знаем: на 17-й минуте зритель ушёл. Почему – вопрос факультативный.

И пока аналитика просто измеряет поведение после просмотра, ничего особенно интересного не происходит. Веселье начинается, когда метрика возвращается обратно в производство.

Зритель ушёл на длинной сцене – сократим. Не понял – объясним. Просел темп – добавим событие. Не хватает эмоционального вовлечения – выдадим эмоцию пораньше. 

Так форма наконец-то превращается в оптимизацию воронки. Продуктовый подход действительно умеет отвечать на вопрос, который теория кино решала значительно хуже: смотрит ли человек дальше? Продуктовая аналитика выяснила, что зритель делает с кнопкой play,  смотрит ли на х2 и в какой момент. Так что, возможно, режиссёр будущего (текущего?) действительно продакт не самого нужного продукта.

Главное – не забывайте проводить A/B-тест финала. В конце концов, если «целое» действительно гармонично складывается из «частей», это неплохо бы подтвердить на статистически значимой выборке.

Всё вышеизложенное является художественным вымыслом. Любые совпадения с реальными продакт-менеджерами, режиссёрами, платформами, метриками и квартальными KPI случайны. Ни один зритель в процессе оптимизации воронки не пострадал.

Теги:
Всего голосов 2: ↑2 и ↓0+4
Комментарии0

Почему UFW не спасает от Docker: анатомия сетевой подставы и что ищут боты в открытых портах БД

Типичная картина при переезде на свежий VPS. Подняли чистую Ubuntu или Debian под новый проект, сразу навели базовый порядок: ufw default deny incoming, снаружи оставили только 22, 80 и 443. Глянули ufw status — всё четко, лишнего не торчит. Дальше ставится Docker, через компоуз взлетает бэкенд с PostgreSQL и Redis. Чтобы удобно ходить в базу с ноута через DBeaver и гонять миграции, на автомате дописываем ports: - "5432:5432". Кажется, что мы в домике: наружу ничего не светит, фаервол же режет всё, кроме веба и SSH.

А через пару дней прилетает абуза от хостера или срабатывает алерт в мониторинге: все ядра в полке, в htop резвится какой‑нибудь kdevtmpfsi или kinsing, а вместо таблиц в базе лежит одна записка README_TO_RECOVER с биткойн‑кошельком. Грабли старые, как сам Docker. Но на них с завидной регулярностью наступают и джуны, и вполне опытные админы, привыкшие доверять выводу ufw status.

Почему UFW не спасает от Docker: анатомия сетевой подставы и что ищут боты в открытых портах БД

Публикации