Skip to main content
These steps apply to product cards you render yourself. Cards rendered by a legacy Depict UI SDK already carry these attributes.
We need to tell DPC about the product cards that you created using Depict data. Also, you need to enable Depict to understand what product this product card is in our internal representation. In the response from all our API:s there’s an id inside each display. You need to add this id to your product card template as a data attribute. The ID is called different things based on different endpoints
/v3/search/suggestions returns no displays, so there is nothing to tag for it.
This step enables DPC to track clicks on the product cards — including clicks on add-to-cart buttons inside them. Cards added later (for example after client-side navigation or infinite scroll) are picked up automatically.

​
Examples

One attribute per card, named after the endpoint the display came from (see the table above). The value is the id from that display.
Collection or category page (/v3/listings/*)
Recommendations (/v3/recommend/products)
Search results (/v3/search/*)

​
Product card impressions

A click data attribute does not prove that impression tracking is active. When you render cards yourself, add visibility tracking for search, listing and recommendation cards. Check the events your installed DPC version sends before you add a second sender. Send a card impression when the card becomes visible. Send it from the browser, after rendering. Do not send an impression only because the server rendered a card in HTML. A custom sender can use POST https://api.depict.ai/create-events with a JSON array. Each event requires tenant, market, type and at least one identity field: session_id, user_id or dsid. For an impression, set type to element_visible. Include the result ID from the visible display and its selected variant’s product_id.
For listing cards, use product_listing_result_id instead of search_result_id. For recommendation cards, use recommendation_id. Include exactly the result ID for the card’s source. A custom click sender uses the same endpoint and identity fields, with type: "click" and the card’s result ID. /create-events uses tenant, although v3 serving requests use merchant. Use the same session ID in serving requests, DPC and custom events. Configure DPC with setSessionId. The ID guide explains the 10-minute result ID lifetime and event validation. Check the HTTP status when sending events. A 200 response with {"message": "ok"} confirms that the batch passed validation. It does not prove that result IDs matched. Confirm event arrival and product matching in the portal’s Tracking status tab.