Hot News
O Google publicou uma proposta na instância GitHub do projeto Schema.org que propõe propor uma atualização no Schema.org para expandir os dados estruturados de compras para que os comerciantes possam fornecer mais informações de envio que provavelmente aparecerão na Pesquisa Google e em outros sistemas.
Envio de dados estruturados do Schema.org
O novo tipo de dados estruturados proposto pode ser usado pelos comerciantes para fornecer mais detalhes de envio. Ele também sugere adicionar a flexibilidade de usar dados estruturados de envio em todo o site que podem então ser aninhados com os dados estruturados da organização, evitando assim ter que repetir as mesmas informações milhares de vezes em um site.
A proposta inicial afirma:
“Esta é uma proposta do Google para apoiar uma representação mais rica dos detalhes do envio (como custo e velocidade de entrega) e tornar explícito esse tipo de dados. Se adotado pelo schema.org e pelos editores, consideramos provável que as experiências de pesquisa e outros sistemas de consumo possam ser melhorados com o uso de tal marcação.
Esta alteração introduz um novo tipo, ShippingService, que agrupa as restrições de envio (locais de entrega, prazo, limites de peso e tamanho e taxa de envio). Os campos redundantes de ShippingRateSettings foram, portanto, descontinuados nesta proposta.
Como consequência, são também propostas as seguintes alterações:
alguns campos em OfferShippingDetails foram movidos para ShippingService;
ShippingRateSettings tem mais maneiras de especificar a taxa de envio, proporcional ao preço do pedido ou ao peso do envio;
a vinculação da Oferta agora deve ser feita com a vinculação padrão de URI da Web Semântica.”
A proposta está aberta para discussão e muitas partes interessadas estão oferecendo opiniões sobre como funcionariam os dados atualizados e novos estruturados.
Por exemplo, uma pessoa envolvida na discussão perguntou como um tipo de dados estruturados em todo o site colocado no nível da organização poderia ser substituído por produtos individuais com informações diferentes e outra pessoa forneceu uma resposta.
Um participante da discussão do GitHub chamado Tiggerito postou:
“Reli o documento e o que você disse faz sentido. A Organização é um local onde ShippingConditions compartilhadas podem ser armazenadas. Mas o ShippingDetails está sempre no nível ProductGroup ou Product.
É assim que eu lido atualmente com os detalhes de envio:
No back-end, o proprietário pode definir um conjunto global de detalhes de envio. Cada um contém os campos que o Google suporta atualmente, como localização e horários, mas não detalhes sobre dimensões. Cada entrada também tem condições para o produto ao qual a entrada pode ser aplicada. Isso pode incluir uma faixa de preço e uma faixa de peso.
Ao gerar os dados estruturados para uma página, incluo as entradas onde o produto atende às condições.
Parece que essa mudança me permitirá deixar de filtrar as condições no servidor e incluí-las nos dados estruturados na página do produto.
Em seguida, os consumidores dos dados podem calcular quais ShippingConditions correspondem e, portanto, quais taxas estão disponíveis ao solicitar um número específico do produto. Atualmente, você só pode fornecer preços para o envio de um.
A divisão também significa que é mais fácil fornecer informações específicas do produto, bem como informações de remessa compartilhadas, sem a necessidade de repetição.
Seu exemplo no documento ao final para usar Organization. Parece que você está fazendo referência a ShippingConditions para um produto que está em uma página de remessa. Essa referência cruzada entre as páginas pode reduzir bastante o inchaço que isso causa na página do produto, se for apoiado pelo Google.”
O Googler respondeu a Tiggerito:
“@Tiggerito
A Organização é um local onde ShippingConditions compartilhadas podem ser armazenadas. Mas o ShippingDetails está sempre no nível ProductGroup ou Product.
Na verdade, e este já é o caso. Esta mudança também separa os dois significados de, por exemplo. largura, altura, peso como descrição do produto (em ShippingDetails) e como restrições em ShippingConditions onde podem ser expressos como um intervalo (QuantitativeValue tem mínimo e máximo).
No back-end, o proprietário pode definir um conjunto global de detalhes de envio. Cada um contém os campos que o Google suporta atualmente, como localização e horários, mas não detalhes sobre dimensões. Cada entrada também tem condições para o produto ao qual a entrada pode ser aplicada. Isso pode incluir uma faixa de preço e uma faixa de peso.
Ao gerar os dados estruturados para uma página, incluo as entradas onde o produto atende às condições.
Parece que essa mudança me permitirá deixar de filtrar as condições no servidor e incluí-las nos dados estruturados na página do produto.
Em seguida, os consumidores dos dados podem calcular quais ShippingConditions correspondem e, portanto, quais taxas estão disponíveis ao solicitar um número específico do produto. Atualmente, você só pode fornecer preços para o envio de um.
Algumas restrições de envio não estão disponíveis no momento em que o produto é listado ou mesmo renderizado em uma página (por exemplo, destino de envio, número de itens, velocidade de entrega desejada ou nível de cliente se o usuário não estiver logado). O ShippingDetails anexado a um produto deve conter informações apenas sobre o produto em si; o restante é movido para o novo ShippingConditions nesta proposta.
Observe que o schema.org não especifica uma cardinalidade, de modo que poderíamos especificar vários links ShippingConditions para que o link apropriado seja selecionado no lado do consumidor.A divisão também significa que é mais fácil fornecer informações específicas do produto, bem como informações de remessa compartilhadas, sem a necessidade de repetição.
Seu exemplo no documento ao final para usar Organization. Parece que você está fazendo referência a ShippingConditions para um produto que está em uma página de remessa. Essa referência cruzada entre páginas pode reduzir bastante o inchaço que isso causa na página do produto, se for apoiado pelo Google.
De fato. É aqui que estamos tentando chegar.”
Discussão no LinkedIn
Irina Tuduce, membro do LinkedIn (perfil do LinkedIn), engenheira de software do Google Shopping, iniciou uma discussão que recebeu diversas respostas que demonstravam interesse pela proposta.
Andrea Volpini (perfil do LinkedIn), CEO e cofundador do WordLift, expressou seu entusiasmo pela proposta em sua resposta:
“Assim, Irina Tuduce agilizaria a modelagem de velocidade de entrega, locais e custos para grandes organizações
De fato. É aqui que estamos tentando chegar.”
Outro membro, Ilana Davis (perfil do LinkedIn), desenvolvedora do aplicativo JSON-LD para SEO Shopify, postou:
“Já dei meu feedback sobre as convenções de nomenclatura que eles implementaram no schema.org. Minha preocupação com o Google é como exatamente os comerciantes inserirão esses dados na marcação. É quase impossível obter taxas de envio exatas no SD se elas flutuarem. Os comerciantes podem inserir uma taxa fixa aproximada, mas muitas vezes se perguntam se isso é aceitável. Haverá consequências para eles se as taxas de envio forem aproximadas (por exemplo, uma incompatibilidade de preço no GMC desaprova um produto)?”
Uma visão interna do desenvolvimento de novos dados estruturados
A discussão contínua no LinkedIn oferece uma ideia de como as partes interessadas nos novos dados estruturados se sentem em relação à proposta. A discussão oficial do GitHub do Schema.org não apenas fornece uma visão de como a proposta está progredindo, mas também oferece às partes interessadas a oportunidade de fornecer feedback para definir como ela será.
Há também um documento público do Google intitulado Proposta de alteração do esquema de detalhes de envio, que contém uma descrição completa da proposta.
Imagem em destaque da Shutterstock/Stokkete
#hotnews #noticias #tecnologia #AtualizaçõesDiárias #SigaHotnews #FiquePorDentro #ÚltimasNotícias #InformaçãoAtual