Skip to main content
다음 비교 가이드를 확인하세요:

X API: 엔터프라이즈 데이터 사전

Introduction

Enterprise 포스트는 X의 모든 것을 구성하는 가장 기본적인 원자 단위입니다. 포스트를 반환하는 모든 X API는 해당 데이터를 JavaScript Object Notation(JSON) 형식으로 인코딩해 제공합니다. JSON은 이름이 있는 속성과 그에 연결된 값으로 이루어진 키-값 쌍에 기반합니다. API에서 조회한 게시물 객체에는 X 사용자의 “status update”가 포함되지만, 리트윗, 답글, 인용 Tweet 역시 모두 게시물 객체입니다. 게시물이 리트윗, 답글 또는 인용 Tweet처럼 다른 게시물과 연관되어 있는 경우, 각각은 게시물 객체 안에 식별 정보로 포함되거나 중첩됩니다. 기본 X 데이터 형식에서 가장 단순한 게시물조차도 작성자, 멘션된 사용자, 태그된 장소(위치), 해시태그, 캐시태그 심볼, 미디어 또는 URL 링크와 같은 게시물의 다른 속성을 표현하기 위해 중첩된 JSON 객체를 포함합니다. X 데이터를 다룰 때는 이 개념을 이해하는 것이 중요합니다. X API에서 받게 되는 게시물 데이터의 형식은 수신한 게시물의 종류, 사용 중인 X API, 그리고 포맷 설정에 따라 달라집니다. 게시물 객체를 반환하는 Enterprise 엔드포인트는 게시물의 편집 이력을 이해하는 데 필요한 메타데이터를 제공하도록 업데이트되었습니다. 이러한 메타데이터에 대해 더 알아보려면 “게시물 편집” 기본 사항 페이지를 참고하세요.
네이티브 X 형식에서는 JSON 페이로드에 ‘루트 수준’ 속성과 {} 표기법으로 표시된 중첩 JSON 객체가 포함됩니다.

사용 가능한 데이터 형식

참고: 엔터프라이즈 데이터 API에는 Enriched Native 형식 사용을 강력히 권장합니다. 
  • Enriched Native 형식에는 poll 메타데이터를 비롯해 reply_count 및 quote_count와 같은 추가 지표 등 2017년 이후 추가된 모든 신규 메타데이터가 포함됩니다.
  • Activity Streams 형식은 2017년 문자 수 업데이트 이후로 새로운 메타데이터나 enrichment가 반영되지 않았습니다.
엔터프라이즈 데이터 API는 두 가지 서로 다른 형식으로 데이터를 제공합니다. 표준 v1.1 native 형식과 가장 유사한 엔터프라이즈 형식은 Native Enriched입니다. 레거시 엔터프라이즈 데이터 형식은 Activity Streams로, 당시 X 및 기타 소셜 미디어 데이터 제공업체 전반에서 공통 포맷으로 사용하기 위해 Gnip이 처음 구현한 정규화 형식입니다. 이 형식은 여전히 사용할 수 있지만, X는 2017년 이후로 새로운 기능 및 개발을 Native Enriched 형식에만 투자해 왔습니다. Enriched Native 형식은 이름 그대로, native X 객체에 더해 URL 언와인딩 메타데이터, 프로필 위치 정보(profile geo), poll 메타데이터, 추가 참여(engagement) 지표 등과 같은 엔터프라이즈 데이터 제품에서 제공되는 추가 enrichment를 포함합니다.  

데이터 형식별 객체 비교

어떤 X 사용 사례이든 간에, 이 JSON으로 인코딩된 게시물 객체와 속성이 무엇을 나타내는지 이해하는 것은 관심 있는 데이터 신호를 성공적으로 찾는 데 매우 중요합니다. 이를 돕기 위해, 각 데이터 형식의 각 객체를 다루는 전용 페이지들이 준비되어 있습니다. 위의 JSON 계층 구조를 반영하여, 각 객체에 대한 링크는 다음과 같습니다:

파싱 모범 사례

  • X JSON은 UTF-8로 인코딩됩니다.
  • 파서는 필드 순서의 변동을 무리 없이 허용하도록 설계해야 합니다. 게시물 JSON은 순서가 없는 데이터 해시로 제공된다고 가정해야 합니다.
  • 파서는 ‘새로운’ 필드의 추가를 허용해야 합니다. 
  • JSON 파서는 ‘누락된’ 필드를 허용해야 합니다. 모든 필드가 모든 컨텍스트에 나타나는 것은 아니기 때문입니다.
  • 일반적으로 null로 설정된 필드, 빈 집합, 필드가 없는 경우를 동일한 것으로 간주해도 안전합니다.

엔터프라이즈 네이티브 Enriched 데이터 객체

Native Enriched Tweet 객체

X API v2 형식과 Native Enriched 데이터 형식 간의 매핑 방식에 대해 더 자세히 알고 싶으신가요? 비교 가이드를 참조하세요: Native Enriched compared to X API v2

게시물 객체

엔터프라이즈 데이터 제품을 사용할 때, 데이터 사전의 많은 부분이 게시물 데이터의 기본(native) 포맷과 유사하며, 여기에 추가로 강화(enriched) 메타데이터가 포함되어 있음을 알 수 있습니다. 기본 수준의 네이티브 강화 포맷은 X API v1.1 데이터 포맷과 상당 부분 동일한 객체 이름을 사용합니다. 게시물 객체에는 id, created_at, text와 같은 기본 속성을 포함한 ‘루트 수준’ 속성이 길게 나열됩니다. 게시물 객체에는 또한 user, entities, extended_entities를 포함하는 중첩 객체도 존재합니다. 게시물 객체는 retweeted_status, quoted_status, extended_tweet와 같은 중첩 게시물 객체도 포함합니다. 네이티브 강화 포맷에는 추가로 matching_rules 객체가 포함됩니다.
X Data Dictionary
아래에는 이러한 ‘루트 레벨’ 속성에 대한 데이터 사전과 하위 객체 데이터 사전에 대한 링크가 제공됩니다.
추가 게시물 속성
포스트(예: GET statuses/lookup 엔드포인트)를 제공하는 X API에서는 다음과 같은 추가 게시물 속성이 포함될 수 있습니다:
사용 중단된 속성

중첩된 게시물 객체

여러 경우에 게시물 객체에는 다른 중첩 객체가 포함됩니다. 중첩 객체를 다루는 경우, 해당 JSON 페이로드에는 여러 게시물 객체가 포함되며, 각 게시물 객체는 자체 하위 객체를 포함할 수 있습니다. 루트 레벨 객체에는 수행된 액션의 유형, 즉 리트윗인지 인용 Tweet인지에 대한 정보가 포함되며, 공유되고 있는 ‘원본’ 게시물을 설명하는 객체가 포함될 수도 있습니다. 확장 게시물(Extended Posts)은 2017년 업데이트 시 하위 호환성을 유지하기 위해 도입된, 140자를 초과하는 내용을 담는 중첩 확장 객체를 포함합니다. 각 중첩 객체 딕셔너리에 대해서는 아래에서 설명합니다. 리트윗(Retweets) 리트윗은 항상 두 개의 게시물 객체를 포함합니다. 리트윗되고 있는 ‘원본’ 게시물은 “retweeted_status” 객체로 제공됩니다. 루트 레벨 객체는 리트윗 자체를 캡슐화하며, 여기에는 리트윗 액션을 수행한 계정에 대한 User 객체와 리트윗 시각이 포함됩니다. 리트윗은 게시물을 팔로워와 공유하는 액션이며, 새로운 콘텐츠를 추가할 수 없습니다. 또한 (새로운) 위치 정보는 리트윗에 제공할 수 없습니다. ‘원본’ 게시물에 지오태그가 있더라도, 리트윗의 “geo” 및 “place” 객체는 항상 null입니다. 확장 게시물이 도입되기 이전에도, 루트 레벨의 “entities” 객체는 일부 경우에 “RT @username ” 문자열이 리트윗되는 게시물 메시지에 덧붙여지면서 잘리거나 불완전한 상태가 되었습니다. 리트윗이 다시 리트윗되는 경우에도 “retweet_status”는 여전히 원본 게시물을 가리키며, 이는 중간 리트윗이 포함되지 않는다는 의미입니다. x.com을 사용해 리트윗을 ‘표시(display)‘할 때도 유사한 동작이 나타납니다. 리트윗 ‘액션’에 할당된 고유 Post ID를 복사하면, 원본 게시물이 표시됩니다.  아래는 리트윗의 예시 구조입니다. 다시 말해, 리트윗을 파싱할 때에는 전체 (원본) 게시물 메시지와 엔티티 메타데이터를 얻기 위해 “retweeted_status” 객체를 파싱하는 것이 핵심입니다.
인용 Tweet
인용 Tweet은 새로운 게시물 메시지가 포함된다는 점을 빼면 리트윗과 매우 비슷합니다. 이러한 새 메시지에는 자체 해시태그, 링크 및 기타 “entities” 메타데이터가 포함될 수 있습니다. 인용 Tweet에는 인용 Tweet을 게시하는 사용자가 공유한 위치 정보와 GIF, 동영상, 사진과 같은 미디어가 함께 포함될 수도 있습니다. 인용 Tweet에는 최소 두 개, 경우에 따라 세 개의 게시물 객체가 포함됩니다. 인용되는 게시물(그 자체가 인용 Tweet일 수도 있음)은 “quoted_status” 객체로 제공됩니다. 루트 수준 객체는 공유 동작을 수행하는 계정의 User 객체와 인용 Tweet 시각을 포함하여, 인용 Tweet 자체를 캡슐화합니다. 이제 인용 Tweet에는 ‘Post’ 사용자 인터페이스를 사용해 사진, GIF 또는 동영상을 추가할 수 있다는 점에 유의하세요. 외부에 호스팅된 미디어에 대한 링크가 인용 Tweet 메시지에 포함된 경우, 루트 수준 “entities.urls”에서 이를 서술합니다. 인용 Tweet에 첨부된 미디어는 루트 수준 “extended_entities” 메타데이터에 나타납니다. 인용 Tweet이 처음 출시되었을 때는 단축 링크(t.co URL)가 ‘원본’ 게시물 메시지에 덧붙여져 루트 수준 “text” 필드에 제공되었습니다. 또한 해당 t.co URL에 대한 메타데이터는 루트 수준 ‘entities.urls’ 배열에 포함되었습니다. 2018년 5월에는 사양이 변경되어, 인용된 Tweet으로 연결되는 단축 t.co URL이 루트 수준 “text” 필드에 더 이상 포함되지 않게 되었습니다. 둘째로, 인용된 Tweet에 대한 메타데이터도 “entities.urls” 메타데이터에 더 이상 포함되지 않습니다. 대신, 인용된 Tweet에 대한 URL 메타데이터는 루트 수준(또는 최상위 수준)의 새로운 “quoted_status_permalink” 객체에 포함되며, “quoted_status” 객체와 동일한 계층 수준에 위치합니다. 아래는 이 초기 포맷을 사용하는 인용 Tweet의 예시 구조입니다.
확장 게시물
*확장 게시물(Extended Posts)*을 설명하는 JSON은 280자 게시물이 2017년 11월에 출시될 때 함께 도입되었습니다. 게시물 JSON은 이 더 긴 메시지를 캡슐화하도록 확장되었지만, 이러한 기본 X 객체를 파싱하던 수천 개 App이 동작에 문제가 생기지 않도록 설계되었습니다. 완전한 하위 호환성을 제공하기 위해, 원래의 140자 길이의 ‘text’ 필드와 그로부터 파싱되던 엔터티 객체들은 유지되었습니다. 140자를 초과하는 게시물의 경우 루트 레벨의 ‘text’ 필드는 잘려서(truncated) 불완전해집니다. 루트 레벨의 ‘entities’ 객체에는 포함된 해시태그와 링크처럼 ‘text’ 메시지에서 파싱된 핵심 메타데이터의 배열이 들어 있으므로, 이러한 컬렉션 역시 불완전해지게 됩니다. 예를 들어 게시물 메시지가 200자이고 끝에 해시태그가 포함되어 있다면, 레거시 루트 레벨의 ‘entities.hashtags’ 배열에는 이 해시태그가 포함되지 않습니다.  더 긴 게시물 메시지와 완전한 엔터티 메타데이터를 저장하기 위해 새로운 ‘extended_tweet’ 필드가 도입되었습니다. “extended_tweet” 객체는 140자를 초과할 때 잘리지 않은 전체 게시물 메시지를 담는 “full_text” 필드를 제공합니다. “extended_tweet” 객체에는 해시태그, 링크, 멘션 등의 완전한 배열을 포함하는 “entities” 객체도 들어 있습니다. 확장 게시물은 루트 레벨의 “truncated” 불리언으로 식별됩니다. 값이 true일 때(“truncated”: true) 루트 레벨 필드 대신 “extended_tweet” 필드들을 파싱해야 합니다. 아래 JSON 예시에서 루트 레벨의 “text” 필드는 잘려 있으며, 게시물 메시지에 해시태그가 세 개 포함되어 있음에도 루트 레벨의 “entities.hashtags” 배열은 비어 있다는 점에 주목하십시오. 이는 확장 게시물이므로 “truncated” 필드는 true로 설정되어 있고, “extended_tweet” 객체가 전체 “full_text”와 “entities” 게시물 메타데이터를 제공합니다.

네이티브 Enriched 사용자 객체

User 객체에는 참조된 X 사용자를 설명하는 X 사용자 계정 메타데이터가 포함됩니다. 

사용자 데이터 딕셔너리

더 이상 지원되지 않는(사용 중단됨) 속성

예시 사용자 객체:

네이티브 Enriched Geo 객체

포스트에는 위치를 연결할 수 있으며, 이렇게 하면 ‘지오태그(geo-tagged)’된 게시물이 생성됩니다. 게시물 위치는 X 사용자 인터페이스를 사용하거나 API로 게시물을 작성할 때 지정할 수 있습니다. 게시물 위치는 정확한 ‘포인트(point)’ 위치이거나, 공연장부터 전체 지역에 이르는 더 넓은 영역을 설명하는 ‘바운딩 박스(bounding box)’를 가진 X Place일 수 있습니다. 게시물과 연결된 위치를 설명하기 위해 사용되는 세 개의 ‘루트 레벨’ JSON 객체가 있습니다: place, geo, coordinates 추가로, 네이티브 enriched 형식에는 사용자 객체 내에 프로필 geo enrichment의 파생 위치가 포함됩니다. place 객체는 게시물이 Place로 지오태그될 때마다 항상 존재합니다. Place는 해당 지리 좌표가 있는 특정 이름의 위치를 의미합니다. 사용자가 자신의 게시물에 위치를 지정하기로 선택하면, 후보 X Place 목록이 사용자에게 제시됩니다. API를 사용하여 게시물을 작성할 때는 게시 시 place_id를 지정하여 X Place를 첨부할 수 있습니다. Place와 연결된 포스트는 반드시 해당 위치에서 발행된 것일 필요는 없으며, 해당 위치에 관한 포스트일 수도 있습니다. geo 및 coordinates 객체는 게시물에 정확한 위치 가 지정된 경우에만 (null이 아닌 상태로) 존재합니다. 정확한 위치가 제공되면 coordinates 객체는 지리 좌표가 담긴 [long, lat] 배열을 제공하고, 해당 위치에 대응되는 X Place가 지정됩니다.

장소 데이터 사전

경계 상자

Geo object 데이터 사전

Coordinates object 데이터 사전

파생 위치

예제:

데이터 사전: Enterprise

X 엔티티

이 페이지에서 바로가기 소개 엔티티 객체   - Hashtag 객체   - 미디어 객체   - 미디어 크기 객체   - URL 객체   - 사용자 멘션 객체   - 심볼 객체   - 투표 객체 리트윗 및 인용 트윗 세부 정보 사용자 객체의 엔티티 다이렉트 메시지의 엔티티 다음 단계

소개

엔티티(entities)는 X에 게시된 콘텐츠에 대한 메타데이터와 추가적인 문맥 정보를 제공합니다. entities 섹션에는 게시물에 포함되는 공통 요소들의 배열이 들어 있습니다: 해시태그, 사용자 멘션, 링크, 주식 티커(심볼), X 투표, 그리고 첨부 미디어입니다. 이러한 배열은 포스트를 수집하는 개발자에게 편리한데, X가 본문 텍스트를 사실상 사전 전처리(pre-processed) 또는 사전 파싱(pre-parsed)해 두었기 때문입니다. 게시물 본문에서 이 엔티티들을 직접 검색해 찾아야 하는 대신, 파서가 바로 이 JSON 섹션으로 이동하면 거기에 모두 포함되어 있습니다. 파싱 편의성을 제공하는 것 외에도, entities 섹션은 유용한 부가적인 메타데이터도 제공합니다. 예를 들어, Enhanced URLs enrichment을 사용하는 경우, URL 메타데이터에는 완전히 확장된 URL뿐 아니라 관련 웹사이트의 제목과 설명도 포함됩니다. 또 다른 예로, 사용자 멘션이 있는 경우 엔티티 메타데이터에는 숫자 기반 사용자 ID가 포함되며, 이는 여러 X API에 요청을 보낼 때 유용합니다. 모든 게시물 JSON 페이로드에는 entities 섹션이 포함되며, 여기에 최소한의 hashtags, urls, user_mentions, symbols 속성 집합이 들어갑니다. 이는 해당 엔티티가 게시물 메시지의 일부가 아니더라도 마찬가지입니다. 예를 들어, 본문이 “Hello World!”이고 첨부 미디어가 전혀 없는 게시물의 JSON을 살펴보면, 엔티티 배열에 항목이 0개인 다음과 같은 콘텐츠가 해당 게시물의 JSON에 포함되어 있습니다:
참고:
  • media 및 polls 엔티티는 해당 유형의 콘텐츠가 게시물에 포함된 경우에만 표시됩니다.
  • 네이티브 media(사진, 동영상 또는 GIF)로 작업하는 경우 Extended Entities object를 사용해야 합니다.

Entities object

entitiesextended_entities 섹션은 모두 엔티티 object 배열로 구성됩니다. 아래에서 각 엔티티 object에 대한 설명과 함께, object의 속성 이름, type, 간단한 설명을 담은 데이터 딕셔너리를 확인할 수 있습니다. 또한 이러한 속성과 매칭되는 PowerTrack Operator를 표시하고, 일부 JSON 페이로드 예시도 포함합니다. 포스트에서 공통적으로 발견되는 엔티티(해시태그, 링크, 사용자 멘션 등)의 모음입니다. 이 entities object에는 media 속성이 포함되어 있지만, entiites 섹션에서의 구현은 단일 사진이 있는 포스트에 대해서만 완전히 정확합니다. 둘 이상의 사진, 동영상 또는 애니메이션 GIF가 포함된 모든 포스트에 대해서는 extended_entities 섹션을 참고해야 합니다.

엔티티 데이터 사전

entities 객체는 다른 엔티티 하위 객체 배열을 담는 컨테이너입니다. entities 구조를 먼저 설명한 뒤, 이 하위 객체들에 대한 데이터 사전과 이에 매칭되는 연산자들이 제공됩니다.

해시태그 객체

entities 섹션에는 게시물 본문에 포함된 각 해시태그에 대한 객체를 담고 있는 hashtags 배열이 있으며, 해시태그가 없으면 빈 배열이 포함됩니다. PowerTrack의 # 연산자는 text 속성을 기준으로 매칭하는 데 사용됩니다. has:hashtags 연산자는 배열에 최소 하나의 항목이 있으면 매칭됩니다.

미디어 객체

게시물에 미디어 객체가 ‘첨부’된 경우, entities 섹션은 단일 미디어 객체를 포함하는 media 배열을 포함합니다. 네이티브 미디어가 첨부되지 않은 경우, entities 내에 media 배열은 존재하지 않습니다. 다음과 같은 이유로 게시물의 네이티브 미디어를 처리할 때는 extended_entities 섹션을 사용해야 합니다:
  • 비디오와 GIF가 게시물에 첨부된 경우에도, 미디어 type 은 항상 ‘photo’를 나타냅니다.
  • 최대 네 개의 사진을 첨부할 수 있지만, entities 섹션에는 첫 번째 사진만 나열됩니다.
has:media 연산자는 이 배열에 값이 있으면 매칭됩니다.

미디어 크기 객체

네이티브 미디어(사진, 동영상, GIF)가 포함된 모든 포스트에는 높이와 너비(픽셀 단위) 정보가 있는 ‘thumb’, ‘small’, ‘medium’, ‘large’ 크기 집합이 포함됩니다. 사진 및 미리보기 이미지 미디어 URL의 경우, Photo Media URL formatting에서 서로 다른 크기의 사진 미디어를 로드하기 위한 다양한 URL을 구성하는 방법을 설명합니다.

Sizes object

Size 객체

사진 미디어 URL 포맷팅

X의 사진 미디어는 서로 다른 크기로 로드할 수 있습니다. 특정 이미지 뷰포트에 맞으면서도 그보다 약간 더 큰 크기 중 가능한 한 가장 작은 이미지를 로드하는 것이 가장 좋습니다. 서로 다른 크기를 로드하려면 Size Objectmedia_url(또는 media_url_https)을 특정 형식으로 조합해야 합니다. 사진 미디어 URL을 구성하는 예제로, 앞서 제공된 media entity 예제 객체를 활용하겠습니다. media_url 또는 media_url_https만 단독으로 로드할 수도 있으며, 이 경우 기본적으로 medium 변형이 로드됩니다. 하지만 가능하다면 완전한 형식으로 구성된 사진 미디어 URL을 제공하는 것이 바람직합니다. 사진 미디어 URL은 세 부분으로 구성됩니다: 이 세 부분(Base URL, format, name)을 조합하여 로드할 사진 미디어 URL을 구성합니다. 이 방식으로 이미지를 로드하는 포맷에는 legacymodern 두 가지가 있습니다. 모든 이미지 로드는 legacy 포맷 사용을 중단하고 modern 포맷을 사용해야 합니다. modern 포맷을 사용하면 호출자에게 더 나은 CDN 히트율을 제공하여, 데이터 센터에서 미디어를 새로 생성·로드해야 할 가능성을 줄이고, 그 결과 로드 지연 시간을 개선할 수 있습니다.

URL object

entities 섹션에는 Post 본문에 포함된 각 링크에 해당하는 객체가 들어 있는 urls 배열이 있으며, 링크가 없으면 빈 배열이 포함됩니다. has:links 연산자는 배열에 최소 한 개의 항목이 있을 경우 매치됩니다. url: 연산자는 expanded_url 속성을 기준으로 매치하는 데 사용됩니다. Expanded URL enrichment를 사용하는 경우, url: 연산자는 unwound.url(완전히 풀어낸 URL) 속성을 기준으로 매치하는 데 사용됩니다. Exhanced URL enrichment를 사용하는 경우, url_title:url_decription: 연산자는 unwound.titleunwound.description 속성을 기준으로 매치하는 데 사용됩니다. Expanded 및/또는 Enhanced URL enrichment를 사용하는 경우, 다음 메타데이터가 unwound 속성 아래에서 제공됩니다:

사용자 멘션 객체

entities 섹션에는 게시물 본문에 포함된 각 사용자 멘션마다 하나의 객체를 담은 user_mentions 배열이 포함되며, 사용자 멘션이 없으면 빈 배열이 포함됩니다. PowerTrack @ 연산자는 screen_name 속성 값을 기준으로 매칭하는 데 사용됩니다. has:mentions 연산자는 배열에 최소 한 개의 항목이 있을 경우 매칭됩니다.

Symbol object

entities 섹션에는 게시물 본문에 포함된 모든 $cashtag마다 하나의 객체를 담은 symbols 배열이 포함되며, 심볼이 없으면 빈 배열이 포함됩니다. PowerTrack $ 연산자는 text 속성 값을 기준으로 매치하는 데 사용됩니다. has:symbols 연산자는 배열에 최소 한 개의 항목이 있을 경우 매치됩니다.

Poll 객체

게시물에 투표가 포함되어 있으면 entities 섹션에 단일 poll 객체를 담은 polls 배열이 생성됩니다. 투표가 포함되지 않은 경우 entities 섹션에 polls 배열이 존재하지 않습니다. 이 Poll 메타데이터는 다음 Enterprise API에서만 제공됩니다:

Retweet and Quote Tweet 세부 정보

X API 관점에서 Retweet과 Quote Tweet은 원본 포스트를 포함하는 특수한 종류의 포스트입니다. 따라서 Retweet 및 Quote Tweet 객체는 하위 ‘original’ 포스트를 가진 상위 객체이며(이로 인해 전체 크기가 두 배가 됩니다), Retweet에는 최상위에 “retweeted_status” 객체가 있고, Quote Tweet에는 “quoted_status” 객체가 있습니다. 일관성을 위해 이 최상위 Retweet 및 Quote Tweet 객체에도 text 속성과 관련 엔티티가 있습니다. 다만, 최상위에 있는 엔티티는 포함된 ‘original’ 포스트에서 제공되는 엔티티와 다를 수 있습니다. Retweet의 경우 새 텍스트가 원본 포스트 본문 앞에 추가됩니다. Quote Tweet의 경우 새 텍스트가 포스트 본문 뒤에 추가됩니다. 일반적으로는, 가능한 경우 항상 retweeted_status 내의 원본 포스트에서 텍스트, 엔티티, 원본 작성자 및 날짜를 가져오는 것이 모범 사례입니다. 예외적으로는, 추가된 Quote 부분에 포함된 X 엔티티를 가져와야 하는 경우가 있습니다. 자세한 내용과 팁은 아래를 참고하세요.

Retweets

Retweet과 관련된 중요한 세부 사항은, Retweet 시 해당 게시물에 새로운 X entities 를 추가할 수 없다는 점입니다. 사용자는 Retweet을 할 때 해시태그, URL 또는 기타 세부 정보를 추가할 수 없습니다. 하지만 Retweet의 (top-level) text 속성은 원본 게시물의 텍스트 앞에 “RT @username: ”가 붙은 형태로 구성됩니다.   특히 사용자 이름이 긴 계정의 경우처럼, 새로 추가된 문자와 원본 게시물 본문이 합쳐지면 원래 게시물 텍스트의 길이 제한인 140자를 쉽게 초과할 수 있습니다. 140자 기반 표시 및 저장에 대한 지원을 유지하기 위해, top-level 본문은 게시물 본문의 끝 부분을 잘라내고 말줄임표(“…”)를 추가합니다. 그 결과, 원본 게시물의 끝부분에 위치해 있던 일부 top-level entities — 예를 들어 잘려 나간 해시태그나 URL 항목 — 는 부정확해지거나 누락될 수 있습니다. 다음 게시물(https://x.com/FloodSocial/status/907974220298125312)의 게시물 텍스트는 다음과 같습니다:                Just another test Post that needs to be exactly 140 characters with trailing URL and hashtag http://wapo.st/2w8iwPQ #Testing 위 예시에서는 URL과 해시태그 모두 영향을 받았습니다. 해시태그는 완전히 잘려 나가고 URL은 일부만 잘려 나갔기 때문에, 이들은 top-level entities 에서 누락되어 있습니다. 또한 text 필드 앞에 붙는 “RT @floodsocial: ” 접두어로 인해, 추가적인 user_mentions top-level entity 가 생긴 것도 확인할 수 있습니다. 그러나 retweeted_status 안의 게시물 텍스트와 entities 는 잘림이나 잘못된 entity 없이 원본 게시물을 정확하게 반영하므로, Retweet의 경우에는 중첩된 retweeted_status 객체를 사용하는 것을 권장합니다.

인용 Tweet

인용 Tweet은 2016년에 도입되었으며, Retweet과는 달리 게시물을 “인용(quote)“할 때 공유된 게시물 위에 새로운 콘텐츠를 덧붙인다는 점에서 차이가 있습니다. 이 새로운 콘텐츠에는 원래 게시물이 가질 수 있는 거의 모든 요소를 포함할 수 있으며, 여기에는 새로운 텍스트, 해시태그, 멘션, URL 등이 포함됩니다. 인용 Tweet에는 네이티브 미디어(사진, 동영상, GIF)를 포함할 수 있으며, entities 오브젝트 아래에 나타납니다. X의 entities에 항목을 추가할 수 있으므로, 인용에 해당하는 entities는 원본의 entities와 다를 가능성이 높습니다. 다음 예시에서는 새로운 URL과 해시태그가 인용 Tweet의 끝에 배치되어 있습니다. 이 게시물 https://x.com/FloodSocial/status/907983973225160704 의 게시물 텍스트는 다음과 같습니다:                   strange and equally tragic when islands flood… trans-atlantic testing of quote tweets | @thisuser @thatuserhttp://bit.ly/2vMMDuu #testing 이 경우, 최상위 entities는 인용에 대한 세부 내용을 반영하지 않습니다.  그러나 extended_tweet 내의 게시물 텍스트와 entities는 잘림(truncation)이나 잘못된 엔티티 없이 인용 Tweet을 완벽하게 반영하므로, 인용 Tweet의 경우 중첩된 _extended_tweet_ 오브젝트를 기준으로 삼을 것을 권장합니다.

사용자 오브젝트의 Entities

사용자 오브젝트의 Entities는 사용자가 정의한 프로필 URL 및 설명 필드에 나타나는 URL을 설명합니다. 이들은 해시태그나 user_mentions를 설명하지 않습니다. 게시물 엔티티와 달리, 사용자 엔티티는 상위 오브젝트 내 여러 필드에 적용될 수 있습니다. 이를 구분하기 위해, 어떤 필드에 엔티티가 적용된 URL이 포함되어 있는지 나타내는 상위 노드 urldescription이 제공됩니다. 이 예시에서 사용자 url 필드는 응답의 entities/url/urls[0] 노드 안에 완전히 확장된 형태의 t.co 링크를 포함합니다. 이 사용자의 설명(description)에는 래핑된 URL이 포함되어 있지 않습니다.

JSON 예시

X 확장 엔티티

이 페이지에서 바로가기 소개 Extended Entities 객체 예제 Tweet 및 JSON 페이로드   - 네 장의 네이티브 사진이 포함된 Tweet   - 네이티브 동영상이 포함된 Tweet   - 애니메이션 GIF가 포함된 Tweet 다음 단계

소개

게시물에 네이티브 미디어(외부 링크가 아니라 게시물 UI를 통해 공유된 미디어)가 포함되어 있으면 extended_entities 섹션도 존재합니다. 네이티브 미디어(사진, 동영상, GIF)의 경우 여러 가지 이유로 extended_entities가 선호되는 메타데이터 소스입니다. 현재 하나의 게시물에는 최대 네 장의 사진을 첨부할 수 있습니다. entities 메타데이터에는 첫 번째 사진만 포함되지만(2014년까지는 사진을 한 장만 포함할 수 있었습니다) extended_entities 섹션에는 첨부된 모든 사진이 포함됩니다. 네이티브 미디어에서 entities.media 메타데이터의 또 다른 한계점은, 첨부된 미디어가 동영상이거나 애니메이션 GIF인 경우에도 미디어 type이 항상 ‘photo’로 표시된다는 점입니다. 실제 미디어 유형은 extended_entities.media[].type 속성에 지정되며, photo, video, animated_gif 중 하나로 설정됩니다. 이러한 이유로 네이티브 미디어를 다루는 경우에는 extended_entities 메타데이터를 사용하는 것이 가장 좋습니다. 사진, 동영상, 애니메이션 GIF가 첨부된 모든 포스트에는 extended_entities JSON 객체가 포함됩니다. extended_entities 객체에는 media 객체들로 이루어진 단일 media 배열이 포함됩니다(데이터 사전은 entities 섹션을 참조). 해시태그나 링크와 같은 다른 엔티티 typeextended_entities 섹션에는 포함되지 않습니다. extended_entities 섹션의 media 객체는 entities 섹션에 포함된 것과 구조가 동일합니다. 게시물에는 한 종류의 미디어만 첨부할 수 있습니다. 사진의 경우 최대 네 장까지 첨부할 수 있고, 동영상 및 GIF는 하나만 첨부할 수 있습니다. extended_entities 섹션의 미디어 type 메타데이터는 미디어 유형(‘photo’, ‘video’, ‘animated_gif’)을 정확히 나타내며 최대 4장의 사진을 지원하므로, 네이티브 미디어에 대해서는 우선적으로 사용해야 하는 메타데이터 소스입니다.

포스트 예시와 JSON 페이로드

아래는 몇 가지 포스트 예시와 각 포스트에 연결된 엔티티 메타데이터입니다. 네 개의 네이티브 사진이 포함된 포스트 해시태그, 사용자 멘션, 캐시태그, URL, 네 개의 네이티브 사진이 포함된 포스트:
이 포스트에 대한 entities 섹션은 다음과 같습니다:
아래의 이 ‘extended’ 페이로드에만 최대 네 개의 네이티브 사진이 포함됩니다. 배열의 첫 번째 사진이 extended가 아닌 X entities 섹션에 포함된 단일 사진과 동일하다는 점에 유의하세요. 사진용 media 메타데이터 구조는 entities 섹션과 extended_entities 섹션 모두에서 동일합니다. 이 게시물의 extented_entities 섹션은 다음과 같습니다:

네이티브 동영상이 포함된 게시물

아래는 동영상이 포함된 이 게시물의 extended entities 메타데이터입니다:
광고주가 동영상 재생을 X가 소유·운영하는 플랫폼에서만 가능하도록 제한하기로 선택하면, video_info 객체는 additional_media_info 객체로 대체됩니다. additional_media_info에는 게시자가 제공한 title, description, embeddable flag 등 추가 미디어 정보가 포함됩니다. embeddable=false인 경우 동영상 콘텐츠는 X의 공식 클라이언트에서만 이용할 수 있습니다. 이때 페이로드에 포함된 모든 동영상 URL은 X 기반이므로, 사용자는 링크를 클릭해 X 소유 자산에서 동영상을 열 수 있습니다. 이러한 상황에서 extended entities 객체가 어떻게 표시되는지에 대한 예시는 다음과 같습니다:
위에서 설명했듯이, 아래는 type이 ‘photo’로 잘못 설정된 entities 섹션입니다. 다시 한 번, ‘video’와 ‘animated_gif’을 포함한 모든 네이티브 미디어 타입에는 extended_entities 섹션을 사용하는 것이 권장됩니다.

애니메이션 GIF가 포함된 게시물

아래는 이 애니메이션 GIF 게시물의 extended entities 메타데이터입니다.

Native Enriched 예시 페이로드

게시물

답글 게시물

확장 게시물

extended_entitites 필드가 포함된 게시물

리트윗

인용 Tweet

리트윗된 인용 Tweet

Enterprise Activity Streams 데이터 객체

Activity Streams 데이터 형식이 X API v2 형식에 어떻게 매핑되는지 더 알아보고 싶으신가요?
비교 가이드를 확인하세요: Activity Streams compared to X API v2
주의: 엔터프라이즈 데이터 API에는 Enriched Native 형식을 사용하는 것을 강력히 권장합니다. 
  • Enriched Native 형식에는 투표 메타데이터와 같은 2017년 이후의 모든 신규 메타데이터와 reply_count 및 quote_count 같은 추가 지표(메트릭)가 포함되어 있습니다.
  • Activity Streams 형식은 2017년의 문자 수 업데이트 이후 새로운 메타데이터나 데이터 보강(enrichment)으로 업데이트되지 않았습니다.

Activity Object

Activity Streams는 Gnip이 만든 객체 스키마로, X의 원래 데이터 형식을 제3자 Activity Base Schema(여기에서 설명)를 사용해 게시물 데이터와 기타 소셜 미디어 데이터를 ‘형식 표준화(normalize the format)’하기 위해 변환한 것입니다. 포스트는 note, person, place, service 객체 type과 같은 중첩 객체들을 포함하는 Activity Streams 스키마로 정규화됩니다. 포스트에는 Retweet에 대한 중첩 게시물 activity 객체나 twitter_quoted_status, long_object 등이 중첩될 수 있습니다. 기본 레벨 객체 type인 “activity”는 네이티브 enriched 형식의 게시물 기본 레벨 객체와 유사합니다. Activity Streams 형식의 예제 payload는 여기에서 확인할 수 있습니다.

데이터 사전

아래에서 이러한 ‘루트 수준’ “activity” 속성에 대한 데이터 사전과 하위 객체 데이터 사전에 대한 링크를 확인할 수 있습니다.

추가 게시물 속성

사용 중단된 속성

중첩된 게시물 활동 객체

여러 경우에 Post 객체 안에는 다른 중첩된 게시물이 포함됩니다. 중첩 객체를 다루는 경우, 해당 JSON 페이로드에는 여러 객체가 포함되며, 각 Post 객체는 자체적인 하위 객체를 포함할 수 있습니다. 루트 수준 객체에는 Retweet 인지 Quote Tweet 인지와 같이 수행된 작업의 type 정보가 포함되며, 공유되는 ‘원본’ 게시물을 설명하는 객체를 포함할 수도 있습니다. Extended Posts 에는 2017년 업데이트 당시 하위 호환성 유지를 위해 140자를 초과하는 내용을 담기 위한 중첩 확장 객체가 포함됩니다. 각 중첩 객체 딕셔너리에 대해서는 아래에서 설명합니다. Retweet Retweet 의 Activity Streams 형식에는 Retweet 되고 있는 원본 게시물을 표현하기 위해 type 이 “activity” 이고 verb 가 “note” 인 중첩 객체가 포함됩니다.
X 인용 상태 Activity Streams 형식에는 인용 Tweet이 임베드됩니다 { "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:

Long object

extended_tweet의 Activity Streams 포맷

Actor 객체

Actor 객체에는 활동을 생성한 X 사용자를 설명하는 X 사용자 계정 메타데이터가 포함되어 있습니다.

데이터 사전

더 이상 지원되지 않는(사용 중단된) 속성

예시:

Location Object

Location objects는 X 계정 수준에서 설정된 actor object 내에 존재할 수도 있고, gnip object의 profileLocations object 내에 존재할 수도 있습니다. Location objects는 place object type을 가지며, name, address 또는 geo coordinates를 포함할 수 있습니다. Location objects는 네이티브 enriched 형식의 Geo와 유사합니다.

Location 데이터 사전

profileLocations 파생 객체

예시

X 엔티티 객체

Activity Streams 형식의 경우, twitter_entities는 네이티브 확장 형식의 엔티티 객체와 동일한 형식과 데이터 사전을 갖습니다.

예시:

X extended entities object

Activity Streams 형식의 경우, twitter_extended_entities는 네이티브 enriched 형식에서 extended_entities 객체에 표시된 것과 동일한 형식과 데이터 사전을 따릅니다.

예시:

Gnip object

Activity Streams 형식에서 gnip 객체는 활성화된 enrichment 기능에 의해 추가된 메타데이터와 해당 activity에 매칭된 규칙 정보를 포함합니다.

데이터 사전

예시:

Activity Streams 페이로드 예시

게시물 활동
답글 게시물 Activity
long_object가 포함된 게시물 액티비티
twitter_extended_entities를 포함한 게시물 activity
리트윗 활동
인용 Tweet 활동
리트윗된 인용 Tweet 활동

Tweet 메타데이터 타임라인

이 페이지 내 바로가기 소개 핵심 개념 X 타임라인 필터링 팁 다음 단계

소개**

본질적으로 X는 공개적이고, 실시간이며, 전 세계적인 커뮤니케이션 네트워크입니다. 2006년 이후 X의 발전은 사용자 이용 패턴과 관례, 그리고 새로운 제품 기능과 개선 사항에 의해 주도되어 왔습니다. X 데이터를 활용해 역사 연구를 수행하는 경우, 이러한 발전의 타임라인을 이해하는 것은 데이터 아카이브에서 관심 있는 게시물을 찾아내는 데 중요합니다. X는 단순한 SMS 모바일 App으로 시작하여 종합적인 커뮤니케이션 플랫폼으로 성장했습니다. 완전한 API 세트를 갖춘 플랫폼입니다. API는 항상 X 네트워크의 한 축이었습니다. 첫 번째 API는 X가 출시된 직후 곧바로 공개되었습니다. 2009년에 게시물 지오태깅이 처음 도입되었을 때, 이는 Geo API를 통해 제공되었으며(이후 게시물에 ‘지오태그’를 추가하는 기능은 X.com 사용자 인터페이스에 통합되었습니다). 오늘날 X의 API는 속보와 정보 공유의 원천이 된 양방향 커뮤니케이션 네트워크를 구동하고 있습니다. 이 전 세계 실시간 커뮤니케이션 채널 위에 무언가를 구축할 수 있는 기회는 무궁무진합니다. X는 공개적으로 이용 가능한 모든 게시물에 접근할 수 있는 두 가지 히스토리컬 API, 즉 Historical PowerTrack과 Full-Archive Search API를 제공합니다. 두 API 모두 관심 있는 게시물을 쿼리하고 수집하는 데 사용되는 연산자 세트를 제공합니다. 이러한 연산자는 각 게시물과 연관된 다양한 속성에 대해 매칭을 수행하며, 게시물의 텍스트 콘텐츠, 작성자의 계정 이름, 게시물에 포함된 링크 등 수백 가지 속성이 이에 포함됩니다. 게시물과 그 속성은 일반적인 텍스트 기반 데이터 교환 형식인 JSON으로 인코딩됩니다. 따라서 새로운 기능이 도입될 때마다 새로운 JSON 속성이 등장했고, 일반적으로는 해당 속성에 대해 매칭할 수 있는 새로운 API 연산자도 함께 도입되었습니다. 사용 사례에 전 세계가 X에서 무엇을 말했는지 리스닝 해야 하는 요구가 포함되어 있다면, 연산자가 언제부터 매칭할 수 있는 JSON 메타데이터를 갖기 시작했는지를 잘 이해할수록 히스토리컬 PowerTrack 필터를 더 효과적으로 구성할 수 있습니다. 다음으로, 게시물 메타데이터의 변경 사항이 관심 있는 데이터 신호를 찾는 데 어떤 영향을 미치는지 이해하는 데 도움이 되는 몇 가지 핵심 개념을 소개하겠습니다.

핵심 개념**

사용자 관습에서 X 일급 객체

X 사용자들은 자연스럽게 새로운, 그리고 이제는 필수적인 커뮤니케이션 패턴들을 X 네트워크에 도입했습니다. 대표적인 예가 해시태그로, 이제 거의 모든 소셜 네트워크에서 사용됩니다. 해시태그는 대화와 주제를 정리하기 위한 방법으로 도입되었습니다. 하루에 수억 개의 메시지가 오가는 네트워크에서, 관심 있는 포스트를 찾기 위한 도구는 핵심이며, 해시태그는 이를 위한 기본적인 방법이 되었습니다. 해시태그 사용이 증가한 직후, 해시태그는 X로부터 공식적인 지위와 지원을 받게 되었습니다. 해시태그가 ‘일급(first-class)’ 객체 가 되었다는 것은 여러 가지 의미를 가집니다. 이는 해시태그가 X.com 사용자 인터페이스에서 클릭 및 검색이 가능해졌다는 뜻이기도 합니다. 또한 해시태그가 @멘션, 첨부 미디어, 주식 심볼, 공유 링크와 함께 X의 entities 패밀리의 구성원이 되었다는 의미이기도 합니다. 이러한 엔티티들은 미리 파싱된 JSON 배열로 편리하게 인코딩되어, 개발자가 이를 더 쉽게 처리하고, 스캔하며, 저장할 수 있도록 합니다. 리트윗은 사용자 주도의 관습이 공식 객체가 된 또 다른 예시입니다. 리트윗은 다른 사람에게 콘텐츠를 ‘포워딩’하는 방법으로 등장했습니다. 처음에는 게시물을 복사해 붙여넣고 앞에 “RT @” 패턴을 붙이는 수동 프로세스로 시작되었습니다. 이 과정은 결국 새로운 리트윗 버튼을 통해 자동화되었고, 새로운 JSON 메타데이터까지 제공하게 되었습니다. 이렇게 ‘공식’ 리트윗이 탄생했습니다. 그 밖의 예로는 ‘멘션’, 미디어 및 웹 링크 공유, 그리고 게시물에 위치를 함께 공유하는 기능 등이 있습니다. 이러한 각 사용 패턴은 새로운 x.com 사용자 인터페이스 기능, 이를 지원하는 새 JSON, 그리고 포스트와 매칭하는 새로운 방법으로 이어졌습니다. 이러한 모든 기본 게시물 속성들은 결국 이를 기준으로 매칭하기 위한 PowerTrack Operators로 이어졌습니다.

게시물 메타데이터, 가변성, 업데이트, 최신성

게시물 메시지는 정해진 최대 글자 수까지만 작성할 수 있지만, 게시물을 나타내는 JSON은 100개가 넘는 속성으로 구성됩니다. 누가 언제 게시했는지, 원본 게시물인지 리포스트인지 여부와 같은 속성뿐 아니라 해시태그, 멘션, 공유 링크와 같은 일급 객체들의 배열도 포함됩니다. 게시물을 게시한 계정에 대해서는 사용자의 프로필 및 기타 계정 메타데이터를 제공하는 다양한 속성을 가진 User(또는 Actor) 객체가 있습니다. 프로필에는 짧은 소개 문구, 거주지(자유 형식 텍스트), 선호 언어, 선택적 웹사이트 링크가 포함됩니다. 일부 계정 메타데이터는 절대 변경되지 않습니다(예: 숫자형 사용자 ID와 생성 일자). 어떤 것들은 시간이 지나면서 서서히 변경되고, 다른 속성들은 더 자주 바뀝니다. 사람들은 직장을 바꾸고 이사를 합니다. 회사는 정보를 갱신합니다. 과거 게시물을 수집할 때는, 일부 메타데이터는 게시물이 게시되었을 당시의 그대로 이고, 다른 메타데이터는 쿼리를 제출하는 시점 기준 이라는 점을 이해하는 것이 중요합니다.  모든 이력 관련 API에서, 사용자의 프로필 설명, 표시 이름, 프로필 ‘home’ 속성은 쿼리 시점의 값으로 업데이트됩니다.

“네이티브” 미디어

X.com과 X 모바일 앱에서는 버튼을 클릭해 사진 갤러리를 탐색하여 게시물에 사진과 동영상을 추가할 수 있습니다. 이제 이러한 기능이 일급 동작으로 통합되었기 때문에, 이 방식으로 공유된 동영상과 사진을 ‘네이티브’ 미디어라고 부릅니다. 많은 쿼리 Operator가 이러한 ‘네이티브’ 리소스에 대해 동작하며, 여기에는 has:videos, has:images, has:media 등이 포함됩니다. 이 Operator들은 X 기능을 통해 공유된 미디어 콘텐츠에만 일치합니다. X 플랫폼 외부에 호스팅된 다른 미디어와 일치시키려면, URL 메타데이터를 기준으로 일치하는 Operator를 사용해야 합니다. 그래서 Historical PowerTrack과 Full-Archive Search 제품의 세부 사항을 살펴보기 전에, 제품이자 플랫폼으로서 X가 시간이 지나며 어떻게 발전해 왔는지 먼저 살펴보겠습니다. X 연대표 아래에는 X의 일부 연대표 를 정리해 두었습니다. 이러한 X 업데이트 대부분은 어느 정도는 사용자 행동, 게시물 JSON 내용, 쿼리 Operator, 또는 이 세 가지 모두에 근본적인 영향을 미쳤습니다. X를 API 플랫폼으로 바라보면, 다음 이벤트들은 게시물을 인코딩하는 데 사용되는 JSON 페이로드에 어떤 식으로든 영향을 주었습니다. 그 결과 이러한 JSON 세부 정보는 X historical API가 게시물을 어떻게 매칭하는지에도 영향을 줍니다. 이 연대표 목록은 전반적으로는 정확한 편이지만, 모든 항목을 망라한 것은 아니라는 점에 유의하세요.

2006

  • 10월
    • @replies 사용 관례가 자리 잡습니다.
    • cashtags가처음등장하지만,주식티커언급에사용하는것이일반화되는것은2009년초부터입니다.cashtags가 처음 등장하지만, 주식 티커 언급에 사용하는 것이 일반화되는 것은 2009년 초부터입니다. Cashtags는 2012년 6월에 클릭할 수 있고 검색 가능한 링크가 됩니다.
  • 11월 - Favorites가 도입됩니다.

2007

  • 1월 - @reply가 in_reply_to 메타데이터를 가진 UI 답글 버튼과 함께 일급 객체가 됩니다.
  • 4월 - 리트윗이 하나의 관행으로 자리잡습니다.
  • 8월 - #해시태그가 포스트를 검색하고 정리하는 주요 도구로 등장합니다.

2009

  • 2월 - $cashtags가 주식 티커 심볼을 논의할 때 사용하는 일반적인 관례로 자리 잡습니다.
  • 5월 - 게시물 본문 앞에 “Via @”를 붙이는 Retweet ‘베타’가 도입됩니다.
  • 6월 - 인증 계정(Verified account)이 도입됩니다.
  • 8월 - “RT @” 패턴과 새로운 retweet_status 메타데이터와 함께 Retweet이 일급 객체로 도입됩니다.
  • 10월 - 리스트 기능이 출시됩니다.
  • 11월 - Post Geotagging API가 출시되어, 사용자가 서드 파티 앱을 통해 위치를 공유할 수 있는 최초의 방법을 제공합니다.

2010

  • 6월 - 포스트에 지오태그를 달 수 있는 X Places가 도입되었습니다.
  • 8월 - 웹사이트용 게시물 버튼이 출시되어 링크 공유가 더 쉬워졌습니다.

2011

  • 5월 - 웹사이트와 연결된 계정을 더 쉽게 팔로우할 수 있도록 팔로우 버튼이 도입되었습니다.
  • 8월 - 네이티브 사진 기능이 도입되었습니다.

2012

  • 6월 - $Cashtags가 클릭하거나 검색할 수 있는 링크가 됩니다.

2014

  • 3월 - 사진 태그 기능과 최대 4장의 사진 지원. 확장된 X Entities 메타데이터가 도입되었습니다.
  • 4월 - X UI에서 이모지가 기본 지원되기 시작했습니다. 이모지는 적어도 2008년부터 게시물에서 일반적으로 사용되어 왔습니다.

2015

  • 4월 - X의 ‘게시물’ 사용자 인터페이스 디자인이 변경되면서 위치 정보가 포함된 게시물 수가 줄어들었습니다.
  • 10월 - X Polls 도입. Polls는 처음에는 24시간 투표 기간으로 두 개의 선택지만 지원했습니다. 11월에는 Polls가 네 개의 선택지와 5분부터 7일(일주일)까지의 투표 기간을 지원하기 시작했습니다. Poll 메타데이터는 2017년 2월에 제공되기 시작했으며, 확장 네이티브 형식에서만 제공되었습니다.

2016

2017

  • 2월 - X Poll 메타데이터가 게시물 메타데이터에 포함됨(강화된 네이티브 형식에서만 제공).
  • 4월 - 회신 대상 계정이 140자 수에 포함되지 않는 ‘Simplified Replies’ 도입(“dmw140, part 2”).
2018
  • 5월 - GDPR 업데이트에 따라 user.time_zone이 null로 설정되고, user.utc_offset이 null로 설정되며, user.profile_background_image_url이 기본값으로 설정됨
  • 6월 - quoteTweet 서식 변경 반영
2022
  • 9월 29일 - 포스트를 수정할 수 있는 기능이 소규모 테스트 그룹에 롤아웃됨. 수정된 게시물 메타데이터가 관련되는 경우 게시물 객체에 추가됨. 여기에는 edit_history 및 edit_controls 객체가 포함됨. 이러한 메타데이터는 수정 기능이 추가되기 전에 생성된 포스트에는 반환되지 않음. 이 메타데이터와 연결된 연산자는 없음. 게시물 수정이 어떻게 작동하는지 더 알아보려면 게시물 편집 기본 사항을 참고하세요.
필터링 팁 X 타임라인에서 새로운 기능이 언제, 어떻게 추가되었는지 숙지하면 더 효과적인 쿼리를 만드는 데 도움이 됩니다. 여기서 쿼리는 X 과거용 API가 Post JSON에 매칭하기 위해 PowerTrack 연산자를 사용하여 포스트 아카이브에 적용하는 필터 또는 규칙 을 의미합니다. 예로, 특정 언어의 포스트에 매칭하는 데 사용되는 lang: 연산자가 있습니다. X는 50개가 넘는 언어를 지원하는 언어 분류 서비스를 제공하며, X API는 각 게시물에 대해 생성되는 JSON에 이 메타데이터를 제공합니다. 따라서 게시물이 스페인어로 작성되면 “lang” JSON 속성은 “es”로 설정됩니다. 따라서 lang:es 절을 사용해 필터를 구성하면 스페인어로 분류된 포스트에만 매칭됩니다. 타임라인 정보는 수신한 포스트 데이터를 더 잘 해석하는 데도 도움이 됩니다. 예를 들어, 2008년과 2012년 하계 올림픽 관련 콘텐츠 공유를 연구한다고 가정해 봅시다. 리트윗에 매칭하기 위해 is:retweet 연산자만 적용하면 2008년에는 어떤 데이터도 매칭되지 않을 것입니다. 하지만 2012년에는 수백만 개의 리트윗이 있을 수 있습니다. 이로 인해 2008년에는 리트윗이 사용자 관행이 아니었거나, 아무도 그 올림픽에 대해 리트윗하지 않았다는 잘못된 결론을 내릴 수 있습니다. 리트윗이 2009년에 일급(first-class) 객체가 되었기 때문에, 2008년의 리트윗을 식별하려면 ”RT @” 규칙 절을 추가해야 합니다. 리트윗과 포스트 언어 분류는 모두 오랜 역사와 다양한 제품 세부 정보를 가진 포스트 속성의 예입니다. 아래에서 X 데이터를 매칭하고 이해하는 데 중요한 이러한 속성과 다른 속성 클래스에 대한 더 많은 세부 정보를 설명합니다.

거짓 음성 인식하기

필터를 작성할 때 중요한 점 중 하나는, 메타데이터 연산자가 일치 여부를 판단하는 모든 메타데이터에는 각각 “생성 시점(“born on” date)”이 있다는 것입니다. 포스트가 게시된 이후에 도입된 메타데이터에 작동하는 연산자로 필터를 구성하면, 거짓 음성이 발생하게 됩니다. 예를 들어, ‘snow’를 언급하면서 동영상을 공유하는 모든 포스트에 관심이 있다고 가정해 보겠습니다. 이때 네이티브 동영상이 있는 포스트와 일치하는 has:videos 연산자로 규칙을 만들면, 그 절은 2015년 이전의 어떤 포스트와도 일치하지 않습니다. 하지만 X에서 동영상 공유는 2015년 훨씬 이전부터 일반적이었습니다. 그전에는 사용자가 다른 곳에 호스팅된 동영상으로 연결되는 링크를 공유했지만, 2015년에 X가 플랫폼에 직접 ‘동영상 공유’ 기능을 새로 구축했습니다. 이러한 과거의 관심 포스트를 찾으려면 url:”youtube.com”과 같은 규칙 절을 추가해야 합니다. 또한 Search API에서는 인덱스를 재구축하면서 일부 메타데이터를 소급 반영(‘backfill’)한 사례도 있습니다. 좋은 예가 주식 종목 기호를 논의할 때 널리 사용되기 시작한 2009년의 cashtag입니다.cashtag입니다. cashtag 연산자가 2015년에 도입된 후 Search 인덱스가 재구축되었고, 그 과정에서 심벌 엔티티가 $가 주로 속어에 사용되던 2006년 초반의 포스트까지 포함해, 모든 포스트 본문에서 추출되었습니다. 예: “I hope it nownow $oon!”.

사용 사례에 중요한 게시물 속성 식별 및 필터링

X 계정 숫자 ID와 같은 일부 메타데이터는 서비스 초기부터 존재해 왔으며(변경되지 않는 계정 메타데이터의 한 예입니다), 다른 메타데이터는 2006년에 X가 시작된 이후 상당한 시간이 지난 뒤에야 도입되었습니다. 새로 도입된 메타데이터의 예로는 리트윗 메타데이터, 게시물 위치 정보, URL 제목 및 설명, 그리고 ‘네이티브’ 미디어 등이 있습니다. 아래에는 이러한 X 플랫폼 업데이트로 인해 근본적으로 영향을 받은, 가장 일반적인 유형의 게시물 속성들을 정리해 두었습니다. 이 속성들에 대한 필터링/매칭 동작은 대부분의 경우 어떤 과거용 게시물 API(역사 데이터용 Post API)를 사용하느냐에 따라 달라집니다. 어떤 제품이 여러분의 연구 및 사용 사례에 가장 적합한지 판단하는 데 도움을 드리기 위해, 아래에 제공되는 속성 상세 정보에는 개괄적인 제품 정보도 함께 포함되어 있습니다.

X Profiles

무엇보다 X는 전 세계 실시간 커뮤니케이션 채널이기 때문에, 게시물 데이터를 활용한 연구에서는 누가 소통하고 있는지에 중점을 두는 경우가 많습니다. X 사용자가 어디를 자신의 거주지로 삼고 있는지 아는 것이 도움이 될 때가 자주 있습니다. 계정의 자기소개(bio)에 관심사와 취미에 대한 언급이 포함되어 있는지를 알면, 관심 있는 게시물을 찾는 데 도움이 될 수 있습니다. 또한 관심 있는 계정에서 나오는 포스트를 모니터링하고 싶어 하는 경우도 매우 흔합니다. 이러한 모든 사용 사례에서 프로필 속성은 핵심적인 역할을 합니다. X의 모든 계정에는 X @handle, 표시 이름(display name), 짧은 자기소개(bio), 거주지(사용자가 자유 형식으로 입력한 텍스트), 팔로워 수 등 다양한 메타데이터가 포함된 프로필이 있습니다. 숫자형 user id 및 계정 생성 시점과 같이 절대 변경되지 않는 속성도 있습니다. 반면 게시한 포스트 수, 팔로우하는 계정 수, 팔로워 수와 같이 보통 하루, 일주일, 한 달 단위로 변하는 속성도 있습니다. 표시 이름, 거주지, 자기소개와 같은 다른 계정 속성도 언제든지 변경될 수 있지만, 상대적으로 변경 빈도는 낮은 편입니다. 모든 게시물의 JSON payload에는 해당 게시물 작성자에 대한 계정 프로필 메타데이터가 포함됩니다. 해당 게시물이 리트윗(Retweet)인 경우, 원본 게시물을 올린 계정의 프로필 메타데이터도 함께 포함됩니다. 게시물의 프로필 메타데이터가 얼마나 변할 수 있는지는 사용한 과거 데이터 제품에 전적으로 달려 있습니다. Search API는 검색을 수행하는 시점의 프로필 설정을 기준으로 과거 포스트를 제공합니다. Historical PowerTrack의 경우, 2011년 이전 데이터를 제외하면 게시물이 게시된 시점의 프로필이 반영됩니다. 2011년보다 오래된 포스트에 대해서는, 프로필 메타데이터가 2011년 9월 당시의 프로필을 반영합니다.

원본 게시물과 리트윗

리트윗은 사용자 주도의 관행이 공식 객체가 된 또 다른 예입니다. 리트윗은 다른 사람에게 콘텐츠를 ‘전달’하는 방식으로 등장했습니다. 처음에는 게시물을 복사/붙여넣기하고 앞에 “RT @” 패턴을 붙이는 수동 프로세스로 시작되었습니다. 이후 이 프로세스는 새로운 리트윗 버튼으로 자동화되었고, 이에 맞춰 새로운 JSON 메타데이터도 도입되었습니다. 이렇게 ‘공식’ 리트윗이 탄생했고, 리트윗하는 행위는 일급 게시물 이벤트로 취급되기 시작했습니다. 또한 새로운 리트윗 버튼과 함께, 원본 게시물의 전체 페이로드와 같은 새로운 메타데이터도 도입되었습니다. 게시물이 원본인지 재공유된 것인지는 일반적으로 사용하는 필터링 ‘스위치’입니다. 어떤 경우에는 원본 콘텐츠만 필요합니다. 다른 경우에는 게시물 참여도가 가장 중요하므로 리트윗이 핵심이 됩니다. PowerTrack is:retweet 연산자는 사용자가 리트윗을 포함하거나 제외할 수 있도록 해줍니다. 2009년 8월 이전의 데이터를 가져오는 경우, 사용자는 리트윗 일치(또는 비일치)를 위해 두 가지 전략이 필요합니다. 2009년 8월 이전에는 게시물 텍스트 자체에서 “@RT ” 패턴이 있는지 정확한 구문 일치 방식으로 확인해야 합니다. 2009년 8월 이후 기간에 대해서는 is:retweet 연산자를 사용할 수 있습니다.

게시물 언어 분류

게시물이 어떤 언어로 작성되었는지는 많은 경우 중요한 관심 정보입니다. 게시물 언어는 게시물의 위치를 추론하는 데 도움이 되며, 분석이나 표시 목적상 특정 언어만 필요할 때가 자주 있습니다. (X 프로필에는 선호 언어 설정도 있습니다.) 게시물 언어 분류를 기준으로 필터링할 때 X의 과거용 제품들(Search API 및 Historical PowerTrack)은 서로 상당히 다릅니다. Search 아카이브를 구축할 때 모든 게시물에 X 언어 분류가 소급 적용(backfill)되었습니다. 따라서 lang: 연산자는 전체 게시물 아카이브에 대해 사용할 수 있습니다. Historical PowerTrack에서는 X의 언어 분류 메타데이터가 2013년 3월 26일부터 아카이브에 포함되어 제공됩니다. 

포스트의 지리 정보 참조

게시물이 어디에서 게시되었는지(즉, 지리 정보를 통해 참조하는 것)를 파악하는 것은 많은 사용 사례에서 중요합니다. 포스트의 지리 정보를 참조하는 주요 방법은 세 가지가 있습니다.
  • 게시물 메시지에 포함된 지리적 정보
  • 사용자가 위치 태그(지오태그)를 지정한 포스트
  • 사용자가 계정 프로필에 설정한 ‘home’ 위치
게시물 메시지의 지리적 참조
게시물 메시지의 지리적 참조를 기준으로 매칭하는 방식은 지역에 대한 지식에 의존하므로 가장 까다로운 방법인 경우가 많지만, 전체 게시물 아카이브에 사용할 수 있는 한 가지 옵션입니다. 아래는 ‘golden gate’ 필터를 사용해 2006년 샌프란시스코 지역에 대해 수행한 지리적 참조 기반 매칭 예시입니다: https://x.com/biz/statuses/28311
사용자가 지오태깅한 포스트
2009년 11월 X는 포스트를 정확한 위치와 함께 지오태깅할 수 있게 해주는 Post Geotagging API를 도입했습니다. 2010년 6월에는 장소, 동네, 도시 규모의 지리적 영역을 표현하는 X Places를 도입했습니다. 전체 포스트 중 약 1–2%가 이 두 가지 방법 중 하나를 사용해 지오태깅되어 있습니다. 사용 가능한 지오태깅 이력은 사용 중인 Historical API에 따라 달라집니다. Search APIs의 경우, 일부 Geo 연산자를 사용해 포스트를 매칭할 수 있는 기능은 2010년 3월부터 제공되었고, 다른 연산자들은 2015년 2월부터 제공되었습니다. Historical PowerTrack을 사용하는 경우, 지리 참조(geo-referencing)는 2011년 9월 1일부터 시작됩니다. Historical PowerTrack 아카이브가 구축될 때 이 날짜 이전의 모든 지오태깅 데이터는 포함되지 않았습니다.
사용자가 설정한 계정 프로필 ‘홈’ 위치
모든 X 사용자는 자신의 프로필 위치(Profile Location)를 설정해 홈 위치를 표시할 수 있습니다. 수많은 X 사용자가 이 정보를 제공하며, 이는 X Firehose 내 지리 데이터(geodata)의 양을 크게 늘립니다. 이 위치 메타데이터는 비정규화된, 사용자 생성의 자유 형식 문자열입니다. 약 30%의 계정에는 국가 수준까지 해석(매핑)할 수 있는 Profile Geo 메타데이터가 포함되어 있습니다. 게시물 geo와 마찬가지로, 매칭 방법과 사용 가능한 기간은 사용 중인 Historical API에 따라 달라집니다. Historical PowerTrack을 사용하면 이러한 자유 형식 문자열에 대해 직접 사용자 정의 매칭을 시도할 수 있습니다. 이 프로세스를 더 쉽게 하기 위해 X는 가능한 경우 지오코딩을 수행해 정규화된 메타데이터와 해당 연산자(Operator)를 제공하는 Profile Geo Enrichment도 제공합니다. Profile Geo 연산자는 Historical PowerTrack과 Search API 양쪽에서 모두 사용할 수 있습니다. Historical PowerTrack의 경우 이 Profile Geo 메타데이터는 2014년 6월부터 제공됩니다. Search API의 경우 이 메타데이터는 2015년 2월부터 제공됩니다. 웹 페이지 링크, 사진, 동영상 공유는 항상 X의 핵심 사용 사례였습니다. 초기에는 이러한 작업을 모두 게시물 메시지 자체에 URL 링크를 포함하는 방식으로 수행했습니다. 2011년에는 X가 사진 공유 기능을 사용자 인터페이스에 직접 통합했고, 2016년에는 네이티브 동영상이 추가되었습니다. 이러한 배경으로, 이 콘텐츠를 매칭하기 위해 사용되는 다양한 필터링 연산자가 존재합니다. 포스트에 공유된 링크, 사진, 동영상이 있는지 여부를 기준으로 매칭하는 연산자 집합이 있습니다. 또한 X에서 공유되는 대부분의 URL은 포스트의 문자 수를 덜 차지하도록 단축되기 때문에(예: bitly나 tinyurl 같은 서비스에서 생성된 URL), X는 매칭에 사용할 수 있는 완전한 확장 URL을 생성하는 데이터 보강 기능을 제공합니다. 예를 들어, X와 조기 경보 시스템에 대해 논의하는 링크가 포함된 포스트를 매칭하고 싶다면, ‘severe weather communication’을 참조하는 필터는 http://bit.ly/1XV1tG4 URL이 포함된 포스트와 매칭됩니다. 2012년 3월에 확장 URL 보강이 도입되었습니다. 이 시점 이전에는 게시물 페이로드에 사용자 제공 URL만 포함되었습니다. 따라서 사용자가 단축 URL을 포함한 경우, 관심 있는 (확장된) URL에 대해 매칭하기가 어려울 수 있습니다. Historical PowerTrack과 Search API들에서는 2012년 3월부터 이러한 메타데이터를 사용할 수 있습니다. 2016년 7월에는 향상된 URL 보강이 도입되었습니다. 이 향상된 버전은 웹사이트의 HTML 제목과 설명을 게시물 페이로드에 함께 제공하며, 이에 대해 매칭할 수 있는 연산자도 제공합니다. Historical PowerTrack에서는 이러한 메타데이터가 2016년 7월부터 제공됩니다. Search API들에서는 2014년 12월부터 이러한 메타데이터가 나타나기 시작합니다. 2016년 9월 X는 ‘네이티브 첨부’ 기능을 도입하여, 뒤에 오는 공유 링크가 게시물의 140자 제한에 포함되지 않도록 했습니다. 두 가지 URL 보강은 이러한 공유 링크에도 계속 적용됩니다. URL 필터링에 대한 URL 관련 제품별 기타 세부 정보는 관련 문서를 참고하십시오.