User Identity Persistence in Requests

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 in a traditional baseline implementation implementation, monetateid is set as a first party cookie, mt v it persists for future site visits for engine api implementations, however, monetate generates a monetateid if no identifier is passed in the request because monetate has no way to set the mt v cookie in an engine api implementation, 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 , 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 , which is case sensitive these user identity measures allow monetate to reconcile information collected by both the engine api and the baseline implementation 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 example requests new visitor request this example of a new visitor request has no monetateid in the response monetate includes it new visitor request without monetateid { "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" } ] } new visitor response { "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 included in this example returning visitor request, which is mirrored in the response returning visitor request without monetateid { "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" } ] } returning visitor response { "meta" { "code" 200 }, "data" { "responses" \[ { "requestid" "11111", "actions" \[ { "data" { "example" "json" }, "actiontype" "monetate\ action\ omnijson" } ] } ] } } deviceid sample requests 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 new visitor request with deviceid { "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" } ] } new visitor response with monetateid { "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 doesn't include the deviceid but instead returns monetateid returning visitor request with deviceid { "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" } ] } returning visitor response with monetateid { "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 model monetate\ context\ customvariables in a request to let monetate know that this customer is either a new or returning visitor request with deviceid and custom variable { "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 for the who settings of an experience, 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 dataset 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 that you've 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 user identity persistence in requests docid 7m254upwksja xlmmy6m4 you must send monetateid or deviceid with each request you cannot use customerid in lieu of monetateid or deviceid request with monetateid and customerid { "channel" "a 1d121c07/p/monetate api myshopify com", "monetateid" "5 1824559023 1570975471014", "customerid" "123abc", "events" \[ { 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 user identity persistence in requests docid 7m254upwksja xlmmy6m4 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 and 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