Заголовок приложения имеет самый высокий вес для ранжирования в App Store — выше, чем описание, ключевые слова и подзаголовок вместе взятые. Логика подсказывает: нужно название с ключевым словом, максимально описывающее суть продукта. «Фитнес трекер шагов» — казалось бы, идеальный вариант для поиска.
А теперь смотрим на закон. По статье 1483 ГК РФ главное требование к товарному знаку — различительная способность: название должно указывать на производителя, а не описывать сам товар. Фантазийные слова типа «Яндекс» или «Kodak» регистрируются без проблем. Описательные конструкции типа «Свежий хлеб» или «Фитнес трекер шагов» — почти никогда. Получается, что чем лучше название работает на ASO, тем хуже оно проходит регистрацию. Это не теоретический конфликт, а то, с чем сталкивается каждая вторая команда, выбирающая имя по советам из статей про App Store Optimization.
Рабочий компромисс — гибридная структура: придумывать фантазийное или частично неологичное ядро названия, а описательную часть выносить в подзаголовок (subtitle в App Store) или в имя разработчика в Google Play, которое там тоже индексируется полностью. Так бренд получает юридическую защиту, а поиск — ключевые слова.
Ограничение по символам в обоих сторах — 30 знаков. Но пользователь на экране смартфона видит примерно 15 символов, а на главном экране iOS — и того меньше, около 11. Это значит, что решающую роль играют первые слова: если смысл или узнаваемость появляются после 12-го символа, для большинства пользователей их просто не существует.
| Параметр | App Store | Google Play |
|---|---|---|
| Что индексируется | Название, подзаголовок, ключевые слова (скрытое поле) | Название, полное описание, имя разработчика |
| Вес названия в ранжировании | Самый высокий среди всех полей | Высокий, но конкурирует с текстом описания |
| Видимая часть на экране | ~11 символов на главном экране | ~15 символов в списке результатов |
| Как определяется локализация | По загруженным локалям в App Store Connect | По загруженным локалям в Play Console |
Отдельная ошибка — писать в описании фразу «available in 10 languages», надеясь усилить релевантность. Оба стора определяют, на каких языках доступно приложение, не по тексту, а по факту загруженных локализаций в консоли разработчика. Символы описания, потраченные на это, просто выброшены.
Проверка свободного домена — это привычка, унаследованная из веб-нейминга, и для приложений она обманчива. Свободный домен ничего не говорит о том, зарегистрирован ли похожий товарный знак в Роспатенте. Нужно проверять базу по классам МКТУ — для мобильного приложения это, как правило, сразу несколько классов: 09 (программное обеспечение), 42 (услуги по разработке ПО, SaaS) и 45 (если продукт связан с юридическими или персональными сервисами).
Суды и патентные эксперты при оценке сходства смотрят на три признака одновременно:
Добавление одного слова или смена окончания редко спасает. Известен показательный пример из ИТ-сферы: названия «Окошки» и «Есть окошко» были признаны сходными для целей защиты знака, хотя визуально это разные фразы. Это значит, что при выборе имени нельзя ограничиваться проверкой точного совпадения — нужно искать фонетически близкие варианты в тех же классах.
Команда, разрабатывавшая приложение для сна, выбрала название Sova — «сова» по-русски, логичная ассоциация с ночью и отдыхом. Проверили английский и русский — всё чисто, ассоциации положительные. Но название не проверили на шведском и французском.
По-шведски «sova» буквально означает «спать» — казалось бы, удачное совпадение для приложения о сне. А вот во французском произношении название звучит как «Ça va?» — разговорное «как дела?», что создаёт странную путаницу при звуковой рекламе и голосовом поиске. Ни то, ни другое не критично на этапе локального запуска в одной стране, но становится проблемой в момент масштабирования на несколько рынков одновременно, когда одно и то же имя должно работать в App Store сразу нескольких локалей. Вывод простой: проверка культурного и фонетического значения нужна на всех языках, где планируется запуск, а не только на тех, что кажутся очевидными.
С 2026 года требование к локализованным названиям для глобальных приложений становится обязательным, а не опциональным. Частая ошибка — брать русское или английское ядро семантики и переводить его буквально на другие языки, сохраняя структуру ключевых слов.
Это не работает, потому что поисковое поведение отличается по странам сильнее, чем кажется. Один и тот же продукт — танковый шутер — в Турции ищут по запросу «игра про танки», а в Великобритании тот же жанр называют «онлайн-стрелялка», хотя технически это разные акценты одного игрового процесса. Правильный подход — собирать семантическое ядро заново для каждого рынка через локальные инструменты частотности запросов, а не переводить существующий список ключевых слов через словарь.
Полноценную юридическую экспертизу поверенный проведёт лучше, но базовый фильтр можно сделать самостоятельно и отсечь заведомо провальные варианты до того, как тратить деньги на консультацию.
Этот набор шагов не заменяет патентную экспертизу перед подачей заявки, но отсекает большинство кандидатов, которые заведомо создадут проблемы — и экономит время на переговоры с поверенным по единственному оставшемуся варианту, а не по десяти.
Заголовок приложения имеет самый высокий вес для ранжирования в App Store — выше, чем описание, ключевые слова и подзаголовок вместе взятые. Логика подсказывает: нужно название с ключевым словом, максимально описывающее суть продукта. «Фитнес трекер шагов» — казалось бы, идеальный вариант для поиска.
А теперь смотрим на закон. По статье 1483 ГК РФ главное требование к товарному знаку — различительная способность: название должно указывать на производителя, а не описывать сам товар. Фантазийные слова типа «Яндекс» или «Kodak» регистрируются без проблем. Описательные конструкции типа «Свежий хлеб» или «Фитнес трекер шагов» — почти никогда. Получается, что чем лучше название работает на ASO, тем хуже оно проходит регистрацию. Это не теоретический конфликт, а то, с чем сталкивается каждая вторая команда, выбирающая имя по советам из статей про App Store Optimization.
Рабочий компромисс — гибридная структура: придумывать фантазийное или частично неологичное ядро названия, а описательную часть выносить в подзаголовок (subtitle в App Store) или в имя разработчика в Google Play, которое там тоже индексируется полностью. Так бренд получает юридическую защиту, а поиск — ключевые слова.
Ограничение по символам в обоих сторах — 30 знаков. Но пользователь на экране смартфона видит примерно 15 символов, а на главном экране iOS — и того меньше, около 11. Это значит, что решающую роль играют первые слова: если смысл или узнаваемость появляются после 12-го символа, для большинства пользователей их просто не существует.
| Параметр | App Store | Google Play |
|---|---|---|
| Что индексируется | Название, подзаголовок, ключевые слова (скрытое поле) | Название, полное описание, имя разработчика |
| Вес названия в ранжировании | Самый высокий среди всех полей | Высокий, но конкурирует с текстом описания |
| Видимая часть на экране | ~11 символов на главном экране | ~15 символов в списке результатов |
| Как определяется локализация | По загруженным локалям в App Store Connect | По загруженным локалям в Play Console |
Отдельная ошибка — писать в описании фразу «available in 10 languages», надеясь усилить релевантность. Оба стора определяют, на каких языках доступно приложение, не по тексту, а по факту загруженных локализаций в консоли разработчика. Символы описания, потраченные на это, просто выброшены.
Проверка свободного домена — это привычка, унаследованная из веб-нейминга, и для приложений она обманчива. Свободный домен ничего не говорит о том, зарегистрирован ли похожий товарный знак в Роспатенте. Нужно проверять базу по классам МКТУ — для мобильного приложения это, как правило, сразу несколько классов: 09 (программное обеспечение), 42 (услуги по разработке ПО, SaaS) и 45 (если продукт связан с юридическими или персональными сервисами).
Суды и патентные эксперты при оценке сходства смотрят на три признака одновременно:
Добавление одного слова или смена окончания редко спасает. Известен показательный пример из ИТ-сферы: названия «Окошки» и «Есть окошко» были признаны сходными для целей защиты знака, хотя визуально это разные фразы. Это значит, что при выборе имени нельзя ограничиваться проверкой точного совпадения — нужно искать фонетически близкие варианты в тех же классах.
Команда, разрабатывавшая приложение для сна, выбрала название Sova — «сова» по-русски, логичная ассоциация с ночью и отдыхом. Проверили английский и русский — всё чисто, ассоциации положительные. Но название не проверили на шведском и французском.
По-шведски «sova» буквально означает «спать» — казалось бы, удачное совпадение для приложения о сне. А вот во французском произношении название звучит как «Ça va?» — разговорное «как дела?», что создаёт странную путаницу при звуковой рекламе и голосовом поиске. Ни то, ни другое не критично на этапе локального запуска в одной стране, но становится проблемой в момент масштабирования на несколько рынков одновременно, когда одно и то же имя должно работать в App Store сразу нескольких локалей. Вывод простой: проверка культурного и фонетического значения нужна на всех языках, где планируется запуск, а не только на тех, что кажутся очевидными.
С 2026 года требование к локализованным названиям для глобальных приложений становится обязательным, а не опциональным. Частая ошибка — брать русское или английское ядро семантики и переводить его буквально на другие языки, сохраняя структуру ключевых слов.
Это не работает, потому что поисковое поведение отличается по странам сильнее, чем кажется. Один и тот же продукт — танковый шутер — в Турции ищут по запросу «игра про танки», а в Великобритании тот же жанр называют «онлайн-стрелялка», хотя технически это разные акценты одного игрового процесса. Правильный подход — собирать семантическое ядро заново для каждого рынка через локальные инструменты частотности запросов, а не переводить существующий список ключевых слов через словарь.
Полноценную юридическую экспертизу поверенный проведёт лучше, но базовый фильтр можно сделать самостоятельно и отсечь заведомо провальные варианты до того, как тратить деньги на консультацию.
Этот набор шагов не заменяет патентную экспертизу перед подачей заявки, но отсекает большинство кандидатов, которые заведомо создадут проблемы — и экономит время на переговоры с поверенным по единственному оставшемуся варианту, а не по десяти.