Las entradas del registro de cambios se clasifican de esta forma:
Las nuevas funciones, los cambios y las retiradas solo atañen a esta versión. Los cambios importantes en 90 días afectan a todas las versiones.
Los cambios importantes no se incluyen aquí porque no están vinculados a publicaciones concretas.
Fecha de lanzamiento: 18 de abril de 2017 | Disponible hasta: 18 de julio de 2019
Operación de lectura tras la de escritura: las solicitudes POST
de la API Graph ahora admiten la devolución de valores especificados de un objeto durante la misma solicitud de escritura, lo que evita el envío y la devolución de los datos para los clientes. Si se especifica un parámetro fields
(explicación de la sintaxis), la solicitud realizará en primer lugar la operación de escritura y, a continuación, la de lectura del objeto creado o actualizado, seleccionando los campos con el parámetro fields
, como respuesta. Ahora se admite la operación de lectura tras la de escritura en todas las versiones de la API Graph. Para obtener más información, consulta la página de documentación.
Nuevo campo short_names
en el objeto de usuario. Se ha añadido el siguiente campo al extremo user
:
short_name
: first_name
supone que el procedimiento globalmente aceptado para hacer referencia a una persona de forma amigable es mediante su nombre. Sin embargo, en muchas culturas (especialmente en la china, la japonesa, la coreana, la tailandesa o la índica, entre otras) no es apropiado dirigirse a las personas por su nombre de pila. El nuevo método “short_name” tiene en cuenta las reglas específicas de cada cultura para dirigirse a las personas con un nombre corto. Es decir, los usuarios de EE. UU. seguirán viendo a sus amigos en China, Japón, Corea y la India con sus nombres de pila, pero los amigos de estas mismas personas que residan en Asia Oriental o Asia Meridional verán a sus amigos con sus nombres y apellidos.Asignación de páginas de aplicaciones empresariales: el nodo user
tiene dos nuevos perímetros, ids_for_pages
y ids_for_apps
, con los que se puede cancelar la referencia al identificador de un usuario para una aplicación o una página. El perímetro ids_for_pages
devuelve otros identificadores del usuario para páginas que pertenecen a la misma empresa. Del mismo modo, el perímetro ids_for_apps
devuelve otros identificadores del usuario para aplicaciones que son propiedad de la misma empresa. Para obtener más información, consulta Conectar con personas en varias aplicaciones y bots en Messenger.
Compatibilidad con POST en páginas para añadir páginas a vídeos que se usan en publicaciones cruzadas: POST /{page_id}/crossposting_pages
permite aprobar y aceptar solicitudes de relaciones de uso en publicaciones cruzadas procedentes de otras páginas.
Serialización de los identificadores de webhooks como cadenas: los identificadores numéricos se convierten en cadenas en esta actualización del webhook.
Permisos detallados: esta nueva función brinda a los usuarios más control sobre los permisos de objetos administrados. Durante el paso de inicio de sesión, si se concede un permiso relacionado con páginas, empresas o grupos, el usuario tendrá la opción de seleccionar a qué objetos administrados se aplica dicho permiso. En consecuencia, es posible que veas un número menor de páginas, empresas y grupos. Los usuarios pueden administrar los siguientes permisos de forma detallada:
Lugar actual. Se han añadido los campos siguientes:
GET /current_place/results
: ayuda a determinar la ubicación actual de una persona mediante señales de ubicación. Se requiere el permiso del usuario.POST /current_place/feedback
: te permite proporcionar comentarios sobre si realmente ha estado allí. Para obtener más información, consulta Gráfica de lugares.GET /search?type=place
. Se han añadido los parámetros siguientes:
categories
: buscar por categoría.matched_categories
: indica con qué categorías coincide el lugar resultante. Debe usarse con categories
.Tiempo dedicado a las métricas de vídeo para una página. Se han añadido las métricas siguientes: Para obtener más información, consulta Métrica de insights /{object-id}/insights/{metric}.
page_video_view_time
: tiempo dedicado a los vídeos en la página.post_video_view_time_by_country_id
: tiempo dedicado a los vídeos en la página por país. Recepción de valores modificados por parte de las aplicaciones para las actualizaciones del perfil del usuario con actualizaciones de webhooks: cuando un usuario modifica un campo, la aplicación puede recibir el nuevo valor como parte de la actualización sin necesidad de comprobarlo. Anteriormente, siempre que un usuario modificaba alguno de los campos, se notificaba a la aplicación este cambio sin enviar el nuevo valor.
Documentación: ahora los webhooks disponen de documentación de referencia sobre temas y campos a los que te puedes suscribir. Esta documentación está disponible en el sitio de Facebook para desarrolladores, en la referencia de webhooks de la API Graph.
Herramienta de remitente de ejemplo: con esta nueva herramienta, los desarrolladores pueden realizar pruebas con mayor facilidad en la estructura de actualización de webhooks antes de suscribirse a un tema. Anteriormente, los desarrolladores debían suscribirse a un campo y, a continuación, intentar activar la actualización realizando los cambios correspondientes mediante Facebook. Por ejemplo, supongamos que una aplicación quería averiguar cuándo un usuario (de entre los que habían instalado la aplicación y concedido los permisos necesarios) cambiaba su foto de perfil. La aplicación se tenía que suscribir al campo de la foto de perfil en la estructura de webhooks. Sin embargo, para comprobar si la operación se había completado correctamente, tenías que cambiar la foto de perfil de un usuario que hubiera instalado la aplicación para ver la estructura de la actualización que se enviaba. La herramienta de remitente de ejemplo permite a las aplicaciones realizar pruebas en la estructura de la actualización sin necesidad de realizar cambios innecesarios. La herramienta de remitente de ejemplo está disponible en la sección “Webhooks” del panel de la aplicación.
Control de versiones: ahora los webhooks utilizan las mismas versiones que la API Graph. Las suscripciones a webhooks existentes se ejecutarán en la versión más antigua compatible de la aplicación. Anteriormente, las suscripciones a webhooks no admitían el control de versiones y solo se podían realizar cambios importantes. Para obtener más información sobre las versiones de webhooks, consulta la sección sobre el control de versiones.
La API de lotes devuelve un error en lugar de una respuesta nula para los elementos solicitados cancelados en dicha API. Para obtener más información, consulta API Graph, Realización de solicitudes por lotes.
GET /{url}/share
. Se ha eliminado el extremo share
y se ha sustituido por:
engagement
con los subcampos siguientes:
comment_count
comment_plugin_count
reaction_count
share_count
/{page-id}/feed
: las publicaciones a las que se asignaron fechas anteriores se incluirán en la solicitud {page_id}/feed
si el valor backdated_time
de la publicación está en el intervalo de tiempo de since
y until
. El campo created_time
indica la hora de creación real. (Consulta los cambios en Publicaciones a continuación.)
page-restaurant-services
: todos los campos ahora devuelven false
o true
en lugar de 0
o 1
.
overall_star_rating
: si hay pocas calificaciones o ninguna, no se devolverá el campo overall_star_rating
. GET /{post-id}
. Se ha añadido el siguiente campo a este extremo:
promotable_id
: algunas publicaciones no podían promocionarse anteriormente (solo se podía promocionar su contenido). En estos casos, el campo id
devolvía el identificador del contenido en lugar del correspondiente a la publicación. Ahora, las publicaciones siempre devuelven su propio identificador en el campo id
y, al promocionar la publicación, se usa un nuevo campo promotable_id
que se añade al extremo GET {post-id}
.created_time
de la publicación. En su lugar, duplicará el original, pero con created_time
y backdated_time
establecidos en el nuevo valor. La publicación original conservará su valor created_time
anterior y obtendrá el nuevo valor backdated_time
. Por último, GET {post-id}/feed
ya no devolverá la publicación original, sino el duplicado recién creado.Expón una URL de vista previa del panel de control para vídeos en directo en lugar de una URL RTMP.
GET /{page_id}/crosspost_pending_approval_pages
: enumera todas las páginas a las que tu página ha enviado solicitudes de publicación cruzada, pero que todavía no han aceptado.
GET /{page_id}/crosspost_whitelisted_pages
: enumera todas las páginas a las que has concedido permiso para usar tu contenido en publicaciones cruzadas.
POST /{video_id}/allow_crossposting_for_pages = [{"page_id": {page_id}, "allow": {true/false}]
: concede o anula el permiso de usar un vídeo en concreto en publicaciones cruzadas a determinadas páginas de tu lista de autorizados con dicho permiso.
POST /{page_id}/crossposting_pages=[{"page_id": {page_id}, "allow": false, "action": "EXPIRE_ALL_CROSSPOSTS_ON_SHARED_ASSETS"}]
: elimina páginas de tu lista de autorizados para publicaciones cruzadas y hace que caduque todo el contenido usado anteriormente en publicaciones cruzadas.
POST /{page_id}/crossposting_pages=[{"page_id": {page_id}, "allow": false, "action": "NO_ACTION"}]
: elimina páginas de tu lista de autorizados para publicaciones cruzadas sin que afecte al contenido usado anteriormente en este tipo de publicaciones.
GET /{app-id}/subscriptions
: ahora este extremo devuelve versiones para los campos. Antes de que se incorporara el control de versiones de webhooks, el extremo devolvía solo una lista de campos suscritos. Ahora, los extremos devuelven la lista de campos con sus respectivas versiones.GET /{message-id}
. Se ha retirado el siguiente campo:
subject
GET /{thread-id}
. Se ha retirado el siguiente campo:
tags
Se han retirado los campos siguientes de los perímetros y los cuadros de diálogo que permiten adjuntar enlaces a publicaciones:
caption
description
name
picture
thumbnail
A continuación, se incluyen los perímetros y los cuadros de diálogo para los que se han retirado dichos campos:
POST /{event-id}/feed
POST /{group-id}/feed
POST /{page-id}/feed
POST /{user-id}/feed
share
y feed
paid
y organic
. Se han retirado los siguientes campos de webhooks del tema de usuario:
about_me
birthday_date
contact_email
current_location
education_history
hometown_location
sex
statuses
tv
work_history
En su lugar, utiliza:
about
birthday
education
email
gender
hometown
location
status
television
work
Crea campañas de Canvas en Facebook con la API de marketing. Gracias a la imagen, el sonido y el movimiento, el formato de vídeo hace que los anunciantes obtengan mejores resultados en cuanto a los objetivos de respuesta directa y de marca. Para obtener más información, consulta API de marketing > Anuncios de Canvas.
Calidad del catálogo de anuncios dinámicos: hemos añadido nuevas API para ayudarte a poner en circulación anuncios dinámicos con éxito: la API de comprobaciones y la de calidad. La API de comprobaciones permite verificar que el origen de las señales proporcione suficiente información para entregar los anuncios correctos si se usan anuncios dinámicos. La API de calidad permite verificar que la cantidad y la calidad de la información del catálogo y de la lista sean suficientes para entregar anuncios dinámicos. Para obtener más información, consulta Anuncios dinámicos > Calidad del catálogo y las señales.
Varias imágenes para un mismo elemento: muestra varias imágenes para un mismo elemento en anuncios dinámicos con el formato por secuencia. Ahora pueden utilizarse hasta 20 imágenes de un catálogo para representar un mismo elemento en anuncios dinámicos con el formato por secuencia. Así puedes mostrar un único elemento, como un hotel o un destino, con varias imágenes. Puedes aprovechar esta función con dos opciones: force_single_link = true
y show_multiple_images = true
. Para obtener más información, consulta Anuncios dinámicos > Administración de anuncios > Plantilla de contenido.
Texto del anuncio: ahora puedes duplicar tus campañas, conjuntos de anuncios y anuncios existentes con la API de texto del anuncio. De este modo, no tendrás que volver a crear los anuncios de cero cada vez. En lugar de esto, puedes duplicar los que ya funcionan y crear recipientes de plantillas de anuncio. Para obtener más información, consulta Contenido, ubicación y vista previa.
Alcance diario estimado: hay un nuevo extremo /delivery_estimate
en los niveles del conjunto de anuncios y de la cuenta publicitaria. Este extremo permite obtener estimaciones de pujas y una predicción de resultados a partir de las conversiones y el alcance diarios de un conjunto de anuncios determinado. Para obtener más información, consulta Segmentación > Alcance diario estimado.
API de motor de reglas: usa esta API para administrar fácilmente tus anuncios con mayor eficiencia y tomar decisiones más inteligentes en función de las reglas empresariales que tú definas. El motor de reglas sigue un modelo basado en notificaciones de inserción. Por ello, en lugar de tener que consultar la API continuamente para obtener información actualizada sobre los anuncios, te enviaremos notificaciones de inserción de forma proactiva y realizaremos las acciones que especifiques, siempre que se cumplan los criterios establecidos mediante las reglas. Para obtener más información sobre la API de motor de reglas, haz clic aquí.
API de lotes: agrupa las solicitudes y envíalas de forma asíncrona. Agrupa varias llamadas a la API Graph en una única solicitud HTTP y ejecútalas de forma asíncrona sin necesidad de bloquear. También puedes especificar dependencias entre operaciones relacionadas. Facebook procesa las operaciones independientes de forma paralela y, las operaciones dependientes, de forma secuencial. Para obtener más información, consulta Solicitudes asíncronas y por lotes > API de lotes.
effective_
, puedes determinar las ubicaciones de anuncios reales que Facebook ofrece para el objetivo publicitario y la ubicación que tú especifiques. Asimismo, con la API de recomendaciones puedes averiguar por qué no se incluyen algunas ubicaciones. Para obtener más información, consulta Opciones avanzadas de segmentación > Ubicación eficaz.Ubicación de vídeo sugerido: se seleccionaba automáticamente si usabas la ubicación de la sección de noticias de Facebook, ya que formaba parte de esta. A partir de la versión 2.9, se diferencia entre las ubicaciones de vídeo sugerido y de la sección de noticias para que puedas descartar la primera aunque decidas usar la segunda. En la versión 2.8 y anteriores, si usabas la ubicación de la sección de noticias de Facebook, dejaremos de entregar los anuncios automáticamente en la ubicación de vídeo sugerido cuando selecciones la de la sección de noticias.
Objetivo de difusión local: se ha retirado el objetivo de campaña LOCAL_AWARENESS
. A partir de la versión 2.9, no se aceptará LOCAL_AWARENESS
como objetivo al crear nuevas campañas. Si deseas fomentar la difusión local con conjuntos de anuncios de ubicación única, usa campañas con el objetivo REACH
. Ya no se admite LOCAL_AWARENESS
con varias ubicaciones. Si tienes campañas en curso con este objetivo, podrás seguir consultándolas y editándolas, e incluso crear nuevos anuncios y conjuntos de anuncios para ellas. Si optas por copiar campañas en curso, el tipo de campaña determinará si puedes hacerlo o no. En el caso de campañas de ubicación única y con el objetivo LOCAL_AWARENESS
, las copiamos con el parámetro REACH
especificado. Si usas LOCAL_AWARENESS
con varias ubicaciones, no podrás copiar la campaña.
Objetivos de anuncios para móviles: para simplificar los objetivos de los anuncios para móviles, estamos retirando CanvasAppEngagement
, CanvasAppInstalls
, MobileAppInstalls
y MobileAppEngagement
, denominados CAE
, MAE
, CAI
y MAI
, respectivamente. A partir de la versión 2.9 no se pueden crear nuevas campañas con estos cuatro objetivos. En su lugar, pueden usarse las opciones siguientes:
Conjuntos de anuncios CAE
con campañas LINK_CLICKS
: usa LINK_CLICKS
para crear campañas con anuncios de interacción con aplicaciones de página principal.
Conjuntos de anuncios MAE
con objetivos de campaña LINK_CLICKS
o CONVERSIONS
: cambia a LINK_CLICKS
o CONVERSIONS
para crear campañas con anuncios de interacción con aplicaciones para móviles.
Conjuntos de anuncios CAI
con APP_INSTALLS
: usa APP_INSTALLS
para crear campañas con anuncios sobre la descarga de aplicaciones para página principal.
MAI
con APP_INSTALLS
: usa APP_INSTALLS
para crear campañas con anuncios sobre la descarga de aplicaciones para móviles.
Compatibilidad de los objetivos de anuncios para móviles: si duplicas campañas CAE
, MAE
, CAI
y MAI
con las herramientas de Facebook o la API de marketing, estos objetivos retirados se convierten automáticamente en sus correspondientes equivalentes de la versión 2.9:
Campañas MAI
o CAI
: se convierten en campañas con el objetivo APP_INSTALLS
.
Campañas CAE
: se convierten en campañas con el objetivo LINK_CLICKS
.
Campañas MAE
: se convierten en campañas con los objetivos LINK_LICKS
o CONVERSIONS
, en función de las optimizaciones que especifiques para los conjuntos de anuncios de la campaña. Si hay conjuntos de anuncios secundarios optimizados con OFFSITE_CONVERSION
, las campañas MAE
se convierten en campañas CONVERSIONS
. Si no los hay, las campañas MAE
se convierten en campañas LINK_CLICKS
.
Categorías bloqueadas: se están retirando algunas categorías de Audience Network, vídeo in-stream y artículos instantáneos en favor de otras más unificadas en estas ubicaciones. Estas categorías ayudan a impedir la aparición de anuncios cuyo contenido pueda resultar inapropiado, como los relacionados con el juego o el alcohol. Se han retirado las categorías politics
y religion
. Se encuentran disponibles las categorías siguientes:
Para artículos instantáneos y Audience Network: debated_social_issues
, mature_audiences
, tragedy_and_conflict
, dating
y gambling
.
Para vídeos in-stream: debated_social_issues
, mature_audiences
y tragedy_and_conflict
.
Se ha retirado SUPPLEMENTAL_MEDIA_ID
del contenido de los anuncios en los niveles de anuncio y cuenta publicitaria. Este campo ya no se puede leer.
Se ha retirado ACTION_SPEC
del contenido de los anuncios. Anteriormente se utilizaba con historias patrocinadas que ya no se admiten.
Se han retirado los campos actor_image_hash
, actor_image_url
y actor_name
del contenido de los anuncios en las versiones 2.9 y 2.8. Anteriormente se utilizaban con action_spec
, que también se ha retirado.
Se han retirado link_title
y link_description
de call_to_action
en el contenido de los anuncios. Para definir títulos y descripciones en el contenido, usa name
y description
en link_data
, o title
y link_description
en video_data
.
run_status=3
: anteriormente hacía referencia a un campo y un valor que permitían eliminar contenido, lo que resultaba confuso. Para solucionar esto, se ha cambiado el nombre de run_status
a status
y el valor entero por el valor de cadena DELETED
. Para eliminar contenido del anuncio, usa status=DELETED
.
Se ha retirado COVER_PHOTO_ID
de GET
en los extremos “creative” {creative_id}
y {ad_account_id}/adcreatives
. Se utilizaba con poca frecuencia y su uso era interno y limitado.
image_url
o image_hash
: ahora solo se puede proporcionar uno de estos valores en video_data
para el objeto object_story_spec
del contenido del anuncio. Para obtener más información, consulta Referencia > Contenido.
Se ha retirado OBJECT_INSTAGRAM_ID
de GET
para los extremos “creative”, incluidos {creative_id}
y AD_ACCOUNT_ID/adcreatives
. Este campo no estaba diseñado para uso externo.
En la versión 2.8 y anteriores, instagram_story_id
se usaba para recuperar identificadores de publicaciones de Instagram del contenido de los anuncios. Si anteriormente usabas este campo al proporcionar el contenido del anuncio, se lanzaba una excepción, pero se ignoraba este parámetro y se devolvían resultados con instagram_story_id
. Si usabas esta respuesta, se generaba un error. Para resolver este problema, se ha cambiado el nombre de instagram_story_id
a effective_instagram_story_id
y este campo ya no se usa para proporcionar el contenido del anuncio.
Ahora, los tipos de retorno spent
, today_spent
y yesterday_spent
para todos los objetos de anuncio son String
, no Integer
. Este cambio afecta a las campañas, los conjuntos de anuncios y los anuncios.
No se admiten conjuntos de productos idénticos: ya no se pueden usar conjuntos de productos idénticos a otros conjuntos del mismo catálogo. Si intentas crear un conjunto de productos idéntico a otro de un mismo catálogo, nuestra API devolverá una excepción FacebookApiException
con el código 10803
que incluirá el identificador del conjunto de productos idéntico.
Se ha retirado quoted_fields
en POST /{product_feed_id}
. En la versión 2.6 se eliminó quoted_fields
en POST /{product_feed_id/product_feeds}
. Ahora se retira también en este parámetro para completar la limpieza correspondiente.
El extremo POST {catalog-id}/batch
ahora devuelve STRING
debido a las mejoras que se están realizando en los catálogos de productos de anuncios dinámicos.
Error en las actualizaciones de público: si usas anuncios dinámicos e intentas actualizar un público para estos anuncios, la solicitud genera un error. Para realizar cambios, debes eliminar el público asociado con los anuncios dinámicos y crear uno nuevo. Para obtener más información, consulta Anuncios dinámicos > Públicos y Públicos personalizados.
template_url_spec
sustituye a template_url
. De este modo, puedes realizar un seguimiento de clics e insertar en los anuncios URL específicas del contexto, sin necesidad de limitarte a las URL del catálogo de productos. Por ejemplo, puedes incluir en un anuncio las fechas de entrada y salida que una persona ha seleccionado. Para obtener más información, consulta Anuncios dinámicos > Administración de anuncios.
Cambio de nombre de los orígenes de eventos: si anteriormente creabas o consultabas conversiones personalizadas, usabas los campos etiquetados como pixel_id
, pixel_rule
y pixel_aggregation_rule
. Como estamos añadiendo la compatibilidad con los datos de las conversiones fuera de internet y de las conversiones personalizadas de las aplicaciones, estamos modificando las etiquetas de estos campos para expresar esta ampliación de ámbito. Ahora se denomina a estos campos event_source_id
, rule
y aggregation_rule
.
Píxel de conversión: este píxel se retiró el 15 de febrero de 2017. En consecuencia, se han retirado todos los perímetros y los nodos para crear, actualizar y leer el píxel de conversión, así como para hacer referencia a él, en todas las versiones de la API.
El parámetro friends_of_connection
asociado con los identificadores de evento se ha retirado como opción de segmentación de anuncios. Esto significa que no se pueden segmentar los amigos de las personas que han aceptado la invitación a un evento de Facebook.
Compatibilidad con delivery_estimate
: se han realizado cambios en el alcance estimado para que el extremo delivery_estimate
que se ha lanzado recientemente resulte compatible:
Se ha eliminado el campo bid_estimations
del extremo /reach_estimates
y se han transferido todas las funciones documentadas a /delivery_estimate
.
/AD_ID/reachestimate
se ha retirado. Para acceder a esta información usa /ADSET_ID/delivery_estimate
.
Se ha eliminado el campo data
.
Retiradas de date_preset
: se están retirando varios valores de date_preset
y sustituyendo por otros nuevos. Estos nuevos valores se han diseñado para simplificar su uso y en consonancia con las expectativas de los anunciantes. Asimismo, dejarán de incluir datos del día en curso. Por ejemplo, una solicitud realizada el 8 de febrero, con el intervalo de fechas predefinido de los últimos siete días, generará un informe que abarcará desde el 1 de febrero hasta las 23:59 del 7 de febrero, ambos días incluidos. El 8 de febrero quedará excluido. Se han retirado los valores siguientes:
last_3_days
se ha sustituido por last_3d
.
last_7_days
se ha sustituido por last_7d
.
last_14_days
se ha sustituido por last_14d
.
last_28_days
se ha sustituido por last_28d
.
last_30_days
se ha sustituido por last_30d
.
last_90_days
se ha sustituido por last_90d
.
last_week
se ha sustituido por last_week_sun_sat
y last_week_mon_sun
.
this_week
se ha sustituido por this_week_sun_today
y this_week_mon_today
.
Se ha retirado last_3_months
.
En la versión 2.8 y anteriores, se pueden utilizar tanto estos valores nuevos como los valores antiguos predefinidos de fechas.
Selección predeterminada de date_preset
: si anteriormente se realizaba una consulta de estadísticas sin date_preset
, se utilizaba de forma predeterminada last_30_days
, que incluía la actividad del día en curso, desde las 0:00, de acuerdo con la zona horaria de la cuenta publicitaria. A partir de la versión 2.9, se utiliza last_30d
de forma predeterminada. Este parámetro incluye los 30 días anteriores completos, hasta las 23:59 de la última noche, de acuerdo con la zona horaria de la cuenta. No incluye el día en curso.
Se ha retirado video_complete_watched_actions
, que proporcionaba la misma información que video_30_sec_watched_actions
.
Se han retirado unique_impression
y unique_social_impressions
. Utiliza reach
y social_reach
en su lugar.
Se han retirado los resultados obsoletosnewsfeed_clicks
, newsfeed_impressions
, newsfeed_avg_position
, video_avg_sec_watched_actions
y video_avg_pct_watched_actions
.
follow
, gift_sale
, video_play
y vote
se han retirado del campo action_type:
.
Ahora se puede acceder a click_to_play_video
mediante el desglose action_video_type
.
Se ha retirado de la API de estadísticas el campo de desglose placement
para los datos de entrega. Solo se admite ["publisher_platform", "platform_position"]
en la versión 2.9. En la versión 2.8 se pueden seguir utilizando ["placement"]
o ["publisher_platform", "platform_position"]
como desgloses.
attribution_spec
: anteriormente se utilizaban dos campos independientes para los intervalos de atribución de visualización y de clics en la API de estadísticas. Ahora se debe utilizar attribution_spec
para definir ambos intervalos. Si se define attribution_spec
, se sobrescribirá la configuración existente. Si se había definido previamente la atribución de visualización y de clics, cuando se defina attribution_spec
como event_type = CLICK_THROUGH
solo se eliminará la atribución de visualización.