We sell products that are accessories to someone else’s product (a LEGO set). One of our products might work for 1 LEGO set, or we might have a generic product that works for multiple LEGO sets. For our products that are associated with 1 LEGO set, we have a product entry that shows all the info about the product and pictures as it pertains to that 1 LEGO set, and customers can easily find it with a search. The problem comes when we have a generic product that works for more than 1 LEGO set. We know our customers are going to search by the LEGO set number, and I’d prefer to have a product entry for each LEGO set, even if they all point to the same product on the back end. However, i’m not sure if this is possible. I assume every product entry needs a unique SKU. Is it possible for us to make multiple product entries with different description and photos, but have them point to the same SKU or Variant for convenience? I don’t want just a landing page, I don’t think. I’d prefer a product page that looks the same as the others, where I show our “generic” product in use with that specific LEGO set, and they can add it to their cart. I’d just have to make one of these virtual product pages for every LEGO set that our generic product is compatible with. I know its more work, but since customers are searching by LEGO set, they won’t know that this Generic product entry will work for it.
Hi @GSpence this is possible it’s just not a typical concept on the platform so it can be hard to communicate about and take some thinking to implement. If you need information architecture consulting or implementation of one of these method below you can contact me with info in my forum signature, please provide context.
At it’s most simple this is a placeholder product page that adds a different core|foundational|main|prime|underlying product to the cart.
Kinda the inverse of doing a product-family customization where a product has no actual variants but presents multiple separate products as the variant options.
So in the product templates/sections you’d find all the relevant product object references and change it to be a defined variable such as current_product that is set to be the core product, while leaving specific references to properties of the generic product such as description or it’s variant images.
Five organization approaches one based on handle names, linked or specially named collections, navigation menus, and now metafield definitions(mfdf).
A rough handle convention example be /product/accesory-1-single vs /product/accesory-1-generickeyword… wherein you just match every accesory-1-generickeyword… product to accesory-1-single using the all_products liquid feature to pull in the prime products data https://shopify.dev/api/liquid/objects#all_products . The handle method can be best in some situations where product names are well formed minimizing the amount of setup work that needs to be done as you just have to let code do all the association work.
Collection based method is generally the collection is named after the core product, then you just need a way to figure out what that core products name is in any generic-products logic such as with a metafield definition(mfdf), tags , or again utilizing product handles to figure out the associated handles.
If all sharing the same sku could also make the collection named after the sku then use a mfdf to define which product is the core product.
Note: the fundamental blocker here is that products cannot be queried by things like sku in liquid.
Navigation is similar to collection method but can be a right pain to setup in exchange for not having a bunch of collections muddying up the admin or the frontend.
Metafield definition method is just using a product reference type mfdef, or list, to associate the generice product with the core product but can result in ALOT of data entry if not thought through and possibly automated. Automation would basically need all the core products to be flagged then have some known convention to find all of a core products generic alternates to then have the generic be given a reference to the core product.
Alternative templates - every set of products is given a specific alternative product template that is wired to that sets core product. Lots of setup required
For the frontend sleight of hand some situations may just want to use the section-rendering api to pull in the product form of the core product using ajax instead of trying to modify every product-object reference in liquid templates and sections.
There can be different knock-on effects with this depending on implementation and backend needs such as whether you need to actually track the stock of the “placeholder” item, conversion analytics, SEO etc etc because your doing some presentation sleight of hand but not all systems will know this is going on. Which is why it could be better for the generic-product pages to act as landing pages that send them to the core product.
Goodluck.
The most basic form of this product page is the addition of a different product to the cart as an alternative to the core foundational main prime underlying one.
In a sense, this is the opposite of doing product-family customization, where a product has no actual variants, but displays multiple separate products as variant options in order to present users with more options.
So in the product templates sections you’d find all the relevant product object references and change them into a defined variable such as current product. This variable is set to be the core product, while leaving specific references to properties of the generic product such as description or its variant images.