Монетизация это…

скачать книгу бесплатно

Монетизация это…
Алексей Мозголин

Данная серия статей с базовыми принципами монетизации основана на личном опыте работы с физическими и цифровыми продуктами, и носит исключительно ознакомительный характер

Монетизация это…

Алексей Мозголин

Данная серия статей с базовыми принципами монетизации основана на личном опыте работы с физическими и цифровыми продуктами, и носит исключительно ознакомительный характер

© Алексей Мозголин, 2024

ISBN 978-5-0062-7052-7

Создано в интеллектуальной издательской системе Ridero

акции, скидки и сезонные предложения

В период распродаж или перед какими-то крупными праздниками можно делать скидки на тематические товары, или оформлять сами предложения как-то по-особенному, или предлагать что-то, что не предлагается больше никогда, кроме как в этот период.

Например, неплохим вариантом может быть уникальное предложение с ресурсами в игре, ограниченная по времени или даже отложенная скидка на одну или несколько следующих покупок в магазине, или выбор категории в программе лояльности, на которую будет действовать скидка на протяжении всего периода акции, и так далее.

Но важно помнить, что сразу после этого может возникнуть, так называемое, «похмелье». Это когда некоторый период после будет резкое снижение среднего дохода из-за того, что пользователи купили все, что хотели купить. Особенно, если подобные акции происходят периодически, и уже не в первый раз. Поэтому важно сохранять баланс, и не гнаться за высоким доходом здесь и сейчас. Поскольку в долгосрочной перспективе это может сделать только хуже. Но если вообще, то использовать это нужно и можно. Только аккуратно и осторожно.

анализ и инсайты

Важной частью существования любого продукта является анализ рынка и конкурентов, а также постоянный поиск чего-то нового. Продукт может какое-то время существовать «как есть», но для роста и развития необходимо не только успевать меняться или же подстраиваться под текущие условия, но и пробовать что-то новое, и желательно быстрее конкурентов. Чтобы не довольствоваться чем-то малым, а «снять самые сливки».

В качестве примера можно привести интеграцию в продукт какой-то новой технологии, когда она еще не была так широко известна, и не стала использоваться повсеместно. Например, маски дополненной реальности или генеративный искусственный интеллект. Те продукты, которые предлагали доступ к этому раньше других, смогли монетизировать это у себя. Остальные же теперь могут лишь пытаться повторить данный успех на какой-то маленькой выборке. Но, будем честны, вряд ли у них это получится.

Поэтому крайне важно иметь широкий кругозор, здоровую любознательность, развитую насмотренность, интуитивное видение и понимание трендов. Постоянно смотреть, изучать и пробовать что-то новое. И делать все то, что может помочь находиться впереди других. А также иметь достаточный потенциал, пусть даже, для временного, но быстрого роста.

баланс

Развитие продукта это постоянный поиск баланса. Между нуждами пользователей и требованиями бизнеса. Между ценовой политикой и лояльностью. Между качеством и скоростью. При более медленном темпе появляется время на реакцию и обратную связь, но повышается риск упустить важные возможности, за которые необходимо быстро хвататься. А при быстром, когда постоянно пробуешь что-то новое, не успеваешь или просто игнорируешь старое, наоборот, велика вероятность так же быстро перегореть.

Например, чтобы развести костер, нужно выбрать самые сухие ветки, и подкладывать их по очереди, одну за другой. А если бездумно кидать все подряд, то огонь погаснет, и чтобы разжечь его снова в следующий раз, потребуется куда больше усилий, чем в каждый предыдущий.

Так же и продукты не существуют в вакууме, а зависят от множества факторов, которые необходимо учитывать постоянно. Поэтому для наиболее эффективного не только существования, но и развития всегда и во всем важен баланс. В продуктовых метриках, в возможностях и ограничениях, в скорости, качестве и количестве изменений, во взаимодействии как внутри команды, так и с внешними заинтересованными лицами. Но в конечном итоге важным остается лишь то, чтобы продуктом пользовались. Ведь, как и любая вещь, продукт живет ровно до тех пор, пока им пользуются. Иначе уже никакие изменения не помогут, и не останется ничего другого, кроме как закрыть продукт.

бесплатная пробная версия

В мире, наполненным различными альтернативами, каждый из нас старается выбрать лучшее, чтобы не тратить зря свои деньги и время. Но чтобы определиться для себя, и окончательно решить, сначала нужно погрузиться в продукт чуть глубже. Ведь невозможно узнать что-то новое, пока не попробуешь сам.

Например, нравится автомобиль. Нравится, как он выглядит. Нравится, как он едет. Но при этом совершенно непонятно, как он управляется. Поэтому сначала люди записываются на тест-драйв, по итогу которого уже делают выводы, и определяются – их это автомобиль или не их. Приобретать или же просто продолжать смотреть на него с восхищением, но уже только со стороны. То же самое и в цифровом мире. Прежде чем приобрести полную версию, пользователю необходимо понять его ли это продукт. Решает ли он текущую проблему эффективнее других. Удовлетворяет ли потребность лучше аналогов или же прямых конкурентов. И бесплатная пробная версия отлично помогает ему в этом разобраться.

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

взаимодействие

Зачастую даже самая маленькая и незначительная анимация или информационное окно при взаимодействии может принести или же, наоборот, лишить продукт дополнительного дохода.

Например, подтверждение банковского перевода. Если нет окна или анимации с подтверждением, то пользователь просто не понимает была совершена операция или же нет. И поэтому он может обратиться к адресату платежа, проверить перевод в истории операций, и даже позвонить или написать в службу поддержки. Хотя, казалось бы, такая мелочь, а имеет такое большое значение.

Поэтому при разработке так важно учитывать особенности «общения» пользователя с продуктом, и давать обратную связь на каждом этапе и в каждом элементе, через который проходит пользователь, и с которым он взаимодействует.

воронка активации

У любого продукта есть конечная точка, начиная с которой пользователя можно считать активированным. То есть сделать предположение о том, что он останется пользоваться данным продуктом. Но прежде чем активироваться, данный пользователь прошел несколько этапов. И для оптимизации, а также минимизации шагов до активации помогают воронки.

Например, к нам обратился потенциальный заказчик, но по какой-либо причине заказ так и не совершил. Сначала мы даем ему время прийти самому или вернуться по тому каналу, по которому он о нас узнал. Если он так и не возвращается самостоятельно, то напоминаем о себе, предлагаем скидки, привлекаем акциями. И как только клиент, он же заказчик, совершил заказ или приобрел услугу, его можно считать активированным. Хотя, на самом деле, лучше пойти еще дальше, и точкой активации считать второй заказ. Поскольку первый мог быть случайным или ошибочным. А для этого продолжать взаимодействие, запрашивать обратную связь, своевременно реагировать и отвечать на его запросы.

И все это делается для того, чтобы для следующих похожих потенциальных клиентов данный путь становился короче, заказ они делали быстрее, и вообще идеально, если оставались подольше. Поскольку дальнейший доход они будут приносить уже, преимущественно, без нашего участия.

встроенные покупки

Встроенные покупки оказывают значительное влияние как на доход, так и на другие соседние метрики.

Ведь чем в продукте больше платящих, тем дороже будет стоить их привлечение. А значит с рекламы, показанной данным пользователям, можно заработать больше. Поскольку каждый хочет привлечь в свой продукт такого пользователя, который с наибольшей вероятностью совершит хотя бы одну покупку. И поэтому готов тратить значительные суммы для увеличения шанса на привлечение именно такого пользователя. Или удержание. Ведь если пользователь уже совершил какую-то покупку, то выше вероятность, что он продолжит им пользоваться, а не уйдет к конкурентам, например.

Поэтому встроенные покупки являются мощнейшим инструментом влияния не только на доход, но и на другие продуктовые метрики. Главное, правильно выстроить стратегию. Не продавать дешевое слишком дешево, а дорогое – слишком дорого. Не создавать несколько покупок с разной, и тем более одинаковой стоимостью, но с очень близкой друг к другу ценностью. А также не забывать про акции, скидки и сезонные предложения.

геймификация и достижения

Игра является естественным процессом обучения и познания окружающего мира у людей и животных. Через игру лучше строится любое взаимодействие, а также увеличивается вовлеченность. Но проходит время, дети становятся взрослыми, но привычка и тяга к игре так и остаются. Поэтому самой универсальной и наиболее применимой моделью геймификации, или игрофикации, является система наград и достижений. То есть при достижении какой-то конкретной цели, пользователь получает заранее известную ему награду.

Это может быть, например, десятая чашка кофе в подарок при условии, что девять предыдущих покупок было совершено не более, чем за три последние недели. Или дополнительные 5% к ставке по вкладу, если траты по всем картам в текущем месяце составляют не менее 10.000 рублей.

И таким образом можно увеличить не только лояльность и вовлеченность в использование продукта, но и средний чек за счет увеличения количества покупок. Которые чаще всего стимулируются страхом упущенной выгоды. Поэтому пользователь старается как можно быстрее выполнить задание, и получить награду. Даже в тех случаях, когда остается достаточно времени, или сама награда не представляет какой-либо значимой ценности.

гибкость

Ни один из продуктов не создается и не существует в каком-то вакууме, а постоянно подвергается воздействию каких-либо внешних факторов. Это могут быть меняющиеся требования рынка, применение конкурентами новых решений или технологий, необходимые доработки по итогу общения с пользователями, и так далее. И чтобы успевать на это все реагировать, необходимо иметь гибкость.

Сначала продукт может, например, рекомендовать подарки к определенному празднику на основе ассортимента крупного торгового центра или маркетплейса. Но спустя несколько итераций и проведенных тестов выяснить, что данная потребность не является массовой, и поэтому продукт не имеет смысла развивать дальше. Но обладая календарем праздников, данными с интересами пользователей, пониманием особенностей рынка подарков, можно сделать новый продукт. И поскольку выяснилось, что большой проблемой является найти подходящее поздравление к празднику, пусть это будет конструктор электронных открыток, который позволяет для каждого праздника или просто важного события из заранее заготовленной базы выбрать изображение, текст, музыку и даже анимацию, а затем максимально простым и удобным способом отправить нужному адресату через необходимый мессенджер. Но спустя время на рынке появляется новый тренд в виде искусственного интеллекта, который сам создает изображения, текст, музыку и даже анимацию на основе того, что именно захочет пользователь. И в этот момент приходит понимание, что добавление данной функциональности, с одной стороны, может увеличить вовлеченность за счет непосредственного участия пользователя в создании того, что ему нужно, с другой же, сократить затраты на художников, копирайтеров, композиторов, аниматоров. То есть приносит пользу как пользователю, так и продукту. Поэтому продукт снова меняется.

Таким образом, гибкость не является чем-то ужасным из-за своей обязательности в постоянных изменениях, а приносит реальную пользу, если эти изменения вовремя производить.

гипотезы

На гипотезах строиться процесс становления и развития продукта. Но чтобы не тратить время впустую, и не свернуть куда-то не туда, необходимо делать это правильно. А также документировать все, что хочется, делается или уже было протестировано. И у любой гипотезы должно быть четкое и конкретное понимание метрики, на изменение которой она влияет, сроки, в которые гипотеза должна быть проверена, и выводы, которые из проверки данной гипотезы были сделаны. И лучше всего использовать для этого HADI-циклы. Иначе говоря, сформулировать и оценить саму гипотезу, затем подготовить действия, направленные на ее проверку, далее проверить ее, проанализировать полученные данные, и уже после зафиксировать все возможные инсайты и выводы, сделанные по итогу проверки данной гипотезы, которые способствуют более простой, легкой и дешевой проверке следующих гипотез.

Например, мы предполагаем, что изменение текста на баннере с рекламой продолжит в том же объеме привлекать пользователей из целевой аудитории, а также привлечет некоторую часть пользователей из другого сегмента. Для этого производятся необходимые действия в виде написания нового текста, редизайна баннера, затем верстки, печати, монтажа, и так далее. Но уже спустя две недели анализируются результаты, и делается вывод, что новый текст не только не смог привлечь дополнительную аудиторию, но и стал меньше привлекать целевую. Поэтому необходимо вернуть старую версию рекламы, и зафиксировать, что данный текст в данный момент времени, или даже в данный сезон года, не работает на привлечение данного сегмента. Но зато отрицательно работает на целевой аудитории.

И важно отметить, что чем больше гипотез проверяется, тем выше потенциал вырастить продукт. Но чтобы не затягивать этот рост, необходимо проверять их быстро. А чтобы проверять гипотезы быстро, нужно правильно их формулировать. А для этого необходимо понимать какие изменения на какие метрики влияют, и что именно ожидается достичь данными изменениями. И если целью указывать увеличение конверсии, увеличение дохода, возврата, продолжительности и частоты сессий, то это будет просто впустую потраченным временем. А по результату не получится ответить ни на один из этих вопросов. Поскольку для разных метрик потребуется разное количество пользователей, а также само изменение, в действительности, имеет влияние лишь на что-то одно. Поэтому необходимо не торопиться проверять все и сразу, а вдумчиво подходить к тестированию гипотез, и не забывать фиксировать все результаты. Чтобы спустя пару недель или месяцев не проверять снова то же самое, но сбоку.

делать запланированное

Хотя это правило применимо для жизни, в принципе – не делать сегодня то, что можно отложить на завтра. Но если без шуток, нельзя откладывать то, что уже запланировано. Иначе запланированное может не реализоваться вообще никогда. И это применимо не только при работе над продуктом, но и для жизни в целом.

Если рассматривать на примере разработки, то в начале каждого цикла должно быть четкое и конкретное понимание конечного итога. И если во время этого цикла добавить какие-то дополнительные изменения или требования, то цикл может растянуться, потери потенциального дохода увеличиться, а действительно нужные и необходимые изменения не выйти вообще никогда. Потому, что чем продукт старше, тем больше изменений он содержит, тем дольше времени требуется на проверку их корректной работоспособности, и тем сложнее добавить какие-то новые требования вне очереди, минимизируя при этом какие-либо возможные конфликты.

Поэтому, если на эту неделю были запланированы вот эти конкретные изменения, то в конце выйти должны только они. Если что-то не успели, то это откладывается на следующую неделю. А все дополнительное идет уже в порядке приоритета. А не добавляется и не заменяется уже по ходу работы.

детали и контекст

Мало кто задумывается о том, как, казалось бы, незначительные детали способны спасти или же навсегда уничтожить целый продукт.