Optimizar feed de Google Shopping por margen, no por ROAS
Optimizar el feed de Google Shopping por margen: custom_labels por banda de CM y tROAS por break-even. El feed no es un catálogo, es tu estructura de pujas.
El feed es tu estructura de pujas: sin señal de margen, el smart bidding optimiza por ingresos y escala tus SKUs menos rentables. Etiqueta cada SKU con custom_label por banda de margen de contribución y asigna a cada banda un tROAS derivado de su break-even.
El feed no es un catálogo: es tu estructura de pujas
Tu feed de Google Shopping no es un catálogo de productos: es tu estructura de pujas. En PMax y Shopping, Google decide cuánto pujar por cada producto usando los atributos del feed — y si el feed no contiene ninguna señal de margen, el smart bidding optimiza por ingresos, no por beneficio. El resultado es predecible: el algoritmo escala tus productos de más facturación y menos margen, y tú celebras un ROAS que no paga las facturas.
Optimizar el feed de Google Shopping por margen — etiquetando cada SKU con custom_label según su margen de contribución y asignando un tROAS distinto a cada banda — es la palanca de rentabilidad con mejor ratio esfuerzo/impacto que existe en Shopping. Y casi nadie la toca, porque casi todo el mundo sigue “optimizando el feed” reescribiendo títulos.
Por qué el feed ES tu estructura de pujas
En una campaña de Search clásica, tú controlas la estructura: keywords, grupos de anuncios, pujas. En Shopping y PMax esa estructura desaparece. Lo que queda es el feed.
Google agrupa y decide con lo que hay en el feed:
- Los títulos y descripciones determinan a qué búsquedas te asocia.
product_typeygoogle_product_categorydeterminan cómo te clasifica.price,sale_pricey disponibilidad alimentan la predicción de conversión.- Los
custom_label_0acustom_label_4son los únicos cinco campos que Google te deja definir libremente — y los únicos con los que puedes segmentar campañas, asset groups y listing groups.
Aquí está el problema estructural: el smart bidding de Google (tROAS, Maximize Conversion Value) optimiza por el valor de conversión que le envías. Y el valor de conversión que le envía el 90% de los ecommerce es revenue. Google no sabe — no puede saber — que tu SKU estrella tiene un 18% de margen y el producto que casi no anuncia tiene un 65%.
Sin señal de margen, el algoritmo hace exactamente lo que le has pedido: maximizar ingresos. Que es distinto de maximizar beneficio. A veces, opuesto.
Es la misma tesis que desarrollamos en Contribution Margin Bidding: ROAS es lo que le cuentas a tu jefe, margen de contribución es lo que le cuentas a tu banco. El feed es donde esa tesis se ejecuta a nivel de SKU.
Qué pasa cuando “optimizas el feed” sin tocar la economía
La industria del feed management se ha construido alrededor de tres actividades: reescribir títulos, enriquecer atributos y arreglar desaprobaciones. Todo eso es higiene necesaria. Nada de eso es estrategia.
Un feed con títulos perfectos y cero señales de margen sigue teniendo el mismo defecto de fondo: todo el catálogo compite por el mismo presupuesto con el mismo objetivo de puja. Un tROAS de 400% aplicado a todo el feed significa:
- Productos con 65% de margen, que serían rentables a ROAS 1,8×, se quedan sin impresiones porque el objetivo global es demasiado agresivo para ellos.
- Productos con 15% de margen, que necesitan ROAS 7× para no perder dinero, escalan felizmente a ROAS 4× — quemando margen en cada venta.
El feed decide tu rentabilidad. Si no le das estructura de margen, la estructura que aplica Google es la de sus incentivos, no la de los tuyos.
El método Sellencia: feed etiquetado por margen, paso a paso
Esto es lo que hacemos en producción con los feeds que gestionamos. Cinco pasos, ninguno opcional.
Paso 1 · COGS por SKU → margen de contribución por producto
No puedes etiquetar por margen sin conocer el margen. Por SKU, no por categoría “a ojo”:
CM unitario = PVP (sin IVA)
− COGS
− envío medio por unidad
− fees de pasarela
− coste de devolución prorrateado por categoría
La fuente puede ser tu ERP, un CSV de COGS mantenido en Sheets, o — como lo montamos nosotros — una tabla de COGS en BigQuery que cruza contra el catálogo de Shopify. Esta capa es exactamente lo que resuelve Sellencia OS: Shopify + COGS + fees + devoluciones unificados, refrescados en tiempo real.
Si hoy no tienes COGS por SKU, empieza con COGS por categoría y un coste de envío medio. Impreciso es infinitamente mejor que ausente.
Paso 2 · custom_label_0 por bandas de margen
Con el CM% calculado, asigna cada SKU a una banda y escríbela en custom_label_0:
| Banda | Margen de contribución | custom_label_0 |
|---|---|---|
| A | CM > 60% | cm-60-plus |
| B | CM 40–60% | cm-40-60 |
| C | CM 20–40% | cm-20-40 |
| D | CM 0–20% | cm-0-20 |
| E | CM negativo | cm-loss |
Las bandas concretas dependen de tu distribución de márgenes: si el 80% de tu catálogo cae en una sola banda, ajusta los cortes hasta que las bandas separen de verdad. Los otros labels quedan libres para señales adicionales — custom_label_1 para tasa de devolución por categoría, custom_label_2 para estacionalidad o novedades.
La escritura del label se hace con una regla de feed en Merchant Center (si la lógica es simple), con la columna custom_label_0 en un feed suplementario, o programáticamente vía Content API. Nosotros usamos la tercera opción — más sobre esto en el paso 5.
Paso 3 · Campañas o asset groups por banda, con tROAS derivado del break-even
Aquí es donde el etiquetado se convierte en dinero. Cada banda tiene un ROAS de equilibrio distinto, calculable directamente:
ROAS break-even de la banda = 1 / CM% medio de la banda
Un producto con 50% de CM alcanza el equilibrio a ROAS 2×. Uno con 20%, a ROAS 5×. Pujar ambos con el mismo tROAS es garantizar que uno de los dos está mal pujado.
La estructura resultante:
- Una campaña PMax (o Shopping estándar) por banda, filtrada por
custom_label_0en los listing groups. - tROAS de cada campaña = break-even de la banda × factor de beneficio objetivo (típicamente 1,2–1,5×, según cuánto margen quieras retener por venta frente a cuánto quieras escalar).
- Presupuestos independientes: la banda A puede escalar agresivamente sin que la banda D le robe inversión.
¿Por qué campañas separadas y no un solo PMax con varios asset groups? Porque el tROAS en PMax se define a nivel de campaña, no de asset group. Si mezclas bandas en una campaña, vuelves a la casilla de salida: un objetivo único para economías distintas.
Paso 4 · SKUs en pérdidas: excluir o puja mínima
La banda E (cm-loss) — productos que pierden dinero en cada venta después de COGS, envío y devoluciones — tiene dos tratamientos legítimos:
- Exclusión del feed publicitario (vía
excluded_destinationo exclusión en listing groups). Es la opción por defecto. - Campaña propia con tROAS altísimo y presupuesto residual, solo si esos SKUs cumplen una función estratégica medible: producto gancho con LTV probado, liquidación de stock con coste de almacenaje real, o entrada a un bundle.
Lo que no es legítimo es lo que hace la cuenta media: dejar que esos SKUs compitan por presupuesto como los demás, financiando cada venta con margen de otros productos sin que nadie lo haya decidido.
Paso 5 · Mantenimiento: las etiquetas caducan
Los COGS cambian. Las tarifas de envío cambian. El proveedor te sube un 8% y tu banda B pasa a ser banda C sin avisar. Un feed etiquetado a mano en enero está mintiendo en abril.
Por eso el recálculo tiene que ser automático:
- Trigger: cambio en la tabla de COGS, en tarifas de envío, o recálculo programado (semanal es suficiente para la mayoría de catálogos).
- Proceso: recalcular CM% por SKU → reasignar banda → escribir
custom_label_0en Merchant Center vía Content API. - Stack: un workflow de n8n o una edge function que lee COGS de BigQuery/Supabase, recalcula y hace push al feed. Es el mismo patrón
merchant-feed-labelsque tenemos en producción dentro de Sellencia OS: la etiqueta de margen deja de ser un dato estático y pasa a ser un output del P&L.
El SKU cuyo margen cae de banda se mueve solo a la campaña con el tROAS correcto en el siguiente ciclo. Sin tickets, sin Excel, sin “lo reviso el mes que viene”.
Ejemplo numérico completo (hipotético)
Todos los números de esta tabla son de ejemplo, inventados para ilustrar la mecánica. No son datos de clientes. Catálogo ficticio de 400 SKUs, factor de beneficio objetivo 1,3×:
| Banda | CM% medio | custom_label_0 | ROAS break-even | tROAS objetivo (×1,3) | Tratamiento |
|---|---|---|---|---|---|
| A | 65% | cm-60-plus | 1,5× | 200% | PMax propia, presupuesto prioritario, escalar |
| B | 48% | cm-40-60 | 2,1× | 270% | PMax propia, escalar con control |
| C | 30% | cm-20-40 | 3,3× | 430% | PMax propia, presupuesto contenido |
| D | 12% | cm-0-20 | 8,3× | 1.080% | Shopping estándar, puja mínima, vigilar |
| E | −6% | cm-loss | n/a | n/a | Excluidos del feed publicitario |
Fíjate en la lectura contraintuitiva: la campaña “peor” por ROAS reportado (banda A, tROAS 200%) es la más rentable de la cuenta, y la de ROAS más espectacular (banda D, 1.080%) es la que menos margen genera por euro invertido. Si tu informe mensual ordena campañas por ROAS, este sistema te obligará a explicarle a alguien por qué la campaña de ROAS 2× es la buena. Esa conversación es el síntoma de que estás optimizando bien.
Errores típicos (los vemos cada semana en auditorías)
1. Optimizar títulos sin tocar la economía. Títulos perfectos + tROAS único = un feed precioso que pierde dinero de forma muy bien indexada. La higiene del feed es el paso cero, no la estrategia.
2. Un solo tROAS para todo el catálogo. Es el error estructural por excelencia. Un objetivo de 400% global infra-invierte en tus productos de margen alto y sobre-invierte en los de margen bajo, simultáneamente.
3. Ignorar devoluciones por categoría. En moda y calzado, una categoría con 30% de devoluciones y otra con 5% no tienen el mismo margen real aunque el COGS diga lo mismo. Prorratea el coste de devolución en el CM antes de asignar banda — o usa custom_label_1 como señal de devoluciones separada.
4. Etiquetar una vez y no volver. Un custom_label estático es una foto de tu P&L de hace tres meses. Sin recálculo automático, el sistema se degrada en silencio.
5. Bandas que no separan nada. Si el 85% del catálogo cae en cm-40-60, tus cortes están mal elegidos. Mira la distribución real de márgenes y corta donde haya masa a ambos lados.
¿Lo aplicamos a tu feed?
Si facturas +200K€/año y tu cuenta de Shopping/PMax funciona con un tROAS único para todo el catálogo, es casi seguro que estás financiando ventas sin margen con el beneficio de tus mejores SKUs.
En la auditoría gratuita de Paid Media analizamos tu feed, tu distribución de márgenes y tu estructura de campañas, y te decimos qué bandas tienen sentido para tu catálogo. Diagnóstico en 7 días. Sin compromiso, sin permanencia.
Preguntas frecuentes
- ¿Cuántos SKUs necesito para que las campañas por banda de margen funcionen?
- Con menos de ~50 SKUs por banda, consolida en dos campañas (margen alto / margen bajo) con dos tROAS. Cada campaña PMax necesita unas 30+ conversiones al mes para que el smart bidding aprenda.
- ¿Esto funciona en PMax o solo en Shopping estándar?
- Funciona en ambos. En PMax filtras por custom_label_0 en los listing groups; en Shopping estándar, en los grupos de producto. PMax exige campañas separadas porque el tROAS es a nivel de campaña.
- ¿Necesito un data warehouse para calcular el margen por SKU?
- No para empezar: un CSV con COGS por SKU, envío medio y fees de pasarela da una primera versión de las bandas. El warehouse entra para recalcular etiquetas automáticamente cuando cambian los costes.
- ¿No pierdo volumen al subir el tROAS de los productos de margen bajo?
- Pierdes volumen no rentable, que es el objetivo. El ROAS agregado puede bajar, pero el margen de contribución total sube porque el presupuesto migra a los SKUs donde cada euro devuelve más beneficio.
¿Quieres aplicarlo
a tu ecommerce?
Auditoría de Google Ads y Meta Ads: 490 € + IVA que solo pagas si encontramos al menos 1.000 € al año que recuperar.
Pedir la auditoría →