La integración XML de VTEX genera un archivo con los productos de una colección de la tienda, que se envía a Google Merchant Center para anunciar en Google Shopping. El camino funciona, pero la propia VTEX recomienda el conector nativo de Google Shopping como opción estándar y desaconseja usar el XML y el conector al mismo tiempo.
Quien trabaja con ese XML casi siempre llegó por uno de tres caminos: productos rechazados por precio o disponibilidad, un catálogo demasiado grande para revisarlo a mano, o la decisión de cambiar de herramienta. La pregunta detrás de los tres es la misma: de dónde lee Merchant Center el dato, y con cuánto retraso.
¿Qué es la integración XML de VTEX?
El XML se configura en el Admin, en Configuración de la tienda, Canales, Integración XML, con el botón Nuevo XML. Para Google Shopping, VTEX indica elegir el tipo XML libre (estándar), apuntar a una colección de productos y marcar la opción de mostrar el producto con los datos del SKU estándar. Al guardar, el enlace del XML se genera automáticamente.
Quien administra la tienda controla bastantes aspectos: qué colección entra, la moneda, el formato del precio, si aparecen los SKU no disponibles y el nombre de cada etiqueta que la base de datos de VTEX va a completar. La tienda arma la estructura; Google lee lo que haya ahí.
La página de VTEX sobre el XML de Google Shopping trae dos avisos: describe un modelo de especificaciones de Google de 2013, que Google puede haber cambiado desde entonces, y anuncia una integración más nueva, mediante API.
¿Qué suele salir mal en el XML?
Para cada problema de la lista, un punto para revisar antes de tocar el archivo:
- Precio y disponibilidad desincronizados. La especificación de datos de producto de Google pide que el precio y la disponibilidad sean iguales a los de la página de destino y del proceso de compra. En el XML, un cambio tarda en promedio dos horas en aparecer, según VTEX, y Merchant Center descarga el archivo cada 24 horas por defecto. Qué revisar: la programación de lectura del archivo, que se puede ajustar, y las promociones más cortas que ese intervalo.
- Artículos que desaparecen del archivo. Con la opción de mostrar SKU no disponibles desmarcada, los productos agotados quedan fuera del XML, y los productos inactivos nunca entran. Qué revisar: esa opción en el XML y el estado del producto en la tienda.
- Ropa y accesorios. Google pide género y grupo de edad para esos productos, y VTEX indica resolverlo creando especificaciones de producto. Qué revisar: si la categoría tiene esas especificaciones completas.
- Formato del precio. VTEX mantiene publicada una página de problema conocido sobre el precio con coma en el XML. Qué revisar: cómo escribe el precio tu archivo.
Cuando el artículo ya fue rechazado, el post sobre producto rechazado en Merchant Center muestra cómo abordar las causas que más se repiten.
XML o conector: ¿qué recomienda VTEX?
En la guía de integración con Google Shopping, VTEX dice que su propio conector debe ser la opción estándar, por eficiencia y seguridad. El conector se activa en el módulo Marketplace con el Merchant Id de la cuenta y una política comercial, que define el surtido y los valores enviados.
Lado a lado, con los plazos que publican VTEX y Google:
- XML de la tienda. Se configura en Integración XML. Un cambio tarda en promedio dos horas en llegar al archivo, y Merchant Center lee el archivo cada 24 horas por defecto.
- Conector de VTEX. Se activa en el módulo Marketplace. Según la documentación de envío de productos, un cambio ya procesado puede tardar hasta 30 minutos en llegar al feed, y el conector reenvía los productos cada 29 días, antes del plazo de 30 días en que Google hace expirar el artículo que no se actualiza.
- Gestor de feed. Queda fuera de la tienda, y el plazo depende de cómo publica la herramienta.
VTEX desaconseja usar el XML de Google Shopping y el conector al mismo tiempo, porque eso genera conflictos y discrepancias en la información. En la migración, planifica el cambio para que el mismo artículo no tenga los dos orígenes activos a la vez.
Cuándo mantener, cambiar o usar un gestor de feed
Mantener el XML tiene sentido mientras el catálogo es pequeño, Google es el único destino y el precio y el stock cambian lo bastante despacio como para caber en el intervalo entre lecturas. Cambiar al conector es el paso natural cuando las promociones y el stock cambian el mismo día, y es lo que VTEX recomienda por defecto.
El XML y el conector llevan a Google lo que está en la tienda. Un gestor de feed, o un PIM con feeds, entra cuando el problema está antes de la tienda:
- El dato no nace completo en VTEX. Ficha técnica que llega en una hoja de cálculo, foto en una carpeta, atributo que solo tiene el fabricante.
- Más de un canal lee el mismo catálogo. Google, Meta, comparadores de precios y marketplaces piden campos y formatos distintos.
- El feed necesita reglas. Enviar solo una marca, una categoría o un rango de precio a un canal.
Si un gestor de feed empieza a enviar el artículo a Merchant Center, saca ese artículo del XML y del conector. Google no separa los productos por fuente de datos: con el mismo ID y la misma etiqueta de feed, un envío reemplaza al otro, y cuesta saber de qué origen viene el dato que está publicado. Los campos que más pesan en ese envío están en el post sobre feed de productos para Google.
Dónde entra AdCore Turbo
AdCore Turbo reúne PIM, DAM y feeds por canal. Trabaja un paso antes, en el registro, y no modifica el XML de VTEX. Para los artículos que publica en Google, pasa a ser su origen en Merchant Center, en lugar del XML o del conector. El registro queda en el PIM, y de ahí salen la publicación en Google Merchant Center mediante la Merchant API y la publicación en el catálogo de la tienda VTEX. El catálogo entra al PIM por archivo CSV.
En el camino de los feeds, Feed Health señala en el SKU el campo obligatorio que falta, como título, descripción, enlace, imagen o precio, y da una puntuación de 0 a 100 por feed. La corrección se hace una sola vez, en el registro, y cada publicación siguiente, en la tienda o en un canal, ya sale con el dato corregido. Las reglas de gestión de feeds eligen qué productos van a cada canal, por marca, categoría o precio.
AdCore Turbo ayuda cuando el problema es un campo faltante o un registro disperso. La diferencia de precio por una promoción es otro tema: el precio que va a Google es el del registro, así que una promoción creada solo en la tienda también tiene que llegar al registro antes de la próxima publicación. Qué dejar listo antes de publicar en VTEX está en el post sobre registro de productos en VTEX.