Para crear reglas de reequilibrio del presupuesto basadas en el ROI, es importante comprender cada componente. ROI significa retorno de la inversión (por sus siglas en inglés).
En esta página, conocerás cada componente de la regla de reequilibrio y de qué manera cada parámetro afecta la manera en que se ejecuta la regla.
En el caso de las reglas de reequilibrio, se recomienda usar un calendario DAILY
o CUSTOM
, ya que la acción no debería ocurrir con frecuencia.
Los criterios de evaluación funcionan armoniosamente con rebalance_spec
para determinar las listas de objetos se ven afectadas por el reequilibrio.
Para todos los tipos de reequilibrio, la lista de objetos que aprueban la evaluación es la fuente de presupuestos. La lista de destinatarios varía según el tipo de reequilibrio especificado. En la mayoría de los casos (por ejemplo, si se especificó EVEN
), los destinatarios son los objetos que no aprobaron la evaluación.
Por ejemplo, si mi criterio de regla de tipo EVEN
es cost_per_mobile_app_install
> 2.50
, quiere decir que se pausarán todos los conjuntos de anuncios que tengan un costo de instalación de app para dispositivos móviles superior a 2,50, y sus presupuestos se moverán a todos los conjuntos de anuncios que tengan un costo de instalación de app para dispositivos móviles inferior o igual que 2,50.
rebalance_spec
determina exactamente cómo obtienen su presupuesto los destinatarios. Hay cinco parámetros:
Campo | Descripción |
---|---|
| Obligatorio. Determina cómo se asignan los presupuestos. Si el valor no es Valores admitidos: |
| Opcional. Especifica la métrica de estadísticas utilizada para clasificar a los destinatarios. Es obligatorio si Valores admitidos: un campo de estadísticas, como |
| Opcional. Especifica el número (K) de destinatarios. La combinación de esto, Valores admitidos: un número entero positivo, como |
| Opcional. Especifica si permites que los presupuestos se asignen entre campañas de anuncios (o no). Si no se especifica o es Valores admitidos: un valor booleano, como |
| Opcional. Especifica si los destinatarios se deben clasificar de mayor a mejor (o a la inversa) respecto de sus valores de Valores admitidos: un valor booleano, como |
Hay algunos matices específicos respecto de esta acción:
Si los conjuntos de anuncios que se van a reequilibrar contienen presupuestos diarios y totales, los separamos en dos categorías. Por lo tanto, los conjuntos de anuncios solo mueven sus presupuestos diarios a otros conjuntos de anuncios que tienen presupuestos diarios. Lo mismo sucede con los presupuestos totales.
En el caso de los conjuntos de anuncios con presupuestos totales, tomamos el presupuesto sobrante, la diferencia entre el presupuesto y el gasto totales, cuando determinamos la cantidad del presupuesto que pueden asignar. Esto garantiza que no se cambie el presupuesto total en el nivel de la campaña de anuncios.
rebalance_spec
En el caso de los tipos EVEN
y PROPORTIONAL
, pausamos los objetos coincidentes (los donantes del presupuesto para los destinatarios). Cuando pausamos estos objetos, no ajustamos sus presupuestos de ninguna manera por los siguientes motivos:
Esto significa que si vuelves a habilitar el conjunto de anuncios después, conservará el mismo presupuesto que tenía antes. Esto se puede ver cuando se interactúa con el objeto pausado y se obtienen sus datos de presupuesto.
En el caso del tipo NO_PAUSE_PROPORTIONAL
, no pausamos los objetos coincidentes. Determinamos cuánto presupuesto ajustar mirando todos los objetos (donantes y destinatarios) juntos y clasificando su rendimiento. Esto garantiza que el presupuesto solo se traslade de donantes a destinatarios. Esta configuración evita una situación en la que el reequilibrio da como resultado un conjunto de anuncios con buen rendimiento, en el que se dona a un conjunto de anuncios con bajo rendimiento simplemente debido a la cantidad de presupuesto que tiene. Consulta el siguiente ejemplo para obtener más información.
En el caso del tipo MATCHED_ONLY_PROPORTIONAL
, solo miramos los objetos coincidentes. Nuevamente, no los pausamos. Los clasificamos entre ellos y redistribuimos sus presupuestos en función de su rendimiento. Esto significa que tomamos el presupuesto total de todos los donantes y lo compartimos proporcionalmente con la misma lista de donantes. Consulta el siguiente ejemplo para obtener más información.
En el caso de los tipos que terminan en PROPORTIONAL
, distribuimos más presupuesto a conjuntos de anuncios que tienen mejor rendimiento, en función del target_field
definido. Por ejemplo, si la métrica es reach
y tiene dos conjuntos de anuncios destinatarios que tienen 10 y 20 reach
, asignamos 33,3% y 66,6% de todo el presupuesto a estos conjuntos de anuncios, respectivamente. Si el tipo es EVEN
, recibirían 50%.
is_inverse
La marca is_inverse
es útil para métricas como cost_per_mobile_app_install
, donde un número de métrica más bajo demuestra que el conjunto de anuncios tiene mejor rendimiento. Esto se recalca en el siguiente ejemplo y significa que los conjuntos de anuncios con un valor inferior obtienen una mayor parte de la asignación del presupuesto.
Este es un ejemplo de una regla de reequilibrio que realiza lo siguiente:
Definimos "con bajo rendimiento" como un cost_per_mobile_app_install
alto y estable. Asignamos proporcionalmente el presupuesto de todos los conjuntos de anuncios con bajo rendimiento a los mejores 10 conjuntos de anuncios de la cuenta publicitaria. Esta regla se ejecuta todos los días a las 8 horas, mientras se observan los datos totales.
curl \ -F 'name=Test Rebalance Rule' \ -F 'schedule_spec={ "schedule_type": "CUSTOM", "schedule": [ { "start_minute": 480 } ] }' \ -F 'evaluation_spec={ "evaluation_type": "SCHEDULE", "filters": [ { "field": "entity_type", "value": "ADSET", "operator": "EQUAL" }, { "field": "time_preset", "value": "LIFETIME", "operator": "EQUAL" }, { "field": "mobile_app_install", "value": 100, "operator": "GREATER_THAN" }, { "field": "cost_per_mobile_app_install", "value": 3.0, "operator": "GREATER_THAN" } ] }' \ -F 'execution_spec={ "execution_type": "REBALANCE_BUDGET", "execution_options": [ { "field": "rebalance_spec", "value": { "type": "INVERSE_PROPORTIONAL", "target_field": "cost_per_mobile_app_install", "target_count": 10, "is_cross_campaign": true }, "operator": "EQUAL" }, ] }' \ -F "access_token=<ACCESS_TOKEN>" \ https://graph.facebook.com/<VERSION>/<AD_ACCOUNT_ID>/adrules_library
Aquí, la regla hace lo siguiente:
curl \ -F 'name=Test Rebalance Rule' \ -F 'schedule_spec={ "schedule_type": "DAILY" }' \ -F 'evaluation_spec={ "evaluation_type": "SCHEDULE", "filters": [ { "field": "entity_type", "value": "ADSET", "operator": "EQUAL" }, { "field": "time_preset", "value": "LIFETIME", "operator": "EQUAL" }, { "field": "impressions", "value": 8000, "operator": "GREATER_THAN" }, { "field": "audience_reached_percentage", "value": 70, "operator": "GREATER_THAN" } ] }' \ -F 'execution_spec={ "execution_type": "REBALANCE_BUDGET", "execution_options": [ { "field": "rebalance_spec", "value": { "type": "EVEN" }, "operator": "EQUAL" }, ] }' \ -F "access_token=<ACCESS_TOKEN>" \ https://graph.facebook.com/<VERSION>/<AD_ACCOUNT_ID>/adrules_library
Aquí hay un ejemplo que aprovecha el tipo NO_PAUSE_PROPORTIONAL
. En este caso, el presupuesto se reasigna de conjuntos de anuncios dentro de las campañas de anuncios de aquellos con una pequeña cantidad de reproducciones de video. Sin embargo, en este caso, los conjuntos de anuncios no se pausan y quedan con una cantidad proporcional del presupuesto.
Este es un ejemplo numérico de lo que sucede:
1-5
con video_view
de 1-5
, con un presupuesto diario de 3000
cada uno y la siguiente regla. 6000
de los conjuntos de anuncios 1
y 2
, y determinamos cómo distribuirlo proporcionalmente. En este caso, cada conjunto de anuncios tiene proporciones de 1/15
de hasta 5/15
. 400
, 800
, 4200
, 4600
y 5000
, respectivamente. Esto garantiza que todos los destinatarios (conjuntos de anuncios 1
, 2
y 3
) aumenten siempre su presupuesto.curl \ -F 'name=Test Rebalance Rule' \ -F 'schedule_spec={ "schedule_type": "DAILY" }' \ -F 'evaluation_spec={ "evaluation_type": "SCHEDULE", "filters": [ { "field": "entity_type", "value": "ADSET", "operator": "EQUAL" }, { "field": "time_preset", "value": "LIFETIME", "operator": "EQUAL" }, { "field": "video_view", "value": 3, "operator": "LESS_THAN" }, ] }' \ -F 'execution_spec={ "execution_type": "REBALANCE_BUDGET", "execution_options": [ { "field": "rebalance_spec", "value": { "type": "NO_PAUSE_PROPORTIONAL", "target_field": "video_view" }, "operator": "EQUAL" }, ] }' \ -F "access_token=<ACCESS_TOKEN>" \ https://graph.facebook.com/<VERSION>/<AD_ACCOUNT_ID>/adrules_library
Por último, aquí hay un ejemplo que aprovecha MATCHED_ONLY_PROPORTIONAL
. En este caso, no tienes que preocuparte por objetos que no tienen coincidencia. El foco está en los conjuntos de anuncios que cumplen con los filtros de la regla. Puedes usar el mismo ejemplo anterior, salvo que ahora no es necesario determinar las dos listas según el bajo rendimiento de los conjuntos de anuncios.
Con el mismo ejemplo numérico anterior, terminaríamos usando todos los presupuestos del grupo (15000
) y distribuyéndolos proporcionalmente. Como resultado, los conjuntos de anuncios 1-5
terminarían con un presupuesto de 1000-5000
.
La principal desventaja de este type
es que no hay garantía de que los conjuntos de anuncios con mejor rendimiento no terminen perdiendo presupuesto, en especial, en los casos en los que hay valores de presupuesto no equilibrados. Con todo lo demás igual, si el conjunto de anuncios 5
comenzó con un presupuesto de 18000
, terminaría perdiendo 8000
del presupuesto.
curl \ -F 'name=Test Rebalance Rule' \ -F 'schedule_spec={ "schedule_type": "DAILY" }' \ -F 'evaluation_spec={ "evaluation_type": "SCHEDULE", "filters": [ { "field": "entity_type", "value": "ADSET", "operator": "EQUAL" }, { "field": "time_preset", "value": "LIFETIME", "operator": "EQUAL" }, ] }' \ -F 'execution_spec={ "execution_type": "REBALANCE_BUDGET", "execution_options": [ { "field": "rebalance_spec", "value": { "type": "MATCHED_ONLY_PROPORTIONAL", "target_field": "video_view" }, "operator": "EQUAL" }, ] }' \ -F "access_token=<ACCESS_TOKEN>" \ https://graph.facebook.com/<VERSION>/<AD_ACCOUNT_ID>/adrules_library