A sales and benefit platform with a 12,000 SKU catalogue and four payment models

The situation

Trippi sells bikes, e-bikes and cycling accessories. The catalog comes from four distributors, each describing the same gear differently - different naming, different units, different levels of detail. Together that's over 22,000 products.

Not all of it is meant to be sold. Part of the suppliers' offer sits outside what Trippi wants to trade in - brands that don't fit the store's positioning, products with no margin, end-of-series leftovers, categories the competition covers better. The target catalog is 12,000 SKUs picked out of those 22,000.

Before the project, the entire pool landed in the shop exactly as the supplier sent it. Categories mirrored distributor price lists rather than the way buyers search. Filters came from a generic ecommerce setup - one set for the entire store, the same for a bike and for a helmet. Some products existed under several name variants, others had no attributes. Connecting a new supplier took 2-3 weeks of developer work.

The Trippi homepage - layout, categories and filters made for selling bikes and accessories.

Scope

• A catalogue of about 12,000 items from many suppliers, with a unified category tree and shared attributes
• Offer page
• An availability enquiry form routed to the Trippi team responsible for the offer
• Basket and orders
• Google sign-in (SSO, OAuth2)
• User roles: user, backoffice admin, backoffice user
• After signing in: current sales, B2B companies, partner invitations
• Content migration from the previous WordPress site, keeping URLs (301 redirects) and SEO metadata

Straightening out the catalog

The first step was getting 22,000 records into a state where they can be shown in the store, and picking the 12,000 SKUs.

• Assortment rules - what enters the store from a supplier's pool and what gets rejected, defined per supplier, brand and category instead of product by product
• Deduplicating products carried by several suppliers - one model is one product page instead of three near-identical ones
• One naming convention for brands and models instead of four ways of spelling the same manufacturer
• Separating what is a variant (frame size, color) from what is a separate product
• Flagging products missing photos, descriptions or attributes required by their type - as a to-do list for the catalog team instead of publishing products with gaps

Product schema and attributes

An e-bike, a kids' bike, a helmet and a lock are four different product types and don't share a set of properties. We set up product schemas - each type has its own defined attributes, types and units, and the system enforces what has to be filled in before publishing.

As a result battery capacity is always a number in watt-hours, wheel size is always in inches, and drivetrain is always written one way - no matter which of the four suppliers sent the product. Filters, sorting and price-comparison feeds are built on these attributes.

Wheel size, frame material, drivetrain, brakes - attributes reduced to one convention across all suppliers. The counts are catalog coverage.

Category tree

The category tree follows the contents of the catalog. We went through all 22,000 supplier products to see what the pool contains and how much of it there is. We built the structure around the 12,000 SKUs that go on sale and around how buyers name what they're looking for.

The "Electric" category leads on to city, trekking, mountain, road and gravel, cargo and SUV bikes. In accessories the branches are helmets, shoes, locks, bags and bottles. Every branch shows its product count. No category is empty.

The "Electric" listing - 1,368 products split into subcategories that match how people shop for a bike.

Per-category filters

Filters are assigned to categories instead of to the whole store. In electric bikes, buyers filter by brand, wheel and frame size, frame material, drivetrain, brakes and battery capacity. In accessories the set is entirely different - the one that fits that group of products.

Filter values come straight from attributes, so a filter with no backing data can't be published. Every value shows its product count, and a filter with no results doesn't appear.

Same mechanics, different category - accessories have no frame size or drivetrain, because those properties don't exist for these products.

Supplier integrations and data normalization

Four data sources are connected through a single integration layer. Each supplier runs its own flow, but the storefront and the admin see one catalog. Data from every source is brought to one standard at import time. Adding a new supplier now takes 2-3 days instead of 2-3 weeks.

What changed for the business

• The 12,000 SKU catalog can be browsed - buyers reach a product through categories and filters, even when they don't know the model name
• The store shows what Trippi wants to sell - 12,000 SKUs selected from the 22,000 available at suppliers, by rules that can be changed without a developer
• Filters match the contents of the category - instead of one set for the whole store
• New supplier onboarding from 2-3 weeks to 2-3 days - Trippi adds brands without a long IT phase
• Consistent product data across suppliers - one model, one product page, one set of units, one description standard
• Zero license cost - the whole store runs on open-source Lunar PHP, on their own server