Detalles
Síncrono vs. asíncrono
Las diferencias entre los endpoints de analytics síncronos y asíncronos se resumen en la siguiente tabla. Esta información está pensada para ayudar a los desarrolladores a elegir qué conjunto de endpoints utilizar.* Se refiere al número máximo de jobs que pueden estar en estado de procesamiento en un momento dado.** Una vez que el job haya terminado de procesarse correctamente, se devuelve una URL. Desde allí se puede descargar el archivo de resultados comprimido (gzip).Más allá de esto, los endpoints ofrecen la misma funcionalidad.
Casos de uso
Existen tres casos de uso principales para analytics.- Optimización en tiempo real: usar métricas de rendimiento para actualizar campañas activas
- Sincronización: sincronizaciones en segundo plano programadas periódicamente
- Onboarding de cuentas nuevas: recarga (backfill) de datos históricos
Opciones de la solicitud
Las solicitudes de analytics están acotadas a cuentas de anuncios y, por tanto, requieren el ID de la cuenta en la ruta del recurso. Las opciones de la solicitud, listadas a continuación, se especifican como parámetros de consulta. Se requieren los siguientes tipos de valores.- Entidades: el tipo de entidad y hasta 20 IDs de entidad para los que deseas solicitar analytics
- Rango de tiempo: las horas de inicio y fin, expresadas en ISO 8601
- Nota: deben expresarse en horas completas
- Grupos de métricas: uno o más conjuntos de métricas relacionadas (consulta Metrics and Segmentation para ver la lista de métricas dentro de cada grupo)
- Granularidad: especifica el nivel de agregación con el que se deben devolver las métricas
- Placement: determina si las métricas se obtienen para anuncios servidos dentro o fuera de X
- Nota: solo se puede especificar un único valor de placement por solicitud
start_time y end_time para especificar un rango de tiempo. Estos valores deben alinearse con la granularidad especificada de la siguiente manera.
TOTAL: especifica cualquier rango de tiempo (dentro de los límites del endpoint)DAY: tanto el valor de inicio como el de fin deben alinearse con la medianoche en la zona horaria de la cuentaHOUR: especifica cualquier rango de tiempo (dentro de los límites del endpoint)
start_time=2026-01-01T00:00:00Z y end_time=2026-01-02T00:00:00Z devolverá métricas de analytics correspondientes a un solo día (no dos), ya que este rango de tiempo cubre únicamente un período de 24 horas.
Segmentación
Disponible únicamente a través de nuestros endpoints asíncronos de analytics, la segmentación permite a partners y anunciantes obtener métricas desglosadas por determinados valores de segmentación. Para solicitar métricas segmentadas, utiliza el parámetro de solicitud segmentation_type. Para más detalles sobre las opciones de segmentación, consulta Metrics and Segmentation.
Preguntas frecuentes
¿Por qué los números de la Ads API no coinciden con lo que se muestra en la interfaz de X Ads?- Asegúrate de haber solicitado los datos para todos los placements:
ALL_ON_TWITTER,SPOTLIGHTyTREND. - Recuerda que las horas de fin en la Ads API son exclusivas; en la interfaz de Ads son inclusivas
- En cuanto las métricas de reporte están disponibles, puedes obtenerlas. Están disponibles casi en tiempo real. Sin embargo, estos resultados iniciales son estimaciones y, por tanto, se espera que cambien. Las métricas se finalizan después de 24 horas, salvo los datos de gasto.
- Las métricas de gasto suelen ser definitivas dentro de los 3 días siguientes al evento. No obstante, procesamos los datos de facturación hasta 14 días desde la fecha del evento (por filtrado de spam, por ejemplo).
- Usa el endpoint Active Entities
null?
- Es probable que la campaña no se haya servido durante el período de tiempo solicitado
- Usa el endpoint Active Entities para determinar qué entidades consultar para analytics y en qué período de tiempo
null mientras que la UI muestra 0?
- La UI elige mostrar estos valores como 0, pero los valores son equivalentes
- Admitimos los siguientes valores de placement en analytics:
ALL_ON_TWITTER,SPOTLIGHTyTREND
- Sí. El estado de la entidad no afecta la disponibilidad de las métricas de analytics.
- No se espera que los datos segmentados sumen al 100 % de los datos no segmentados, debido a cómo se deriva esta información.
- La API devuelve métricas segmentadas acotadas al tipo de entidad específico que consultas (CAMPAIGN, PROMOTED_TWEET). La UI de Ads Manager agrega los datos entre tipos de entidades. Son vistas diferentes de los mismos datos subyacentes y este es el comportamiento esperado.
- No admitimos la segmentación múltiple.
Buenas prácticas
Algunas buenas prácticas al recopilar datos de analytics de la Ads API.Rate Limiting y reintentos
- En consultas que están limitadas por rate limit (las que devuelven un código de estado
HTTP 429), debes inspeccionar el headerx-rate-limit-resety reintentar solo en o después del momento indicado. - En consultas que resulten en un código de estado HTTP 503 Service Unavailable, debes inspeccionar el header
retry-aftery reintentar solo después del momento indicado. - Las aplicaciones que no respeten los tiempos indicados para los reintentos podrían ver su acceso a la Ads API revocado o limitado sin previo aviso.
Métricas de analytics en pocas palabras
- Todas las métricas de analytics quedan fijas y no cambiarán después de 24 horas, salvo
billed_charge_local_micro. - La métrica
billed_charge_local_microes una estimación hasta 3 días después de que se devuelven los datos. - Tras 24 horas, esta métrica puede disminuir debido a créditos por sobregasto (anuncios servidos después del
end_timeindicado) y por eventos facturables que se determinen como junk. Esta métrica cambia mínimamente después de 24 horas. - Consulta Analytics para más información.
Obtención de datos no segmentados en tiempo real
- Proporciona siempre tanto un
start_timecomo unend_time. - No extraigas datos para ninguna entidad con más de 7 días de antigüedad.
- Solicita los datos (idealmente) con granularidad
HOUR, ya que siempre puedes agregar y sumar métricas para obtener granularidadesDAYyTOTAL. - Solicita los datos (idealmente) a nivel de
line_itemsypromoted_tweets, ya que siempre puedes agregar y sumar estas métricas para obtener totales en toda la jerarquía de entidades de anuncios (es decir, a nivel de campaña, instrumento de financiación o cuenta). - Guarda y almacena los valores de las métricas de analytics de tu lado (localmente).
- No consultes repetidamente datos con más de 30 días de antigüedad. Estos datos no cambiarán y deben almacenarse localmente.
- Todos los datos no segmentados son en tiempo real y deberían estar disponibles a los pocos segundos de ocurrir un evento.
- Agrupa las métricas de conversión y las que no son de conversión en solicitudes separadas.
Obtención de datos segmentados
- Consulta las directrices proporcionadas anteriormente en “Obtención de datos no segmentados en tiempo real”. A continuación se ofrecen recomendaciones adicionales.
- Para la mayoría de los tipos de datos segmentados, es posible que los datos no estén completos durante hasta 1 hora en ocasiones. Los datos segmentados por
INTERESTSpueden retrasarse hasta 12 horas. - No se espera que los datos segmentados sumen al 100 % de los datos no segmentados, debido a cómo se deriva esta información.
Obtención de datos históricos
- Al realizar backfill de datos (es decir, al añadir una nueva cuenta de anunciante), es posible que tengas que hacer varias solicitudes en bloques más pequeños de
start_timeyend_time. - Limita tus extracciones a ventanas de fechas de 30 días.
- Regula (throttle) estas solicitudes y distribúyelas en el tiempo para no agotar tus rate limits con estas extracciones.
Ejemplo
Puedes encontrar un script de ejemplo que demuestra algunas de estas buenas prácticas (fetch_stats) en nuestro repositorio de ads-platform-tools en GitHub.
Métricas por objetivo
Las métricas aplicables a una entidad dependen del objetivo de la campaña. Usa esta guía para determinar los grupos de métricas relevantes que debes obtener para cada tipo de objetivo, así como la forma de calcular métricas derivadas adicionales.ENGAGEMENTS
Grupos de métricas relevantes: ENGAGEMENT y BILLING.
WEBSITE_CLICKS y WEBSITE_CONVERSIONS
Grupos de métricas relevantes: ENGAGEMENT, BILLING y WEB_CONVERSION.
APP_INSTALLS
Grupos de métricas relevantes: ENGAGEMENT, BILLING, MOBILE_CONVERSION y LIFE_TIME_VALUE_MOBILE_CONVERSION. VIDEO también es aplicable si se utiliza una video app card en los creativos.
FOLLOWERS
Grupos de métricas relevantes: ENGAGEMENT y BILLING.
VIDEO_VIEWS
Grupos de métricas relevantes: ENGAGEMENT, BILLING y VIDEO.
VIDEO_VIEWS_PREROLL
Grupos de métricas relevantes: ENGAGEMENT, BILLING y VIDEO.
Métricas y segmentación
Este documento es una visión general de las métricas disponibles desde nuestro Analytics para cada tipo de entidad, así como la segmentación disponible para cada métrica.
*Algunas métricas de la familia
ENGAGEMENT no están disponibles a nivel de cuenta ni de instrumento de financiación. Consulta la sección ENGAGEMENT para más detalles.
Métricas disponibles por grupo de métricas
ENGAGEMENT
BILLING
VIDEO
Aviso sobre cambios en la definición de métricas de video:
La métrica video_total_views dentro del grupo de métricas VIDEO reportará cualquier vista que esté visible al menos al 50 % durante 2 segundos, según el estándar MRC.
Nuestra definición original de vista de video del 100 % visible durante al menos 3 segundos seguirá estando disponible como una nueva métrica video_3s100pct_views dentro del grupo de métricas VIDEO. Para continuar pujando y cobrando con base en la definición original de vista, usa la nueva bid_unit VIEW_3S_100PCT disponible.
WEB_CONVERSION
MOBILE_CONVERSION
Las estadísticas de conversión móvil solo están disponibles para las cuentas de anunciante habilitadas para MACT.
LIFE_TIME_VALUE_MOBILE_CONVERSION
Las estadísticas de conversión móvil de por vida (lifetime) solo están disponibles para las cuentas de anunciante habilitadas para MACT.
Segmentación
La elaboración de reportes con segmentación permite obtener métricas desglosadas por los valores de un tipo de segmentación determinado. La segmentación solo está disponible a través de consultas asíncronas de analytics debido a su considerable complejidad añadida. A partir de mayo de 2026, solo están habilitados los siguientes tipos de segmentación. METROS devuelve códigos DMA de Nielsen como cadenas numéricas (819 = Seattle-Tacoma). Los tipos de segmentación geográfica como METROS requieren el parámetro country (96683cc9126741d1 para US).Métricas derivadas
Las métricas de campaña dependen de su objetivo de campaña. Usa esta guía para determinar cómo calcular métricas derivadas para utilizarlas en función de los objetivos establecidos. Cualquiermetric sin llaves es una métrica que devuelven los endpoints de analytics de la Ads API. Cualquier nombre rodeado por {llaves} indica una métrica derivada para esa categoría.
ENGAGEMENTS
WEBSITE_CLICKS
APP_INSTALLS
FOLLOWERS
VIDEO_VIEWS
QUALIFIED_IMPRESSIONS
CUSTOM
Paraplacement_type PROMOTED_ACCOUNT, consulta el objetivo FOLLOWERS indicado anteriormente. Para todos los demás placements con este objetivo, consulta ENGAGEMENTS para las métricas derivadas correspondientes.
Guías
Active Entities
Introducción
El endpoint Active Entities está pensado para usarse junto con nuestros endpoints de analytics síncronos y asíncronos, ya que proporciona información sobre qué campañas solicitar para analytics. Lo hace devolviendo detalles sobre las entidades de anuncios y cuándo cambiaron sus métricas. Usar este endpoint simplificará enormemente tu código y la lógica de obtención de analytics. Esta guía incluye información y contexto sobre el endpoint y su fuente de datos. También proporciona directrices de uso y una serie de solicitudes de ejemplo que muestran cómo usar Active Entities junto con nuestros endpoints de analytics. La sección Resumen ofrece una descripción de alto nivel del enfoque recomendado.Datos
Cada vez que cambia la métrica de una entidad de anuncios, registramos información sobre ese cambio. Estos eventos de cambio se almacenan en buckets horarios e incluyen detalles sobre la entidad y el momento al que aplica el cambio. Esto último es necesario porque los eventos de cambio no siempre corresponden al momento en que fueron registrados. Los ajustes de facturación son una razón habitual para esto, pero hay otras.Endpoint
Solicitud
Las solicitudes de Active Entities están acotadas a cuentas de anuncios y tienen tres parámetros de consulta obligatorios:entity, start_time y end_time.
twurl -H ads-api.x.com "/12/stats/accounts/18ce54d4x5t/active_entities?entity=PROMOTED_TWEET&start_time=2026-03-05T00:00:00Z&end_time=2026-03-06T00:00:00Z"
Se admiten los siguientes valores de entity: CAMPAIGN, FUNDING_INSTRUMENT, LINE_ITEM, PROMOTED_ACCOUNT y PROMOTED_TWEET. Esto refleja los tipos de entidad que admiten nuestros endpoints de analytics.
Los valores start_time y end_time deben expresarse en ISO 8601 y especifican qué buckets horarios consultar. Deben expresarse en horas completas.
Este endpoint también admite tres parámetros opcionales que pueden usarse para filtrar los resultados: funding_instrument_ids, campaign_ids y line_item_ids. Funcionan en todos los niveles de la jerarquía de anuncios y con cualquier tipo de entity especificado.
Respuesta
La respuesta de Active Entities para la solicitud anterior se muestra a continuación.data incluye un objeto por cada entidad que debe incluirse en una solicitud de analytics posterior. No debes solicitar analytics para IDs fuera de este conjunto.
Cada objeto incluye cuatro campos: entity_id, activity_start_time, activity_end_time y placements. Los tiempos de inicio y fin de actividad representan el rango temporal al que aplican los eventos de cambio de la entidad asociada y, por tanto, determinan las fechas que deben especificarse en las solicitudes de analytics posteriores. El array placements puede incluir los siguientes valores: ALL_ON_TWITTER, SPOTLIGHT y TREND. Indica qué placements deben solicitarse para el ID de entidad dado.
Uso
El endpoint Active Entities debe dictar cómo se realizan las solicitudes de analytics. Las siguientes directrices de uso están redactadas para apoyar la sincronización de analytics, permitiendo a los partners mantener sus almacenes de datos sincronizados con X. En otras palabras, describe cómo realizar sincronizaciones en segundo plano programadas periódicamente. Hay dos decisiones que debe tomar un desarrollador.- Con qué frecuencia solicitar la información de active entities y, por tanto, con qué frecuencia extraer analytics.
- Cómo usar los tiempos de inicio y fin de actividad para determinar los valores
start_timeyend_timede la solicitud de analytics.
Resumen
Usa el endpoint Active Entities de la siguiente manera para dictar cómo se realizan las solicitudes de analytics. Sigue estos pasos una vez que hayas decidido con qué frecuencia solicitar la información de active entities y, por tanto, con qué frecuencia extraer analytics.- Haz la solicitud a Active Entities.
- Divide la respuesta por placement. Un grupo para
ALL_ON_TWITTER, uno paraSPOTLIGHTy otro paraTREND. - Para cada grupo de placement, haz lo siguiente.
- Extrae los IDs de entidad.
- Determina los valores
start_timeyend_timede analytics.- Encuentra el
activity_start_timemínimo. Redondea este valor hacia abajo. - Encuentra el
activity_end_timemáximo. Redondea este valor hacia arriba.
- Encuentra el
- Realiza la(s) solicitud(es) de analytics.
- Agrupa los IDs de entidad en lotes de 20.
- Usa los valores
start_timeyend_timedel punto #3b. - Especifica el valor de
placementadecuado.
- Escribe en tu almacén de datos.
Frecuencia
La respuesta a la primera pregunta determina el rango de tiempo que se debe usar en las solicitudes de Active Entities. Por ejemplo, si solicitas información de active entities cada hora, el rango de tiempo debe ser de una hora. Si solicitas información de active entities una vez al día, el rango de tiempo debe ser de un día. En otras palabras, los rangos de tiempo deben seleccionarse de modo que elstart_time de la solicitud actual sea igual al end_time de la solicitud anterior.
Nota: Una ventana de tiempo solo debe solicitarse una vez. Solicitar una ventana de tiempo más de una vez generará solicitudes de analytics innecesarias. (Excepción más abajo).
Dada la forma en que se almacenan los eventos de cambio, las cuatro solicitudes de Active Entities anteriores consultan el mismo bucket horario, lo cual es necesario para este caso de uso. Sin embargo, después de la hora actual, este bucket horario ya no debe consultarse.
Tiempos de actividad
Recomendamos el siguiente enfoque para trabajar con los tiempos de inicio y fin de actividad. A través de todos los objetos en la respuesta de Active Entities, encuentra elactivity_start_time mínimo y el activity_end_time máximo. Modifica estos valores redondeando hacia abajo el tiempo mínimo de inicio de actividad y redondeando hacia arriba el tiempo máximo de fin de actividad. Concretamente, pon a cero los timestamps en ambos casos y suma un día al tiempo de fin, como se ilustra en la siguiente tabla. Estos son los tiempos de inicio y fin que deben especificarse en las solicitudes de analytics posteriores.
Nota: Es importante incluir los timestamps con horas, minutos y segundos a cero. De lo contrario, si solo se pasa la fecha, asumiremos que estás solicitando analytics que empiezan y terminan a medianoche en la zona horaria de la cuenta de anuncios, lo que puede no ser deseable. Por ejemplo, si el tiempo mínimo de inicio de actividad es 2026-02-28T01:30:07Z y se omite el timestamp para una cuenta de anuncios con un offset de -08:00:00, la solicitud de analytics omitirá los cambios que ocurrieron entre las 01:30 y las 08:00.
Alternativamente, si prefieres solicitar analytics solo para la ventana de tiempo de actividad devuelta sin expandirla a días completos, puedes hacerlo. Con este enfoque, los tiempos derivados de inicio y fin serían 2026-03-04T20:00:00Z y 2026-03-05T15:00:00Z, respectivamente. (Ten en cuenta que rangos como estos no se aceptan si especificas granularidad
DAY en la solicitud de analytics).
Ejemplo
Esta sección muestra cómo usar Active Entities junto con el endpoint síncrono de analytics. (Las respuestas se han modificado ligeramente para mejorar la legibilidad). En este ejemplo, se llama al endpoint Active Entities al inicio de cada hora, mirando cada solicitud la hora anterior. La respuesta determina cómo se utiliza el endpoint síncrono de analytics. La primera solicitud de Active Entities se realiza a las 03:00:00. La respuesta indica que las métricas del line item dvcz7 cambiaron y que esos eventos de cambio aplican a la ventana entre 02:02:55 y 02:28:12.start_time y end_time de analytics se establecen en 2026-02-11T00:00:00Z y 2026-02-12T00:00:00Z, respectivamente. Vemos que el tercer elemento en cada uno de los arrays de métricas debajo es distinto de cero, como esperábamos en función de la información de active entities.
Guía asíncrona
Referencia de la API
Asynchronous Analytics
Introducción
Los endpoints asíncronos de analytics permiten a partners y anunciantes solicitar métricas enviando solicitudes de creación que el servidor procesa de forma asíncrona. (Nos referimos a estos como “jobs” asíncronos de analytics). Con este enfoque, la conexión del cliente no necesita permanecer abierta hasta que la solicitud sea atendida. Estos endpoints, al igual que su contraparte síncrona, permiten a partners y anunciantes solicitar estadísticas detalladas sobre el rendimiento de campañas. Admiten solicitar datos para cuentas, instrumentos de financiación, campañas, line items, posts promocionados y creativos de medios. La diferencia entre estos y el endpoint síncrono es que los endpoints asíncronos de analytics admiten rangos de fechas más largos, de hasta 90 días, así como segmentación. Puedes encontrar detalles adicionales sobre las diferencias entre ambos en nuestra página Analytics Overview. A diferencia de nuestros endpoints síncronos, el rate limiting se basa en el número de jobs concurrentes para una cuenta determinada. En otras palabras, se basa en el número de jobs que pueden estar en estado de procesamiento en un momento dado. Esto se cuenta a nivel de cuenta de anuncios.Uso
Obtener métricas de campaña usando los endpoints asíncronos de analytics es un proceso de varios pasos. Implica crear un job, comprobar si el job ha terminado de procesarse y, finalmente, descargar los datos. El archivo de datos debe descomprimirse. Los cuatro pasos específicos se describen a continuación.- Crea el job usando el endpoint POST stats/jobs/accounts/:account_id.
- Realiza solicitudes a intervalos regulares al endpoint GET stats/jobs/accounts/:account_id para determinar si el job ha terminado de procesarse.
- Una vez que el job haya terminado de procesarse, descarga el archivo de datos.
- Descomprime el archivo de datos.
segmentation_type al crear el job.
Ejemplo
Esta sección demuestra cómo usar los endpoints asíncronos de analytics. Empieza creando un job usando el endpoint POST stats/jobs/accounts/:account_id. El ejemplo siguiente solicita métricas de engagement —como impresiones, likes, clics, etc.— para un line item específico durante el lapso de una semana. (Ten en cuenta que el rango de tiempo solicitado llega hasta, pero no incluye, el 20 de marzo, ya que el timestamp se establece a medianoche).id como id_str.
A continuación, querrás comprobar si el job que has creado, usando el id_str de la respuesta anterior, ha terminado de procesarse, lo cual se indica con "status": "SUCCESS" en la respuesta. Esto significa que los datos están listos para descargarse. El campo url contiene el enlace de descarga.
job_ids para comprobar el estado de múltiples jobs a la vez, especificando hasta 200 IDs de job.
A continuación, descarga el archivo de datos usando el valor url indicado.
Reach y frecuencia promedio
GET stats/accounts/:account_id/reach/campaigns
Obtén analytics de reach y frecuencia promedio para las campañas especificadas.URL del recurso
https://ads-api.x.com/stats/accounts/:account_id/reach/campaigns
Parámetros
Solicitud de ejemplo
GET https://ads-api.x.com/12/stats/accounts/18ce54d4x5t/reach/campaigns?campaign_ids=8fgzf&start_time=2026-05-19&end_time=2026-05-26
Respuesta de ejemplo
GET stats/accounts/:account_id/reach/funding_instruments
Obtén analytics de reach y frecuencia promedio para los instrumentos de financiación especificados.URL del recurso
https://ads-api.x.com/stats/accounts/:account_id/reach/funding_instruments
Parámetros
Solicitud de ejemplo
Respuesta de ejemplo
Synchronous Analytics
GET stats/accounts/:account_id
Obtén analytics síncronos para la cuenta actual. Se permite un rango de tiempo máximo (end_time - start_time) de 7 días.
URL del recurso
https://ads-api.x.com/12/stats/accounts/:account_id
Parámetros
Solicitud de ejemplo
Respuesta de ejemplo
Active Entities
GET stats/accounts/:account_id/active_entities
Obtén detalles sobre qué métricas de analytics de qué entidades han cambiado en un período de tiempo determinado. Este endpoint debe usarse junto con nuestros endpoints de analytics. Los resultados de este endpoint indican para qué entidades de anuncios se debe solicitar analytics. Consulta nuestra Guía de Active Entities para conocer las directrices de uso. Los eventos de cambio están disponibles en buckets horarios.- Los valores
start_timeyend_timeespecifican qué buckets horarios se consultan. - El array
datadevuelto incluirá un objeto por cada entidad que deba incluirse en solicitudes de analytics posteriores. - IMPORTANTE: Las fechas que deben especificarse en solicitudes de analytics posteriores deben determinarse en función de los valores
activity_start_timeyactivity_end_time.- Estos valores representan los rangos de tiempo a los que aplican los eventos de cambio almacenados. Esto se devuelve por entidad.
end_time - start_time) de 90 días.
URL del recurso
https://ads-api.x.com/12/stats/accounts/:account_id/active_entities
Parámetros
Solicitud de ejemplo
GET https://ads-api.x.com/12/stats/accounts/18ce54d4x5t/active_entities?entity=PROMOTED_TWEET&start_time=2026-02-28&end_time=2026-03-01