Google предлагает новые структурированные данные о покупках, которые позволят продавцам предоставлять еще больше информации о доставке
Google опубликовал предложение в экземпляре Schema.org Project GitHub, в котором предлагается предложить обновление на Schema.org для расширения структурированных данных о покупках, чтобы продавцы могли предоставлять больше информации о доставке, которая, вероятно, будет отображаться в Поиске Google и другие системы.
Shipping Schema.org Structured Data
Предлагаемый новый тип структурированных данных может использоваться продавцами для предоставления дополнительной информации о доставке. Он также предлагает добавить гибкость использования структурированных данных о доставке на всем сайте, которые затем можно вкладывать в структурированные данные организации, таким образом избегая необходимости повторять ту же информацию тысячи раз на веб-сайте.
Начальное предложение говорит:
<цитата>
“Это предложение от Google для поддержания более детального представления деталей доставки (таких как стоимость и скорость доставки) и предоставления таких данных четко. Если schema.org и издатели примут решение, мы считаем вероятным, что опыт поиска и другие системы потребления можно будет улучшить с помощью такой разметки.
Это изменение вводит новый тип, ShippingService, который группирует ограничение доставки (места доставки, время, ограничение веса и размера и скорость доставки). Таким образом, в этом предложении устарели избыточные поля из ShippingRateSettings.
Как следствие, также предлагаются следующие изменения:
некоторые поля в OfferShippingDetails перемещены к ShippingService;
ShippingRateSettings имеет больше способов указать ставку доставки, пропорциональную цене заказа или весу доставки;
связывание с Предложением теперь должно осуществляться с помощью стандартного связывания URI семантического веба.~~Предложение открыто для обсуждения, и многие заинтересованные стороны высказывают свои мнения относительно того, как будут работать обновленные и новые структурированные данные.
Например, один человек, участвовавший в обсуждении, спросил, как тип структурированных данных на уровне сайта, размещенный на уровне организации, может быть заменен отдельными продуктами с другой информацией, и кто-то другой ответил.
Участник дискуссии GitHub по имени Tiggerito написал:
<цитата>
“Я перечитал документ и то, что вы сказали, имеет смысл. Организация – это место, где могут сохраняться общие условия доставки. Но ShippingDetails всегда на уровне ProductGroup или Product.
Вот как я сейчас имею дело с деталями доставки:
На задней части владелец может определить глобальный набор деталей доставки. Каждое содержит поля, которые теперь поддерживают Google, например местоположение и время, но не указывает на размеры. Каждая запись также содержит условия продукта, к которому он может применяться. Это может включать диапазон цен и диапазон веса.
Когда я&m;rsquo;м генерирую структурированные данные для страницы, я включаю записи, где продукт соответствует условиям.
Похоже, это изменение позволит мне изменить фильтрацию условий на сервере на включение их в структурированные данные на странице продукта.
Тогда потребители данных могут вычислить, какие условия доставки соответствуют и, следовательно, какие тарифы доступны при заказе определенного количества товара. Теперь вы можете указать цены только за доставку одного.
Разделение также означает, что легче предоставлять информацию о продукте, а также общую информацию о доставке без необходимости повторять.
Ваш пример в документе в конце использования Организации. Похоже, вы ссылаетесь на условия доставки для продукта на странице доставки. Эта перекрестная ссылка между страницами могла бы значительно уменьшить разгрузку страницы продукта, если это поддерживается Google.~~~~~~~>Рабочий Google ответил Tiggerito:
<блочная цитата>
“@Tiggerito
Организация является местом, где могут сохраняться общие условия доставки. Но ShippingDetails всегда на уровне ProductGroup или Product.
В самом деле, и это уже так. Это изменение также разделяет два значения напр. ширина, высота, вес как описание продукта (у ShippingDetails) и как ограничение в ShippingConditions, где их можно выразить как диапазон (QuantitativeValue имеет min и max).
На серверной части владелец может определить глобальный набор деталей доставки. Каждое содержит поля, которые теперь поддерживают Google, например местоположение и время, но не указывает на размеры. Каждая запись также содержит условия продукта, к которому он может применяться. Это может включать диапазон цен и диапазон веса.
Когда я&m;rsquo;м создаю структурированные данные для страницы, я включаю записи, где продукт соответствует условиям.
Кажется, это изменение позволит мне изменить фильтрацию условий на сервере на включение их в структурированные данные на странице продукта.
Тогда потребители данных могут вычислить, какие условия доставки соответствуют и, следовательно, какие тарифы доступны при заказе определенного количества товара. Теперь вы можете указать цены только на доставку одного.
Некоторые ограничения по доставке недоступны в то время, когда продукт размещен в списке или даже отображен на странице (например, пункт назначения, количество товаров, желаемая скорость доставки или уровень клиента, если пользователь не вошел в систему) . Поле ShippingDetails, добавленное к продукту, должно содержать информацию только о самом продукте, остальное переносится к новым условиям доставки в этом предложении.
Обратите внимание, что schema.org не указывает мощность, чтобы мы могли указать несколько ссылок ShippingConditions, чтобы соответствующее было выбрано на стороне потребителя.
Разделение также означает, что легче предоставлять информацию о продукте, а также общую информацию о доставке без необходимости повторять.
Ваш пример использования Организации в документе в конце. Похоже, вы ссылаетесь на условия доставки для продукта на странице доставки. Эта перекрестная ссылка между страницами могла бы значительно уменьшить раздутость страницы продукта, если это поддерживается Google.
Действительно. Вот где мы пытаемся достигнуть.”
Обсуждение на LinkedIn
Участница LinkedIn Ирина Тудуце (профиль LinkedIn), инженер-программист в Google Shopping, инициировала обсуждение, которое получило многочисленные ответы, демонстрирующие интерес к предложению.
Андреа Вольпини (профиль в LinkedIn), генеральный директор и соучредитель WordLift, выразил свой энтузиазм относительно предложения в своем ответе:
“Как это Ирина Тудуце, это оптимизировало бы моделирование скорости доставки, мест расположения и стоимости для крупных организаций
Действительно. Вот где мы пытаемся достигнуть.”
Другая участница, Илана Дэвис (профиль в LinkedIn), разработчик JSON-LD для SEO Shopify App, опубликовала:
“Я уже прислал свой отзыв о правилах именования на schema.org, которые они реализовали. Меня волнует Google, как именно продавцы внесут эти данные в разметку. Практически невозможно получить точные тарифы доставки в SD, если они колеблются. Продавцы могут ввести приблизительную фиксированную ставку, но они часто задаются вопросом, приемлемо ли это. Есть ли для них последствия, если тарифы доставки приблизительны (например, несоответствие цены в GMC отклоняет продукт)?
Взгляд изнутри на разработку новых структурированных данных
Длительная дискуссия на LinkedIn предлагает понять, как заинтересованные стороны новых структурированных данных относятся к предложению. Официальное обсуждение Schema.org GitHub не только предоставляет просмотр как продвигается предложение, она предлагает заинтересованным сторонам возможность предоставить отклик для формирования того, как оно в конечном итоге будет выглядеть.
Существует также общедоступный документ Google под названием «Предложение по изменению схемы доставки деталей», содержащий полное описание предложения.