You must implement a tracking script if you are implementing with Tipser APIs. Script tracking enables Tipser to provide you with a data dashboard of full-funnel customer actions. Currently Tipser only supports defined tracking events.
All APIs (except the Analytics API) use the same base URLs in two different environments.
For the Analytics API use the following base URLs for testing and implementation:
You'll need to generate a sessionId and pull it through each tracking request. This sessionId corresponds to one shopper's session and links tracking events generated from Tipser elements to tracking events generated from API components.
The sessionId is crucial for a seamless API integration because it prevents the data from being broken up by source.
For information about how to work with sessionIds, refer to the Send Tracking Event API Reference.
Tipser elements send tracking events to the Analytics API by default. We recommend implementing your event handling based off of how Tipser elements handle events, and modifying the approach needed.
A cart tab component was rendered on the page visited by the user. This is not necessarily in the viewport.
User is presented with the cart phase.
A collection component, or part of it, was in the viewport of the user's browser.
The user visited the product detail page, either as a modal or the embedded product page. In the current implementation, this is sent together with the click event.
A product tile component was in the viewport of the user's browser. If it disappears and reappears in the user's viewport, this generates another instance of the event.
A store component, or part of it, was in the viewport of the user's browser.
User has clicked the payment button.
The user clicked a product tile component. This can be a standalone product tile or from a collection.
A product was added to the cart, or the quantity of the product in the cart was increased. Increasing the quantity by any number generates one add_to_cart event, which contains the quantity in a parameter.
A product was removed form the cart, or the quantity of the product in the cart was decreased. Decreasing the quantity by any number generates one remove_from_cart event, which contains the quantity in a parameter.
The user opened the checkout view. Generates an instance of this event every time the user enters this view or refreshes this page.
The user has seen the purchase confirmation page. Generates an instance of this event every time the user enters this view or refreshes this page.
User has accepted the data policy.
User has rejected the data policy.
If a user rejects the data policy, you'll need to block the API from sending tracking events for this user.
tw-trackevents cannot be disabled with the setting