Types of Implementations

monetate offers three primary deployment options monetate javascript api, engine api, and monetate sdk a hybrid implementation of the monetate javascript api and engine api is possible monetate javascript api the getting started with the monetate javascript api allows you to pass page level data to the monetate platform it follows common ecommerce patterns and is straightforward for experienced front end developers each method call is categorized by the type of page for which it is intended or most often used in a traditional baseline implementation –based integration, monetate is running in the browser and can directly manipulate your site by inserting, editing, or removing content via reusable actions monetate can additionally leverage dom elements (cookies, javascript variables, html elements) to target and track site specific segments and events by implementing the monetate javascript api method calls and monetate features unlocked , monetate additionally collects (and targets against) behavioral data such as products that have been viewed, carted, and purchased engine api the getting started with the engine api is a restful api that serves as a direct entry point to monetate's decision engine and allows clients to use it in any channel web (server side or within the browser), mobile applications, spa frameworks, and nontraditional implementations such as in store displays or sms/text messaging when using the engine api, you must pass all page and visitor level data to monetate within the request body ip address and latitude and longitude coordinates for geographical targeting user agent for technographic targeting additional context such as url, page type, product ids, and skus as they're viewed, carted, or purchased, as necessary monetate doesn't directly drive changes to the requesting application instead, the engine api response contains json formatted data (often configured in advance by the end user) that the requesting application then reacts to see available omnichannel actions in the monetate knowledge base for more information on the available action templates for engine api experiences the engine api allows three things to be done with a single call send contextual information about the current visitor/page retrieve actions that are supposed to fire in the current context these actions can be part of any omnichannel experience in monetate and can be a mix of personalized content and tests to be activated send events/metrics to monetate to measure success bundling all these capabilities into a single endpoint allows all data to be received via a single call and reduces latency when transmitting to monetate retracks on engine api every time something is sent to the engine api, it's similar to a ajax site updates if a decision request is sent with a page view, it's similar to the track call (for example, selecting a color on a product details page) a decision request can be sent without a page view (for example, just the color sku), which only counts as a single page view implementing engine api in mobile apps monetate recommends taking a "personalization aware design" approach, where ui components check for personalization decisions prior to rendering, or render a loading indicator while awaiting the personalization decision this personalization decision may involve replacing or otherwise overriding the components' default content, so it is advised to not display default content until the personalization decision has been received if the application is structured in such a way that each ui component or structure can be checked for personalization overrides before rendering, code pushes simply to run experiences can be avoided identify default components and structures identify which components and structures within the app can be personalized create a store for personalization decisions that may override default components and structures upon render, check the decision store for personalized components flowchart illustrating a mobile application implementing the engine api keep in mind the following points if you're considering implementing engine api in a mobile app the importance of persisting a monetateid (or deviceid ) remains a request must be made any time the app user views a product ( model monetate\ context\ productdetailview ), manages their cart contents ( model monetate\ context\ cart ) or makes a purchase ( model monetate\ context\ purchase ) this enables monetate to track the behavior for reporting/analytics as well as for recommendation algorithms (as applicable) to test against specific device(s), include a testing custom variable by default engine api custom variable testing example { "eventtype" "monetate\ context\ customvariables", "customvariables" \[ { "variable" "qa testing", "value" "true" } ] } hybrid implementation when used within a website, the engine api should be implemented with the traditional monetate tag based approach in a hybrid implementation in this way the monetate javascript api can be relied on for all core reporting and analytics depending on your team's governance model, the engine api can be used for some or all testing and personalization decisioning so long as the monetateid (or deviceid ) is persistent across both the engine api and monetate javascript api deployments in a hybrid implementation, monetate ensures that sessions aren't counted twice because it reconciles the persistent id into a single session page view metrics are only recorded by the monetate javascript api to prevent double counting with hybrid implementations, the engine api requests can be made entirely server side, entirely within the browser, or some combination of the two the exact implementation is dependent on your familiarity with your site architecture and how you want to communicate with monetate flowchart of a hybrid implementation of the engine api regardless of whether engine api requests are made server side or within the browser, the most important thing is to establish a governance model which controls when and where you do or do not use monetate tag–based experiences (where actions run and can directly manipulate the dom) or omnichannel experiences (where the engine api returns a decision and your site reacts to that decision to render the personalized content) keep in mind the following points if you're considering a hybrid implementation monetate tag–based experiences allow the continued use of marketer friendly tools ( action builder , target builder , wysiwyg editors, etc ) to directly manipulate the site with little to no knowledge of front end web development code and with little to no lead time omnichannel experiences require more development resources and time to ensure the correct context is being passed and the correct logic is being applied to render the personalized content monetate tag based experiences can sometimes experience flicker as the site and monetate are "competing" to render the personalized content omnichannel experiences, when implemented properly, can completely eliminate the occurrence of flicker because of the ability to control what renders on the page and when best practices for a hybrid implementation are as follows implement the monetate tag and api methods for reporting and analytics collection implement engine api requests when desired or necessary for decision requests and event recording (such as api events, managed impressions, recommendation item impressions, recommendation item clicks) depending on the site architecture, engine api requests may be made server side, within the browser, or some combination of the two establish an internal governance model for when or where to deploy experiences, such as in these examples use the monetate javascript api solely for reporting and analytics and engine api for all experiences use engine api for high impact, above the fold experiences, and use the monetate javascript api for lower impact experiences define clear use cases for the agility of the monetate javascript api versus the performance of engine api if you're using an spa framework, the same logic can be applied with the following additional considerations the monetate javascript api implementation requires retracks whenever the state of the page changes so that monetate can re evaluate for any monetate tag–driven experiences and properly collect analytics engine api requests should be made from within the browser single page application implementation options single page applications, such as those built with react or vue, can present unique challenges to how the monetate javascript api implementation drives testing and personalization changes while these challenges aren't insurmountable with just the monetate tag–based approach, more clients pursue a hybrid implementation within their spa when using a hybrid implementation within an spa, the engine api may be called from the server on initial app load but from within the browser as the customer navigates the app or whenever the state changes flowchart of spa lifecycles spa front end implementations spa frameworks can also use a front end method of implementation in this method, the monetate tag remains, and the engine api is used—but from the front end for example, in an spa for which the front end stack is based on react, some out of the box actions operating on the dom confuse react (or other javascript frameworks), and then block it from rendering subsequent changes by using the engine api, hooked into some data mutation and template change functions, actions can instead change front end templates or component configurations the spa, therefore, still works as designed while allowing clients to create a/b tests and personalization experiences here are some of the benefits of using an spa front end implementation there's no need to change back end services data is still collected with the monetate tag, so there's no need to re implement data collection here are some of the drawbacks to using an spa front end implementation some full page test (fpt) experiences still require a reload, depending on the front end design monetate's visual tools— action builder and content builder —don't work in this mode content masking is difficult in this mode monetate sdk the getting started with monetate sdks is a library of objects and methods that allow you to easily utilize the capabilities of the engine api using methods that simplify the api calls, you can create and run an experience quickly and with minimal effort the sdk can be used for any channel, including web, mobile apps, and spas the monetate sdk simplifies the api calls by acting as a translation layer to the monetate decision engine the sdk provides easy to use methods that send event data directly to the decision engine and receive the experience to serve