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

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

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

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

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

ISBN 978-5-0062-7052-7

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

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

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

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

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

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

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

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

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

баланс

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

гибкость

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

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

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

гипотезы

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

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

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

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

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

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

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

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

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.