Оформление объявлений и карточки организации

На вкладке Рекламные материалы разместите рекламную информацию и добавьте изображения для оформления карточки. При этом все элементы заполнять необязательно. Все изменения настроек сразу отображаются в области предварительного просмотра выбранного блока.

Вся размещенная рекламная информация будет отображаться в карточке на Яндекс Картах, в том числе и в мобильном приложении. В Яндекс Навигаторе будет отображаться только акция.

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

Заголовок карточки

Акция

Анонс акции будет ссылкой на подробное описание в карточке организации.

Кнопка действия

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

Выберите надпись на кнопке и укажите ссылку, куда может перейти пользователь (см. требованиям к ссылкам).

Витрина товаров или услуг

Добавьте до 10 популярных товаров или услуг организации.

Товары для витрины можно добавлять автоматически из разных источников. Подробнее см. в Автоматическое добавление товаров.

Текстовое объявление

Подменный номер

Укажите номер, который надо заменить и добавьте описание.

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

Услуга будет подключена сразу после запуска рекламной кампании. Подробнее

Галерея

Для иллюстрации объявлений в Дзене и Рекламной сети Яндекса выберите фото из Яндекс Справочника, фотобанка (доступен не для всех рубрик), загрузите свои или используйте все три источника. Можно выбрать не более 10 штук.

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

Настройка доступна только для кампаний Рекламная подписка.

Партнерские ссылки

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

Вы можете отключить отображение ссылок в карточках.

Рекламные материалы должны соответствовать требованиям Яндекса, поэтому все тексты, ссылки и изображения проходят модерацию. Для рекламы товаров или услуг, требующих сертификации или лицензирования, необходимо предоставить подтверждающие документы.

Если вы размещаете несколько вариантов рекламных материалов, например акций или витрин товаров, то в объявлениях и на Картах будут опубликованы первые по дате создания.

Примечание. Если рекламная кампания запущена для Telegram, вместо вкладки Рекламные материалы будет показана вкладка Посты.

Написать в службу поддержки

Как Яндекс Карты с помощью отзывов улучшают поиск организаций / Хабр

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

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

Пара слов о геопоиске

Все запросы про адреса, местоположения объектов и организации в Яндекс Картах, Навигаторе и Поиске обрабатываются специальным внутренним компонентом — геопоиском. Геопоиск основан на базе организаций, которая читателям Хабра лучше всего знакома как Справочник. Владелец организации может указать в своей карточке информацию с помощью «рубрик» и «признаков».

И ещё не так давно поиск по организациям основывался исключительно на текстовом поиске по названию и фильтрации по рубрикам и признакам. Для этого в процессе поиска слова запроса сопоставляются с данными об организациях из Яндекс Бизнеса и обогащаются синонимами. Например, для запроса [кафе] выделяются рубрики «Кафе», «Ресторан», «Кофейня». Дальше геопоиск находит все организации с необходимыми характеристиками в нужной части карты. Чтобы облегчить пользователю задачу выбора, мы показываем ему только несколько десятков лучших организаций.

Чтобы из десятков тысяч отобранных на первой стадии заведений выбрать лучшие, мы используем библиотеку CatBoost. Модель работает на основе нескольких сотен самых разных признаков: рейтинга организации, расстояния до пользователя и так далее. Такой подход хорошо работает на простых запросах вроде [кафе] или [магазин продуктов], при этом большинство пользовательских запросов гораздо сложнее.

Рубрики и признаки — довольно сильное упрощение реального мира. Например, в запросе [уютное кафе] уютное — это признак? Не очень понятно, по какому критерию его нужно ставить. Такой признак очень сложно формализовать, и он будет иметь низкое качество.

К тому же текущие признаки оптимизированы для отображения в карточке организации, а не для поиска. Пользователи в поиске могут интерпретировать рубрику не так, как владелец организации, когда он её ставит. К примеру, популярная сеть закусочных отмечена как ресторан, имеется в виду «ресторан быстрого питания», а пользователь по запросу [ресторан] ожидает увидеть дорогие места с хорошим обслуживанием. В результате по сложным запросам мы можем не находить всех нужных организаций или в некоторых случаях показывать нерелевантные места — пользователю такие ошибки могут показаться глупыми.

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

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

Нейросети для поиска организаций

Классический способ использовать неструктурированные тексты в машинном обучении — это нейросети. В Яндексе есть несколько стандартных архитектур, которые очень удобно использовать в поиске. Для начала мы попробовали применить DSSM. Это достаточно старая архитектура, её устройство подробно описано в постах про «Палех» и «Королёв».

Если коротко, DSSM — сиамская сеть, в которой есть две независимые «башни»: одна, как правило, используется для представления запроса, другая — для представления документа. На вход башням подается «мешок слов», состоящий из слов запроса, словесных биграмм и буквенных триграмм. На выходе каждой башни получается слой эмбеддингов. Косинус вектора-эмбеддинга запроса и вектора-эмбеддинга документа — это и есть выход сети. По сравнению с современными большими нейросетями DSSM — более простая модель, её всё ещё можно применять на CPU за адекватное время, к тому же учить её гораздо быстрее, чем трансформеры. Именно поэтому мы начали с DSSM.

Какой же датасет подать на вход, чтобы сеть научилась «искать» по отзывам? Для обучения сетей настолько большого размера нужны миллионы примеров. В качестве источника данных такого объёма часто используют клики: в нашем случае мы могли бы по всем показам выдачи геопоиска пользователям собирать пары запрос-организация там, где пользователь кликнул на эту организацию. Но кликовый датасет обладает очевидным недостатком: данные в нём очень сильно смещены в наше текущее ранжирование. Если мы сейчас не очень хорошо умеем отвечать на запрос [уютное кафе], то способность предсказывать клики здесь не поможет.

Поэтому вместо кликов мы решили начать с редакторских подборок мест, размещённых в Яндекс Картах. Чтобы подготовить данные для обучения, мы сопоставили организации из подборок с запросами пользователей в веб-поиске Яндекса, по которым эта подборка показывалась хотя бы несколько раз.

При этом в качестве данных про организацию использовали топ отзывов.

К сожалению, таким методом у нас получилось сгенерировать лишь несколько сотен тысяч обучающих примеров. Для качественного обучения DSSM этого недостаточно, архитектура требует на несколько порядков больше данных на входе.

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

Мы взяли Large BERT, который был обучен по запросам пользователя в веб-поиск предсказывать, выбрал бы он этот документ в выдаче или нет. Такая модель уже достаточно хорошо умеет понимать тексты запросов. К тому же за счёт особенностей архитектуры она неплохо умеет работать с неизвестными словами. Это важное свойство модели, потому что в геозапросах пользователи часто используют названия населённых пунктов, мало встречающиеся в обычных текстах, к примеру, [почта в Урюпинске].

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

Мы попробовали несколько вариантов генерации примеров организаций, не входящих в подборку. Например, брали близкие организации в той же рубрике или просто случайные организации в том же регионе. В результате каждый раз у нас неплохо получалось обучить сеть. На части пула, которую она не видела в обучении, мы оценили precision — долю верно классифицированных позитивных примеров из всех, и recall — долю верно найденных позитивных примеров среди всех позитивных примеров. Для обеих метрик значения получились более 95%, что достаточно хорошо.

Как понять, будет ли такой BERT помогать ранжированию? Для оценки качества поиска по смыслу мы скачиваем поисковую выдачу по определённому набору запросов и просим экспертов оценить, является ли каждая организация в выдаче релевантной данному запросу. То есть — помогает ли она пользователю решить свою задачу. Мы добавили BERT в качестве признака в ранжирующий CatBoost геопоиска. К сожалению, ни один вариант BERT в качестве фичи не показывал существенных улучшений релевантности нашей выдачи. Кажется, предсказание подборок — это всё-таки неподходящая задача, надо было использовать какие-то другие данные.

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

Чтобы не попасть в режим переобучения и сохранить способность наших офлайн-метрик качественно оценивать выдачу, для обучения сети мы брали оценки на «отложенном» множестве запросов — тех, которые не участвовали в оценке качества. Обучив BERT, мы снова оценили его в качестве фичи CatBoost’а. И на этот раз получилось хорошо! Фича с предсказанием BERT входила в топ-5 по feature importance и статистически значимо улучшала loss.

Но нельзя просто взять и внедрить трансформер в рантайм. На CPU такая модель будет применяться слишком долго. Запрос в поиск с включённым подсчётом фичи для лучших найденных документов стал обрабатываться за несколько минут! И даже на GPU применение модели такого размера очень сильно увеличило бы время ответа поиска. К тому же нам хотелось бы перенести как можно больше тяжёлых вычислений на этап подготовки данных. Этого можно достичь с помощью DSSM, предпосчитав удобное для сети представление организаций, а в рантайме обчитывать только запросы. Поэтому мы приступили к дистилляции BERT в DSSM.

Дистилляция — процесс, позволяющий получить более простую модель, которая решает задачу практически с тем же качеством, что и тяжёлая. Для этого на гигантском пуле простую модель-«пародию» обучают предсказывать результаты работы тяжёлой модели. Мы собрали все наши выдачи по всем запросам из логов за год, для каждой пары (запрос — организация) посчитали скор BERT’а — его оценку, насколько организация релевантна запросу.

У нас получилось около 300 миллионов примеров в обучающем пуле. Мы подали на вход DSSM ровно те же данные, что использовались трансформером: запрос и топ отзывов про организацию, а в качестве таргета — скор Large BERT с предыдущего шага.

Модель-пародия оказывалась в топе по feature importance основного ранжирующего CatBoost’а, но loss уже не улучшался.

Небольшие изменения loss очень трудно интерпретировать, поэтому мы начали сравнивать вердикты BERT и DSSM на проблемных выдачах. Оказалось, что небольшое количество запросов типа [где поесть] и [кафе] занимают в обучающем пуле огромную долю. При этом на таких запросах наше ранжирование прекрасно справляется и без использования отзывов. А вот более сложных и проблемных запросов в пуле оказывалось гораздо меньше.

Мы подправили пул, устранив перекос в частотные запросы. В результате дистиллированный DSSM стал улучшать loss ранжирующей формулы.

При этом поначалу модель не оказывала существенного влияния на порядок в выдаче. Причина была в том, что для обучения нашего ранжирующего CatBoost’а используется комбинация сигналов разной степени сложности и чистоты. В итоге отзывы неплохо помогали на начальном этапе, но добиться большого улучшения было сложно. Тогда мы обратили внимание, что DSSM можно использовать и более просто — для фильтрации нерелевантных результатов из выдачи. С этим модель справлялась достаточно хорошо — ведь ровно на такой задаче дообучался исходный Large BERT. И вот в этой конфигурации наконец-то получилось увидеть улучшение в эксперименте и выкатить модель в продакшен.

Ниже пара примеров применения модели.

Скажем, раньше по запросу [торты Рязань] мы показывали сеть пиццерий «Ташир» и KFC. С помощью новой модели на базе отзывов нам удалось убрать нерелевантные результаты:

По запросу [кальянные в СПб] среди наших результатов был суши-бар «Токио Сити», а после внедрения модели в выдаче остались только кальян-бары.

Что в итоге?

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

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

Текущая отзывная нейросеть, конечно, не идеальна. Например, из-за ограничений по длине текста обрабатывается только часть отзывов — а ведь про вкусный фалафель могут писать и не в самом первом из них. У нас на подходе новые модели, которые способны учитывать больше отзывов в Картах, а также включают в себя другие сигналы, полезные при определении релевантности документа. Важный итог: по офлайн-замерам релевантности дистиллированная модель на отзывах в одиночку дала такое же улучшение качества поиска, как все внедрения нашей команды за предыдущий квартал.

ios — Не работает кран метки на карте Яндекса. Swift

У меня есть несколько меток на карте. Добавили к ним тап-жесты. Добавление слушателя в цикл for заменяет касание один за другим, и только последний маркер имеет жест. Локальная ссылка вообще не работает, она не обеспечивает отвод. только с сильной ссылкой это работает. не могу понять, как я могу нажать на все из них.

 функция showMarkers() {
    пусть mapObjects = yandexMapView.mapWindow.map.mapObjects
    mapObjects.clear()
    
    для pickupPoint в masterVC?.aryPickupPoints ?? [] {
        если pickupPoint.latitude != 0 && pickupPoint.longitude != 0 {
            let point = YMKPoint(широта: pickupPoint.широта!, долгота: pickupPoint.longitude!)
            
            let placemark = mapObjects.addPlacemark (с точкой)
            placemark. userData = точка получения
            
            переключатель pickupPoint.pickupType {
            случай 3:
                если пусть изображение = UIImage (с именем: "lockerPin") {
                    placemark.setIconWith(self.imageWithImage(изображение: изображение, scaledToSize: CGSize(ширина: 30, высота: 40)))
                }
            по умолчанию:
                если пусть изображение = UIImage (с именем: "otherPin") {
                    placemark.setIconWith(self.imageWithImage(изображение: изображение, scaledToSize: CGSize(ширина: 30, высота: 40)))
                }
            }
            dLog("--------------------------- \(точка)----------------")
            
            // Клиентский код должен сохранять сильную ссылку на слушателя.
            yandexMapObjectTapListener = YandexMapObjectTapListener(controller: self)
            placemark.addTapListener(с: yandexMapObjectTapListener)
        }
    }
//MARK: - YandexMapObjectTapListener
закрытый класс YandexMapObjectTapListener: NSObject, YMKMapObjectTapListener {
    частный слабый контроллер var: UIViewController?
    var selectedPickupPoint: PickupPoint?
    инициализация (контроллер: UIViewController) {
        self. controller = контроллер
    }
    func onMapObjectTap (с mapObject: YMKMapObject, точка: YMKPoint) -> Bool {
        охранять пусть маркер = mapObject как? YMKPlacemarkMapObject иначе {вернуть false}
        пусть pickupPoint = marker.userData как? Место сбора
        пусть данные = ["pickupPoint": pickupPoint как любой,
                    "marker": маркер] как [String: Any]
        NotificationCenter.default.post (имя: NSNotification.Name (rawValue: NotificationObserver.ShowBottomSheet), объект: ноль, userInfo: данные)
        вернуть истину
    }
}
 

• ios
• свифт
• яндекс

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя электронную почту и пароль

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Условия использования API Яндекс.

Карт. Руководство разработчика

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

API можно использовать бесплатно или на коммерческой основе. Бесплатное использование ограничено рядом условий. Коммерческая версия API предназначена для коммерческого использования и снимает ограничения бесплатной версии. Подробнее о коммерческой версии.

Перед использованием API внимательно прочитайте Условия использования. Они представлены ниже.

1. API нельзя использовать без ключа API

Для работы с бесплатной версией API необходимо получить ключ API. Если вы хотите использовать API без ключа API, приобретите коммерческую версию API.

2. API может использоваться только в проектах с открытым доступом

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

3. API не может использоваться в коммерческих проектах

лицензирование. Если вы хотите использовать API в коммерческом проекте, приобретите коммерческую версию API.

4. Данные, полученные через API, должны отображаться на карте Yandex

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

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

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

Если вам необходимо сохранить или изменить данные, полученные с помощью API, напишите нам.

6. Запрещено скрывать или изменять авторские права Yandex и логотипы на карте

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

7. API не может быть использован для мониторинга и отправки

Когда используя бесплатную версию API, You ON MANT: . Отслеживайте транспортные средства, людей и другие объекты в режиме реального времени. Автоматически следовать по маршруту, как в случае с навигатором. Решаем логистические задачи, такие как согласование доставки или построение оптимальных маршрутов для курьерских служб. Для этих проектов используйте коммерческую версию API.

8. Суточный лимит запросов к API не должен превышаться0002 API устанавливает дневной лимит на использование сервисов геокодирования и маршрутизации Яндекса, а также панорам. В бесплатной версии API ограничение для HTTP Geocoder составляет 1000 запросов в сутки . Для JavaScript API ограничение составляет 25 000 запросов в день. Дополнительные сведения о том, какие запросы подпадают под это ограничение, см. в таблице ниже.

Если вам необходимо увеличить дневной лимит, приобретите коммерческую версию API.

Примечание. Обратите внимание, что Условия использования API регулируются Пользовательским соглашением. Текущий документ лишь разъясняет условия соглашения.

Для API JavaScript и HTTP API геокодера установлены следующие ограничения:

• Запросов в секунду (RPS): до 50. Рассчитывается как сумма запросов от клиента и от сервера.

• Общее количество запросов. Общее количество запросов рассчитывается по следующей формуле:

  Запросы геокодера + Запросы маршрутизатора + 5 × Запросы панорамы

  В бесплатной версии общее количество запросов не может превышать 25 000 в день, из них количество запросов к HTTP API Геокодера не может превышать 1000 в день. Если вы превысите лимит, установленный для JavaScript API или HTTP API Geocoder, вам следует перейти на коммерческую версию API, где этот лимит устанавливается в зависимости от тарифного плана.

Ниже приведены операции, формирующие запросы к перечисленным сервисам, то есть они учитываются в лимите API.

4 API геокодирования.

— Вызов функции геокодирования().

— Получение местоположения пользователя через функцию geolocation.get(), при условии, что включено обратное геокодирование (опция autoReverseGeocode установлена ​​на верно ).

— Построение маршрута при условии, что его точки указаны в виде адресов, как в примере. Каждый адрес инициирует отдельный запрос к геокодеру.

— Поиск по карте через элемент searchControl() (с любым поставщиком поиска).

Не учитываются следующие операции :

— Геолокация с отключенным обратным геокодированием (опция autoReverseGeocode установлена ​​на false ).

Сервис	Операции
Геокодирование
Маршрутизация	— Создание экземпляра класса multiRouter.MultiRoute. — Построение маршрута через элемент control.RoutePanel. — Редактирование построенного маршрута: добавление, удаление и перетаскивание точек. — Изменение параметров маршрутизатора таким образом, что это приводит к повторной маршрутизации. Например, включение опции маршрутизации пробок или изменение типа маршрутизации. — Вызов функции route().
Яндекс Панорамы	— Вызов функцииpanorama.locate() для поиска панорам в окрестностях заданной точки. — Вызов функции панорамы.createPlayer() для встраивания плеера с панорамой Яндекса на страницу. — Вызов метода панорамы.Manager.openPlayer() для отображения плеера с панорамой Яндекса. Не учитываются следующие операции : — Переходы между связанными панорамами внутри открытого плеера, например переходы с помощью стрелок. — Создание плеера со своей панорамой. — Добавление слоя панорамы на карту.

* При перетаскивании точек маршрута запросы к роутеру отправляются в среднем каждые 3 секунды, если скорость ответа сервера достаточно высока.