Поиск внутри платформы, а не только в Google

Что решаем

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

Полей, по которым платформа сопоставляет запрос, мало, и они короткие. Впишете туда не те слова — спрос пройдёт мимо.

При этом ничего не сломается и никуда ничего не запишется, поэтому такую поломку так дорого и искать.

Шаги

Каждая платформа сопоставляет свой набор полей. Разберитесь с этим набором до того, как что-то писать.

Платформа	По чему ищет	По чему не ищет
Telegram	Имя бота и @username	Description и About — их читают после того, как вас нашли
App Store	Title, subtitle, поле keywords, основная категория	Description и промо-текст
Google Play	Title и остальные метаданные карточки	—

Имя тянет весь поиск, поэтому пишите его их словами

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

Бюджеты маленькие, в этом вся трудность:

Поле	Лимит
Имя бота в Telegram	0–64 символа
Title в App Store	30 символов
Title в Google Play	30 символов
Короткое описание в Telegram	120 символов
Описание в Telegram	512 символов
Keywords в App Store	100 байт

Выбирать один алфавит при этом не обязательно. setMyName и setMyDescription принимают language_code, то есть носителям каждого языка вы показываете отдельное имя, и это самая дешёвая правка на всей странице.

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

Как потратить бюджет keywords и не повториться

Поле keywords у Apple вмещает 100 байт через запятую. Байт, а не символов. ASCII тратит байт на букву, кириллица в UTF-8 — два, так что для русского списка это примерно 50 букв.

На своей странице про product page Apple пишет «100 characters», но в справочнике App Store Connect стоят байты, и на приёмке действует именно справочник.

Слова, которые уже стоят в title или subtitle, повторять там не надо, а имена конкурентов в этом поле — частая причина отклонения.

Само поле относится к версии, а не к приложению целиком. Поэтому его и не находят.

Откройте Apps, выберите приложение, потом версию под её платформой в боковом меню: Keywords лежит там рядом с Description и Promotional Text и локализуется по языкам.

Name и Subtitle общие для всех версий. Они лежат под App Information, то есть на другом экране.

Прочитать метаданные обратно с платформы

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

getMe возвращает объект User — id, username и first_name, то есть имя бота, а описания в нём нет вообще, поэтому за полями описаний нужны отдельные вызовы.

getMyName, getMyDescription и getMyShortDescription читают по одному полю каждый и принимают language_code. Передавайте язык аудитории. Иначе прочитаете дефолт и решите, что ничего не установлено.

Поискать себя чужими глазами

Свежий аккаунт, язык аудитории, фразы, которые она правда набрала бы. Запишите, кто выходит.

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

Разметить каждую ссылку, ведущую внутрь платформы

Свой start parameter на каждую площадку. Пишите его в запись пользователя только при первом контакте.

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

Что не сработало

• Имя только на английском, когда спрос был в другом алфавите. Глобальный поиск сопоставляет имя, поэтому запросы в алфавите аудитории до бота не доходили вообще — ничего не ломалось и ничего не логировалось.
• Читать состав пользователей как сигнал рынка. География регистраций совпадала с латинским написанием имени, а не с рынком, под который я строил, поэтому недели ушли на продуктовые теории про эту аудиторию. А аудитория была артефактом одного поля метаданных.
• Рассчитывать, что вытянет description. Он всё это время был на нужном языке, но поиск по этому полю не сопоставляет, поэтому не изменилось ничего.
• Сравнивать продукты вместо имён. Конкуренты с функцией, выписанной в алфавите аудитории, были заметно крупнее, и работали они на тех же публичных API. У них было имя, а не технология.
• Считать символы против лимита в байтах. Поле keywords вмещает 100 байт, а кириллица тратит по два байта на букву: половины бюджета не стало до того, как я что-то набрал. На маркетинговой странице Apple написано «символы», её я и прочитал.
• Верить своей памяти об имени. Прочитанное обратно через API разошлось с тем, что я считал установленным, и все диагнозы до этой проверки стояли на неверном факте.
• Публиковать ссылки без start parameter. Код этот параметр тоже не читал, поэтому атрибуция была не приблизительной, а нулевой, и месяцы работы над дистрибуцией оценить было нечем.
• Считать сайт главной дверью. Источника не нёс ни один вход, значит доля сайта неизвестна: откуда пользователь пришёл. Позиции я поднимал по-настоящему, только направлял работу в канал, про который так и не показал, что им пользуются.

Проверить

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

• Прочитать имя, description и короткое описание обратно через API и сверить с тем, что вы собирались установить.

  curl -s "https://api.telegram.org/bot$TOKEN/getMyName?language_code=ru"

• Считать символы против лимитов платформы до отправки, а не после отклонения.

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

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

Снаружи платформы первые внешние ссылки берутся совсем в другом месте: откуда берутся первые внешние ссылки.