Re-target Campaigns Based on Changed Display Unit Criteria

This use case describes the requirements for re-targeting campaigns based on change display unit criteria.

Note: The ID#s we use in these samples are for illustration purposes. They are invalid. Be sure to use your own ID#s for your integrations. Also, in our examples, we use the api-sandbox endpoint and HTTP token.

To re-target campaigns based on changed display unit criteria, use the following operations:

  • Create a new association between a criterion and a display unit using POST and the /resource_criteria/v7/add method.
  • Retarget the campaign using POST and the /reservation/v21/add_skin_slots method.

For this step, you will need the ID# of the criterion (criteria_id) and the display unit. With this method, use the display unit ID# in the parent_id parameter.

Copy 
curl -X POST \
    https://api-sandbox.broadsign.com:10889/rest/resource_criteria/v7/add \
    -H 'authorization: Bearer YourAPIKeyHere' \
    -H 'cache-control: no-cache' \
    -H 'content-type: application/json' \
    -d '{
    "parent_id": 1753,
    "criteria_id": 555,
    "type": 5,
    "domain_id": 1
    }'
Copy 
{
    "resource_criteria": [
    {
        "id": 1808
    }
    ]
}

In Step 1, we changed the criteria associated with a display unit. To retarget the campaign to this display unit, we associate a skin_slot with it. A skin_slot is a slot_reservation of a campaign inside a frame.

We will use the resource_criteria result from Step 1: Update Display Unit Criteria for the parameter du_or_criteria (in this example).

Copy 
curl -X POST \
    https://api-sandbox.broadsign.com:10889/rest/reservation/v21/add_skin_slots \
    -H 'authorization: Bearer YourAPIKeyHere' \
    -H 'cache-control: no-cache' \
    -H 'content-type: application/json' \
    -d '{
    "domain_id": 123456789,
    "id": 17531,
    "sub_elements": {
        "du_or_criteria": [ { "id": 1808 } ]
            }
    }'
Copy 
{
    "reservation": [
    {
    "id": 17531
    }
    ]
}