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.
Base URLs
All APIs (except the Analytics API) use the same base URLs in two different environments.
Production Environment: api.tipser.com
Staging Environment: api.stage.tipser.com
For the Analytics API use the following base URLs for testing and implementation:
Production Environment: analytics.tipser.com
Staging Environment: analytics.stage.tipser.com
Session IDs
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.
Event handling recommendations
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.
Supported events quick reference
| Action | Target | Event name | Description |
|---|---|---|---|
| View | Cart-tab | view_cart-tab | A cart tab component was rendered on the page visited by the user. This is not necessarily in the viewport. |
| View | Cart | view_cart | User is presented with the cart phase. |
| View | Collection | view_collection | A collection component, or part of it, was in the viewport of the user's browser. |
| View | Product | view_product_details | 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. |
| View | Product tile | view_product_tile | 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. |
| View | Shop | view_shop | A store component, or part of it, was in the viewport of the user's browser. |
| Click | Payment button | click_payment_button | User has clicked the payment button. |
| Click | Product tile | click_product | The user clicked a product tile component. This can be a standalone product tile or from a collection. |
| Cart | Product | add_to_cart | 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. |
| Cart | Product | remove_from_cart | 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. |
| Cart | Payment | view_checkout | The user opened the checkout view. Generates an instance of this event every time the user enters this view or refreshes this page. |
| Purchase | Order | purchase_completed | 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. |
| Consent | Data policy | User has accepted the data policy. | |
| Reject | Data policy | User has rejected the data policy. |
Block tracking events
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 settingdisableAnalytics: true.