Adding the webtag to your website

The Customer Data Platform (CDP) Webtag has 3 components :

  1. A Javascript SDK (“AgilOne Webtag Library”) to be included on your website’s pages
  2. An authentication scheme
  3. A set of Javascript models (provided by the CDP Webtag Library) to be leveraged with specific data payloads to send event data to CDP

This article will walk you through the implementation of each of those components.

Adding the CDP Webtag library to your pages

CDP provides a Javascript SDK (“AgilOne Webtag Library”) to track events happening on your website. This takes the form of a Javascript file that needs to be included with a configuration script (below) on every page where you need to track events. The SDK can be included anywhere in your HTML pages using 2 <script> tags but we recommend placing it near the bottom of your page header (ie. between the <head> tags) to ensure it does not block other scripts but is still available for the entire page to use. Your pages should therefore look as follows :

<!doctype html>
         var $A1Config = {
             key: “yourKeyHere”,
             tenantId: yourTenantId (e.g. 999)
     <script src=””></script>

The first <script> tag is important to configure the Webtag Library on each of your pages via the $A1Config variable used by the library. It contains the following attributes :

  • key : this is related to the authentication mechanism, explained in the following section of this article.
  • tenantId : this is the identifier for your CDP tenant. This is provided by CDP during your implementation.

Implementing the CDP Webtag authentication

Please review the following article, and implement the authentication flow adapted to your website : Authentication for website & app implementations

Tracking events

CDP provides 2 ways to interact with the Library : a generic way and a model-oriented way which makes it easier to reuse data across your page/ application. The generic way consists of passing a JSON payload containing all the necessary objects & attributes to the Library. This can be used for custom events or actions not supported by the model-oriented objects. A separate documentation will be made available for the generic implementation in the future.

The model-oriented objects represent the different entities that need to be manipulated : Customers, Transactions, Events, and Targets (which is leveraged to pass structured data to all the other models). Each of those models accept a set of attributes & targets as documented in sections below. The objects can be reused in the rest of your page or across pages. For example if the customer browses a product then adds that product to his cart on the same page, you can just define that customer object and product (target) object once and reuse them for both events.

At a high level, tracking an event follows this process :

  • Initializing an instance of the Customer model or reusing an instance of that Customer (if it was already initialized earlier).
  • Creating the Target and optionally the Transaction model instances that will contain the data corresponding to the event being tracked.
  • Creating the Event instance to tie all this data together, and indicate which type of event is being tracked.
  • Sending that data to CDP.

Next steps - Identifying your visitors

Once the authentication and basic setup is done, it is very important to understand the information you need to send to CDP to identify all activity on your website and tie to existing contacts for marketing purposes : Identifying your website visitors.