2021-02-26 15:25:17
AppLoca. Часть II
Здесь я рассказал что такое AppLoca и обещал дописать продолжение, почему же мы решили не создавать сервис для локализации приложений.
Напомню, что сервисов по управлению локализациями достаточно много и мы не хотели делать “еще один”, а хотели покрыть всего 2 сценария:
1. Локализация приложений условно бесплатно за счет участия юзеров.
2. Существенно повысить качество переводов профессиональных переводчиков за счет переводов прямо в приложении (нахождения в контексте) и упростить взаимодействие с переводчиками (им не пришлось бы заходить в какие-то внешние системы)
_________________________
Оказалось, что пока мы искали СЕО, некоторые сервисы уже выкатили возможность переводчику просмотреть как будет выглядеть перевод прямо на устройстве и у нас оставался, по сути, только первый сценарий как уникальный продукт.
Мы решили проверить, достаточно ли рынка для этого продукта - для этого я провел несколько десятков интервью с продакт-оунерами мобильных приложений и вот что выяснил - аудитория существенно ограничена такими критериями:
1. Нативные приложения. Мы не тестировали технологию для Unity (почти все игры) и кроссплатформенных фреймворков типа Xamarin, React.Native и т.д. Возможно, она работала бы и там тоже, но это еще предстояло выяснить.
2. Приложения с большим количеством юзеров, как правило, уже локализованы на основные 10-15 языков.
Из чего следует 2 вывода:
2.1. Нет уверенности, что локализация в мелких странах настолько сможет повысить ретеншн и/или конверсию в оплату, чтобы дополнительная прибыль стоила того, чтобы заморачиваться с локализацией. А ведь мы еще хотели бы как-то заработать на этом.
2.2. Те приложения, которые не локализованы даже на базовые языки - вряд ли имеют достаточное количество лояльной аудитории даже в основных странах, чтобы привлечь ее для локализации.
3. Большие приложения не в восторге от идеи встроить “еще один SDK”.
4. Большинство из опрошенных не пользуются даже существующими системами менеджмента локализаций и работают через гуглотаблицы (а многие просто делают гуглопереводы), т.е. не понимают ценности качественного перевода и еще не “созрели” для такого сервиса.
5. Те немногие, для кого такая потребность была актуальной - согласились платить сильно ниже той цены, которая могла бы быть нам интересна.
_________________________
Кроме вышеперечисленных проблем с объемом рынка, были еще внутренние риски:
1. На все ли интерфейсные объекты мы смогли бы навесить свой ивент через SDK?
2. Такие “перехваты” в интерфейсы потенциально могли увеличивать количество крашей приложения.
3. Необходимость проверки переводов. У нас была мысль избежать этого и сделать так, чтобы перевод автоматически применялся если, например, как минимум 80% переводчиков предложили один и тот же вариант перевода (при этом переводчиков не меньше 5).
Но такой подход открывал потенциальную возможность диверсии от конкурентов (конкурент, узнав что у приложения есть такая система, может скачать приложение и добавить туда некорректный перевод хоть 5, хоть 10 раз).
Все эти факторы в совокупности снизили привлекательность этого проекта и мы решили от него отказаться в пользу других, более привлекательных.
1.7K views12:25