Skip to main content
以下の比較ガイドも参照してください:

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 形式の利用を強く推奨します。 
  • Enriched Native 形式には、poll metadata など 2017 年以降に追加されたすべての新しいメタデータや、reply_count・quote_count などの追加メトリクスが含まれます。
  • Activity Streams 形式は、2017 年の character update 以降、新しいメタデータやエンリッチメントは追加されていません。
エンタープライズデータ API は 2 種類の形式でデータを提供します。エンタープライズ形式のうち、標準 v1.1 のネイティブ形式に最も近いのが Enriched Native です。レガシーのエンタープライズデータ形式が Activity Streams で、当時 X および他のソーシャルメディアデータプロバイダー全体で正規化された形式として、もともと Gnip によって実装・利用されていました。この形式は現在も利用可能ですが、X は 2017 年以降、新機能や開発投資を Enriched Native 形式のみに行ってきました。 Enriched Native 形式は名前のとおり、ネイティブな X オブジェクトに加えて、URL アンワインドのメタデータ、profile geo、poll metadata、追加のエンゲージメントメトリクスなど、エンタープライズデータ製品で利用可能な追加エンリッチメントを含みます。  

データ形式ごとのオブジェクト比較

どのような X のユースケースであっても、これらの JSON でエンコードされたポストオブジェクトと属性が何を_表しているか_を理解することは、関心のあるデータシグナルを見つけるうえで極めて重要です。その一助として、各データ形式内の各オブジェクトに特化したページ群が用意されています。 上記の JSON 階層を反映して、各オブジェクトへのリンクは次のとおりです。

パースに関するベストプラクティス

  • X の JSON は UTF-8 文字でエンコードされています。
  • パーサーはフィールドの並び順の違いを柔軟に扱えるようにすべきです。ポストの JSON は順序を持たないハッシュデータとして提供されると想定してください。
  • パーサーは「新しい」フィールドが追加されても問題なく処理できるべきです。
  • JSON パーサーは「欠落している」フィールドに対しても寛容でなければなりません。すべてのコンテキストで、すべてのフィールドが必ずしも出現するとは限らないためです。
  • null が設定されたフィールド、空の集合、フィールドが存在しない状態は、一般的には同一のものとみなして問題ありません。

Enterprise Native Enriched データオブジェクト

Native Enriched ツイートオブジェクト

Native Enriched データ形式が X API v2 形式にどのようにマッピングされるか、さらに詳しく知りたい方は、 比較ガイドをご覧ください: Native Enriched と X API v2 の比較

ポストオブジェクト

エンタープライズ向けデータ製品を利用する場合、データディクショナリの多くはポストデータのネイティブ形式とよく似ていますが、そこに追加のエンリッチされたメタデータが含まれます。ネイティブエンリッチ形式のベースレベルでは、X API v1.1 データ形式 と多くの同じオブジェクト名を共有しています。ポストオブジェクトには、idcreated_attext などの基本的な属性を含む、多数の「ルートレベル」属性があります。ポストオブジェクトには、userentitiesextended_entities といった情報を保持するネストされたオブジェクトも含まれます。ポストオブジェクトには、retweeted_status、quoted_status、extended_tweet など、その他のネストされたポストオブジェクト も含まれます。さらに、ネイティブエンリッチ形式には matching_rules オブジェクトが追加されます。
X データディクショナリ
以下に、これらの「ルートレベル」属性のデータディクショナリと、その子オブジェクトのデータディクショナリへのリンクを示します。
追加のポスト属性
ポストを返す X API (例: GET statuses/lookup エンドポイント) は、これらの追加のポスト属性を含む場合があります。
非推奨属性

ネストされたポストオブジェクト

いくつかのケースでは、ポストオブジェクトの中に、さらに別のオブジェクトがネストされていることがあります。ネストされたオブジェクトを扱う場合、その JSON ペイロードには複数のポストオブジェクトが含まれ、それぞれのポストオブジェクトが独自のオブジェクトを持つことがあります。ルートレベルのオブジェクトには、どの種類のアクションが行われたか、つまりリツイートなのか引用ツイートなのかといった情報が含まれ、共有されている「オリジナル」のポストを表すオブジェクトを含むこともあります。拡張ポストには、140 文字を超える拡張オブジェクトがネストされており、これは 2017 年のアップデート時に破壊的変更を避けるために使用されました。各ネストされたオブジェクトのディクショナリについて、以下で説明します。 リツイート リツイートには常に 2 つのポストオブジェクトが含まれます。リツイートされる「オリジナル」のポストは、“retweeted_status” オブジェクト内に含まれます。ルートレベルのオブジェクトはリツイート自体をカプセル化しており、リツイートアクションを行ったアカウントの User オブジェクトと、リツイート時刻を含みます。リツイートは、ポストをフォロワーと共有するためのアクションであり、新しいコンテンツを追加することはできません。また、リツイートに (新たな) 位置情報を付与することもできません。「オリジナル」のポストにジオタグが付与されている場合でも、リツイート側の “geo” および “place” オブジェクトは常に null になります。 拡張ポストの導入以前から、ルートレベルの “entities” オブジェクトは、場合によっては “RT @username ” という文字列がリツイートされるポストメッセージに付加されることにより、切り詰められて不完全になることがありました。また、あるリツイートがさらにリツイートされた場合でも、“retweet_status” はオリジナルのポストを指し続け、中間のリツイートは含まれないことに注意してください。x.com を使ってリツイートを「表示」する場合にも同様の挙動が見られます。リツイート「アクション」に割り当てられた一意の Post ID をコピーすると、オリジナルのポストが表示されます。  以下は、リツイートの構造例です。繰り返しになりますが、リツイートをパースする際には、完全な (オリジナルの) ポストメッセージとエンティティメタデータを取得するために “retweeted_status” オブジェクトをパースすることが重要です。
引用ツイート
引用ツイートはリツイートとよく似ていますが、新しいポストメッセージが含まれる点が異なります。これらの新しいメッセージには、独自のハッシュタグ、リンク、およびその他の “entities” メタデータを含めることができます。引用ツイートには、投稿したユーザーが共有した位置情報や、GIF、動画、写真などのメディアを含めることもできます。 引用ツイートには、少なくとも 2 つのポストオブジェクトが含まれ、多い場合は 3 つ含まれます。引用されているポスト (それ自体が引用ツイートである場合もあります) は、“quoted_status” オブジェクト内で提供されます。ルートレベルのオブジェクトは引用ツイート自体をカプセル化しており、共有アクションを行っているアカウントの User オブジェクトと、引用ツイートの時刻を含みます。 引用ツイートには、‘Post’ ユーザーインターフェースを使用して、写真、GIF、または動画を追加できるようになったことに注意してください。外部ホストのメディアへのリンクが引用ツイートメッセージに含まれている場合、それらはルートレベルの “entities.urls” で記述されます。引用ツイートに添付されたメディアは、ルートレベルの “extended_entities” メタデータに格納されます。 引用ツイートが最初に提供開始された際には、短縮リンク (t.co URL) が「元の」ポストメッセージの末尾に追加され、ルートレベルの “text” フィールドに含まれていました。さらに、その t.co URL のメタデータは、ルートレベルの ‘entities.urls’ 配列に含まれていました。2018 年 5 月に、これを変更し、引用されたツイートへの短縮 t.co URL はルートレベルの “text” フィールドには含まれないようにしました。次に、引用されたツイートのメタデータ も “entities.urls” メタデータには含まれないようにしました。その代わりに、引用されたツイートの URL メタデータは、ルートレベル (またはトップレベル) の新しい “quoted_status_permalink” オブジェクト内に配置され、“quoted_status” オブジェクトと同じ階層レベルになります。 以下に、この元のフォーマットを使用した引用ツイートの構造例を示します。
Extended Posts
Extended Posts を記述する JSON は、2017 年 11 月に 280 文字の投稿が導入された際に追加されました。投稿 JSON は、これらのより長いメッセージを扱えるように拡張されましたが、同時に、これらの基本的な X オブジェクトをパースしている既存の何千ものアプリケーションに影響を与えないよう配慮されています。完全な後方互換性を提供するために、元の 140 文字の ‘text’ フィールドと、そこからパースされる entities オブジェクトは保持されました。140 文字を超える投稿の場合、ルートレベルの ‘text’ フィールドは切り詰められ、不完全になります。ルートレベルの ‘entities’ オブジェクトには、含まれているハッシュタグやリンクなど、‘text’ メッセージからパースされた主要なメタデータの配列が含まれるため、これらの配列も不完全になります。例えば、投稿メッセージが 200 文字であり、その末尾にハッシュタグが含まれている場合、従来のルートレベルの ‘entities.hashtags’ 配列にはそれが含まれません。 より長い投稿メッセージと完全な entities メタデータを保持するために、新たに ‘extended_tweet’ フィールドが導入されました。“extended_tweet” オブジェクトは、140 文字を超える場合に完全で切り詰められていない投稿メッセージを含む “full_text” フィールドを提供します。“extended_tweet” オブジェクトには、ハッシュタグ、リンク、メンションなどの完全な配列を持つ “entities” オブジェクトも含まれます。 Extended Posts は、ルートレベルにある “truncated” ブール値で識別されます。true (“truncated”: true) の場合、ルートレベルのフィールドの代わりに “extended_tweet” のフィールドをパースする必要があります。 下の JSON 例では、ルートレベルの “text” フィールドが切り詰められており、投稿メッセージに 3 つのハッシュタグが含まれているにもかかわらず、ルートレベルの “entities.hashtags” 配列が空であることに注意してください。これは Extended Post であるため、“truncated” フィールドは true に設定されており、“extended_tweet” オブジェクトが完全な “full_text” と “entities” の投稿メタデータを提供します。

ネイティブ Enriched User オブジェクト

User オブジェクトには、参照されている X ユーザーについて記述する X ユーザーアカウントのメタデータが含まれます。 

ユーザーデータ辞書

サポート終了 (非推奨) の属性

ユーザーオブジェクトの例:

ネイティブ拡張ジオオブジェクト

投稿には位置情報を関連付けることができ、その結果「ジオタグ付き」のポストが生成されます。ポストの位置情報は、X のユーザーインターフェースを使用するか、API を使用してポストを投稿する際に割り当てることができます。ポストの位置情報は、正確な「ポイント」位置である場合も、会場から地域全体までの広い範囲を示す「バウンディングボックス」を持つ X Place である場合もあります。 ポストに関連付けられた位置情報を記述するために使用される「ルートレベル」の JSON オブジェクトは 3 種類あります: placegeo、および coordinates です。  さらに、ネイティブ拡張フォーマットには、ユーザーオブジェクト内に profile geo enrichmentderived location が含まれます。 place オブジェクトは、ポストが Place でジオタグ付けされている場合には必ず存在します。Place は、対応する地理座標を持つ、特定の名前付き位置情報です。ユーザーが自分のポストに位置情報を割り当てることを選択すると、候補となる X Place のリストが提示されます。API を使用して投稿する場合は、投稿時に place_id を指定することで X Place を添付できます。Place に関連付けられたポストは、必ずしもその場所から発信されているとは限らず、その場所「について」のポストである可能性もあります。 geo および coordinates オブジェクトは、ポストに 正確な位置 が割り当てられている場合にのみ (null ではなく) 存在します。正確な位置が指定されている場合、coordinates オブジェクトはその地理座標を表す [long, lat] 配列を提供し、その位置に対応する X Place が割り当てられます。

Place データディクショナリ

境界ボックス

Geo オブジェクト データディクショナリ

Coordinates オブジェクト データディクショナリ

導出された位置情報

使用例

データディクショナリ:エンタープライズ

X エンティティ

このページ内の項目 イントロダクション Entities オブジェクト   - Hashtag オブジェクト   - Media オブジェクト   - Media size オブジェクト   - URL オブジェクト   - User mention オブジェクト   - Symbol オブジェクト   - Poll オブジェクト リツイートと引用ツイートの詳細 ユーザーオブジェクト内の Entities ダイレクトメッセージ内の Entities 次のステップ

はじめに

entities は、X 上にポストされたコンテンツに関するメタデータおよび追加的なコンテキスト情報を提供します。entities セクションには、ポストに含まれる一般的な要素の配列が含まれます。具体的には、ハッシュタグ、ユーザーへのメンション、リンク、株式ティッカー (symbols) 、X の投票、添付メディアなどです。これらの配列によって、X がテキスト本文を実質的にあらかじめ前処理 (パース) しているため、開発者が投稿を取り込む際に便利です。ポスト本文の中からこれらの entity を明示的に検索・抽出する必要はなく、パーサーはこの JSON セクションを直接参照するだけで済みます。 パースを容易にするだけでなく、entities セクションは有用な「付加価値」のあるメタデータも提供します。たとえば、Enhanced URLs enrichment を使用している場合、URL メタデータには完全に展開された URL に加えて、関連するウェブサイトのタイトルや説明が含まれます。別の例として、ユーザーへのメンションがある場合、entities メタデータには数値のユーザー ID が含まれており、多くの X API にリクエストを送信する際に役立ちます。 すべてのポストの JSON ペイロードには entities セクションが含まれており、hashtagsurlsuser_mentionssymbols 属性の最小セットが、これらの entity がポストメッセージの一部でない場合でも必ず存在します。たとえば、本文が「Hello World!」でメディアが添付されていないポストの JSON を確認すると、entity 配列に要素が 0 件の状態で、次のような内容が含まれていることが分かります。
注意:
  • media と polls エンティティは、その種類のコンテンツがポストに含まれている場合にのみ返されます。
  • ネイティブメディア (写真、動画、GIF) を扱う場合は、Extended Entities object を使用することを推奨します。

Entities オブジェクト

entitiesextended_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 オペレーターは、この配列に要素が含まれている場合に一致します。

メディアサイズオブジェクト

ネイティブメディア (写真、動画、GIF) を含むすべての投稿には、高さと幅のピクセル数を持つ「thumb」「small」「medium」「large」のサイズのセットが含まれます。写真およびプレビュー画像のメディア URL については、写真メディア URL の書式設定 で、異なるサイズの写真メディアを読み込むための URL の構成方法を説明しています。

Sizes object

Size オブジェクト

写真メディア URL のフォーマット

X 上の写真メディアは、さまざまなサイズで読み込むことができます。特定の画像ビューポートを十分に満たす範囲で、できるだけ小さいサイズの画像を読み込むのが最適です。異なるサイズを読み込むには、Size Objectmedia_url (または media_url_https) を特定の形式で組み合わせる必要があります。ここでは、写真メディア URL を構築する例として、すでに示している media entity の例オブジェクトを使用します。 media_url または media_url_https 単体でも読み込むことができ、その場合はデフォルトで medium バリアントが読み込まれます。ただし、可能な場合は、完全にフォーマットされた写真メディア URL を指定することを推奨します。 写真メディア URL は次の 3 つの要素で構成されます。 これら 3 つの要素 (Base URL、Format、Name) を組み合わせて、読み込む写真メディア URL を構成します。この方法で画像を読み込むフォーマットには、legacymodern の 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.titleunwound.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 でのみ利用可能である点に注意してください。

Retweet と Quote Tweet の詳細

X API の観点では、Retweet と Quote Tweet は、元のポストを埋め込みオブジェクトとして含む、特殊な種類の投稿です。したがって Retweet と Quote Tweet オブジェクトは、子である ‘original’ ポストを持つ親となり (そのためサイズは 2 倍になります) 。Retweet にはトップレベルに “retweeted_status” オブジェクトがあり、Quoted Tweet には “quoted_status” オブジェクトがあります。整合性のため、これらトップレベルの Retweet および Quote Tweet オブジェクトにも text プロパティとそれに対応する entities が存在します。ただし、トップレベルの entities は、埋め込まれた ‘original’ 側の entities とは異なる場合があります。Retweet の場合、新しいテキストは元のポスト本文の前に付加されます。引用ポストの場合、新しいテキストはポスト本文の後ろに付加されます。 一般的には、retweeted_status が存在する場合は常に、元のポストから text、entities、元の投稿者、および日付を取得することがベストプラクティスです。例外は、追加された引用部分に含まれる X のエンティティを取得する場合です。詳細とヒントについては、以下を参照してください。

リツイート

リツイートに関する重要な点として、ポストには新たな X の entities を追加することができません。ユーザーはリツイート時にハッシュタグや URL、その他の詳細を追加できません。ただし、リツイート (トップレベル) の 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

User オブジェクトの Entities は、ユーザーが定義したプロフィールの URL および description フィールド内に含まれる URL を表します。これらは hashtags や user_mentions を表すものではありません。ポストの entities と異なり、user entities は親オブジェクト内の複数のフィールドに適用される可能性があります。その曖昧さを解消するために、どのフィールドにエンティティ化された URL が含まれているかを示す、url および description という親ノードが用意されています。 この例では、user の url フィールドには t.co リンクが含まれており、レスポンスの entities/url/urls[0] ノード内で完全に展開されています。ユーザーの description には、t.co でラップされた URL は含まれていません。

JSON のサンプル

X 拡張エンティティ

このページの内容 概要 Extended Entities オブジェクト ツイートと JSON ペイロードの例   - ネイティブ写真 4 枚を含むツイート   - ネイティブ動画を含むツイート   - アニメーション GIF を含むツイート 次のステップ

はじめに

あるポストにネイティブメディア (どこかへのリンクではなく、ポストのユーザーインターフェースを通じて共有されるメディア) が含まれている場合、extended_entities セクションも含まれます。ネイティブメディア (写真、動画、GIF) を扱う場合、いくつかの理由から extended_entities が推奨されるメタデータソースとなります。現在、1つのポストには最大4枚の写真を添付できます。entities メタデータには最初の1枚の写真しか含まれません (2014年までは1枚のみ添付可能でした) が、extended_entities セクションには添付されたすべての写真が含まれます。ネイティブメディアに関しては、entities.media メタデータには別の制約があり、添付されたメディアが動画やアニメーションGIFである場合でも、メディアの種別が常に「photo」となってしまう点があります。実際のメディア種別は extended_entities.media[].type 属性で指定され、photovideo、または 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 セクションは以下のとおりです:
以下の「extended」ペイロードにのみ、最大 4 枚のネイティブ写真が含まれます。配列内の先頭の写真が、拡張されていない X の entities セクションに含まれている単一の写真と同じであることに注意してください。写真に関する media メタデータ構造は、entities セクションと extended_entities セクションの両方で同じです。 このポストの extented_entities セクションは次のとおりです。

ネイティブ動画付きポスト

以下は、ネイティブ動画を含むこのポストの extended entities メタデータです。
広告主が動画の再生先をXが所有・運営するプラットフォームのみに制限することを選択した場合、video_info オブジェクトは additional_media_info オブジェクトに置き換えられます。 additional_media_info には、titledescriptionembeddable flag のような、パブリッシャーによって提供される追加のメディア情報が含まれます。embeddable=false の場合、動画コンテンツはX公式クライアントにのみ提供されます。この場合、ペイロード内で提供されるすべての動画URLはXに基づくものとなるため、ユーザーはリンクをクリックしてXが所有・運営するプロパティ上で動画を開くことができます。 このような状況で、extended entities オブジェクトがどのような形になるかの例を以下に示します。
前述のとおり、ここでは type が誤って「photo」に設定されている entities セクションを示しています。繰り返しになりますが、videoanimated_gif を含むすべてのネイティブメディア type には、extended_entities セクションを使用することを推奨します。

アニメーション GIF を含むポスト

以下は、このアニメーション GIF を含むポストの extended entities メタデータです。

ネイティブエンリッチされたペイロード例

ポスト

返信ポスト

拡張ポスト

extended_entitites を含むポスト

リツイート

引用ツイート

引用ツイートのリツイート

Enterprise Activity Streams データオブジェクト

Activity Streams データ形式が X API v2 の形式にどのようにマッピングされるのか、詳しく知りたい方は次をご覧ください。
比較ガイド: Activity Streams compared to X API v2
注意: エンタープライズ向けデータ API には、Enriched Native 形式の利用を強く推奨します。 
  • Enriched Native 形式には、poll metadata など、2017 年以降に追加されたすべての新しいメタデータや、reply_count や quote_count などの追加メトリクスが含まれます。
  • Activity Streams 形式は、2017 年の character update 以降、新しいメタデータやエンリッチメントで更新されていません。

Activity Object

Activity Streams は、Gnip が作成した X の元のデータ形式のオブジェクトスキーマ版であり、サードパーティの Activity Base Schema (詳細はこちら) を用いて、ポストデータおよびその他のソーシャルメディアデータの「形式を正規化」するためのものです。投稿は Activity Streams スキーマに正規化され、note、person、place、service の各オブジェクト type がネストされたオブジェクトとして含まれます。ポストには、リツイートや twitter_quoted_statuslong_object を含む、その他のネストされたポストの activity オブジェクトを持たせることができます。 ベースレベルのオブジェクト type である “activity” は、ネイティブ enriched 形式のポストのベースレベルオブジェクトに似ています。Activity Streams 形式のペイロード例はこちらで確認できます。

データディクショナリ

以下では、これらの「ルートレベル」の「activity」属性に対するデータディクショナリと、その子オブジェクトのデータディクショナリへのリンクを示します。

追加のポスト属性

非推奨属性

ネストされたポストアクティビティオブジェクト

いくつかのケースでは、ポストオブジェクトの中に他のポストがネストされることがあります。ネストされたオブジェクトを扱う場合、その JSON ペイロードには複数のオブジェクトが含まれ、各ポストオブジェクトがそれぞれ独自のオブジェクトを含んでいる場合があります。ルートレベルのオブジェクトには、どの種類のアクションが行われたか、つまりリツイートか引用ツイートかといった情報が含まれ、さらに共有されている「オリジナル」のポストを表すオブジェクトが含まれることもあります。拡張ポストには、2017 年の更新時に破壊的変更を防ぐ目的で導入された、140 文字を超える内容を保持するネストされた拡張オブジェクトが含まれます。各ネストされたオブジェクトディクショナリについては、以下で説明します。 Retweets リツイートの Activity Streams 形式では、リツイートされているオリジナルのポストを表現するために、type “activity” と verb “note” を持つネストされたオブジェクトが含まれます。
X 引用ステータス 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 オブジェクト

extended_tweet の Activity Streams 形式

Actor オブジェクト

Actor オブジェクトには、そのアクティビティを作成した X ユーザーについての X ユーザーアカウントメタデータが含まれます。

データディクショナリ

サポート終了 (非推奨) の属性

Location Object

Location オブジェクトは、X アカウントレベルで設定される actor オブジェクト内、または gnip object の profileLocations オブジェクト内に存在する場合があります。Location オブジェクトの type は place オブジェクトであり、name、address、geo coordinates (地理座標) を持つことができます。Location オブジェクトは、ネイティブ拡張フォーマットの Geo に類似しています。

Location データディクショナリ

profileLocations から派生したオブジェクト

X entities オブジェクト

Activity Streams フォーマットの場合、twitter_entities は、ネイティブ拡張フォーマットの entities オブジェクト で示されているものと同じフォーマットおよびデータディクショナリです。

例:

X 拡張エンティティオブジェクト

Activity Streams フォーマットの場合、twitter_extended_entities は、ネイティブ拡張 (enriched) フォーマットで示されている extended_entities オブジェクト と同じ形式とデータディクショナリです。

例:

Gnip オブジェクト

Activity Streams フォーマット内の gnip オブジェクトには、アクティブなエンリッチメントによって追加されたメタデータと、そのアクティビティがどのルールにマッチしたかを示す情報が含まれます。

データディクショナリ

例:

アクティビティストリームのペイロード例

ポストのアクティビティ
返信ポストのアクティビティ
long_object を含むポストのアクティビティ
twitter_extended_entities を含むポストのアクティビティ
リツイートアクティビティ
引用ツイートアクティビティ
引用ツイートのリツイートアクティビティ

ツイートメタデータタイムライン

このページ内の目次 概要 重要な概念 X タイムライン フィルタリングのヒント 次のステップ

はじめに**

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 の_第一級オブジェクト_へ

X のユーザーは、自然発生的に新しい、そして現在では不可欠となっているコミュニケーションパターンを X ネットワークにもたらしてきました。その代表例がハッシュタグで、今ではほぼすべてのソーシャルネットワークで使われています。ハッシュタグは、会話やトピックを整理するための手段として導入されました。1 日に何億件ものメッセージが流れるネットワークでは、関心のある投稿を見つけるためのツールが重要であり、その中心的な方法の 1 つがハッシュタグになりました。ハッシュタグの利用が広がると間もなく、X によって公式なステータスとサポートが与えられました。ハッシュタグが_「第一級」のオブジェクト_になったことで、多くの変化が生まれました。ハッシュタグは X.com のユーザーインターフェース上でクリック可能/検索可能になり、@mentions、添付メディア、株式シンボル、共有リンクと並んで X の entities ファミリーの一員にもなりました。これらのエンティティは、あらかじめパース済みの JSON 配列として便利にエンコードされており、開発者がそれらを処理・スキャン・保存しやすくなっています。 Retweet も、ユーザー主導の慣習が公式オブジェクトになった例です。Retweet は、コンテンツを他者に「転送」する方法として登場しました。これは、ポストをコピー&ペーストし、その先頭に「RT @」というパターンを付ける手動のプロセスとして始まりました。このプロセスは、専用の Retweet ボタンと新しい JSON メタデータによって自動化されました。こうして「公式の」Retweet が誕生しました。その他の例としては、「メンション」、メディアやウェブリンクの共有、ポストと一緒に位置情報を共有することなどがあります。これらそれぞれの利用パターンによって、新たな x.com のユーザーインターフェース機能、新たな補助 JSON が生まれ、その結果、投稿をマッチングする新たな方法が生まれました。これらすべての基本的なポストの属性は、それらにマッチさせるために使用される PowerTrack オペレーターとして実装されています。

ポストのメタデータ、可変性、更新、最新性

ポストの本文には最大文字数の制限がありますが、ポストを表現する JSON には 100 を超える属性が含まれます。誰がいつポストしたか、それがオリジナルのポストなのかリポストなのかといった属性に加え、ハッシュタグ、メンション、共有リンクといった第一級オブジェクトの配列も含まれます。ポストしたアカウントについては、そのユーザーのプロフィールやその他のアカウントメタデータを提供する、さまざまな属性を持つ User (または Actor) オブジェクトがあります。プロフィールには、短い自己紹介文、ホームロケーション (自由入力テキスト) 、優先言語、任意のウェブサイトリンクが含まれます。 一部のアカウントメタデータは変わることはありません (例: 数値のユーザー ID や作成日) 。一部は時間の経過とともにゆっくり変化し、その他の属性はより頻繁に変化します。人は仕事を変え、引っ越しをします。企業は自社情報を更新します。履歴の投稿を収集する場合、メタデータのうち一部は「ポストされた当時の情報」であり、別のメタデータは「クエリ送信時点の情報」であることを理解しておくことが重要です。  すべての履歴系 API では、ユーザーのプロフィールの説明文、表示名、およびプロフィールの「home」属性は、クエリ送信時点の値に更新されます。

「ネイティブ」メディア

X.com と X モバイルアプリでは、ボタンをクリックしてフォトギャラリーから選択することで、ポストに写真や動画を追加できます。これらは第一級の操作として統合されているため、この方法で共有される動画や写真は「ネイティブ」メディアと呼ばれます。 多くのクエリ演算子は、これらの「ネイティブ」リソースを対象として機能し、has:videoshas:imageshas:media などがあります。これらは、X の機能を通じて共有されたメディアコンテンツにのみマッチします。X プラットフォーム外でホストされているその他のメディアにマッチさせるには、URL メタデータに対してマッチする演算子を使用する必要があります。 Historical PowerTrack と Full-Archive Search の製品詳細に入る前に、プロダクトおよびプラットフォームとしての X が時間の経過とともにどのように進化してきたかを見ていきましょう。 X のタイムライン 以下に、X に関する タイムライン の一部を示します。これらの X のアップデートのほとんどは、ユーザー行動、ポストの JSON コンテンツ、クエリ演算子、あるいはそのすべてに、何らかの形で根本的な影響を与えました。X を API プラットフォームとして見ると、これらのイベントは、ポストをエンコードするために使用される JSON ペイロードに何らかの形で影響してきました。その結果、その JSON の詳細が、X の履歴 API がそれらにどのようにマッチするかにも影響します。 このタイムライン一覧は、概ね正確ではありますが、網羅的ではない点に注意してください。

2006

  • 10月
    • @replies が慣習として使われるようになる。
    • cashtagsが初めて登場するが、株式ティッカーの言及に使われるようになるのが一般的になるのは2009年初頭ごろ。cashtags が初めて登場するが、株式ティッカーの言及に使われるようになるのが一般的になるのは 2009 年初頭ごろ。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

2017

  • 2月 - X Poll メタデータがポストのメタデータに含まれるようになる (拡張ネイティブ形式のみ) 。
  • 4月 - 「Simplified Replies」 が導入され、返信先アカウントが 140 文字数にカウントされなくなる (「dmw140, part 2」) 。
2018 2022
  • 9月29日 - 投稿の編集機能が一部のテストグループにロールアウトされる。編集されたポストのメタデータが、該当する場合はポストオブジェクトに追加される。これには edit_history オブジェクトおよび edit_controls オブジェクトが含まれる。これらのメタデータは、編集可能機能が追加される前に作成された投稿については返されない。これらのメタデータに関連する Operator は存在しない。ポストの編集がどのように機能するかの詳細については、Edit Posts fundamentals を参照。
フィルタリングのヒント 新機能がいつ、どのように追加されたかという X のタイムラインに慣れておくことは、より効果的なクエリの作成に役立ちます。ここでいうクエリとは、X の履歴 API によって投稿アーカイブに適用される フィルター または ルール を意味し、PowerTrack Operators を使用してポストの JSON にマッチさせます。例としては、特定の言語の投稿にマッチさせるために使用される 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 データのマッチングと理解に重要な、これらおよびその他の属性クラスについて、さらに詳しく説明します。

偽陰性を見分ける

フィルターを作成する際に重要なポイントの 1 つは、メタデータを対象にマッチングする Operator にはすべて「導入日 (born on 日) 」があるということです。あるポストが投稿されたに導入されたメタデータに対して動作する Operator を使ってフィルターを作成すると、そのポストはヒットせず、偽陰性が発生します。たとえば、「snow」に言及し、かつ動画を共有しているすべての投稿に関心があるとします。このとき、ネイティブ 動画を含む投稿にマッチする has:videos Operator を使ってルールを作成しても、その条件は 2015 年以前の投稿にはマッチしません。 しかし、X では 2015 年よりずっと前から、動画の共有は一般的に行われていました。当時は、ユーザーは他の場所にホストされている動画へのリンクを共有していましたが、2015 年に X はプラットフォームに新しい「動画共有」機能を直接実装しました。こうしたそれ以前の対象ポストを見つけるには、url:”youtube.com” のようなルール句を追加します。 なお、Search API では、インデックスの再構築時にメタデータが「バックフィル」される例もあります。よい例としては、株式銘柄を議論する際に 2009 年に広く使われるようになった cashtagがあります。2015年にcashtag があります。2015 年に cashtag オペレーターが導入された後、Search インデックスが再構築され、その過程でシンボルエンティティが、2006 年初期を含むすべてのポスト本文から抽出されました。当時は $ は主にスラングとして使われており、「I hope it nownow $oon!」のような使われ方をしていました。

ユースケースにとって重要なポスト属性の特定とフィルタリング

X アカウントの数値 ID など、メタデータの中にはサービス開始当初から存在しており (変更されることのないアカウントメタデータの一例です) 、一方で、2006 年の X 開始からかなり時間が経ってから導入されたものもあります。新しく導入されたメタデータの例としては、リツイートのメタデータ、ポストの位置情報、URL のタイトルと説明、「ネイティブ」メディアなどがあります。以下では、これらの X プラットフォームの更新によって大きな影響を受けた、代表的なポスト属性の種類をいくつか紹介します。 これらに対するフィルタリングやマッチングの動作は、多くの場合、使用する過去のポスト API によって異なります。どの製品が調査やユースケースに最適であるかを判断しやすくするため、以下の属性の詳細には、概要レベルの製品情報も含めています。

X プロフィール

根本的には X はグローバルなリアルタイムのコミュニケーションチャネルであるため、ポストデータを用いたリサーチでは、誰が発信しているのかに重点が置かれることがよくあります。多くの場合、X ユーザーがどこをホームと考えているかを知ることが役立ちます。また、アカウントの自己紹介文 (bio) に興味や趣味への言及が含まれているかを知ることで、関心のあるポストを見つけやすくなります。関心のあるアカウントからの投稿をモニタリングしたいというニーズも非常によくあります。プロフィール属性は、これらすべてのユースケースにおける重要な要素です。 X 上のすべてのアカウントにはプロフィールがあり、X の @handle、表示名、短い自己紹介文、ホームロケーション (ユーザーが入力する自由形式テキスト) 、フォロワー数などのメタデータが含まれます。数値のユーザー id やアカウントの作成日時のように、決して変わらない属性もあります。一方で、投稿数やフォローしているアカウント数、フォロワー数のように、日ごと・週ごと・月ごとに変化するのが通常の属性もあります。その他のアカウント属性もいつでも変更できますが、変更頻度はそれほど高くありません。たとえば、表示名、ホームロケーション、自己紹介文などです。 すべてのポストの JSON ペイロードには、そのポストの投稿者に関する account profile メタデータが含まれます。リポスト (Retweet) の場合、元のポストを投稿したアカウントのプロフィールメタデータも含まれます。 ポストのプロフィールメタデータの可変性は、利用している履歴向けプロダクトに完全に依存します。Search APIs は、取得時点の プロフィール設定を持つ履歴投稿を提供します。Historical PowerTrack では、2011 年以前のデータを除き、プロフィールは ポストが投稿された時点の状態 を反映します。2011 年より古い投稿については、プロフィールメタデータは 2011 年 9 月時点のプロフィールを反映します。

元のポストとリツイート

リツイートは、ユーザー主導の慣習が公式なオブジェクトになったもう一つの例です。リツイートは、コンテンツを他者に「転送」する方法として生まれました。最初は、ポストをコピー&ペーストし、その先頭に「RT @」というパターンを付ける手作業のプロセスでした。このプロセスは、JSON メタデータを備えた新しい Retweet ボタンによって自動化されました。こうして「公式」なリツイートが誕生し、リツイートするという行為は、第一級のイベントとして扱われるポストイベントになりました。新しい Retweet ボタンとともに、元のポストの完全なペイロードといった新しいメタデータも導入されました。 ポストがオリジナルか共有かは、よく使われるフィルタリング条件です。オリジナルのコンテンツだけが必要となるケースもあれば、ポストのエンゲージメントが最重要となり、リツイートが鍵となるケースもあります。PowerTrack の is:retweet 演算子を使うことで、リツイートを含めるか除外するかを制御できます。2009年8月より前のデータを取得する場合、ユーザーはリツイートにマッチさせる (あるいはマッチさせない) ための 2つ の戦略を持つ必要があります。2009年8月以前については、ポストメッセージ自体を、「@RT 」パターンに対して完全一致検索を行うことでチェックする必要があります。2009年8月以降の期間については、is:retweet 演算子が利用可能です。

ポストの言語分類

ポストがどの言語で書かれているかは、一般的な関心事項です。ポストの言語は、そのポストのおおよその位置を推定する手がかりとなり、多くの場合、分析や表示の目的では特定の言語だけを対象にすれば十分です。 (X のプロフィールには、優先言語の設定もあります。) ポストの言語分類によるフィルタリングについては、X の履歴系プロダクト (Search API と Historical PowerTrack) では仕様が大きく異なります。Search アーカイブが構築された際、すべてのポストに X の言語分類がさかのぼって付与されました。そのため、lang: 演算子はポストの全アーカイブに対して利用できます。一方、Historical PowerTrack では、X の言語分類メタデータは 2013 年 3 月 26 日以降のアーカイブで利用可能です。 

投稿の位置参照

ポストがどこから発信されたか (すなわち、位置情報をひも付けること) は、多くのユースケースで重要です。投稿に位置情報をひも付ける主な方法は次の 3 つです。
  • ポスト本文中の地理的な参照情報
  • ユーザーによって位置情報タグが付けられた投稿
  • ユーザーがアカウントプロフィールで設定した「ホーム」ロケーション
ポストメッセージ内の地理的参照
ポストメッセージ内の地理的参照に基づいてマッチングする方法は、ローカルな知識に依存するため多くの場合もっとも難しい手法ですが、ポストアーカイブ全体に適用できるオプションです。以下は、「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月で、その他の Geo 演算子では 2015年2月からです。Historical PowerTrack を使用している場合、ジオリファレンスは 2011年9月1日から利用可能です。Historical PowerTrack アーカイブが構築された際、この日付より前のすべてのジオタグ情報は含まれていません。
ユーザーが設定するアカウントプロフィールの「自宅」位置情報
すべてのXユーザーは、自分のホームロケーションを示す Profile Location を設定することができます。何百万人ものXユーザーがこの情報を提供しており、X Firehose 内の地理データ量を大幅に増加させています。この位置情報メタデータは、正規化されていない、ユーザーが自由入力した自由形式の文字列です。約 30% のアカウントには、国レベルまで特定可能な Profile Geo メタデータがあります。 ポストの位置情報と同様に、照合方法や利用可能な期間は、使用している Historical API に依存します。Historical PowerTrack を利用すると、これらの自由形式文字列に対して独自のカスタム照合を試すことができます。そのプロセスを容易にするために、X は可能な場合にジオコーディングを実行し、正規化されたメタデータと対応するオペレーターを提供する Profile Geo Enrichment も提供しています。Profile Geo オペレーターは、Historical PowerTrack と Search APIs の両方で利用できます。Historical PowerTrack では、これらの Profile Geo メタデータは 2014 年 6 月から利用可能です。Search APIs では、このメタデータは 2015 年 2 月から利用可能です。 Webページのリンク、写真、動画を共有することは、常にXにおける基本的なユースケースでした。初期の頃は、これらすべての操作は投稿本文の中にURLリンクを含めることで行われていました。2011年には、Xのユーザーインターフェースに写真を直接共有する機能が統合され、2016年にはネイティブ動画が追加されました。 このような経緯から、この種のコンテンツにマッチさせるためのさまざまなフィルタリング用の演算子があります。共有リンク、写真、動画を含む投稿かどうかに基づいてマッチさせる演算子のセットが用意されています。また、X上で共有されるURLのほとんどは、投稿の文字数を節約するために短縮されており (例: bitly や tinyurl などのサービスによって生成) 、Xはマッチングに利用できる完全な展開済みURLを生成するデータエンリッチメントを提供しています。たとえば、XとEarly-warning systems (早期警報システム) についてのリンクを含む投稿にマッチさせたい場合、「severe weather communication」を参照するフィルターは、この http://bit.ly/1XV1tG4 URL を含む投稿にマッチします。 2012年3月に、expanded URL enrichment が導入されました。それ以前は、投稿のペイロードにはユーザーが指定したURLのみが含まれていました。そのため、ユーザーが短縮URLを含めていた場合、関心のある (展開された) URLにマッチさせることは困難になり得ます。Historical PowerTrack と Search APIs の両方では、これらのメタデータは2012年3月以降利用可能です。 2016年7月には、enhanced URL enrichment が導入されました。この拡張版では、投稿のペイロード内にウェブサイトのHTMLタイトルと説明が含まれ、それらに対してマッチングを行うための演算子も提供されます。Historical PowerTrack では、これらのメタデータは2016年7月から利用可能です。Search APIs では、これらのメタデータは2014年12月から利用可能になります。 2016年9月、Xは「ネイティブ添付」を導入し、末尾の共有リンクが投稿の140文字制限のカウント対象外となりました。両方のURLエンリッチメントは、これらの共有リンクにも引き続き適用されます。 URLフィルタリングに関する、URL関連プロダクト固有のその他の詳細については、該当する記事を参照してください。