Skip to main content
Consulta nuestras guías de comparación:

​
X API: Diccionario de datos de nivel empresarial

​
Introducción

Enterprise Las Publicaciones son la unidad atómica fundamental de todo en X. Todas las X API que devuelven Publicaciones proporcionan esos datos codificados en formato JavaScript Object Notation (JSON). JSON se basa en pares clave-valor, con atributos con nombre y valores asociados. Los objetos de Publicación recuperados a través de la API incluyen la “actualización de estado” de un Usuario de X, pero los Retweets, las respuestas y los Tweets citados también son objetos de Publicación. Si una Publicación está relacionada con otra Publicación, como un Retweet, una respuesta o un Tweet citado, cada una se identificará o se incluirá en el objeto de Publicación. Incluso la Publicación más sencilla en el formato de datos nativo de X tendrá objetos JSON anidados para representar otros atributos de una Publicación, como el autor, los usuarios mencionados, la ubicación del lugar etiquetado, los hashtags, los símbolos de cashtag, los contenidos multimedia o los enlaces URL. Al trabajar con datos de X, este es un concepto importante que debes entender. El formato de los datos de la Publicación que recibirás desde la X API depende del tipo de Publicación recibida, de la X API que estés utilizando y de la configuración de formato. Los endpoints de Enterprise que devuelven objetos de Publicación se han actualizado para proporcionar los metadatos necesarios para comprender el historial de edición de la Publicación. Obtén más información sobre estos metadatos en la página de fundamentos de “Editar Publicaciones”.
En el formato nativo de X, el payload JSON incluirá atributos de «nivel raíz» y objetos JSON anidados (representados aquí con la notación {}):

​
Formatos de datos disponibles

Tenga en cuenta: se recomienda encarecidamente utilizar el formato Enriched Native para las APIs de datos empresariales. 
  • El formato Enriched Native incluye todos los metadatos nuevos desde 2017, como los metadatos de encuestas, y métricas adicionales como reply_count y quote_count.
  • El formato Activity Streams no se ha actualizado con nuevos metadatos ni enriquecimientos desde la actualización de caracteres en 2017.
Las APIs de datos empresariales entregan datos en dos formatos diferentes. El formato empresarial más cercano al formato estándar v1.1 nativo es Native Enriched. El formato empresarial de datos heredado es Activity Streams, implementado originalmente y utilizado por Gnip como un formato normalizado en X y otros proveedores de datos de redes sociales en ese momento. Aunque este formato sigue estando disponible, X solo ha invertido en nuevas funciones y desarrollos en el formato Native Enriched desde 2017. El formato Native Enriched es exactamente lo que su nombre indica: incluye objetos nativos de X, así como enriquecimientos adicionales disponibles para los productos de datos empresariales, como metadatos de expansión de URL, geolocalización de perfil, metadatos de encuestas y métricas de interacción adicionales.  

​
Comparación de objetos por formato de datos

Independientemente de tu caso de uso en X, comprender qué representan estos objetos de Publicación codificados en JSON y sus atributos es fundamental para encontrar correctamente las señales de datos que te interesan. Para ayudarte en ello, hay un conjunto de páginas dedicadas a cada objeto en cada formato de datos_._ Siguiendo la jerarquía JSON anterior, aquí están los enlaces a cada uno de estos objetos:

​
Mejores prácticas de análisis

  • El JSON de X se codifica en UTF-8.
  • Los analizadores deben tolerar sin problemas la variación en el orden de los campos. Debe suponerse que el JSON de la Publicación se sirve como un hash de datos no ordenado.
  • Los analizadores deben tolerar la incorporación de campos “nuevos”. 
  • Los analizadores de JSON deben tolerar la ausencia de campos, ya que no todos los campos aparecen en todos los contextos.
  • En general, es seguro considerar un campo con valor nulo, un conjunto vacío y la ausencia de un campo como equivalentes.

​
Objetos de datos de Enterprise Native Enriched

​
Objeto Tweet de Native Enriched

¿Te interesa aprender más sobre cómo el formato de datos Native Enriched se corresponde con el formato de X API v2? Consulta nuestra guía comparativa: Native Enriched comparado con X API v2

​
Objeto Post

Al usar productos de datos empresariales, notará que gran parte del diccionario de datos es similar al formato nativo de datos de Post, con algunos metadatos enriquecidos adicionales. El nivel base del formato nativo enriquecido usa muchos de los mismos nombres de objeto que el formato de datos de X API v1.1. El objeto Post tiene una larga lista de atributos de «nivel raíz», incluidos atributos fundamentales como id, created_at y text. Los objetos Post también tendrán objetos anidados que incluyen user, entities y extended_entities. Los objetos Post también tendrán otros objetos Post anidados, como retweeted_status, quoted_status y extended_tweet. El formato nativo enriquecido también tendrá un objeto matching_rules.
Diccionario de datos de X
A continuación se muestra el diccionario de datos de estos atributos de nivel raíz, así como enlaces a los diccionarios de datos de los objetos hijo.
Atributos adicionales de la Publicación
Las X APIs que proporcionan Publicaciones (p. ej., el endpoint GET statuses/lookup) pueden incluir estos atributos adicionales de la Publicación:
Atributos obsoletos

​
Objetos de Publicación anidados

En varios casos, un objeto de Publicación incluirá otros objetos anidados. Si trabajas con objetos anidados, esa carga útil JSON contendrá varias Publicaciones, y cada objeto de Publicación podrá contener sus propios objetos. El objeto de nivel raíz contendrá información sobre el tipo de acción realizada, es decir, si es un Retweet o un Quote Tweet, y también podrá contener un objeto que describa la Publicación «original» que se está compartiendo. Las Publicaciones extendidas incluirán un objeto extendido anidado que se extiende más allá de 140 caracteres, lo cual se utilizó para evitar cambios incompatibles cuando se hizo la actualización en 2017. Cada diccionario de objetos anidados se describe a continuación. Retweets Los Retweets siempre contienen dos objetos de Publicación. La Publicación «original» a la que se hace Retweet se proporciona en un objeto retweeted_status. El objeto de nivel raíz encapsula el propio Retweet, incluido un objeto de User para la cuenta que realiza la acción de Retweet y la hora del Retweet. Hacer Retweet es una acción para compartir una Publicación con tus seguidores, y no se puede añadir ningún contenido nuevo. Además, no se puede proporcionar una ubicación (nueva) con un Retweet. Aunque la Publicación «original» pueda estar geolocalizada, los objetos geo y place del Retweet siempre serán null. Incluso antes de la introducción de las Publicaciones extendidas, el objeto entities de nivel raíz estaba en algunos casos truncado e incompleto debido a que se agregaba la cadena RT @username al mensaje de la Publicación a la que se hacía Retweet. Ten en cuenta que, si a un Retweet se le vuelve a hacer Retweet, el retweet_status seguirá apuntando a la Publicación original, lo que significa que el Retweet intermedio no se incluye. Se observa un comportamiento similar al usar x.com para «mostrar» un Retweet. Si copias el id de Publicación único asignado a la «acción» de Retweet, se muestra la Publicación original.  A continuación se muestra una estructura de ejemplo para un Retweet. De nuevo, al analizar Retweets, es clave analizar el objeto retweeted_status para obtener el mensaje completo de la Publicación original y los metadatos de entidades.
Tweets citados
Los Tweets citados son muy similares a los Retweets, excepto que incluyen un nuevo mensaje de Publicación. Estos nuevos mensajes pueden contener su propio conjunto de hashtags, enlaces y otros metadatos de “entities”. Los Tweets citados también pueden incluir información de ubicación compartida por el usuario que publica el Tweet citado, junto con contenido multimedia, como GIF, vídeos y fotos. Los Tweets citados contendrán al menos dos objetos de Publicación y, en algunos casos, tres. La Publicación que se cita, que a su vez puede ser un Tweet citado, se proporciona en un objeto “quoted_status”. El objeto de nivel raíz encapsula el propio Tweet citado, e incluye un objeto User para la cuenta que realiza la acción de compartir y la hora del Tweet citado. Ten en cuenta que los Tweets citados ahora pueden tener fotos, GIF o vídeos añadidos mediante la interfaz de usuario “Post”. Cuando se incluyen enlaces a contenido multimedia alojado externamente en el mensaje del Tweet citado, el “entities.urls” de nivel raíz los describirá. El contenido multimedia adjunto a Tweets citados aparecerá en los metadatos “extended_entities” de nivel raíz. Cuando se lanzaron por primera vez los Tweets citados, se añadía un enlace acortado (URL t.co) al mensaje de la Publicación “original” y se proporcionaba en el campo “text” de nivel raíz. Además, los metadatos para esa URL t.co se incluían en el array “entities.urls” de nivel raíz. En mayo de 2018, cambiamos esto de forma que la URL t.co acortada que apunta al Tweet citado no se incluirá en el campo “text” de nivel raíz. En segundo lugar, los metadatos del Tweet citado no se incluirán en los metadatos “entities.urls”. En su lugar, los metadatos de la URL del Tweet citado estarán en un nuevo objeto “quoted_status_permalink” en el nivel raíz (o nivel superior), es decir, al mismo nivel que el objeto “quoted_status”. A continuación se muestra una estructura de ejemplo para un Tweet citado que usa este formato original.
Publicaciones extendidas
El JSON que describe las Publicaciones extendidas se introdujo cuando se lanzaron las Publicaciones de 280 caracteres en noviembre de 2017. El JSON de la Publicación se amplió para encapsular estos mensajes más largos, sin afectar a los miles de aplicaciones que analizan estos objetos fundamentales de X. Para proporcionar total compatibilidad con versiones anteriores, se conservaron el campo original de 140 caracteres ‘text’ y los objetos de entidades analizados a partir de este. En el caso de Publicaciones de más de 140 caracteres, este campo ‘text’ de nivel raíz pasaba a estar truncado y, por lo tanto, incompleto. Dado que los objetos ‘entities’ de nivel raíz contienen arreglos de metadatos clave extraídos del mensaje ‘text’, como hashtags y enlaces incluidos, estas colecciones quedarían incompletas. Por ejemplo, si el mensaje de una Publicación tuviera 200 caracteres, con un hashtag incluido al final, el arreglo heredado ‘entities.hashtags’ de nivel raíz no lo incluiría.  Se introdujo un nuevo campo ‘extended_tweet’ para almacenar los mensajes de Publicaciones más largos y los metadatos completos de las entidades. El objeto “extended_tweet” proporciona el campo “full_text”, que contiene el mensaje completo de la Publicación, sin truncar, cuando supera los 140 caracteres. El objeto “extended_tweet” también contiene un objeto “entities” con arreglos completos de hashtags, enlaces, menciones, etc. Las Publicaciones extendidas se identifican con un booleano “truncated” de nivel raíz. Cuando es true (“truncated”: true), se deben analizar los campos de “extended_tweet” en lugar de los campos de nivel raíz. Observa en el ejemplo JSON siguiente que el campo “text” de nivel raíz está truncado y el arreglo “entities.hashtags” de nivel raíz está vacío, a pesar de que el mensaje de la Publicación incluye tres hashtags. Dado que se trata de una Publicación extendida, el campo “truncated” se establece en true y el objeto “extended_tweet” proporciona metadatos completos de la Publicación en “full_text” y “entities”.

​
Objeto de usuario enriquecido nativo

El objeto User contiene metadatos de la cuenta de usuario de X que describen al usuario de X al que se hace referencia. 

​
Diccionario de datos de usuario

​
Atributos en desuso (ya no admitidos)

​
Ejemplo de objeto de usuario:

​
Objetos Geo Nativos Enriquecidos

Las Publicaciones pueden asociarse a una ubicación, generando una Publicación “etiquetada geográficamente” (geo‑tagged). Las ubicaciones de las Publicaciones pueden asignarse usando la interfaz de usuario de X o al publicar una Publicación usando la API. Las ubicaciones de las Publicaciones pueden ser una ubicación “punto” exacta o un X Place con una “caja delimitadora” (bounding box) que describe un área más grande que puede ir desde un recinto hasta toda una región. Hay tres objetos JSON de “nivel raíz” que se usan para describir la ubicación asociada a una Publicación: place, geo y coordinates.  Además, el formato nativo enriquecido incluye la ubicación derivada del enriquecimiento de geo de perfil dentro del objeto user. El objeto place siempre está presente cuando una Publicación está etiquetada con ubicación mediante un Place. Los Places son ubicaciones específicas y con nombre, con coordenadas geográficas correspondientes. Cuando los usuarios deciden asignar una ubicación a su Publicación, se les presenta una lista de X Places candidatos. Cuando se usa la API para publicar, se puede adjuntar un X Place especificando un place_id al publicar. Las Publicaciones asociadas con Places no necesariamente se emiten desde esa ubicación, sino que también podrían potencialmente tratarse sobre esa ubicación. Los objetos geo y coordinates solo están presentes (no nulos) cuando a la Publicación se le asigna una ubicación exacta. Si se proporciona una ubicación exacta, el objeto coordinates proporcionará un arreglo [long, lat] con las coordenadas geográficas, y se asignará un X Place que corresponda a esa ubicación.

​
Diccionario de datos de Place

​
Bounding box

​
Diccionario de datos del objeto Geo

Diccionario de datos del objeto Coordinates

​
Ubicaciones derivadas

​
Ejemplos:

Diccionario de datos: Enterprise

​
Entidades de X

Ir a secciones de esta página Introducción Objeto entities   - Objeto de hashtag   - Objeto de medios   - Objeto de tamaño de medios   - Objeto URL   - Objeto de mención de usuario   - Objeto de símbolo   - Objeto de encuesta Detalles de Retweet y Tweet citado Entidades en objetos de usuario Entidades en Mensajes Directos Siguientes pasos

​
Introducción

Las entidades proporcionan metadatos e información contextual adicional sobre el contenido publicado en X. La sección entities proporciona arrays de elementos comunes incluidos en las Publicaciones: hashtags, menciones de usuarios, enlaces, símbolos bursátiles (tickers), encuestas de X y medios adjuntos. Estos arrays son prácticos para los desarrolladores al procesar Publicaciones, ya que X ha preprocesado, o preanalizado, esencialmente el cuerpo de texto. En lugar de tener que buscar y encontrar explícitamente estas entidades en el cuerpo de la Publicación, tu analizador puede ir directamente a esta sección JSON y allí estarán. Además de proporcionar estas facilidades de análisis, la sección entities también ofrece metadatos útiles que “añaden valor”. Por ejemplo, si estás usando el Enhanced URLs enrichment, los metadatos de URL incluyen las URL totalmente expandidas, así como los títulos y descripciones de los sitios web asociados. Otro ejemplo es cuando hay menciones de usuarios; los metadatos de entidades incluyen el id numérico de usuario, que es útil al realizar solicitudes a muchas X API. Cada carga útil JSON de una Publicación incluye una sección entities, con el conjunto mínimo de atributos hashtags, urls, user_mentions y symbols, incluso si ninguna de esas entidades forma parte del mensaje de la Publicación. Por ejemplo, si examinas el JSON de una Publicación con un cuerpo de “Hello World!” y sin medios adjuntos, el JSON de la Publicación incluirá el siguiente contenido con arrays de entidades que contienen cero elementos:
Notas:
  • las entidades media y polls solo aparecerán cuando ese tipo de contenido forme parte de la Publicación.
  • si trabajas con contenido multimedia nativo (fotos, videos o GIFs), el Extended Entities object es la opción recomendada.

​
Objeto Entities

Las secciones entities y extended_entities están compuestas por arrays de objetos de entidad. A continuación se incluyen descripciones de cada uno de estos objetos de entidad, incluidos diccionarios de datos que describen los nombres de los atributos del objeto, sus tipos y una breve descripción. También indicaremos qué operadores de PowerTrack coinciden con estos atributos e incluiremos algunos ejemplos de payloads JSON. Una colección de entidades comunes que se encuentran en las Publicaciones, incluidas las etiquetas (hashtags), los enlaces y las menciones de usuarios. Este objeto entities sí incluye un atributo media, pero su implementación en la sección entiites solo es completamente precisa para Publicaciones con una sola foto. Para todas las Publicaciones con más de una foto, un video o un GIF animado, se remite al lector a la sección extended_entities.

​
Diccionario de datos de Entities

El objeto entities es un contenedor de arrays de otros subobjetos de entidades. Después de ilustrar la estructura de entities, se proporcionarán diccionarios de datos para estos subobjetos y los Operadores que coinciden con ellos.

​
Objeto de hashtag

La sección entities contendrá un array hashtags con un objeto por cada hashtag incluido en el cuerpo de la Publicación, e incluirá un array vacío si no hay hashtags presentes. El operador PowerTrack # se utiliza para hacer coincidir el atributo text. El operador has:hashtags coincidirá si hay al menos un elemento en el array.

​
Objeto multimedia

La sección entities contendrá un array media que incluirá un único objeto multimedia si se ha “adjuntado” algún objeto multimedia a la Publicación. Si no se ha adjuntado contenido multimedia nativo, no habrá ningún array media en entities. Por las siguientes razones, se debe usar la sección extended_entities para procesar el contenido multimedia nativo de la Publicación:
  • El type del contenido multimedia siempre indicará photo incluso en los casos en que se adjunte un video o un GIF a la Publicación.
  • Aunque se pueden adjuntar hasta cuatro fotos, solo la primera se incluirá en la sección entities.
El operador has:media coincidirá si este array contiene elementos.

​
Objetos de tamaño de contenido multimedia

Todas las Publicaciones con contenido multimedia nativo (fotos, videos y GIFs) incluirán un conjunto de tamaños “thumb”, “small”, “medium” y “large” con valores de alto y ancho en píxeles. Para las fotos y las URL de imágenes de vista previa de contenido multimedia, el apartado Photo Media URL formatting describe cómo construir distintas URL para cargar contenido fotográfico en diferentes tamaños.

​
Objeto Sizes

​
Objeto de tamaño

​
Formato de URL de medios de fotos

Los medios de fotos en X se pueden cargar en diferentes tamaños. Es mejor cargar la imagen del tamaño más pequeño que siga siendo lo suficientemente grande como para ajustarse a un área de visualización de imagen en particular. Para cargar diferentes tamaños, el Size Object y media_url (o media_url_https) deben combinarse en un formato específico. Usaremos el objeto de ejemplo de la media entity ya proporcionado para nuestro ejemplo al construir una URL de medios de fotos. media_url o media_url_https se pueden cargar por sí solos, lo que dará como resultado que se cargue la variante de tamaño medio de forma predeterminada. Sin embargo, es preferible proporcionar una URL de medios de fotos completamente formateada cuando sea posible. Hay tres partes en una URL de medios de fotos: Tomamos estas tres partes (URL base, formato y nombre) y las combinamos en la URL de medios de fotos que se va a cargar. Hay 2 formatos para cargar imágenes de esta manera, legacy y modern. Todas las cargas de imágenes deben dejar de usar el formato legacy y usar el formato modern. Usar el formato modern dará como resultado una mejor tasa de aciertos en la CDN para quien realiza la llamada, mejorando así las latencias de carga al ser menos probable que tenga que generar y cargar los medios desde el centro de datos.

​
Objeto URL

La sección entities contendrá un array urls que incluye un objeto por cada enlace incluido en el cuerpo de la Publicación, y un array vacío si no hay enlaces presentes. El operador has:links coincidirá si hay al menos un elemento en el array. El operador url: se utiliza para hacer coincidir el atributo expanded_url. Si estás utilizando el Expanded URL enrichment, el operador url: se utiliza para hacer coincidir el atributo unwound.url (URL completamente expandida). Si estás utilizando el Exhanced URL enrichment, los operadores url_title: y url_decription: se utilizan para hacer coincidir los atributos unwound.title y unwound.description. Si estás utilizando los enriquecimientos Expanded y/o Enhanced URL, los siguientes metadatos están disponibles en el atributo unwound:

​
Objeto de mención de usuario

La sección entities contendrá un arreglo user_mentions que incluye un objeto por cada mención de usuario incluida en el cuerpo de la Publicación, y un arreglo vacío si no hay ninguna mención de usuario. El operador PowerTrack @ se utiliza para hacer coincidir el atributo screen_name. El operador has:mentions coincidirá si hay al menos un elemento en el arreglo.

​
Objeto Symbol

La sección entities contendrá un array symbols que incluye un objeto por cada $cashtag incluido en el cuerpo de la Publicación, y un array vacío si no hay ningún símbolo presente. El operador $ de PowerTrack se utiliza para hacer coincidencias con el atributo text. El operador has:symbols coincidirá si hay al menos un elemento en el array.

​
Objeto poll

La sección entities contendrá un arreglo polls que incluirá un único objeto poll si la Publicación contiene una encuesta. Si no se incluye ninguna encuesta, no habrá un arreglo polls en la sección entities. Ten en cuenta que estos metadatos de encuestas solo están disponibles con las siguientes APIs Enterprise:

​
Detalles de Retweets y Tweets citados

Desde la perspectiva de la X API, los Retweets y los Tweets citados son tipos especiales de Publicaciones que contienen la Publicación original como un objeto incrustado. Por lo tanto, los objetos de Retweet y de Tweet citado actúan como padres de una Publicación hija “original” (y, por lo tanto, duplican su tamaño). Los Retweets tienen un objeto de nivel superior “retweeted_status” y los Tweets citados tienen un objeto “quoted_status”. Por coherencia, estos objetos de nivel superior de Retweet y Tweet citado también tienen una propiedad text y las entities asociadas. Sin embargo, las entities en el nivel superior pueden diferir de las entities proporcionadas por las entities “originales” incrustadas. En el caso de los Retweets, se antepone texto nuevo al cuerpo de la Publicación original. En el caso de las Publicaciones citadas, se agrega texto nuevo al final del cuerpo de la Publicación. En general, la mejor práctica es recuperar el texto, las entities, el autor original y la fecha de la Publicación original en retweeted_status siempre que exista. Una excepción es obtener las entities de X que formen parte de la cita adicional. Consulta a continuación más detalles y recomendaciones.

​
Retweets

Un detalle importante sobre los Retweets es que no se pueden añadir entities adicionales de X a la Publicación. Los usuarios no pueden añadir hashtags, URL u otros detalles cuando realizan un Retweet. Sin embargo, el atributo de texto del Retweet (de nivel superior) se compone del texto de la Publicación original con «RT @username: » antepuesto.   En algunos casos, especialmente con cuentas con nombres de usuario largos, la combinación de estos nuevos caracteres y el cuerpo de la Publicación original puede exceder fácilmente el límite original de 140 caracteres para el texto de la Publicación. Para mantener la compatibilidad con la visualización y el almacenamiento basados en 140 caracteres, el cuerpo de nivel superior trunca el final del cuerpo de la Publicación y añade puntos suspensivos («…»). En consecuencia, algunas entities de nivel superior situadas al final de la Publicación original pueden ser incorrectas o faltar, por ejemplo, en el caso de un hashtag o una entrada de URL truncados. Esta Publicación, https://x.com/FloodSocial/status/907974220298125312, tiene el siguiente texto:                Just another test Post that needs to be exactly 140 characters with trailing URL and hashtag http://wapo.st/2w8iwPQ #Testing En el ejemplo anterior, tanto la URL como el hashtag se vieron afectados. Dado que el hashtag se truncó por completo y la URL se truncó parcialmente, estos faltan en las entities de nivel superior. También verás la user_mentions adicional de nivel superior que proviene del prefijo «RT @floodsocial: » en el campo text. Sin embargo, el texto de la Publicación y las entities en retweeted_status reflejan perfectamente la Publicación original sin truncamiento ni entities incorrectas; por lo tanto, recomendamos confiar en el objeto anidado retweeted_status para los Retweets.

​
Tweets citados

Los Tweets citados se introdujeron en 2016 y se diferencian de los Retweets en que, cuando “citas” una Publicación, agregas contenido nuevo “sobre” una Publicación compartida. Este contenido nuevo puede incluir casi cualquier elemento que pueda tener una Publicación original, como texto adicional, hashtags, menciones y URL. Los Tweets citados pueden contener contenido multimedia nativo (fotos, videos y GIF) y aparecerán en el objeto entities. Dado que se pueden agregar entidades de X, es probable que las entidades del Tweet citado sean diferentes de las entidades originales. En este ejemplo, se colocaron una nueva URL y un nuevo hashtag al final del Tweet citado. Esta Publicación, https://x.com/FloodSocial/status/907983973225160704, tiene el siguiente texto de la Publicación:                   strange and equally tragic when islands flood… trans-atlantic testing of quote tweets | @thisuser @thatuserhttp://bit.ly/2vMMDuu #testing En este caso, las entidades de nivel superior no reflejan los detalles del Tweet citado.  Sin embargo, el texto de la Publicación y las entities en extended_tweet reflejan perfectamente el Tweet citado, sin truncaciones ni entidades incorrectas; de ahí nuestra recomendación de confiar en el objeto anidado _extended_tweet _objeto para los Tweets citados.

​
Entidades para el objeto user

Las entidades para objetos de usuario describen las URL que aparecen en los campos definidos por el usuario para la URL de perfil y la descripción. No describen hashtags ni user_mentions. A diferencia de las entidades de Publicación, las entidades de usuario pueden aplicarse a múltiples campos dentro de su objeto padre; para distinguirlas, encontrarás nodos padre llamados url y description que indican qué campo contiene la URL con entidades aplicadas. En este ejemplo, el campo url del usuario contiene un enlace t.co que está completamente expandido dentro del nodo entities/url/urls[0] de la respuesta. El usuario no tiene una URL acortada en su descripción.

​
Ejemplo de JSON

​
Entidades extendidas de X

Ir a en esta página Introducción Objeto Extended Entities Ejemplos de Tweets y cargas útiles JSON   - Tweet con cuatro fotos nativas   - Tweet con video nativo   - Tweet con un GIF animado Próximos pasos

​
Introducción

Si una Publicación contiene contenido multimedia nativo (compartido mediante la interfaz de usuario de la Publicación en lugar de a través de un enlace a otro sitio), también habrá una sección extended_entities. Cuando se trata de cualquier medio nativo (foto, video o GIF), extended_entities es la fuente de metadatos preferida por varias razones. Actualmente, se pueden adjuntar hasta cuatro fotos a una Publicación. Los metadatos de entities solo contendrán la primera foto (hasta 2014 solo se podía incluir una foto), mientras que la sección extended_entities incluirá todas las fotos adjuntas. Con el contenido multimedia nativo, otra limitación de los metadatos de entities.media es que el tipo de medio siempre indicará “photo”, incluso en los casos en que el contenido adjunto sea un video o un GIF animado. El tipo real de medio se especifica en el atributo extended_entities.media[].type y se establece en photo, video o animated_gif. Por estas razones, si trabajas con contenido multimedia nativo, los metadatos de extended_entities son la mejor opción. Todas las Publicaciones con fotos, videos y GIF animados adjuntos incluirán un objeto JSON extended_entities. El objeto extended_entities contiene un único arreglo media de objetos media (consulta la sección entities para ver su diccionario de datos). Ningún otro tipo de entidad, como hashtags y enlaces, se incluye en la sección extended_entities. El objeto media en la sección extended_entities es idéntico en estructura al que se incluye en la sección entities. Las Publicaciones solo pueden tener un tipo de contenido multimedia adjunto. Para fotos, se pueden adjuntar hasta cuatro fotos. Para videos y GIF, se puede adjuntar uno. Dado que los metadatos type del medio en la sección extended_entities indican correctamente el tipo de medio (“photo”, “video” o “animated_gif”) y admiten hasta 4 fotos, es la fuente de metadatos preferida para contenido multimedia nativo.

​
Ejemplos de Publicaciones y cargas útiles en JSON

A continuación se muestran algunas Publicaciones de ejemplo y los metadatos de las entidades asociadas. Publicación con cuatro fotos nativas Publicación con hashtag, mención de usuario, cashtag, URL y cuatro fotos nativas:
Esta es la sección entities de esta Publicación:
Solo en la carga útil “extendida” que aparece a continuación encontrarás las cuatro fotos nativas (como máximo). Observa que la primera foto del array es la misma que la foto única incluida en la sección de entities no extendida de X. La estructura de metadatos de media para fotos es la misma tanto en las secciones entities como extended_entities. Aquí está la sección extented_entities para esta Publicación:

​
Publicación con video nativo

A continuación se muestran los metadatos de las entidades extendidas de esta Publicación con video:
Cuando un anunciante decide limitar la reproducción de video solo a las plataformas propiedad y operadas por X, el objeto video_info se reemplazará por un objeto additional_media_info. El objeto additional_media_info contendrá información de medios adicional proporcionada por el editor, como title, description y embeddable flag. El contenido de video solo está disponible para los clientes oficiales de X cuando embeddable=false. En este caso, todas las URL de video proporcionadas en el payload estarán basadas en X, de modo que el usuario pueda abrir el video en una propiedad de X haciendo clic en el enlace. Aquí tienes un ejemplo de cómo se verá el objeto extended entities en esta situación:
Como se indicó anteriormente, aquí está la sección entities que tiene incorrectamente el type asignado a ‘photo’. Nuevamente, se prefiere la sección extended_entities para todos los tipos de medios nativos, incluidos ‘video’ y ‘animated_gif’.

​
Publicación con un GIF animado

A continuación se muestran los metadatos de extended entities para esta Publicación con un GIF animado:

​
Ejemplos de payloads con enriquecimiento nativo

​
Publicación

​
Respuesta a una Publicación

​
Publicación extendida

​
Publicación con extended_entitites

​
Retweet

​
Tweet citado

​
Retuit de Tweet citado

​
Objetos de datos de Enterprise Activity Streams

¿Quieres obtener más información sobre cómo el formato de datos de Activity Streams se corresponde con el formato de X API v2?
Consulta nuestra guía comparativa: Activity Streams comparado con X API v2
Ten en cuenta: se recomienda encarecidamente usar el formato Enriched Native para las API de datos empresariales. 
  • El formato Enriched Native incluye todos los metadatos nuevos desde 2017, como los metadatos de encuestas, y métricas adicionales como reply_count y quote_count.
  • El formato Activity Streams no se ha actualizado con nuevos metadatos ni enriquecimientos desde la actualización de caracteres en 2017.

​
Objeto de actividad

Activity Streams es un esquema de objetos que traduce el formato de datos original de X, creado por Gnip para “normalizar el formato” de los datos de Publicaciones y otros datos de redes sociales usando el Activity Base Schema de terceros descrito aquí. Las Publicaciones se normalizan en el esquema de Activity Streams, incluyendo los tipos de objeto anidados note, person, place y service. Las Publicaciones pueden tener otros objetos de actividad de Publicación anidados para Retweets u otros, incluyendo twitter_quoted_status, long_object. El tipo de objeto de nivel básico activity es similar al objeto de nivel básico de Post del formato nativo enriquecido. Se pueden encontrar ejemplos de cargas útiles en formato Activity Streams aquí.

​
Diccionario de datos

A continuación se presenta el diccionario de datos de estos atributos “activity” de nivel raíz, así como enlaces a los diccionarios de datos de los objetos hijo.

​
Atributos adicionales de la Publicación

​
Atributos obsoletos

​
Objetos de actividad de Publicaciones anidadas

En varios casos, un objeto de Publicación incluirá otras Publicaciones anidadas. Si trabajas con objetos anidados, la carga útil JSON contendrá múltiples objetos y cada objeto de Publicación puede contener sus propios objetos. El objeto de nivel raíz contendrá información sobre el tipo de acción realizada, es decir, si es un Retweet o un Tweet citado, y también puede contener un objeto que describe la Publicación ‘original’ que se está compartiendo. Las Publicaciones extendidas incluirán un objeto extendido anidado que se extiende más allá de los 140 caracteres, lo cual se utilizó para evitar cambios disruptivos cuando se realizó la actualización en 2017. Cada diccionario de objetos anidados se describe a continuación. Retweets El formato de activity streams de los Retweets incluye un objeto anidado con el type “activity” y el verb “note” para representar la Publicación original que se está Retweeteando.
Estado citado en X El formato de activity streams incrusta Tweets citados { "id": "tag:search.x.com,2005:222222222222", "objectType": "activity", "verb": "post", "body": "Quoting a Tweet: https://t.co/mxiFJ59FlB", "actor": { "displayName": "TheQuoter2" }, "object": { "objectType": "note", "id": "object:search.x.com,2005:111111111", "summary": "https://t.co/mxiFJ59FlB" }, "twitter_entities": {}, "twitter_extended_entities": {}, "gnip": {}, "twitter_quoted_status": { "id": "tag:search.x.com,2005:111111111", "objectType": "activity", "verb": "post", "body": "console.log('Happy birthday, JavaScript!');", "actor": { "displayName": "TheOriginalTweeter" }, "object": { "objectType": "note", "id": "object:search.x.com,2005:111111111" }, "twitter_entities": {} } } Tweet citado retuiteado:

​
Objeto long

Formato Activity Streams de extended_tweet

​
Objeto Actor

El objeto Actor contiene metadatos de la cuenta de usuario de X que describen al usuario de X que creó la actividad.

​
Diccionario de datos

​
Atributos que ya no se admiten (obsoletos)

​
Ejemplos:

​
Objeto Location

Los objetos Location pueden existir dentro del objeto actor configurado a nivel de la cuenta de X o dentro del objeto profileLocations del objeto gnip. Los objetos Location tienen un type de objeto place y pueden incluir un nombre, una dirección o coordenadas geográficas. Los objetos Location son similares a Geo en el formato enriquecido nativo.

​
Diccionario de datos de Location

​
objetos derivados de profileLocations

Ejemplos

​
Objeto de entidades de X

Para el formato Activity Streams, twitter_entities tiene el mismo formato y diccionario de datos que en el formato enriquecido nativo objeto entities aquí.

​
Ejemplo:

​
Objeto de entidades extendidas de X

Para el formato Activity Streams, twitter_extended_entities utiliza el mismo formato y diccionario de datos que se muestra en el formato nativo enriquecido en el objeto extended_entities aquí.

​
Ejemplo:

​
Objeto Gnip

El objeto gnip, dentro del formato Activity streams, contiene los metadatos añadidos por los enriquecimientos activos, así como la indicación de las reglas de coincidencia que aplican a la actividad.

​
Diccionario de datos

​
Ejemplo:

​
Ejemplos de cargas útiles de Activity Streams

Actividad de publicaciones
Actividad de respuesta de la Publicación
Actividad de Publicación con long_object
Actividad de publicaciones con twitter_extended_entities
Actividad de Retweets
Actividad de Tweet con cita
Actividad de Retweet de Tweet citado

​
Cronología de metadatos de Tweet

Ir a en esta página Introducción Conceptos clave Cronología de X Consejos de filtrado Próximos pasos

​
Introduction**

En esencia, X es una red de comunicación pública, en tiempo real y global. Desde 2006, la evolución de X ha estado impulsada tanto por los patrones de uso y las convenciones de los usuarios como por nuevas funciones y mejoras de producto. Si usas datos de X para investigación histórica, entender la cronología de esta evolución es importante para poder encontrar Publicaciones de interés en el archivo de datos. X se lanzó como una sencilla App móvil basada en SMS y ha crecido hasta convertirse en una plataforma de comunicación completa. Una plataforma con un conjunto completo de APIs. Las APIs siempre han sido un pilar de la red de X. La primera API se puso en marcha poco después del lanzamiento de X. Cuando el etiquetado geográfico de Publicaciones se introdujo por primera vez en 2009, se ofreció mediante una Geo API (y más tarde la capacidad de “etiquetar geográficamente” una Publicación se integró en la interfaz de usuario de X.com). Hoy en día, las APIs de X impulsan la red de comunicación bidireccional que se ha convertido en la fuente de noticias de última hora y de intercambio de información. Las oportunidades para crear soluciones sobre este canal de comunicación global y en tiempo real son infinitas. X pone a disposición dos APIs históricas que proporcionan acceso a cada Publicación disponible públicamente: Historical PowerTrack y la Full-Archive Search API. Ambas APIs ofrecen un conjunto de operadores que se utilizan para consultar y recopilar Publicaciones de interés. Estos operadores buscan coincidencias en una variedad de atributos asociados con cada Publicación, cientos de atributos como el contenido de texto de la Publicación, el nombre de cuenta del autor y los enlaces compartidos en la Publicación. Las Publicaciones y sus atributos se codifican en JSON, un formato de intercambio de datos de texto muy común. Por lo tanto, a medida que se introducían nuevas funciones, aparecían nuevos atributos JSON y, normalmente, se introducían nuevos operadores de API para hacer coincidir esos atributos. Si tu caso de uso incluye la necesidad de escuchar lo que el mundo ha dicho en X, cuanto mejor entiendas cuándo los operadores empezaron a disponer de metadatos JSON con los que buscar coincidencias, más eficaces podrán ser tus filtros históricos de PowerTrack. A continuación, presentaremos algunos conceptos clave que sientan las bases para entender cómo las actualizaciones en los metadatos de las Publicaciones afectan a la búsqueda de tu señal de datos de interés.

​
Conceptos clave**

​
De convenciones de usuario a objetos de primera clase en X

Los usuarios de X introdujeron de forma orgánica patrones de comunicación nuevos y ahora fundamentales en la red de X. Un ejemplo seminal es el hashtag, hoy casi universalmente utilizado en todas las redes sociales. Los hashtags se introdujeron como una forma de organizar conversaciones y temas. En una red con cientos de millones de mensajes al día, las herramientas para encontrar Publicaciones de interés son clave, y los hashtags se han convertido en un método fundamental. Poco después de que el uso de los hashtags creciera, recibieron condición y soporte oficiales por parte de X. Cuando los hashtags se convirtieron en un “objeto de primera clase”, esto implicó muchas cosas. Significó que los hashtags pasaron a ser elementos en los que se podía hacer clic y que se podían buscar en la interfaz de usuario de X.com. También significó que los hashtags pasaron a ser miembros de la familia de entities de X, junto con las @mentions, el contenido multimedia adjunto, los símbolos bursátiles y los enlaces compartidos. Estas entities se codifican de forma conveniente en un array JSON preanalizado, lo que facilita a los desarrolladores procesarlas, examinarlas y almacenarlas. Los Retweets son otro ejemplo de convenciones impulsadas por los usuarios que se convierten en objetos oficiales. El Retweet surgió como una forma de “reenviar” contenido a otras personas. Comenzó como un proceso manual de copiar/pegar una Publicación y anteponerle el patrón “RT @”. Este proceso acabó automatizándose mediante un nuevo botón de Retweet, completo con nuevos metadatos JSON. Así nació el Retweet “oficial”. Otros ejemplos incluyen las “mentions”, el intercambio de contenido multimedia y enlaces web, y compartir una ubicación con tu Publicación. Cada uno de estos patrones de uso dio lugar a nuevas funciones en la interfaz de usuario de x.com, nuevo JSON de soporte y, por tanto, nuevas formas de encontrar Publicaciones coincidentes. Todos estos atributos fundamentales de las Publicaciones han dado lugar a operadores de PowerTrack utilizados para hacer coincidir Publicaciones en función de ellos.

​
Metadatos de la Publicación, mutabilidad, actualizaciones y vigencia

Aunque una Publicación puede tener hasta un número fijo de caracteres, la descripción JSON de una Publicación consta de más de 100 atributos. Estos incluyen atributos como quién publicó, en qué momento, si es una Publicación original o un Retweet, y una matriz (array) de objetos de primera clase como hashtags, menciones y enlaces compartidos. Para la cuenta que publicó, hay un objeto User (o Actor) con una variedad de atributos que proporcionan el perfil del usuario y otros metadatos de la cuenta. Los perfiles incluyen una breve descripción biográfica, una ubicación principal (texto libre), el idioma preferido y un enlace de sitio web opcional. Algunos metadatos de la cuenta nunca cambian (por ejemplo, el id numérico de usuario y la fecha de creación), otros cambian lentamente con el tiempo, mientras que otros atributos cambian con mayor frecuencia. Las personas cambian de trabajo y se mudan. Las empresas actualizan su información. Cuando recopilas Publicaciones históricas, es importante entender que algunos metadatos son tal como eran cuando se Publicó y otros metadatos son tal como son cuando se envía la consulta.  Con todas las API históricas, la descripción del perfil del usuario, el nombre para mostrar y los atributos de perfil ‘home’ se actualizan a los valores del momento de la consulta.

​
Contenido multimedia “nativo”

X.com y las aplicaciones móviles de X permiten agregar fotos y videos a una Publicación haciendo clic en un botón y navegando por tus galerías de fotos. Ahora que están integrados como acciones de primer nivel, los videos y las fotos compartidos de esta manera se denominan contenido multimedia “nativo”. Muchos Operadores de consulta funcionan con estos recursos “nativos”, incluidos has:videos, has:images y has:media. Estos solo coincidirán con contenido multimedia que se haya compartido a través de funciones de X. Para hacer coincidir otro contenido multimedia alojado fuera de la plataforma de X, deberás usar Operadores que coincidan con metadatos de la URL. Entonces, antes de profundizar en los detalles del producto Historical PowerTrack y Full-Archive Search, hagamos un recorrido por cómo X, como producto y plataforma, ha evolucionado con el tiempo. Cronología de X A continuación encontrarás una cronología seleccionada de X. La mayoría de estas actualizaciones de X afectaron de alguna manera, de forma fundamental, el comportamiento de los usuarios, el contenido JSON de las Publicaciones, los Operadores de consulta o los tres. Si consideramos X como una plataforma de API, los siguientes eventos afectaron de alguna manera las cargas (payloads) JSON que se utilizan para codificar Publicaciones. A su vez, esos detalles JSON afectan cómo las API históricas de X coinciden con ellas. Ten en cuenta que esta lista cronológica es en general precisa, pero no exhaustiva.

​
2006

  • Octubre
    • @replies pasa a ser una convención.
    • cashtagsaparecenporprimeravez,perosuusoparamencionarsıˊmbolosbursaˊtilesnosegeneralizahastaprincipiosde2009.Loscashtags aparecen por primera vez, pero su uso para mencionar símbolos bursátiles no se generaliza hasta principios de 2009. Los Cashtags pasaron a ser un enlace sobre el que se podía hacer clic y que se podía buscar en junio de 2012.
  • Noviembre - Se introducen los Favoritos.

​
2007

  • Enero - las @replies se convierten en un objeto de primera clase con un botón de respuesta en la interfaz de usuario y metadatos in_reply_to.
  • Abril - los Retweets se convierten en una convención.
  • Agosto - los #hashtags surgen como una herramienta principal para buscar y organizar Publicaciones.

​
2009

  • Febrero - los $cashtags se convierten en una convención común para hablar de símbolos bursátiles.
  • Mayo - se introduce la versión ‘beta’ del Retweet con “Via @” añadido al cuerpo de la Publicación.
  • Junio - se introducen las cuentas verificadas.
  • Agosto - los Retweets se convierten en un objeto de primera clase con el patrón “RT @” y nuevos metadatos retweet_status.
  • Octubre - se lanza la función de Listas.
  • Noviembre - se lanza la API de geotagging de Publicaciones, que proporciona el primer método para que los usuarios compartan su ubicación a través de apps de terceros.

​
2010

  • Junio: se introduce X Places para geoetiquetar Publicaciones.
  • Agosto: se lanza el botón de Publicación para sitios web, lo que facilitó compartir enlaces.

​
2011

  • Mayo: se introduce el botón Seguir (Follow), que facilita seguir cuentas asociadas a sitios web.
  • Agosto: se introducen las fotos nativas.

​
2012

  • junio: los $Cashtags se convierten en un enlace en el que se puede hacer clic y que se puede buscar.

​
2014

  • Marzo - se admite el etiquetado de fotos y hasta cuatro fotos. Se introdujeron los metadatos de X Entities extendidos.
  • Abril - los emoji se admiten de forma nativa en la interfaz de usuario de X. Los emoji se utilizaban habitualmente en Publicaciones al menos desde 2008.

​
2015

  • abril: un cambio en el diseño de la interfaz de usuario de las Publicaciones de X provoca que se etiqueten geográficamente menos Publicaciones.
  • octubre: se introdujeron las encuestas de X. Inicialmente, las encuestas admitían dos opciones con un período de votación de 24 horas. En noviembre, las encuestas empezaron a admitir cuatro opciones con períodos de votación de 5 minutos a siete días. Los metadatos de las encuestas se pusieron a disposición (solo en formato nativo enriquecido) en febrero de 2017.

​
2016

​
2017

  • Febrero: los metadatos de encuestas de X se incluyen en los metadatos de la Publicación (solo formato nativo enriquecido).
  • Abril: se introducen las “Simplified Replies”, con las cuentas a las que se responde sin contarse dentro de los 140 caracteres (“dmw140, part 2”).
2018 2022
  • 29 de septiembre: se habilita la capacidad de editar Publicaciones para un pequeño grupo de prueba. Los metadatos de Publicaciones editadas se añaden al objeto de la Publicación cuando corresponde. Esto incluye los objetos edit_history y edit_controls. Estos metadatos no se devolverán para Publicaciones que se crearon antes de que se añadiera la funcionalidad de edición. No hay Operators asociados para estos metadatos. Para obtener más información sobre cómo funcionan las ediciones de Publicaciones, consulta los Fundamentos de edición de Publicaciones
Consejos de filtrado Familiarizarte con la cronología de X sobre cuándo y cómo se añadieron nuevas funciones puede ayudarte a crear consultas más efectivas. Aquí, una consulta significa un filtro o regla que aplican las APIs históricas de X al archivo de Publicaciones, utilizando PowerTrack Operators para hacer coincidir el JSON de la Publicación. Un ejemplo es el operador lang:, que se usa para hacer coincidir Publicaciones en un idioma específico. X proporciona un servicio de clasificación de idioma (que admite más de 50 idiomas), y las APIs de X proporcionan estos metadatos en el JSON que se genera para cada Publicación. Así, si una Publicación está escrita en español, el atributo JSON lang se establece en es. Por lo tanto, si creas un filtro con la cláusula lang:es, solo coincidirá con Publicaciones clasificadas como español. La información de la cronología también puede ayudar a interpretar mejor los datos de las Publicaciones recibidas. Supongamos que investigas el intercambio de contenido sobre los Juegos Olímpicos de Verano de 2008 y 2012. Si aplicas únicamente el operador is:retweet para hacer coincidir Retweets, no habría datos que coincidan en 2008. Sin embargo, para 2012 probablemente habría millones de Retweets. A partir de esto, podrías concluir erróneamente que en 2008 los Retweets no eran una convención de uso, o que simplemente nadie hizo Retweet sobre esos Juegos Olímpicos. Dado que los Retweets se convirtieron en un objeto de primera clase en 2009, debes añadir una cláusula de regla "RT @" para ayudarte a identificarlos en 2008. Tanto los Retweets como la clasificación por idioma de las Publicaciones son ejemplos de atributos de Publicación con una larga historia y muchos detalles de producto. A continuación, hablaremos con más detalle sobre estas y otras clases de atributos importantes para hacer coincidencias y para comprender los datos de X.

​
Reconocer falsos negativos

Cuando se trata de escribir filtros, una conclusión importante es que todos los Operadores de metadatos sobre los que se hace coincidencia tienen fechas de “nacimiento”. Si creas un filtro con un Operador que actúa sobre metadatos introducidos después de que se publicó la Publicación, obtendrás un falso negativo. Por ejemplo, supongamos que te interesan todas las Publicaciones que mencionan ‘snow’ y comparten un video. Si creas una regla con el Operador has:videos, que hace coincidir Publicaciones con videos nativos, esa cláusula no coincidirá con ninguna Publicación anterior a 2015. Sin embargo, compartir videos ha sido común en X mucho antes de 2015. Antes de esa fecha, los usuarios compartían enlaces a videos alojados en otros sitios, pero en 2015 X incorporó nuevas funciones de “compartir video” directamente en la plataforma. Para encontrar estas Publicaciones anteriores de interés, deberías incluir una cláusula de regla como url:"youtube.com". Ten en cuenta que, con las APIs de Search, hay algunos ejemplos de metadatos que se han “rellenado retrospectivamente” a medida que se reconstruía su índice. Un buen ejemplo son los cashtags,quepasaronautilizarseampliamenteparahablardesıˊmbolosbursaˊtilesen2009.Despueˊsdequeseintrodujoeloperadorcashtags, que pasaron a utilizarse ampliamente para hablar de símbolos bursátiles en 2009. Después de que se introdujo el operador cashtag en 2015, se reconstruyó el índice de Search y, en ese proceso, la entidad del símbolo se extrajo de todos los cuerpos de las Publicaciones, incluidos los de principios de 2006, cuando $ se usaba principalmente como jerga: “I hope it nownow $oon!”.

​
Identificar y filtrar atributos de Publicaciones importantes para tu caso de uso

Algunos metadatos, como los id numéricos de cuentas de X, han existido desde el primer día (y son un ejemplo de metadatos de cuenta que nunca cambian). Otros metadatos no se introdujeron hasta mucho después de que X comenzara en 2006. Ejemplos de nuevos metadatos que se introdujeron posteriormente incluyen metadatos de Retweets, ubicaciones de Publicaciones, títulos y descripciones de URL y contenido multimedia nativo. A continuación se muestran algunos de los tipos más comunes de atributos de Publicaciones que se han visto afectados de forma fundamental por estas actualizaciones de la plataforma de X. El comportamiento de filtrado y coincidencia de estos depende, en la mayoría de los casos, de qué API histórica de Publicaciones se use. Para ayudarte a determinar qué producto se ajusta mejor a tu investigación y caso de uso, los detalles de los atributos que se proporcionan a continuación incluyen información general de alto nivel sobre el producto.

​
Perfiles de X

Dado que, en esencia, X es un canal de comunicación global en tiempo real, la investigación con datos de Publicaciones suele poner el énfasis en quién se está comunicando. A menudo es útil saber cuál es el lugar de residencia de un usuario de X. Con frecuencia, saber que la biografía de una cuenta incluye menciones de intereses y pasatiempos puede llevarte a Publicaciones relevantes. Es muy común querer monitorizar Publicaciones de cuentas de interés. Los atributos del perfil son clave para todos estos casos de uso. Cada cuenta en X tiene un perfil que incluye metadatos como el @handle de X, el nombre para mostrar, una breve biografía, la ubicación de residencia (texto libre ingresado por un usuario), el número de seguidores y muchos otros. Algunos atributos nunca cambian, como el id numérico de usuario y la fecha en que se creó la cuenta. Otros suelen cambiar día a día, semana a semana o mes a mes, como el número de Publicaciones realizadas y el número de cuentas seguidas y de seguidores. Otros atributos de la cuenta también pueden cambiar en cualquier momento, pero tienden a cambiar con menos frecuencia: nombre para mostrar, ubicación de residencia y biografía. La carga útil JSON de cada Publicación incluye metadatos de perfil de cuenta para el autor de la Publicación. Si es un Retweet, también incluye metadatos de perfil para la cuenta que publicó la Publicación original. La mutabilidad de los metadatos de perfil de una Publicación depende totalmente del producto histórico utilizado. Las API de búsqueda devuelven Publicaciones históricas con la configuración de perfil tal como está en el momento de la recuperación. Para Historical PowerTrack, el perfil es tal como era en el momento en que se publicó la Publicación, excepto para los datos anteriores a 2011. Para Publicaciones anteriores a 2011, los metadatos de perfil reflejan el perfil tal como era en septiembre de 2011.

​
Publicación original y Retweets

Los Retweets son otro ejemplo de convenciones impulsadas por los usuarios que se convierten en objetos oficiales. El Retweet surgió como una forma de “reenviar” contenido a otras personas. Comenzó como un proceso manual de copiar y pegar una Publicación y anteponerle el patrón “RT @”. Este proceso acabó automatizándose mediante un nuevo botón de Retweet, con nuevos metadatos JSON. Nació el Retweet “oficial” y la acción de hacer retweet se convirtió en un evento de Publicación de primera clase. Junto con el nuevo botón de Retweet, se introdujeron nuevos metadatos, como el payload completo de la Publicación original. Que una Publicación sea original o compartida es un criterio de filtrado habitual. En algunos casos, solo se necesita contenido original. En otros casos, la interacción con la Publicación es de máxima importancia, por lo que los Retweets son clave. El operador de PowerTrack is:retweet permite a los usuarios incluir o excluir Retweets. Si se extraen datos de antes de agosto de 2009, los usuarios necesitan dos estrategias para hacer coincidir (o no) los Retweets. Antes de agosto de 2009, es necesario comprobar el propio texto de la Publicación, utilizando coincidencia de frase exacta, para buscar coincidencias con el patrón “@RT ”. Para periodos posteriores a agosto de 2009, el operador is:retweet está disponible.

​
Clasificaciones de idioma de las Publicaciones

El idioma en que está escrita una Publicación suele ser de interés. El idioma de la Publicación puede ayudar a inferir la ubicación de una Publicación y, a menudo, solo se necesita un idioma específico para el análisis o la visualización. (Los perfiles de X también tienen una configuración de idioma preferido). Para filtrar según la clasificación de idioma de una Publicación, los productos históricos de X (Search API y Historical PowerTrack) son bastante diferentes. Cuando se creó el archivo de búsqueda, todas las Publicaciones se completaron de forma retroactiva con la clasificación de idioma de X. Por lo tanto, el operador lang: está disponible para todo el archivo de Publicaciones. Con Historical PowerTrack, los metadatos de clasificación de idioma de X están disponibles en el archivo a partir del 26 de marzo de 2013. 

​
Georreferenciar Publicaciones

Poder indicar desde dónde se publicó una Publicación (es decir, georreferenciarla) es importante para muchos casos de uso. Hay tres métodos principales para georreferenciar Publicaciones:
  • Referencias geográficas en el mensaje de una Publicación
  • Publicaciones etiquetadas con ubicación por el usuario
  • Ubicación «principal» del perfil de la cuenta configurada por un usuario
Referencias geográficas en el mensaje de una Publicación
La coincidencia basada en referencias geográficas en el mensaje de la Publicación, aunque a menudo es el método más complejo porque depende del conocimiento local, es una opción disponible para todo el archivo de Publicaciones. Aquí hay un ejemplo de coincidencia georreferenciada de 2006 para el área de San Francisco basado en un filtro de “golden gate”: https://x.com/biz/statuses/28311
Publicaciones geolocalizadas por el usuario
En noviembre de 2009, X introdujo su Post Geotagging API, que permitió que las Publicaciones se geolocalizaran con una ubicación exacta. En junio de 2010, X introdujo X Places, que representan un área geográfica a escala de local, vecindario o ciudad. Aproximadamente entre el 1 % y el 2 % de las Publicaciones están geolocalizadas mediante cualquiera de estos métodos. El historial de geolocalización disponible depende de la Historical API que estés utilizando. Con las Search APIs, la posibilidad de empezar a hacer coincidencias de Publicaciones con algunos Geo Operators comenzó en marzo de 2010, y con otros en febrero de 2015. Si estás utilizando Historical PowerTrack, la georreferenciación comienza el 1 de septiembre de 2011. Cuando se creó el archivo de Historical PowerTrack, no se incluyó ninguna geolocalización anterior a esa fecha.
Ubicación de “inicio” del perfil de la cuenta establecida por un usuario
Todos los usuarios de X tienen la posibilidad de configurar su ubicación de perfil, indicando su ubicación de inicio. Millones de usuarios de X proporcionan esta información, y esto incrementa significativamente la cantidad de geodatos en X Firehose. Estos metadatos de ubicación son una cadena de texto de formato libre, generada por el usuario y no normalizada. Aproximadamente el 30% de las cuentas tienen metadatos de Profile Geo que pueden resolverse a nivel de país. Al igual que con la geolocalización de las Publicaciones, los métodos de coincidencia y los períodos de tiempo disponibles dependen de la API histórica que utilices. Historical PowerTrack permite a los usuarios intentar sus propias coincidencias personalizadas sobre estas cadenas de texto de formato libre. Para facilitar ese proceso, X también ofrece un Profile Geo Enrichment que realiza la geocodificación cuando es posible, proporcionando metadatos normalizados y operadores correspondientes. Los operadores de Profile Geo están disponibles tanto en Historical PowerTrack como en las APIs de búsqueda. Con Historical PowerTrack, estos metadatos de Profile Geo están disponibles a partir de junio de 2014. Con las APIs de búsqueda, estos metadatos están disponibles a partir de febrero de 2015. Compartir enlaces a páginas web, fotos y videos siempre ha sido un caso de uso fundamental de X. Al principio de su historia, todas estas acciones implicaban incluir un enlace URL en el mensaje de la Publicación. En 2011 X integró el uso compartido de fotos directamente en su interfaz de usuario. En 2016 se añadieron los videos nativos. Dada esta historia, existe una variedad de operadores de filtrado usados para hacer coincidencias con este contenido. Hay un conjunto de operadores que determinan si las Publicaciones tienen enlaces compartidos, fotos y videos. Además, dado que la mayoría de las URL compartidas en X se acortan para usar menos caracteres de una Publicación (por ejemplo, generadas por un servicio como bitly o tinyurl), X proporciona enriquecimientos de datos que generan una URL completa y expandida que se puede usar para hacer coincidencias. Por ejemplo, si quisieras hacer coincidencias con Publicaciones que incluyan enlaces que traten sobre X y sistemas de alerta temprana, un filtro que haga referencia a “severe weather communication” coincidiría con una Publicación que contenga esta URL http://bit.ly/1XV1tG4. En marzo de 2012 se introdujo el enriquecimiento de URL expandida. Antes de ese momento, los payloads de las Publicaciones incluían solo la URL proporcionada por el usuario. Por lo tanto, si el usuario incluía una URL acortada, puede ser difícil hacer coincidencias con las URL (expandidas) de interés. Con Historical PowerTrack y las API de búsqueda, estos metadatos están disponibles a partir de marzo de 2012. En julio de 2016 se introdujo el enriquecimiento de URL mejorada. Esta versión mejorada proporciona el título HTML y la descripción de un sitio web en el payload de la Publicación, junto con operadores para hacer coincidencias con esos elementos. Con Historical PowerTrack, estos metadatos pasan a estar disponibles en julio de 2016. Con las API de búsqueda, estos metadatos comienzan a aparecer en diciembre de 2014. En septiembre de 2016 X introdujo los “adjuntos nativos”, en los que un enlace compartido al final no se cuenta dentro del límite de 140 caracteres de la Publicación. Ambos enriquecimientos de URL siguen aplicándose a estos enlaces compartidos. Para obtener otros detalles específicos del producto sobre el filtrado de URL, consulta los artículos correspondientes para obtener más información.