以下の比較ガイドも参照してください:
X API: エンタープライズ データディクショナリ
はじめに
Enterprise
投稿は、X に関するあらゆるものの最小単位となる基本的な構成要素です。投稿を返すすべての X API は、そのデータを JavaScript Object Notation (JSON) を用いてエンコードして提供します。JSON は、名前付き属性とそれに関連付けられた値からなるキーと値のペアに基づいています。API から取得されるポストオブジェクトには X ユーザーの「ステータス更新」が含まれますが、リツイート、返信、引用ツイートもすべてポストオブジェクトです。あるポストが別のポストとリツイート、返信、引用ツイートとして関連している場合、それぞれはポストオブジェクト内で識別されるか、埋め込まれます。X ネイティブのデータ形式における最も単純なポストであっても、投稿者、メンションされたユーザー、タグ付けされた場所情報、ハッシュタグ、キャッシュタグ記号、メディア、URL リンクなど、ポストの他の属性を表現するために入れ子になった JSON オブジェクトを持ちます。X データを扱う際には、これは理解しておくべき重要な概念です。X API から受け取るポストデータの形式は、受信するポストの種類、利用している X API、およびフォーマット設定によって異なります。
ポストオブジェクトを返す Enterprise エンドポイントは、ポストの編集履歴を理解するために必要なメタデータを提供するよう更新されています。これらのメタデータの詳細については、“ポストの編集」の基本 ページを参照してください。
ネイティブな X フォーマットでは、JSON ペイロードには「ルートレベル」の属性や、
{} 記法で表されるネストされた JSON オブジェクトが含まれます:
利用可能なデータ形式
ご注意:エンタープライズデータ API では、Enriched Native 形式の利用を強く推奨します。エンタープライズデータ API は 2 種類の形式でデータを提供します。エンタープライズ形式のうち、標準 v1.1 のネイティブ形式に最も近いのが Enriched Native です。レガシーのエンタープライズデータ形式が Activity Streams で、当時 X および他のソーシャルメディアデータプロバイダー全体で正規化された形式として、もともと Gnip によって実装・利用されていました。この形式は現在も利用可能ですが、X は 2017 年以降、新機能や開発投資を Enriched Native 形式のみに行ってきました。 Enriched Native 形式は名前のとおり、ネイティブな X オブジェクトに加えて、URL アンワインドのメタデータ、profile geo、poll metadata、追加のエンゲージメントメトリクスなど、エンタープライズデータ製品で利用可能な追加エンリッチメントを含みます。
- Enriched Native 形式には、poll metadata など 2017 年以降に追加されたすべての新しいメタデータや、reply_count・quote_count などの追加メトリクスが含まれます。
- Activity Streams 形式は、2017 年の character update 以降、新しいメタデータやエンリッチメントは追加されていません。
- Expanded and enhanced URLs enrichment
- Matching rules enrichment
- Poll metadata enrichment
- Profile geo enrichment
データ形式ごとのオブジェクト比較
パースに関するベストプラクティス
- X の JSON は UTF-8 文字でエンコードされています。
- パーサーはフィールドの並び順の違いを柔軟に扱えるようにすべきです。ポストの JSON は順序を持たないハッシュデータとして提供されると想定してください。
- パーサーは「新しい」フィールドが追加されても問題なく処理できるべきです。
- JSON パーサーは「欠落している」フィールドに対しても寛容でなければなりません。すべてのコンテキストで、すべてのフィールドが必ずしも出現するとは限らないためです。
- null が設定されたフィールド、空の集合、フィールドが存在しない状態は、一般的には同一のものとみなして問題ありません。
Enterprise Native Enriched データオブジェクト
Native Enriched ツイートオブジェクト
Native Enriched データ形式が X API v2 形式にどのようにマッピングされるか、さらに詳しく知りたい方は、 比較ガイドをご覧ください: Native Enriched と X API v2 の比較
ポストオブジェクト
id、created_at、text などの基本的な属性を含む、多数の「ルートレベル」属性があります。ポストオブジェクトには、user、entities、extended_entities といった情報を保持するネストされたオブジェクトも含まれます。ポストオブジェクトには、retweeted_status、quoted_status、extended_tweet など、その他のネストされたポストオブジェクト も含まれます。さらに、ネイティブエンリッチ形式には matching_rules オブジェクトが追加されます。
X データディクショナリ
追加のポスト属性
非推奨属性
ネストされたポストオブジェクト
引用ツイート
Extended Posts
ネイティブ Enriched User オブジェクト
ユーザーデータ辞書
サポート終了 (非推奨) の属性
ユーザーオブジェクトの例:
ネイティブ拡張ジオオブジェクト
place オブジェクトは、ポストが Place でジオタグ付けされている場合には必ず存在します。Place は、対応する地理座標を持つ、特定の名前付き位置情報です。ユーザーが自分のポストに位置情報を割り当てることを選択すると、候補となる X Place のリストが提示されます。API を使用して投稿する場合は、投稿時に place_id を指定することで X Place を添付できます。Place に関連付けられたポストは、必ずしもその場所から発信されているとは限らず、その場所「について」のポストである可能性もあります。
geo および coordinates オブジェクトは、ポストに 正確な位置 が割り当てられている場合にのみ (null ではなく) 存在します。正確な位置が指定されている場合、coordinates オブジェクトはその地理座標を表す [long, lat] 配列を提供し、その位置に対応する X Place が割り当てられます。
Place データディクショナリ
Geo オブジェクト データディクショナリ
Coordinates オブジェクト データディクショナリ
導出された位置情報
使用例
X エンティティ
はじめに
entities は、X 上にポストされたコンテンツに関するメタデータおよび追加的なコンテキスト情報を提供します。entities セクションには、ポストに含まれる一般的な要素の配列が含まれます。具体的には、ハッシュタグ、ユーザーへのメンション、リンク、株式ティッカー (symbols) 、X の投票、添付メディアなどです。これらの配列によって、X がテキスト本文を実質的にあらかじめ前処理 (パース) しているため、開発者が投稿を取り込む際に便利です。ポスト本文の中からこれらの entity を明示的に検索・抽出する必要はなく、パーサーはこの JSON セクションを直接参照するだけで済みます。
パースを容易にするだけでなく、entities セクションは有用な「付加価値」のあるメタデータも提供します。たとえば、Enhanced URLs enrichment を使用している場合、URL メタデータには完全に展開された URL に加えて、関連するウェブサイトのタイトルや説明が含まれます。別の例として、ユーザーへのメンションがある場合、entities メタデータには数値のユーザー ID が含まれており、多くの X API にリクエストを送信する際に役立ちます。
すべてのポストの JSON ペイロードには entities セクションが含まれており、hashtags、urls、user_mentions、symbols 属性の最小セットが、これらの entity がポストメッセージの一部でない場合でも必ず存在します。たとえば、本文が「Hello World!」でメディアが添付されていないポストの JSON を確認すると、entity 配列に要素が 0 件の状態で、次のような内容が含まれていることが分かります。
- media と polls エンティティは、その種類のコンテンツがポストに含まれている場合にのみ返されます。
- ネイティブメディア (写真、動画、GIF) を扱う場合は、Extended Entities object を使用することを推奨します。
Entities オブジェクト
entities と extended_entities セクションはどちらも、エンティティ オブジェクト の配列で構成されています。以下では、これらそれぞれのエンティティ オブジェクトについて説明し、オブジェクトの属性名、type、簡潔な説明を示したデータディクショナリを記載しています。また、どの PowerTrack オペレーターがこれらの属性にマッチするかを示し、JSON ペイロードのサンプルも含めます。
投稿内で一般的に見られるエンティティ (ハッシュタグ、リンク、ユーザーへの言及など) の集合です。この entities オブジェクトには media 属性も含まれていますが、entiites セクションでの実装が完全に正確なのは、写真が 1 枚だけの投稿に対してのみです。複数の写真、動画、またはアニメーション GIF を含むすべての投稿については、extended_entities セクションを参照してください。
Entities データディクショナリ
entities オブジェクトは、ほかのエンティティのサブオブジェクト配列を保持するコンテナです。entities の構造を示したあとで、これらのサブオブジェクト向けのデータディクショナリと、それらにマッチする Operators を提示します。
Hashtag object
entities セクションには、ポスト本文に含まれる各ハッシュタグごとに 1 つのオブジェクトを要素とする hashtags 配列が含まれ、ハッシュタグが存在しない場合は空配列が含まれます。
PowerTrack の # 演算子は、text 属性に対するマッチングに使用されます。has:hashtags 演算子は、配列に 1 つ以上の要素が存在する場合にマッチします。
Media object
entities セクションには、ポストに何らかのメディアオブジェクトが「添付」されている場合、1 つのメディアオブジェクトを格納した media 配列が含まれます。ネイティブメディアが添付されていない場合、entities 内に media 配列は存在しません。次の理由から、ポストのネイティブメディアを処理する際は extended_entities セクションを使用する必要があります。
- メディアの
typeは、動画や GIF がポストに添付されている場合でも常に「photo」を示します。 - 最大 4 枚の写真を添付できますが、
entitiesセクションには最初の 1 枚しか一覧表示されません。
has:media オペレーターは、この配列に要素が含まれている場合に一致します。
メディアサイズオブジェクト
Sizes object
Size オブジェクト
写真メディア URL のフォーマット
media_url または media_url_https 単体でも読み込むことができ、その場合はデフォルトで medium バリアントが読み込まれます。ただし、可能な場合は、完全にフォーマットされた写真メディア URL を指定することを推奨します。
写真メディア URL は次の 3 つの要素で構成されます。
これら 3 つの要素 (Base URL、Format、Name) を組み合わせて、読み込む写真メディア URL を構成します。この方法で画像を読み込むフォーマットには、legacy と modern の 2 種類があります。すべての画像読み込みは legacy フォーマットの使用をやめ、modern フォーマットを使用する必要があります。modern フォーマットを使用すると呼び出し側の CDN ヒット率が向上し、その結果として、データセンターでメディアを生成して読み込む必要が生じにくくなり、読み込みレイテンシが改善されます。
URL オブジェクト
entities セクションには、ポスト本文内に含まれるすべてのリンクごとに 1 つのオブジェクトを要素として持つ urls 配列が含まれ、リンクが存在しない場合は空の配列になります。
has:links 演算子は、配列に少なくとも 1 つ要素がある場合にマッチします。url: 演算子は expanded_url 属性にマッチするために使用されます。Expanded URL enrichment を使用している場合、url: 演算子は unwound.url (完全に展開された URL) 属性にマッチするために使用されます。Exhanced URL enrichment を使用している場合、url_title: および url_decription: 演算子は、それぞれ unwound.title と unwound.description 属性にマッチするために使用されます。
Expanded および/または Enhanced URL エンリッチメントを使用している場合、次のメタデータが
unwound 属性の下に含まれます:
ユーザー言及オブジェクト
entities セクションには、ポスト本文に含まれるユーザー言及ごとに 1 つのオブジェクトを要素とする user_mentions 配列が含まれます。ユーザー言及が存在しない場合は、空の配列になります。
PowerTrack の @ 演算子は、screen_name 属性にマッチさせるために使用されます。has:mentions 演算子は、その配列に少なくとも 1 件の要素がある場合にマッチします。
Symbol オブジェクト
entities セクションには、ポスト本文に含まれる各 $cashtag ごとに 1 つのオブジェクトを格納した symbols 配列が含まれ、シンボルが存在しない場合は空の配列が含まれます。
PowerTrack の $ 演算子は text 属性に対してマッチさせるために使用されます。has:symbols 演算子は、配列内に 1 件以上の要素がある場合にマッチします。
投票オブジェクト
entities セクションには、ポストに投票が含まれている場合、単一の poll オブジェクトを要素とする polls 配列が含まれます。投票が含まれていない場合、entities セクション内に polls 配列は存在しません。
これらの投票メタデータは、次の Enterprise API でのみ利用可能である点に注意してください。
- ボリュームストリーム (Decahose)
- Real-time PowerTrack
- X Search APIs (Full-Archive Search と 30-Day Search)
Retweet と Quote Tweet の詳細
リツイート
text 属性は、元のポストのテキストの先頭に「RT @username: 」を付与して構成されます。
場合によっては、特にユーザー名が長いアカウントでは、これら新しい文字と元のポスト本文を組み合わせることで、元のポストのテキスト長制限である 140 文字を簡単に超えてしまうことがあります。140 文字ベースの表示および保存のサポートを維持するために、トップレベルの本文はポスト本文の末尾を切り詰め、省略記号 (「…」) を追加します。その結果、元のポスト末尾に位置していた一部のトップレベルの 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 も一部が切り詰められたため、これらはトップレベルの entities から欠落しています。また、text フィールドの先頭に付与される「RT @floodsocial: 」プレフィックスにより、追加の user_mentions トップレベル entity が存在することにも気付くでしょう。
しかし、retweeted_status 内のポストテキストと entities は、切り詰めや誤った entities なしに元のポストを完全に反映しています。そのため、リツイートについては、ネストされた retweeted_status オブジェクト に依存することを推奨します。
引用ツイート
引用ツイートは 2016 年に導入されました。リツイートと異なり、ポストを「引用」すると、共有されたポストに対して、その「上に」新しいコンテンツを追加する形になります。この新しいコンテンツには、新しいテキスト、ハッシュタグ、メンション、URL など、元のポストが持ちうるほとんどすべての要素を含めることができます。 引用ツイートにはネイティブメディア (写真、動画、GIF) を含めることができ、その情報はentities オブジェクトの下に現れます。
X の entities は追加できるため、引用部分の entities は元の entities とは異なることがよくあります。
次の例では、新しい URL とハッシュタグが引用ツイートの末尾に配置されています。
このポスト 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 は、切り捨てや誤った entities もなく、引用ツイートを完全に反映しています。そのため、引用ツイートでは、ネストされた _extended_tweet_ オブジェクトに依拠することを推奨します。
user オブジェクトの Entities
JSON のサンプル
X 拡張エンティティ
はじめに
extended_entities セクションも含まれます。ネイティブメディア (写真、動画、GIF) を扱う場合、いくつかの理由から extended_entities が推奨されるメタデータソースとなります。現在、1つのポストには最大4枚の写真を添付できます。entities メタデータには最初の1枚の写真しか含まれません (2014年までは1枚のみ添付可能でした) が、extended_entities セクションには添付されたすべての写真が含まれます。ネイティブメディアに関しては、entities.media メタデータには別の制約があり、添付されたメディアが動画やアニメーションGIFである場合でも、メディアの種別が常に「photo」となってしまう点があります。実際のメディア種別は extended_entities.media[].type 属性で指定され、photo、video、または animated_gif のいずれかが設定されます。これらの理由から、ネイティブメディアを扱う場合は extended_entities メタデータを利用することを推奨します。
写真、動画、アニメーションGIFが添付されているすべてのポストには、extended_entities JSON オブジェクトが含まれます。extended_entities オブジェクトには、media オブジェクトからなる単一の media 配列が含まれます (データディクショナリについては entities セクションを参照してください) 。ハッシュタグやリンクなど、その他のエンティティタイプは extended_entities セクションには含まれません。extended_entities セクション内の media オブジェクトは、entities セクションに含まれるものと構造的に同一です。
ポストには1種類のメディアのみ添付できます。写真については最大4枚まで添付できます。動画およびGIFについては1つのみ添付できます。extended_entities セクション内のメディア type メタデータはメディア種別 (「photo」「video」「animated_gif」) を正しく示し、最大4枚の写真をサポートするため、ネイティブメディア向けの推奨メタデータソースとなっています。
投稿例とJSONペイロード
entities メタデータを示します。
4枚のネイティブ写真を含むポスト
ハッシュタグ、ユーザー名のメンション、キャッシュタグ、URL、および4枚のネイティブ写真を含むポスト:
このポストの
entities セクションは以下のとおりです:
extented_entities セクションは次のとおりです。
ネイティブ動画付きポスト
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 を含むすべてのネイティブメディア type には、extended_entities セクションを使用することを推奨します。
アニメーション GIF を含むポスト
以下は、このアニメーション GIF を含むポストの extended entities メタデータです。
ネイティブエンリッチされたペイロード例
ポスト
返信ポスト
拡張ポスト
extended_entitites を含むポスト
リツイート
引用ツイート
引用ツイートのリツイート
Enterprise Activity Streams データオブジェクト
Activity Streams データ形式が X API v2 の形式にどのようにマッピングされるのか、詳しく知りたい方は次をご覧ください。
注意: エンタープライズ向けデータ API には、Enriched Native 形式の利用を強く推奨します。
- Enriched Native 形式には、poll metadata など、2017 年以降に追加されたすべての新しいメタデータや、reply_count や quote_count などの追加メトリクスが含まれます。
- Activity Streams 形式は、2017 年の character update 以降、新しいメタデータやエンリッチメントで更新されていません。
Activity Object
twitter_quoted_status、long_object を含む、その他のネストされたポストの activity オブジェクトを持たせることができます。
ベースレベルのオブジェクト type である “activity” は、ネイティブ enriched 形式のポストのベースレベルオブジェクトに似ています。Activity Streams 形式のペイロード例はこちらで確認できます。
データディクショナリ
追加のポスト属性
非推奨属性
ネストされたポストアクティビティオブジェクト
{ "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": {} } }
リツイートされた引用ツイート:
Long オブジェクト
Actor オブジェクト
データディクショナリ
サポート終了 (非推奨) の属性
例
Location Object
Location データディクショナリ
profileLocations から派生したオブジェクト
例
X entities オブジェクト
例:
X 拡張エンティティオブジェクト
twitter_extended_entities は、ネイティブ拡張 (enriched) フォーマットで示されている extended_entities オブジェクト と同じ形式とデータディクショナリです。
例:
Gnip オブジェクト
gnip オブジェクトには、アクティブなエンリッチメントによって追加されたメタデータと、そのアクティビティがどのルールにマッチしたかを示す情報が含まれます。
データディクショナリ
例:
アクティビティストリームのペイロード例
twitter_extended_entities を含むポストのアクティビティ
ツイートメタデータタイムライン
はじめに**
X は本質的に、公開され、リアルタイムで、グローバルなコミュニケーションネットワークです。2006 年以降、X の進化は、ユーザーの利用パターンや慣習に加え、新しいプロダクト機能や機能拡張によって推進されてきました。X データを歴史研究に活用する場合、この進化のタイムラインを理解することは、データアーカイブから関心のある投稿を見つけ出すうえで重要です。 X はシンプルな SMS モバイル App としてローンチされ、その後、包括的なコミュニケーションプラットフォームへと成長しました。完全な API 群を備えたプラットフォームです。API は常に X ネットワークの柱でした。最初の API は、X のローンチ直後に公開されました。2009 年にポストのジオタグ機能が初めて導入された際には、その機能は Geo API を通じて提供されました (その後、「ジオタグ」をポストに付与する機能は X.com のユーザーインターフェースに統合されました) 。現在、X の API は双方向のコミュニケーションネットワークを支えており、このネットワークは速報ニュースや情報共有のソースとなっています。このグローバルでリアルタイムなコミュニケーションチャネルの上に構築できる機会は無限にあります。 X では、すべての公開ポストにアクセスできる 2 つの歴史データ向け API を提供しています。Historical PowerTrack と Full-Archive Search API です。どちらの API も、関心のある投稿をクエリして収集するための一連の オペレーター を提供します。これらのオペレーターは、各ポストに関連付けられたさまざまな属性、たとえばポストのテキストコンテンツ、投稿者のアカウント名、ポスト内で共有されているリンクなど、数百におよぶ属性にマッチします。ポストおよびその属性は、テキストベースの一般的なデータ交換フォーマットである JSON でエンコードされています。そのため、新機能が導入されると新しい JSON 属性が追加されることが多く、通常はその属性にマッチする新しい API オペレーターも追加されてきました。ユースケースに、世界中の人々が X 上で「何を言ってきたか」に 耳を傾ける 必要が含まれる場合、各オペレーターに対応する JSON メタデータがいつから存在しているのかをよく理解しているほど、Historical PowerTrack フィルターをより効果的に構築できます。 次に、ポストのメタデータの更新が、関心のあるデータシグナルの発見にどのような影響を与えるかを理解する前提となる、いくつかの主要な概念を紹介します。重要な概念**
ユーザー主導の慣習から X の_第一級オブジェクト_へ
ポストのメタデータ、可変性、更新、最新性
「ネイティブ」メディア
has:videos、has:images、has:media などがあります。これらは、X の機能を通じて共有されたメディアコンテンツにのみマッチします。X プラットフォーム外でホストされているその他のメディアにマッチさせるには、URL メタデータに対してマッチする演算子を使用する必要があります。
Historical PowerTrack と Full-Archive Search の製品詳細に入る前に、プロダクトおよびプラットフォームとしての X が時間の経過とともにどのように進化してきたかを見ていきましょう。
X のタイムライン
以下に、X に関する タイムライン の一部を示します。これらの X のアップデートのほとんどは、ユーザー行動、ポストの JSON コンテンツ、クエリ演算子、あるいはそのすべてに、何らかの形で根本的な影響を与えました。X を API プラットフォームとして見ると、これらのイベントは、ポストをエンコードするために使用される JSON ペイロードに何らかの形で影響してきました。その結果、その JSON の詳細が、X の履歴 API がそれらにどのようにマッチするかにも影響します。
このタイムライン一覧は、概ね正確ではありますが、網羅的ではない点に注意してください。
2006
- 10月
- @replies が慣習として使われるようになる。
- Cashtags は 2012 年 6 月にクリック可能/検索可能なリンクになった。
- 11月 - 「お気に入り」 (Favorites) 機能が導入される。
2007
- 1月 - @replies が
in_reply_toメタデータを持つ UI の返信ボタンを備えた第一級のオブジェクトとなる。 - 4月 - リツイートが慣習として広く用いられるようになる。
- 8月 - #ハッシュタグが投稿を検索・整理するための主要な手段として使われ始める。
2009
- 2月 - 株式ティッカーシンボルを議論する際の一般的な表記法として、$cashtags の利用が一般化する。
- 5月 - Post 本文の先頭に「Via @」を付加する Retweet の「ベータ版」が導入される。
- 6月 - 認証済みアカウントが導入される。
- 8月 - 「RT @」パターンと新しい
retweet_statusメタデータを伴い、Retweet がファーストクラスのオブジェクトとして扱われるようになる。 - 10月 - リスト機能が公開される。
- 11月 - Post Geotagging API が公開され、サードパーティ製 App を通じてユーザーが位置情報を共有できる最初の方法が提供される。
2010
- 6月 - 投稿にジオタグを付けるための X Places を導入。
- 8月 - ウェブサイト向けの Post ボタンをリリース。リンク共有が容易になった。
2011
- 5月 - Followボタンが導入され、ウェブサイトと関連付けられたアカウントをより簡単にフォローできるようになりました。
- 8月 - ネイティブな写真投稿機能が導入されました。
2012
- 6月 - $Cashtags がクリックおよび検索可能なリンクになる。
2014
- 3月 - 写真へのタグ付けと最大4枚までの写真に対応。拡張版 X Entities メタデータが導入されました。
- 4月 - 絵文字が X の UI でネイティブにサポートされました。絵文字は少なくとも 2008 年以降、投稿で一般的に使用されていました。
2015
- 4月 - X の「ポスト」ユーザーインターフェースデザインの変更により、位置情報付きの投稿数が減少。
- 10月 - X Polls introduced。Polls は当初、24時間の投票期間で 2 つの選択肢に対応していた。11月には、投票期間 5 分〜7 日で 4 つの選択肢に対応するようになった。Poll メタデータは、2017 年 2 月に利用可能になった (拡張ネイティブ形式のみ) 。
2016
- 2月 - ポスト作成画面でネイティブにホストされたGIFを検索して利用できる機能。
- 5月 - 「140文字でもっとできること」 (dmw140) を発表し、ポストの140文字メッセージに関して、リプライや添付メディアを扱う新しい方法を導入する計画を明らかにしました。
- 6月 - ネイティブ動画サポート。
- 6月 - 引用リツイートが一般提供開始。
- 6月 - 写真に追加するためのステッカーを導入。
- 9月 - 「ネイティブアタッチメント」を導入。末尾のURLが140文字数にカウントされないようにするもの (「dmw140 パート1」) 。
2017
- 2月 - X Poll メタデータがポストのメタデータに含まれるようになる (拡張ネイティブ形式のみ) 。
- 4月 - 「Simplified Replies」 が導入され、返信先アカウントが 140 文字数にカウントされなくなる (「dmw140, part 2」) 。
- 5月 - GDPR 更新 により、user.time_zone が null に設定され、user.utc_offset が null に設定され、user.profile_background_image_url がデフォルト値に設定される
- 6月 - quoteTweet のフォーマット変更
- 9月29日 - 投稿の編集機能が一部のテストグループにロールアウトされる。編集されたポストのメタデータが、該当する場合はポストオブジェクトに追加される。これには edit_history オブジェクトおよび edit_controls オブジェクトが含まれる。これらのメタデータは、編集可能機能が追加される前に作成された投稿については返されない。これらのメタデータに関連する Operator は存在しない。ポストの編集がどのように機能するかの詳細については、Edit Posts fundamentals を参照。
lang: Operator があります。X は言語分類サービス (50 を超える言語に対応) を提供しており、X API は各ポストに対して生成される JSON 内でこのメタデータを提供します。たとえば、あるポストがスペイン語で書かれている場合、その JSON 属性「lang」は「es」に設定されます。このため、lang:es という句を含むフィルターを作成すると、スペイン語として分類された投稿メッセージのみにマッチします。
タイムライン情報は、受信した投稿データをより適切に解釈するうえでも役立ちます。たとえば、2008 年と 2012 年の夏季オリンピックに関するコンテンツの共有を調査しているとします。is:retweet Operator だけを適用してリツイートにマッチさせた場合、2008 年にはデータは 1 件もマッチしません。しかし、2012 年については、おそらく数百万件のリツイートが存在するでしょう。このことから誤って、2008 年にはリツイートがユーザーの慣行ではなかった、もしくは単に誰もそのオリンピックについてリツイートしなかった、と結論づけてしまう可能性があります。リツイートは 2009 年にファーストクラスのオブジェクトになったため、2008 年のリツイートを特定するには ”RT @” というルール句を追加する必要があります。
リツイートと言語分類はいずれも、長い歴史と多くのプロダクト上の詳細を持つ投稿属性の例です。以下では、X データのマッチングと理解に重要な、これらおよびその他の属性クラスについて、さらに詳しく説明します。
偽陰性を見分ける
has:videos Operator を使ってルールを作成しても、その条件は 2015 年以前の投稿にはマッチしません。
しかし、X では 2015 年よりずっと前から、動画の共有は一般的に行われていました。当時は、ユーザーは他の場所にホストされている動画へのリンクを共有していましたが、2015 年に X はプラットフォームに新しい「動画共有」機能を直接実装しました。こうしたそれ以前の対象ポストを見つけるには、url:”youtube.com” のようなルール句を追加します。
なお、Search API では、インデックスの再構築時にメタデータが「バックフィル」される例もあります。よい例としては、株式銘柄を議論する際に 2009 年に広く使われるようになった cashtag オペレーターが導入された後、Search インデックスが再構築され、その過程でシンボルエンティティが、2006 年初期を含むすべてのポスト本文から抽出されました。当時は $ は主にスラングとして使われており、「I hope it $oon!」のような使われ方をしていました。
ユースケースにとって重要なポスト属性の特定とフィルタリング
X プロフィール
元のポストとリツイート
is:retweet 演算子を使うことで、リツイートを含めるか除外するかを制御できます。2009年8月より前のデータを取得する場合、ユーザーはリツイートにマッチさせる (あるいはマッチさせない) ための 2つ の戦略を持つ必要があります。2009年8月以前については、ポストメッセージ自体を、「@RT 」パターンに対して完全一致検索を行うことでチェックする必要があります。2009年8月以降の期間については、is:retweet 演算子が利用可能です。
ポストの言語分類
lang: 演算子はポストの全アーカイブに対して利用できます。一方、Historical PowerTrack では、X の言語分類メタデータは 2013 年 3 月 26 日以降のアーカイブで利用可能です。
投稿の位置参照
- ポスト本文中の地理的な参照情報
- ユーザーによって位置情報タグが付けられた投稿
- ユーザーがアカウントプロフィールで設定した「ホーム」ロケーション