Squarespace combina la estructura de un sitio web alojado con registros comerciales dentro de un mismo entorno. Esa combinación cambia el significado de los datos durante una migración. Un Product no existe únicamente como una fila de catálogo: pertenece a una Store Page, tiene un tipo de Product concreto, puede contener variantes y atributos y se presenta mediante la estructura de contenido y navegación del sitio. Una persona compradora puede aparecer como Contact, Customer, suscriptor, donante o usuario del sitio según la relación que originó el registro. Un Order conserva una transacción, pero no se convierte en la configuración que determina el funcionamiento futuro del proceso de compra, pagos, procesamiento de pedidos o impuestos.
La tarea central consiste en conservar las relaciones que hacen útil cada registro dentro de Squarespace. Los datos de Product deben mantenerse conectados con su tipo de Product, Store Page, variantes, imágenes, URL e inventario. Los datos de Contact deben conservar la diferencia entre identidad de comprador, participación en listas de correo, actividad de donaciones y acceso a cuentas. Los registros de contenido y SEO deben mantener su destino y referencias internas en lugar de tratarse como texto decorativo alrededor de la tienda.
El significado comercial de Squarespace empieza en el sitio y la Store Page
Squarespace no es un catálogo independiente colocado junto a un sitio web sin relación. Los registros comerciales viven dentro de un sitio cuyo panel Pages, Store Pages, navegación, colecciones de contenido, dominios y URL determinan cómo se publican y encuentran los Products. Cada Product pertenece a una única Store Page, mientras que su disponibilidad también depende tanto de la visibilidad del Product como del estado de la Store Page.
Esta regla de propiedad importa cuando la plataforma de origen utiliza varios catálogos, colecciones, sitios web o canales de venta. Un Product no puede trasladarse correctamente hasta definir la relación con su Store Page de destino. La ubicación en una Store Page no es una simple decisión de menú: participa en la visibilidad del Product y en el significado de su URL.
| Supuesto en la tienda de origen | Significado de la relación en Squarespace | Consecuencia para la adaptación |
|---|---|---|
| Los Products existen independientemente del sitio web | Cada Product pertenece a una Store Page dentro de un sitio Squarespace | Mantener la identidad del Product junto con la Store Page que debe ser su propietaria. |
| La asignación de categorías recrea la navegación | La agrupación de Products, ubicación en Store Pages, etiquetas, Categories y navegación del sitio están relacionadas, pero son independientes | Adaptar la clasificación por separado de los menús y la presentación de las páginas. |
| Un tipo genérico de Product sirve para cualquier oferta | Squarespace diferencia Products físicos, de servicio, tarjetas regalo y descargables | El tipo de Product determina qué relaciones de variantes, inventario, procesamiento y archivos están disponibles. |
| Customer equivale a suscriptor de lista de correo | Contacts puede representar Customers, suscriptores, donantes y otras relaciones con el sitio | Conservar el motivo por el que existe la persona en el destino, no solo su correo electrónico. |
| Los Orders importados recrean las operaciones comerciales | Orders conserva historial y estado transaccional; el funcionamiento futuro se configura por separado | Mantener la evidencia de transacciones separada de la configuración de pagos, impuestos, envíos y notificaciones. |
Esta relación entre sitio y comercio también afecta a los identificadores externos. Un ID de Product del origen puede tener que permanecer asociado al Product o variante de Squarespace que utiliza un ERP. Un ID de página del origen puede corresponder a la migración de contenido y no al comercio. Un ID CRM de Customer debe permanecer con la relación de Contact reconocida por el CRM, no con un Order simplemente porque ese identificador apareció por primera vez durante el proceso de compra.
Los tipos de Product definen relaciones distintas entre registros
Squarespace admite Products físicos, de servicio, tarjetas regalo y descargables. Estos tipos no son simples etiquetas visuales. Determinan si un Product puede tener variantes, cómo se representa el inventario, qué significado tiene el procesamiento y qué registros adicionales participan en la venta.
Los Products físicos pueden contener variantes y datos relacionados con el envío. Los Products de servicio también pueden contener variantes, por ejemplo duración o nivel, aunque el significado de su procesamiento difiere de una entrega física. Los Products de tarjeta regalo pueden utilizar variantes para las denominaciones. Los Products descargables conectan el Product con un bien digital y no admiten variantes de la misma manera.
| Oferta del origen | Significado del Product en Squarespace | Relación que debe conservarse |
|---|---|---|
| Mercancía tangible | Product físico | Store Page, variantes, SKU, precio, peso/dimensiones cuando corresponda, inventario, imágenes, significado de envío y URL. |
| Consultoría, clase, experiencia o nivel de servicio | Product de servicio | Identidad del servicio, variante de nivel o duración, precio, contenido y cualquier responsable independiente de programación o prestación. |
| Crédito de tienda o certificado regalo digital | Product de tarjeta regalo | Variantes de denominación, relación de emisión de la tarjeta, contexto de comprador/destinatario y significado financiero. |
| Archivo descargable | Download Product más relación DigitalGood | Metadatos del Product, archivo comprado, derecho de entrega y URL; no un conjunto inventado de variantes. |
| Oferta de suscripción o recurrente | Product más relación de suscripción y Order | La identidad del Product sigue separada de la facturación recurrente, los derechos y el estado de renovación. |
| Oferta de donación o membresía | Donación, membresía u otra área conectada de Squarespace en lugar de un Product ordinario cuando corresponda | Las relaciones de Contact, transacción, acceso y contenido siguen perteneciendo a la función correcta de Squarespace. |
Una plataforma de origen puede modelar todas estas ofertas como Products, SKU o tipos personalizados de Product. La adaptación a Squarespace debe seguir el funcionamiento del destino. Un archivo descargable de un curso, una consulta programada y un libro enviado pueden compartir título y precio, pero no comparten las mismas relaciones de procesamiento ni de registros.
Atributos, variantes, imágenes e inventario de Product
Los atributos de Product en Squarespace definen valores como color o talla, mientras que las variantes representan combinaciones que pueden comprarse. Una variante puede tener un SKU, precio, cantidad de existencias, dimensiones y valores de atributo propios. Las imágenes pertenecen a la colección de imágenes del Product y pueden asociarse con variantes.
Las opciones del origen deben separarse según su efecto comercial. Un valor que cambia SKU, precio, existencias, imagen o identidad de procesamiento se comporta como una variante. Una instrucción de personalización, servicio opcional, componente de paquete o configuración generada por una aplicación puede no tener un equivalente directo como variante de Squarespace. Convertir todas las elecciones del origen en variantes puede crear una matriz de Products inmanejable, mientras que reducir variantes reales a texto elimina identidad de inventario y SKU.
| Patrón de opción del origen | Propietario en Squarespace | Significado que debe mantenerse |
|---|---|---|
| Combinación talla/color con SKU y existencias | Atributos de Product y ProductVariant | Identidad comprable, valores de atributos, SKU, precio, inventario y relación con imágenes. |
| Nivel o duración de servicio | Variante de Product de servicio | Elección de servicio que puede venderse y sus diferencias de precio o descripción. |
| Denominación de tarjeta regalo | Variante de Product de tarjeta regalo | Denominación monetaria que puede comprarse. |
| Formato de descarga | Normalmente identidad de Product o relación de archivo separada, no variante de un Download Product | Derecho correcto sobre el archivo e identidad del Product. |
| Grabado, texto libre o archivo subido por el comprador | Entrada personalizada, datos de línea del Order o extensión conectada según el funcionamiento compatible | El valor aportado por el cliente permanece vinculado a la compra y al responsable del procesamiento. |
| Paquete o configurador | Relación entre Products, simplificación aceptada o estructura de extensión/sistema externo | Los componentes, SKU resultante, precio, inventario y salida de línea de Order siguen siendo explicables. |
El inventario se gestiona por variante. La Inventory API de Squarespace representa un InventoryItem como una variante de un Product físico o de servicio y almacena si el inventario se controla o es ilimitado, junto con SKU e información de disponibilidad. Esto significa que una cantidad mantenida a nivel de Product en el origen debe reconciliarse primero con la estructura de variantes del destino.
Una cantidad de existencias del origen también necesita una decisión sobre el sistema autoritativo. Si Squarespace es propietario del inventario, la cantidad inicial debe alinearse con las variantes de Product del destino. Si un almacén o ERP sigue siendo autoritativo, la relación duradera es ProductVariant → clave externa de stock → sincronización de inventario. Una cantidad copiada sin ese identificador queda desactualizada en cuanto el sistema externo reanuda sus actualizaciones.
Store Pages, Categories, etiquetas, navegación y descubrimiento
Las Store Pages son propietarias de los Products, pero no sustituyen todas las estructuras de descubrimiento del origen. Categories, etiquetas, ubicación en Store Pages, enlaces de navegación, bloques de resumen, búsqueda, páginas de contenido y enlaces de campañas externas pueden ayudar a encontrar Products. Una colección del origen puede haber representado un departamento permanente, una campaña temporal, una marca, un resultado de filtros o una página editorial. Estos significados deben mantenerse diferenciados.
| Estructura de descubrimiento del origen | Significado en el destino Squarespace |
|---|---|
| Departamento permanente del catálogo | Product Category o agrupación duradera en Store Page según la estructura del destino. |
| Marca del Product | Etiqueta, relación de contenido, convención de nombres o campo externo de información de Product, según el uso de la marca. |
| Colección de temporada | Category, etiqueta, página seleccionada o relación temporal de navegación, no necesariamente un tipo permanente de Product. |
| Atributo de filtro por facetas | Atributo de variante, contenido estructurado del Product, etiqueta o sistema externo de búsqueda/filtrado; no automáticamente una Category. |
| Enlace de navegación principal | Relación de navegación del sitio hacia una Store Page, vista de Category, página de contenido o URL externa. |
| Página de entrada SEO | Página o destino de Store Page conectado con Products, contenido, URL, metadatos y enlaces internos. |
La Products API no expone todas las relaciones de Category de una Store Page del mismo modo que expone registros de Product, lo que refuerza la necesidad de separar los datos de catálogo de la organización del sitio. El modelo de destino debe identificar qué registros son propietarios de la clasificación de Products y qué registros del sitio son responsables del descubrimiento público.
Un Product puede migrarse correctamente y, aun así, quedar prácticamente inaccesible si pertenece a una Store Page equivocada, está oculto o no dispone de una ruta de navegación accesible. Es un problema de relaciones, no evidencia de que falten los campos del Product.
Contacts, Customers, suscriptores, donantes y acceso a cuentas
Las funciones comerciales y de marketing de Squarespace pueden crear varios significados relacionados con una misma persona. Contacts puede representar Customers, suscriptores, donantes y otras personas asociadas al sitio. Las libretas de direcciones y las preferencias de marketing pertenecen a esas relaciones. El modelo anterior Profiles exponía categorías similares de usuarios del sitio, mientras que la Contacts API actual es el propietario moderno de una gestión más amplia de Contacts.
Una cuenta de Customer del origen también puede incluir contraseñas, grupos de clientes, roles B2B, saldos de fidelización, datos de pago guardados, acceso de membresía, estado de suscripción, exenciones fiscales o atributos CRM. Estos significados no deben reducirse a un único registro Contact simplemente porque la persona utiliza una sola dirección de correo electrónico.
| Patrón de identidad del origen | Decisión de relación en Squarespace |
|---|---|
| Comprador registrado | Identidad Contact/Customer conectada con Orders, direcciones y funcionamiento de cuenta compatible. |
| Comprador invitado durante el proceso de compra | Identidad vinculada al Order, con Contact duradero solo cuando la relación de destino lo admite. |
| Suscriptor de boletín | Contact más relación con lista de marketing y consentimiento, separada del historial de compras cuando corresponde. |
| Donante | Contact más historial de donaciones/transacciones, no automáticamente un Customer comercial. |
| Miembro o participante con contenido restringido | Contact/usuario del sitio más relación de membresía o acceso; contraseña y derechos no son campos ordinarios de perfil. |
| Comprador B2B u organización | Contact más responsabilidad de CRM/sistema externo para empresa, rol, precios, impuestos o estructuras de aprobación. |
| Perfiles duplicados del origen | Solo se consolidan cuando identidad, consentimiento, dirección y evidencia de Orders respaldan que se trata de una misma persona. |
El correo electrónico puede ser una señal fuerte de identidad, pero no la única. Direcciones compartidas, cambios de correo, Orders como invitado, importaciones duplicadas y contactos de organizaciones pueden producir fusiones incorrectas. Pueden ser necesarios IDs externos de CRM, IDs de Customer del origen, direcciones y relaciones con Orders para mantener separadas las personas y su historial.
El consentimiento de marketing debe seguir siendo una relación distinta de la identidad de comprador. Un Customer que compró no se convierte automáticamente en suscriptor de una lista de correo y un suscriptor puede no haber comprado nunca. Conservar el Contact sin mantener la relación que explica por qué existe puede crear confusión operativa y problemas de consentimiento.
Orders, transacciones, procesamiento e historial
Los Orders de Squarespace pueden representar compras únicas y Orders de suscripción. Contienen líneas, información de Customer, direcciones de facturación y envío, totales, descuentos, impuestos, detalles de envío, estado de procesamiento, estado de pago, reembolsos y otro contexto transaccional. Transactions proporciona los registros financieros asociados a Orders y donaciones.
El Order debe mantener el Product o variante comprado en ese momento, incluso si el Product actual cambia posteriormente. Una línea es una instantánea de la transacción, no una referencia activa que deba sobrescribirse con el contenido actual del catálogo. Los estados de pago y reembolso describen lo que ocurrió financieramente. El procesamiento y seguimiento explican cómo se atendió la compra. Los Orders importados o históricos no definen los procesadores de pago actuales, reglas de envío, configuración fiscal, funcionamiento del correo ni conexiones con almacenes.
| Registro histórico | Significado en Squarespace |
|---|---|
| Número de Order del origen | Referencia externa rastreable para atención al Customer y conciliación. |
| Línea de Product/variante | Título comprado, SKU, atributos seleccionados, cantidad, precio y otra información instantánea de la línea. |
| Direcciones de facturación y envío | Contexto histórico de la transacción, no dirección permanente de la cuenta salvo que pertenezca por separado al Contact. |
| Línea de descuento, impuesto y envío | Explicación del total histórico, no configuración actual de descuentos o impuestos. |
| Estado de pago y transacción | Historial financiero vinculado al Order, no credenciales de pago reutilizables. |
| Procesamiento y seguimiento | Contexto histórico de envío o prestación del servicio, no definición de los métodos actuales de procesamiento. |
| Estado de suscripción o plan de pagos | Ciclo de vida de Order y transacción que debe permanecer conectado con el sistema que controla los cargos futuros. |
| Order importado desde un canal externo | Historial del Order más identificador del canal externo y relación con el origen. |
Squarespace puede importar Orders desde canales de venta de terceros mediante sus Commerce APIs, pero el historial importado debe conservar el origen y los identificadores originales. Crear un Order de Squarespace no elimina al mercado en línea, proveedor de pagos o sistema de procesamiento original como propietario histórico de las referencias relacionadas.
Páginas, Blog Posts, recursos multimedia, URL y relaciones SEO
Los sitios Squarespace pueden contener páginas normales, Store Pages, Blog Posts, elementos de colección, imágenes, archivos, enlaces de navegación, URL de Products, vistas de Category, campos SEO, redirecciones, dominios y servicios conectados. Estos registros forman un grafo de contenido alrededor del catálogo comercial.
La descripción de un Product del origen pertenece al Product. Una guía de compra puede pertenecer a una página o Blog Post que enlaza con varios Products. La descripción de una Category puede convertirse en contenido de una Store Page o página de entrada. Una página de campaña puede incluir referencias a Products sin ser propietaria de sus datos. Los recursos multimedia pueden compartirse entre Products y contenido, pero el orden de imágenes, recorte, texto alternativo, pies y enlaces internos tienen significado específico dentro del sitio.
| Recurso web del origen | Propietario en Squarespace |
|---|---|
| Título, descripción, imágenes, slug de URL y datos SEO de Product | Relación Product y Store Page. |
| Página CMS informativa o de políticas | Página Squarespace con contenido, recursos multimedia, metadatos y relación de navegación. |
| Blog Post | Elemento de colección del blog con contexto de publicación, categorías/etiquetas, recursos multimedia, enlaces internos y URL. |
| Guía de Products o página de campaña | Página/colección de contenido más referencias a Products y navegación. |
| Elemento de menú | Relación de navegación del sitio hacia una página, Store Page, destino de Product, ancla o URL externa. |
| URL del origen | Ruta de destino más relación de redirección cuando cambia la ruta. |
| Bloque del tema o código personalizado | Presentación/configuración del sitio que referencia registros de contenido y comercio sin convertirse en su propietario. |
La continuidad de URL depende de la identidad del destino. Una redirección debe conectar la ruta antigua del origen con el Product, Store Page, página, Blog Post u otro destino correcto. No debe utilizarse para ocultar la incertidumbre sobre qué registro sustituyó a la página original. Los enlaces internos dentro del contenido migrado también deben apuntar al destino previsto en lugar de conservar URL obsoletas del origen.
Extensiones, API, campos personalizados y propiedad de sistemas externos
Las Commerce APIs de Squarespace exponen Products, Inventory, Orders, Transactions, Contacts, Discounts, Websites y webhooks. Los servicios y extensiones conectados también pueden ser propietarios de reseñas, fidelización, suscripciones, procesamiento de pedidos, contabilidad, envíos, marketing, programación, donaciones, membresías u otros datos. Un registro de aplicación del origen no debe tratarse como dato nativo de Squarespace simplemente porque una extensión de destino ofrezca una función similar.
El propietario correcto depende del propósito comercial y del ciclo de vida. Un ID de almacén de Product pertenece a la relación entre ProductVariant y ERP. Un ID CRM de Contact pertenece al Contact y al CRM. Un ID de Order de un mercado en línea pertenece al Order y al canal. Un derecho de membresía pertenece al sistema de membresías, no a una nota genérica del Contact.
| Valor personalizado o externo | Propiedad en el destino |
|---|---|
| ID ERP de Product o variante | Product/ProductVariant más relación ERP con el mismo nivel de granularidad del catálogo. |
| Clave externa de inventario | ProductVariant más almacén o sistema de inventario. |
| ID CRM de Contact | Contact más relación CRM. |
| ID de Order de mercado en línea | Order más relación con el canal de venta. |
| Registro de reseña, fidelización o suscripción | Extensión o sistema externo más referencias a Product, Contact u Order. |
| Salida de configurador de Product | Product/variante más configuración perteneciente a extensión e instantánea resultante de la línea del Order. |
| Respuesta personalizada durante el proceso de compra | Order o Contact según el propósito comercial, más formulario/extensión responsable de recoger y mostrar el dato. |
| Tabla del origen no compatible | Registro padre explícito, clave duradera, ciclo de vida y propietario de destino antes de conservar el valor. |
Este límite evita dos fallos habituales: forzar cada valor dentro del campo más próximo de Squarespace y conservar datos de aplicaciones sin ningún consumidor en el destino. Un campo personalizado solo es útil cuando el equipo de destino sabe qué registro es su propietario, qué sistema lo reconoce y si describe comercio actual, contexto histórico, contenido o configuración externa.
Cadenas representativas de adaptación a Squarespace
Una cadena de relaciones muestra cómo un concepto del origen se divide entre registros de comercio, Contact, contenido y sistemas externos en Squarespace. Hace visible al propietario de destino y evita que un único campo importado cargue con varios significados incompatibles. La cadena debe seguir siendo comprensible incluso cuando la plataforma de origen ya no esté disponible, de forma que cada referencia a Product, Contact, Order, URL y extensión tenga un padre y un consumidor continuado claramente definidos.
| Patrón del origen | Relación de destino en Squarespace |
|---|---|
| Product de ropa con existencias por talla/color | Store Page → Product físico → atributos → ProductVariants → imágenes/SKU de variante → InventoryItems. |
| Paquetes de consultoría | Store Page → Product de servicio → variantes de nivel/duración → contenido → sistema externo de programación o prestación cuando sea necesario. |
| Descarga digital | Store Page → Download Product → DigitalGood → línea de Order → Contact comprador → derecho de entrega. |
| Suscriptor que después compra | Contact → relación de lista de correo/consentimiento → historial de Customer/Order, sin asumir que ambas relaciones son idénticas. |
| Venta importada de un mercado en línea | Order → instantánea de línea → historial de transacción/procesamiento → Contact → ID externo del mercado. |
| Colección de Products sensible para SEO | Store Page/Category o página seleccionada → referencias a Products → navegación → URL de destino → redirecciones desde rutas de origen. |
| Registro de membresía o donación | Contact → propietario de membresía o donación → historial de transacción/acceso, separado de campos ordinarios de Product y Customer. |
Estas cadenas mantienen visible la propiedad entre Product, sitio, Contact, Order, contenido y sistemas externos. También muestran dónde una plataforma de origen puede haber combinado varios significados en un único registro que Squarespace representa por separado.
Conclusión
La adaptación del modelo de datos de Squarespace depende de la relación entre los registros comerciales y el sitio que los publica. Los Products pertenecen a Store Pages y tipos de Product; las variantes son propietarias de las combinaciones vendibles y del inventario; Contacts puede representar significados de Customer, suscriptor, donante y acceso a cuentas; Orders conserva el historial de transacciones; páginas, Blog Posts, URL y navegación son responsables del descubrimiento de contenido; y las extensiones y sistemas externos son propietarios del funcionamiento especializado.
Un modelo de destino sólido conserva estas relaciones sin confundir los datos migrados con la presentación del sitio o la configuración operativa futura. El resultado no es simplemente un sitio Squarespace lleno de registros, sino un conjunto coherente de Products, Contacts, Orders, contenido y registros externos cuya propiedad sigue siendo comprensible.
Preguntas frecuentes
¿Por qué importa la propiedad de Store Page para los Products de Squarespace?
Cada Product de Squarespace pertenece a una Store Page y su disponibilidad depende tanto de la visibilidad del Product como del estado de esa Store Page. Por eso, los datos del Product y su ubicación en Store Page forman una relación de destino, aunque la navegación del sitio continúe siendo una capa separada.
¿Puede cualquier opción de Product del origen convertirse en una variante de Squarespace?
No. Una variante es adecuada cuando la elección crea una combinación comprable distinta con SKU, precio, inventario, imagen, dimensiones u otro significado de venta. La personalización, los paquetes, archivos subidos o elecciones controladas por aplicaciones pueden necesitar otro propietario.
¿Contacts, Customers y suscriptores de Squarespace son el mismo tipo de registro?
Pueden referirse a la misma persona, pero sus relaciones son distintas. El historial de Customer, el consentimiento para listas de correo, la actividad de donaciones, las libretas de direcciones y el acceso a cuentas deben seguir siendo distinguibles incluso cuando un Contact los conecte.
¿Un Order migrado recrea el funcionamiento del proceso de compra de Squarespace?
No. El Order conserva el contexto de transacción, líneas, pagos, reembolsos, direcciones y procesamiento. Los procesadores de pago actuales, configuración fiscal, métodos de envío, notificaciones y funcionamiento del procesamiento conectado siguen siendo configuración separada.
¿Cómo debe representarse el inventario de Product en Squarespace?
El inventario debe seguir al ProductVariant de Squarespace que representa el artículo vendible. Si un sistema externo de inventario sigue siendo autoritativo, la variante también necesita la clave externa duradera utilizada para mantener las existencias después de la transferencia inicial de datos.
¿Dónde deben permanecer los datos personalizados o pertenecientes a aplicaciones en Squarespace?
Deben permanecer con el Product, ProductVariant, Contact, Order, registro de contenido, extensión o sistema externo que sea propietario de su propósito comercial. Las notas genéricas no sustituyen una relación padre definida ni un identificador duradero.