From chaos to clarity. Using Akeneo & BigCommerce to tame complex product data.

Many businesses we work with are trying to solve the same problem: How do you scale product data without losing control of it?

Platforms like BigCommerce are excellent at delivering fast, flexible storefronts and handling the transactional side of commerce. But as product data becomes more complex, with richer metadata, relationships and channel-specific variations, these platforms start to show their limits.

You can extend them with custom fields and workarounds, but they are not designed to be the primary home for complex product information. That’s where a dedicated PIM comes in. Akeneo fills that gap by giving you a structured, governed environment for modelling and managing product data properly, rather than forcing it into a system that was never built for it.

This post explores why Akeneo is so powerful, how we integrate Akeneo with BigCommerce and why its flexibility is both its greatest strength and the reason it needs careful planning.

The challenge of complex product domains

Often, businesses begin with relatively straightforward product data. Over time, however, their catalogues evolve to include items that cannot be expressed through a flat set of attributes. They need structured relationships, multi-level metadata and the ability to describe products in a way that reflect how customers search for and understand them.

Music is a clear example. A single CD or vinyl release can include dozens of interconnected details: contributors such as artists, producers and guest performers, track lists with ordering and timings, edition details, related formats and sometimes links to wider franchises or collections. Attempting to manage all of this within a commerce platform alone quickly becomes restrictive. These systems excel at pricing, inventory and order management but are not designed as relational data stores. For instance, BigCommerce allows us to extend SKUs by adding custom fields, but they are simple key-value pairs and do not offer relational associations.

Similarly, a headless CMS such as Storyblok is excellent at presenting product information and giving editors control over page composition, but it is not optimised to act as the system of record for complex product data. From both a content modelling and performance perspective, it should consume structured data, not own it.

This creates a gap for many organisations. They need a central place where their product domain can be modelled properly and maintained with confidence. They need structured workflows, validation, and a single source of truth that can feed multiple channels.

The challenge is not just storing this information, it is maintaining consistency, avoiding duplication and ensuring it can be reused across channels without constant manual intervention. This is the gap Akeneo fills.

Akeneo. The product information powerhouse for BigCommerce

Akeneo is purpose built for managing product information as a first-class concern, rather than as an extension of commerce or content tooling. Its core strength lies in centralising product data, enriching it through structured workflows, and enforcing governance so that quality remains high as catalogues grow and teams can scale.

One of Akeneo’s biggest advantages is the flexibility of its data modelling. Products can be composed using a wide range of attribute types, from simple text and numeric values to references, multi-select attributes and structured tables. This makes it possible to represent complex product information in a way that mirrors the real world, rather than forcing it into flat or repetitive fields. For domains like music, this means contributors, tracks and editions can be modelled cleanly and reused across products without duplication.

Why is Akeneo a good PIM?

Akeneo also handles relational data particularly well. Products can reference other entities, enabling patterns that reflect how customers and editors actually think about products. Instead of embedding the same information repeatedly, relationships can be managed once and reused everywhere they are needed, improving consistency and reducing editorial effort.

Families and attribute sets add another layer of control. They allow teams to define shared structures across large catalogues, ensuring that similar products follow the same rules while still leaving room for variation where required. This balance of structure and flexibility is key when working with thousands of SKUs across multiple product types.

Finally, Akeneo’s support for channels and locales allows the same core product data to be adapted for different markets, storefronts and platforms. Content can be tailored per channel or region without cloning products or fragmenting the catalogue. When paired with platforms such as BigCommerce for transactions and Storyblok for presentation, Akeneo becomes the authoritative source that keeps everything aligned while allowing each system to focus on what it does best.

Flexibility brings power, but also complexity

Akeneo gives teams a high degree of freedom to design product structures that reflect their business domain. This is one of its greatest strengths. Rather than forcing products into rigid templates, Akeneo allows organisations to model their data around how their products actually work, whether that means contributors and track listings, complex ingredient data, regulatory information, or multi layered variants.

What planning is required to set-up a PIM?

However, that flexibility comes with responsibility. Without careful planning, product models can become inconsistent, overly complicated and difficult to evolve. Attributes added reactively, relationships introduced without consistency, or families that overlap in purpose can all create long term maintenance challenges. Akeneo does not impose a fixed structure, which means the quality of the outcome depends heavily on the decisions made early on.

There is an inherent trade off at play:

Flexibility

• Highly customisable product schemas tailored to specific business needs
• Supports deep relational modelling and rich, structured content
• Adapts well to complex and non-standard sectors such as entertainment, publishing, food, health and regulated industries

Complexity

• Requires strong governance and upfront data modelling workshops
• Product owners and data stewards need clear editorial workflows and ownership
• Integrations must be carefully mapped into commerce and CMS platforms

At Ridgeway, we approach this by treating Akeneo as a core architectural component rather than just another system. We run structured discovery and modelling sessions, define product schemas with intent, and put clear boundaries in place around what belongs in the PIM. This ensures Akeneo remains a powerful source of truth, rather than becoming a dumping ground for uncontrolled fields and one-off requirements.

Why Akeneo is our go to tool for BigCommerce

Within Ridgeway’s composable commerce architecture, Akeneo acts as the single source of truth for product content and relationships. It is where product structures are defined, enriched and governed, ensuring consistency across every channel that consumes product data.

How can Ridgeway deal with complexity?

BigCommerce is treated as the transactional backbone of a composable commerce architecture. It owns SKUs, pricing, stock, promotions and checkout behaviour. This clear separation allows BigCommerce to remain focused on commerce, while Akeneo manages the complexity of product information and relationships.

For content driven storefronts, Ridgeway layers in Storyblok as the presentation and editorial CMS. Product detail pages in Storyblok use a product selector field to reference a BigCommerce product. Editors manage all additional editorial content, such as descriptions, marketing copy, supporting imagery and contextual content, directly within Storyblok, without duplicating core product data.

At runtime, when a product page is rendered, the selected SKU is resolved through BigCommerce for transactional data and in parallel looked up in Akeneo, either directly or via a lightweight middleware layer such as Supabase. This enrichment step allows structured product metadata, relational information and domain specific data to be injected into the page alongside commerce data.

For complex domains like music, this approach is particularly effective. Contributor data, track listings and structured metadata are modelled in Akeneo and exposed through a well defined schema, while BigCommerce supplies pricing and availability. Storyblok brings these streams together, allowing the front end to render rich, expressive product pages without forcing complex relational data into the commerce layer.

Real world example: Music catalogues

As previously mentioned, Music catalogues highlight why a composable approach to product data works so well. Products such as CDs, vinyl and box sets rarely fit into a simple attribute model. They are defined by rich relationships and structured metadata that need to be accurate, ordered and reusable across formats and editions. 

A single release may include detailed track listings with explicit ordering, durations and optional bonus content. It will often reference multiple contributors, each fulfilling different roles such as primary artist, featured performer, producer or composer. Products are also commonly linked across formats and editions, including reissues, deluxe versions, bundles and box sets that group multiple products together.

Akeneo allows all of this to be modelled in a single, consistent structure, with contributors and track data managed as structured relationships rather than flattened fields. Enrichment workflows ensure that releases meet defined quality standards before they are made available to downstream systems.

BigCommerce then provides the transactional layer, supplying SKUs, pricing and availability. Product pages are constructed in Storyblok, where editors select the relevant product and add supporting editorial content. At runtime, the SKU is resolved through BigCommerce and enriched with structured data from Akeneo, either directly or via a middleware layer such as Supabase.

By separating concerns in this way, Ridgeway can stitch together rich product data, transactional accuracy and editorial flexibility into a seamless experience. Complex music metadata is handled where it belongs, while the storefront remains maintainable and easy to evolve.

Akeneo as a foundation for AI-driven commerce

As commerce continues to evolve, the role of structured product data is becoming even more critical. AI-driven experiences, whether that is intelligent search, recommendations, automated content generation or emerging agentic workflows, rely heavily on well modelled, high-quality data.

Akeneo provides a strong foundation for this. Its structured attributes, relationships and governed workflows create a dataset that looks much more like a knowledge graph than a flat product catalogue. This makes it significantly easier to power AI use cases that depend on understanding how products relate to one another.

What can Akeneo AI do?

For example, relational data such as contributors, product hierarchies or related items can be used to drive more meaningful recommendations. Structured attributes and completeness rules ensure that AI models are working with consistent and reliable inputs rather than fragmented or incomplete data. There is also a growing opportunity around automated enrichment. With the right guardrails in place, AI can assist with generating descriptions, classifying products or suggesting relationships, but this only works when the underlying data model is well defined. Without that structure, automation quickly becomes inconsistent or unreliable.

Looking ahead, as agentic commerce begins to emerge, where systems can reason about products and make decisions on behalf of users, the importance of structured, relational product data will only increase. In that context, Akeneo is not just a PIM, it becomes part of the foundation that enables those capabilities.

Are Akeneo & BigCommerce right fit for you?

The outcome of this approach is a scalable and maintainable source of truth for product information that can support business now, and into the future as their product offering grows in size and complexity.

Product launches become faster because editors work within a single, well-defined environment rather than duplicating effort across systems. Integrations remain cleaner and easier to maintain, as each platform plays to its strengths rather than being stretched beyond its intended purpose.

Most importantly, this architecture provides a future proof foundation for composable commerce. As new markets, channels or platforms are introduced, product data can be adapted and distributed without reworking the entire stack, allowing businesses to evolve without sacrificing stability.

In future posts, we’ll be exploring how this kind of structured product data can be used to support AI-driven enrichment, search and emerging agentic commerce patterns, and why the quality of your product model is likely to become a competitive advantage.

If your team is wrestling with complex product data, get in touch with us to discuss how we can support your next digital project.