Calling the Engine API
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 (CSM) 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.
﻿
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.
Initial monetate:decision:DecisionRequest Response
{
  "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
          }
        ]
      }
    ]
  }
}
{
  "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 Follow-Up monetate:record:Impressions Request
Response
{
  "meta": 
  {
    "code": 200,
    "errors": []
  },
  "data": 
  {
    "responses": []
  }
}
{
  "meta": 
  {
    "code": 200,
    "errors": []
  },
  "data": 
  {
    "responses": []
  }
}
﻿
﻿
Updated 25 Sep 2024
Context vs Events for Analytics
Request Filtering