¿Cómo reclasificar un gran catálogo de productos sin romper la tienda?

Un producto puede pertenecer a varios sistemas de clasificación

Un producto puede tener una familia interna de mercancías, un grupo de productos ERP, una categoría de productos Shopify, un tipo de producto personalizado, una o más colecciones, una categoría de productos de Google y una clasificación de proveedores. Estos valores pueden parecer similares mientras sirven diferentes propósitos. Tratarlos como un campo de categoría intercambiable causa cambios no deseados.

La categoría de producto de Shopify utiliza su taxonomía de producto estándar. Tipo de producto es un valor personalizado separado. Colecciones de productos de grupo para la navegación y merchandising. Los metacampos de categoría proporcionan atributos asociados a una categoría de taxonomía. Un catálogo interno puede necesitar una jerarquía más detallada que cualquier canal externo.

Antes de cambiar los registros, cree un registro de clasificación que nombre cada esquema, su propietario, identificador, propósito de negocio y destinos. La migración debe traducir entre esquemas deliberadamente en lugar de copiar una etiqueta en cada campo.

Definir primero el problema de cliente y operativo

La reclasificación es útil cuando los clientes no pueden navegar por el catálogo, los filtros muestran valores inconsistentes, los canales publicitarios malinterpretan los productos, los equipos informan de la misma gama de manera diferente o los nuevos productos entran en el flujo de trabajo incorrecto. Escribe la mejora prevista en términos mensurables antes de diseñar el nuevo árbol.

Una solicitud para “tidy the categories” es demasiado vaga. Estado que los viajes deben mejorar: encontrar un accesorio por máquina y aplicación, comparar una familia de productos, enrutar un producto al equipo de aprobación correcto, o enviar una categoría exacta a un canal de ventas.

Mantenga la profundidad de clasificación proporcional. Una jerarquía que es elegante para un especialista de datos puede crear ramas de almacén vacías y mantenimiento innecesario. Use categorías para significado de producto estable y atributos para distinciones que los clientes puedan filtrar o comparar.

Preserve identidad de producto mientras las clasificaciones cambian

Una migración de categoría no debe crear nuevos productos simplemente porque las etiquetas o caminos cambian. Retener el ID de producto mercante, SKU, Shopify product and variety IDs, ERP item reference and any verified trade-item identifiers. La clasificación es una propiedad del registro, no su identidad.

No coincida con las filas de migración sólo por título, mango o categoría actual. Los títulos cambian, los mangos pueden ser editados y la vieja categoría ya puede estar equivocada. Resolver cada cambio propuesto contra IDs estables y mostrar a la empresa especializada Shopify store o ERP antes de que se ejecute un lote.

Mantenga la antigua clasificación junto a los nuevos valores propuestos en la vista previa. Eso hace que los mapas inesperados de muchos a uno, los registros no registrados y las asignaciones duplicadas sean visibles antes de que se escriba algo.

Diseño de una tabla de asignación con resultados explícitos

Por cada valor antiguo, definir la nueva clase interna, relevante categoría Shopify taxonomía, tipo de producto, atributos requeridos, reglas de recogida y cartografías de canales. Utilice identificadores de taxonomía estables donde una plataforma les proporciona, en lugar de confiar sólo en etiquetas que pueden ser renombradas o traducidas.

Permitir más que un simple par viejo a nuevo. Un grupo viejo puede dividirse según los atributos del producto; varios grupos heredados pueden fusionarse; un valor obsoleto puede requerir revisión; y algunos productos pueden permanecer intencionadamente sin clasificarse hasta que se disponga de pruebas.

Dar a cada fila un resultado como mapeado, condicional, sin cambios, revisión o rechazado. Un mapeo perdido debe detener ese registro en lugar de caer a una categoría amplia que hace que el lote parezca completo.

Treat Shopify category and product type as different fields

Shopify describe la categoría de producto como un campo estándar de su taxonomía y tipo de producto como una categoría personalizada que se puede utilizar además de las categorías estándar. Decidir qué vocabulario controlado pertenece en cada campo y no sobreescribir un tipo de producto útil simplemente porque se introduce una categoría de taxonomía.

Una categoría Shopify puede soportar requisitos de canal, condiciones de recogida y atributos específicos de categoría. Tipo de producto puede preservar la propia agrupación de un comerciante donde la taxonomía estándar es más amplia que el catálogo. Los dos campos deberían haber documentado mapas, no duplicado el texto libre por accidente.

Avance registros cuyo valor actual no mapea exactamente. Una categoría aparentemente cercana puede llevar atributos inapropiados o significado corriente. Tener tareas inciertas para la revisión de producto-propietario.

Compruebe los metacampos y filtros de la categoría antes de publicar

Shopify category metafields map to product categories and expose attributeds relevant to that category. Mover un producto puede cambiar qué atributos de categoría están disponibles. Inventario de los metacampos de categoría existentes y decidir cómo se transfieren sus valores, permanecen como datos de producto ordinarios o requieren revisión.

Shopify Search & Discovery puede utilizar la categoría, opciones de productos, metafields y metafields de categoría como filtros. Por lo tanto, una migración puede eliminar un filtro, introducir valores vacíos o fragmentar un valor en varias ortografías. Pruebe la configuración planeada en una colección representativa antes de aplicarla a través del catálogo.

Destinguir ‘no aplicable’ de datos perdidos. Ocultar o mover valores de filtro vacíos según el viaje del cliente, pero mantener la excepción de calidad de datos subyacente visible al equipo responsable de completar los registros.

Colecciones separadas de la taxonomía subyacente

Las colecciones son grupos orientados al cliente y pueden ser manejadas manualmente o por reglas. Un producto puede aparecer legítimamente en varias colecciones aunque tenga una categoría de taxonomía primaria. No forzar colecciones promocionales, de marca, compatibilidad y de casos de uso en un árbol de categoría única.

Listar todas las condiciones de colección automatizadas que dependen del tipo de producto, etiquetas, proveedor, precio, inventario o metacampos. Simular la membresía con los datos propuestos y comparar los recuentos de productos antes y después. Investigar adiciones y absorciones inesperadas antes de publicar.

Mantenga cambios de navegación en una versión revisada separada. Clasificación correcta de productos primero, verificar la membresía de la colección, luego actualizar menús y landing pages. Esto evita enviar clientes a una rama vacía o incompleta mientras la migración sigue funcionando.

Mapa categorías de publicidad sin copiarlas ciegamente

Google Merchant Center distingue la categoría de productos Google predefinidos del tipo de producto definido por comerciante. Google puede asignar categorías automáticamente, mientras que una categoría presentada puede anular ese resultado para productos seleccionados. Esa es otra decisión de mapeo, no una razón para que cada categoría interna coincida con la redacción de Google.

Google requiere que las categorías de productos de Google sean presentadas para utilizar su taxonomía predefinida. Mantenga el código seleccionado o el camino completo en el mapeo del canal y validarlo contra la taxonomía actual. Preserve la propia jerarquía del tipo de producto del comerciante por separado cuando ayuda a agrupar o reportar campañas.

Después de la reclasificación, compare el sitio web, datos de producto estructurados y valores de alimentación para productos representativos. La información de los productos conflictiva o inexacta puede restringir la elegibilidad o producir pantallas incorrectas. Revisar el diagnóstico del Centro Merchant en lugar de asumir una carga aceptada demuestra que la categoría es útil.

Use estándares de clasificación como mapas, no la verdad universal

GS1 Global Product Classification proporciona a los socios comerciales un lenguaje común para agrupar productos según propiedades y relaciones esenciales. Puede ser valioso para el intercambio con proveedores y clientes, pero una organización puede todavía necesitar clasificaciones internas operativas y orientadas al cliente.

Grabar la versión e identificador de cada taxonomía externa utilizada. Cuando un estándar publica una revisión, calcula qué mapas son afectados antes de cambiar los registros en vivo. No remape todo el catálogo solamente porque una etiqueta cambió mientras que el significado de la categoría y el identificador permanecen estables.

Retener pruebas para decisiones ambiguas. Una nota corta explicando por qué un acoplador de excavadoras pertenece en una rama en lugar de un grupo de maquinaria general es más útil para el próximo revisor que un valor de categoría sin racionalidad.

Vista previa del gráfico de dependencia

Una vista previa útil muestra los IDs estables de cada producto, clasificaciones actuales y propuestas, regla de asignación y razón. También enumera las colecciones, filtros automatizados afectados, metacampos de categoría, campos de alimentación, enlaces de navegación, informes y valores conectados de ERP.

Impacto del resumen antes de pedir aprobación: productos que se mueven, registran sin cambios, mapas perdidos, filtros que ganan o pierden valores, colecciones que cambian de membresía y categorías de canales que están siendo superados. Deje que los revisores inspeccionen los registros individuales detrás de cada cuenta.

Nunca convierta una vista previa parcial en una operación de escritura. Si no se puede leer una conexión, versión taxonomía o definición de colección, marque la dependencia desconocida y detenga los registros afectados.

1. Congelar la versión cartográfica y exportar el estado de clasificación actual.
2. Resolver productos a través de IDs estables de origen y destino.
3. Cálculo de los valores propuestos en cada esquema de clasificación.
4. Simula colecciones, filtros, atributos, feeds e informes.
5. Examinar excepciones y aprobar un lote controlado.
6. Escribir campos aprobados, leerlos y verificar el comportamiento público.

Un ejemplo concreto: reorganizar un catálogo de apegos de excavadoras

Imagínese que una tienda Shopify tiene 6.000 adjuntos bajo tipos de productos heredados como ‘Buckets’, ‘Digger Buckets’, ‘HD Bucket’ y ‘Excavator Parts’. El ERP utiliza grupos de elementos numéricos, mientras que las colecciones automatizadas dependen del tipo de producto y las etiquetas. Los clientes necesitan navegar por la familia adjunto y luego filtrar por clase de máquina, ancho y ajuste.

El mapeo mantiene sin cambios cada producto y variante ID. asigna categorías de taxonomía aprobadas Shopify cuando sea apropiado, crea una familia interna controlada para cavar, deshacerse y cubos de enigma, y mueve la clase y el ancho de la máquina en atributos validados. Los tipos de productos Legacy mapa a un vocabulario mercante más pequeño en lugar de ser copiado en el campo de categoría estándar.

La vista previa revela que 214 productos dejarían sus colecciones ya existentes porque una regla todavía comprueba 'HD Bucket', 73 registros carecen de ancho, y 18 productos tienen identidades inciertas. El equipo actualiza la regla de la colección, tiene registros incompletos y aprueba un piloto de 250 productos. Después de leer-back, los filtros de tienda, los valores de alimentación de Google y los informes de ERP se verifican antes de que los lotes restantes sean liberados.

Roll out in reversible batches

Comience con un piloto representativo que incluye simples asignaciones, divisiones, fusiones, variantes, productos incompletos y registros utilizados por importantes colecciones. Un lote debe ser lo suficientemente pequeño para inspeccionar pero lo suficientemente amplio para exponer fallas de reglas.

Almacene los valores anteriores, versión de mapeo, aprobación y resultado de per-destinación. Si la verificación falla, restaurar sólo los campos afectados a través de los mismos IDs estables. No tire hacia atrás precios, acciones o copias que estaban fuera del ámbito de migración.

Pausa entre lotes lo suficiente como para inspeccionar los recuentos de colección, filtros, diagnóstico de alimentación y retroalimentación. Una migración rápida que daña el descubrimiento de productos crea más trabajo que una secuencia controlada con puntos de control visibles.

Prueba la migración con registros difíciles

Crear casos de regresión para un movimiento directo, una sola división, una combinación de muchos a uno, categoría desconocida, atributo faltante, colección manual, colección automática, categoría metafield, etiqueta multilingüe, anulación de alimentación y producto descontinuado. Decir qué debe y no debe cambiar.

Incluir fallos: duplicar SKUs, mal Shopify store, indisponible NetSuite o Sage 200 conexión, identificador de taxonomía, escritura parcial y un producto devuelto con diferentes valores después de leer-back. Confirme que un registro fallido no hace que el lote parezca totalmente exitoso.

Medir los productos no incluidos, los movimientos incorrectos de recolección previnieron, los atributos perdidos descubiertos, advertencias de alimentación, retrocesos verificados y el tiempo necesario para aprobar excepciones. El objetivo es un catálogo más útil, no sólo menos nombres de categoría.