Supervisa el estado de tus anuncios en tiempo real. Una regla basada en activadores se evalúa en cuanto cambian los metadatos o los datos de insights de los objetos de anuncio pertinentes. Normalmente, la latencia de los cambios en los metadatos es de unos pocos segundos y la de los cambios en las insights, de unos pocos minutos (actualmente, la latencia P99 es de unos 7,5 minutos).
El campo schedule_spec
no se admite para las reglas basadas en activadores, ya que estas siempre se comprueban en tiempo real.
Por el momento, las reglas basadas en activadores solo están disponibles en la API; no se puede acceder a ellas mediante el Administrador de anuncios.
Los objetos trigger
definen cómo se evalúan las reglas. Todos los tipos de activación requieren un field
de activación, excepto METADATA_CREATION
. Las reglas basadas en activadores solo comprueban su condición cuando este campo cambia.
Las reglas basadas en activadores solo pueden tener un trigger
. Si tienes condiciones o restricciones en varias métricas, puedes añadir el resto como filters
.
El campo filters
se utiliza igual que en las reglas basadas en programación. Las reglas basadas en activadores solo superan la evaluación cuando el trigger
y todos los filters
satisfacen las comparaciones. Por tanto, un activador y un filtro son intercambiables si el cambio en uno de los campos conlleva un cambio en el otro. Por ejemplo, si quieres que una regla se active cuando cost_per_mobile_app_install
> X
Y spent
> Y
, puedes usar cost_per_mobile_app_install
o spent
como activador y el otro campo como uno de los filtros, ya que estos dos campos son dependientes.
El objeto trigger
pertenece a evaluation_spec
y sigue la siguiente estructura:
Claves de objetos de activación | Descripción |
---|---|
| Tipo de regla basada en activadores. Las opciones que se admiten actualmente son:
|
| Campo subyacente. No se usa para |
| Valor del filtro subyacente. No se usa para |
| Operador del filtro subyacente. No se usa para |
Puedes crear reglas de anuncios que se activen de cuatro formas distintas:
METADATA_CREATION
o METADATA_UPDATE
STATS_MILESTONE
o STATS_CHANGE
Esta regla se utiliza para supervisar cuando se crea un objeto publicitario. Solo se requiere el campo type
en la especificación de trigger
. Para los filtros, especifica el valor de entity_type
que quieres supervisar.
A continuación, se muestra un ejemplo de regla de creación de metadatos para supervisar la creación de todos los anuncios que tienen un objetivo determinado. Cada vez que se crea un nuevo anuncio en una campaña publicitaria con el objetivo APP_INSTALLS
, se envía una notificación.
curl -i -X POST \ -F 'name=Metadata Creation Example 1' \ -F 'evaluation_spec={ "evaluation_type" : "TRIGGER", "trigger" : { "type": "METADATA_CREATION", }, "filters" : [ { "field": "entity_type", "value": "AD", "operator": "EQUAL", }, { "field": "campaign.objective", "value": ["APP_INSTALLS"], "operator": "IN", }, ] }' \ -F 'execution_spec={ "execution_type": "PING_ENDPOINT" }' \ -F "access_token=<ACCESS_TOKEN>" \ "https://graph.facebook.com/<VERSION>/<AD_ACCOUNT_ID>/adrules_library"
Esta regla se utiliza para supervisar los cambios en los metadatos de un objeto publicitario. Consulta la lista de campos de metadatos admitidos. En la especificación de trigger
, field
es obligatorio, mientras que value
y operator
son opcionales.
Si te interesa conocer los cambios en un campo, independientemente de su valor, solo tienes que especificar la opción field
. A continuación, se muestra un ejemplo para enviar una notificación de Facebook cuando se cambia el presupuesto diario de un conjunto de anuncios.
curl -i -X POST \ -F 'name=Metadata Update Example 1' \ -F 'evaluation_spec={ "evaluation_type" : "TRIGGER", "trigger" : { "type": "METADATA_UPDATE", "field": "daily_budget", }, "filters" : [ { "field": "entity_type", "value": "ADSET", "operator": "EQUAL", }, ] }' \ -F 'execution_spec={ "execution_type": "NOTIFICATION" }' \ -F "access_token=<ACCESS_TOKEN>" \ "https://graph.facebook.com/<VERSION>/<AD_ACCOUNT_ID>/adrules_library"
Si solo te interesa un subconjunto de eventos, proporciona las opciones operator
y value
para mejorar la condición trigger
. A continuación, se muestra un ejemplo para recibir una notificación cuando se cambia el presupuesto diario de un conjunto de anuncios y es superior a 1000:
curl -i -X POST \ -F 'name=Metadata Update Example 2' \ -F 'evaluation_spec={ "evaluation_type" : "TRIGGER", "trigger" : { "type": "METADATA_UPDATE", "field": "daily_budget", "value": 1000, "operator": "GREATER_THAN" }, "filters" : [ { "field": "entity_type", "value": "ADSET", "operator": "EQUAL", }, ] }' \ -F 'execution_spec={ "execution_type": "PING_ENDPOINT" }' \ -F "access_token=<ACCESS_TOKEN>" \ "https://graph.facebook.com/<VERSION>/<AD_ACCOUNT_ID>/adrules_library"
Con STATS_MILESTONE
como type
, evaluation_spec
se activa cuando field
alcanza un múltiplo del valor de value
para los objetos que coinciden con las condiciones de la matriz filters
.
Para este tipo de regla en concreto, el operator
de activación debe ser EQUAL
y el filtro time_preset
debe tener un valor de LIFETIME
.
Tiene un conjunto de campos admitidos más restringido. Cualquier campo que no aparezca a continuación, no se admitirá como field
de activación, aunque se podrá utilizar como filtro en la lista de filters
. Además, el campo value
del activador tiene valores mínimos obligatorios en función de field
.
Valores admitidos para el campo de activación | Valor mínimo |
---|---|
| 1000 |
| 1000 |
| 1000 |
| 10 |
| 10 |
| 1000 (centavos) |
| 5 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
A continuación, se muestra un ejemplo de regla para hitos en las estadísticas que envía una notificación cuando alguien comenta en tu publicación:
curl \ -F 'name=Rule 1' \ -F 'evaluation_spec={ "evaluation_type" : "TRIGGER", "trigger" : { "type": "STATS_MILESTONE", "field": "post_comment", "value": 1, "operator": "EQUAL" }, "filters" : [ { "field": "entity_type", "value": "CAMPAIGN", "operator": "EQUAL", }, { "field": "time_preset", "value": "LIFETIME", "operator": "EQUAL", }, ] }' \ -F 'execution_spec={ "execution_type": "PING_ENDPOINT" }' \ -F "access_token=<ACCESS_TOKEN>" \ https://graph.facebook.com/<VERSION>/<AD_ACCOUNT_ID>/adrules_library
Cuando se usa STATS_CHANGE
como type
de activación, execution_spec
se activa cuando el operador lógico AND
del activador y todos los filtros se evalúan de false
a true
en un time_preset
determinado.
Si las evaluaciones posteriores del operador lógico AND
también resultan verdaderas, execution_spec
no se ejecuta. Sin embargo, si la evaluación del operador lógico AND
cambia de true
a false
, execution_spec
se ejecuta cuando vuelve a cambiar a true
.
Para este tipo de regla en concreto, el operator
de activación puede ser GREATER_THAN
, LESS_THAN
, IN_RANGE
o NOT_IN_RANGE
.
A continuación, se muestra un ejemplo de regla para cambios en las estadísticas para que cada vez que un anuncio supere las 5000 personas y los diez USD por compra en los últimos tres días, se ponga en pausa.
curl \ -F 'name=Rule 1' \ -F 'evaluation_spec={ "evaluation_type" : "TRIGGER", "trigger" : { "type": "STATS_CHANGE", "field": "cost_per_purchase_fb", "value": 1000, "operator": "GREATER_THAN", }, "filters" : [ { "field": "entity_type", "value": "AD", "operator": "EQUAL" }, { "field": "time_preset", "value": "LAST_3_DAYS", "operator": "EQUAL" }, { "field": "reach", "value": 5000, "operator": "GREATER_THAN" } ] }' \ -F 'execution_spec={ "execution_type": "PAUSE" }' \ -F "access_token=<ACCESS_TOKEN>" \ https://graph.facebook.com/<VERSION>/<AD_ACCOUNT_ID>/adrules_library
Cuando se usa DELIVERY_INSIGHTS_CHANGE
como type
de activación, la regla se activa cuando todos los filtros definidos en evaluation_spec
se evalúan como true
y el activador definido en evaluation_spec
solo cambia de false
a true
.
En las evaluaciones posteriores, si los filtros y el activador se siguen evaluando como true
, la regla no se vuelve a activar.
Para utilizar el tipo de ejecución PING_ENDPOINT
, debes configurar una suscripción para la aplicación mediante webhooks. Configura una URL de devolución de llamada, una aplicación de Facebook y webhooks para recibir notificaciones de la API de reglas.
Consulta la guía de webhooks y crea una URL de devolución de llamada que pueda gestionar retos y respuestas durante la verificación. La URL de devolución de llamada gestiona la estructura de datos enviada cuando se activa una regla:
{ object: 'application', entry: [{ id: '<APPLICATION_ID>', time: 1468938744, changes: [{ field: 'ads_rules_engine', value: { 'rule_id': 1234, 'object_id': 5678, 'object_type': 'ADSET', 'trigger_type': 'STATS_CHANGE', 'trigger_field': 'COST_PER_LINK_CLICK', 'current_value': '15.8', } }], }], }
El campo current_value
es una cadena con codificación JSON. Su valor puede ser una cadena con comillas dobles, un número o una matriz que empiece con [
(corchete izquierdo) y termine con ]
(corchete derecho).
ads_rules_engine
a la aplicaciónUna vez que la URL de devolución de llamada gestiona los retos y las respuestas para la verificación, regístrala en la aplicación cuando se active una regla:
ad_rules_engine
.Como alternativa, este proceso se puede realizar mediante la API Graph y usar un identificador de acceso a la aplicación en lugar de un identificador de acceso de usuario:
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"
Consulta la Referencia de suscripciones para obtener más información sobre APP_ID/subscriptions
.