Зачастую даже самая маленькая и незначительная анимация или информационное окно при взаимодействии может принести или же, наоборот, лишить продукт дополнительного дохода.
Например, подтверждение банковского перевода. Если нет окна или анимации с подтверждением, то пользователь просто не понимает была совершена операция или же нет. И поэтому он может обратиться к адресату платежа, проверить перевод в истории операций, и даже позвонить или написать в службу поддержки. Хотя, казалось бы, такая мелочь, а имеет такое большое значение.
Поэтому при разработке так важно учитывать особенности «общения» пользователя с продуктом, и давать обратную связь на каждом этапе и в каждом элементе, через который проходит пользователь, и с которым он взаимодействует.
У любого продукта есть конечная точка, начиная с которой пользователя можно считать активированным. То есть сделать предположение о том, что он останется пользоваться данным продуктом. Но прежде чем активироваться, данный пользователь прошел несколько этапов. И для оптимизации, а также минимизации шагов до активации помогают воронки.
Например, к нам обратился потенциальный заказчик, но по какой-либо причине заказ так и не совершил. Сначала мы даем ему время прийти самому или вернуться по тому каналу, по которому он о нас узнал. Если он так и не возвращается самостоятельно, то напоминаем о себе, предлагаем скидки, привлекаем акциями. И как только клиент, он же заказчик, совершил заказ или приобрел услугу, его можно считать активированным. Хотя, на самом деле, лучше пойти еще дальше, и точкой активации считать второй заказ. Поскольку первый мог быть случайным или ошибочным. А для этого продолжать взаимодействие, запрашивать обратную связь, своевременно реагировать и отвечать на его запросы.
И все это делается для того, чтобы для следующих похожих потенциальных клиентов данный путь становился короче, заказ они делали быстрее, и вообще идеально, если оставались подольше. Поскольку дальнейший доход они будут приносить уже, преимущественно, без нашего участия.
Встроенные покупки оказывают значительное влияние как на доход, так и на другие соседние метрики.
Ведь чем в продукте больше платящих, тем дороже будет стоить их привлечение. А значит с рекламы, показанной данным пользователям, можно заработать больше. Поскольку каждый хочет привлечь в свой продукт такого пользователя, который с наибольшей вероятностью совершит хотя бы одну покупку. И поэтому готов тратить значительные суммы для увеличения шанса на привлечение именно такого пользователя. Или удержание. Ведь если пользователь уже совершил какую-то покупку, то выше вероятность, что он продолжит им пользоваться, а не уйдет к конкурентам, например.
Поэтому встроенные покупки являются мощнейшим инструментом влияния не только на доход, но и на другие продуктовые метрики. Главное, правильно выстроить стратегию. Не продавать дешевое слишком дешево, а дорогое – слишком дорого. Не создавать несколько покупок с разной, и тем более одинаковой стоимостью, но с очень близкой друг к другу ценностью. А также не забывать про акции, скидки и сезонные предложения.
Игра является естественным процессом обучения и познания окружающего мира у людей и животных. Через игру лучше строится любое взаимодействие, а также увеличивается вовлеченность. Но проходит время, дети становятся взрослыми, но привычка и тяга к игре так и остаются. Поэтому самой универсальной и наиболее применимой моделью геймификации, или игрофикации, является система наград и достижений. То есть при достижении какой-то конкретной цели, пользователь получает заранее известную ему награду.
Это может быть, например, десятая чашка кофе в подарок при условии, что девять предыдущих покупок было совершено не более, чем за три последние недели. Или дополнительные 5% к ставке по вкладу, если траты по всем картам в текущем месяце составляют не менее 10.000 рублей.
И таким образом можно увеличить не только лояльность и вовлеченность в использование продукта, но и средний чек за счет увеличения количества покупок. Которые чаще всего стимулируются страхом упущенной выгоды. Поэтому пользователь старается как можно быстрее выполнить задание, и получить награду. Даже в тех случаях, когда остается достаточно времени, или сама награда не представляет какой-либо значимой ценности.
Ни один из продуктов не создается и не существует в каком-то вакууме, а постоянно подвергается воздействию каких-либо внешних факторов. Это могут быть меняющиеся требования рынка, применение конкурентами новых решений или технологий, необходимые доработки по итогу общения с пользователями, и так далее. И чтобы успевать на это все реагировать, необходимо иметь гибкость.
Сначала продукт может, например, рекомендовать подарки к определенному празднику на основе ассортимента крупного торгового центра или маркетплейса. Но спустя несколько итераций и проведенных тестов выяснить, что данная потребность не является массовой, и поэтому продукт не имеет смысла развивать дальше. Но обладая календарем праздников, данными с интересами пользователей, пониманием особенностей рынка подарков, можно сделать новый продукт. И поскольку выяснилось, что большой проблемой является найти подходящее поздравление к празднику, пусть это будет конструктор электронных открыток, который позволяет для каждого праздника или просто важного события из заранее заготовленной базы выбрать изображение, текст, музыку и даже анимацию, а затем максимально простым и удобным способом отправить нужному адресату через необходимый мессенджер. Но спустя время на рынке появляется новый тренд в виде искусственного интеллекта, который сам создает изображения, текст, музыку и даже анимацию на основе того, что именно захочет пользователь. И в этот момент приходит понимание, что добавление данной функциональности, с одной стороны, может увеличить вовлеченность за счет непосредственного участия пользователя в создании того, что ему нужно, с другой же, сократить затраты на художников, копирайтеров, композиторов, аниматоров. То есть приносит пользу как пользователю, так и продукту. Поэтому продукт снова меняется.
Таким образом, гибкость не является чем-то ужасным из-за своей обязательности в постоянных изменениях, а приносит реальную пользу, если эти изменения вовремя производить.
На гипотезах строиться процесс становления и развития продукта. Но чтобы не тратить время впустую, и не свернуть куда-то не туда, необходимо делать это правильно. А также документировать все, что хочется, делается или уже было протестировано. И у любой гипотезы должно быть четкое и конкретное понимание метрики, на изменение которой она влияет, сроки, в которые гипотеза должна быть проверена, и выводы, которые из проверки данной гипотезы были сделаны. И лучше всего использовать для этого HADI-циклы. Иначе говоря, сформулировать и оценить саму гипотезу, затем подготовить действия, направленные на ее проверку, далее проверить ее, проанализировать полученные данные, и уже после зафиксировать все возможные инсайты и выводы, сделанные по итогу проверки данной гипотезы, которые способствуют более простой, легкой и дешевой проверке следующих гипотез.
Например, мы предполагаем, что изменение текста на баннере с рекламой продолжит в том же объеме привлекать пользователей из целевой аудитории, а также привлечет некоторую часть пользователей из другого сегмента. Для этого производятся необходимые действия в виде написания нового текста, редизайна баннера, затем верстки, печати, монтажа, и так далее. Но уже спустя две недели анализируются результаты, и делается вывод, что новый текст не только не смог привлечь дополнительную аудиторию, но и стал меньше привлекать целевую. Поэтому необходимо вернуть старую версию рекламы, и зафиксировать, что данный текст в данный момент времени, или даже в данный сезон года, не работает на привлечение данного сегмента. Но зато отрицательно работает на целевой аудитории.
И важно отметить, что чем больше гипотез проверяется, тем выше потенциал вырастить продукт. Но чтобы не затягивать этот рост, необходимо проверять их быстро. А чтобы проверять гипотезы быстро, нужно правильно их формулировать. А для этого необходимо понимать какие изменения на какие метрики влияют, и что именно ожидается достичь данными изменениями. И если целью указывать увеличение конверсии, увеличение дохода, возврата, продолжительности и частоты сессий, то это будет просто впустую потраченным временем. А по результату не получится ответить ни на один из этих вопросов. Поскольку для разных метрик потребуется разное количество пользователей, а также само изменение, в действительности, имеет влияние лишь на что-то одно. Поэтому необходимо не торопиться проверять все и сразу, а вдумчиво подходить к тестированию гипотез, и не забывать фиксировать все результаты. Чтобы спустя пару недель или месяцев не проверять снова то же самое, но сбоку.
Хотя это правило применимо для жизни, в принципе – не делать сегодня то, что можно отложить на завтра. Но если без шуток, нельзя откладывать то, что уже запланировано. Иначе запланированное может не реализоваться вообще никогда. И это применимо не только при работе над продуктом, но и для жизни в целом.
Если рассматривать на примере разработки, то в начале каждого цикла должно быть четкое и конкретное понимание конечного итога. И если во время этого цикла добавить какие-то дополнительные изменения или требования, то цикл может растянуться, потери потенциального дохода увеличиться, а действительно нужные и необходимые изменения не выйти вообще никогда. Потому, что чем продукт старше, тем больше изменений он содержит, тем дольше времени требуется на проверку их корректной работоспособности, и тем сложнее добавить какие-то новые требования вне очереди, минимизируя при этом какие-либо возможные конфликты.
Поэтому, если на эту неделю были запланированы вот эти конкретные изменения, то в конце выйти должны только они. Если что-то не успели, то это откладывается на следующую неделю. А все дополнительное идет уже в порядке приоритета. А не добавляется и не заменяется уже по ходу работы.
Мало кто задумывается о том, как, казалось бы, незначительные детали способны спасти или же навсегда уничтожить целый продукт.
О проекте
О подписке
Другие проекты