はじめに

 

Twitter APIを使用すると、公開の会話を分析して、いま何が起きているのかの把握、インサイトの発見、トレンドの見極めなどが行えます。公開の会話の大量で多様なデータは、Twitter APIを使用して自分のデータセットを構築する大きなメリットとなります。  同様に、これらのダイナミクスは、質と量の両方の観点で適切なデータを確保する際の課題となります。 

 

高品質のフィルターを構築することで、最終的に、分析対象となる会話のユースケースあるいは代表となる十分なデータを確保できます。さらに、適切なフィルターを構築すると、データセットの整理に必要な時間と労力が節約でき、アクセス制限の範囲内で確実に作業できるようになります。時間を割いて高品質なフィルターを作成することは、Twitterデータを正しく分析するための重要なステップの1つです。

 

このガイドでは、次のような、分析用フィルターを構築するためのベストプラクティスをご紹介します。

  • 必要なデータを決定する際に検討すべき主な事項

  • データセットに変更や影響を与える可能性のある、考慮すべき重要な要因 

  • 新しいTwitter APIで使用できる新しい演算子

  • ルールとクエリを構築するための演算子の使用例

  • 調査と分析用にデータを収集する際の、その他の考慮事項

 

目次

 

適切なデータ収集のための範囲設定

フィルターのタイプ

ツイート収集時の重要な考慮事項

演算子とそれらの調査および分析のユースケースに対する関連性の概要

クエリおよびルールの例

追加リソース


 

適切なデータ収集のための範囲設定

 

Twitterデータの収集のために演算子を使用したりルールを構築したりする前に、データ条件の範囲を定義することが重要です。「Twitterデータを使用してさらに多くのことを行う」の記事では、目的のユースケースにどのようなデータが必要かを計画する際の重要な検討事項について説明しています。以下では、さらに詳細を加えたうえでその内容を説明します。

 

理由

 

この検討事項は、ユースケースの目的に関係します。特定のトピックについてのデータを探す「理由」を把握することは、必要となるデータの種類を定めるうえでの助けとなります。たとえば、可視化でのクラスプロジェクトに必要なデータ(ツイートの例1つで十分かもしれません)は、機械学習(ML)の問題を解決する分類器をトレーニングし構築するために必要なデータ(より多くの特殊なデータが必要)とは異なるでしょう。

 

対象

 

この検討事項は必要なデータの種類に関係します。考慮すべきポイントには次のようなものがあります。

  • 特定言語のツイートが必要かどうか。

  • 画像付きのツイートが必要かどうか。

  • リツイートのツイートが必要かどうか。

これらの検討事項に答えることが、必要なデータの種類(さらには適切なフィルター基準)を定める手助けとなります。目的のユースケース用にデータを収集する場合に考慮すべきいくつかのヒントを以下に示します。

 

時期

 

この検討事項は、目的とするユースケースに必要なデータの期間を定める手助けとなります。調査対象のトピックに履歴データが必要かどうか(必要の場合、いつまで遡るか)、リアルタイムで作成されるツイートが必要かどうか、などを定めます。これに基づき、必要性を満たすエンドポイントを決めることができます。 

 

対象者

 

目的のユースケースによっては、以下からのツイートの収集が必要となるかもしれません。

  • 特定のアカウント

  • 特定のアカウントのフォロワー

  • オーディエンスまたはアカウントのセット(主要なニュース組織など)

  • 特定のトピックについて会話しているすべての人々

 

これらの検討事項は、目的のユースケースに対して適切なツイートソースを特定する手助けとなります。使用するエンドポイントも、この検討事項への答えにより異なります。たとえば、特定のアカウントについて調べる場合、user_timeline endpointfollowers/idsなどを使用することになるでしょう。

 

場所

 

この検討事項は、目的のユースケースのツイートおよびユーザーの地理的場所を特定することと関係します。その一例は、ハリケーン「ハービー」に関する会話の調査があります。緊急事態管理システムの研究者や開発者は、調査のため、2017年のハリケーンの間、ヒューストンのユーザーがどのようにTwitterを使用していたかを調べる必要があります。それには、ヒューストンから、またはヒューストンにあるユーザーからの、「ジオタグ付きの」ツイートを調べる必要があります。「ジオフィルタリング」の詳細は次のセクションを参照してください。 

 

フィルターのタイプ

 

Twitter APIからデータを収集する場合、必要なデータをフィルタリングする方法には2種類あります。

 

演算子を使用したフィルタリング

 

Twitter APIを使用する場合、演算子を使用して、フィルタリング対象のデータを指定できます。これにより、Twitter APIから受け取るデータは、指定した基準に合うものに限定されます。使用するルールやフィルタリングが適切に定義され包括的なものであればあるほど、必要のないデータを収集する可能性は低くなります(また、やり直しの頻度が少なくなり、取り損なうデータが減ります)。そのため、データセットを整理する労力を減らすことができます。最新の検索エンドポイントやフィルタリングされたストリームエンドポイントに使用できる演算子の詳細は、以下のリンクを参照してください。

 

カスタムコードロジックを使用したフィルタリング

 

演算子が直接サポートするのではなく、カスタムコーディングが必要な、高度な条件に基づいたツイートのフィルタリングが必要な場合もあります。たとえば、少なくとも「x」人のフォロワーがいるユーザーによるツイートをフィルタリングする場合です。そのような条件の場合、後処理が必要です。まずTwitterデータを処理した後、ユーザーオブジェクト上で条件チェックを行います。


 

ツイート収集時の重要な考慮事項

 

探索的分析

 

大量のツイートが保存されているデータの収集を開始する代わりに、データに必要なクエリやルールを指定した後、このデータの一部を収集し、収集したツイートの初期サブセットを探索的分析にかけるのは理にかなった方法です。それによって、クエリやルールを検証し、適切なデータを収集しているかどうかの確認ができます。探索的分析から、次のような追加情報を取得できます。

  • 調査対象の会話で他にどのような用語が使用されているか
  • それまで含められていなかった、会話に関する特定の「スラング」ワード

  • 特定のハッシュタグが会話の一部として使用されているか

  • 特定の場所の人々が他よりも多くそのトピックについてツイートしているか

  • 特定のメディアコンテンツが会話の一部として使用されているか

  • 人々が会話の一部としてURLなどを共有しているか

探索的分析の初期結果に基づきルールを改善し、収集するデータが、データのニーズに確実に関連するようにできます。

 

このような探索的分析を行う一般的な方法を次に示します。

  • PythonでPandasを使用したり、Rを使用したりしている場合は、head()関数を使用してツイートの初期データフレームの一部を探索し、コンテンツを詳細に把握する

  • matplotlib(Python)やggplot2などの可視化ライブラリを使用し、ツイートデータの可視化表示を行い、ツイートのパターンを確認する

  • ツイートをトークン化し、特定のキーワードの頻度や出現数をカウントする 

 

ノイズのフィルタリング

 

前のセクションで説明したように、映画のアイアンマンではなくトライアスロンレースのアイアンマンに関する全ツイートが必要な場合、初期の探索的分析を行うと、結果データには映画のアイアンマン(レースではなく映画に関連したその他の用語)についてのツイートが含まれるという事実を特定できます。あるいは、「ドッグ」に関するツイートを探していて、探索的分析を行うと、初期ツイートデータには「ホットドッグ」や「ウォッチドッグス」(テレビゲーム)などが含まれることがわかります。ここで、「ホット」や「テレビゲーム」などの用語を(否定演算子「-」を使用して)除外するようルールを改良し、ノイズを除去して取得する結果データが目的のユースケースに関連するようにします。

 

さらに、探索的分析後、以下の項目を基にデータコレクションからノイズをフィルタリングし除去するように決めることもできます。

 

  • ユーザーアカウント

    特定のアカウントをそのアカウントの性質やコンテンツの質に基づいて除外したり、無関係な特定のアカウントツイートとの間のツイートを除外したりできます。また、特定のユーザーアカウントが無関係なキーワードと結びついて頻繁に@ツイートされる場合にも、これを行うことができます。

 

  • ツイートコンテンツ

    コンテンツ自体に基づいてツイートを除外することもできます。たとえば、あるトピックに関するセンチメントを知りたい場合、センチメントを判断する材料となるテキスト、コンテンツ、句などがないハッシュタグだけのツイートを除外できます。このようなツイートのデータを詳細化するためには、正規表現などを使用してコードにカスタムロジックを書き込む必要があります。 

 

  • リツイートのふるまい

    ツイート自体の内容を調べていて、ツイート量の大きさやメトリクスには高い関心がないかもしれません。この場合、微調整してリツイートをフィルタリングできます(たとえば、-is:retweet)。または、一部の情報の拡散の仕方に関心がある場合は、分析の一部としてリツイートを調べることもできます。 

 

まとめると、ノイズをフィルタリングするには次のように複数の手法を組み合わせて使用します。

 

  • 演算子を使用してTwitter APIから直接受け取るデータの範囲を設定する

    • 包含、除外(否定、AND、句と個別の単語)

       

  • 条件に基づく追加フィルターが演算子やその他の定性的な条件に合わない場合に、カスタムコードロジックや後処理を使用する次のようないくつかの例があります。

    • 特定の数のフォロワーがいるユーザーによるツイート

    • 特定の数のリツイートがあるツイート

    • 特定のコンテンツ構造を持つツイート(たとえば、追加情報のないハッシュタグだけのツイートはすべて除外)

 

目的のユースケースとコンテキストが関連するキーワードを使用する 

 

ルールを作成しデータをフィルタリングする場合、ユースケースに直接関連するさまざまな用語を使用することを検討してください。

 

ユースケースに基づき、同じトピックに異なる用語を使用してツイートを収集する必要があることもあります。

  • たとえば米国で「フットボール」というキーワードを使用すると、その語が指すのはアメリカンフットボールであり、その他の国で「フットボール」と呼ばれる「サッカー」ではありません。 
  • 同様に、映画やスーパーヒーローのアイアンマンではなく、トライアスロンレースの称号であるアイアンマンを指すために「アイアンマン」という語を使用する場合もあるかもしれません。 

したがって、コンテキストが関連する適切な用語セットを確実に使用することが、データを適切に収集するのに役立ちます。

 

大半のユースケースでは、ハッシュタグだけがトピックの会話全体を表すわけではありません。 トピック会話の参加者が自分のツイートに所定のハッシュタグを含めない(あるいは別のハッシュタグを使用したり新しく始めたりする)ことは、よくあります。たとえば、特定の都市の交通量のように、現在進行中のトピックに関する会話に関心がある場合、一部のユーザーがこのトピックについての自分のツイートにハッシュタグ(#nyctrafficなど)を使用しても、他の多くのユーザーは使用しないかもしれません。ハッシュタグは、会話の中でのその他の関連または派生する用語、ユーザー、ハッシュタグのすべてを識別するためのすぐれた開始点ではありますが、単独で使用した場合、通常は不十分だったり、トピックや会話を代表するものではなかったりします。 

 

スレッドと会話を調査する

 

対象のツイートに関連した応答や会話の調査に関心をお持ちかもしれません。これまで、コメントや返信のあるリツイートを含むスレッドや会話を収集することは、開発者にとって、やや困難な課題でした。しかし、新しいTwitter APIでは、親ツイート(返信ツイートの親)を含むようになった会話ID機能の挿入で、このプロセスが簡単になりました。これらの分野と使用法に関する詳細は、この記事の後の方で説明します。

 

コンテンツやトピックの変化

 

特定のトピックについてのデータ収集を開始する場合、そのトピックに関連する可能性のある特定のキーワードセットから始めます。しかし、会話が進むにつれ、別の新しいキーワードが現れる場合もあります。たとえば、パンデミック初期のコロナウィルスに関するツイートを収集し始めた場合、covid19、covid-19、コロナ、コロナウィルスなどのキーワードを使用するかもしれません。しかし、会話は、「隔離」、「#stayathome」、「ソーシャルディスタンス」などのコロナウィルスに関連した新しい語で識別できる別の話題に変化しました。調査の一環として、これらの新しいキーワードの一部またはすべてを含む、このトピックに関するツイートを収集することに関心を持つかもしれません。以下に、コンテンツやトピックの「変化」に対処する戦略を2つ示します。

 

データパイプラインで一般的な用語を追跡し続ける

 

会話の変化を見分けるための最も基本的な手法は、一般的によく出現する用語と、自分の関心のあるトピックに関連付けられる新しい用語の出現を継続して追跡することです。ユースケースのために初期データパイプラインを構築してTwitterデータを使用し保存する際、取り込んだツイートのメタデータを一定期間保持できます。このメタデータを使用することで、新しいキーワードの出現を識別できます。 

 

これを行うには、パイプラインにデータを取り込む際、ツイートをトークン化してストップワードや特殊文字などを除外し、単語の総計カウントと頻度を期間ごとに保持します。この集計データを使用すると、新しい用語が現れたかどうかを識別できます。新しい用語を識別したら、クエリ(最新の検索を使用している場合)またはルール(フィルタリングされたストリームを使用している場合)を更新し、新しい用語を含めることができます。

 

注釈を使用する(コンテキストまたはエンティティ演算子を使用)

 

新しいTwitter API v2のエンドポイント(フィルタリングされたストリームおよび最新の検索)はどちらもcontextオペレータまたはentityオペレータでのフィルタリングをサポートしており、これを利用してトピックごとにツイートを収集できます。したがって、あるトピックについてさまざまな検索語を使用する代わりに、コンテキストオペレータまたはエンティティ演算子を使用して、ツイートのドメインまたはエンティティを指定できます。このように、トピックの基盤となるキーワードが変化しても、Twitterが新しい語をそのトピックに関連付けて、これらのキーワードを持つツイートが応答に含まれるようになります。データセットにキーワードを追加することにした場合、クエリやルールにこれらの追加用語をいつでも補足できます。最低でも、注釈を有用な開始点として利用できます。注釈の使用方法についての詳細は、この記事の「演算子」セクションを参照してください。

 

サンプルと収集のバイアス

 

データの収集方法は、分析、評価、結論に影響する可能性があるため、重要です。以下では、Twitterデータのコンテキストで、バイアスが入り込むいくつかの例に加え、バイアスに対処するためのアイデアを示します。

 

狭い範囲のキーワードセットに頼る

1つまたは2つのハッシュタグやキーワードに基づいて、それ以外のさまざまなキーワードでも発生しているトピックについてツイートを収集すると、特定の会話に片寄ったデータセットになってしまう可能性があります。上述のコロナウィルスを例にとると、検索語としてcovid19だけを使用した場合、隔離、#stayathomeなどのその他の語を使用する関連の会話を、すべて見逃してしまう可能性があります。

 

ジオタグ付きのツイートのみに頼る 

ツイートでそれに関連するジオタグがあるのは、わずかです。したがって、ジオタグの付いたツイートだけに頼ると、データセットにバイアスが生じる可能性があります。これは、データ収集の方法論やユースケースの一部とみなす必要があります。

 

小さいデータセットに頼る

ユースケースに基づき、データセットには、会話を代表すると思われる十分な量のツイートを確保する必要があります。分類などのMLのユースケースでは、非常に小さなデータセットを使用した場合、モデルの過剰適合につながりかねません。そのため、調査には十分な量のデータを含むようにする必要があります。小さなサブセットのツイートデータセットのみを使用する場合、会話全体についての結論は引き出せません。

 

特定期間のみのツイートに頼る

ユースケースで、過去に起こったイベントについてのデータ(履歴データ)を検索する必要があるのか、現在の(進行中の)イベントを調べようとしているのか、調査する会話のあらゆる側面を考慮できるように、データを収集する期間を慎重に検討してください。タイムフレームが不適切あるいは不十分(イベントの重要な日付、開始時点、終了時点などがない)な場合、データセットにバイアスが生じる可能性があります。

 

コンプライアンス

 

Twitterデータを保存する場合、開発者ポリシーの一環として、ポリシーに準拠する必要があります。詳細については、ドキュメンテーションページを参照してください。

 

演算子とそれらの調査および分析のユースケースに対する関連性の概要

 

Twitterデータをフィルターするには、「クエリ」を指定する(最新の検索エンドポイントを使用する場合)か「ルール」を作成する(フィルタリングされたストリームエンドポイントを使用する場合)必要があります。これらのクエリとルールは、必要なデータを指定するのに役立つ演算子の組み合わせです。これまでに、v1.1 search/tweetsエンドポイントを使用したことがある場合、そのエンドポイントの演算子についてよくご存知かもしれません。この新しいエンドポイント(最新の検索またはフィルタリングされたストリーム)は、新しい演算子をサポートしています。新しい最新の検索エンドポイントと、新しいフィルタリングされたストリームエンドポイントの演算子の全リストについて記載したドキュメンテーションを確認してください。

 

注:フィールドが最新の検索エンドポイントからツイートオブジェクトにリクエストされる仕組みは、以前のsearch/tweetsエンドポイントとは異なります。新しいツイートペイロードは、v1.1 search/tweetsエンドポイントに含まれていない追加フィールドもサポートします。新旧のツイートペイロードの詳細な比較は、移行ハブに記載されています。

 

以下は、これらの新しい演算子と、それらの調査や分析のユースケースに対する関連性の一部をまとめたものです。

 

会話ID

 

最新の検索エンドポイントでは、会話の一部であるツイートをすべて収集できる新しい演算子conversation_idが導入されました。たとえば、フォローアップの会話を把握するために、あるツイートへの返信すべてを収集する場合、最初のツイートのツイートIDとともに、最新の検索クエリでconversation_id演算子を使用します。

 

 この演算子が使用できるようになるまでは、開発者は独自の手法でツイートに対する返信を収集する必要がありました。これには、「to」演算子を使用し、処理するすべてのツイートを収集した後、応答を解析して、in_reply_to_status_id_strに一致するツイートを抽出する過程などがありました。conversation_id演算子を使用することで、このカスタムロジックを行う必要がなくなり、簡単に、会話(返信を含む)の一部であるツイートをすべて収集できるようになります。 

 

クエリやルールの例のセクションでこの演算子を使用する例を以下に示します。

 

ツイート注釈(コンテキストおよびエンティティ)

 

フィルタリングされたストリームエンドポイントと最新の検索エンドポイントはどちらも、新しい「context」および「entity」演算子をサポートしており、ツイートデータのコンテキストに即した解釈に基づいてツイートを収集する場合に便利です。これらのオペレータを使用すると、膨大な検索用語のリストを持つ複雑なクエリを書かなくても、トピックまたはエンティティのデータを収集できます。たとえば、アメリカンフットボールに関するすべてのツイートが必要な場合、以前は、検索クエリやルールに、(NFL OR Football OR “Baltimore Ravens” OR “Seattle Seahawks”)などのさまざまな語を使用する必要がありました。contextオペレータを使用すると、上記のクエリをcontext:11.689566306014617600で置き換えるだけで、アメリカンフットボールに関するツイートをすべて収集できます。 

 

context演算子は、ドメインやトピックでのツイートのフィルタリングをサポートし、entity演算子は、名前の付いたエンティティでのツイートのフィルタリングをサポートします。ドメインとエンティティのどちらもIDで識別でき、名前プロパティも持っています。ドメインには、Brand、Product、Personなどがあります。エンティティは、NFL Football、Baltimore Ravensなどがあります。context演算子を使用する場合のフォーマットは、context:<domain_id>.<entity_id> です。

 

注釈とサポート対象のドメインについての詳細はドキュメンテーションを参照してください。クエリやルールの例のセクションでこの演算子を使用する例を以下に示します。

 

ORの前のANDを優先

 

新しい最新の検索エンドポイントとフィルタリングされたストリームエンドポイントで演算子を使用する場合に注意すべき重要な相違点は次のとおりです。

  • 以前のv1.1 API(search/tweets)では、ORは論理AND(語や演算子の間でスペースで示される)の前に適用されます。

  • 新しいTwitter API(最新の検索とフィルタリングされたストリーム)では、ANDがORの前に適用されます。

 

次の例を参照してください。

 

クエリ:corona covid OR covid-19

 

以前の標準的な検索エンドポイントでの解釈:

coronaという用語とともにcovidまたはcovid-19という語が付くツイートすべてを返す

 

新しい最新の検索エンドポイントでの解釈:

次のいずれかを含むツイートすべてを返す

  • coronaとcovidという両方の用語

  • またはcovid-19という用語

 

クエリおよびルールの例

 

ルールとフィルターを構築するために一般的に使用される演算子の例をいくつか以下に示します。

 

否定演算子を使用する

 

否定演算子を使用すると、特定の条件に基づくツイートを除外できます。これは、演算子の前のハイフン(-)で記されます。 

 

たとえば、アイアンマンレースに関するツイートを収集しながらも映画やスーパーヒーローのアイアンマンについては収集したくない場合、次に示すように否定演算子を使用してこれらの語を除外できます。

 

ironman -movie -superhero

 

同様に、リツイートではないツイートすべてを除外する場合には、次の例を使用できます。

 

-is:retweet

 

注:括弧でまとめられた演算子のセットを否定することはできません。セットを否定する代わりに、個別の演算子を否定します。

たとえば、-(grumpy OR cat OR meme)を使用する代わりに、-grumpy -cat -memeを使用することを推奨します。

 

ANDを使用する

 

AND演算子は演算子間の論理ANDのために使用できます。したがって、ANDを演算子間に用いると、すべての条件に一致するツイートが返されます。

 

たとえば、「cat」と「dog」の両方に関するツイートを収集する場合、クエリのフォーマットは次のようになります。

 

cat AND dog

 

上記の例では、「cat」と「dog」の両方の語に一致するツイートのみが含まれます。

 

注:2つの語または演算子間のスペースも論理ANDを示します。

 

ORを使用する

 

OR演算子を使用すると、それ以外の演算子間の論理OR条件が設定できます。そのため、条件の1つが当てはまるツイートがあると、応答としてそのツイートが返されます。

 

たとえば、「cat」または「dog」に関するツイートを収集する場合、クエリのフォーマットは次のようになります。

 

cat OR dog

 

上記の例で、

  • ツイートに「dog」がある場合、応答にはそれが含まれます。

  • ツイートに「cat」がある場合、応答にはそれが含まれます。

 

完全フレーズ一致

 

二重引用符(“)でフレーズを指定することで、そのフレーズと完全に一致するフレーズを含むツイートを検索できます。たとえば、「Twitter API」と完全に一致するフレーズを含むツイートをすべて収集する場合、次のようなクエリ

 

Twitter API

 

は機能しません。これはTwitterという言葉とAPIという言葉を含むツイートを含めますが、これらの言葉は「Twitter API」というフレーズのように必ずしも互いに隣り合っているわけではありません。つまり、たとえばデータセットには「I am new to Twitter and I want to learn about API programming」というようなツイートが含まれるかもしれませんが、探しているのは、「I am interested in learning about the Twitter API」のようなTwitter APIのフレーズについて話すツイートかもしれません。この完全一致を得るには、次の例のように引用符で囲まれた、Twitter APIを使用できます。

 

“Twitter API”

 

言語によるフィルタリング

 

lang演算子を使用すると、ツイートを言語でフィルタリングできます。そのために、ツイートが行われている言語を(言語コードを使用して)指定できます。サポートされる言語のリストを確認してください。この演算子のフォーマットは次のとおりです。 

 

lang:language_code

 

たとえば、英語のツイートをすべて収集する場合、lang演算子は次のようになります。

 

lang:en

 

括弧を使用する

 

括弧を使用すると演算子をグループにまとめることができます。これによって、クエリを整理し、適切な論理演算子をクエリに確実に適用できるようになります。たとえば、

 

(grumpy cat) OR (#meme has:images) 

 

は、grumpyおよびcatという語を含むツイート、または、#memeというハッシュタグを含む画像付きのツイートを返します。 

 

注:AND演算子が最初に適用され、その後にORが適用されます。

 

ツイートへの返信を収集する

 

新しい演算子conversation_idを使用してツイートへの返信を収集できます。ツイートが会話スレッドの一部である場合、そのツイートの会話IDは、親ツイートIDに一致します。 

 

この演算子の使用例は次のとおりです。

 

conversation_id:1255542774432063488

 

トピック別にツイートを収集する

 

さまざまなキーワードのリストを使用する代わりに、次の2つの演算子を使用して、最新の検索エンドポイントまたはフィルタリングされたストリームエンドポイントを使用すると、特定のトピックについてのツイートを収集できます。

 

1. context

この演算子は、特定のドメインID、またはドメインIDとエンティティIDのペア(またはその両方)を持つツイートを収集できます。サポート対象のドメインのリストは、注釈のページにあります。この演算子を使用する場合のフォーマットは、次のいずれかです。

 

context:domain_id.entity_id [This will give you all Tweets about an entity within that domain]

 

context:domain_id.* [This will give you all Tweets about that domain]

 

たとえば、

ドメイン「NFL Football Game」に関するツイートを収集する場合、context演算子は次のようになります。

 

context:28.* [28 is the domain id for this domain]

 

2. entity

この演算子では、エンティティ名の文字列を使用してツイートを収集できます。この演算子を使用する場合のフォーマットは、次のとおりです。

 

entity:entity_name [entity name is the string value, name for the entity]

 

たとえば、

Baltimore Ravensに関するツイートを収集する場合、entity演算子は次のようになります。

 

entity:Baltimore Ravens [“Baltimore Ravens” is the name of the entity]

 

演算子の例のまとめ

 

演算子

使用方法

-

ハイフンの後の用語や演算子を除外する

AND

AND間の基準に一致するツイートをすべて含める、用語や演算子の間の論理AND

OR

OR間の基準のいずれかに一致するツイートを含める、用語や演算子の間の論理OR

“”

検索対象の用語と完全に一致する用語を指定するには二重引用符を使用

()

演算子や用語をグループ化しクエリを整理するには括弧を使用

lang

目的のツイートの言語を指定

conversation_id

ツイートIDを使用してツイートへの返信を含む会話を取得

context

domain_idまたはentity_idまたはその両方を使用して指定されるトピックのツイートを収集

entity

エンティティ名を使用して、名前エンティティのツイートを収集

 

このチュートリアルが、Twitterデータを収集するフィルター構築の手始めとしてお役立ていただければ幸いです。@Twitterdevまたはコミュニティフォーラムに、ご意見、ご感想をお寄せください。


 

追加リソース

  • 新しい最新の検索エンドポイントの演算子の全リスト 

  • 新しいフィルタリングされたストリームエンドポイントの演算子の全リスト