Variantes de color y talla: cómo organizar la información para que no se convierta en un desastre
Una guía práctica para organizar variantes de producto en hojas de cálculo y sistemas PIM, con criterios claros para decidir qué va en el padre y qué en el hijo.
Las variantes parecen simples hasta que abrimos la planilla.
Tenemos una remera en tres colores y cinco talles. Un pantalón con dos lavados y seis talles. Un par de zapatillas con varios números. Una camisa que comparte descripción, material y marca, pero cambia color, talle, SKU, código de barras, stock, imagen y a veces hasta precio.
Al principio, todo parece una sola familia de productos. Después, cuando llega el momento de cargarlo en una hoja de cálculo, en un eCommerce o en un PIM, aparece la pregunta que ordena —o desordena— todo: ¿qué información va en el producto padre y qué información va en cada hijo?
Esta decisión es una de las más importantes en catálogos con variantes. Si la resolvemos bien, el catálogo se vuelve más claro, más mantenible y más fácil de publicar. Si la resolvemos mal, cada carga de productos se transforma en una colección de excepciones, duplicados y correcciones manuales.
En esta nota vamos a enfocarnos en variantes de color y talla porque son muy comunes, especialmente en moda, indumentaria, calzado y retail. Pero la lógica también sirve para otros casos: medidas, capacidades, acabados, presentaciones, voltajes o combinaciones técnicas.
Una variante no es un producto completamente nuevo ni una simple característica suelta. Es una versión específica de un producto base que comparte información común, pero cambia en atributos clave.
¿Qué es una variante de producto?
Una variante de producto es una versión específica de un producto que comparte una base común con otras versiones, pero se diferencia por uno o más atributos.
Por ejemplo:
- Remera básica blanca talle S.
- Remera básica blanca talle M.
- Remera básica negra talle S.
- Remera básica negra talle M.
Todas pertenecen al mismo producto base: “Remera básica”. Pero cada combinación de color y talle puede tener su propio SKU, su propio código de barras, su propio stock y, en algunos casos, sus propias imágenes o precios.
En un modelo padre-hijo, el producto padre agrupa la información común. Los productos hijos representan cada variante concreta.
Podemos pensarlo como una receta base y sus presentaciones. La masa puede ser la misma, pero cada porción puede tener distinto topping, tamaño o empaque. Si escribimos toda la receta completa para cada porción, repetimos información. Si guardamos solo la receta base y no registramos qué cambia en cada porción, perdemos precisión. El modelo correcto está en separar lo común de lo variable.
¿Por qué las variantes suelen desordenar el catálogo?
Las variantes desordenan el catálogo cuando no hay una regla clara sobre qué dato pertenece al padre y qué dato pertenece al hijo.
En una planilla, esto se ve enseguida. Algunas filas tienen descripción repetida. Otras solo tienen SKU y talle. Algunas imágenes están en el padre, otras en el hijo. A veces el color está escrito en el nombre, en una columna aparte y también en la descripción. El talle puede aparecer como “M”, “Medium”, “mediano” o “Talle M”. Y, si la información viene de varios proveedores, cada uno puede traer su propia lógica.
El problema no es la existencia de variantes. El problema es que las variantes obligan a tomar decisiones de modelado. Y si esas decisiones no están escritas, cada persona resuelve como puede.
En catálogos con variantes, el desorden no suele empezar por la cantidad de SKUs. Empieza por no separar con claridad qué dato es común y qué dato cambia.
¿Qué va en el producto padre?
El producto padre debería contener la información que comparten todas las variantes.
En una prenda, por ejemplo, suelen ir en el padre:
- Nombre base del producto.
- Marca.
- Categoría.
- Descripción general.
- Material principal, si no cambia por variante.
- Composición, si no cambia por variante.
- Género o público.
- Temporada o colección.
- Línea comercial.
- Instrucciones generales de cuidado.
- Beneficios principales.
- Relación con productos complementarios.
- Texto SEO o texto editorial común, si aplica.
El padre funciona como el “capítulo principal” de ese producto. No debería estar cargado de detalles que solo corresponden a una variante específica.
Por ejemplo, si tenemos “Remera básica” en blanco, negro y azul, la descripción general puede estar en el padre: tipo de prenda, calce, material, uso recomendado. Pero el color específico no debería vivir solo en el padre si cada hijo tiene un color diferente.
Lo mismo ocurre con el talle. Si el producto existe en S, M, L y XL, el talle pertenece a cada hijo. El padre puede decir que el producto tiene variantes por talle, pero no debería tener un valor único de talle.
¿Qué va en el producto hijo?
El producto hijo debería contener la información que identifica a cada variante concreta.
En variantes de color y talla, suelen ir en el hijo:
- SKU.
- Código de barras, EAN o GTIN.
- Color.
- Talle.
- Stock, si se gestiona a nivel de variante.
- Precio, si cambia por variante.
- Imagen específica, si corresponde.
- Peso logístico, si cambia por variante.
- Dimensiones de empaque, si cambian por variante.
- Estado de publicación por canal, si se administra a ese nivel.
- ID externo de marketplace o eCommerce, si aplica.
El hijo responde preguntas más específicas: “¿Cuál es exactamente esta versión del producto?”, “¿qué combinación de color y talle representa?”, “¿se puede vender?”, “¿tiene stock?”, “¿qué código la identifica?”.
Si alguien compra una remera negra talle M, no está comprando el padre abstracto “Remera básica”. Está comprando una variante concreta. Por eso, los datos necesarios para identificar, vender y entregar esa unidad tienen que estar en el hijo.
El padre organiza la familia del producto. El hijo identifica la versión que realmente se vende, se stockea y se entrega.
Una regla simple para decidir padre o hijo
Cuando aparece la duda, podemos usar una pregunta muy directa:
¿Este dato es igual para todas las variantes o cambia según color, talla u otra opción?
Si el dato es igual para todas las variantes, probablemente vaya en el padre.
Si el dato cambia según la variante, probablemente vaya en el hijo.
| Dato | ¿Dónde suele ir? | Motivo |
|---|---|---|
| Marca | Padre | Es común a todas las variantes |
| Descripción general | Padre | Explica el producto base |
| Color | Hijo | Cambia por variante |
| Talle | Hijo | Cambia por variante |
| SKU | Hijo | Identifica cada variante vendible |
| GTIN / EAN | Hijo | Identifica cada unidad comercial |
| Stock | Hijo | Se gestiona por variante |
| Imagen de color | Hijo o grupo de color | Depende del modelo visual |
| Categoría | Padre | Suele ser común |
| Precio | Padre o hijo | Depende de si cambia por variante |
Esta tabla no es una ley universal. Hay industrias y plataformas que pueden pedir estructuras distintas. Pero como criterio inicial ayuda muchísimo.
Color y talla no se comportan exactamente igual
Aunque solemos hablar de “color y talla” juntos, no siempre se comportan igual dentro del catálogo.
El talle suele ser una variante puramente identificatoria. Una remera talle S y una remera talle M pueden compartir la misma imagen, descripción, color y material. Lo que cambia es la talla y, por supuesto, el SKU, el stock y el código de barras.
El color, en cambio, suele tener impacto visual. Una remera blanca y una negra pueden necesitar imágenes distintas. También pueden cambiar algunos textos, nombres comerciales o incluso materiales si el proceso de teñido o el acabado difieren.
Esto hace que muchas veces el color tenga más peso en la experiencia de compra que el talle. En un eCommerce, el usuario suele elegir primero el color que ve y después el talle disponible. En la carga de datos, eso puede implicar una organización más cuidadosa de imágenes, nombres de variante y orden de visualización.
No significa que el color sea más importante que el talle. Significa que cumplen funciones distintas: el color ayuda a elegir visualmente; el talle ayuda a seleccionar la unidad correcta.
Cómo organizar variantes en una hoja de cálculo
Una hoja de cálculo puede funcionar muy bien como etapa previa al PIM si está bien estructurada. El problema aparece cuando intentamos representar padres e hijos sin un criterio claro.
Una estructura simple podría tener una fila para el padre y una fila para cada hijo. Para eso, conviene usar columnas que indiquen el tipo de registro y la relación entre ellos.
| Tipo de registro | ID padre | SKU hijo | Nombre | Color | Talle | Marca | Descripción | GTIN |
|---|---|---|---|---|---|---|---|---|
| Padre | REMERA-BASE-001 | Remera básica | Marca X | Remera básica de algodón | ||||
| Hijo | REMERA-BASE-001 | REM-BLA-S | Remera básica blanca S | Blanco | S | 779000000001 | ||
| Hijo | REMERA-BASE-001 | REM-BLA-M | Remera básica blanca M | Blanco | M | 779000000002 | ||
| Hijo | REMERA-BASE-001 | REM-NEG-S | Remera básica negra S | Negro | S | 779000000003 | ||
| Hijo | REMERA-BASE-001 | REM-NEG-M | Remera básica negra M | Negro | M | 779000000004 |
En este ejemplo, la marca y la descripción están cargadas en el padre porque son comunes. El color, el talle, el SKU y el GTIN están en los hijos porque identifican cada variante.
La columna “ID padre” es clave. Sin ese vínculo, las variantes quedan como productos sueltos. Y cuando las variantes quedan sueltas, después es mucho más difícil reconstruir la familia.
En una planilla de variantes, la columna más importante no siempre es el SKU. Muchas veces es el identificador que permite saber qué hijos pertenecen a qué padre.
¿Conviene repetir los datos del padre en cada hijo?
Depende del uso de la planilla.
Para trabajar internamente, suele ser mejor no repetir todo si el modelo padre-hijo está claro. Repetir la descripción, la marca, la categoría y otros datos comunes en cada hijo aumenta el riesgo de inconsistencias. Una fila puede quedar actualizada y otra no.
Pero hay canales o sistemas que piden archivos planos donde cada fila debe estar completa. En esos casos, puede ser necesario repetir algunos datos del padre en cada hijo para que el canal pueda leerlos.
La diferencia está en saber si esa repetición es parte del modelo o solo una exportación.
En el modelo maestro, conviene evitar duplicaciones innecesarias. En una salida específica, puede ser necesario aplanar la información para cumplir con el formato de destino.
Dicho simple: no diseñemos el modelo como si fuera una exportación puntual. Diseñemos el modelo para mantener la información limpia y después preparemos las salidas que cada canal necesite.
Cómo nombrar productos padre e hijos
El nombre del producto también necesita una regla.
El padre debería tener un nombre base claro:
- Remera básica de algodón.
- Jean recto tiro alto.
- Zapatilla urbana modelo Serena.
- Camisa Oxford manga larga.
Los hijos pueden sumar los valores que los diferencian:
- Remera básica de algodón – Blanco – S.
- Remera básica de algodón – Blanco – M.
- Remera básica de algodón – Negro – S.
- Remera básica de algodón – Negro – M.
La clave es evitar dos extremos. Por un lado, nombres de hijos demasiado genéricos, donde no sabemos qué variante representan. Por otro, nombres larguísimos que repiten información innecesaria y mezclan atributos que deberían vivir en columnas.
Un buen nombre de variante ayuda a reconocer el producto, pero no reemplaza la estructura de atributos. El color debe estar en la columna “Color”. El talle debe estar en la columna “Talle”. El SKU debe estar en la columna “SKU”. El nombre acompaña, pero no debería ser el único lugar donde vive la información.
Cómo manejar imágenes en variantes de color
Las imágenes suelen complicar el modelo de variantes, especialmente cuando el color cambia.
Si todas las variantes comparten imagen, la imagen puede estar en el padre. Esto puede pasar en productos donde la diferencia es solo talla o medida.
Si cada color tiene imagen propia, conviene asociar las imágenes al nivel correspondiente. En algunos modelos, eso significa cargar imágenes en cada hijo. En otros, puede existir una agrupación intermedia por color. Depende de la plataforma y del nivel de sofisticación del catálogo.
Lo importante es que la regla sea clara:
- Si la imagen representa a todo el producto, puede ir en el padre.
- Si la imagen representa un color específico, debería asociarse al color o a los hijos de ese color.
- Si la imagen representa una variante exacta, debería ir en el hijo.
Por ejemplo, una remera blanca en todos los talles puede compartir la misma imagen blanca. No necesitamos cargar una foto distinta para S, M, L y XL si visualmente es el mismo producto. Pero sí necesitamos distinguir esa imagen de la remera negra.
La organización de imágenes no es un detalle visual. Es parte del dato de producto. Una imagen mal asociada puede hacer que el usuario compre una variante creyendo que está viendo otra.
El problema de los talles: valores, orden y equivalencias
El talle parece simple, pero puede traer bastante trabajo.
En una planilla podemos encontrar “S”, “Small”, “CH”, “Chico”, “36”, “Talle 36”, “36 EU”, “6 US”. Algunas diferencias son de idioma. Otras son de escala. Otras son de formato. Y otras son diferencias reales que no conviene mezclar.
Por eso, el talle necesita vocabulario controlado y, muchas veces, tablas de equivalencia. No basta con escribirlo “como viene del proveedor”.
Además, el orden importa. Si los talles se ordenan alfabéticamente, pueden aparecer como L, M, S, XL, XS. Para una persona, ese orden es incómodo. Para un sitio de moda, es directamente malo. Conviene definir un orden lógico: XS, S, M, L, XL, XXL; o 35, 36, 37, 38, 39, según el tipo de producto.
Normalizar talles no es solo corregir cómo se escriben. También es definir escala, equivalencias y orden de visualización.
El problema del color: nombres comerciales y colores normalizados
El color también tiene su propia trampa. Muchas marcas usan nombres comerciales: “arena”, “noche”, “vino”, “cemento”, “oliva”, “marfil”, “azul petróleo”, “verde bosque”. Esos nombres pueden ser útiles para vender, pero no siempre sirven como valores normalizados para filtros.
Una forma práctica de resolverlo es separar dos atributos:
| Atributo | Ejemplo | Uso |
|---|---|---|
| Color comercial | Azul noche | Nombre visible o de marca |
| Color normalizado | Azul | Filtro, búsqueda, agrupación |
Así no perdemos riqueza comercial, pero mantenemos orden operativo. El usuario puede ver “Azul noche” en la ficha, mientras el filtro agrupa ese producto bajo “Azul”.
Esto evita listas interminables de colores en el eCommerce y ayuda a que los productos sean más encontrables.
Cuándo una diferencia justifica una variante
No toda diferencia justifica crear una variante.
Una variante debería representar una opción que el usuario puede elegir o una unidad comercial que el negocio necesita identificar de forma separada. Color y talla suelen cumplir con esa condición. Pero otras diferencias pueden resolverse como atributos simples.
Por ejemplo, si un producto tiene una descripción larga y una descripción corta, eso no crea variantes. Si tiene una imagen principal y una imagen secundaria, tampoco. Si tiene varios beneficios, no necesariamente. Si tiene diferente color, talle, capacidad, medida o presentación vendible, probablemente sí.
La pregunta útil es: ¿esta diferencia cambia la unidad que se compra, se stockea, se identifica o se publica?
Si la respuesta es sí, puede ser una variante. Si la respuesta es no, probablemente sea un atributo del producto.
Errores comunes en variantes de color y talla
Hay errores que aparecen una y otra vez cuando trabajamos con variantes.
Uno es cargar cada variante como producto independiente sin relación con el padre. Esto permite avanzar rápido al principio, pero después complica la navegación, la publicación y la experiencia de compra.
Otro error es cargar color y talle solo dentro del nombre del producto. “Remera básica blanca M” puede ser entendible para una persona, pero si el color y el talle no están en columnas propias, no se pueden filtrar, validar ni mapear correctamente.
También es frecuente repetir información del padre en cada hijo sin una regla de herencia. Si se actualiza la descripción en algunos hijos y en otros no, el catálogo empieza a mostrar versiones distintas del mismo producto.
Otro problema es mezclar escalas de talles. Por ejemplo, talles europeos, estadounidenses y locales dentro de la misma columna sin aclaración. Esto genera errores de publicación y confusión para el usuario.
Y, por último, aparece mucho la falta de identificadores únicos. Sin SKU, GTIN o algún identificador estable por variante, cualquier integración se vuelve frágil.
Cómo revisar si una planilla de variantes está bien armada
Antes de importar variantes a un PIM, conviene revisar la planilla con una lógica bastante simple.
Podemos preguntarnos:
- ¿Cada hijo tiene un padre asociado?
- ¿Cada hijo tiene SKU único?
- ¿Cada variante vendible tiene GTIN o identificador requerido por el canal?
- ¿Color y talle están en columnas propias?
- ¿Los valores de color están normalizados?
- ¿Los talles tienen una escala clara?
- ¿La información común está en el padre?
- ¿La información variable está en el hijo?
- ¿Las imágenes están asociadas al nivel correcto?
- ¿Hay variantes duplicadas?
- ¿Falta alguna combinación que debería existir?
- ¿Hay combinaciones que no deberían existir?
Esta revisión puede hacerse con filtros, tablas dinámicas y validaciones simples. No hace falta empezar con una herramienta avanzada. Lo importante es que la planilla permita detectar inconsistencias antes de que entren al sistema.
Cómo se ve esto dentro de un PIM
En un PIM, el modelo padre-hijo permite mantener una estructura más ordenada. El producto padre puede contener los datos comunes y los hijos pueden heredar parte de esa información, mientras completan los atributos que los diferencian.
Por ejemplo, el padre puede tener marca, descripción, categoría, material y colección. Los hijos pueden tener color, talle, SKU, GTIN, stock y códigos de canal.
Esta herencia reduce la duplicación. Si cambia la descripción general, no hace falta corregirla en veinte variantes. Si cambia el material común, se actualiza en el padre. Si cambia el stock de una talla específica, se actualiza en el hijo correspondiente.
El objetivo no es hacer una estructura complicada. Es evitar que la misma información viva repetida en muchos lugares sin control.
Un buen modelo de variantes reduce duplicación sin perder precisión. Lo común se hereda; lo específico se carga donde corresponde.
Qué cambia cuando hay más de dos ejes de variantes
Color y talla son el caso clásico, pero no el único. Hay productos que pueden variar por color, talla y largo. Otros por medida, acabado y voltaje. Otros por capacidad, aroma y presentación.
Cuando aparecen más de dos ejes, el modelo necesita revisarse con más cuidado. No siempre conviene generar todas las combinaciones posibles. A veces no todas existen, no todas se venden o no todas tienen sentido comercial.
Por ejemplo, una prenda puede venir en tres colores y cinco talles, pero no todos los colores están disponibles en todos los talles. Un producto técnico puede venir en dos voltajes y tres capacidades, pero ciertas combinaciones pueden no existir. Si la planilla genera variantes automáticamente sin validar disponibilidad real, crea productos falsos.
En estos casos, conviene trabajar con una matriz controlada, donde cada fila represente una combinación vendible real. No una combinación teórica.
Una regla final para no perderse
Cuando trabajamos con variantes, el objetivo no es que la planilla “se vea linda”. El objetivo es que el modelo represente bien la realidad comercial del producto.
El padre debe responder: ¿qué producto es este?
El hijo debe responder: ¿qué versión exacta se vende?
Si mantenemos esa diferencia clara, muchas decisiones se vuelven más simples. La descripción general va al padre. El SKU va al hijo. El color y el talle van al hijo. La marca suele ir al padre. El GTIN va al hijo. Las imágenes dependen de qué representan. El stock casi siempre va al hijo.
Parece básico, pero esta lógica evita muchísimos errores.
Ordenar variantes es ordenar decisiones
Las variantes de color y talla no son solo un tema de carga de datos. Son una prueba bastante concreta de qué tan bien está pensado el modelo del catálogo.
Si no sabemos qué va en el padre y qué va en el hijo, el catálogo empieza a duplicar información, perder consistencia y depender de correcciones manuales. Si lo definimos bien, la carga se vuelve más clara, la publicación más estable y el mantenimiento más simple.
En moda y retail, esto se nota enseguida. Pero la lógica aplica a cualquier catálogo donde un producto tenga versiones vendibles. Cada variante necesita estar bien identificada. Cada dato común necesita vivir en un lugar confiable. Cada atributo variable necesita estar separado para poder filtrarse, mapearse y publicarse.
Organizar variantes es parecido a ordenar una biblioteca por colección y ejemplares. La obra tiene un título, un autor y una descripción general; cada ejemplar tiene su propio estado, ubicación e identificador. En un catálogo, el padre nos ayuda a entender la familia del producto y el hijo nos permite vender la versión correcta. Cuando esa relación está bien armada, el catálogo deja de ser una pila de filas repetidas y empieza a funcionar como una estructura que se puede mantener, revisar y hacer crecer.
