Migrate from Standalone Tracking to Smart Pixel

This page is for existing Mapp Fashion implementations that still use Standalone Tracking with the dressipi.js loader. It maps every Standalone tracking method to its Smart Pixel equivalent and lists the configuration changes involved.

New implementations do not need this page. Start at Tracking Setup instead.

What changes

Loader: the separate dressipi.js script is replaced by the Mapp Fashion extension for Smart Pixel. Tracking no longer runs independently of Mapp Intelligence.
Session handling: Standalone maintains its own session and visitor identifiers (sid, duid, vid). With Smart Pixel, session and visitor context come from the Mapp Intelligence tracking foundation. You do not configure or send these values yourself.
Configuration: namespace_id and host move into the extension configuration as namespaceId and host.
API host: retrieval calls no longer go to api.dressipi.com but to your delegated domain, for example api.your-domain.com.

Before you start

Smart Pixel is integrated on your site. See Smart Pixel.
The Mapp Fashion extension is loaded and activated, with host and namespaceId configured. See Smart Pixel: Fashion extension.
Your delegated domain is set up. See Delegate a Domain.

Configuration mapping

Standalone	Smart Pixel
`Dressipi('config', 'set', 'host', …)`	`wtSmart.extension.fashion.config({ host: … })`
`Dressipi('config', 'set', 'namespace_id', …)`	`wtSmart.extension.fashion.config({ namespaceId: … })`
Loader snippet with `dressipi.v3.js`	`smart-pixel-fashion.min.js`, the npm package `@webtrekk-smart-pixel/fashion`, or the AMD module
No activation step	`wtSmart.extension.fashion.activate()`

Method mapping

Each Standalone method was triggered as Dressipi('track', '<method>', { ...parameters });. The table below lists the Smart Pixel equivalent and where it is documented.

Standalone method	Smart Pixel equivalent	Documentation
`init`	Extension `config` and `activate`	Fashion extension
`pageView`	`wtSmart.page` tracking	User Interaction Tracking
`identify`	`wtSmart.customer.data.set`	User Interaction Tracking
`pdp` / `itemView`	`wtSmart.product.view.data.set`	User Interaction Tracking
`addToBasket`	`wtSmart.product.addToCart.data.set`	User Interaction Tracking
`removeFromBasket`	`wtSmart.product.deleteFromCart.data.set`	User Interaction Tracking
`order`	`wtSmart.product.confirmation.data.set` and `wtSmart.order.data.set`	User Interaction Tracking
`itemClickPDP`, `itemClickQuickView`, `carouselNavigate`, `carouselPaginate`, `tabClick`	`data-dressipi-*` attributes, or `wtSmart.extension.fashion.call('track', …)`	Recommendation Tracking
`plp`	Not yet documented, see below	–

Retrieval calls

Recommendation content is retrieved from the same API in both setups. Only the host and the client call change.

Outfits and similar items: Dressipi("related","items", …) becomes wtSmart.extension.fashion.call("related","items", …). See Outfits and Similar Items.
Faceted search: Dressipi("facetted","search", …) becomes wtSmart.extension.fashion.call("facetted","search", …). See Faceted Search.
Hosted widgets: Dressipi("widget", …) becomes wtSmart.extension.fashion.call("widget", …), with an additional placement parameter. See Hosted widgets.

Open points

Warning
Product listing page tracking is not yet covered for the Smart Pixel setup. If your implementation uses plp tracking, or a PLP widget that depends on it, contact Mapp before migrating.

Two details are still being confirmed and will be added here:

Which call combination the Mapp Fashion recommender expects for product listing pages, and where the filters and page.number values from the Standalone plp call are sent.
Whether the session cookie set by the retrieval API behaves the same on a delegated domain.