Connect with us

Статьи

Почему авторы Trello не смогли создать бизнес на 1 миллиард долларов

Почему инновационный и популярный продукт не принес своим создателям максимально возможную прибыль? Создатель нескольких SaaS-компаний Хитен Шах разобрал ошибки, которые допустили создатели Trello.

Анна Гуляева

Опубликовано

/

     
     

Почему инновационный и популярный продукт не принес своим создателям максимально возможную прибыль? Создатель нескольких SaaS-компаний Хитен Шах разобрал ошибки, которые допустили создатели Trello.

В 2011 Джоэл Спольски на TechCrunch Disrupt запустил новый продукт компании Fog Creek под названием Trello. Он был похож на белую доску со стикерами, перенесенную в веб-браузер и в приложение для iPhone. Вместо того, чтобы перемещать физические заметки на доске, вы могли перетаскивать карточки на доске в браузере.

За считанные дни Trello удалось привлечь внимание 131 тысячи человек. 22% из этих людей зарегистрировались. Trello хотели создать простой и полезный продукт, который сможет использовать кто угодно. Он распространялся, как лесной пожар.

Поэтому Trello в итоге пришлось продать Atlassian за $425 миллионов, хотя он и мог стать следующим SaaS-приложением на миллиард долларов.

Спустя пару месяцев после запуска Спольски написал пост, в котором предвидел самую большую сложность:

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

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

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

Давайте поговорим о возможности, которую упустил Trello, и что следовало сделать вместо этого.

Почему Trello нужно было заниматься продажами

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

На практике это выглядело так:

Когда Trello только появился, технически было действительно сложно создать браузерную доску, в которой вы сможете совместно перемещать карточки в разные списки. Многие SaaS-инструменты того времени были большими базами данных с визуальным интерфейсом, натянутым поверх (например, Salesforce). Создавалсь архитектура, в которой вы структурируете данные по лидам, клиентам или задачам.

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

Они построили свои сервера на Node и использовали MongoDB для хранения данных, поэтому веб-приложение загружалось очень быстро. Каждый раз, когда пользователь перемещал карточку в новый список или менял запись на доске, Trello отправлял эти данные в другие браузеры, чтобы доска открывалась почти мгновенно.

Архитектура Trello

Результат был удивительно простым. Вы делали изменение на доске, и оно отображалось во всех других местах.

Все это было новым в то время и привлекло к Trello много внимания. Но в 2016 подобное красивое и отзывчивое  приложение стало не так сложно создать, и канбан-доски начали появляться везде:

GitHub представили канбан-доски в сентябре 2016:

Asana анонсировали канбан-доски в ноябре 2016:

Airtable запустили канбан-доски в ноябре 2016:

Джастин Розенштейн, сооснователь одного из крупнейших конкурентов Trello, Asana, сказал: “Мы определенно отдаем должное Trello. Этот продукт первым создал подобное видение”. Но Джастин непреклонен в вопросе копирования функции досок Trello: “Мы рассматриваем Trello как функцию, а не как продукт”.

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

Trello не стал такой системой записей. Он стал сильной визуальной метафорой, которую скопировали его конкуренты. Канбан-доска оказалась отличной UX-функцией, но не защищенной от копирования.

В SaaS побеждает не первая компания и не компания с лучшей идеей. Побеждают те, кто постепенно лучше решают проблему. Когда вы создаете популярную или успешную функцию, конкуренты её крадут.

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

1. Trello недостаточно быстро монетизировался

При помощи freemium модели возможно построить нацеленную на пользователей миллиардную компанию. В 2013, спустя шесть лет после запуска, Dropbox был оценен в 8 миллиардов долларов, их доход – 200 миллионов долларов, а количество пользователей – 200 миллионов человек. Это было даже до того, как Dropbox запустил тариф для бизнеса – доход компания преимущественно получала от продажи пользователям месячной подписки за 10 долларов.

Спустя три года после запуска рост количества пользователей Trello обещал превысить уровень Dropbox: в 2015 году у Trello было 10 миллионов пользователей (через три года после запуска у Dropbox было четыре миллиона клиентов). Но Trello было гораздо сложнее переводить неплатящих пользователей на свой план “Trello Gold”.

Запуск Trello Gold в 2013 был освещен этим постом в блоге, которые выделил три причины, по которые пользователю следует платить 5 долларов в месяц за Trello:

  • Настраиваемый фон доски
  • Ограничение в 250 МБ для файлов, прикрепленных к карточке (против 10 МБ в бесплатном плане)
  • Стикеры и кастомные эмодзи

Хотя все любят эмодзи, это не очень хорошая причина тратить деньги на приложение. Бесплатный тариф Dropbox предоставляет 2 ГБ пространства. Платный тариф предоставляет 1 ТБ, что в 50 раз больше бесплатной версии.

Определить ценностное предложение Trello было сложно, потому что они должны были ещё в начале понять, за какие функции захотят платить индивидуальные пользователи.

Решение: Изучить кейсы freemium-модели

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

Если у вас есть продукт с множеством возможных применений, посмотрите сначала все кейсы его использования:

  • Существует ли у вас конкурент, который может делать то же самое или уже делает это сейчас?
  • Каков потенциальный доход этого варианта?

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

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

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

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

2. Trello не стал незаменимым для SMB

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

В 2013 Trello запустил первый план Business Class для малого и среднего бизнеса. Сначала они установили цену в 200 долларов в год для организации, прежде чем перейти к более традиционной модели ценообразования SaaS за рабочее место.

Trello Business Class стоил 10 долларов за пользователя (плата взималась раз в год), и за эти деньги вы получали:

  • Безграничную интеграцию досок
  • Дополнительные функции совместной работы
  • Режим “только для чтения” и настройки приватности

Когда Дэвид Кэнсел, со-основатель Drift, упомянул годовую стоимость Trello в своей презентации, вся команда была шокирована – цена составила 1700 долларов. Как говорит Дэвид: “Только несколько людей используют Trello ежедневно. Однако мы платим за количество подключенных людей. Очевидно, существует разрыв между ценой, которую мы платим, и пользой, которую мы получаем”. Дэвид затем перевел свою команду обратно на бесплатный план.

В статье на Forbes CEO Trello Майкл Прайор сказал: “Я не хочу, чтобы люди проводили по десять часов в Trello ежедневно, мы не продаем рекламу и не хотим получать больше вашего времени, как это делают социальные платформы”.

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

Что следовало сделать Trello?

Решение: Создать лучшую интеграцию для SMB

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

Представьте возможность открывать и закрывать GitHub Issues прямо внутри Trello. Представьте, что все ваши лиды из Salesforce автоматически открываются или закрываются в Trello. Trello мог бы стать доской управления всеми остальными инструментами компании, что было бы очень ценно.

Вместо этого главные функции Trello были скопированы. Представителю GitHub задали вопрос о создании досок для визуального управления вопросами, на что он сказал: “Все ожидали этой функции и спрашивали, почему у нас её не было”. Поэтому GitHub создали доски.

Если вы создаете подобное горизонтальное SaaS-приложение, разделите своих пользователей по интеграциям:

  • Какие API используют люди?
  • Сколько данных входит в продукт и выходит из него?

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

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

3. Trello не подходил для предприятий

Смена фокуса на рынок предприятий – доказанная модель для SaaS. Slack сделал это, запустив Enterprise Grid. Trello могли бы построить прибыльный бизнес таким же образом, быстро переключившись на рынок предприятий.

Менее чем через год после запуска стратегии корпоративных продаж, ежегодные платежи (ARR) достигли отметки в 10 миллионов долларов. В своем интервью вице-президент Trello по продажам Кристен Хабахт сказала, что Trello следует достаточно простой стратегии корпоративных продаж:

«Наша команда по работе с предприятиями рассматривает [клиентов], у которых действительно много пользователей Trello. Большая часть нашей стратегии исходящих продаж – это просто связаться с этими компаниями и сказать: У вас более 2 000 человек пользуются Trello, с кем мы можем поговорить об этом?»

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

Решение: Стать системой хранения данных для предприятия

Trello должны были задать такой вопрос: “Как нам интегрироваться с системами, которые используют большие компании, и стать незаменимой частью рабочего процесса?”.

Один из способов – стратегия Slack. С ростом компании они пытались распространиться от индивидуальных разработчиков к командам, а от команд к компаниям. Slack обнаружил здесь проблему, потому что, в отличие от инструмента продаж или маркетинговой аналитики, почти каждый человек в команде мог наложить вето на инструмент повышения продуктивности. Поэтому Slack провел шесть месяцев в приватном бета-тестировании, изучая свою клиентскую базу и рассказывая им о необходимости в инструменте внутренней коммуникации. Они оптимизировали процесс онбординга вокруг метрики в 2000 отправленных внутри организации сообщений. Сегодня 93% этих компаний продолжают использовать Slack.

Видение, стоящее за корпоративным продуктом Slack, позволяет организациям создавать “структуры” при помощи Slack. Функциональность приложения для предприятия отличается пользовательского. Команды в компании могут организовываться в “рабочие пространства” и формировать подразделения в соответствии со структурой организации. В Slack пытались понять, как и почему продукт распространяется от маленьких команд к отделам и целым организациям, и поэтому они смогли выделить ключевые проблемы предприятий и решить их в Enterprise Grid.

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

Поздравляю, Trello

Смотреть в прошлое, конечно, проще. Хотя большая часть статьи посвящена упущенной возможности Trello, мы не должны забывать, что создание SaaS-бизнеса, оцененного в 425 миллионов долларов, это большое достижение.

Команда Fog Creek заплатила за создание Trello из своего кармана. Приложение стало успешным с момента запуска на TechCrunch Disrupt. За два года Trello приобрел 500 тысяч пользователей, а за четыре года – 4,75 миллиона, и это до привлечения средств инвесторов. Команда создала удивительный продукт, который опередил свое время. Он был простым, изящным и легким в использовании.

В прошлом году я написал такой твит:

Вот такое влияние Trello оказал на SaaS, и вы видите его следы везде: от GitHub до Jira.

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

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

 

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Разработка

Интересные материалы для разработчика мобильных приложений #193 (4-10 декабря)

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

Леонид Боголюбов

Опубликовано

/

8 учебных проектов

Предлагаем 8 вариантов проектов, которые можно сделать «по фану», дабы получить реальный опыт разработки.

Зачем я купил Mac Mini (Late 2012) накануне 2018 года?

После смены старого MacBook Pro на еще более древний Mac Mini, объем оперативной памяти увеличился с 8 GB до 16 GB и маленький 13” экран сменился на два 22”. Осталось разобраться с производительностью.

14-й опрос Developer Economics

Этот опрос создан разработчиками для разработчиков и прольет свет на будущее индустрии программного обеспечения.

 iOS

 Android

 Разработка

 Аналитика, маркетинг и монетизация

 Устройства, IoT, AI

Комментарии
Продолжить чтение

Программирование

Правила, которые я выработал по результатам 1000 code review

Леонид Боголюбов

Опубликовано

/

Во время работы в LinkedIn большая часть моей работы состояла из проверки кода. Были определенные ситуации, которые постоянно возникали снова и снова, поэтому я решил составить список, которым и поделился с командой.

Вот мои 3 (+1 бонус) наиболее распространенных правки, которые я делал во время code review.

Правка 1: Генерирование исключения, когда что-то идет не так

Обычно я видел такое:

List<String> getSearchResults(...) {
  try {
    List<String> results = // make REST call to search service
    return results;
  } catch (RemoteInvocationException e) {
    return Collections.emptyList();
  }
}

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

Если бы вместо этого API выбросил исключение, то наша система мониторинга немедленно подобрала бы его, обработала и мы ошибку исправили.

Во многих случаях возникает соблазн просто вернуть пустой объект после того, как вы поймали исключение. Примерами пустых объектов в Java являются Optional.empty(), нулевой или пустой список. Хорошим примером того, где это все встречается постоянно, является парсинг URL. Вместо того, чтобы возвращать null, если URL-адрес не может быть получен из строки, спросите себя: «Почему URL-адрес неправильно сформирован? Является ли это проблемой данных, которую мы должны исправить где-то выше?».

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

Правка 2: Использование наиболее конкретного типа

Это предложение в основном противоречит строгому типизированному программированию.

Слишком часто я видел код, подобный этому примеру:

void doOperation(String opType, Data data); 
// where opType is "insert", "append", or "delete", this should have clearly been an enum

String fetchWebsite(String url);
// where url is "https://google.com", this should have been an URN

String parseId(Input input);
// the return type is String but ids are actually Longs like "6345789"

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

Внимание, вопрос: как опытные программисты в конечном итоге пишут плохой типизированный код? Ответ: потому что внешний мир не сильно типизирован. Есть несколько разных мест, откуда берутся строки, например:

  • параметры запроса и пути в URL-адресах
  • JSON
  • Базы данных, которые не поддерживают enum
  • Плохо написанные библиотеки

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

// Step 1: Take a query param representing a company name / member id pair and parse it
// example: context=Pair(linkedin,456)
Pair<String, Long> companyMember = parseQueryParam("context");
// this should throw an exception if malformed

// Step 2: Do all the stuff in your application
// MOST if not all of your code should live in this area

// Step 3: Convert the parameter back into a String at the very end if necessary
String redirectLink = serializeQueryParam("context");

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

Правка 3: Использование Optionals вместо null

Одна из лучших функций Java 8 – это класс Optional, который представляет собой объект, который может существовать или не существовать.

Вопрос на миллион долларов: какое единственное исключение имеет собственную аббревиатуру? Ответ: NPE или Null Pointer Exception. Это, безусловно, самое распространенное исключение в  Java и, конечно, ошибка, которая стоит миллион долларов.

Optional позволяет вам полностью устранить NPE. Однако его следует использовать правильно. Вот некоторые советы по работе с Optional:

  • Не надо просто называть .get () в любое время, когда вам надо использовать Optional. Вместо этого внимательно подумайте о том случае, когда Optional не представлен, и придумайте разумное значение по умолчанию.
  • Если у вас еще нет разумного значения по умолчанию, тогда такие методы, как .map () и .flatMap (), позволяют отложить это решение.
  • Если внешняя библиотека возвращает значение NULL, чтобы указать на пустой случай, сразу же оберните значение с помощью параметра Optional.ofNullable (). Поверьте мне, вы поблагодарите себя позже. Нули имеют тенденцию «всплывать» внутри программ, поэтому лучше остановить их в первоисточнике.
  • Используйте Optional как возвращаемый тип в методах. Это здорово, потому что вам не нужно будет читать javadoc, чтобы выяснить, возможно ли, чтобы значение было пустым.

Бонус: Использование Unlift методов, когда это возможно

Вы должны избегать методов, которые выглядят следующим образом:

// AVOID:
CompletableFuture<T> method(CompletableFuture<S> param);
// PREFER: 
T method(S param);

// AVOID:
List<T> method(List<S> param);
// PREFER:
T method(S param);

// AVOID: 
T method(A param1, B param2, Optional<C> param3);
// PREFER:
T method(A param1, B param2, C param3);
T method(A param1, B param2);
// This method is clearly doing two things, it should be two methods
// The same is true for boolean parameters

Что общего у всех этих методов? Они используют контейнерные объекты, такие как Optional, List или Task как параметры методов. Еще хуже, когда  возвращаемый тип является тем же самым (т.е. метод принимает Optional и возвращает Optional).

Почему это плохо?

  1. Promise<A> method(Promise<B> param)
    менее гибко, чем просто
  2. A method(B param)

Если у вас есть Promise <B>, вы можете использовать 1, или вы можете использовать 2 путем «подъема» функции с помощью .map. (т.е. promise.map(method)).

Однако, если у вас есть только B, вы можете легко использовать 2, но вы не можете использовать 1, что делает 2 гораздо более гибким вариантом.

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

 

Комментарии
Продолжить чтение

Статьи

Настоящее и будущее машинного обучения на устройствах

Специалист по глубокому обучению Маттейс Холлеманс рассмотрел перспективы машинного обучения на устройствах и как его можно использовать уже сейчас.

Анна Гуляева

Опубликовано

/

Как вы, конечно, заметили, машинное обучение на устройствах сейчас все больше развивается. Apple упомянула это около ста раз во время WWDC 2017. Неудивительно, что разработчики хотят добавить машинное обучение в свои приложения.

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

Нейросеть для определения лиц, встроенная в смартфон

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

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

Машинное обучение сегодня

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

iOS использует несколько моделей глубокого обучения на устройствах: распознавание лиц на фото, фразы «Привет, Siri» и рукописных китайских иероглифов. Но все эти модели ничему не учатся от пользователя.

Почти все API машинного обучения (MPSCNN, TensorFlow Lite, Caffe2) могут делать предсказания на основе пользовательских данных, но вы не можете заставить эти модели узнавать новое из этих данных.

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

Обучение на сервере — это хорошая стратегия, если обновление модели происходит нерегулярно, и каждый пользователь использует одну и ту же модель. Приложение получает обновление модели каждый раз при обновлении приложения в App Store или при периодической загрузке новых параметров из облака.

Сейчас обучение больших моделей на устройстве невозможно, но так будет не всегда. Эти модели и не должны быть большими. И самое важное: одна модель для всех может быть не лучшим решением.

Зачем нужно обучение на устройстве?

Существует несколько преимуществ обучения на устройстве:

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

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

На iOS-устройствах это уже делают некоторые приложения:

  • Клавиатура учится на основе текстов, которые вы набираете, и делает предположения о следующем слове в предложении. Эта модель обучается конкретно для вас, а не для других пользователей. Так как обучение происходит на устройстве, ваши сообщения не отправляются на облачный сервер.
  • Приложение «Фото» автоматически организует изображения в альбом «Люди». Я не совсем уверен, как это работает, но программа использует API распознавания лиц на фото и размещает похожие лица вместе. Возможно, это просто неконтролируемая кластеризация, но обучение все равно должно происходить, так как приложение позволяет вам исправлять его ошибки и совершенствуется на основе вашей обратной связи. Вне зависимости от вида алгоритма это приложение — хороший пример кастомизации пользовательского опыта на основе их данных.
  • Touch ID и Face ID учатся на основе вашего отпечатка пальца или лица. Face ID продолжает учиться со временем, поэтому, если вы отрастите бороду или начнете носить очки, оно по-прежнему будет узнавать ваше лицо.
  • Обнаружение движения. Apple Watch изучает ваши привычки, например, изменение биения сердца во время разных активностей. Опять же, я не знаю, как это работает, но, очевидно, обучение должно происходить.
  • Clarifai Mobile SDK позволяет пользователям создавать свои модели классификации изображений при помощи фотографий предметов и их обозначения. Обычно классификационная модель требует тысячи изображений для обучения, но этот SDK может научиться всего на нескольких примерах. Возможность создавать классификаторы изображений из ваших собственных фото, не будучи экспертом в машинном обучении, имеет много практических применений.

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

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

Другие существующие примеры включают в себя определение спама (ваш email-клиент учится на письмах, которые вы определяете как спам), коррекцию текста (она изучает ваши наиболее частые ошибки при наборе текста и исправляет их) и умные календари, вроде Google Now, которые учатся распознавать ваши регулярные действия.

Насколько далеко мы можем зайти?

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

Вот забавный пример: нейронная сеть превращает рисунки в эмодзи. Она просит вас нарисовать несколько разных фигур и учит модель распознавать их. Это приложение реализовано на Swift Playground, не самой быстрой платформе. Но даже при таких условиях нейронная сеть учится недолго — на устройстве это занимает всего несколько секунд (вот как работает эта модель).

Если ваша модель тоже не очень сложна, как эта двухслойная нейронная сеть, вы уже можете проводить обучение на устройстве.

Примечание: на iPhone X у разработчиков есть доступ к 3D-модели пользовательского лица в низком разрешении. Вы можете использовать эти данные, чтобы обучить модель, которая выбирает эмодзи или другое действие в приложение на основе выражения лица пользователей.

Вот несколько других будущих возможностей:

  • Smart Reply — это модель от Google, которая анализирует входящее сообщение или письмо и предлагает подходящий ответ. Она пока не обучается на устройстве и рекомендует одни и те же ответы всем пользователям, но (в теории) она может обучаться на текстах пользователя, что значительно улучшит модель.
  • Распознавание почерка, которое будет учиться именно на вашем почерке. Это особенно полезно на iPad Pro с Pencil. Это не новая функция, но если у вас такой же плохой почерк, как и у меня, то стандартная модель будет допускать слишком много ошибок.
  • Распознавание речи, которое будет становиться более точным и подстроенным под ваш голос.
  • Трекинг сна/фитнес-приложения. Прежде чем эти приложения будут давать вам советы об улучшении здоровья, им нужно узнать вас. Из соображений безопасности этим данным лучше оставаться на устройстве.
  • Персонализированные модели для диалога. Нам ещё предстоит увидеть будущее чат-ботов, но их преимущество заключается в том, что бот может адаптироваться под вас. Когда вы говорите с чат-ботом, ваше устройство будет изучать вашу речь и предпочтения и изменять ответы чат-бота под вашу личность и манеру общения (например, Siri может учиться давать меньше комментариев).
  • Улучшенная реклама. Никому не нравится реклама, но машинное обучение может сделать её менее назойливой для пользователей и более прибыльной для рекламодателя. Например, рекламный SDK может изучать, как часто вы смотрите и кликаете на рекламу, и подбирать более подходящую рекламу для вас. Приложение может обучать локальную модель, которая будет запрашивать только рекламу, работающую для конкретного пользователя.
  • Рекомендации — это распространенное использование машинного обучения. Проигрыватель подкастов может обучаться на программах, которые вы слушали, чтобы давать советы. Сейчас приложения осуществляют эту операцию в облаке, но это можно делать и на устройстве.
  • Людям с ограниченными возможностями приложения могут помогать ориентироваться в пространстве и лучше его понимать. Я не разбираюсь в этом, но могу представить, что приложения могут помогать, например, различать разные лекарства при помощи камеры.

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

Разные сценарии обучения моделей

Перед применением модели вам нужно её обучить. Обучение нужно продолжать и далее, чтобы улучшать модель.

Существует несколько вариантов обучения:

  1. Отсутствие обучения на данных пользователя. Сбор собственных данных или использование публично доступных данных для создания единой модели. При улучшении модели вы выпускаете обновление приложения или просто загружаете в него новые параметры. Так делают большинство существующих приложений с машинным обучением.
  2. Централизованное обучение. Если ваше приложение или сервис уже требует данные от пользователя, которые хранятся на ваших серверах, и у вас есть к ним доступ, тогда вы можете осуществлять обучение на основе этих данных на своем сервере. Пользовательские данные можно использовать для обучения под конкретного пользователя или под всех пользователей. Так поступают платформы вроде Facebook. Этот вариант вызывает вопросы, связанные с приватностью, безопасностью, масштабированием и многие другие. Вопрос с приватностью можно решить методом «избирательной приватности» Apple, но и у него есть свои последствия.
  3. Коллаборативное обучение. Этот способ перемещает затраты на обучение на самих пользователей. Обучение происходит на устройстве, и каждый пользователь обучает небольшую часть модели. Обновления модели отправляются другим пользователям, так что они могут учиться на ваших данных, а вы — на их. Но это по-прежнему единая модель, и у всех в итоге оказываются одни и те же параметры. Главным плюсом такого обучения является его децентрализованность. В теории это лучше для приватности, но, согласно исследованиям, этот вариант может быть хуже.
  4. Каждый пользователь обучает собственную модель. В этом варианте лично я заинтересован больше всего. Модель может учиться с нуля (как в примере с рисунками и эмодзи) или это может быть обученная модель, которая настраивается под ваши данные. В любом случае модель можно совершенствовать со временем. Например, клавиатура начинает с уже обученной на определенном языке модели, но со временем учится предсказывать, какое предложение вы хотите написать. Минусом этого подхода является то, что другие пользователи не могут получить от этого пользу. Так что этот вариант работает только для приложений, которые используют уникальные данные.

Как осуществлять обучение на устройстве?

Стоит помнить, что обучение на данных пользователя отличается от обучения на большом объеме данных. Начальную модель клавиатуры можно обучить на стандартном корпусе текстов (например, на всех текстах Википедии), но текстовое сообщение или письмо будет написано языком, отличающимся от типичной статьи в Википедии. И этот стиль будет отличаться от пользователя к пользователю. Модель должна предусматривать эти виды вариаций.

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

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

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

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

Вот ещё несколько проблем, с которыми предстоит столкнуться при обучении на устройстве:

  • Большие модели. Для сетей глубокого обучения текущие методы обучения проходят слишком медленно и требуют слишком много данных. Многие исследования сейчас посвящены обучению моделей на небольшом количестве данных (например, на одном фото) и за небольшое число шагов. Я уверен, что любой прогресс приведет к распространению обучения на устройстве.
  • Несколько устройств. Вероятно, вы пользуетесь не одним устройством. Ещё предстоит решить вопрос передачи данных и моделей между устройствами пользователя. Например, приложение «Фото» в iOS 10 не передает информацию о лицах людей между устройствами, поэтому обучается на всех устройствах отдельно.
  • Обновления приложения. Если ваше приложение включает обученную модель, которая подстраивается под поведение и данные пользователя, то что происходит, когда вы обновляете модель вместе с приложением?

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

 

Комментарии
Продолжить чтение

Промо-материалы

Подходы к созданию мобильной видеорекламы

Руководитель отдела медиабаинга Go Mobile Игорь Слинкин продолжает рассказывать о креативной коммуникации.

AppTractor

Опубликовано

/

Автор:

Для продвижения сервисов и продуктов разных тематик требуются разные креативные концепции видеорекламы. Среди факторов, которые влияют на выбор подхода:

  • KPI. Что вы хотите от пользователя: познакомить с новым брендом, напомнить о давно известном, удивить или заставить немедленно что-нибудь купить;
  • Сегмент. Реклама мобильной игры, очевидно, будет отличаться от ролика про сервис перевозок;
  • Функционал приложения. Если есть чем похвастаться, обязательно покажите это на видео. Если главная особенность сервиса не заключается в функционале, покажите, какую проблему пользователя вы решаете.
  • Бюджет. Отталкиваемся от возможностей.

Брендинг

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

Более перспективная стратегия для видеорекламы требует большего внимания к деталям:

  • Видеоролики в интернете не полностью дублируют ТВ-рекламу, а являются ее продолжением или альтернативой. Например, в расширенной версии ролика покупатель сталкивается с проблемой, покупает товар и решает ее. А для интернет-продвижения создаются ролики по 10 секунд, где показаны другие ситуации, когда продукт помогает пользователю.
  • Видео на интернет-площадках создается с учетом их функционала. Например, в Instagram Stories можно использовать маски, в Facebook учитывать квадратный формат и возможность показать 360°.
  • HTML5-баннеры как альтернатива видео. Такие баннеры и позволяют показать анимацию, и вовлекают пользователя во взаимодействие. Учитывая, что в среднем видеоролики смотрят всего 2-3 секунды. Такие баннеры могут оказаться более эффективным инструментом. Главная проблема – существуют далеко не на всех площадках.

CPAx

Совсем другая история – это KPI на получение целевых действий. Когда вам нужно не просто рассказать о своем существовании, а довести пользователя до кликов, заказов, звонков или покупок, фокус стоит сместить на другие детали:

  • Мобильные видео в большинстве случаев проигрываются без звука. Поэтому субтитры – musthave.
  • Классический прием для повышения CTR: взаимодействия пользователя с интерфейсом приложения. Покажите процесс взаимодействия с приложением, пусть в кадре будет рука пользователя.
  • Call-to-action. Важно использовать в ролике призывы к действию: “установить приложение”, “заказать сейчас”, “играть в игру”. Не делайте их очень навязчивыми, но и не упускайте совсем.
  • Учитывайте возможности площадки.  Этот пункт по смыслу дублирует аналогичный в разделе Branding. В Instagram Stories можно добавить кнопку “еще”, в Facebook учитывать квадратный формат, добавить к объявлению кнопку и обыграть взаимодействие героев ролика с ней.

Тайминг

Отдельно скажу про время. Самые важные в ролике — первые 5 секунд. В них нужно обязательно вставить название продукта и вложить что-то, что может заинтересовать потребителя. Идеальная длина ролика — 15 секунд. Глобальная тенденция – не более 45 секунд, еще лучше – не более 30 секунд.

Если видео заинтересовало, то человек досмотрит его до конца. Первые 3-5 секунд должны “зацепить”.

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

Производство

  • Используйте трендовые инструменты. Для рекламы, нацеленной на неконсеватиную аудиторию, отлично работает следование последним трендам. Помните Prisma и Meitu? В следующий раз обязательно попробуйте новый модный сервис. Сейчас явно на пике анимоджи. Торопитесь, пока это не стало зашкваром.
  • Не забывайте о классических инструментах, которые у вас есть. Камеры iPhone достаточно, чтобы снять 10-секундный ролик для Facebook или Instagram. Добавьте классические элементы оформления, предоставленные на площадках. Такой подход к продакшну помогает убить сразу двух зайцев. Вы тратите на ролик 0 рублей и 10 минут своего времени. Пользователь видит узнаваемые элементы, дистанция между брендом и потребителем сокращается.

Сервисы для тех, у кого нет под рукой дизайнера, программиста, монтажера, оператора и прочих видеомейкеров: Supa, WeVideo, Animoto, Video Star.

Резюмирую:

  • Длина ролика не больше 20 секунд;
  • Самое важное в первых 3-5 секундах;
  • Акцент на интерфейсе приложения;
  • Учитывайте функционал площадки размещения;
  • Экспериментируйте с инструментами;
  • Помните, что можно сделать быстро и дешево без потери эффективности.
Комментарии
Продолжить чтение

Наша рассылка

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков веб и мобильных приложений!

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Популярное

X

Спасибо!

Теперь редакторы в курсе.