Tip:
Highlight text to annotate it
X
DANNY HERMES: Muito bem.
Olá a todos.
Bem-vindos a este seminário na Web sobre como manter
os dados do produto atualizados.
Chamo-me Danny Hermes.
Pertenço ao departamento de RP de programação
da equipa comercial da Google.
Estamos a esforçar-nos por difundir algumas das nossas APIs,
a fornecer ajuda e feedback e, ainda, a realizar eventos
como este seminário na Web.
Hoje, comigo, estão Ali Afshar, Amanda Surya e Jasmine Kahn.
Estarão no chat connosco para responder às suas perguntas.
Esteja à vontade para perguntar.
Existe a opção para levantar a mão, mas não o faça.
Basta que coloque a questão e esta será abordada
da melhor forma possível.
Sem mais delongas, vamos começar.
Hoje, esperamos responder a algumas questões muito importantes
acerca da API de Conteúdo.
Primeiro, o que é?
Segundo, o que é a nossa política de atualização de dados
e de que forma se aplica à API?
Por que deve você escolher esta API?
Vamos comparar e contrastar
a API e feeds de dados.
Depois, vem a implementação.
Como pode utilizar a API?
Por isso, se tiver dúvidas sobre algum dos diapositivos,
coloque-as no chat para tentarmos obter
uma resposta aceitável.
Para começar, o que é o Google Content API for Shopping?
Antes de abordarmos este assunto, precisamos de falar sobre o
Google Shopping.
Os itens vão para o Google Shopping,
ao serem carregados para o Google Merchant Center.
Os dados do produto ficam armazenados no Merchant Center
e, daí, são transferidos para o Google Shopping
no ambiente de trabalho.
Depois, são transferidos para o Google Shopper no Google Mobile
e para outros canais, como o Google Affiliate Network e o Google
Commerce Search.
Digamos que tem três câmaras digitais
que quer vender.
Basta carregar os itens para o Google Merchant Center
e, depois, alguém vai ao Google
procurar câmaras digitais.
Aqui estão elas, realçadas a azul,
as três câmaras que carregou.
Recapitulando, para que um item surja no Google Shopping,
em primeiro lugar tem de ser carregado para
o Google Merchant Center.
Existem duas formas de efetuar este processo:
o Google Product Feeds e a aplicação que vamos abordar hoje,
o Google Content API for Shopping.
O que é o Google Content API for Shopping?
É a questão a que prometi responder.
É uma API com base em HTTP, REST e GData.
O que significa isto?
Você tem um pedido com todos os dados do produto
e pode obter, publicar, colocar ou eliminar.
São quatro verbos de uma API baseada em REST.
Envia o pedido para o nosso recurso,
em googleapis.com,
e nós enviamos-lhe uma resposta em XML.
Vamos falar um pouco sobre APIs.
Uma API permite interagir de forma programada
com elementos como os servidores da Google
ou, neste caso, com o Google Merchant Center.
É uma forma que permite a comunicação
entre dois programas.
Ao contrário dos feeds... Um feed de dados é apenas um ficheiro
com todas as informações sobre os seus produtos.
É muito semelhante ao pedido enviado
através da API de Conteúdo, só que não passa de um simples
ficheiro .txt ou .xml.
Estes ficheiros contêm os atributos e entidades
que definem o que os seus dados de produto específicos são.
Estes ficheiros .txt ou .xml
são carregados diretamente para o Google Merchant Center.
Assim, o Google Content API for Shopping
permite que os seus programadores carreguem esses dados de forma programada
para todos os Web sites de compras da Google.
Permite-lhe gerir subcontas
para o caso de ter um mercado e de estar a gerir vários
vendedores ou sublojas.
E também lhe permite configurar feeds de dados.
Portanto, se quer misturar e corresponder com a API de Conteúdo
utilizando feeds de dados, pode gerir esses feeds
através da API.
Depois de ter carregado os seus dados,
pode obter desempenho e configurar outros elementos
através do Painel de controlo do Google Merchant Center.
Este painel de controlo contém informações
sobre os feeds que utiliza atualmente, os produtos que já carregou,
a qualidade dos dados e outras estatísticas de desempenho.
Além disso, com a API pode controlar cliques.
Ao enviar um pedido para o link neste diapositivo
- não vou explicar isto na totalidade -
está a definir uma data de início,
uma data de fim e um item específico.
Depois, regressa ao controlo de cliques nesse intervalo de datas.
É um benefício extra que incluímos nesta API.
Em seguida, a política de atualização.
Quando alguém vai à Pesquisa do Google para pesquisar um produto,
se este surgir com o preço de $102, como pode ver aqui,
o utilizador espera poder comprar o item
por $102.
Se o preço base for diferente do preço total,
o utilizador espera saber a diferença.
Ou seja, o utilizador quer saber
quanto vai acabar por pagar, certo?
Relativamente ao Google Shopping,
estamos preocupados com três pessoas.
Em primeiro lugar, estamos preocupados com o utilizador.
Queremos que este tenha a melhor experiência possível,
queremos que consiga encontrar aquilo que procura
e queremos que consiga obter informações precisas
sobre estes produtos.
Em segundo lugar, estamos preocupados com os revendedores e comerciantes.
Estamos preocupados com as pessoas que vendem os seus bens,
porque também queremos que tenham uma experiência agradável
na oferta dos bens através do Google Shopping.
Em terceiro lugar, estamos nós.
Só queremos satisfazer todos os intervenientes.
Com isto em mente, a política de atualização do Google Data diz:
"Quando um utilizador visita...", etc, etc.
Não vou ler o texto todo aqui.
Se quer ler a política, aceda ao link no fim deste diapositivo:
goo.gl/C5P8X.
A política descreve o que explicámos sobre a atualização de dados,
mas lembre-se de que primeiro está o utilizador,
depois estão vocês e, por último, estamos nós.
Como é que isto se aplica à API de Conteúdo?
Um exemplo específico: se os preços e quantidades se alterarem com frequência,
certamente gostaria de poder atualizar os seus itens
de modo a que essas alterações se reflitam no Google Shopping.
Se utiliza feeds, só pode atualizar
um número limitado de vezes por dia,
o que limita a frequência com que pode atualizar
os preços e quantidades.
Já o Google Content API for Shopping permite-lhe atualizar os itens
assim que os preços se alteram,
e as alterações são logo efetuadas.
Além disso, se tem um inventário de itens muito extenso,
a manutenção e carregamento diários
do mesmo feed todos os dias pode tornar-se inviável.
Por isso, um carregamento maciço do seu inventário,
seguido de várias pequenas atualizações através da API, poderá ser o melhor método.
Assim, por que é a API de Conteúdo a escolha mais acertada?
Sem dúvida de que o último diapositivo nos deu uma noção.
Eis uma visão geral da diferença.
Os feeds dos dados dos produtos são úteis
para inventários pequenos e estáticos de produtos,
ou seja, inventários pequenos e alterados poucas vezes.
E uma vez que se trata de ficheiros .txt ou .csv,
o esforço de implementação é reduzido.
Já o Google Content API for Shopping
é melhor para inventários extensos e sempre em alteração,
embora a sua utilização exija algum esforço de utilização.
Uma das maiores vantagens da API de Conteúdo
é o facto de funcionar em tempo real.
A introdução de novos produtos é rapidíssima.
A introdução de produtos
demora apenas alguns segundos
e recebe imediatamente uma resposta da Google
a informá-lo se o produto foi introduzido.
Do mesmo modo, se está a atualizar o preço e a quantidade dos itens,
não existe um processamento extra.
Depois do carregamento de um item para o Google Merchant Center,
é necessário algum processamento para que este tenha a qualidade exigida
antes de o disponibilizarmos aos nossos utilizadores, não é?
Se já carregou um item e apenas
pretende atualizar o preço ou quantidade, a atualização é imediata.
O item entra no que chamamos de pipeline expresso.
Este pipeline expresso para alterações de preço e quantidade
é uma importante componente da API de Conteúdo.
Para mais, a API de Conteúdo é automatizada,
pelo que o seu feedback da API é apresentado exatamente no mesmo formato
do pedido enviado por si.
O feedback é apresentado ao nível do item,
pelo que recebe uma resposta para cada item específico
que tente introduzir, atualizar ou eliminar.
Como disse antes, as respostas são imediatas.
Assim que faz o pedido,
recebe uma resposta da Google a informá-lo se a atualização
foi efetuada com êxito,
ao contrário do feedback dos feeds, que é enviado por e-mail.
Este não passa de um resumo, em vez de ser uma resposta
ao nível do item de formato similar.
Vamos comparar e contrastar a implementação.
Os feeds de produtos funcionam com ficheiros .csv,
.txt., ou com ficheiros .xml,
se assim o pretender.
Contudo, não precisa de um programador para os feeds,
sobretudo a uma escala pequena.
Já a API de Conteúdo exige que tenha, no mínimo,
conhecimentos práticos de XML,
bem como algumas
capacidades de programação.
E à medida que atualizamos as especificações e alteramos
alguns aspetos da API, para melhorar a sua experiência
e para aperfeiçoar os dados que conseguimos fornecer
aos nossos utilizadores do Google Shopping, será necessário fazer a manutenção
dos itens que envia.
Deste modo, a API de Conteúdo apresenta funcionalidades extra
que os feeds simplesmente não têm.
A primeira, que já mencionei, permite-lhe gerir subcontas,
caso tenha vendedores subordinados
ou lojas inteiras sob a sua gestão.
Também pode gerir feeds de dados, caso queira
carregar todo o seu inventário através de um único feed de dados
e, em seguida, usar a API de Conteúdo para introduzir pequenas alterações.
Pode gerir esse feed de dados específico
através da API de Conteúdo.
Também de realçar, pode aceitar pedidos onde colocar novos itens
bem como para atualizar itens existentes e eliminar alguns itens,
tudo isto num extenso pedido de batch. Falarei mais sobre este assunto
na secção de implementação.
Como pode utilizar a API?
Como funciona a implementação?
Eis um XML.
É um pedido que contém as informações relativas ao item
que vai ser enviado para a Google.
Aqui temos um título,
temos algumas informações acima,
apenas detalhes necessários para que o pedido seja enviado.
Também há conteúdo sobre o item, preço, condição.
Todos estes atributos são importantes
quando um utilizador procura um item.
Agora, vamos falar um pouco sobre XML.
O XML é uma linguagem de marcação,
muito semelhante ao HTML.
É uma linguagem estruturada
utilizada para transportar dados que os computadores compreendam.
O último diapositivo era complicado,
difícil de compreender,
pois foi concebido
para ser processado por uma máquina,
não para ser lido por um ser humano.
Eis um exemplo de uma parte de um XML.
Estamos apenas a definir uma nota,
a dizer que é do Ali para mim.
O Ali definiu o assunto como XML e o corpo da mensagem é
"O XML é o miado do gato!"
É um conjunto de dados estruturais
que um computador pode compreender.
Depois de termos os dados estruturados
para um item específico, publicamo-lo.
Uma mensagem é um daqueles quatro verbos para a API
publicada para um link específico.
Você também está a publicar em formato autenticado,
pelo que precisa de um código de autorização, descrito na documentação.
Assim que for enviado para a Google,
enviamos-lhe uma resposta a informar do êxito da operação.
Só mais umas coisas...
Em cima, vemos um código HTTP, 201,
o que significa que foi efetuado com êxito.
No fim da resposta, repare que existe uma localização
para o item específico que introduziu.
Isso é importante.
Não se esqueça disto.
Essa localização é um URL único
para o produto introduzido por si.
Neste URL, temos a raiz,
content.googleapis.com/content/v1.
Temos a ID.
Vemos um caminho e uma projeção,
que são apenas detalhes para a API.
No fim do URL, temos algo muito importante:
a ID do produto.
A ID do produto é específica do produto
que acabou de introduzir.
Ao avançar, depois de ter introduzido o produto
no seu inventário, pode utilizar o link para voltar atrás
e atualizar ou eliminar o produto.
Com a resposta 201, quando fornece a localização,
também recebe uma resposta.
Como disse antes, as respostas que recebe da Google
estão no mesmo formato dos pedidos enviados.
Eis um exemplo de resposta.
Vemos a informação de sempre: o título, o conteúdo, a ID,
mas também temos elementos como a data de publicação e de edição.
São dados que a Google envia sobre quando o item foi carregado
e editado pela última vez, bem como sobre a data de envio
e de expiração.
A data de expiração predefinida é 30 dias.
Antes de passar para o essencial
da implementação, criámos uma
demonstração interativa on-line.
Se procurar o Google Content API for Shopping na Pesquisa do Google,
pode encontrar a demonstração.
A demonstração permite-lhe realizar todas as operações.
Permite-lhe introduzir novos itens, atualizar itens existentes,
eliminar itens, gerir subcontas...
Pode explorar todas as opções da API
através de uma interface on-line fácil de utilizar.
Quando envia os pedidos, recebe uma resposta,
como a que receberia com a API: a resposta do estado HTTP
e o conteúdo da mesma.
Recebe o conteúdo exato que receberia através da API.
Quando tiver acabado a demonstração, se quiser implementar,
temos quatro bibliotecas em código aberto para os nossos clientes
escritas em .net, Java, python e php.
Estas bibliotecas resumem algumas dificuldades,
como o link de ID, que tem segmentos
difíceis de memorizar e que não são totalmente necessários
para a implementação.
Está tudo resumido,
e estas bibliotecas para clientes são excelentes para fazer pedidos,
para se autenticar e para explorar todas as opções da API
através de linguagens que os seus programadores já conhecem.
Consulte o link no final do diapositivo
para saber mais acerca destas bibliotecas,
para as quais eu próprio e outros programadores,
como o Ali, aqui presente,
contribuímos muito e continuamente.
No geral, as bibliotecas são suportadas por vários engenheiros da Google,
mas como são de código aberto,
pode sempre ver o código fonte,
bem como atualizações.
Se quiser, até pode submeter atualizações.
Aliás, vi algumas pessoas na lista de convidados
que submeteram correções de erros
para algumas das bibliotecas.
Só para vos dar uma ideia.
Como já disse, uma das melhores funcionalidades extra da API de Conteúdo
é que pode enviar pedidos de batch.
Repare na imagem ao lado.
Está a agrupar produtos e operações numa única mensagem,
o que é fantástico.
Pode colocar vários produtos e operações num único pedido.
Assim, se, ao mesmo tempo,
quiser eliminar alguns itens e atualizar outros, pode fazê-lo.
Pode introduzir um novo item
ao mesmo tempo que altera o preço de outro
através de uma operação batch.
As operações batch são limitadas.
Cada pedido pode ter o máximo de 1 MB,
mas é possível comprimi-lo em gzip ou em qualquer outro formato
para reduzir o tamanho.
Recebe uma resposta como quando efetua uma introdução normal
ou como uma resposta de atualização,
a qual está no mesmo formato do pedido enviado,
com os erros e sucessos apresentados ao nível individual
de cada produto.
Um benefício disto é que pode enviar um pedido,
em vez de enviar cem pedidos por cem itens,
poupando no volume de pedidos.
Vamos ver a próxima funcionalidade de implementação da API de Conteúdo,
mas primeiro quero dar algumas informações
sobre a mesma.
Quando a adicionámos, tínhamos uma alteração pendente
à especificação do feed.
Muitos de vocês aqui já sabem disso.
A 22 de setembro, alterámos a especificação do feed
para permitir que os utilizadores tivessem uma melhor experiência
através do Google Shopping.
Assim, certos pedidos enviados através da API de Conteúdo
eram válidos antes de 22 de setembro,
mas tornar-se-iam inválidos após essa data.
Queríamos que fosse possível avisá-lo com antecedência.
Assim, pode anexar um sinalizador de aviso ao final de um URL
quando faz um pedido para efetuar uma introdução,
uma atualização, ou qualquer operação
que modifique o estado do seu inventário.
Quando adiciona o sinalizador
- repare que este está em negrito no final do link -
no final de um pedido,
a resposta incluirá o sucesso ou fracasso do mesmo,
bem como avisos sobre aspetos específicos
que poderão falhar.
No caso de recomendarmos um atributo,
mas sem o exigirmos,
é-lhe apresentado um aviso a mostrar essa recomendação.
Na mesma linha do sinalizador de aviso,
também temos um sinalizador de ***.
Este é uma sandbox.
Trata-se, literalmente, de um ***
que lhe permite enviar um pedido, como se fosse
atualizar os seus dados, ou modificá-los,
sem que seja preciso introduzir os dados,
nem modificar seja o que for.
Assim, recebe uma resposta igual à que receberia
caso tivesse enviado um pedido, com a diferença
de que não são efetuadas alterações.
É uma evolução relativamente à demonstração interativa on-line,
mas na mesma linha.
Permite-lhe testar uma implementação
antes que esta tenha algum efeito sobre os dados do produto
no Google Merchant Center.
Vamos falar de outra funcionalidade ótima das APIs em geral,
sobretudo para os comerciantes e revendedores.
Se tem um sistema empresarial de planeamento de recursos,
um sistema ERP, sempre que um produto
é adicionado, introduzido ou alterado,
pode reagir de forma programada a essas ações no seu sistema ERP
e, através do Google Content API for Shopping,
alterar o seu inventário de forma similar no Google Merchant Center.
Deste modo, pode manter o seu sistema de inventário atualizado
através do nosso sistema de inventário.
Espero que tenha gostado do que ouviu hoje.
Se estiver interessado em continuar,
temos uma comunidade on-line ativa.
É um Grupo do Google.
Se pesquisar por Google Content API for Shopping,
no Grupos do Google, encontrará o Grupo.
Aqui também tem um link.
Eu também leio o fórum
e muitos dos nossos engenheiros também o acompanham.
As respostas são sempre pesquisáveis,
pelo que se alguém antes de si já tiver colocado a mesma questão,
poderá pesquisar e encontrar a resposta
de modo a atualizar a sua implementação.
Se estiver interessado em apoio técnico mais pessoal,
contacte o gestor da sua conta.
Também temos outras opções,
bem como alguma documentação, que eu próprio mantenho atualizada,
para que estejam tão informados quanto possível,
que pode encontrar em
code.google.com/api/shopping/content.
Não precisa de memorizar este URL.
Se for ao Google e pesquisar por Google Content API for Shopping,
é o primeiro link,
o primeiro resultado.
Por fim, se quer receber comentários para além das Perguntas e Respostas,
junte-se a mim para uma hora no escritório, dentro de uma semana,
num Hangout do Google+ a 3 de novembro.
Também posso fornecer
mais informações no final.
E se quiser comentar diretamente este seminário na Web,
disponibilizamos um link.
Siga-o, goo.gl/7PjFA,
para poder comentar
o seminário na Web de hoje.
Se alguém tiver mais questões, pergunte à vontade.