Baseline Implementation

step 1 implement the monetate tag 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 baseline implementation docid\ zcx p3d6nd2rr5bjloyug 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 {{monetatesupportcontact}} to discuss your business needs and then determine which tag type is right 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 purpose 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 create experiences within the platform using the monetate core components deploy previously created experiences use the platform's builders to create actions , targets , and page level kpis create experiences with a range of data variables , including marketing referral channels, geographic location, weather, technographics, and more, all of which are available to use as soon as the tag is live synchronous tag 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 for the synchronous tag to be most performant, use content masking for any action that you create using action builder see content masking in the monetate knowledge base for more information the synchronous tag's content consists of two components entry js and custom js entry js the entry js component does the following adds any entry masks hides content affected by monetate experiences optionally, applies any full page experiences redirects the page if a full page test (fpt) experience matches the current page and the user is within the experiment group requests the custom js file asynchronously updates when changes occur to monetate experiences or to the account the client site waits until this file loads and runs custom js the custom js component is an asynchronous script that does the following reports track data (for example, url, user, browser, etc ) and applies experiences rarely changes 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 synchronous monetate tag example \<! begin monetate expresstag sync v8 1 place at start of document head do not alter > \<script type="text/javascript">var monetatet = new date() gettime();\</script> \<script type="text/javascript" src="//se monetate net/js/2/a 3e41bf76/p/monetate mybigcommerce com/entry js">\</script> \<! end monetate tag > asynchronous tag 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 technical details single script request that enters the page asynchronously reports track data (for example, url, user, browser, etc ) and applies experiences served from akamai cdn the client site continues to load during the request here is an example of the asynchronous tag code asynchronous monetate tag example \<! begin monetate expresstag async v6 1 place at start of document head do not alter > \<script type="text/javascript"> var monetatet = new date() gettime(); (function() { var p = document location protocol; if (p == "http " || p == "https ") { var m = document createelement('script'); m type = 'text/javascript'; m async = true; m src = (p == "https " ? "https //s" "http //") + "e monetate net/js/2/a b6206def/p/fifthlevelfashion com/custom js"; var s = document getelementsbytagname('script')\[0]; s parentnode insertbefore(m, s); } })(); \</script> \<! end monetate tag > tag comparison 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 there's no extra cost regardless of which tag you choose you can switch between the synchronous and asynchronous tag to check for differences in performance changing tags doesn't disrupt your monetate service in any way all monetate features remain functional regardless of which tag you use if you're concerned that customers might see a visual artifact from your native site, then you should use the synchronous tag this table offers a side by side comparison of the two tags synchronous tag asynchronous tag served from akamai cdn served from akamai cdn monetate fully functional monetate fully functional, except for full page test experiences all monetate features available all monetate features available two script requests ( entry js and custom js ) single script request blocking tag nonblocking tag guarantees monetate tag load priority loads independent of your site prevents visual artifacts from occurring visual artifacts are possible on your site use content masking for edit and hide actions cannot use content masking 11 ms response time (average) 13 ms response time (average) 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 callout of the server environment for each account shown in the account selector in the monetate platform if production appears next to an account listed in the selector, then conversion data is collected for it installing the tag follow these steps to obtain and install the code for the monetate tag although monetate does not recommend using a tag management system (tms) to install the monetate tag, the tag does work as expected with systems such as tealium iq for more information, consult your tms provider and submit a support ticket using the {{monetatesupportcontact}} in the monetate platform, click the settings cog and then select integration callout of the integration option in the settings menu click the tag tab the tag tab of the integration page of the monetate platform settings use the toggle to select the baseline implementation docid\ zcx p3d6nd2rr5bjloyug or baseline implementation docid\ zcx p3d6nd2rr5bjloyug version of the monetate tag animated demonstration of a user switching a toggle to view the synchronous version and then the asynchronous version of the monetate tag copy and paste the tag code into the first line of the \<head> element on every page of your site callout of the asynchronous version of the monetate tag code in the 'head' element of the html code for a site you can use the monetate inspector to verify that the tag is working tag management systems & the monetate tag 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 step 2 capture site structure with page types 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 http //example com http //example com/ https //example com https //example com/ http //www example com http //www example com/ https //www example com https //www example com/ 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 step 3 capture products on list pages 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 product skus or ids cannot exceed 50 characters 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 step 4 capture product details 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") although both product id (pid) and sku are required in a product catalog, monetate only requires you to implement method calls for pid that said, you should implement sku if you intend to use the product recommendations feature addproductdetails example // addproductdetails example window\ monetateq = window\ monetateq || \[]; window\ monetateq push(\[ "addproductdetails", \["a123"] ]); window\ monetateq push(\[ "trackdata" ]); example with sku // addproductdetails example with sku window\ monetateq = window\ monetateq || \[]; window\ monetateq push(\[ "addproductdetails", \[{ productid "pidstring", sku "skustring" }] ]); window\ monetateq push(\[ "trackdata" ]); example with multiple skus // addproductdetails example with multiple skus window\ monetateq = window\ monetateq || \[]; window\ monetateq push(\[ "addproductdetails", \[{ productid "pidstring", sku "skustring 01" }], \[{ productid "pidstring", sku "skustring 02" }], \[{ productid "pidstring", sku "skustring 03" }] ]); window\ monetateq push(\[ "trackdata" ]); product skus or ids cannot exceed 50 characters sending skus is only required if you're using product recommendations step 5 capture cart information 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 only captures the product price and no separate delivery, tax, or promotion costs addcartrows example // addcartrows example window\ monetateq = window\ monetateq || \[]; window\ monetateq push(\[ "addcartrows", \[{ "productid" "200001", "quantity" "1", "unitprice" "99 99", "currency" "eur" }, { "productid" "b345", "quantity" "3", "unitprice" "29 99", "currency" "eur" }] ]); window\ monetateq push(\[ "trackdata" ]); empty cart example // empty cart example window\ monetateq = window\ monetateq || \[]; window\ monetateq push(\["addcartrows", \[]]); window\ monetateq push(\["trackdata"]); 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 step 6 capture site conversions 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 purchaseid property must be the same across all rows within addpurchaserows the value it contains must be unique across visitors so that you can validate the implementation by matching purchases collected by monetate with your own data addpurchaserows example // addpurchaserows example window\ monetateq = window\ monetateq || \[]; window\ monetateq push(\[ "addpurchaserows", \[{ "purchaseid" "73893797", "productid" "a123", "quantity" "1", "unitprice" "99 99", "currency" "eur" }, { "purchaseid" "73893797", "productid" "b345", "quantity" "3", "unitprice" "29 99", "currency" "eur" }] ]); window\ monetateq push(\[ "trackdata" ]); the addpurchaserows method requires the following properties purchaseid , productid , quantity , and unitprice optional properties include currency and sku non us sites must include currency integrate third party analytics 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 implement a product catalog 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