Chapter 3: The Architecture of the Catalogue
The Runner, the Template, and the Documentary
A customer types “running shoes for flat feet” into a search bar. The query is specific, the intent clear. The ecommerce site returns a grid of forty-three products. The customer clicks the first result, a shoe with a 4.3-star rating and a price within the expected range. The product page loads with a carousel of images, a size selector, and a block of text describing the mesh upper and the cushioned midsole. Below the add-to-cart button, a section titled “You Might Also Like” displays three items: a pair of running shorts, a generic water bottle, and a different shoe from the same brand. The customer glances at the recommendations and feels a faint, familiar disappointment. The suggestions are not wrong in a categorical sense — runners do wear shorts and carry water bottles — but they have nothing to do with the reason the customer searched for that specific shoe. The flat-footed runner needs stability, arch support, a particular kind of insole. The recommendation engine, blind to these attributes, has defaulted to the broadest possible association: people who buy running shoes might also like running accessories. The cross-sell opportunity collapses into irrelevance.
Now imagine a different sequence. The same customer lands on a product page for a stability running shoe. The page describes the shoe’s medial post, its firm heel counter, its compatibility with custom orthotics. Below the description, a recommendation card reads: “Runners who chose this shoe for overpronation also use these insoles.” The card shows three insole models, each with a firmness rating and an arch height specification. The customer, recognizing the language of their own condition, clicks the middle insole. The cross-sell has not interrupted the shopping experience. It has extended it, using the same vocabulary that brought the customer to the page in the first place. The difference between the two scenes is not the sophistication of the recommendation algorithm. It is the granularity of the product data that feeds the algorithm. The first site knows the product is a shoe. The second site knows what kind of shoe, for what kind of foot, with what kind of biomechanical problem in mind. That knowledge makes the upsell possible.
The principle extends beyond physical goods. A software user signs up for a project management tool and creates a new board. The tool suggests a template for a marketing campaign, because the user selected “Marketing” as their department during signup. The template contains pre-built columns for content calendar, asset review, and campaign launch. It feels helpful, tailored, almost prescient. The user adopts it and, a week later, hits the free plan’s limit of ten boards. The upgrade prompt appears, and it is not a generic “Unlock more features.” It is a specific invitation: “Upgrade to the Business plan to create unlimited marketing boards and get advanced campaign reporting.” The upsell offer is relevant because the system knows what the user is doing. And it knows what the user is doing because the template data — the fact that this board type is “marketing campaign” and not just “project” — was encoded as a structured attribute from the start.
A final scene, drawn from a different domain. A viewer finishes a documentary on a streaming platform. The credits roll, and the platform immediately queues up a romantic comedy. The viewer, still mentally processing the documentary’s investigation of corporate malfeasance, feels a jarring tonal shift. The recommendation is not random — the platform’s collaborative filtering model has detected that viewers who watched this documentary also watched that romantic comedy — but it is contextually absurd. The viewer does not want to laugh. They want to stay in the headspace of the documentary. A platform that understood its content not just as “titles” but as structured clusters of attributes — mood, pace, subject matter, narrative style — might instead suggest another investigative piece, perhaps on a related topic, keeping the viewer engaged and inside the ecosystem. The absence of that granularity is the absence of an upsell that would have been welcomed.
These scenes share a common root. The relevance of any recommendation, upsell, or cross-sell depends entirely on the quality of the data that describes the things being recommended. When the data is thin — a product name, a category, a price — the offers that emerge are generic. When the data is rich — a web of attributes that captures use cases, compatibility, conditions, and outcomes — the offers become specific, and specificity is the foundation of conversion. This chapter examines that foundation. It asks what it takes to build a product catalogue that can support precise upsells, and it traces how two companies, Zappos and Netflix, invested in data granularity long before it became a competitive necessity.
When the Catalogue Thinks in Attributes
A product catalogue is not a list of items for sale. It is a database that represents real-world objects in a form a machine can query, compare, and combine. The quality of that database determines the ceiling of every system built on top of it: the search engine, the recommendation module, the upsell logic, the email personalization engine. When the database is thin, the systems produce thin results. When the database is rich, the systems can produce results that feel attentive, even intelligent. The difference between thin and rich is data granularity.
Data granularity refers to the level of detail at which information is captured and stored. A catalogue with low granularity might describe a shoe with five fields: name, brand, color, size, and price. A catalogue with high granularity might describe the same shoe with forty fields: the five basic ones, plus sole type, heel-to-toe drop, arch support level, pronation control, upper material, closure type, weight in grams, intended terrain, waterproof rating, and so on. The first catalogue can answer the question “Do you have blue shoes in size ten?” The second can answer “Do you have a stability shoe for overpronators with a wide toe box and a rocker sole, suitable for marathon training on pavement?” The difference is not academic. It is the difference between a cross-sell that recommends a water bottle and a cross-sell that recommends an insole engineered for a specific gait pattern.
The mechanism through which granularity enables upsells has three layers. The first layer is attribute-based filtering. When a customer interacts with a product — viewing it, adding it to cart, purchasing it — the system can read that product’s attributes and search for other products that share relevant attributes. If a runner buys a shoe with the attribute “stability: high” and “arch: low,” an attribute-based filter can retrieve insoles, socks, or second-pair shoes that match those constraints. The filter does not need purchase history from thousands of other customers. It only needs the attributes of the current product and the attributes of the candidate recommendations. This makes attribute-based filtering extraordinarily powerful in cold-start scenarios — situations where the system has little to no user interaction data. A new product, a new customer, a niche category: all of these pose cold-start problems that collaborative filtering, which relies on patterns of collective behavior, cannot solve. Attribute-based filtering, by contrast, works from day one, as long as the attributes are populated.
Research published in IEEE journals on recommendation systems consistently demonstrates that hybrid approaches combining attribute-based and collaborative filtering outperform pure collaborative models, especially in domains with long-tail catalogues and diverse user needs. An article in IEEE Transactions on Knowledge and Data Engineering (2019) showed that attribute-based recommendations maintain relevance even when user-item interaction matrices are sparse, because they anchor recommendations in product properties rather than behavioral patterns. For an ecommerce business, this means that the investment in catalogue granularity pays off most visibly in the edges of the catalogue — the obscure products, the new arrivals, the niche categories — where behavioral data is thin but attribute data can be rich from the moment of listing.
The second layer is semantic relevance. A recommendation that shares multiple attributes with the purchased product feels coherent to the customer. It makes intuitive sense. The runner who just bought a stability shoe sees an insole for overpronation and immediately understands the logic of the suggestion. The coherence reduces the cognitive effort required to evaluate the offer, which, as discussed in previous chapters, increases the likelihood of acceptance. Semantic relevance is not just about matching attributes; it is about matching attributes that matter to the customer’s specific use case. A shoe’s color is an attribute, but for the runner with flat feet, the arch support attribute matters more. A catalogue with high granularity allows the recommendation engine to weight attributes by their relevance to the context — signaled by the customer’s search query, the product description they spent time reading, or the filters they applied during browsing. The same shoe, presented to a fashion-conscious customer, might trigger a cross-sell based on color and style. Presented to an injury-prone runner, it triggers a cross-sell based on biomechanics. The catalogue does not change. The attribute weights do.
The third layer is the internal operability of the business. A catalogue with deep, structured attributes is not just a tool for customer-facing recommendations. It is a tool for the merchandising team, the buying team, and the marketing team. The merchandising team can use attributes to identify gaps in the assortment: “We have fifty running shoes but only two with a wide toe box and a rocker sole — that is an underserved segment.” The buying team can use attributes to brief suppliers with precision, reducing the rate of returns caused by mismatched expectations. The marketing team can use attributes to build audience segments and trigger automated campaigns: “Customers who bought shoes with waterproof rating above IPX4 and intended terrain: trail should receive an email about our new range of trail-running socks.” The upsell, in this view, is not a standalone tactic. It is one output of a data infrastructure that makes the entire business more intelligent about its products.
The cold-start problem deserves a deeper look because it is the moment when granularity proves its worth most dramatically. A new ecommerce site launches with five hundred products. It has no customer purchase history. It has no browsing data. A pure collaborative filtering system — “people who bought this also bought that” — has nothing to work with. The recommendations it produces are either nonexistent or, worse, random. The site’s upsell modules sit empty or display best-sellers that have no relationship to the product being viewed. The customer experience feels hollow. An attribute-based system, by contrast, can generate relevant recommendations from the first visitor. When that visitor lands on the product page for a cast-iron skillet, the system reads the attributes — material: cast iron, diameter: 10 inches, compatible cooktop: all, maintenance: requires seasoning — and retrieves other products that share those attributes: a chainmail scrubber for cast iron, a silicone handle cover, a seasoning wax. Each of these is a cross-sell opportunity that would not exist without the attributes. The cold-start problem disappears for the customer, even if it persists for the collaborative model, because the customer never sees the collaborative model. They see the attribute model, which is already warm.
The upfront cost of this granularity is real. Someone has to define the attributes, create the taxonomy, train the data entry team, and populate the fields for every product. For a catalogue of five hundred SKUs, this is a manageable project. For a catalogue of fifty thousand, it is a significant undertaking. The investment, however, compounds. Every future system that touches the catalogue — the site search, the faceted navigation, the recommendation engine, the email personalization — becomes more effective. The cost of not making the investment is harder to see but larger: every generic upsell that is ignored, every abandoned search that returns no results because the filters are too coarse, every customer who leaves the site without finding the complementary product that would have made the original purchase complete. These are not line items on a profit-and-loss statement, but they are real.
The next section examines Zappos, a company that built its reputation on the depth of its catalogue data, and Netflix, which invested in a granular content taxonomy to keep viewers engaged. Together, they demonstrate that the architecture of the catalogue is not a back-office concern. It is a front-line revenue driver.
Zappos’ Forty Fields and Netflix’s 70,000 Micro‑Genres
Zappos began, as many enduring internet companies do, with a simple observation dressed as a complaint. In the late 1990s, Nick Swinmurn, the company’s founder, walked through a mall searching for a specific pair of shoes in a specific color and size and found nothing. The physical retail model, with its shelf-space constraints, could never stock every variation a customer might want. The online model, in theory, could. But merely listing thousands of shoes on a website would not solve the deeper problem. The deeper problem was that shoes are not interchangeable commodities. A running shoe is not just a shoe; it is a biomechanical device with properties that interact with the wearer’s anatomy. A dress shoe is not just a fashion item; it is a structure with heel heights, toe box shapes, and materials that determine whether the wearer can stand for three hours without pain. A customer who buys the wrong shoe online — a shoe that looks right in the photograph but fits wrong on the foot — returns it. And return rates in online shoe retail, in the early 2000s, were punishingly high, often exceeding thirty percent. Each return erased not only the sale but the margin on several successful sales. The economics of online shoe retailing looked like a leaky bucket. Zappos decided to patch the bucket not with better photos or more aggressive discounts, but with better data.
The company invested in building what was, at the time, one of the most granular product catalogues in all of ecommerce. For every pair of shoes, Zappos captured over forty distinct attributes. These went far beyond the obvious: brand, size, color, price. The attribute schema included heel height measured in inches, platform height, shaft circumference for boots, arch support type, pronation control (neutral, stability, motion control), closure type (lace, buckle, slip-on, Velcro), upper material, lining material, insole type, outsole material, weight in ounces, waterproof rating, intended terrain for outdoor shoes, toe box width classification, and many others. The team physically measured shoes, verified materials, and cross-referenced manufacturer specifications with internal quality checks. This was not a one-time data entry exercise. It was a continuous operational process embedded in the merchandising workflow. Every new product that entered the warehouse was accompanied by a data sheet that had to be completed before the product went live on the site. As a result, the catalogue became a living, structured repository of physical reality, not a mere inventory list.
The immediate application of this granularity was faceted search and navigation. A customer could filter the entire shoe catalogue not just by size and color, but by attributes that corresponded to their personal needs. A runner with plantar fasciitis could filter for shoes with “arch support: high” and “cushioning: maximum.” A nurse who stood for twelve-hour shifts could filter for “closure: slip-on” and “heel height: low” and “weight: under 10 ounces.” This level of precision reduced the cognitive burden of scanning hundreds of undifferentiated products. More importantly, it increased the probability that the shoe the customer eventually purchased would perform as expected, which in turn reduced the probability of a return. Zappos never published a controlled experiment isolating the exact return-rate reduction attributable to attribute granularity alone — too many variables changed simultaneously as the company grew — but industry analysts and case studies consistently pointed to the catalogue architecture as a foundational element of Zappos’ ability to achieve return rates significantly below the online shoe retail average.
The upsell implications of this architecture were not an afterthought. They were embedded in the same data layer. When a customer viewed a specific shoe, the recommendation engine — which at Zappos was a combination of attribute-based rules and collaborative filtering — could retrieve products that matched on the attributes most likely to be relevant to that customer’s inferred context. A customer viewing a stability running shoe with a firm medial post and a straight last would see recommendations for insoles designed for overpronation, socks with arch compression, and a second pair of shoes with similar biomechanical profiles for cross-training. The recommendations made sense because they were anchored in the same attribute vocabulary that had guided the original search. The cross-sell conversion rates on these attribute-grounded recommendations were, according to former Zappos product team members speaking at industry events such as Shop.org and IRCE (Internet Retailer Conference and Exhibition) in the mid-2010s, multiples of what generic “you might also like” modules achieved on comparable sites. Zappos did not publicize precise figures, but the directional evidence was strong enough that the company’s catalogue architecture became a standard case study in ecommerce education, cited in publications ranging from Practical Ecommerce to Harvard Business School case notes on digital retail operations.
The Zappos case illustrates a broader point about the relationship between catalogue architecture and upsell performance. The upsell is not a separate system that can be optimized independently. It is a downstream output of the product data model. If the data model captures the attributes that matter to customers — the attributes they use to describe their own needs — then the upsell engine has the raw material it needs to construct relevant offers. If the data model is thin, no amount of algorithmic sophistication can compensate. A deep learning model trained on five attributes will still produce generic recommendations, because the signal simply is not there to extract. The investment must happen at the data layer first.
The second case, drawn from the domain of digital media rather than physical retail, extends the principle from products to content. Netflix, the streaming service, does not sell shoes. But it faces a structurally identical problem: how to keep a subscriber engaged by presenting them with content they want to watch next. The company’s early recommendation engine relied heavily on collaborative filtering — “people who watched X also watched Y” — and on star ratings. These methods worked adequately, but they suffered from a known weakness. They were good at surfacing popular, broadly appealing titles, but they struggled with niche interests, cold-start titles, and the subtle dimensions of taste that separate a viewer who likes “quirky romantic comedies with strong female leads” from a viewer who likes “romantic comedies set in New York.” The difference between those two viewers is the difference between a successful upsell of attention — a recommendation that keeps the viewer watching — and a failed one that prompts them to close the app.
To address this, Netflix invested heavily in a content taxonomy of extraordinary granularity. The company’s so-called “micro-genre” system, described in detail by Alexis C. Madrigal in a 2014 article for The Atlantic based on an analysis of Netflix’s public interface, comprises over 70,000 distinct categories. These are not just “Action” and “Comedy.” They are combinations of attributes: mood, tone, setting, protagonist characteristics, narrative structure, time period, pace, and dozens of other dimensions. A title is tagged with multiple such attributes, creating a rich vector that captures not just what the title is about, but how it feels to watch it. A single film might be tagged with “cerebral,” “dystopian,” “slow-burn,” “anti-hero,” and “nonlinear narrative.” The recommendation system can then match these attribute vectors against a viewer’s inferred preferences — derived from their viewing history — and surface content that aligns on multiple subtle dimensions simultaneously.
The result is a recommendation experience that feels almost unnervingly accurate, and that accuracy is the engine of Netflix’s retention. The company has reported in quarterly earnings letters and investor communications that effective recommendations reduce churn and increase viewing hours, although it does not disclose the exact marginal contribution of micro-genres versus other factors. What is publicly known, from presentations by Netflix engineers at academic conferences like RecSys, is that the content taxonomy is a critical input to the recommendation models, and that models incorporating deep content attributes consistently outperform those that rely solely on user behavior patterns. In a 2015 blog post on the Netflix TechBlog, engineers explained that the company’s “similarity algorithms” incorporate metadata such as genres, maturity ratings, and release years to improve personalization. The 70,000 micro-genre taxonomy, though partially automated, requires a substantial human tagging effort, a cost Netflix has been willing to bear for over a decade because the return — measured in subscriber lifetime value — justifies the investment many times over.
The Netflix case reinforces the Zappos lesson with a different category of inventory. Whether the “products” are physical shoes or digital films, the structural requirement is the same. An upsell — whether of a complementary product or of the next piece of content — is only as precise as the attributes that describe the items in the catalogue. Granularity is not a luxury reserved for companies with millions of SKUs. It is a competitive necessity for any business that wants its recommendations to earn attention rather than waste it.
The Schema That Grows with the Business
The Zappos and Netflix cases sit in different industries, serve different customer needs, and operate with different inventory types — physical goods versus digital content. Yet the structural logic that connects them is precise enough to be expressed in a single sentence: the quality of an upsell is bounded by the granularity of the catalogue that feeds it. No recommendation algorithm, regardless of its mathematical elegance, can compensate for a product database that describes a shoe as just a shoe. The data layer is the foundation, and the foundation sets the ceiling.
This principle, like the timing principle in Chapter 1 and the naming principle in Chapter 2, is not confined to the large-scale enterprises that serve as the primary cases. It translates across business types, scales, and sectors with a common set of implementation patterns. The translation requires understanding what attributes matter to the customer in each context, how those attributes can be captured at reasonable cost, and how they can be wired into the upsell machinery. The following three applications — a small direct-to-consumer brand, a B2B industrial supplier, and a two-sided service platform — illustrate how the logic adapts.
Consider a small ecommerce brand selling specialty coffee beans. The product count might be thirty or forty SKUs — tiny by the standards of Zappos. The temptation is to treat the catalogue lightly: a product name, a roast level, a price, a photo of the bag. Under that thin schema, the site’s recommendation module can only suggest “other dark roasts” or “coffees from the same region.” That is not useless, but it misses the dimensions that genuinely drive a coffee enthusiast’s purchasing. A customer who buys a single-origin Ethiopian with tasting notes of blueberry and jasmine is expressing a preference for bright, fruity profiles, not just for African geography. If the catalogue captures origin, processing method, varietal, altitude, roast level, and a structured tasting-notes vocabulary, the upsell engine can connect that Ethiopian to a Kenyan with similar brightness, or to a washed Colombian with a complementary body. The recommendation that says “If you loved the blueberry notes in this Ethiopian, try this Kenyan with blackcurrant” is far more likely to convert than “Other customers also bought a French roast.” The extra attributes — processing method, varietal, specific flavor tags — cost nearly nothing to assign at the point of product setup. For a thirty-SKU catalogue, the total data entry burden is measured in hours. The return is a recommendation layer that sounds like a knowledgeable barista rather than a random product grid.
The cold-start problem is particularly relevant here. Small brands often launch with no customer purchase history, no browsing trails, no collaborative filtering signal of any kind. Attribute-grounded recommendations are the only way to make the site feel alive from day one. A visitor to a brand-new coffee site who lands on a product page expects to see something that relates to that product. If the only content in the recommendation slot is a generic “best sellers” list, the site feels hollow. If the slot shows coffees with matching flavor profiles, the site feels curated. The difference is not algorithmic wizardry; it is pre-existing attribute data that the collaborative model would take months of accumulated transactions to approximate. In this sense, data granularity is not just a long-term competitive advantage. It is a short-term survival tactic for new entrants who must deliver relevance before they have audiences.
For a B2B industrial supplier, the scale and complexity are larger, but the logic holds. A distributor of fasteners — bolts, screws, nuts, washers — might carry fifty thousand SKUs. A purchasing manager from a construction firm visits the site looking for a specific bolt: M10, 1.5mm thread pitch, 50mm length, stainless steel 304, hex head, partial thread. This is not a whimsical search. It is a procurement requirement with zero tolerance for ambiguity. The catalogue that captures all those attributes can immediately present cross-sell offers that are genuinely useful: matching nuts with the same thread specification, washers of the correct size and material, a thread-locking compound rated for stainless steel. The catalogue that captures only “bolt, M10, stainless” cannot make those associations. Its cross-sell module will suggest generic categories — “more fasteners” — that the purchasing manager will ignore. In B2B, the cost of irrelevance is not just a lost upsell. It is a signal that the supplier does not understand the customer’s operational reality, which erodes trust and can cost the primary sale as well. The attribute schema in this context must align with the procurement vocabulary of the customer. That vocabulary includes thread standards (metric vs. imperial), material grades (A2, A4, 304, 316), head types, drive types, and compliance certifications. Capturing these attributes is labor-intensive at fifty thousand SKUs, but the alternative — a catalogue that cannot answer the questions its customers are asking — is a structural weakness that no marketing campaign can hide.
A key lesson from both the small DTC and the large B2B environments is that the attribute schema should be designed outward from the customer’s search and selection criteria, not inward from the supplier’s inventory categories. A supplier of fasteners might internally classify products by warehouse bin location or by manufacturer part number. Those are important for operations, but they are not the attributes that matter for upsells. The upsell attributes are those that define how the product is used, what it connects to, what problem it solves. Designing the schema from the customer’s perspective means asking: when a customer describes what they need, what words do they use? What dimensions do they care about? What would make a recommendation feel like it was selected by someone who knows their job? The answers to those questions become the attribute fields.
The third context, a two-sided service platform, adds a layer of complexity because the “products” are not physical items but services performed by humans. A platform that connects patients with therapists, for instance, does not have SKUs in the traditional sense. But it does have a catalogue of providers, and each provider has attributes: therapeutic modality (CBT, psychodynamic, EMDR), areas of specialization (anxiety, trauma, relationships), session format (video, phone, in-person), language spoken, insurance accepted, years of experience, gender, and even more subjective attributes like therapeutic style (directive, exploratory, structured). A patient who completes a session with a therapist and reports a positive experience is a candidate for an upsell — perhaps a package of sessions at a discounted rate, a group workshop led by the same therapist on a relevant topic, or a recommendation to try a different modality with another therapist who shares the same specialization. The platform’s ability to make that upsell relevant depends entirely on the granularity of the therapist profiles. If the platform only records “therapist, anxiety, $100/session,” the upsell options are limited to “book another session with this therapist or a different one.” If the platform records a dozen attributes per therapist, it can construct precise, context-aware offers: “Patients who worked with a CBT therapist for anxiety also found mindfulness-based stress reduction groups helpful — here is one led by a therapist in your city.” The upsell crosses the line from commercial offer to genuine service enhancement, which is exactly where the highest conversion rates live.
The operational implication for any business, regardless of scale, is that catalogue architecture is not a one-time project. It is a living discipline. As new products are added, the attribute schema must be applied consistently. As customer needs evolve, the schema itself must be extended to capture new dimensions of relevance. Netflix’s micro-genre taxonomy did not arrive fully formed. It grew iteratively over years, as data scientists and content taggers identified new axes of viewer preference and added them to the tagging vocabulary. Zappos added attributes as shoe technology advanced — new sole materials, new closure systems, new sustainability certifications. The catalogue is a model of the business’s understanding of its own products and its customers’ worlds. When that model is rich and well-maintained, the upsell systems that feed on it produce results that feel like intelligence. When the model is thin and neglected, the same systems produce results that feel like noise. The choice is not between having a catalogue and not having one. It is between a catalogue that enables precision and a catalogue that guarantees mediocrity.
Are You Describing Products or Answering Questions?
For the small business owner, the diagnostic question is uncomfortable in its simplicity: if you were handed your product catalogue — every field, every attribute, every tag — and told to find a complementary product for a specific customer using only that data, would you succeed? More concretely, pick a product in your catalogue. Examine its data record. List every attribute that is captured in a structured, queryable field. Now imagine a customer who has just bought that product. What else could they need? If the answer involves an attribute that is not in the catalogue, that missing attribute is a lost upsell opportunity. The practical step, achievable in an afternoon, is to take ten products and write down the questions a customer might have after purchasing them — questions about compatibility, about alternatives, about next-step purchases. Then check whether the catalogue contains the data that would answer those questions. The gaps will be visible almost immediately, and populating the most critical missing attributes for the top-selling products can begin the same week.
The second question for the business owner is about process: when a new product is added to the catalogue, does the data entry workflow force the team to complete a set of structured attribute fields before the product goes live? Or does the product go live with a name, a price, and a photo, and the rest is added later — or never? The discipline of mandatory attribute completion is unglamorous, but it is the difference between a catalogue that supports upsells and a catalogue that undermines them. Implementing a simple checklist — even a spreadsheet — that must be marked complete before a product is published can shift the trajectory of the entire recommendation layer.
For the consultant or strategist, the questions delve into the design of the attribute schema itself. First, when auditing a client’s catalogue, how do you distinguish between attributes that are nice-to-have and attributes that are essential for upsell relevance? One method is to analyze the search queries that currently yield zero results or that users refine multiple times. These queries often contain attribute terms — “waterproof,” “lightweight,” “compatible with X” — that are not captured as structured fields. By identifying the most frequent high-intent queries that the catalogue cannot answer, the consultant can prioritize the attributes that will unlock the most immediate revenue impact. The second question concerns the tension between completeness and maintainability. A small team cannot populate forty attributes per product on a catalogue of ten thousand SKUs. What is the minimum viable attribute schema for the client’s specific category, and how can the consultant design a data collection process that sources attribute values from suppliers, manufacturers, or even customers (via structured reviews) rather than relying solely on internal manual entry? This is an operational design problem as much as a data problem, and it calls for a solution that fits the client’s organizational capacity.
The one-week implication for a reader who wants to act immediately is this: audit five top-selling products and five underperforming products. For the top sellers, identify the attributes that the product pages currently highlight — these are often in the product description prose but not in structured fields. Create those structured fields and populate them for the top sellers. Then, check whether the site’s recommendation logic can use those new fields to generate at least one specific, relevant cross-sell per product. For the underperforming products, check whether they have fewer structured attributes than the top sellers. If they do, the thin data may be suppressing their visibility and their ability to appear in upsell slots. Populate the same attribute fields for those products as well. The time investment is a few hours of spreadsheet work and CMS configuration. The outcome is a measurable improvement in the coherence of the recommendations, which, if the Zappos and Netflix cases are any guide, compounds over time as more products receive the same treatment. The architecture of the catalogue is not a technical debt to be paid down later. It is an income-generating asset that appreciates with every attribute added.