
Auditoría de identificadores Shopify POD para Google Merchant
Tabla de contenido
- 1. Separar clases de identificador
- Ejecutar negative test
- 2. Clasificar la variante vendible
- Usar cuatro clases
- 3. Asignar field ownership
- Separar decisión e implementación
- 4. Crear source-evidence ledger
- Clasificar evidencia
- 5. Elegir identifier path
- Bloquear tres atajos
- 6. Cambiar una variante representativa
- Guardar rollback
- 7. Leer ambos sistemas
- Separar transporte de aceptación
- 8. Ampliar tras la aceptación
- Mantener registro durable
- Matriz de decisión
- Checklist de una variante
- FAQ — Preguntas Shopify POD
- ¿SKU puede ser MPN?
- ¿Todo POD usa false?
- ¿Colores comparten GTIN?
- ¿Seller crea un MPN?
- ¿Approval prueba corrección?
- Siguiente paso — audita una variante
Un SKU de Shopify puede organizar la tienda y aun así no ser el GTIN o MPN que Google espera. El ID de variante del proveedor puede identificar blank, color y talla para fulfillment sin identificar el producto terminado vendido al comprador. Una impresión personalizada puede cambiar la identidad comercial, pero la palabra custom no demuestra que todos los identificadores externos falten.
Por eso un warning comienza con clasificación, no con rellenar campos. Shopify dirige al merchant a un barcode verificado cuando existe GTIN o a brand y MPN apropiados en Google & YouTube. Google exige identificadores asignados, sin adivinar, sustituir con SKU interno ni copiar un sibling. Este flujo registra una variante desde source hasta channel; no promete approval ni resultados.
1. Separar clases de identificador
Escribe store SKU, provider variant ID, Google item ID, GTIN, MPN y brand en columnas separadas. SKU es clave operativa del merchant; provider ID suele mapear blank, método, color o talla; Google item ID identifica una oferta enviada. GTIN, MPN y brand describen identidad de producto asignada y no son intercambiables.
Ejecutar negative test
2. Clasificar la variante vendible
Clasifica una variante terminada, no todo el catálogo como POD. Usa cuatro clases: widely manufactured con identifiers asignados; store brand/private label sin GTIN; custom-made finished product que puede carecer de UPI; y mixed/unresolved identity cuando blank y finished product chocan. No existe regla universal para custom: algunos conservan GTIN del manufacturer y otros no tienen UPI.
Usar cuatro clases
3. Asignar field ownership
Crea un mapa de cuatro owners. Sourcing conserva evidencia manufacturer/provider del blank. Product owner define decoration, options y customer-facing brand.
Separar decisión e implementación
4. Crear source-evidence ledger
Para un warning variant registra Shopify product/variant ID, SKU, title, options, provider product/variant ID, blank, print method, seller brand, market, language, landing URL, Google item ID, UPIs actuales, identifier-exists, diagnostic y timestamps. Califica sources como strong, conditional, weak o invalid. Cada valor debe completar: esta parte asignó este valor a este exact sellable object y se observó aquí en esta fecha.
Clasificar evidencia
5. Elegir identifier path
Si la variante exacta tiene GTIN asignado, envía solo el verified value y brand/MPN verificados aplicables. Si GTIN existe pero no está disponible, no adivines ni uses false como bypass. Si seller es manufacturer y only seller de store-brand item, aplica una política brand/MPN documentada cuando las reglas lo permitan.
Bloquear tres atajos
6. Cambiar una variante representativa
Congela valores Shopify, Google item ID, diagnostic, landing URL y timestamp. Elige una representative variant con source claro y sin bulk edit activo. Cambia solo el field set sustentado: barcode verificado, brand/MPN verificados, retiro de sibling value o eliminación de invented value mientras investiga el owner.
Guardar rollback
7. Leer ambos sistemas
Reabre exact Shopify variant y verifica SKU, barcode, options, availability y Google channel fields. Luego abre exact Merchant Center item y verifica item ID, target country, language, submitted GTIN/MPN/brand, identifier-exists, processing e issue details. Registra por separado saved in Shopify, submitted by channel, received by Google y evaluated for destination.
Separar transporte de aceptación
8. Ampliar tras la aceptación
Abre landing page como buyer y confirma title, selected option, color, size, brand y visible finished product contra feed item y evidence.
Mantener registro durable
Matriz de decisión
| Situación | Acción | Liberación |
|---|---|---|
| Hay GTIN asignado | Enviar exact verified value | Probar una variante |
| GTIN existe pero falta | Dejar unresolved, no adivinar | Consultar source owner |
| Store brand sin GTIN | Usar política brand/MPN documentada | Verificar categoría |
| No hay UPI relevante | Dejar campos y evaluar false | Leer diagnostics |
Checklist de una variante
- Registrar Shopify product ID
- Registrar Shopify variant ID
- Registrar store SKU
- Registrar provider product ID
- Registrar provider variant ID
- Nombrar finished product
- Registrar color y size
- Registrar seller brand
- Capturar target country
- Capturar target language
- Capturar Google item ID
- Guardar diagnostic
- Separar SKU de GTIN
- Separar provider ID de MPN
- Verificar GTIN issuer
- Verificar variant scope
- Verificar MPN issuer
- Verificar brand source
- Clasificar identity
- Registrar razón de false
- Hacer sibling negative test
- Congelar current values
- Definir rollback
- Cambiar un field set
FAQ — Preguntas Shopify POD
¿SKU puede ser MPN?
No solo por ser único. MPN necesita issuer y exact product scope válidos.
¿Todo POD usa false?
No. Clasifica exact finished variant y usa false solo cuando UPIs faltan realmente.
¿Colores comparten GTIN?
No lo supongas. Verifica assignment para cada color y size.
¿Seller crea un MPN?
Puede aplicar en manufacturer/store-brand documentado, no autoriza valores aleatorios.
¿Approval prueba corrección?
No. Conserva source evidence, submitted values, landing identity, destination y tiempo.
Siguiente paso — audita una variante
Elige una Shopify POD variant con Google identifier warning, prueba su clase, cambia solo el field set respaldado y guarda readbacks de Shopify, Merchant Center y buyer view antes de tocar siblings.
Marco general de ecommerce operations, no consejo legal, publicitario, regulatorio, fiscal, financiero, de datos ni platform policy. Google, Shopify, providers, categorías, mercados, identifiers, diagnostics y channels cambian. Revisa documentación oficial y exact item state. No garantiza approval, visibility, traffic, ranking, clicks, conversion, revenue ni resultado financiero.