Google опубликовал предложение в экземпляре проекта Schema.org на GitHub, в котором предлагается обновить Schema.org для расширения структурированных данных о покупках, чтобы продавцы могли предоставлять больше информации о доставке, которая, вероятно, будет отображаться в поиске Google и других системах.
Структурированные данные Schema.org о доставке
Предлагаемый новый тип структурированных данных может использоваться продавцами для предоставления более подробной информации о доставке. Он также предлагает добавить гибкость использования структурированных данных о доставке по всему сайту, которые затем можно вкладывать в структурированные данные Организации, тем самым избегая необходимости повторять одну и ту же информацию тысячи раз на веб-сайте.
В первоначальном предложении говорится:
«Это предложение Google поддержать более подробное представление деталей доставки (например, стоимости и скорости доставки) и сделать этот вид данных явным. Если такая разметка будет принята Schema.org и издателями, мы считаем вполне вероятным, что возможности поиска и другие потребительские системы могут быть улучшены за счет использования такой разметки.
Это изменение вводит новый тип ShippingService, который группирует ограничения доставки (места доставки, время, ограничения по весу и размеру, а также стоимость доставки). Поэтому избыточные поля из ShippingRateSettings в этом предложении признаны устаревшими.
В связи с этим также предлагаются следующие изменения:
некоторые поля в OfferShippingDetails перемещены в ShippingService;
ShippingRateSettings имеет больше способов указать стоимость доставки, пропорциональную цене заказа или весу доставки;
ссылки из Предложения теперь должны выполняться с помощью стандартных ссылок Semantic Web URI».
Предложение открыто для обсуждения, и многие заинтересованные стороны высказывают свои мнения о том, как будут работать обновленные и новые структурированные данные.
Например, один человек, участвовавший в обсуждении, спросил, как структурированный тип данных всего сайта, размещенный на уровне организации, может быть заменен отдельными продуктами, имеющими другую информацию, и кто-то другой дал ответ.
Участник дискуссии на GitHub по имени Тиггерито. опубликовано:
«Я перечитал документ, и то, что вы сказали, имеет смысл. Организация — это место, где могут храниться общие условия доставки. Но ShippingDetails всегда находится на уровне ProductGroup или Product.
Вот как я сейчас отношусь к деталям доставки:
В серверной части владелец может определить глобальный набор данных о доставке. Каждое из них содержит поля, которые Google в настоящее время поддерживает, например местоположение и время, но не содержит сведений об измерениях. В каждой записи также указаны условия, к какому продукту может относиться данная запись. Это может включать диапазон цен и диапазон веса.
Когда я генерирую структурированные данные для страницы, я включаю записи, в которых продукт соответствует условиям.
Похоже, что это изменение позволит мне перейти от фильтрации условий на сервере к включению их в структурированные данные на странице продукта.
Затем потребители данных могут рассчитать, какие условия доставки совпадают и, следовательно, какие тарифы доступны при заказе определенного количества продукта. В настоящее время вы можете указать цены только за доставку.
Разделение также означает, что легче предоставлять информацию о конкретном продукте, а также общую информацию о доставке без необходимости повторения.
Ваш пример в документе в конце для использования Organization. Похоже, вы ссылаетесь на Условия доставки для продукта, который находится на странице доставки. Подобные перекрестные ссылки между страницами могли бы значительно уменьшить раздувание страницы продукта, если бы это поддерживалось Google».
Гуглер ответил Тиггерито:
«@Тиггерито
Организация — это место, где могут храниться общие условия доставки. Но ShippingDetails всегда находится на уровне ProductGroup или Product.
Действительно, и это уже так. Это изменение также разделяет два значения, например. ширина, высота, вес в качестве описания продукта (в ShippingDetails) и в качестве ограничений в ShippingConditions, где они могут быть выражены в виде диапазона (QuantitativeValue имеет минимальное и максимальное значения).
В серверной части владелец может определить глобальный набор данных о доставке. Каждое из них содержит поля, которые Google в настоящее время поддерживает, например местоположение и время, но не содержит сведений об измерениях. В каждой записи также указаны условия, к какому продукту может относиться данная запись. Это может включать диапазон цен и диапазон веса.
Когда я генерирую структурированные данные для страницы, я включаю записи, в которых продукт соответствует условиям.
Похоже, что это изменение позволит мне перейти от фильтрации условий на сервере к включению их в структурированные данные на странице продукта.
Затем потребители данных могут рассчитать, какие условия доставки совпадают и, следовательно, какие тарифы доступны при заказе определенного количества продукта. В настоящее время вы можете указать цены только за доставку.
Некоторые ограничения на доставку недоступны на момент, когда продукт указан или даже отображается на странице (например, пункт назначения доставки, количество товаров, желаемая скорость доставки или уровень клиента, если пользователь не вошел в систему). Данные ShippingDetails, прикрепленные к товару, должны содержать только информацию о самом продукте, остальная часть перемещается в новые Условия доставки в этом предложении.
Обратите внимание, что на сайте Schema.org не указывается кардинальность, поэтому мы можем указать несколько ссылок ShippingConditions, чтобы на стороне потребителя выбиралась соответствующая.Разделение также означает, что легче предоставлять информацию о конкретном продукте, а также общую информацию о доставке без необходимости повторения.
Ваш пример в документе в конце для использования Organization. Похоже, вы ссылаетесь на Условия доставки для продукта, который находится на странице доставки. Такие перекрестные ссылки между страницами могут значительно уменьшить раздувание страницы продукта, если это поддерживается Google.
Действительно. Вот чего мы пытаемся достичь».
Обсуждение в LinkedIn
Участник LinkedIn Ирина Тудуче (Профиль в LinkedIn), инженер-программист Google Shopping, инициировал обсуждение которые получили несколько ответов, демонстрирующих интерес к этому предложению.
Андреа Вольпини (англ.Профиль в LinkedIn), генеральный директор и соучредитель WordLift, выразил энтузиазм по поводу этого предложения в своем ответе:
«Как и Ирина Тудуче, это упростит моделирование скорости доставки, местоположения и затрат для крупных организаций.
Действительно. Вот чего мы пытаемся достичь».
Другая участница, Илана Дэвис (Профиль в LinkedIn), разработчик JSON-LD для приложения SEO Shopifyразместил:
«Я уже высказал свое мнение о соглашениях об именах на сайте Schema.org, которые они реализовали. Меня беспокоит Google, как именно продавцы будут включать эти данные в разметку. Практически невозможно получить точные тарифы на доставку в SD, если они колеблются. Продавцы могут ввести приблизительную фиксированную ставку, но они часто задаются вопросом, приемлемо ли это. Будут ли для них последствия, если стоимость доставки будет приблизительной (например, несоответствие цен в GMC приведет к отклонению продукта)?»
Взгляд изнутри на разработку новых структурированных данных
продолжающееся обсуждение в LinkedIn предлагает взглянуть на то, как заинтересованные стороны в новых структурированных данных относятся к этому предложению. Официальный Обсуждение Schema.org на GitHub не только дает представление о том, как продвигается предложение, но и дает заинтересованным сторонам возможность предоставить обратную связь для формирования того, как оно в конечном итоге будет выглядеть.
Существует также общедоступный документ Google под названием: Предложение по изменению схемы деталей доставкикоторый содержит полное описание предложения.
Рекомендованное изображение: Shutterstock/Stokkete
