Marketing API Version

Ad Rules Engine

This is a central rule management service that helps you manage ads more easily, efficiently and intelligently. Normally, you periodically query the Marketing API to monitor an ad's performance and manually take actions on certain conditions. Since we can express most conditions as logical expressions, we can automate management two ways: using Schedule or Trigger Based rules.

As of July 5th, 2017, Schedule Based Rules are available publicly.

Trigger Based Rules are still in open beta. To apply for access to the Trigger Rules Beta, please email rulesengine@fb.com with your app ID.

Ad Rules

Ad Rules are standalone objects created and stored in the Ad Rules Library and minimally contain a name, an evaluation_spec and an execution_spec. This is the basic structure of a rule:

curl \
-F 'name=Rule 1' \
-F 'evaluation_spec={
    ...
   }' \
-F 'execution_spec={
    ...
   }' \
-F "access_token=<ACCESS_TOKEN>" \
https://graph.facebook.com/<VERSION>/<AD_ACCOUNT_ID>/adrules_library

Facebook evaluates Trigger Based Rules when an Insights metric or Object metadata field changes. We evaluate Schedule Based Rules on scheduled intervals.

Evaluation Spec

The main purpose of the evaluation_spec of a rule is to determine the objects upon which the rule should execute its action. The evaluation_type determines the type of evaluation method and has the following options:

Evaluation Type Description

SCHEDULE

Schedule Based Rule

TRIGGER

Trigger Based Rule

The evaluation_spec also contains a filters array, which allows us to further narrow the list of matched objects. For example, you can construct filters on Ad, Adset and Campaign metadata and Insights metrics. All filters are evaluated together using the AND operator.

The array contains a list of filter objects, which themselves are dictionaries with keys of field, value, and operator:

Filter Object Keys Required Description

field

Yes

Filter field (e.g. insights or metadata)

value

Yes

Static filter value for the field

operator

Yes

Logical operator for the field

Each filter has a list of supported logical operators. Here is a list of all the logical operators which are supported in SCHEDULE and TRIGGER rules:

Logical Operator Value (Example)

GREATER_THAN

numeric (100)

LESS_THAN

numeric (100)

EQUAL

numeric (100)

NOT_EQUAL

numeric (100)

IN_RANGE

tuple ([100, 200])

NOT_IN_RANGE

tuple ([100, 200])

IN

list (["1", "2", "3"])

NOT_IN

list (["1", "2", "3"])

CONTAIN

string ("ABC")

NOT_CONTAIN

string ("ABC")

ANY

list ([1, 2, 3])

ALL

list ([1, 2, 3])

NONE

list ([1, 2, 3])

The evaluation_spec also optionally (required for TRIGGER evaluation type) contains a trigger. The trigger contains a type and an underlying filter specification (field, value, operator).

The difference is that the trigger dynamically determines whether or not we should evaluate a rule, and you can have only one. See the section under Trigger Based Rules below for more information.

Below we define some special filters, as well as general groups of filters that one can use.

Special Filters

The time_preset filter determines the time period over which we aggregate Insights metrics. Currently, we only allow one time_preset, and it will apply to all stats filters in the rule, including the one used for the trigger if present. The only supported operator for time_preset is EQUAL, and this is required as long as any Insights filter or trigger is present.

Note that time presets for rules behave differently from other interfaces; most of the time presets here include today's data. This is because today's data is critical for rules that run more frequently than daily. For other interfaces, a preset value of LAST_N_DAYS would not include today's data. See the descriptions below for more details.

{
  "field": "time_preset",
  "value": "TODAY",
  "operator": "EQUAL"
}
Time Preset Values Description

TODAY

The current day starting from midnight in the ad account's timezone

YESTERDAY

The previous full day, not including TODAY

LAST_3_DAYS

Last 2 full days and TODAY

LAST_7_DAYS

Last 6 full days and TODAY

LAST_14_DAYS

Last 13 full days and TODAY

LAST_30_DAYS

Last 29 full days and TODAY

LIFETIME

Lifetime of the object

The attribution_window filter determines the lookback window over which we aggregate Insights metrics. For more information, see Conversion Attribution. Currently, we only allow one attribution_window, and it will apply to all stats filters in the rule. The only supported operator for attribution_window is EQUAL, and this is only supported by Schedule Based Rules. If this filter is not specified, it defaults to the DEFAULT value.

{
  "field": "attribution_window",
  "value": "1D_VIEW_1D_CLICK",
  "operator": "EQUAL"
}
Attribution Window Values Description

DEFAULT

The default attribution window is 1 day views, 28 day clicks

1D_VIEW

1 day views, 0 day clicks

7D_VIEW

7 day views, 0 day clicks

28D_VIEW

28 day views, 0 day clicks

1D_CLICK

0 day views, 1 day clicks

7D_CLICK

0 day views, 7 day clicks

28D_CLICK

0 day views, 28 day clicks

1D_VIEW_1D_CLICK

1 day views, 1 day clicks

7D_VIEW_1D_CLICK

7 day views, 1 day clicks

28D_VIEW_1D_CLICK

28 day views, 1 day clicks

1D_VIEW_7D_CLICK

1 day views, 7 day clicks

7D_VIEW_7D_CLICK

7 day views, 7 day clicks

28D_VIEW_7D_CLICK

28 day views, 7 day clicks

7D_VIEW_28D_CLICK

7 day views, 28 day clicks

28D_VIEW_28D_CLICK

28 day views, 28 day clicks

Metadata filters

With metadata filters, you can filter objects based on the current state of their metadata fields. These also support multi-level filtering, which means you can use prefixes to apply a metadata filter on an object's parent or grandparent as well. This does not affect other filters; Insights filters will still apply to the normal object. All metadata filters are supported for Scheduled Rules however only a subset are currently supported for Trigger Rules.

For instance, if you want a rule that applies to Ad Sets of Campaigns whose objective is WEBSITE_CLICKS, you can include two filters:

 "filters" : [
  {
    "field": "entity_type",
    "value": "ADSET",
    "operator": "EQUAL",
  },
  {
    "field": "campaign.objective",
    "value": "WEBSITE_CLICKS",
    "operator": "EQUAL"
  }
]

Below is a list of metadata filters supported by trigger and schedule based rules:

Metadata FieldDescriptionSupported PrefixesSupported ValuesSupported Operators

id*

Specific static objects for which the rule is applied.

ad, adset, campaign

int, array(int)

EQUAL, NOT_EQUAL, IN, NOT_IN

entity_type*

The object level for which the rule is applied.

none

AD, ADSET, CAMPAIGN

EQUAL

name

Name of the object, by partial or complete match

ad, adset, campaign

string

EQUAL, CONTAIN, NOT_CONTAIN

effective_status

Effective statuses of the object

ad, adset, campaign

array(ACTIVE, PAUSED, ADSET_PAUSED, CAMPAIGN_PAUSED, PENDING_REVIEW, ...)

IN, NOT_IN

created_time

Created epoch time of the object

ad, adset, campaign

int

GREATER_THAN, LESS_THAN, IN_RANGE, NOT_IN_RANGE

updated_time

Updated epoch time of the object

ad, adset, campaign

int

GREATER_THAN, LESS_THAN, IN_RANGE, NOT_IN_RANGE

delivery_info**

Delivery statuses of the object

ad, adset, campaign

array(ACTIVE, LIMITED, PENDING_REVIEW, INACTIVE, ...)

IN, NOT_IN

adlabel_ids

Ad label ids of the object

ad, adset, campaign

array(int)

ANY, ALL, NONE

objective

Objective of the ad or campaign of the object

ad, campaign

array(PAGE_LIKES, LINK_CLICKS, VIDEO_VIEWS, ...)

IN, NOT_IN

start_time

Start epoch time of the object

ad, adset, campaign

int

GREATER_THAN, LESS_THAN, IN_RANGE, NOT_IN_RANGE

stop_time

Stop epoch time of the object

ad, adset, campaign

int

GREATER_THAN, LESS_THAN

Below is a list of additional metadata filters supported only in schedule based rules:

Metadata FieldDescriptionSupported PrefixesSupported ValuesSupported Operators

topline_id

Topline id of the campaign of the object

campaign

array(int)

IN, NOT_IN

buying_type

Buying type of the campaign of the object

campaign

array(AUCTION, FIXED_CPM, RESERVED)

IN, NOT_IN

billing_event

Billing event of the adset of the object

adset

array(APP_INSTALLS, LINK_CLICKS, IMPRESSIONS, ...)

IN, NOT_IN

optimization_goal

Optimization goal of the adset of the object

adset

array(APP_INSTALLS, LINK_CLICKS, IMPRESSIONS, ...)

IN, NOT_IN

placement.page_types

Page types for placement of the adset of the object

adset

array(DESKTOPFEED, HOME, INSTAGRAMSTREAM, INSTAGRAMSTORY, ...)

ANY, ALL, NONE

budget_reset_period

Budget reset period of the adset of the object

adset

array(DAY, LIFETIME)

IN, NOT_IN

is_autobid

Autobid status of the adset of the object

adset

array(bool)

IN, NOT_IN

end_time

End epoch time of the adset of the object

adset

int

GREATER_THAN, LESS_THAN

hours_since_creation

Hours since created_time of the object

ad, adset, campaign

int

GREATER_THAN, LESS_THAN, IN_RANGE, NOT_IN_RANGE


*For every rule of evaluation type SCHEDULE or TRIGGER, we require you to specify either an entity_type or id filter.

By specifying an entity_type filter, you specify a dynamic object level for which to apply the rule. For example, if the entity_type is AD, this means that the rule will automatically evaluate every new Ad that is added under the account regardless of when you create the rule. By specifying an id filter instead, the rule will only apply to this static object of list of objects.

Note that you can use these in conjunction with multi-level filtering. For example, if you want a rule that applies to all Ads under some specified Ad Sets, you would have an entity_type filter of AD and an adset.id filter with the specified Ad Sets.

**By default, if you do not specify a delivery_info filter, we implicitly add one when evaluating the rule. This default filter has an operator of IN and a value of ['ACTIVE', 'LIMITED'], which means the rule will only evaluate objects that have active or limited delivery. This is an internal optimization given that all of our currently supported execution types only act upon active objects. Should we support execution types that act upon inactive objects in the future (e.g. UNPAUSE), we will remove this optimization. Should you need to act on active but not delivering objects, you should specify your own delivery_info filter.

Insights Filters

We evaluate insights filters against the current values returned from Insights API for a given time_preset.

Note that these filters will apply directly to the list or level of objects, and do not support multi-level filtering.

Also note that the units represented here are based on the currency's base in the Ads API. For example, for USD, the base unit is the cent, which means that a value of 1000 for spent would be equivalent to $10.00.

For a description of each of the fields below, see the Insights API docs.

All Insights filters support the following operators: GREATER_THAN, LESS_THAN, EQUAL, IN_RANGE, NOT_IN_RANGE

Below is a list of Insights filters and whether they are supported by Trigger Based Rules:

Insights Field Allowed for Trigger Based Rules?

impressions

Yes

social_impressions

Yes

unique_impressions

Yes

clicks

Yes

social_clicks

Yes

unique_clicks

Yes

spent

Yes

result

Yes

cpc

Yes

cpm

Yes

ctr

Yes

cpa

Yes

cpp

Yes

reach

Yes

actions

Yes

frequency

Yes

leadgens

No

link_ctr

No

result_rate

No

unique_social_impressions

No

cost_per_mobile_app_install

No

cost_per_initiate_checkout_fb

No

cost_per_purchase_fb

No

cost_per_add_to_cart_fb

No

cost_per_lead_fb

No

cost_per_add_payment_info_fb

No

cost_per_complete_registration_fb

No

cost_per_add_to_wishlist_fb

No

cost_per_search_fb

No

cost_per_view_content_fb

No

cost_per_link_click

No

unique_social_clicks

No

lifetime_impressions

No

lifetime_spent

No

today_spent

No

yesterday_spent

No

Execution Spec

The execution_spec of a rule determines the action that applies to all objects that pass evaluation. Schedule and Trigger Based Rules support different actions, and we denote the action in the execution_type field.

Execution Type Description Supported Evaluation Types

NOTIFICATION

Sends a notification to the user. By default, this sends an email if user_ids are provided and also a jeweled notification.

SCHEDULE

PAUSE

Pauses the objects, and also sends notifications as defined above.

SCHEDULE

CHANGE_BUDGET

Changes the budgets based on a defined change_spec. This applies to Ad Sets only.

SCHEDULE

CHANGE_BID

Changes the bids based on a defined change_spec. This applies to Ad Sets only.

SCHEDULE

ROTATE

Pauses the currently active Ad and activates the next Ad by id in the Ad Set. Requires an id filter of Ad Sets, and an entity_type filter of AD.

SCHEDULE

PING_ENDPOINT

Sends a ping to the application's subscription via Webhooks. See Trigger Based Rules for more details on setup.

TRIGGER

Additional information may be required in order to perform some of these actions. The execution_spec provides an optional execution_options array for users to specify these additional parameters. The array contains a list of execution_option objects, which themselves are dictionaries with keys of field, value, and operator just like the filter objects above.

Below, we define the supported execution options that one can use, which execution_type values they support, and how to structure them. Currently, the only supported operator for all options is EQUAL. Note that Trigger Based Rules do NOT require any execution options.

Execution Option Field Description Supported Execution Types Value (Example)

user_ids

Email recipients. Required for NOTIFICATION.

NOTIFICATION, PAUSE

array ([123, 456])

change_spec

Specifies the amount, limit, and unit. Required as a dictionary for the supported types.

CHANGE_BUDGET, CHANGE_BID

{ amount => int, limit => ?int, unit => ACCOUNT_CURRENCY or PERCENTAGE }

execution_count_limit

Specifies the max number of times action is taken for the rule. Default is no limit if not specified.

CHANGE_BUDGET, CHANGE_BID

int (123)

Status

The status of a rule determines whether the rule should be running. There are two statuses: ENABLED and DISABLED. To temporarily turn off a rule, edit the rule and set its status to DISABLED. To reactivate a rule, edit the rule and set its status back to ENABLED. To permanently remove a rule, delete it.

Schedule Based Rules

Monitor the state of your ads by checking them at a set interval to see if they meet the evaluation_spec criteria. For Schedule Based Rules, an additional schedule_spec is required in the rule spec:

curl \
-F 'name=Rule 1' \
-F 'evaluation_spec={
    ...
   }' \
-F 'execution_spec={
    ...
   }' \
-F 'schedule_spec={
     "schedule_type": "DAILY"
   }' \

-F "access_token=<ACCESS_TOKEN>" \
https://graph.facebook.com/<VERSION>/<AD_ACCOUNT_ID>/adrules_library

Schedule Spec

The schedule_spec of a rule determines how frequently to run it. We denote this interval in the schedule_type field.

Schedule Type Description

DAILY

Run the rule at midnight in the ad account's timezone.

HOURLY

Run the rule at the start of every hour.

SEMI_HOURLY

Run the rule at the start of every half-hour.

Here's an example of an evaluation_spec. This rule applies to all actively delivering Ads under the Ad Sets with ID 101, 102, or 103 that, in the last 7 days, have had more than 10000 impressions:

curl \
-F 'name=Rule 1' \
-F 'schedule_spec={
    ...
   }' \
-F 'evaluation_spec={
      "evaluation_type" : "SCHEDULE",
      "filters" : [
       {
         "field": "entity_type",
         "value": "AD",
         "operator": "EQUAL"
       },
       {
         "field": "time_preset",
         "value": "LAST_7_DAYS",
         "operator": "EQUAL"
       },
       {
         "field": "delivery_info",
         "value": ["ACTIVE"],
         "operator": "IN"
       },
       {
         "field": "adset.id",
         "value": [101, 102, 103],
         "operator": "IN"
       },
       {
         "field": "impressions",
         "value": 10000,
         "operator": "GREATER_THAN"
       }
     ]
   }' \
-F 'execution_spec={
    ...
   }' \
-F "access_token=<ACCESS_TOKEN>" \
https://graph.facebook.com/<VERSION>/<AD_ACCOUNT_ID>/adrules_library

Here is an example of an execution_spec. This rule increases the budget of all matching objects by 10%, with a maximum execution limit of 5 times:

curl \
-F 'name=Rule 1' \
-F 'schedule_spec={
    ...
   }' \
-F 'evaluation_spec={
    ...
   }' \
-F 'execution_spec={
     "execution_type": "CHANGE_BUDGET",
     "execution_options": [
       {
         "field": "change_spec",
         "value": {
           "amount": 10,
           "unit": "PERCENTAGE"
         },
         "operator": "EQUAL"
       },
       {
         "field": "execution_count_limit",
         "value": 5,
         "operator": "EQUAL"
       }
     ]
   }' \
-F "access_token=<ACCESS_TOKEN>" \
https://graph.facebook.com/<VERSION>/<AD_ACCOUNT_ID>/adrules_library

Trigger Based Rules

Set up Trigger Based Rules and actions to monitor and optimize your ads. You no longer have to manually manage ads which improves accuracy, and enables you to scale rules across thousands of Ads. You can now also monitor Ads metadata and stats changes in near real-time.

Set Up Webhooks

In order to use the only supported execution type PING_ENDPOINT, you will need to set up a subscription for your application through Webhooks.

Set up a callback URL, a Facebook App and Webhooks to get notifications from Rules API.

1. Set up a callback URL

See Webhooks Guide and create a callback URL that can handle the challenge and response during verification. The callback URL handles the data structure sent when a rule is triggered:

{
  object: 'application',
  entry: [{
    id: '<APPLICATION_ID>',
    time: 1468938744,
    changes: [{
      field: 'ads_rules_engine',
      value: {
        current_value: '1.30',
        trigger_field: 'CPC',
        rule_id: 1234,
        object_id: 4567
      }
    }],
  }],
}

2. Add ads_rules_engine Webhook to your app

Once the callback URL handles the challenge and response for verification, register it in your app when a rule is triggered:

  • Create a new Facebook App or use an existing one.
  • Add the Webhooks Product.
  • Create a New Subscription for an Application and select the ad_rules_engine.

Alternatively this can be done through the Graph API using an App access token and not a user access token:

curl \
-F "object=application" \
-F "callback_url=<CALLBACK_URL>" \
-F "fields=ads_rules_engine" \
-F "verify_token=<VERIFY_TOKEN>" \
-F "access_token=<APP_ACCESS_TOKEN>" \
"https://graph.facebook.com/<VERSION>/<APP_ID>/subscriptions"

See the Subscriptions Reference for details on APP_ID/subscriptions.

Trigger Object

The trigger object is the condition used to determine whether or not the rest of the filters should be applied. You can only have one trigger. If you have a rule that is based on multiple conditions being true, these additional conditions should be placed in the filters since the trigger and all filters are evaluated together with a logical AND.

The trigger object has the following structure, and belongs in the evaluation_spec:

Trigger Object Keys Description

type

The type of Trigger Based Rule. The current supported options are:

STATS_CHANGE: Given an Insights field, evaluate the rule every time this changes to satisfy the comparison

STATS_MILESTONE: Given an Insights field, evaluate the rule every time this reaches a multiple of the value

field

The underlying filter field

value

The underlying filter value

operator

The underlying filter operator

You can create Ad Rules that are triggered in two different ways: as STATS_MILESTONE or as STATS_CHANGE.

Creating a Stats Change Rule

When using STATS_CHANGE as the trigger type, the execution_spec will be triggered when the logical AND of the trigger and all filters is evaluated from false to true in the given time frame determined by the time_preset. If subsequent evaluations of the logical AND are also true, the execution_spec does not execute. However, if the evaluation of the logical AND changes from true to false, the execution_spec executes when it changes back to true again.

For this specific type of rule, the trigger operator can be any of GREATER_THAN, LESS_THAN, IN_RANGE, or NOT_IN_RANGE.

Here is an example of a stats change rule. Every time the cpc evaluated over the last 7 days crosses over 10, the trigger will be true. Pings will be sent for Ads under the Ad Sets with ID 101, 102, or 103 that have had more than 10000 impressions in the last 7 days and satisfy this trigger.

curl \
-F 'name=Rule 1' \
-F 'evaluation_spec={
      "evaluation_type" : "TRIGGER",
      "trigger" : {
        "type": "STATS_CHANGE",
        "field": "cpc",
        "value": 10,
        "operator": "GREATER_THAN",
      },
      "filters" : [
       {
         "field": "entity_type",
         "value": "AD",
         "operator": "EQUAL"
       },
       {
         "field": "time_preset",
         "value": "LAST_7_DAYS",
         "operator": "EQUAL"
       },
       {
         "field": "adset.id",
         "value": [101, 102, 103],
         "operator": "IN"
       },
       {
         "field": "impressions",
         "value": 10000,
         "operator": "GREATER_THAN"
       }
     ]
   }' \
-F 'execution_spec={
      "execution_type": "PING_ENDPOINT"
   }' \
-F "access_token=<ACCESS_TOKEN>" \
https://graph.facebook.com/<VERSION>/<AD_ACCOUNT_ID>/adrules_library

Creating a Stats Milestone Rule

With STATS_MILESTONE as type the evaluation_spec triggers when the field reaches a multiple of the value for the objects matching the conditions in the filters array.

For this specific type of rule, the trigger operator must be EQUAL, and the time_preset filter must have a value of LIFETIME.

We also have a more restrictive set of supported fields; any field not listed below is not supported as a trigger field, but can still be used as a filter in the list of filters. In addition, there are required minimum values for the trigger's value depending on the field.

Supported Trigger Field Values Minimum Value

impressions

1000

social_impressions

1000

unique_impressions

1000

reach

1000

clicks

100

social_clicks

100

unique_clicks

100

spent

10000

result

10

actions

10

Here is an example of a stats milestone rule. Every time the impressions reaches a multiple of 2000, the trigger will be true. A ping will be sent for any Ad that has more than 100 clicks in its lifetime and satisfies this trigger.

curl \
-F 'name=Rule 1' \
-F 'evaluation_spec={
      "evaluation_type" : "TRIGGER",
      "trigger" : {
        "type": "STATS_MILESTONE",
        "field": "impressions",
        "value": 2000,
        "operator": "EQUAL"
      },
      "filters" : [
       {
         "field": "entity_type",
         "value": "AD",
         "operator": "EQUAL",
       },
       {
         "field": "time_preset",
         "value": "LIFETIME",
         "operator": "EQUAL",
       },
       {
         "field": "clicks",
         "value": 100,
         "operator": "GREATER_THAN"
       }
     ]
   }' \
-F 'execution_spec={
      "execution_type": "PING_ENDPOINT"
   }' \
-F "access_token=<ACCESS_TOKEN>" \
https://graph.facebook.com/<VERSION>/<AD_ACCOUNT_ID>/adrules_library

API Calls

Read a Rule

curl -G   \
-d 'fields=name,evaluation_spec,execution_spec,status'   \
-d 'access_token=<ACCESS_TOKEN>'   \
https://graph.facebook.com/<VERSION>/<AD_RULE_ID>

Updating a Rule

In order to update a spec, you must provide all fields including those that are unchanged. Here is an example updating the rules trigger to instead be for every 1000 impressions. Updating a rule's status requires no spec changes.

curl \
-F 'evaluation_spec={
      "evaluation_type": ...,
      "trigger" : {
        "type": "STATS_MILESTONE",
        "field": "IMPRESSIONS",
        "value": 1000,
        "operator": "EQUAL"
      },
      "filters": ...
     ]
   }' \
-F 'access_token=<ACCESS_TOKEN>'   \
https://graph.facebook.com/<VERSION>/<AD_RULE_ID>

Here is an example updating the filters to instead select all Ads who have more than 200 clicks. The other filters such as entity_type and time_preset must still be in this update.

curl \
-F 'evaluation_spec={
      "evaluation_type": ...,
      "filters" : [
       {
         "field": "clicks",
         "value": 200,
         "operator": "GREATER_THAN",
       },
       {
       ...
     ]
   }' \
-F 'access_token=<ACCESS_TOKEN>'   \
https://graph.facebook.com/<VERSION>/<AD_RULE_ID>

Delete a Rule

curl -X DELETE \
-d 'access_token=<ACCESS_TOKEN>' \
https://graph.facebook.com/<VERSION>/<AD_RULE_ID>

Access a Rule's Execution History

We provide an endpoint to access history data for each of a Schedule Based Rule's executions. By default, this endpoint provides relevant data such as results and actions. You can also check the state of the rule at each execution to track edits.

curl -G   \
-d 'access_token=<ACCESS_TOKEN>' \
https://graph.facebook.com/<VERSION>/<AD_RULE_ID>/history

In addition, this endpoint supports three filtering mechanisms on the data: object_id, action, and hide_no_changes. You can filter the results by an object_id or an action to see results for only that object_id or action type. You can also filter the results using the hide_no_changes flag to exclude all executions for which there are no changes at all. You can combine these filters to further narrow your results.

curl -G   \
-d 'object_id=123' \
-d 'action=CHANGED_BID' \
-d 'hide_no_changes=true' \
-d "access_token=<ACCESS_TOKEN>" \
https://graph.facebook.com/<VERSION>/<AD_RULE_ID>/history