Tip:
Highlight text to annotate it
X
DANNY HERMES: Muy bien.
Hola.
Bienvenido a este seminario web sobre cómo mantener
actualizados los datos de los productos.
Me llamo Danny Hermes
y trabajo en el área de Relaciones de programadores con el
equipo de Comercio aquí, en Google.
Nuestro trabajo consiste en divulgar algunas de nuestras API y
ofrecer ayuda e información, además de crear
seminarios web como este.
Hoy me acompañan Ali Afshar, Amanda Surya y Jasmine
[? Kahn ?]. Estarán disponibles en el chat para ayudarte con
cualquier pregunta que tengas.
Hay una opción para levantar la mano. Pero no la levantes,
haz la pregunta directamente y te contestarán
lo mejor que sepan.
Así que, empecemos.
Hoy esperamos contestar a algunas preguntas
bastante importantes sobre el API de contenido.
En primer lugar, ¿qué es el API de contenido?
En segundo lugar, ¿qué es la política de datos actualizados y cómo
afecta al API?
¿Por qué necesitas el API?
Compararemos el
API y los feeds de datos.
Luego hablaremos de la implementación.
¿Qué aplicaciones tiene el API?
Si durante la presentación tienes preguntas sobre alguna de las
diapositivas, escríbelas en el chat y
te responderemos lo mejor que sepamos.
Para empezar, ¿qué es el API de contenido para Shopping?
Para responder a esta pregunta, primero tenemos que hablar de
Shopping.
Los artículos que aparecen en Google Shopping primero se
han subido a Google Merchant Center.
Los datos del producto se almacenan en Merchant
Center y de ahí pasan a Google Shopping,
en el ordenador.
También pasan a Google Shopper, en dispositivos móviles, y a
otros canales, como la Red de afiliación de Google y
Commerce Search.
Pongamos, por ejemplo, que tienes tres cámaras digitales
y las quieres vender.
Las subes a Google Merchant Center y luego
alguien realiza una búsqueda
de cámaras digitales en Google.
Y aquí están, resaltadas en azul, las tres cámaras
que subiste.
Como he dicho, para que un artículo aparezca en Google
Shopping, hay que subirlo primero a Google
Merchant Center.
Hay dos formas de hacerlo:
mediante los feeds de producto de Google y mediante el API de contenido para Shopping,
que es lo que nos ocupa el seminario de hoy.
Entonces, ¿qué es el API de contenido de Shopping?
Volvamos a la pregunta que prometí responder.
Es un API que se basa en HTTP, en REST y en GData.
Y eso, ¿qué es?
Tienes una solicitud que incluye todos los datos del producto y aplicas
los métodos GET, POST, PUT o DELETE.
Son las cuatro acciones del API REST.
La envías a nuestro recurso alojado en
googleapis.com
y nosotros mostramos la respuesta XML.
Hablemos un poco sobre el API.
Un API es una forma de interactuar mediante un programa con, por ejemplo,
servidores de Google o con Google Merchant
Center, en este caso.
Es una forma para que dos programas
se comuniquen.
A diferencia de los feeds, un feed de datos es simplemente un archivo
que contiene toda la información sobre tus productos.
Es muy parecido a la solicitud que se envía
mediante el API de contenido, con la diferencia de que
es un archivo .txt sin formato o XML.
En estos archivos, se incluyen atributos y entidades que describen
los datos concretos del producto.
Y estos archivos, los .txt o los XML, se
suben directamente a Merchant Center.
Así pues, el API de contenido para Shopping permite a tus
programadores subir esos datos a todos los
sitios de compra de Google de forma automatizada.
Permite administrar subcuentas en caso de que
tengas un sitio de mercado y administres varios
vendedores o varias subtiendas.
Además, permite configurar feeds de datos.
Si quieres combinar el API de contenido y
el uso de feeds de datos, puedes administrar esos
feeds a través del API.
Una vez que hayas subido los datos,
verás los resultados y podrás configurar más ajustes mediante el panel de Google
Merchant Center.
En este panel se incluye información sobre los feeds
que estás utilizando, los productos que has subido,
la calidad de los datos y otras estadísticas de rendimiento.
Además, el API te permite realizar un seguimiento de los clics.
Así que, con una solicitud al enlace de esta diapositiva
(ahora no explicaré cómo funciona todo el proceso),
básicamente se especifica una fecha de inicio, otra
de finalización y un artículo determinado. Los resultados que recibes
corresponden al seguimiento de clics de ese periodo.
Esta es una mejora adicional que hemos incluido en el API.
Veamos ahora la política de actualización de datos.
Cuando alguien accede a la Búsqueda de Google y busca
un producto, si este aparece por 102 USD, como
ves aquí, el usuario espera poder comprar
el artículo por ese precio.
Si el precio base es diferente al
total, el usuario espera conocer esa discrepancia.
Querrá saber lo que acabará
pagando, ¿verdad?
Así que para Google Shopping, hay tres personas
que nos preocupan.
En primer lugar, los usuarios.
Queremos que tengan la mejor experiencia posible,
que encuentren lo que buscan,
y que obtengan información precisa de
esos productos.
En segundo lugar, nos preocupan los vendedores.
Nos preocupan las personas que venden productos porque
también queremos que tengan una experiencia positiva a la hora de ofrecer
sus productos a través de Google Shopping.
Y, en tercer lugar, nos preocupamos nosotros mismos.
Queremos contentar a todos.
Teniendo esto en cuenta, la política de actualización de datos de Google
dice que, "Cuando un usuario accede", bla, bla, bla.
No voy a leer todo el documento ahora.
Si quieres leer la política al completo, encontrarás un breve enlace
al final de esta diapositiva: goo.gl/C5P8X.
En ella se detalla la información relacionada con la actualización de los datos.
Pero recuerda que nuestra prioridad es el usuario,
luego tú como vendedor y, finalmente, nosotros.
¿Cómo afecta esto al API de contenido?
Por ejemplo, si tienes precios
y cantidades que cambian a menudo, deberías poder modificar
los artículos en Google Shopping para reflejar tales cambios.
Con los feeds, solo puedes realizar modificaciones un número
determinado de veces al día.
Y esto limita la frecuencia con la que puedes actualizar
los precios y las cantidades.
Con el API de contenido para Shopping, puedes
realizar y aplicar modificaciones en el preciso instante en
que los precios cambian.
Además, si tienes un inventario de artículos muy muy amplio,
mantener y subir el mismo feed de gran tamaño
todos los días puede resultar algo laborioso.
Así que quizás lo mejor sea subir un feed de inventario muy grande
y luego realizar pequeñas actualizaciones a través del API.
¿Por qué necesitas el API de contenido?
La última diapositiva nos ha dado una idea.
Aquí vemos una comparación bien clara.
Como ya he comentado antes, los feeds de datos de productos son adecuados para
inventarios estáticos y con pocos artículos.
Pequeños y que no cambien muy a menudo.
Y, puesto que se trata de archivos .txt o de valores separados por
comas, implementarlo no cuesta demasiado.
En cambio, el API de contenido para Shopping es adecuado para
inventarios grandes y que cambian con frecuencia.
Sin embargo, requiere la intervención de los programadores.
Una de las ventajas del API de contenido
es que se utiliza en tiempo real.
Es muy rápido para introducir productos nuevos.
Tardas segundos
en hacerlo.
Y recibes una respuesta inmediata de Google
indicando si el producto se ha introducido o no.
Si modificas precios o cantidades
de artículos, no tienes que realizar procesos adicionales.
Así que, después de subir un artículo a Merchant Center,
llevamos a cabo algunos procesos para asegurarnos de que ofreceremos calidad
a nuestros usuarios.
Si ya has subido un artículo y solo quieres
modificar un precio o una cantidad, el cambio se aplica al instante.
Es lo que llamamos "la vía directa".
Es una de las grandes ventajas del API
de contenido para cambios en los precios y en las cantidades.
Además, el API de contenido está automatizado.
Así que, aquí, la información del API está en el mismo formato
que la solicitud que has enviado,
artículo por artículo. Recibes
una respuesta para cada uno de los artículos
que quieres introducir, modificar o eliminar.
Y, tal y como he dicho antes, las respuestas son inmediatas.
Así que en el instante en el que realizas la solicitud, recibes una
respuesta de Google que te indica si el cambio
que has introducido se ha aplicado correctamente o no.
En cambio, con los feeds, la información se incluye en un correo electrónico y
la respuesta es simplemente un resumen en lugar de una
respuesta artículo por artículo.
Comparemos ahora la implementación.
Como he dicho antes, con los feeds de producto, basta con usar archivos de valores
separados por comas, archivos .txt o incluso XML,
si quieres.
Pero no necesitas a un programador,
sobre todo si es a pequeña escala.
Para el API de contenido necesitas unos
conocimientos mínimos para trabajar con XML.
También es necesario saber algo de
programación.
Y, por supuesto, a medida que modificamos las especificaciones e introducimos algunos
cambios en el API para mejorar tu experiencia
y los datos que se muestran a nuestros
usuarios de Shopping, habrá que realizar algún tipo de mantenimiento
a la información que envíes.
En este sentido, el API de contenido incluye unas funciones adicionales
muy útiles que los feeds no incluyen. La
primera, tal y como he mencionado antes, es que puedes administrar
las subcuentas en caso de que tengas vendedores a tu cargo
o de que lleves alguna tienda.
También puedes administrar feeds de datos en caso de que quieras
subir todo tu inventario en un único feed de datos y luego
usar el API de contenido para realizar pequeños cambios.
Puedes administrar ese feed de datos concreto
a través del API de contenido.
Otra gran ventaja es que puedes utilizar las solicitudes para introducir
artículos nuevos o para modificar o eliminar otros,
todo desde una única solicitud por lotes. Ampliaré esta
información en el apartado sobre implementación.
¿Cómo se utiliza?
¿Cómo funciona realmente la implementación?
Aquí tenemos código XML.
Es una solicitud con la información del
artículo que quieres enviar a Google.
Aquí tenemos un título, encima hay más cosas
necesarias para
procesar la solicitud.
Hay contenido sobre el artículo, el precio y el estado.
Todos esos atributos que son importantes cuando un usuario
busca el artículo en cuestión.
Hablemos un poco sobre XML.
XML es un lenguaje de marcas.
Es muy parecido al HTML.
Es lenguaje estructurado.
Sirve para contener datos que una máquina pueda entender.
Esa última diapositiva era un poco complicada
de leer.
Eso es porque se ha creado para que la entienda
una máquina
y no una persona.
Este es un ejemplo de XML.
Es la definición de un mensaje:
se indica que es un mensaje mío para Ali.
El asunto es "XML" y luego viene el cuerpo del mensaje:
"XML is the cat's meow!"
Se trata, simplemente, de datos estructurados que puede entender
un ordenador.
Una vez tengamos los datos estructurados para un
determinado artículo, se aplica el método POST.
POST es una de esas cuatro acciones del API.
En este caso la acción se aplica a un enlace concreto.
Además, se hace de forma autentificada, por lo que necesitas un
token de autorización, el cual se describe en la documentación.
Y, una vez se envíe a Google, recibirás una respuesta indicando que se ha procesado
correctamente.
Un par de cosas:
En la parte superior, hay un código HTTP, el 201, que
significa "procesado correctamente".
En la parte inferior, también verás una ubicación del
artículo que has introducido.
Eso es importante.
Toma nota de ello.
La ubicación es una URL exclusiva del producto
que has introducido.
Esta URL contiene una raíz, content.googleap
is.com/content/v1,
un ID,
una ruta y una proyección que, de nuevo,
es simplemente para procesos del API.
Y luego, al final, hay algo muy importante:
el ID de producto.
Este ID es exclusivo para el artículo que
has introducido.
Una vez que hayas introducido el producto
en el inventario, puedes utilizar el enlace para regresar y
actualizar y eliminar el producto.
Así pues, con esa respuesta 201, también se recibe
una respuesta cuando se indica la ubicación.
Como ya he dicho antes, las respuestas de Google tienen
el mismo formato que la solicitud. Veamos
una respuesta de ejemplo.
Incluye muchos elementos iguales: el título, el contenido y el ID.
Pero también contiene datos de publicación () y de modificación ().
Es información de Google que indica cuándo has subido
el artículo, cuándo lo has modificado por última vez y cuándo
nos lo has enviado o cuándo caduca.
De forma predeterminada, son 30 días.
Así que antes de adentrarte en
la implementación, hemos creado una
demostración interactiva online.
La encontrarás si buscas "Search for Content API for
Shopping" en Google.
La demostración te permite realizar todas las operaciones.
Así que podrás introducir artículos nuevos, actualizar
y eliminar otros o administrar subcuentas.
Todo aquello que puedes hacer con el API desde una
interfaz online fácil de usar.
Y cuando estés realizando estas solicitudes recibirás
la respuesta que hubieras obtenido, tanto el estado HTTP
como el contenido de esa respuesta.
Exactamente el mismo contenido que obtendrías en el API.
Cuando lo hayas hecho y quieras
implementarlo, tenemos cuatro bibliotecas cliente de código abierto
en .net, Java, Python y en PHP.
Estas bibliotecas eliminan algunas de las dificultades como, por ejemplo,
ese enlace de ID, donde hay ciertas partes que no son
fáciles de recordar y que tampoco son necesarias
para la implementación.
Todo eso te lo ahorras. Las bibliotecas cliente
son ideales para realizar solicitudes, autenticarte y
hacer todo lo que se puede hacer con el API
mediante lenguajes con los que tus programadores ya estén familiarizados.
En la parte inferior de la diapositiva hay un enlace
por si te interesa obtener más información sobre estas bibliotecas cliente.
Tanto yo como otros programadores, como Ali,
que nos acompaña hoy, hemos colaborado activamente en estas bibliotecas
y seguimos haciéndolo.
La mayoría están respaldadas por muchos ingenieros de Google,
pero son de código abierto, por lo que siempre
puedes acceder al código fuente.
Siempre puedes ver las actualizaciones.
Y, si quieres, puedes enviar cambios.
He revisado la lista de invitados y veo que hay
quien ha enviado correcciones de errores para
algunas de estas bibliotecas.
Por si alguien se anima.
Como ya he comentado antes, una de las funciones adicionales muy útiles del
API de contenido es que puedes enviar solicitudes por lotes.
Observa esta imagen en el lateral.
Agrupas productos y operaciones en una
solicitud POST. Eso es fantástico.
Puedes incluir varios productos y varias operaciones en una
misma solicitud. Así que, si quieres, puedes eliminar unos artículos y,
al mismo tiempo, modificar otros.
Si quieres, a la vez, puedes insertar un artículo nuevo
y cambiar el precio de otro
mediante una operación por lotes.
Ten en cuenta que las operaciones por lotes están limitadas.
Las solicitudes no pueden superar 1 MB.
Pero puedes comprimirlas en un archivo .gzip, .zip o en cualquier otro formato
para reducir su tamaño.
Recibirás una respuesta, como en una inserción normal o
una respuesta de modificación.
Tendrá el mismo formato que el formato de la solicitud que hayas enviado.
Recibirás respuestas de proceso correcto o con error para cada
producto.
La ventaja de esto es que en lugar de enviar 100
solicitudes para 100 artículos, basta con enviar una.
Así disminuyes el volumen de solicitudes.
Me gustaría contextualizar un poco la extraordinaria función de
implementación del API de contenido
que viene a continuación.
Cuando se añadió, estábamos a la espera de un cambio en la
especificación del feed.
Probablemente sepas de qué estoy hablando.
El 22 de septiembre cambiamos la especificación del feed para
ofrecer una experiencia más positiva para los usuarios
a través de Shopping.
Y algunas de las cosas que se enviaban a través del
API de contenido eran válidas antes del 22 de septiembre, pero dejarían de serlo
después de ese día.
Así que queríamos avisarte con antelación de alguna forma.
La marca de advertencia es un elemento sencillo que puedes añadir
al final de una URL a la que envíes la solicitud para realizar
una inserción, una modificación o una operación para cambiar un estado.
Cualquier operación que modifique el inventario.
Y cuando se inserta esta marca, aquí
aparece en negrita al final de este enlace...
Pues cuando se incluye esta marca al final de la solicitud,
la respuesta no solo indica si la operación es correcta o si ha fallado, sino
que también incluye advertencias sobre
elementos que pueden fallar.
O si queremos recomendar un atributo sin
que tenga que ser obligatorio, se muestra una advertencia para indicar
tal recomendación.
En la misma línea que la marca de advertencia, también tenemos
una marca de prueba.
Esta marca de prueba es un espacio aislado.
Es, literalmente, una prueba.
Permite enviar una solicitud como si fueras a
actualizar los datos, a modificarlos de alguna forma, sin tener que
insertar información.
En realidad, no tienes que cambiar nada.
Por lo tanto, recibirás la misma respuesta que
si hubieras enviado una solicitud real, con la diferencia de que no
habrá cambios.
Es un paso superior a la demostración interactiva online, pero
es parecido.
Te permite probar la implementación antes de
que los cambios se apliquen a los datos del producto de
Merchant Center.
Es una fantástica función de las API en general,
y en particular para nuestros vendedores.
Si trabajas con un sistema de planificación de recursos para empresas,
un sistema ERP, cada vez que se añade,
se inserta o se cambia un producto, puedes
responder a esas acciones en el sistema ERP mediante un programa e
invocar el API de contenido para Shopping para realizar un cambio
similar en el inventario de Google Merchant Center.
De esa forma, tienes el sistema de inventario sincronizado con
el nuestro.
Espero que te haya interesado mi explicación de hoy.
Para más información, tenemos
una activa comunidad online.
Es un grupo de Google.
Busca "Content API for Shopping" en
Grupos de Google y lo encontrarás.
Este es el enlace directo.
Yo mismo leo el foro, igual que
muchos de nuestros ingenieros.
Se pueden buscar las respuestas, por lo que si alguien
ya ha hecho la pregunta que quieres hacer,
podrás realizar una búsqueda y encontrar la respuesta
para aplicarla a la implementación.
Si quieres recibir asistencia más específica,
ponte en contacto con tu administrador de cuentas.
Disponemos de otras opciones.
Y, por último, contamos con documentación que
yo mismo voy actualizando para
que estés lo más informado posible. La encontrarás en:
code.google.com/ api/shopping/content.
No hace falta que memorices esta dirección.
Si vas a Google y buscas "Content API for Shopping",
es el primer enlace que aparece
en los resultados.
Si quieres obtener más información aparte de la sesión de preguntas y respuestas,
en una semana, el 3 de noviembre,
montaré una quedada en Google+ durante horas de oficina.
Si quieres, puedo darte más información al
terminar.
Si te apetece enviar tus comentarios sobre este
seminario web,
hazlo a través de este breve enlace: goo.gl/7PjFA.
Podrás aportar tu opinión sobre la
presentación de hoy.
Si tienes alguna otra pregunta, no dudes en hacerla.