Baseline Implementation

The Monetate tag is a small chunk of code that enables Monetate to communicate with your site. There are two tag options: a synchronous tag and an asynchronous tag. Refer to Tag Comparison to better understand the benefits of each tag type, depending on your requirements.

If you need assistance deciding which tag to use, submit a support ticket using the

The tag code must exist in the element of every page on which Monetate should run. Typically, the code is inserted in only one location: the site's main template file. This process can take a matter of minutes, depending on your business' internal processes and release cycles.

The Monetate tag is the foundation for using Monetate to test, personalize, merchandise, and measure anything on your site. Once you install the tag, you gain the ability to do the following:

Your site's code guarantees priority for the synchronous Monetate tag. This allows the tag to display all content at the same time and deliver a consistent experience for your customers.

The synchronous tag loads via a blocking script and has the potential to slightly extend page load time. This tag doesn't display any visual artifact of your native site before Monetate's content renders. Although Monetate cannot guarantee that this call completes within a specified time range, internal testing revealed no material impact on the end user's experience.

The synchronous tag's content consists of two components: entry.js and custom.js.

The entry.js component does the following:

The client site waits until this file loads and runs.

The custom.js component is an asynchronous script that does the following:

Akamai manages both scripts. Monetate pushes updates to them when changes occur.

The synchronous tag loads in the same amount of data as the asynchronous version, but the browser caches most of this process for much longer, resulting in less time spent downloading scripts.

Here's an example of the synchronous tag code:

The asynchronous Monetate tag loads independent of your site. It doesn't affect your site's load time or performance. Due to the priority given to your site's content when the browser loads your page and the robust nature of the Monetate platform, use of the asynchronous tag includes the slight possibility that customers may see a visual artifact of your native site experience before the Monetate-optimized experience renders.

The client site continues to load during the request.

Here is an example of the asynchronous tag code:

Monetate supports both tag types, so the choice of which one to use is up to you. Here are a few things to consider when making your decision:

This table offers a side-by-side comparison of the two tags.

Monetate doesn't collect conversion data for staging, development, testing, or QA tag instances for either version of the Monetate tag. It only collects it for production instances. You can check which tag instance each of your accounts has by looking in the account selector in the top navigation bar of the platform.

If PRODUCTION appears next to an account listed in the selector, then conversion data is collected for it.

Follow these steps to obtain and install the code for the Monetate tag.

You can use the Monetate Inspector to verify that the tag is working.

While you can install the Monetate tag using a tag management system (TMS), the timing of the TMS to the page can hinder performance if the TMS cannot place the tag onto the page prior to the DOMContentLoad window event.

The setPageType method call sends the page type for a page that a site visitor is on to Monetate. This information also allows you to limit actions to specific page types when you add action conditions to Web experiences.

For example, if you want to display a hero banner only on your site's home page, then you must consider all of the possible URLs:

By defining a page type, you can reliably target visitors with "pagetype=main" and not need to know every possible URL or write complex regular expressions to define the right URLs. Instead, add an action condition based on the information passed to Monetate from the setPageType API method.

You can pass any string value for page type, but Monetate recommends using a single word with lowercase values because they're easier to remember.

Key pages to set page types for include the home page, index page, search page, product detail page, cart page, checkout page, and purchase confirmation page. You can include anything you like. Other page types may include store locator pages, Contact Us pages, and more.

The addProducts method sends to Monetate the product IDs and, optionally, the product SKUs that are rendered on an index or search page (for example, fifthlevelfashion.com/men/shirts.html). Because it enables you to target experiences at the product level on index and search pages, you must include this method in the page template for all index and search results pages.

For example, you want to show an action on a product index or search page. To accomplish this goal, you use the On index page action condition. This setup means that when you use this action condition, the action appears only on any index or search page on which those product IDs exist.

Sending both product IDs and product SKUs enhances the capabilities of recommendations and product-badging actions.

If you have facet or filter functionality on a page that updates with AJAX or changes state asynchronously to display new data, you must add a retrack to ensure Monetate receives the changing product IDs on the page. Refer to Page Retracks for more information.

The addProducts method doesn't trigger the product behavioral WHO targets. These are sourced via the addProductDetails, addCartRows, and addPurchaseRows methods.

The addProductDetails method is used to add items when a customer views a more detailed product description on a product detail page. This is usually linked from an index or search page thumbnail. Some product detail pages may have several items described.

For example, if you implemented the addProductDetails method and you want to run an experience based on a product viewed on the product detail page, then you would navigate to the WHO part of the experience and then select the relevant data target (for example, on the product detail page with the product viewed equals "yellow shirt").

Sending SKUs is only required if you're using Product Recommendations.

The addCartRows method sends information about the products that visitors have added to their cart to Monetate. You should make a call to this method on every page or at least on any page on which the basket has the potential to change. Implementing the addCartRows method on these pages is important because it allows you to use experiences such as abandoned cart messaging, delivery threshold messaging, and targeted upsell opportunities based on products in a visitor's cart.

For example, if you've implemented addCartRows and want to run an experience to target visitors with products in their carts above or below a certain value, you can configure the relevant data target, such as product in cart under $50, in the WHO settings of the experience.

The addCartRows method requires the following properties: productId, quantity, and unitPrice. Optional properties include currency and SKU. Non-US sites must include currency.

If your cart updates with AJAX or changes state asynchronously to display new data, you must add a retrack to ensure Monetate is aware of the change. Refer to Page Retracks for more information.

The addPurchaseRows method sends information about the products that a customer has purchased to Monetate and specifies details about that product (for example, quantity, purchase ID, amount, and currency). Implementing this method call is important because it allows you to target experiences based on past purchases and also ensures Monetate can measure the success of experiences that you launch. Include the addPurchaseRows method on purchase confirmation pages.

For example, if you've implemented the addPurchaseRows method and want to run an experience based on a previously purchased product, configure the relevant data target, such as the previously purchased product equals "shoes," as part of the WHO settings of the experience.

The addPurchaseRows method requires the following properties: purchaseId, productId, quantity, and unitPrice. Optional properties include currency and SKU. Non-US sites must include currency.

Passing data from Monetate to your own third-party analytics provider enables more granular reporting.

Monetate allows you to pass experience data to any analytics provider that can accept data within the browser so that your analysts can see the visitors who've been exposed to a Monetate experience. The data passed to your analytics provider includes the experience ID, experience name, and which experience variant the visitor saw.

See the Third-Party Analytics category in the Monetate Knowledge Base for how to integrate your Monetate implementation with such analytics platforms as Google Analytics, Contentsquare, and others.

You must upload a product catalog to use certain Monetate features, such as Product Recommendations and product-badging actions. Uploading a product catalog has the added benefit of allowing you to target products in the WHO settings of an experience by hierarchy, category, or product attribute that you've specified within the product catalog. Monetate highly recommends that you implement a product catalog because doing so unlocks additional capabilities within the platform.

Monetate's product catalog specification is loosely based on Google's product data specification.

See the Product Catalog Datasets category of the Monetate Knowledge Base for more information on creating a product catalog dataset schema and options to upload and update product catalog files in the Monetate platform.