Calling the Engine API

request requirements when an engine api request is made, monetate's decision engine evaluates all active omnichannel experiences in the account and uses the provided context to make decisions about which experiences and actions for which the customer has qualified all engine api requests must be made via a post request and include the following endpoint content type header body endpoint the endpoint to which engine api requests are made is as follows engine api endpoint https //engine monetate net/api/engine/v1/decide/{retailer shortname} the {retailer shortname} placeholder is a unique identifier that specifies the parent value of the account this identifier is provided by your dedicated services team a subsequent channel attribute is required within the request body that specifies the account, domain, and instance (for example "channel" "a 887f2483/p/example com" ) content type header the content type header is required and may be set to either application/json or text/plain monetate recommends text/plain to avoid an extra round trip (the cors preflight options request associated with application/json ) body the body of an engine api request consists of json that identifies the account and passes page and user level data via events events in a request each of the three event types instructs the engine api to do different things with the associated information event types that begin with monetate\ decision request that the engine api evaluate active experiences and return actions event types that begin with monetate\ context provide information about the visitor or page that monetate uses for targeting and decision making purposes event types that begin with monetate\ record provide information that monetate should record but that isn't used for targeting or decision making purposes all engine api requests should follow the same structure as noted in the decision docid\ ciez8brum1bicunssjnil however, including various api models depends on individual integrations and use cases include the pagetype parameter within the monetate\ context\ pageview model to use corresponding action conditions include the monetate\ context\ productthumbnailview event to communicate all items present on a listing page or search results page, which can then be used for action conditions or advanced recommendations use cases include the monetate\ context\ productdetailview event to communicate a product view has occurred and subsequently target/condition based on a specific product, brand, product type/category, or advanced recommendations use cases include the monetate\ context\ cart event to communicate cart contents which are used for behavioral analytics and cart content targets or action conditions include the monetate\ context\ purchase event to communicate a purchase has occurred for behavioral analytics and purchase see target, event, & condition mapping docid\ n vumbacftg0jlhtikean for more extensive mapping of engine api models and how you can use them for targeting and action conditions in experiences and actions user identity persistence monetate identifies anonymous visitors and tracks behavior via a monetateid this id is generated on the first request to the platform if it's not already present and identifies a unique device or browser monetate tag in a traditional baseline implementation docid\ zcx p3d6nd2rr5bjloyug implementation, monetateid is set as a first party cookie, mt v it persists for future site visits engine api for engine api implementations, monetate generates monetateid if no identifier is passed in the request because monetate has no way to set the mt v cookie, the requesting application is responsible for keeping track of the monetateid by setting the cookie or otherwise storing or maintaining the persistence of the value by other means unique to your application if a device id is available that can uniquely identify the customer's device across requests, then you can alternatively include deviceid in all engine api requests this value then acts as a unique identifier and allows monetate to track visitor behavior throughout the current session and across future sessions to summarize user identity persistence options for engine api clients monetateid — can be used for an application and must stored in a variable on your end deviceid — can be used as an alternative to monetateid to identify the customer's device across requests that doesn't need to be stored this value acts as a unique identifier and allows monetate to track customer behavior throughout the current session as well as across future sessions whether you use monetateid or deviceid to identify the customer, you must include it in all requests for both current and future sessions hybrid implementations for types of implementations docid\ zfxs45ymf6aicwwkkgxcc , ensure that you do the following if a monetateid exists in the mt v cookie, then you must pass it in all engine api requests if no existing monetateid is present in an mt v cookie, then you must ensure that the monetateid generated by the initial engine api request is set as a first party cookie named mt v (case sensitive) these user identity measures allow monetate to reconcile information collected by both the engine api and the monetate tag into a single unified session you must take these measures to ensure the seamless functioning and optimal performance of your hybrid implementation failure to do so can result in a variety of issues, including disconnected user experiences and inaccurate data tracking contact your dedicated customer success manager (csm) if you need assistance with these steps monetateid sample requests and responses new visitor request this example of a new visitor request has no monetateid in the response monetate includes it { "channel" "a 12345678/d/example test", "events" \[ { "eventtype" "monetate\ decision\ decisionrequest", "requestid" "11111" }, { "eventtype" "monetate\ context\ ipaddress", "ipaddress" "127 0 0 1" }, { "eventtype" "monetate\ context\ pageview", "url" "https //www example test/path" } ] }{ "meta" { "code" 200, "monetateid" "5 977810341 1521134874631" }, "data" { "responses" \[ { "requestid" "11111", "actions" \[ { "data" { "example" "json" }, "actiontype" "monetate\ action\ omnijson" } ] } ] } } returning visitor request a monetateid is sent in this example returning visitor request, which is mirrored in the response { "channel" "a 12345678/d/example test", "monetateid " "5 977810341 1521134874631", "events" \[ { "eventtype" "monetate\ decision\ decisionrequest", "requestid" "11111" }, { "eventtype" "monetate\ context\ ipaddress", "ipaddress" "127 0 0 1" }, { "eventtype" "monetate\ context\ pageview", "url" "https //www example test/path" } ] }{ "meta" { "code" 200 }, "data" { "responses" \[ { "requestid" "11111", "actions" \[ { "data" { "example" "json" }, "actiontype" "monetate\ action\ omnijson" } ] } ] } } deviceid sample requests and responses new visitor request in this example new visitor request, deviceid is passed instead of monetateid in this scenario, it's a new visitor request because monetate hasn't received this deviceid before in the response, monetate doesn't include the deviceid but instead returns monetateid , which can be ignored in this instance { "channel" "a 12345678/d/example test", "deviceid " "39hu7lgj05454nj5t4", "events" \[ { "eventtype" "monetate\ decision\ decisionrequest", "requestid" "11111" }, { "eventtype" "monetate\ context\ ipaddress", "ipaddress" "127 0 0 1" }, { "eventtype" "monetate\ context\ pageview", "url" "https //www example test/path" } ] }{ "meta" { "code" 200, "monetateid" "5 977810341 1521134874631" }, "data" { "responses" \[ { "requestid" "11111", "actions" \[ { "data" { "example" "json" }, "actiontype" "monetate\ action\ omnijson" } ] } ] } } returning visitor request when the same deviceid is sent again, monetate recognizes it and classifies it as a returning visitor as in the response in the new visitor request that contained a deviceid value, monetate does not include the deviceid but instead returns monetateid { "channel" "a 12345678/d/example test", "deviceid " "39hu7lgj05454nj5t4", "events" \[ { "eventtype" "monetate\ decision\ decisionrequest", "requestid" "11111" }, { "eventtype" "monetate\ context\ ipaddress", "ipaddress" "127 0 0 1" }, { "eventtype" "monetate\ context\ pageview", "url" "https //www example test/path" } ] }{ "meta" { "code" 200, "monetateid" "5 977810341 1521134874631" }, "data" { "responses" \[ { "requestid" "11111", "actions" \[ { "data" { "example" "json" }, "actiontype" "monetate\ action\ omnijson" } ] } ] } } custom variables for new or returning visitors you can pass deviceid and a custom variable in a request to let monetate know that this customer is either a new or returning visitor { "channel" "a 12345678/d/example test", "deviceid " "39hu7lgj05454nj5t4", "events" \[ { "eventtype" "monetate\ decision\ decisionrequest", "requestid" "11111" }, { "eventtype" "monetate\ context\ ipaddress", "ipaddress" "127 0 0 1" }, { "eventtype" "monetate\ context\ customvariables", "customvariables" \[ { "variable" "returning visitor", "value" "true" } ] }, { "eventtype" "monetate\ context\ pageview", "url" "https //www example test/path" } ] } when you first send deviceid , the engine api classifies the customer as new when you use custom variables, you send the custom variable in addition to deviceid to ensure that new visitors are targeted targeting new and returning visitors with deviceid and custom variables use the custom variable visitors option in the landing target type to target new and returning visitors when configuring the who settings of an experience the custom variable visitors target of an experience's who settings, with 'new visitor' in the 'variable name' field and 'true' as the variable value you can also use the new visitors and returning visitors options in the landing target type instead of custom variables callout of the 'new visitors' and 'returning visitors' options on the landing target type panel of the who settings of an experience identifying known customers included in a customer datasets you can provide a customerid for logged in customers of your application this id identifies someone in, for example, a loyalty program it's associated with the identified device and allows you to use your own data, uploaded to monetate in a customer dataset , for targeting and context for customer datasets this content is only for clients with product data and customer data options in the datasets menu in the top navigation bar of the monetate platform if no menu options appear when you click datasets , then this content doesn't apply to your account instead, see for customer attributes datasets request with customerid from customer dataset { "channel" "a 1d121c07/p/monetate api myshopify com", "monetateid" "5 1824559023 1570975471014", "customerid" "123abc", "events" \[ { you must send monetateid or deviceid with each request the customerid cannot replace them for customer attributes datasets this content is only for clients with the one click datasets option in the top navigation bar of the monetate platform if you click datasets and see product data and customer data listed as menu options, then this content doesn't apply to your account instead, see for customer datasets if you have a customer view enabled and have a different type of customer identifier, then continue to send "customerid" for the customer view and send the customer attribute dataset's identifier name, which you can find on the customer attributes view of the datasets list page , via a custom variable you don't need to add the custom variable value for the identifier name to an experience request with customerid & identifier name in custom variable { "channel" "a 1d121c07/p/monetate api myshopify com", "customerid" "123abc", "events" \[ { "eventtype" "monetate\ context\ customvariables", "customvariables" \[ { "variable" "loyaltyid", "value" "1234" } ] } ] } using customer view with engine api it's possible to have a single view of a customer across mobile, desktop, and apps as long as the customerid is the same doing so stitches together the behavioral data for the customer for the corresponding behavioral targets supported by a customer view this setup works in web experiences by matching on the customerid , which then guarantees that monetate serves the same experience for customer a to have this same matching to happen in your omnichannel experiences, then you must contact the services team to set up an id collector if your account already has an id collector set up for web experiences, then provide the name so that it can be copied to your app accounts client side developers must take the following steps create an omnichannel experience with the omni json action matching the desktop experience to ensure that the customer sees the same visual change pass a customerid in the request along with all relevant or identical target information as context the engine api responds to the request with the eligible experiences context vs events for analytics information sent to monetate generally falls into two categories context — session derived data such as geographic and technographic information or custom variables events — data used for calculating analytics and key performance indicators (kpis) context is determined per session and can safely be sent multiple times—by both the monetate tag and engine api, for example—with no effect on analytics however, events can potentially be recorded by both the monetate tag and engine api in types of implementations docid\ zfxs45ymf6aicwwkkgxcc be aware of the following factors api events are recorded at the session level for experience analytics, but you can view the aggregate count (how many times the event occurred) in raw data product views are recorded individually but are only used for processing recommendation algorithms what matters is if a product was viewed in a session, not how many times it was viewed the most viewed (product detail page) recommendation algorithm can be influenced by multiple views in a given session collaborative recommendation algorithms , such as viewed and also viewed and purchased and also purchased, aren't effected by multiple views in a given session and solely function based on whether a product was viewed in a session cart events are recorded as an event, and monetate considers the most recent event for behavioral purposes for this reason, even for traditional monetate tag based implementations, properly recording all applicable cart items on every track is important purchases are recorded individually but are deduplicated by the purchaseid value if a monetate tag based integration and engine api integration report the same purchaseid, then only one is recorded page views aren't currently supported by the engine api as a result, average page views and bounce rate metrics cannot be calculated for omnichannel experiences custom events you can send any event, such as clicks and impressions, that falls outside of monetate's built in events by using monetate\ record\ pageevents example request with monetate\ record\ pageevents { "eventtype" "monetate\ record\ pageevents", "pageevents" \[ "myevent" ] } the list of events sent can be any event configured in monetate by following the steps in creating a custom engine api event in this documentation these events are identified in the api by their unique key, an alphanumeric string set when you create the event you can't use monetate\ record\ pageevents to send an event that doesn't have a unique key you can configure any event to have a unique key requests referencing this key from the time the key is set result in that event being sent to monetate when one or more of these events are sent via the engine api, they're recorded within monetate as having occurred for the customer at the time sent for example, in the example monetate\ record\ pageevents request, an event with the unique key myevent is sent this value was set using the unique key field in the create engine api event modal in the monetate platform a number of rules govern how unique keys function each key must be unique and can only be used if it actively references the event in question you can't set a key retroactively but you can change it if you send a unique key in a monetate\ record\ pageevents request before you create the key, then the unique key is ignored the engine api also ignores any unique key value in a request that no longer references an event, such as when an unique key is changed custom events are useful for reporting and for use as goal metrics in monetate experiences creating a custom engine api event follow these steps to create a custom engine api event in the monetate platform click components in the top navigation bar and then select events callout of the events option in the components menu in the top navigation bar of the monetate platform click the arrow to the right of create event and then select create engine api event callout of the create engine api event option in the create event selector in the create engine api event modal, give the event a title and description, then enter into unique key the value to be sent when this event occurs leave api as the selected option for category optionally, enter a subcategory and any action conditions the create engine api event modal click save monetate recommends creating one or more action conditions to limit the event to pages on which it should be tracked when a customer meets the criteria of the event, send a request with monetate\ record\ pageevents that contains the unique key that you input for the custom event you also must add the custom api event to the why settings of an omnichannel experience as a secondary metric follow steps 5 and 6 in add custom metrics to an experience in the monetate knowledge base to add and select the event in the experience editor managed impressions by default, when a request with monetate\ decision\ decisionrequest is made and an action is returned as part of the engine api response, an impression is recorded for that action at decision time in some situations additional front end logic must be applied for a customer to qualify for a particular action, such as expanding a navigation bar to see additional options in cases such as this one, you can use a managed impressions action action templates with managed impressions must be added to individual accounts contact your dedicated customer success manager for assistance action templates support a managed impressions flag when this flag is set to true, the action isn't recorded at decision time this flag allows you to set additional action conditions beyond those monetate is able to evaluate even without action conditions, it allows the caller to detect the actual visibility of the action and record its impression accordingly for example, an action may adjust the display of options in a drop down menu, but the customer must first click the menu to become eligible to see the action this screenshot shows the omni json managed impression action template configured for this scenario the omni json managed impression action template configured for an action that requires a customer to click a menu when you make a request to the engine api, the initial response contains the experience with managed impression action and a unique impressionid for the visitor in the session { "monetateid" "5 977810341 1521134874631", "channel" "a 12345678/d/example test", "events" \[ { "eventtype" "monetate\ record\ impressions", "impressionids" \[ "2 mty3mte3ni4xlje2mje0mjcyode", "2 mbv8qje1mtq4mdg5mda" ] } ] }{ "meta" { "code" 200, "monetateid" "5 977810341 1521134874631" }, "data" { "responses" \[ { "requestid" "11111", "actions" \[ { "impressionid" "2 mty3mte3ni4xlje2mje0mjcyode", "json" { "clickedelement" "true" }, "actiontype" "monetate\ action\ omnichanneljson", "actionid" 3813493, "iscontrol" true } ] } ] } } each action returned in the response includes two additional fields the impressionid field contains an encoded string that must be passed back to monetate when the customer qualifies for all front end conditions associated with the action (for example, the customer has clicked a drop down menu and is now eligible to see an action that modifies options within the menu) the iscontrol field contains a boolean value that indicates whether the customer has been assigned to the control group for the action regardless of whether iscontrol=true , the impressionid value should be reported back to monetate once the customer meets all eligibility criteria however, if iscontrol=true then the action doesn't display for the visitor once a customer meets all eligibility criteria, the impressionid value must be reported back to monetate so that it can record the impression the same monetateid or deviceid used in the initial request must be passed when recording impressions so that they can be associated with the customer's session multiple impressionid strings can be reported in the same engine api call so long as they're associated with the same visitor example second managed impressions response { "meta" { "code" 200, "errors" \[] }, "data" { "responses" \[] } } request filtering the monetate\ decision\ decisionrequest event supports two types of filtering the slots=\[] attribute expects an array of strings, each of which is a slot name for an engine api action (for example, omni redirect ) only actions that have slot names matching one of the specified slots are evaluated, and for each slot the highest priority action matching that slot is returned the actiontypes=\[] attribute expects an array of strings, each of which is an action type for an engine api action (for example, monetate\ action\ omnichanneljson ) only actions that have an action type matching one of the specified action types are evaluated unlike the slot filters, it's possible to qualify for multiple actions with the same action type if the slots attribute is missing or consists of an empty array, then no slot filtering is performed if the actiontypes attribute is missing or consists of an empty array, then no action type filtering is performed if both slots and actiontypes are specified, then actions must match both the slots and actiontypes filters to be evaluated in this monetate\ decision\ decisionrequest example request, the event considers only omnichannel redirect actions using the slots=\[] approach example monetate\ decision\ decisionrequest with request filtering { "channel" "a 12345678/d/example test", "events" \[ { "eventtype" "monetate\ decision\ decisionrequest", "requestid" "1111111", "slots" \[ "omni redirect" ] }, { "eventtype" "monetate\ context\ pageview", "pagetype" "homepage" } ] } redirect actions when a monetate\ decision\ decisionrequest event that doesn't include slot filtering is submitted, the customer might qualify for redirect actions, non redirect actions, or some combination of the two if the customer qualifies for a redirect action and is assigned to the experiment group, then only that action is returned in the response if the customer qualifies for multiple redirect actions and is assigned to the experiment group for each of them, then the action with the highest priority is returned if the customer doesn't qualify for any redirect actions or is assigned to the control group for all redirect actions they do qualify for, then all non redirect actions are returned single request full page redirects also work when the monetate\ decision\ decisionrequest event includes the attribute managedimpressions=true if the customer qualifies for a redirect action and is assigned to the experiment group, only that action is returned in the response the action includes an impressionid token that should be reported back to monetate when the redirect occurs if the customer qualifies for a redirect action but is assigned to the control group, that redirect action is still included in the response and has an associated impressionid token, but the response indicates that it's a control action with the iscontrol=true flag the impressionid token for a given redirect action must be reported back to monetate regardless of whether the customer is in the experiment group or the control group see calling the engine api docid\ vqhh9ifdagoujqqvsr5sk in this documentation for details about when and how to report the impressionid token the customerr should only be redirected to the url included in the action if iscontrol=false example client side logic # determine whether a redirect action exists among the actions in the response for action in actions if action\['actiontype'] == 'monetate\ action\ omnichannelredirect' \# report the impression regardless of whether the user \# is in the experiment group or control group report impression(action\['impressionid']) \# only redirect if the user is in the experiment group if not action\['iscontrol'] redirect to url(action\['url']) third party analytics for monetate tag–based experiences, third party analytics integrations can be set up that execute client side and send reporting labels directly to a vendor (for example, google analytics) only experiences for which third party reporting is enabled have their labels submitted for engine api experiences, no formal third party integrations are available instead, the engine api response can include reporting data, and the requesting application is responsible for passing the data along to the preferred third party analytics provider these labels are made available when the includereporting=true flag is added to the monetate\ decision\ decisionrequest event { "channel" "a 12345678/d/example test", "monetateid " "5 977810341 1521134874631", "events" \[ { "eventtype" "monetate\ decision\ decisionrequest", "requestid" "11111", " includereporting " true }, { "eventtype" "monetate\ context\ ipaddress", "ipaddress" "127 0 0 1" }, { "eventtype" "monetate\ context\ pageview", "url" "https //www example test/path" } ] }{ "meta" { "code" 200 }, "data" { "responses" \[ { "requestid" "11111", "actions" \[ { "actiontype" "monetate\ action\ omnichanneljson", "impressionreporting" \[ { "experience label" "omni tpa test 1", "variant label" "b", "is control" false } ] } ] } ] } } example request with annotations the following code shows an example request each object is described separately afterward example engine api request { "deviceid" "imei 123456789", "monetateid" "2 309132816 1519728587304", "preview" "6 3 ejyrvkpmts4vzsujz0xrsj ", "customerid" "87654321", "channel" "a 76ca7dd3/p/example com", "events" \[ { "eventtype" "monetate\ decision\ decisionrequest", "requestid" "12345678", "filters" \[ "slot name" ], "manageimpressions" false, "includereporting" true }, { "eventtype" "monetate\ context\ ipaddress", "ipaddress" "79 173 135 170" }, { "eventtype" "monetate\ context\ coordinates", "latitude" "49 566667", "longitude" "10 883333" }, { "eventtype" "monetate\ context\ useragent", "useragent" "mozilla/5 0 (macintosh; u; intel mac os x; en) applewebkit/522 11 (khtml, like gecko) safari/3 0 2" }, { "eventtype" "monetate\ context\ screensize", "width" 1024, "height" 762 }, { "eventtype" "monetate\ context\ metadata", "metadata" { "language" "en gb" } }, { "eventtype" "monetate\ context\ customvariables", "customvariables" \[ { "variable" "variablename", "value" "variablevalue" } ] }, { "eventtype" "monetate\ context\ pageview", "url" "https //www example com/search", "pagetype" "search" }, { "eventtype" "monetate\ context\ referrer", "referrer" "http //www example com" }, { "eventtype" "monetate\ record\ pageevents", "pageevents" \[ "myevent" ] }, { "eventtype" "monetate\ context\ productthumbnailview", "products" \[ "product72", "product43", "product42" ] }, { "eventtype" "monetate\ context\ productdetailview", "products" \[ { "productid" "product72", "sku" "product72 large green" }, { "productid" "product43", "sku" "product43 medium striped" }, { "productid" "product57" } ] }, { "eventtype" "monetate\ context\ cart", "cartlines" \[ { "sku" "product72color2", "pid" "product72", "quantity" 2, "currency" "gbp", "value" "24 00" } ] }, { "eventtype" "monetate\ context\ purchase", "purchaseid" "123456789", "purchaselines" \[ { "sku" "product72color2", "pid" "product72", "quantity" 2, "currency" "gbp", "value" "24 00" } ] }, { "eventtype" "monetate\ record\ impressions", "impressionids" \[ "2 ms4xlje1mtq4mdg5mda" ] } ] } objects deviceid — can be sent with new visitors without mt v , but is normally used for apps and similar deployments in which cookie ids are not possible (targeting, conditioning) "deviceid" "imei 123456789" mt v value — if not provided, one is returned and the session is considered as a new visitor for targeting and analytics "monetateid" "2 309132816 1519728587304" preview flag — if the session is a preview, include the token id for this object for experience and split preview "preview" "6 3 ejyrvkpmts4vzsujz0xrsj " customerid — unique identifier for customer view and customer datasets "customerid" "87654321" channel — monetate account information "channel" "a 76ca7dd3/p/example com" events the following objects are data passed to monetate for experiences and analytics monetate\ decision\ decisionrequest — decision request with possible filtering for certain action types, managed impressions, and whether to include reporting in the response; the filters parameter can be used to filter certain action types { "eventtype" "monetate\ decision\ decisionrequest", "requestid" "12345678", "filters" \[ "slot name" ], "manageimpressions" false, "includereporting" true } monetate\ context\ ipaddress — the ip address (for targeting and analytics) { "eventtype" "monetate\ context\ ipaddress", "ipaddress" "79 173 135 170" } monetate\ context\ coordinates — physical coordinates (for targeting and analytics) { "eventtype" "monetate\ context\ coordinates", "latitude" "49 566667", "longitude" "10 883333" } monetate\ context\ useragent — user agent header (for targeting and analytics) { "eventtype" "monetate\ context\ useragent", "useragent" "mozilla/5 0 (macintosh; u; intel mac os x; en) applewebkit/522 11 (khtml, like gecko) safari/3 0 2" } monetate\ context\ screensize — size of the screen the customer is viewing (for targeting) { "eventtype" "monetate\ context\ screensize", "width" 1024, "height" 762 } monetate\ context\ metadata — client specific metadata (for targeting and conditioning) { "eventtype" "monetate\ context\ metadata", "metadata" { "language" "en gb" } } monetate\ context\ customvariables — custom variables (for targeting) { "eventtype" "monetate\ context\ customvariables", "customvariables" \[ { "variable" "variablename", "value" "variablevalue" } ] } monetate\ context\ pageview — page view and type (for conditioning) { "eventtype" "monetate\ context\ pageview", "url" "https //www example com/search", "pagetype" "search" } monetate\ context\ referrer — referrer (for targeting and conditioning) { "eventtype" "monetate\ context\ referrer", "referrer" "http //www example com" } monetate\ record\ pageevents — custom page events (for analytics) { "eventtype" "monetate\ record\ pageevents", "pageevents" \[ "myevent" ] } monetate\ context\ productthumbnailview — search and product listing page (plp) product view (for targeting and conditioning) { "eventtype" "monetate\ context\ productthumbnailview", "products" \[ "product72", "product43", "product42" ] } monetate\ context\ productdetailview — product detail page (pdp) product view (for targeting and conditioning) { "eventtype" "monetate\ context\ productdetailview", "products" \[ { "productid" "product72", "sku" "product72 large green" }, { "productid" "product43", "sku" "product43 medium striped" }, { "productid" "product57" } ] } monetate\ context\ cart — cart contents (for targeting, conditioning, and analytics) { "eventtype" "monetate\ context\ cart", "cartlines" \[ { "sku" "product72colour2", "pid" "product72", "quantity" 2, "currency" "gbp", "value" "24 00" } ] } monetate\ context\ purchase — products purchased (for targeting and analytics) { "eventtype" "monetate\ context\ purchase", "purchaseid" "123456789", "purchaselines" \[ { "sku" "product72colour2", "pid" "product72", "quantity" 2, "currency" "gbp", "value" "24 00" } ] } monetate\ record\ impressions — when manageimpressions is set to true , this event tells monetate that the impression happened { "eventtype" "monetate\ record\ impressions", "impressionids" \[ "2 ms4xlje1mtq4mdg5mda" ] }