Shopify supera las 12.500 tiendas activas en Francia a finales de 2025 según los datos de BuiltWith, y PrestaShop sigue sólidamente instalado en torno a las 22.000 tiendas activas en el mismo perímetro — dos ecosistemas masivos con perfiles de usuario muy distintos. En Google Shopping, la batalla técnica se juega en tres niveles: calidad del feed de productos, frescura de la sincronización con Merchant Center, limpieza del conversion tracking. Y es ahí donde los dos CMS divergen radicalmente.
La regla que repetimos en cada auditoría de Shopping: feed sano = ROAS sano. Sin atajos por la estrategia de puja, sin magia vía Performance Max — la calidad del feed amplifica o limita todo lo que hay aguas abajo. Esta guía zanja los arbitrajes Shopify vs PrestaShop para Google Ads en 2026: setup de Merchant Center, plugins disponibles, conversion tracking, Performance Max, trampas observadas en ambos stacks. Para una estrategia global de Shopping, lea nuestra guía de setup y optimización de Google Shopping y nuestro playbook e-commerce 2026 de Google Ads en paralelo.
Shopify vs PrestaShop: cuota de mercado y perfiles de usuario
Shopify es una plataforma SaaS hospedada en modo tenant, facturada de €27 a €384 por mes según el plan, operada por Shopify Inc. desde Ottawa (vea los precios oficiales de Shopify). PrestaShop es un CMS open-source autoalojado, gratuito de descargar, pero que exige hosting, mantenimiento técnico y módulos de pago para alcanzar la paridad funcional de un Shopify estándar. Ambos concentran el grueso del mercado DTC en Francia fuera de WooCommerce.
El perfil de usuario diverge marcadamente. Shopify atrae a marcas DTC que quieren un time-to-launch corto, operaciones sin deuda técnica, integraciones de marketing listas para usar (Klaviyo, Meta, canales Google, Pinterest, TikTok), y que aceptan un coste mensual recurrente más una comisión sobre transacción (0% al 2% según el plan, salvo Shopify Payments). PrestaShop atrae a comerciantes con catálogos complejos, multi-marca, multi-idioma, B2B con personalización, o simplemente marcas que prefieren la autonomía técnica y costes marginales de escala más bajos — sin comisión sobre transacción, sin tope de ancho de banda.
Tres puntos pesan especialmente en Google Ads. El canal Google nativo de Shopify automatiza el 80% del setup de Merchant Center: feed generado automáticamente, sync de 15 a 60 min, Enhanced Conversions activable en un clic. En el lado Presta, esas mismas funciones requieren bien un módulo oficial (€200 a €250), bien tiempo de configuración técnica. La frescura de sincronización del feed es el segundo punto crítico: un feed actualizado cada 24h en Presta genera desaprobaciones "Item availability mismatch" en cascada en cuanto el stock fluctúa rápido (promo flash, rotura de stock). En Shopify, la sync de 15 a 60 min limita drásticamente este riesgo. La tercera brecha es la flexibilidad de catálogo B2B: si gestiona precios por grupo de cliente, atributos de negocio personalizados, multi-idioma estricto, PrestaShop sigue siendo estructuralmente más sólido.
Para los arbitrajes de asignación Shopping vs Search, vea también nuestra guía de asignación Shopping vs Search.
Setup de Merchant Center: diferencias plugin vs nativo
El setup de Google Merchant Center es el paso que decide si lanza Shopping en 7 días o en 6 semanas. En Shopify, la operación es casi trivial vía el canal nativo. En PrestaShop, exige una elección de stack de módulos y una configuración manual más larga pero más controlada.
Shopify: la vía nativa por el canal Google & YouTube
El canal Google & YouTube de Shopify es gratuito e instalable desde el gestor de canales de venta en 2 clics. Una vez activado, conecta automáticamente su tienda con Google Merchant Center vía OAuth, genera un feed de productos conforme a las especificaciones de Google (title, description, image, price, GTIN, brand, category, availability, custom_label si está rellenado), y lo sincroniza cada 15 a 60 min según volumen. La documentación de Merchant Center detalla la lista de atributos soportados.
Tres cosas que el canal no gestiona y que tendrá que gestionar a mano. Primero, la verificación de dominio: Shopify conecta el dominio Shopify (mitienda.myshopify.com) pero si sirve bajo mitienda.com, hay que añadir manualmente el meta tag de verificación en theme.liquid o vía DNS TXT. Segundo, los mappings de categoría a 5 niveles: el canal propone una categoría por defecto basada en el product type de Shopify, a menudo demasiado genérica para nichos (Apparel & Accessories > Clothing en lugar de Apparel & Accessories > Clothing > Activewear > Yoga Pants). Vaya a Google Merchant > Productos > todas las fichas de producto y refine manualmente sobre los 50 mejores SKUs por facturación: ganancia significativa en bid relevance. Tercero, los custom_label: no se definen de forma nativa en Shopify, hay que usar un metafield, o pasar por una app de terceros (Shoppingfeed, Feed for Google Shopping, DataFeedWatch).
PrestaShop: módulo oficial o XML personalizado
En PrestaShop, tres vías a elegir según presupuesto y complejidad de catálogo. El módulo oficial "Google Shopping & Ads" en la PrestaShop addons store sigue siendo la solución más directa para un catálogo estándar: €200 a €250 una vez, mappings completos de atributos (incluidos custom_label_0 a 4, clase de eficiencia energética, identifier_exists), generación automática de XML, sync configurable. La vía XML personalizado consiste en servir un archivo XML/CSV vía un endpoint HTTPS en su servidor PrestaShop, recrawleado por Google Merchant Center a la frecuencia configurable (12 a 24h estándar). Exige de 4 a 12h de dev para un desarrollador PrestaShop con experiencia, gratuito en runtime pero caro en setup. La vía Content API consiste en enviar el feed vía la Google Merchant API directamente desde PrestaShop, lo que permite una sync casi en tiempo real — pero exige desarrollo a medida o un módulo premium dedicado.
Nuestra recomendación 2026 por tamaño de catálogo: por debajo de 500 SKUs, módulo oficial basta. Entre 500 y 5.000 SKUs, módulo oficial + Content API. Más allá de 5.000 SKUs, o con multi-idioma/multi-país, prevea un presupuesto de módulo premium dedicado (Shoppingfeed, ShoppingFlux, Lengow) de €80 a €400 por mes.
En las cuentas PrestaShop referenciadas, alrededor de un tercio muestra una tasa de productos desaprobados superior al 8% en Merchant Center por desfase de precio/stock entre tienda y feed. El mecanismo: el feed XML se genera una vez al día, Google Merchant lo crawlea 12h después, así que el desfase precio/stock del lado feed puede alcanzar de 24 a 36h. Durante promos flash o periodos de stock fluctuante, está garantizado que algunos productos se sirvan a un precio obsoleto, y Google los desaprueba en cascada. Solución: forzar la regeneración del feed cada 1 a 4h vía cron, o activar Content API. Solo este cambio sube la tasa de aprobación entre 8 y 12 puntos de media.
Feed de productos: calidad, frecuencia, custom_label, GTIN
La calidad del feed es el árbitro principal de su ROAS de Shopping, por delante de la estrategia de puja e incluso por delante de la estructura de campañas. Un feed limpio aporta entre un 25 y un 45% de ROAS adicional a igualdad de presupuesto frente a un feed mínimo — observado de forma continua en los benchmarks públicos. Cinco dimensiones críticas a dominar, idénticas en Shopify y PrestaShop, pero con limitaciones operativas distintas según el CMS.
Title: los primeros 35 caracteres lo deciden todo
Google trunca a menudo el title a 35-45 caracteres según el placement (carrusel Shopping móvil, Free Listings, panel de shopping del navegador Edge). Formato óptimo: Marca + Modelo + Atributo Clave en los primeros 35 caracteres. Ejemplo: "Sennheiser HD 660S2 Hi-Fi Wired Audio Headphones" — primeros 35 = "Sennheiser HD 660S2 Hi-Fi Wired Au". En las auditorías que realizamos, los títulos con la marca en los primeros 35 caracteres muestran un CTR entre un 18 y un 28% superior al de títulos genéricos como "Auriculares premium hi-fi de estudio cableados negros".
En Shopify, el título de producto es la única palanca fácilmente modificable (Editar > Título). En PrestaShop, puede modificar el name de producto (que también sirve como título de la página web — riesgo SEO), o usar un atributo de feed dedicado feed_title mapeado vía el módulo oficial o un módulo a medida. La segunda vía preserva la libertad del nombre de producto en el lado tienda y optimiza el title del feed en el lado Merchant.
GTIN, brand, mpn: la santa trinidad de la identificación
Google ha endurecido sus exigencias de GTIN desde 2024 sobre las marcas reconocidas: un producto sin GTIN válido en Apple, Sennheiser, Nike, etc. pierde entre un 25 y un 40% de impresiones en queries long-tail de marca. Si distribuye estas marcas, el GTIN es obligatorio. Para las marcas propias (su marca DTC sin GTIN oficial), añada identifier_exists = FALSE al feed y rellene brand + mpn — es la única combinación aceptada por Google para no desaprobar los SKUs.
En Shopify, el campo GTIN es nativo (Variant > Barcode). En PrestaShop, el campo EAN13 también es nativo pero hay que verificar que el módulo de feed mapee bien ean13 → gtin (a menudo sí, a veces no según el módulo). El campo brand es nativo en ambos CMS. El campo mpn (Manufacturer Part Number) es nativo en PrestaShop (product.reference), en Shopify hay que pasar por un metafield o una app de terceros — es una de las brechas prácticas en las que Presta resulta más completo de salida.
Custom_label: la segmentación por margen que lo cambia todo
Los 5 custom_labels (0 a 4) están infrautilizados en el 80% de las cuentas referenciadas, cuando son los que deciden la rentabilidad de Shopping. La estrategia estándar que aplicamos desde hace años: custom_label_0 = nivel de margen (alto/medio/bajo), custom_label_1 = estacionalidad (peak/normal/off-peak), custom_label_2 = ROAS histórico (alto/medio/bajo), custom_label_3 = booleano best-seller, custom_label_4 = libre (según vertical: nueva colección, liquidación, exclusivo online).
Esta segmentación condiciona luego la estructura de las campañas Shopping: campaña Premium (custom_label_0 = margen alto, target ROAS alto), campaña Estándar (custom_label_0 = margen medio, target ROAS medio), campaña Volumen (custom_label_0 = margen bajo, target ROAS bajo pero volumen escalable). Misma lógica trasladada a Performance Max vía asset groups segmentados.
En Shopify, definir custom_labels se hace vía metafields (Configuración > Custom data > Productos > añadir definición de metafield custom.label_0) y luego se exponen vía app de terceros al feed. En PrestaShop, el módulo oficial Google Shopping permite mapear directamente cualquier feature de producto o atributo personalizado a custom_label_0 a 4 — más directo y sin dependencia de una app de terceros.
Conversion tracking: Enhanced Conversions y eventos e-com
El tracking es el segundo pilar tras el feed. Smart Bidding (Target ROAS, Target CPA, Maximize Conversion Value) optimiza hacia la señal que recibe. Si una parte significativa de sus conversiones se trackea mal, el algoritmo optimiza hacia una señal truncada y rinde entre un 16 y un 26% por debajo de su potencial según vertical. Es el bug número uno que vemos en auditorías. Para la estrategia global de tracking, vea nuestra guía de conversion tracking en Google Ads.
Shopify: Enhanced Conversions con un solo toggle
El canal Google de Shopify envía automáticamente los parámetros de Enhanced Conversions en cada conversión enviada a Google Ads, siempre que se activen tres cosas. Primero, en Google Ads, active Enhanced Conversions for Web sobre la conversión principal (Herramientas > Conversiones > seleccionar > activar Enhanced Conversions). Segundo, en Shopify, autorice el customer data sharing (Configuración > Customer privacy > marketing). Tercero, verifique que el píxel de Google Ads esté correctamente inyectado vía el canal y no duplicado vía una app de terceros (en otro caso, doble conteo de conversiones, atribución distorsionada).
Los eventos estándar de e-commerce también están gestionados de forma nativa: view_item, add_to_cart, begin_checkout, purchase. Estos eventos alimentan el remarketing dinámico y las audiencias de GA4 sin configuración adicional. En auditorías Shopify, el bug más frecuente no es la falta de tracking sino un duplicado: una cuenta que tiene canal Google + GTM personalizado + una app de analítica de terceros, los tres enviando el píxel de Google Ads, multiplicando las conversiones por 2 a 3. Solución: un único punto de inyección.
PrestaShop: GTM server-side o módulo dedicado
En PrestaShop, el tracking exige una elección de stack. Vía 1: módulo dedicado tipo "Google Tag Manager" o "Google Ads Conversion Tracking" en la addons store, que inyecta el píxel y gestiona los eventos e-com. Coste de €80 a €200 una vez, operación llave en mano, pero Enhanced Conversions a menudo como opción de pago adicional. Vía 2: GTM server-side (recomendada para cuentas maduras) — instalar GTM en el lado cliente y luego enviar a un contenedor server-side hospedado en Cloud Run o App Engine, que hashea los datos de cliente (email, teléfono, nombre/apellido) antes de enviarlos a Google Ads. Es la vía más robusta para la calidad de señal post-iOS 14 y post-eliminación de cookies third-party.
La diferencia práctica entre ambas vías: el módulo dedicado se despliega en 2-4h, GTM server-side en 1 a 3 días según experiencia de dev. En cuentas Presta con alto volumen de Shopping (más de €30,000 al mes), GTM server-side se rentabiliza en pocas semanas vía la calidad de señal de Smart Bidding.
Performance Max y asset groups: integración con el CMS
Performance Max se ha convertido en el formato dominante en el lado Google Ads desde 2023, con una cuota de gasto en e-commerce que supera el 55% según las cuentas observadas en los benchmarks públicos de Google Ads 2025-2026. El formato explota directamente el feed de Merchant Center para los inventory ads (equivalente a Shopping integrado en PMax) y se complementa con asset groups para los placements de Display, YouTube, Discover, Gmail.
La integración con el CMS pesa en dos dimensiones: la calidad de las imágenes del feed (tamaño, fondo, formato) que alimentan los inventory ads, y la facilidad de crear/mantener los asset groups complementarios.
Asset groups segmentados por margen
El error clásico en PMax e-commerce es crear un único asset group con todo el catálogo y un set de imágenes genérico. Resultado: el algoritmo distribuye el presupuesto de manera uniforme, los SKUs de bajo margen captan tanto gasto como los de alto margen, el ROAS real sobre margen se hunde.
La estructura que recomendamos en 2026: un asset group por nivel de margen (custom_label_0 = alto/medio/bajo). Cada asset group tiene su propio target ROAS alineado con el margen del producto (p. ej., target ROAS 6 en alto margen, target ROAS 3 en bajo margen), sus propias hero images de categoría, sus propios títulos y descripciones adaptados a la propuesta de valor. Esta segmentación supera a un asset group monolítico entre un 22 y un 38% en ROAS sobre margen agregado observado en los benchmarks agregados de Google Ads.
En Shopify, la creación de asset groups se hace directamente en Google Ads (PMax > Asset groups > Nuevo). En PrestaShop, igual. La diferencia no está en la herramienta sino en la calidad de las imágenes fuente: Shopify estandariza mejor el encuadre y la resolución, PrestaShop deja pasar imágenes 400x400 sin fondo blanco que lastran los placements de Display. Auditoría obligatoria de los 50 SKUs principales en facturación antes del lanzamiento de PMax para armonizar. Para la estrategia completa de PMax, vea nuestra guía completa de Performance Max 2026.
La diferencia de ROAS observada entre una cuenta Shopify con canal nativo correctamente activado y una cuenta PrestaShop con feed XML 24h no mantenido se cuantifica entre un 18 y un 35% a igualdad de vertical y de presupuesto. No es culpa del CMS — es culpa del proceso. Un PrestaShop con Content API + módulo premium + GTM server-side rinde tanto como un Shopify, a veces más. A la inversa, un Shopify con apps de tracking duplicadas y un canal mal configurado rinde por debajo de un PrestaShop bien mantenido. El CMS no hace el ROAS — lo hacen las operaciones de feed y de tracking.
Comparativa de trampas y errores típicos
Cada CMS tiene sus trampas recurrentes. Conocer las 6 más frecuentes evita perder de 4 a 8 semanas diagnosticando un ROAS bajo.
Lado Shopify: 3 trampas recurrentes
Trampa 1: doble píxel. Una tienda Shopify activada en paralelo con canal Google + una app de tracking de terceros (Triple Whale, Northbeam, Aftership Marketing) que también envía el píxel de Google Ads en segundo plano. Resultado: las conversiones se cuentan dos veces, el ROAS aparente se multiplica por 1,8 a 2,2, Smart Bidding optimiza sobre una señal inflada, el ROAS real se hunde en cuanto se corta una de las fuentes. Solución: un único punto de inyección del píxel de Google Ads, idealmente el canal nativo.
Trampa 2: product type demasiado genérico. El product_type de Shopify se mapea por defecto a la categoría Google. Si sus product types son genéricos ("Clothing", "Accessories", "Sport"), su categoría Google también es genérica, y el bid relevance cae entre un 12 y un 18% en queries long-tail. Solución: refinar la categoría Google manualmente sobre 5 niveles para los 50 SKUs principales.
Trampa 3: sync con GMC tras cambio de precio promo. Shopify sincroniza el feed cada 15 a 60 min, lo cual es rápido pero no instantáneo. Si lanza una promo flash de 12h, Google Merchant podría reflejar el nuevo precio solo entre 30 y 60 min después. Durante ese plazo, los anuncios sirven al precio antiguo, las conversiones a un ticket medio erróneo, datos de Smart Bidding sesgados. Solución: no inicie la promo hasta haber verificado en GMC que el precio actualizado se ha reflejado. Nuestra calculadora de ticket medio da el AOV con benchmarks por vertical e-commerce.
Lado PrestaShop: 3 trampas recurrentes
Trampa 1: feed XML refrescado una vez al día. Es la trampa más cara y más frecuente. El módulo estándar genera un XML cada 24h, Google Merchant lo crawlea 12h después. Stock mismatch garantizado en cuanto un SKU fluctúa rápidamente. Solución: forzar la regeneración vía cron cada 1 a 4h, o activar Content API.
Trampa 2: caracteres especiales no codificados en el feed. Caracteres franceses mal codificados (é, è, à, ç, œ) o españoles (á, é, í, ó, ú, ñ) en el XML generan warnings de Merchant que pueden escalar a desaprobación. Verifique que el encoding del feed sea UTF-8 estricto (no ISO-8859-1, no Windows-1252). Solución: módulo que fuerce UTF-8 o validación manual del XML producido antes del envío.
Trampa 3: imágenes de producto demasiado pequeñas. PrestaShop permite por defecto imágenes 400x400 o incluso menos, mientras que Google Shopping recomienda 800x800 mínimo (1200x1200 para los inventory ads de PMax en Display). Los SKUs con imagen por debajo de 800x800 pierden típicamente entre un 25 y un 40% de impresiones en placements Edge, MSN, Discover. Solución: auditoría completa de imágenes en los 200 SKUs principales y upgrade a 1200x1200 mínimo.
Migración Shopify a PrestaShop (y viceversa): impacto en los feeds
Una migración de CMS ocurre más a menudo de lo que se piensa — típicamente cuando un Presta legacy cruje bajo deuda técnica y se pasa a Shopify para empezar limpios, o a la inversa cuando un Shopify alcanza su techo funcional B2B y migra a Presta. Se subestima el impacto en Google Ads.
Riesgo número uno: ruptura del histórico de conversiones
Smart Bidding optimiza a partir del histórico de conversiones acumulado en la campaña, ligado a una cuenta Google Ads. Si cambia de CMS y reconfigura el tracking, corre el riesgo de romper el camino entre el evento de conversión y su registro en Google Ads. Durante 1 a 2 semanas, las conversiones no entran (o entran duplicadas si ha dejado activo el píxel antiguo), Smart Bidding entra en fase de aprendizaje caótica, el CPA se dispara temporalmente.
Solución estándar a 30 días pre-migración: prepare el tracking en el nuevo CMS en paralelo, pruebe en staging, luego cambie en modo hot-swap en 24h con monitorización minuto a minuto de las conversiones de Google Ads. Nunca migre un CMS durante un pico estacional (BF/CM, rebajas, fin de año).
Riesgo número dos: ruptura de IDs de producto
Si los id de sus productos cambian entre el CMS antiguo y el nuevo (típicamente, un Presta con IDs numéricos migra a Shopify con IDs alfanuméricos), Google Merchant Center trata todos los productos como nuevos, el feed entra en reaprobación durante 24-72h, y se pierde el histórico de rendimiento por SKU. Esto impacta especialmente a las cuentas que explotan los custom_label para la segmentación de campañas.
Solución: preserve los IDs de producto antiguos tanto como sea posible remapeándolos vía un atributo dedicado (item_group_id o id directamente copiado). Para Shopify, se hace vía metafield. Para PrestaShop migrado, vía mapping de módulo.
Riesgo número tres: pérdida de frescura de sync
Si migra de Shopify (sync de 15 a 60 min) a PrestaShop (sync de 24h por defecto), la degradación de frescura de sync genera desaprobaciones de stock que antes no tenía. Anticípelo activando Content API o un cron de 1-4h desde el día 1 del nuevo stack Presta.
Para migraciones complejas, una auditoría pre-migración se rentabiliza: identifica las áreas de riesgo (custom_labels perdidos, IDs rotos, sync degradada) antes de que la migración rompa el rendimiento de Google Ads. Nuestra auditoría gratuita SteerAds cubre estos puntos en 3 minutos de conexión OAuth, y propone un plan de migración sin ruptura a 14 a 30 días.
Para los arbitrajes estratégicos entre App promo, Shopping clásico y Performance Max e-commerce en el ecosistema Google Ads, lea también nuestra guía 2026 de App Promo Android e iOS — útil si su catálogo e-commerce también está disponible como app nativa.
La elección Shopify vs PrestaShop no es binaria para Google Ads. Shopify aporta una ventaja de time-to-launch y simplicidad operativa que se traduce en una ganancia de ROAS durante los 3 a 6 primeros meses. PrestaShop, operado con rigor (Content API, GTM server-side, módulos premium), alcanza el mismo rendimiento y ofrece flexibilidad superior a largo plazo y en catálogos complejos. El factor determinante no es el CMS en sí, es la calidad de las operaciones de feed, tracking y segmentación por margen. Elija el CMS que case con su velocidad operativa — no el que prometa magia — vea también la documentación oficial de Google Ads para más detalles.
Para profundizar, vea también nuestras guías Google Ads restaurante local, Google Ads servicios legales mundial, Google Ads inmobiliario leadgen.
Fuentes
Fuentes oficiales consultadas para esta guía:
FAQ
¿Shopify o PrestaShop para arrancar una tienda e-commerce diseñada para escalar en Google Ads?
Para un proyecto que apunta a escalar rápido en Google Shopping y Performance Max, Shopify sigue siendo más rápido de configurar: canal Google nativo, feed generado automáticamente, sincronización casi en tiempo real con GMC, Enhanced Conversions accionable en 5 min. PrestaShop exige más configuración inicial (módulo Doofinder, EnvoiMoinsCher, módulos de feed de pago o XML personalizado), pero ofrece una flexibilidad superior para catálogos complejos (multi-idioma, multi-divisa, atributos de negocio personalizados, customizaciones B2B). Para el 90% de las marcas DTC que arrancan, Shopify ofrece un time-to-revenue más rápido. Para comerciantes ya en PrestaShop con operaciones rodadas, migrar a Shopify solo por Google Ads rara vez se justifica — mejor invertir en un buen módulo de feed en el lado Presta.
¿Debo pagar por un módulo de feed de Shopping o usar el nativo de PrestaShop?
PrestaShop no ofrece generación nativa de un feed Google Shopping conforme a las especificaciones 2026 en su versión estándar. El módulo oficial "Google Shopping & Ads" en la PrestaShop addons store cuesta unos 200 a 250 euros una vez y sigue siendo la opción mantenida más directa. Alternativa: un módulo comunitario ("Simple Google Shopping XML feed") gratuito o de bajo coste, pero con menos mappings de atributos avanzados (custom_label, identifier_exists, clase de eficiencia energética). Para un catálogo por debajo de 500 SKUs y un setup estándar, un módulo comunitario puede bastar. Más allá, el coste del módulo oficial se rentabiliza muy rápido por la calidad de aprobación del feed y por tanto por el ROAS.
¿El canal Google nativo de Shopify gestiona Enhanced Conversions sin código?
Sí desde 2024. El canal Google & YouTube de Shopify envía automáticamente los parámetros de Enhanced Conversions (email hasheado, teléfono hasheado, nombre/apellido) en cada conversión enviada a Google Ads, sin intervención de dev. Basta con activar Enhanced Conversions en Google Ads (Herramientas > Conversiones > seleccionar la conversión > activar Enhanced Conversions for Web), y confirmar en Shopify que el customer data sharing está autorizado. En PrestaShop, activar Enhanced Conversions exige bien un módulo específico (a menudo de pago), bien una configuración server-side de GTM. Es una de las brechas operativas que más pesan en la facilidad de operación entre los dos CMS.
¿Cuál es la frecuencia de actualización del feed entre Shopify y PrestaShop?
Shopify, con su canal Google nativo, sincroniza el feed casi en tiempo real (cada 15 a 60 minutos según el volumen), lo que evita el desfase de precio/stock entre tienda y Merchant Center — crítico durante periodos de promo flash o roturas de stock. PrestaShop, en modo estándar, genera típicamente un archivo XML que Google Merchant recrawlea cada 24h. Para pasar a una frecuencia mayor en Presta hay que activar Content API (vía módulo dedicado) o servir un feed XML por HTTPS refrescado por cron cada 1 a 4h. El desfase de stock de 24h es uno de los principales contribuidores a las desaprobaciones "Item availability mismatch" observadas en auditorías Presta.
¿Performance Max funciona igual de bien en ambos CMS?
PMax funciona en ambos en cuanto el feed esté sano y el tracking limpio, pero la diferencia viene de los asset groups. Shopify no facilita la creación de asset groups desde el canal: hay que pasar por Google Ads y subir manualmente imágenes / vídeos / títulos. PrestaShop está en la misma situación, pero con el riesgo añadido de la calidad de las imágenes de producto (a menudo demasiado pequeñas, sin fondo blanco). Para ambos CMS, recomendación 2026: exportar las fichas de producto en un asset group por nivel de margen (alto/medio/bajo) basado en custom_label_0, en lugar de optar por un único asset group para todo el catálogo. La lógica de segmentación por margen está cubierta en nuestro playbook e-commerce 2026.