Proposal: Create Brand Taxon Column for Schema.org and Brand Driven Promotions

[fthobe]

Summary

With the introduction of a separate Brand Taxon we save a lot of logic down the line:

• eventual checks for which taxons could be defined as brands are not neccessary anymore (generation of feed become easier);
• implementation of brands on frontend for structured data does not require particular logic anymore.

Credits for most of the solution go to @JustShah

Checklist

Check out our PR guidelines for more details.

The following are mandatory for all PRs:

• I agree that my PR will be published under the same license as Solidus.
• I have written a thorough PR description.
• I have kept my commits small and atomic.
• I have used clear, explanatory commit messages.

The following are not always needed:

• 📖 I have updated the README to account for my changes.
• 📑 I have documented new code with YARD.
• 🛣️ I have opened a PR to update the guides.
• ✅ I have added automated tests to cover my changes.
• 📸 I have attached screenshots to demo visual changes.

[tvdeyen]

Can you elaborate why you chose to use a taxon over a dedicated model? Not sure that a taxon is actually the correct way of modelling a single attribute of a product. Maybe I am missing something.

[fthobe]

Can you elaborate why you chose to use a taxon over a dedicated model? Not sure that a taxon is actually the correct way of modelling a single attribute of a product. Maybe I am missing something.

Sure.
I can give you a simple example:
Imagine you sell refurbished iPhones (an iPhone 16 Pro Max), perfumes (Armani Passion for Man) or Shoes (Adidas Stan Smith Sneakers).

Those are the searches you want to capture with landing pages:

Short Tail (short searches with high outcome variability on Google)

• Example iPhone: "refurbished iPhone" (a category taxon), "refurbished Apple" (a brand taxon)
• Example Perfume: "Armani man perfume" > Armani Brand Taxon
• Example Sneaker: "Adidas Sneaker" > Adidas Brand Taxon

It's all about having a model behind that generates pages with collections. We actually already started that work here: PR Brand Taxons

Actually if you look at it in detail on other systems a brand is nothing else than a category with a different template.

I am only making it easier to handle for frontend and API.

[tvdeyen]

Can you elaborate why you chose to use a taxon over a dedicated model? Not sure that a taxon is actually the correct way of modelling a single attribute of a product. Maybe I am missing something.

Sure. I can give you a simple example: Imagine you sell refurbished iPhones (an iPhone 16 Pro Max), perfumes (Armani Passion for Man) or Shoes (Adidas Stan Smith Sneakers).

Those are the searches you want to capture with landing pages:

Short Tail (short searches with high outcome variability on Google)

• Example iPhone: "refurbished iPhone" (a category taxon), "refurbished Apple" (a brand taxon)
• Example Perfume: "Armani man perfume" > Armani Brand Taxon
• Example Sneaker: "Adidas Sneaker" > Adidas Brand Taxon

It's all about having a model behind that generates pages with collections. We actually already started that work here: PR Brand Taxons

Actually if you look at it in detail on other systems a brand is nothing else than a category with a different template.

I am only making it easier to handle for frontend and API.

Thanks, I see. I actually do not see a need for adding an additional field to the product for this feature. Why not just create a Taxonomy "Brand" and assign those taxons to the product? Is there anything wrong with this approach? I can imagine adding the "Brand" taxonomy to the sample seeds, so it is easier for stores to start.

[fthobe]

Thanks, I see. I actually do not see a need for adding an additional field to the product for this feature. Why not just create a Taxonomy "Brand" and assign those taxons to the product? Is there anything wrong with this approach? I can imagine adding the "Brand" taxonomy to the sample seeds, so it is easier for stores to start.

Yes, because it creates outcome variability, a lot of additional code to maintain in feeds and brings us back to the same problem that caused us to integrate primary_taxon .

I'd see an additional value in having a brands concern totally separate from brands, but we had that discussion and it was rejected settling for taxons.

If you all three decide to come up with a solution we can follow through with that, but based on previous conversations I think this is a reasonable approach.

[tvdeyen]

Taxons are used to categorize products in nested structures.

We do not use taxons for properties like size or color either. (Although you definitely could). But since you want Brand to be a strong (validated, unique and filtered by) attribute I think it's best to use a "Brand" model.

What are the rest of the @solidusio/core-team thoughts on this? I vaguely remember that some of you proposed a taxon. Can you elaborate why?

[fthobe]

We do not use taxons for properties like size or color either. (Although you definitely could). But since you want Brand to be a strong (validated, unique and filtered by) attribute I think it's best to use a "Brand" model.

Full discussion regarding brands and taxons was here:
Brands as Taxons in GA 4 Discussion

I'd underline that I made the same argument you did today, but that no consent could be found on a separate concern. Therfor just to have at least something that works, I'd appreciate going forward with taxons as it seemed back then the consensus that could be reached.

[jarednorman]

Many of the stores we've worked on already have brand taxons. I understand the tree structure isn't usually useful here, but I think in practice this is a reasonable way to handle this data. My worry about this feature overall is that we have a mix of "brand" implementations across our clients; among those that model brands, some do it as a custom model and some do it as a taxon, and I want to minimize churn for existing stores as we add this.

That said, I don't like this solution. I never thought we should add a column to product.

[fthobe]

For the record: the initial discussion
Brands Dicussion inside the GA thred

Many of the stores we've worked on already have brand taxons. I understand the tree structure isn't usually useful here, but I think in practice this is a reasonable way to handle this data. My worry about this feature overall is that we have a mix of "brand" implementations across our clients;

That's interesting! How do those stores implement schema and brands? Do you have examples?

That said, I don't like this solution. I never thought we should add a column to product.

Could you elaborate? It's a quiet common field and all other platforms support it. I saw that pretty much every shop that is not mono brand running solidus spits that value out separately.

[jarednorman]

For the brands that model taxons as brands, the Spree::Product#brand method still returns a taxon, specifically the first taxon within the brand taxonomy that the product is in. Products still have a taxon and this can be used as needed to power the metadata where it's needed. There's no need to modify the schema to make that work.

[fthobe]

Yeah sorry Jared, we see the world differently. I am with Thomas, this should go ideally into an own resource and I am with you on using the taxons is "fine". I am with neither of you not giving this a separate association.

I think this will lead to exactly the same problem as taxons, people entering multiple taxons that won't validate or rank as good as they can for the purpose of having saved an association here.

We will go in our system for a separate association as proposed, if you don't want to follow us on that, that's fine, we will just not be able to provide anything around it upstream > brands on schema for example or brand related features on promotions.

[fthobe]

I'd like to have this either as a virtual ressource with a separate endpoint as Taxon literally ignoring the nestings with two APIs:

As a taxon

• one /brands/ api to create / edit taxons in the brands taxonomy
• a separate association for brands

As a concern

• separate resource fully isolated from taxons
• again with an association as proposed here

Given that we decided for taxons we have build an entire functionality in other extensions around this, throwing this overboard would mean rewrite significant amounts.

We will for the above cited outcome variability not go your route, which means also not be able to contribute a restored Feeds and frontend with Full schema.

Decision is fully up to you, I do not see how i can Support your approach.

[jarednorman]

I'm not opposed to making this a separate model with its own association.

[fthobe]

I'm not opposed to making this a separate model with its own association.

Can we live with the current proposal for a limited time @jarednorman
I can live with that and make it a concern. How about you @kennyadsl ?