Use the Catalog in Mapp Intelligence

Overview

When a Product Catalog is active for a Mapp Intelligence account, product information is read directly from the catalog. Reports, dimensions, and metrics use the same structured product, style, and variant identifiers, regardless of how the data is collected on your website or app.

This page summarizes what activation means, what changes in your reports, and how product tracking is simplified as a result.

Activating the Catalog for Intelligence

Activating the new Product Catalog for an Intelligence account is not a self-service action. The switch must be carried out by Mapp because it replaces the existing product-category data source used by Intelligence reports.

Once activation has been requested:

• Mapp assigns a Product Catalog to the workspace that contains the Intelligence account.

• Intelligence starts using the catalog as the source of truth for product information.

• Existing reports continue to work, but their product dimensions are now derived from the catalog rather than from the legacy product categories.

Note: Activation should be planned together with Mapp because it affects how existing reports interpret product data. Contact your Mapp representative to start the activation process.

New Dimensions and Metrics

After activation, Intelligence exposes catalog data as dimensions and metrics that you can use in reports and segmentations.

• Product, style, and variant dimensions: Report and group performance at the level that matches the catalog's structure.

• Catalog attributes as dimensions: Use predefined and custom attributes, for example, brand, category, material, season, or any custom attribute you defined, as dimensions in reports.

• Localized values: Analyze product performance across multiple markets using the localized attribute values stored in the catalog.

• Enriched attributes: When Mapp Fashion enrichment is in use, enriched attributes become available alongside the source attributes.

• Variant Status: Use the lifecycle status of variants (PREORDER, ACTIVE, DISCONTINUED) as a reporting dimension or filter, for example to exclude DISCONTINUED variants from sell-through analyses or to track preorder performance separately. See Product Attribute Model for the value mapping.

Image Rendering in Reports

When a custom attribute is configured with the Display Type Image URL, Intelligence renders its value as an inline image in reports that include the attribute, instead of showing the raw URL as text.

This makes product-level reports easier to scan visually, for example, when reviewing top-selling variants alongside their product images.

For details on Display Type, see Display Type.

Tracking Implications

Once a Product Catalog is the source of truth for product information, your tracking setup can become significantly leaner. Static product information no longer needs to be repeated in every tracking call.

What still needs to be tracked

• Variant identifier: Each product-related event must reference the variant_id so that Intelligence can resolve the rest of the product data from the catalog. Tracking events must always carry a variant, even on product detail pages where the visitor has not yet selected a specific option.

• Behavioral and transactional data: Quantities, order totals, prices paid at the moment of purchase, and similar event-specific values continue to be tracked.

What can be removed from tracking

The following data is read from the Product Catalog once it is active and does not need to be sent with tracking events:

• Static product attributes: Product names, default prices, brand, category, image URLs, and similar descriptive attributes are read from the catalog.

• Product hierarchy: Product, style, and variant relationships are taken from the catalog and do not need to be encoded in eCommerce tracking parameters.

If these attributes continue to be sent through tracking events after the catalog is activated, Intelligence ignores them. The catalog data takes over. You can safely leave existing tracking setups in place; for cleaner implementations and reduced data transfer, removing the obsolete values is recommended but not required.

Tracking behavior on product detail pages

Every tracking event must carry a variant_id. On product detail pages where a visitor has not yet selected a specific variant (for example, a size or color), the choice of which variant to track is left to your implementation. Mapp does not prescribe a specific default — common patterns include tracking the variant currently displayed in the page (for example, the first or default variant) or the most recently viewed variant. The important point is that a variant is always tracked.

When a visitor changes the variant selection on a product detail page (for example, picking a different size), a new tracking event with the new variant_id is sent. This can result in multiple events per page view if visitors browse through several variants.

For high-traffic stores where variant browsing is common, Mapp recommends analyzing performance at the product level rather than the variant level. Product-level analysis aggregates over all variants of the same product and produces more stable insights when variant-level signals are noisy.

Note: When migrating an existing Intelligence setup to the catalog, review your tracking implementation. Variant-centric tracking with a stable variant_id is the recommended approach. If you have questions about the migration, contact your Mapp representative.

Typical Use Cases

• Build consistent product, style, and variant reporting from a single source of truth.

• Analyze product performance across markets using localized attribute values.

• Extend reports with custom and enriched attributes managed in the catalog.

• Simplify the tracking implementation by relying on the catalog for static product information.

For details about how the catalog is structured and which attributes are available, see How Product Catalogs Work and Product Attribute Model.