How to Prepare Your Product Catalog for AI Shopping Agents

Start with the buying decision your catalog needs to support. Then make sure the relevant facts have a consistent meaning, a reliable source, the correct product identity, and a route to the system that will use them. Adding more generated descriptions won't fix a missing specification or a measurement assigned to the wrong variant. A practical test for deciding what work to automate also helps establish whether the recurring work is stable and valuable enough to change.

Algolia's October 6, 2026 Velou acquisition announcement provides the news trigger for this guide. The practical work below is a proposed catalog-preparation method, not a demonstration of Velou or a report of results Rise Productive measured. You can use the method to scope a pilot with your current tools before committing to a larger product-data project.

For the event analysis behind the announcement, see analysis of Algolia acquiring Velou and the product-data question behind AI shopping.

For a retailer, the outcome is a clearer product record. For an agency, it's a deliverable a client can inspect: a defined buyer question, a supported set of attributes, and an evaluation that shows whether the record helps answer that question. The work begins with a bounded sample rather than a promise to transform every product at once.

A small initial scope makes the audit easier to understand. Choose a category whose products share a meaningful buying question. A group of desk lamps might need to answer questions about height, light controls, included parts, and available finishes. A group of replacement accessories might instead depend on model compatibility. Don't mix unrelated categories just to make the sample look larger.

Write the buyer question in ordinary words before designing fields. For a hypothetical desk setup, a person might need a lamp that fits beneath a shelf and comes with the power adapter required to use it. That request involves dimensions and included contents. The pilot needs those two facts, not another long AI-written product description.

Here is one hypothetical record carried through the decision. A buyer asks, “Will this lamp fit beneath my 40-centimetre shelf?” The field is assembled_height_cm for the exact lamp variant. The latest approved specification, revision R4, lists 39 centimetres; an older seller sheet, revision R2, lists 41. Keep the field unresolved while the records conflict. The acceptance rule could require the category owner to confirm the current approved specification for that variant, record the superseded source, and approve the value before export. After approval, check the named destination's received record and run the same shelf question against it. Record the value received and the resulting answer. This is a proposed example, not a product test or a claim about any retailer's catalog.

Use actual customer requests when the business has them and the intended use permits it. A support team may know which details people repeatedly ask about. Search logs may show requests that the current catalog handles poorly. Remove personal information that doesn't belong in the project, and distinguish a real request from an example the team created for the pilot.

Decide what the initial scope includes. It may cover the product information and one destination, rather than every marketplace or assistant. Name the category, the record sample, the questions, the sources, and the receiving system. That keeps a discussion about catalog readiness from expanding into an undefined integration project.

Define completion in terms someone can inspect. For example, the proposed pilot should let a reviewer determine whether each sampled lamp fits the shelf constraint using a documented measurement. That result can be inspected. A statement that the same project will increase sales needs evidence the pilot hasn't produced yet.

Assign an owner for the question as well. The merchandising team might decide what buyers need to know, while a product specialist verifies a technical detail. One person doesn't have to perform every step, but someone must be responsible for resolving a gap rather than assuming the extraction system will answer it.

View image detail

A buyer presents a lamp while a product specialist checks its shelf clearance and holds its separate power adapter.

Actual size

Choose Actual size to read the graphic closely.

Inspect where the product information currently lives. A public page, a supplier specification, an internal spreadsheet, and an export can each contain a different version of the same item. The first audit should show which version the receiving system actually uses. Improving a page doesn't fix a feed that still carries older information.

Take a sampled product and follow its identifier through the path. Locate its current product record, its variants, and the source used for each consequential field. Check whether the same identifier survives the export. If the business uses separate identifiers for a base product and a variant, preserve that distinction rather than merging the records for convenience.

Record the existing values before changing them. This gives reviewers a baseline and provides a way to explain a later correction. If the audit begins by overwriting fields with generated values, the team may lose the evidence needed to understand why an answer changed. Preserve the original source as well as the original record.

List the gaps in relation to the buyer question. A missing height and an inconsistent finish label are different problems. A known value that doesn't reach the destination is another problem again. Put the work in the correct place instead of describing every failure as a need for enrichment.

Algolia's Data Transformation page describes record preparation both before and after indexing. That is relevant background for the audit, but it doesn't mean your current implementation uses every documented capability. Check the actual configuration and supported fields for the system in this pilot.

The output of this step should be a small map a client can read. It should connect the buyer question to the fields, the sources, the product identifiers, and the destination. That map makes the next decision easier: which gap requires a source correction, which requires a naming rule, and which requires a delivery change?

View image detail

A lamp's product information moves from a source sheet through a record and variant to an export and receiving tray.

Actual size

Choose Actual size to read the graphic closely.

A field name doesn't always communicate enough. Height might mean the assembled product, its packaging, or the item with an attachment removed. A reviewer needs to know which meaning applies. Define the field in terms of the customer's question so another person can inspect a value and reach the same interpretation.

For the hypothetical lamp sample, a proposed attribute dictionary might define assembled height, measurement unit, included adapter, finish, and variant identifier. Keep the fields that serve the actual decision. An enormous dictionary can create maintenance work before the business has shown that the extra information helps anyone.

Separate naming conventions from factual decisions. Standardizing centimetres to a shared unit is a transformation with a clear input and rule. Deciding that a lamp fits every shelf in a class requires additional assumptions. Don't hide the second decision inside the first because both can produce a tidy field.

Define how missing and uncertain values appear. An unknown specification, a source conflict, and a value awaiting approval should remain distinguishable. A proposed system might route those states to different review tasks. What matters is that a later consumer can recognize the status instead of treating every populated cell as equally established.

Check whether category definitions need different rules. A dimension relevant to one product group may not apply to another. Forcing a universal field can create false completeness, where a record contains a value but the value doesn't answer a meaningful question. Add a shared field only when its meaning survives across the intended category.

Keep a short example alongside each consequential definition. Show what a valid value looks like, which source can support it, and one case that should remain unresolved. Those examples help reviewers apply the rule consistently. They should describe proposed records, not fabricated screenshots of a vendor interface or claims that a particular tool implements the rule automatically.

View image detail

A lamp, height gauges, a supporting sheet, and a separate covered example distinguish supported and unresolved values.

Actual size

Choose Actual size to read the graphic closely.

Source precedence should be defined per field, since the strongest evidence for a measurement may not be the strongest evidence for included parts. A retailer could start with a policy like this, then have its product and compliance owners approve or change it:

• What is the assembled height of this variant?: Preferred evidence: Current approved manufacturer specification for the exact variant; If evidence conflicts: Keep the value unresolved until the category owner confirms which revision governs
• Which adapter ships in the box?: Preferred evidence: Current, variant-specific contents list or approved packaging record; If evidence conflicts: Ask the product owner to reconcile the list with the shipment record
• Which finish is visibly shown?: Preferred evidence: Current image matched to the exact variant, for visible appearance only; If evidence conflicts: Do not infer a material, coating, or color standard that the image cannot establish

This is a proposed starting policy, not a universal source hierarchy. The organization should name the owner who approves precedence, how an approved revision supersedes an older one, and which conflicts always require review. A photograph can support a visible feature; it cannot settle every technical specification. A source's recency matters only when it is approved for that field and product identity.

Store enough information to find the source again. Keep the source identifier, relevant date or revision, and the location of the supporting detail with the record. A bare label saying manufacturer doesn't help much when the manufacturer has published several different documents. The reviewer needs a retrievable reference.

Treat changes as part of the process. If a supplier corrects a measurement, determine which fields and variants depend on that specification. Then inspect the updated destination. The job isn't finished merely because a new document arrived or a local record changed. The corrected information needs to reach the system that answers the buyer.

These steps make an enrichment project easier to maintain. A future reviewer can understand where a field came from and why the team accepted it. When a customer finds a problem, the business can trace the specific answer instead of starting another search through old attachments and disconnected spreadsheets.

View image detail

A reviewer traces a lamp attribute to a current specification while an older document remains beside it.

Actual size

Choose Actual size to read the graphic closely.

Now the team can decide which parts of the information hunt deserve automation. A proposed extraction step might locate candidate values, associate them with records, and present their sources for review. Start with the fields the pilot needs. Don't expand the task to write descriptions, classify every item, and generate new merchandising claims before the basic record works.

Keep the proposed value separate from the accepted value. This gives reviewers a clear change to inspect and prevents a candidate from becoming public simply because a system produced it. The team can accept supported fields, correct mismatches, and preserve unresolved cases without losing the original record.

The review should focus on meaning. Does the value belong to the correct product and variant? Does the unit match the field definition? Does the supporting source establish the claim? Did the extraction carry a qualifier that matters? A syntactically valid record can still be wrong on any of these points.

Make rejection useful. Record whether a candidate failed because the source was missing, the product identity was ambiguous, or the interpretation was unsupported. Those reasons tell the team what to improve. A generic failed flag can cause the next run to repeat the same attempt without addressing the underlying problem.

Algolia's Intelligent Data Kit page describes data-preparation options and directs customers to confirm plan compatibility and pricing. That guidance applies to IDK. It doesn't establish access, packaging, or a proposed review workflow for Velou or any specific account; check the named tool's current documentation and account terms before scoping it into a pilot.

For each candidate, retain a compact evidence row: candidate value, source and revision, reviewer action, accepted value or unresolved state, and the named destination result. That record makes it possible to tell whether automation reduced the information hunt or simply moved work into review. Measure reviewer effort during the pilot instead of estimating it from how quickly a system produced a batch of fields.

View image detail

A reviewer checks candidate lamp details against a source sheet and separates accepted and unresolved samples.

Actual size

Choose Actual size to read the graphic closely.

An accurate internal record helps only if the relevant system receives and uses it. Inspect the complete path after approving a change. This might involve an index, a product feed, a comparison interface, or another supported destination. The destination's actual requirements determine what belongs in the export.

Verify the product identifier and the field names first. A correctly defined value can disappear because an export uses a different name or leaves the field out. A record can also reach the wrong item when identifiers change between systems. These are delivery problems, even when an enrichment tool produced the right candidate.

Choose one named destination and read its current documentation for supported fields and transformations. Shopify is one platform-specific example: its agentic-storefront documentation distinguishes its product catalog from agent-discovery files and describes product mapping for custom fields. Record only what your pilot can verify for its named destination; behavior observed on one platform does not establish universal readiness.

Check the received value, not only the outgoing request. A workflow can report that it sent an update while the destination still shows an older record or rejected a field. Inspect the stored or rendered result through the destination's supported tools. Keep a receipt or captured comparison that lets the client see what arrived.

Then test the buyer question again. Use the same constraint and the same product group. If the answer remains poor, determine whether the field was omitted, ignored, interpreted differently, or simply insufficient. That diagnosis should guide the next change instead of prompting the team to generate another batch of attributes without a clear reason.

This is where operational design and AI behavior meet. The team can have a strong source, a good definition, and an approved record, yet still need a delivery correction. Keeping those stages separate helps people identify the actual failure and preserve the work that already passed.

View image detail

A product record passes through a delivery checkpoint into a receiving tray for a person to inspect.

Actual size

Choose Actual size to read the graphic closely.

Define the pilot's evaluation before reviewing its final results. The first question is whether the record supports the buying decision correctly. For the hypothetical lamp, that means checking the height against the stated shelf constraint and confirming the included adapter from the appropriate source. It doesn't mean asking whether the generated explanation sounds impressive.

Include requests that should produce an unresolved answer. If the source lacks a necessary measurement, the system should identify the gap or ask for the missing information through its supported behavior. An evaluation made only of easy, complete examples won't show how the workflow handles the cases that create work for the team.

Preserve a set of before-and-after examples. Record the original answer, the changed fields, the accepted sources, and the new answer. Keep cases that improved, stayed the same, or became worse. That gives the client a more useful picture than a gallery of selected successes.

Also record reviewer effort. How much time went into locating sources, checking candidates, and fixing mistakes? If the pilot uses a new review process, compare it with the relevant current process rather than an imagined workflow in which every task happens manually. Avoid claiming a saving until the team actually measures the work.

Sales outcomes require their own evaluation. A product-data correction might help a buyer and still produce no measurable revenue change in a small trial. Other changes might affect sales during the same period. Keep those conditions visible, and don't turn an accurate-answer finding into a causal business claim. Measuring AI business value beyond a vendor ROI example offers a broader approach to separating operational evidence from business outcomes.

The result should tell the client what to change next. The client may choose to extend the workflow, repair one field definition, change a destination mapping, or stop a process that creates too much review work. A pilot that identifies the wrong next step is still valuable if it gives the team a clear reason to avoid a larger mistake.

View image detail

A lamp fit check, a covered unresolved sample, a hand reviewing blank sheets, and a receiving tray show four distinct pilot-evaluation concerns.

Actual size

Choose Actual size to read the graphic closely.

Once the sample behaves sensibly, decide how the operation will continue. Name the person who owns source changes, the person who approves category definitions, and the person who verifies destination updates. These roles can overlap in a small business. What matters is that the work has an owner when the initial project ends.

Choose the events that require a new review. A changed specification, a new variant, a renamed category, or a different destination rule can invalidate part of an earlier approval. The process should reopen the affected work while preserving unrelated fields that remain supported. Starting everything again wastes effort; reusing every old approval hides changes.

Keep the accepted record and its previous state available. A reversible pilot helps the team investigate a correction without reconstructing what existed before the change. Decide how a rejected update gets handled and how the team confirms that a restored value reaches the destination. A rollback plan should concern actual supported operations, not an invented button in a tool the team hasn't implemented.

For an agency engagement, make the final handoff concrete. Provide the category scope, buyer questions, attribute definitions, source rules, accepted sample records, evaluation findings, and continuing responsibilities. The client should be able to identify what passed and what remains unresolved without asking the agency to reinterpret its own report.

Use this proposed register as one row per sampled product, variant, question, and field. Copy the header into a spreadsheet, then keep the acceptance rule and the actual destination check beside the evidence:

product_id,variant_id,buyer_question,field,acceptance_rule,source_id,source_revision,candidate_value,accepted_value_or_unresolved,reviewer_action,destination,destination_check,before_answer,after_answer,outcome_status,owner,next_action

Use passed, unresolved, or change required for outcome_status. “Passed” means the evidence met the stated acceptance rule and the named destination returned the checked value; it does not mean sales improved. An unresolved row keeps its source conflict visible and names who will resolve it. This is a proposed template, not an existing Velou screen or an implementation result. Start the next iteration with the most important remaining gap, and expand only when evidence supports it.

View image detail

An open paper register sits beside a lamp gauge, source sheet, and receiving tray.

Actual size

Choose Actual size to read the graphic closely.