List of tracked events

This article lists out all the events that can be tracked by the Customer Data Platform (CDP) Webtag library as well as the details about the payload that needs to be included for each event.

Important note about event tracking

  1. Each event’s payload contains required and optional attributes. These vary depending on the event type. If an attribute is not applicable to you (or the data is not available on certain pages), do not include those attributes.

  2. You can review your website or mobile app, and implement the appropriate events wherever they are relevant. For example, a click on the Quick Add to Cart button must be tracked through a cartUpdated event, a click on the Quick View button must be tracked through a productBrowsed event, an anonymous visitor filling a form with the email address could trigger a login event. The CDP implementation team can assist you to ensure that the right events are tracked at the right places on your website or mobile app.

  3. Visitors need to be identified on every event. As mentioned above, you should send a customer entity along with each event in on each object/ entity on every call when possible.

  4. The attributes and values that you send to the SDK are case sensitive, and will not work if you use the wrong casing. For instance, if you identify a customer’s email, you would send us

    var currentVisitor = $A1.Customer({
    SourceCustomerNumber: "123",
    Email: “[email protected]” //”Email” with a capital “E”

    And not

    var currentVisitor = $A1.Customer({
    SourceCustomerNumber: "123",
    email: “[email protected]” //”email” with a lower case “e”
  5. You should not initialize an object if you do not want/intend to send that object. For instance, if you are not planning to send transactions via the webtag because they do not match your Order Management System for instance (see the warnings in CDP entities about multiple source systems), do not initialize a $A1.Transaction({}) object. They add SourceTransactionNumber to event object using targets. This way we do not add anything to Transaction Entity and add information to Event and Customer Entity with SourceTransactionNumber added to Event Entity.

  6. In addition to the entities you are sending to CDP, the SDK will collect additional information in each request. The list of items below will be collected :

    • UserAgent - This will be collected off of the browser (if present).
    • UserClient - This defaults to “B” (for “browser”).

List of events

In all cases below, it is expected that the SourceCustomerNumber or Email will be set whenever possible.

Event Name Description When to send it Expected payload
login Tracks users logging into your website. When the visitor logs into your site. A single event with at least a customer identifier (SourceCustomerNumber or Email)
productBrowsed Tracks the product viewed by the visitor. When the visitor views the details of a product (on a product detail page, or via a “Quick View” functionality, etc…). One event for each product viewed with a Target set with the corresponding SourceProductNumber attribute set.
categoryBrowsed Tracks the product category viewed by the visitor. When the visitor is viewing a specific product category page. One event for each category viewed, with the SourceProductCategoryNumber. attribute set
cartUpdated Tracks the content of the visitor’s cart. When an item is added/removed from the cart, or when the cart is cleared. The quantity in the cart for each item does not matter, an item is considered “added” if its quantity in the cart is greater than 0 and “removed” if its quantity becomes 0. One event per cart update, with as many Targets as there are distinct products in the cart, with the corresponding SourceProductNumber attribute set. To represent a cart that has been cleared, send a unique cartUpdated event with one single Target with SourceProductNumber set to NULL.
checkout Tracks orders placed by the visitor. When the visitor has paid and confirmed the transaction. One event for the checkout, with or without a Transaction with the appropriate fields set (SourceTransactionNumber…), and any number of Targets for the related TransactionItems (ie products included in the transaction) with the appropriate fields set (SourceTransactionItemNumber, etc…). There are special cases where you may not want to send any transaction/transactionItem object, more details here : Examples of web event tracking.
onsiteSearch Tracks the search term used by the visitor on your website. When the visitor starts a search on your website. A single event with the SearchTerm attribute set.
logout Tracks users logging out When the visitor logs out of your site. A single event with or without a customer identifier (SourceCustomerNumber or Email).

Next steps - Payload Examples

Now that you know what events are important for CDP to track, you can dig into the actual payloads that need to be sent to CDP to achieve this tracking. All of the events above have example payloads documented & explained in the next article : Examples of web event tracking.