Catalog FAQ

Frequently asked questions about product catalogs in the context of a proof schedule.

Does Constructor need an updated feed daily?

No, not for a Proof Schedule. While full integrations involve regular updates to the product catalog, this is usually not necessary for a Proof Schedule. Occasionally, we do ask for an updated product catalog when a large percentage of the product IDs flowing in from our beacon are no longer matching up with the items defined in the product catalog. When this happens, we'll ask you to send an updated catalog.

What does Constructor mean by "facets?" Aside from the required fields, what kinds of fields should we include for each product?

  • Any fields that your users can filter or sort products on in the current search and browse result experiences
  • Any fields that you'd like to create boost, bury or slotting rules with.
  • Suggestions: brand, color, type, material, size, ingredients, diets, price, make, model

Should the product catalog include image URLs for the proof of concept?

Yes. For this proof of concept, we need a single image URL for each product. If variations of a product are different colors or look different in some other way, please provide image URLs for each variation.

Do we need to send store-level inventory and pricing?

Not for a Proof Schedule, but this data may be required for a full integration.

Do we need to send variation-level pricing?

Not for a Proof Schedule, but this data may be required for a full integration.

Can we send our catalog via FTPS or REST API?

There are some special cases where using FTPS or using our REST API to manage a catalog does make sense during a Proof Schedule, but these occasions are rare. To save engineering time across teams, we recommend that you use one of the options listed on the File transfer options guide for the Proof Schedule.