हमारी तुलना गाइड देखें:
परिचय
Enterprise
पोस्ट्स, X से जुड़ी हर चीज़ के मूलभूत निर्माण खंड हैं। पोस्ट्स लौटाने वाले सभी X APIs यह डेटा JavaScript Object Notation (JSON) में एन्कोड करके प्रदान करते हैं। JSON, कुंजी-मूल्य युग्मों पर आधारित होता है, जिनमें नामित एट्रिब्यूट्स और उनसे जुड़े values होते हैं। API से प्राप्त पोस्ट ऑब्जेक्ट्स में किसी X User का “status update” शामिल होता है, लेकिन Retweets, replies और quote Tweets भी पोस्ट ऑब्जेक्ट्स ही होते हैं। यदि कोई पोस्ट किसी दूसरे पोस्ट से संबंधित है, जैसे Retweet, reply या quote Tweet के रूप में, तो उसे पोस्ट ऑब्जेक्ट में पहचाना या एम्बेड किया जाता है। X के मूल डेटा फ़ॉर्मैट में सबसे सरल पोस्ट में भी, पोस्ट के अन्य एट्रिब्यूट्स, जैसे author, उल्लिखित users, टैग की गई place location, hashtags, cashtag symbols, media या URL links को दर्शाने के लिए nested JSON ऑब्जेक्ट्स होते हैं। X डेटा के साथ काम करते समय यह एक महत्वपूर्ण अवधारणा है, जिसे समझना ज़रूरी है। X API से आपको मिलने वाले पोस्ट डेटा का फ़ॉर्मैट, प्राप्त पोस्ट के type, आपके द्वारा उपयोग किए जा रहे X API, और फ़ॉर्मैट settings पर निर्भर करता है।
पोस्ट ऑब्जेक्ट्स लौटाने वाले Enterprise endpoints को इस तरह अपडेट किया गया है कि वे पोस्ट की edit history को समझने के लिए आवश्यक metadata प्रदान करें। इस metadata के बारे में अधिक जानने के लिए “Edit Posts” fundamentals पृष्ठ देखें।
X के मूल फ़ॉर्मैट में, JSON payload में ‘root-level’ एट्रिब्यूट्स और नेस्टेड JSON objects शामिल होंगे (जिन्हें यहाँ
{} notation में दिखाया गया है):
कृपया ध्यान दें: एंटरप्राइज़ डेटा APIs के लिए Enriched Native फ़ॉर्मैट का उपयोग करना अत्यधिक अनुशंसित है।Enterprise data APIs डेटा को दो अलग-अलग फ़ॉर्मैट में उपलब्ध कराते हैं। मानक v1.1 native फ़ॉर्मैट के सबसे निकट का एंटरप्राइज़ फ़ॉर्मैट Native Enriched है। पुराना एंटरप्राइज़ डेटा फ़ॉर्मैट Activity Streams है, जिसे मूल रूप से उस समय X और अन्य सोशल मीडिया डेटा प्रदाताओं के बीच एक सामान्यीकृत फ़ॉर्मैट के रूप में Gnip ने लागू किया था और इस्तेमाल किया था। हालांकि यह फ़ॉर्मैट अभी भी उपलब्ध है, X ने 2017 से केवल native enriched फ़ॉर्मैट में ही नई सुविधाओं और विकास पर निवेश किया है। Enriched native फ़ॉर्मैट ठीक वैसा ही है जैसा इसका नाम दर्शाता है; इसमें native X objects के साथ-साथ एंटरप्राइज़ डेटा उत्पादों के लिए उपलब्ध अतिरिक्त enrichment भी शामिल हैं, जैसे URL unwinding metadata, profile geo, poll metadata, और अतिरिक्त engagement metrics।
- Enriched Native फ़ॉर्मैट में 2017 से जोड़ा गया सभी नया मेटाडेटा शामिल है, जैसे poll metadata, साथ ही reply_count और quote_count जैसे अतिरिक्त मेट्रिक्स।
- 2017 में हुए character update के बाद से Activity Streams फ़ॉर्मैट को नए मेटाडेटा या enrichment के साथ अपडेट नहीं किया गया है।
- Expanded and enhanced URLs enrichment
- Matching rules enrichment
- Poll metadata enrichment
- Profile geo enrichment
- X JSON को UTF-8 वर्णों का उपयोग करके एन्कोड किया जाता है।
- पार्सर को फ़ील्ड्स के क्रम में होने वाले बदलावों को आसानी से संभालने में सक्षम होना चाहिए। यह मानकर चलना चाहिए कि पोस्ट JSON, डेटा के एक अनक्रमित hash के रूप में दिया जाता है।
- पार्सर को ‘नए’ फ़ील्ड्स जोड़े जाने को भी सहन करना चाहिए।
- JSON पार्सर को ‘अनुपस्थित’ फ़ील्ड्स के प्रति सहनशील होना चाहिए, क्योंकि सभी फ़ील्ड्स हर संदर्भ में दिखाई नहीं देते।
- सामान्यतः, null फ़ील्ड, खाली set, और किसी फ़ील्ड की अनुपस्थिति को एक ही बात मानना सुरक्षित है
क्या आप यह और विस्तार से जानना चाहते हैं कि Native Enriched डेटा फ़ॉर्मैट, X API v2 फ़ॉर्मैट से कैसे मैप होता है? हमारी तुलना गाइड देखें: Native Enriched की X API v2 से तुलनाEnterprise data products का उपयोग करते समय, आप देखेंगे कि डेटा डिक्शनरी का बड़ा हिस्सा पोस्ट data के native format के समान है, जिसमें कुछ अतिरिक्त enriched metadata भी शामिल हैं। Native enriched format का base level X API v1.1 data format जैसे कई object names का उपयोग करता है। पोस्ट ऑब्जेक्ट में ‘root-level’ एट्रिब्यूट्स की एक लंबी सूची होती है, जिसमें
id, created_at, और text जैसे मूलभूत एट्रिब्यूट्स शामिल हैं। पोस्ट ऑब्जेक्ट्स में user, entities, और extended_entities को शामिल करने वाले nested objects भी होते हैं। पोस्ट ऑब्जेक्ट्स में retweeted_status, quoted_status, और extended_tweet जैसे अन्य nested पोस्ट objects भी होते हैं। Native enriched format में अतिरिक्त रूप से एक matching_rules object भी होता है।
X डेटा डिक्शनरी
अतिरिक्त पोस्ट एट्रिब्यूट्स
अप्रचलित एट्रिब्यूट
कई मामलों में, एक पोस्ट ऑब्जेक्ट में अन्य nested ऑब्जेक्ट्स शामिल होते हैं। यदि आप nested ऑब्जेक्ट्स के साथ काम कर रहे हैं, तो उस JSON payload में कई पोस्ट ऑब्जेक्ट्स होंगे, और हर पोस्ट ऑब्जेक्ट में अपने अलग ऑब्जेक्ट्स हो सकते हैं। Root-level ऑब्जेक्ट में की गई कार्रवाई के प्रकार की जानकारी होगी, यानी यह Retweet है या Quote Tweet, और इसमें वह ऑब्जेक्ट भी हो सकता है जो साझा की जा रही ‘original’ पोस्ट का वर्णन करता है। Extended Posts में एक nested extended ऑब्जेक्ट शामिल होता है, जो 140 characters से आगे तक की सामग्री को समेटता है; इसका उपयोग 2017 में अपडेट किए जाने पर breaking changes को रोकने के लिए किया गया था। हर nested object dictionary का वर्णन नीचे किया गया है।
Retweets
Retweets में हमेशा दो पोस्ट ऑब्जेक्ट्स होते हैं। Retweet की जा रही ‘original’ पोस्ट एक “retweeted_status” ऑब्जेक्ट में दी जाती है। Root-level ऑब्जेक्ट, Retweet को ही encapsulate करता है, जिसमें Retweet करने वाले account का User ऑब्जेक्ट और Retweet का समय शामिल होता है। Retweet करना, अपने followers के साथ किसी पोस्ट को साझा करने की एक कार्रवाई है, और इसमें कोई नई सामग्री नहीं जोड़ी जा सकती। साथ ही, किसी Retweet के साथ कोई (नई) location नहीं दी जा सकती। भले ही ‘original’ पोस्ट geo-tagged हो, Retweet के “geo” और “place” ऑब्जेक्ट्स हमेशा null होंगे।
Extended Posts की शुरुआत से पहले भी, root-level “entities” ऑब्जेक्ट कुछ मामलों में truncate हो जाता था और अधूरा रह जाता था, क्योंकि Retweet की जा रही पोस्ट के message में “RT @username ” string जोड़ दी जाती थी। ध्यान दें कि अगर किसी Retweet को फिर से Retweet किया जाता है, तो “retweet_status” फिर भी original पोस्ट की ओर ही संकेत करेगा, यानी बीच वाला Retweet शामिल नहीं होगा। ऐसा ही व्यवहार x.com का उपयोग करके किसी Retweet को ‘display’ करने पर भी देखा जाता है। अगर आप Retweet ‘action’ को दिया गया unique पोस्ट ID कॉपी करते हैं, तो original पोस्ट प्रदर्शित होती है।
नीचे Retweet के लिए एक example structure दिया गया है। फिर से, Retweets को parse करते समय, पूरा (original) पोस्ट message और entity metadata पाने के लिए “retweeted_status” ऑब्जेक्ट को parse करना महत्वपूर्ण है।
कोट ट्वीट्स
विस्तारित पोस्ट्स
अब समर्थित नहीं (deprecated) एट्रिब्यूट
place ऑब्जेक्ट हमेशा मौजूद रहता है। Places विशिष्ट, नामित स्थान होते हैं, जिनसे संबंधित geo coordinates जुड़े होते हैं। जब उपयोगकर्ता अपने पोस्ट को कोई स्थान असाइन करने का निर्णय लेते हैं, तो उन्हें संभावित X Places की एक सूची दिखाई जाती है। API का उपयोग करके पोस्ट करते समय, place_id निर्दिष्ट करके एक X Place अटैच किया जा सकता है। Places से संबद्ध पोस्ट्स का यह आवश्यक नहीं है कि वे उसी स्थान से जारी किए गए हों; वे उस स्थान के बारे में भी हो सकते हैं।
geo और coordinates ऑब्जेक्ट्स केवल तभी मौजूद (non-null) होते हैं, जब पोस्ट को एक सटीक स्थान असाइन किया गया हो। यदि एक सटीक स्थान प्रदान किया गया है, तो coordinates ऑब्जेक्ट भौगोलिक निर्देशांकों के साथ एक [long, lat] array प्रदान करेगा, और उस स्थान से संबंधित एक X Place असाइन किया जाएगा।
Coordinates ऑब्जेक्ट डेटा शब्दकोश
परिचय
एंटिटीज़, X पर पोस्ट की गई सामग्री के बारे में metadata और अतिरिक्त प्रासंगिक जानकारी प्रदान करते हैं।entities सेक्शन में पोस्ट्स में शामिल सामान्य तत्वों की arrays होती हैं: hashtags, user mentions, links, stock tickers (symbols), X polls, और संलग्न media। पोस्ट्स को ingest करते समय ये arrays developers के लिए सुविधाजनक होती हैं, क्योंकि X ने मूल रूप से text body को पहले ही process, या parse, कर दिया होता है। पोस्ट body में इन entities को अलग से खोजने की आवश्यकता के बजाय, आपका parser सीधे इस JSON सेक्शन में जा सकता है, और वे वहीं मिल जाती हैं।
Parsing को आसान बनाने के अलावा, entities सेक्शन उपयोगी ‘value-add’ metadata भी प्रदान करता है। उदाहरण के लिए, अगर आप Enhanced URLs enrichment का उपयोग कर रहे हैं, तो URL metadata में पूरी तरह expanded URLs के साथ-साथ संबंधित website titles और descriptions भी शामिल होते हैं। एक और उदाहरण यह है कि जब user mentions होते हैं, तो entities metadata में numeric user ID भी शामिल होती है, जो कई X APIs को requests करते समय उपयोगी होती है।
हर पोस्ट JSON payload में entities सेक्शन शामिल होता है, जिसमें कम-से-कम hashtags, urls, user_mentions, और symbols attributes का सेट होता है, भले ही इनमें से कोई भी entity पोस्ट message का हिस्सा न हो। उदाहरण के लिए, अगर आप “Hello World!” body वाली और बिना किसी संलग्न media की किसी पोस्ट का JSON देखते हैं, तो पोस्ट के JSON में निम्नलिखित सामग्री शामिल होगी, जिसमें entity arrays में शून्य items होंगे:
- media और polls एंटिटी केवल तभी दिखाई देंगी, जब उस प्रकार का कॉन्टेंट पोस्ट का हिस्सा हो।
- यदि आप native media (फ़ोटो, वीडियो या GIFs) के साथ काम कर रहे हैं, तो Extended एंटिटीज़ object का उपयोग करना बेहतर है।
entities और extended_entities सेक्शन, दोनों entity objects की arrays से मिलकर बने हैं। नीचे आपको इनमें से प्रत्येक entity object का विवरण मिलेगा, जिसमें data dictionaries भी शामिल हैं, जो object के attribute names, types, और संक्षिप्त विवरण बताती हैं। हम यह भी बताएँगे कि कौन से PowerTrack Operators इन attributes से मेल खाते हैं, और कुछ sample JSON payloads भी शामिल करेंगे।
पोस्ट्स में मिलने वाली सामान्य entities का एक संग्रह, जिसमें hashtags, links, और user mentions शामिल हैं। इस entities object में media attribute शामिल होता है, लेकिन entiites सेक्शन में इसका implementation केवल उन पोस्ट्स के लिए पूरी तरह सटीक है जिनमें एक ही photo हो। जिन सभी पोस्ट्स में एक से अधिक photo, video, या animated GIF हो, उनके लिए पाठक को extended_entities सेक्शन देखने का निर्देश दिया जाता है।
entities ऑब्जेक्ट, अन्य entity उप-ऑब्जेक्ट्स के arrays को रखने वाला एक कंटेनर है। entities संरचना, इन उप-ऑब्जेक्ट्स के डेटा शब्दकोश, और उनसे मेल खाने वाले Operators को समझाने के बाद, उन्हें प्रदान किया जाएगा।
entities सेक्शन में एक hashtags array होता है, जिसमें पोस्ट बॉडी में शामिल हर हैशटैग के लिए एक ऑब्जेक्ट होता है। अगर कोई हैशटैग मौजूद नहीं है, तो इसमें एक खाली array शामिल होता है।
PowerTrack # Operator का उपयोग text attribute पर match करने के लिए किया जाता है। has:hashtags Operator तब match करेगा, जब array में कम से कम एक item मौजूद हो।
यदि किसी मीडिया ऑब्जेक्ट को पोस्ट से ‘संलग्न’ किया गया है, तो
entities सेक्शन में एक media array होगा, जिसमें एक ही मीडिया ऑब्जेक्ट शामिल होगा। यदि कोई नेटिव मीडिया संलग्न नहीं किया गया है, तो entities में media array नहीं होगा। निम्न कारणों से पोस्ट के नेटिव मीडिया को प्रोसेस करने के लिए extended_entities सेक्शन का उपयोग किया जाना चाहिए:
- मीडिया
typeहमेशा ‘photo’ दिखाएगा, यहाँ तक कि उन मामलों में भी जहाँ पोस्ट के साथ वीडियो या GIF संलग्न हो। - हालांकि अधिकतम चार फ़ोटो संलग्न की जा सकती हैं,
entitiesसेक्शन में केवल पहली ही सूचीबद्ध होगी।
has:media Operator मैच करेगा।
नेटिव मीडिया (फ़ोटो, वीडियो और GIFs) वाले सभी पोस्ट्स में ऊँचाई और चौड़ाई के पिक्सेल आयामों के साथ ‘thumb’, ‘small’, ‘medium’ और ‘large’ आकारों का एक सेट शामिल होगा। फ़ोटो और प्रीव्यू इमेज मीडिया URLs के लिए, फ़ोटो मीडिया URL फ़ॉर्मैटिंग यह बताता है कि अलग-अलग आकार के फ़ोटो मीडिया लोड करने के लिए अलग-अलग URLs कैसे बनाए जाएँ।
X पर फ़ोटो मीडिया को अलग-अलग आकारों में लोड किया जा सकता है। किसी विशेष इमेज viewport में फ़िट होने के लिए, इतना बड़ा लेकिन यथासंभव सबसे छोटा चित्र लोड करना सबसे अच्छा रहता है। अलग-अलग आकार लोड करने के लिए, आकार ऑब्जेक्ट और media_url (या media_url_https) को एक विशेष फ़ॉर्मैट में संयोजित करना होता है। फ़ोटो मीडिया URL बनाने के उदाहरण के लिए, हम पहले से दिए गए media entity उदाहरण ऑब्जेक्ट का उपयोग करेंगे।
media_url या media_url_https को अपने-आप भी लोड किया जा सकता है, जिससे डिफ़ॉल्ट रूप से medium वैरिएंट लोड होता है। हालाँकि, जहाँ संभव हो, पूरी तरह फ़ॉर्मैट किया गया फ़ोटो मीडिया URL देना बेहतर है।
फ़ोटो मीडिया URL के तीन भाग होते हैं:
हम इन तीन भागों (base URL, format, और name) को मिलाकर लोड किया जाने वाला फ़ोटो मीडिया URL बनाते हैं। इस तरीके से इमेज लोड करने के 2 फ़ॉर्मैट हैं, legacy और modern। सभी इमेज लोड में legacy फ़ॉर्मैट का उपयोग बंद कर देना चाहिए और modern फ़ॉर्मैट का उपयोग करना चाहिए। modern फ़ॉर्मैट का उपयोग करने से कॉलर के लिए बेहतर CDN hit rate मिलता है, जिससे लोड latency बेहतर होती है, क्योंकि Data Center से मीडिया जनरेट और लोड करने की आवश्यकता पड़ने की संभावना कम हो जाती है।
entities सेक्शन में एक urls array होगा, जिसमें पोस्ट बॉडी में शामिल हर लिंक के लिए एक ऑब्जेक्ट होगा। अगर कोई लिंक मौजूद नहीं है, तो इसमें एक खाली array शामिल होगा।
अगर array में कम से कम एक आइटम है, तो has:links Operator मैच करेगा। url: Operator का उपयोग expanded_url attribute पर मैच करने के लिए किया जाता है। अगर आप Expanded URL enrichment का उपयोग कर रहे हैं, तो url: Operator का उपयोग unwound.url (पूरी तरह unwound URL) attribute पर मैच करने के लिए किया जाता है। अगर आप Exhanced URL enrichment का उपयोग कर रहे हैं, तो url_title: और url_decription: Operators का उपयोग unwound.title और unwound.description attributes पर मैच करने के लिए किया जाता है।
अगर आप Expanded और/या Enhanced URL enrichments का उपयोग कर रहे हैं, तो निम्न metadata
unwound attribute के अंतर्गत उपलब्ध है:
entities सेक्शन में एक user_mentions array होता है, जिसमें पोस्ट के मुख्य पाठ में शामिल प्रत्येक उपयोगकर्ता उल्लेख के लिए एक ऑब्जेक्ट शामिल होता है। यदि कोई उपयोगकर्ता उल्लेख मौजूद नहीं है, तो इसमें एक खाली array शामिल होता है।
PowerTrack @ Operator का उपयोग screen_name attribute पर मिलान करने के लिए किया जाता है। has:mentions Operator तब मिलान करेगा, जब array में कम-से-कम एक आइटम मौजूद हो।
entities सेक्शन में symbols array होता है, जिसमें पोस्ट बॉडी में शामिल हर $cashtag के लिए एक ऑब्जेक्ट शामिल होता है। अगर कोई symbol मौजूद न हो, तो इसमें एक खाली array शामिल होगा।
PowerTrack $ Operator का उपयोग text attribute पर match करने के लिए किया जाता है। has:symbols Operator तब match करेगा, जब array में कम-से-कम एक item मौजूद हो।
अगर पोस्ट में पोल शामिल है, तो
entities सेक्शन में polls array होगा, जिसमें एक poll ऑब्जेक्ट शामिल होगा। अगर पोल शामिल नहीं है, तो entities सेक्शन में polls array नहीं होगा।
ध्यान दें कि यह पोल मेटाडेटा केवल निम्नलिखित Enterprise APIs के साथ उपलब्ध है:
- Volume streams (Decahose )
- Real-time PowerTrack
- X Search APIs (Full-Archive Search और 30-Day Search)
X API के दृष्टिकोण से, Retweet और Quote Tweet पोस्ट्स के विशेष प्रकार हैं, जिनमें मूल पोस्ट एक एम्बेडेड ऑब्जेक्ट के रूप में शामिल होता है। इसलिए Retweet और Quote Tweet ऑब्जेक्ट्स में एक चाइल्ड ‘original’ पोस्ट होता है (और इस वजह से उनका आकार दोगुना हो जाता है)। रीट्वीट में टॉप-लेवल “retweeted_status” ऑब्जेक्ट होता है, और Quote Tweets में “quoted_status” ऑब्जेक्ट होता है। एकरूपता बनाए रखने के लिए, इन टॉप-लेवल Retweet और Quote Tweet ऑब्जेक्ट्स में भी एक text प्रॉपर्टी और उससे संबंधित entities होती हैं। हालांकि, टॉप-लेवल पर मौजूद entities, एम्बेडेड ‘original’ entities से अलग हो सकती हैं। रीट्वीट के मामले में, मूल पोस्ट बॉडी के पहले नया टेक्स्ट जोड़ा जाता है। Quoted Posts के मामले में, नया टेक्स्ट पोस्ट बॉडी के अंत में जोड़ा जाता है।
सामान्य तौर पर, सर्वोत्तम अभ्यास यह है कि जब भी retweeted_status मौजूद हो, तब टेक्स्ट, entities, मूल लेखक और तारीख उसी में मौजूद मूल पोस्ट से प्राप्त किए जाएँ। इसका एक अपवाद उन X entities का है जो अतिरिक्त Quote का हिस्सा होती हैं। अधिक जानकारी और सुझावों के लिए नीचे देखें।
रीट्वीट्स के बारे में एक महत्वपूर्ण बात यह है कि पोस्ट में कोई अतिरिक्त X entities नहीं जोड़ी जा सकतीं। उपयोगकर्ता रीट्वीट करते समय हैशटैग, URL या अन्य विवरण नहीं जोड़ सकते। हालांकि, रीट्वीट का (टॉप-लेवल) text attribute मूल पोस्ट के टेक्स्ट से बनता है, जिसके आगे “RT @username: ” जोड़ा जाता है।
कुछ मामलों में, खासकर लंबे उपयोगकर्ता नाम वाले खातों में, इन नए अक्षरों और मूल पोस्ट बॉडी का संयोजन आसानी से 140 अक्षरों की मूल पोस्ट टेक्स्ट-लंबाई सीमा से अधिक हो सकता है। 140-अक्षर आधारित प्रदर्शन और संग्रहण के समर्थन को बनाए रखने के लिए, टॉप-लेवल बॉडी पोस्ट बॉडी के अंत को ट्रंकेट कर देती है और एक एलिप्सिस (“…”) जोड़ देती है। नतीजतन, मूल पोस्ट के अंत में स्थित कुछ टॉप-लेवल entities गलत हो सकती हैं या गायब हो सकती हैं, उदाहरण के लिए किसी ट्रंकेट किए गए हैशटैग या URL entry के मामले में।
यह पोस्ट, https://x.com/FloodSocial/status/907974220298125312, का पोस्ट टेक्स्ट इस प्रकार है:
बस एक और टेस्ट पोस्ट, जिसे ठीक 140 अक्षरों का होना चाहिए, और जिसके अंत में URL तथा हैशटैग हो












http://wapo.st/2w8iwPQ #Testing
ऊपर दिए गए उदाहरण में, URL और हैशटैग दोनों प्रभावित हुए थे। चूंकि हैशटैग पूरी तरह ट्रंकेट हो गया था और URL आंशिक रूप से ट्रंकेट हुआ था, इसलिए ये टॉप-लेवल entities में मौजूद नहीं हैं। आप text field पर “RT @floodsocial: ” prefix से आने वाली अतिरिक्त user_mentions टॉप-लेवल entity को भी देखेंगे।
हालांकि, retweeted_status में पोस्ट का टेक्स्ट और entities मूल पोस्ट को बिना किसी truncation या गलत entities के पूरी तरह दर्शाते हैं, इसलिए हमारी सिफारिश है कि रीट्वीट्स के लिए nested _retweeted_status _object पर भरोसा करें।
Quote Tweets
Quote Tweets को 2016 में पेश किया गया था, और ये Retweets से इस मायने में अलग हैं कि जब आप किसी पोस्ट को “quote” करते हैं, तो आप साझा किए गए पोस्ट के “ऊपर” नई सामग्री जोड़ते हैं। इस नई सामग्री में लगभग वह सब कुछ शामिल हो सकता है जो किसी मूल पोस्ट में हो सकता है, जैसे नया टेक्स्ट, हैशटैग, मेंशन और URL। Quote Tweets में मूल मीडिया (फ़ोटो, वीडियो और GIFs) शामिल हो सकते हैं, और वे entities object के अंतर्गत दिखाई देंगे। चूंकि X entities जोड़ी जा सकती हैं, इसलिए Quote entities मूल entities से अलग होने की संभावना है। इस उदाहरण में, Quote Tweet के अंत में एक नया 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, Quote के विवरण नहीं दर्शाती हैं। हालांकि, extended_tweet में पोस्ट text और entities, Quote Tweet को बिना किसी truncation या गलत entities के पूरी तरह दर्शाते हैं, इसलिए हमारी अनुशंसा है कि Quote Tweets के लिए nested _extended_tweet _object पर भरोसा करें। User Objects के लिए एंटिटीज़ उन URLs का वर्णन करती हैं जो उपयोगकर्ता-परिभाषित प्रोफ़ाइल URL और description फ़ील्ड्स में दिखाई देते हैं। वे hashtags या user_mentions का वर्णन नहीं करती हैं। Post एंटिटीज़ के विपरीत, उपयोगकर्ता एंटिटीज़ अपने पैरेंट ऑब्जेक्ट के भीतर कई फ़ील्ड्स पर लागू हो सकती हैं — इस अस्पष्टता को दूर करने के लिए, आपको url और description नाम के पैरेंट नोड्स मिलेंगे, जो यह बताते हैं कि किस फ़ील्ड में एंटिटाइज़ किया गया URL मौजूद है। इस उदाहरण में, उपयोगकर्ता के url फ़ील्ड में एक t.co लिंक है, जो रिस्पॉन्स के entities/url/urls[0] नोड में पूरी तरह expanded रूप में मौजूद है। उपयोगकर्ता के description में कोई wrapped URL नहीं है।extended_entities JSON ऑब्जेक्ट शामिल होगा। extended_entities ऑब्जेक्ट में media ऑब्जेक्ट्स का एक media ऐरे होता है (इसके डेटा शब्दकोश के लिए entities सेक्शन देखें)। extended_entities सेक्शन में hashtags और links जैसे अन्य किसी भी entity प्रकार को शामिल नहीं किया जाता। extended_entities सेक्शन में मौजूद media ऑब्जेक्ट, संरचना के हिसाब से entities सेक्शन में शामिल media ऑब्जेक्ट के समान है।
पोस्ट्स के साथ केवल एक ही प्रकार का मीडिया संलग्न किया जा सकता है। फ़ोटो के लिए अधिकतम चार फ़ोटो संलग्न की जा सकती हैं। वीडियो और GIFs के लिए, केवल एक संलग्न किया जा सकता है। चूँकि extended_entities सेक्शन में मीडिया type मेटाडेटा मीडिया प्रकार (‘photo’, ‘video’ या ‘animated_gif’) को सही रूप से दर्शाता है, और अधिकतम 4 फ़ोटो का समर्थन करता है, इसलिए यह नेटिव मीडिया के लिए पसंदीदा मेटाडेटा स्रोत है।
इस पोस्ट का
entities अनुभाग यहाँ दिया गया है:
extented_entities सेक्शन दिया गया है:
video_info ऑब्जेक्ट को additional_media_info ऑब्जेक्ट से बदल दिया जाएगा।
additional_media_info में प्रकाशक द्वारा दी गई अतिरिक्त मीडिया जानकारी होगी, जैसे title, description और embeddable flag। जब embeddable=false होता है, तो वीडियो सामग्री केवल X के आधिकारिक क्लाइंट्स पर उपलब्ध होती है। इस स्थिति में, payload में दिए गए सभी वीडियो URL X-आधारित होंगे, ताकि उपयोगकर्ता लिंक पर क्लिक करके वीडियो को X के स्वामित्व वाले प्लेटफ़ॉर्म पर खोल सके।
यहाँ एक उदाहरण दिया गया है कि इस स्थिति में विस्तारित एंटिटीज़ ऑब्जेक्ट कैसा दिखेगा:
entities अनुभाग है, जिसमें type ग़लती से ‘photo’ पर सेट है। फिर भी, ‘video’ और ‘animated_gif’ सहित सभी मूल मीडिया प्रकारों के लिए extended_entities अनुभाग को प्राथमिकता दी जाती है।
नीचे एक एनिमेटेड GIF वाले इस पोस्ट के लिए विस्तारित एंटिटीज़ metadata दिया गया है:
क्या आप यह जानना चाहते हैं कि Activity Streams डेटा फ़ॉर्मैट, X API v2 फ़ॉर्मैट से कैसे मैप होता है?
कृपया ध्यान दें: enterprise data APIs के लिए Enriched Native फ़ॉर्मैट का उपयोग करने की कड़ी अनुशंसा की जाती है।
- Enriched Native फ़ॉर्मैट में 2017 से जोड़ा गया सारा नया मेटाडेटा शामिल है, जैसे poll metadata, और reply_count तथा quote_count जैसे अतिरिक्त मेट्रिक्स।
- Activity Streams फ़ॉर्मैट को 2017 के character update के बाद से नए मेटाडेटा या enrichments के साथ अपडेट नहीं किया गया है।
अतिरिक्त पोस्ट विशेषताएँ
अप्रचलित विशेषताएँ
कई मामलों में, किसी पोस्ट ऑब्जेक्ट में अन्य नेस्टेड पोस्ट्स शामिल होते हैं। यदि आप नेस्टेड ऑब्जेक्ट्स के साथ काम कर रहे हैं, तो उस JSON payload में कई ऑब्जेक्ट्स होंगे, और प्रत्येक पोस्ट ऑब्जेक्ट में अपने ऑब्जेक्ट्स भी हो सकते हैं। रूट-लेवल ऑब्जेक्ट में की गई कार्रवाई के type की जानकारी होगी, यानी यह रीट्वीट है या Quote Tweet, और इसमें साझा की जा रही ‘original’ पोस्ट का वर्णन करने वाला एक ऑब्जेक्ट भी हो सकता है। Extended Posts में एक नेस्टेड extended ऑब्जेक्ट शामिल होगा, जो 140 वर्णों से अधिक सामग्री को समाहित करता है; इसका उपयोग 2017 में अपडेट किए जाने पर breaking changes को रोकने के लिए किया गया था। प्रत्येक नेस्टेड ऑब्जेक्ट dictionary का वर्णन नीचे किया गया है।
रीट्वीट्स
रीट्वीट्स के Activity Streams प्रारूप में type “activity” और verb “note” वाला एक नेस्टेड ऑब्जेक्ट शामिल होता है, जो रीट्वीट की जा रही मूल पोस्ट को दर्शाता है।
{ "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": {} } }
रीट्वीट किया गया Quote Tweet:
उदाहरण
gnip ऑब्जेक्ट में सक्रिय enrichments द्वारा जोड़ा गया metadata होता है, साथ ही activity के लिए लागू matching rules का संकेत भी शामिल होता है।
long_object सहित पोस्ट गतिविधि
twitter_extended_entities सहित पोस्ट गतिविधि
परिचय**
मूल रूप से, X एक सार्वजनिक, रीयल-टाइम और वैश्विक संचार नेटवर्क है। 2006 से, X का विकास उपयोगकर्ताओं के इस्तेमाल के पैटर्न और प्रचलनों, साथ ही नए प्रोडक्ट फीचर्स और सुधारों, दोनों से प्रेरित रहा है। यदि आप ऐतिहासिक शोध के लिए X डेटा का उपयोग कर रहे हैं, तो इस विकास-क्रम की समयरेखा को समझना डेटा आर्काइव से रुचिकर पोस्ट्स खोजने के लिए महत्वपूर्ण है। X की शुरुआत एक सरल SMS मोबाइल ऐप के रूप में हुई थी, और समय के साथ यह एक व्यापक संचार प्लेटफ़ॉर्म बन गया। ऐसा प्लेटफ़ॉर्म जिसमें APIs का पूरा सेट उपलब्ध है। APIs हमेशा से X नेटवर्क का एक प्रमुख स्तंभ रही हैं। पहली API, X के लॉन्च होने के तुरंत बाद ही सार्वजनिक कर दी गई थी। जब 2009 में पहली बार पोस्ट्स में geo-tagging पेश की गई, तो इसे एक Geo API के माध्यम से उपलब्ध कराया गया (और बाद में किसी पोस्ट को ‘geo-tag’ करने की सुविधा X.com user-interface में एकीकृत कर दी गई)। आज, X की APIs उस दो-तरफ़ा संचार नेटवर्क को शक्ति देती हैं, जो ब्रेकिंग समाचार और जानकारी साझा करने का एक प्रमुख स्रोत बन चुका है। इस वैश्विक, रीयल-टाइम संचार चैनल के ऊपर निर्माण करने की संभावनाएँ अनंत हैं। X दो ऐतिहासिक APIs उपलब्ध कराता है जो सार्वजनिक रूप से उपलब्ध हर पोस्ट तक पहुँच प्रदान करती हैं: Historical PowerTrack और Full-Archive Search API। दोनों APIs operators का एक सेट उपलब्ध कराती हैं, जिनका उपयोग रुचिकर पोस्ट्स को query करने और एकत्र करने के लिए किया जाता है। ये operators हर पोस्ट से जुड़े कई तरह के attributes पर match करते हैं—ऐसे सैकड़ों attributes पर, जैसे पोस्ट का text content, author का account name, और पोस्ट में साझा किए गए links। पोस्ट्स और उनके attributes को JSON में encode किया जाता है, जो text-based data interchange का एक सामान्य format है। इसलिए, जैसे-जैसे नए फीचर्स जोड़े गए, नए JSON attributes भी सामने आए, और आम तौर पर उन attributes पर match करने के लिए नए API operators भी पेश किए गए। यदि आपके use-case में X पर दुनिया ने क्या कहा है, इसे सुनने की आवश्यकता शामिल है, तो आप जितना बेहतर यह समझेंगे कि operators के लिए match करने योग्य JSON metadata कब उपलब्ध होना शुरू हुआ, आपके historical PowerTrack filters उतने ही अधिक प्रभावी होंगे। अब, हम कुछ प्रमुख अवधारणाओं का परिचय देंगे, जो यह समझने की पृष्ठभूमि तैयार करती हैं कि पोस्ट metadata में हुए updates आपकी रुचि के data signal को खोजने को कैसे प्रभावित करते हैं।मुख्य अवधारणाएँ**
X उपयोगकर्ताओं ने स्वाभाविक रूप से X नेटवर्क पर संचार के नए पैटर्न विकसित किए, जो अब बुनियादी बन चुके हैं। इसका एक प्रमुख उदाहरण है हैशटैग, जिसका अब लगभग सभी सोशल नेटवर्क्स पर व्यापक रूप से उपयोग होता है। हैशटैग बातचीतों और विषयों को व्यवस्थित करने के एक तरीके के रूप में सामने आए। ऐसे नेटवर्क पर जहाँ हर दिन सैकड़ों मिलियन संदेश होते हैं, रुचिकर पोस्ट्स खोजने के लिए टूल्स बहुत महत्वपूर्ण होते हैं, और हैशटैग एक बुनियादी तरीका बन गए। जल्द ही, जैसे-जैसे हैशटैग का उपयोग बढ़ा, उन्हें X से आधिकारिक मान्यता और समर्थन भी मिल गया। जब हैशटैग एक ‘फर्स्ट-क्लास’ ऑब्जेक्ट बन गए, तो इसका कई स्तरों पर असर पड़ा। इसका मतलब था कि X.com उपयोगकर्ता इंटरफ़ेस में हैशटैग क्लिक करने योग्य और खोजने योग्य हो गए। इसका यह भी मतलब था कि हैशटैग, @mentions, संलग्न मीडिया, स्टॉक सिंबल्स, और साझा लिंक के साथ X entities परिवार का हिस्सा बन गए। इन entities को सुविधाजनक रूप से पहले से पार्स किए गए JSON array में encode किया जाता है, जिससे डेवलपर्स के लिए उन्हें process, scan, और store करना आसान हो जाता है। रीट्वीट, उपयोगकर्ता-आधारित परंपराओं के आधिकारिक ऑब्जेक्ट्स में बदलने का एक और उदाहरण हैं। Retweeting, सामग्री को दूसरों तक ‘forward’ करने के एक तरीके के रूप में उभरा। इसकी शुरुआत किसी पोस्ट को मैन्युअली copy/paste करके और उसके आगे “RT @” pattern जोड़ने से हुई। बाद में इस प्रक्रिया को एक नए रीट्वीट button के ज़रिए automated कर दिया गया, जो नए JSON metadata के साथ आया। इसी तरह ‘आधिकारिक’ रीट्वीट का जन्म हुआ। अन्य उदाहरणों में ‘mentions’, media और web links साझा करना, और अपनी पोस्ट के साथ location साझा करना शामिल हैं। इन प्रत्येक उपयोग-पैटर्न के परिणामस्वरूप x.com पर नए उपयोगकर्ता-इंटरफ़ेस features, नया supporting JSON, और इस तरह पोस्ट्स पर match करने के नए तरीके सामने आए। पोस्ट के इन सभी बुनियादी attributes के आधार पर match करने के लिए PowerTrack Operators विकसित किए गए। हालाँकि पोस्ट संदेशों की लंबाई वर्णों की एक निश्चित सीमा तक हो सकती है, किसी पोस्ट का JSON विवरण 100 से अधिक एट्रिब्यूट्स से मिलकर बना होता है। इनमें यह जानकारी शामिल होती है कि पोस्ट किसने किया, किस समय किया, क्या यह एक मूल पोस्ट है या रीट्वीट, और हैशटैग, मेंशन्स, तथा साझा किए गए लिंक जैसे प्रथम-श्रेणी ऑब्जेक्ट्स की एक सरणी। पोस्ट करने वाले खाते के लिए एक User (या Actor) ऑब्जेक्ट होता है, जिसमें कई एट्रिब्यूट्स होते हैं जो उपयोगकर्ता की Profile और खाते से जुड़े अन्य मेटाडेटा प्रदान करते हैं। प्रोफ़ाइल में एक संक्षिप्त जीवनी-विवरण, home location (मुक्त-रूप टेक्स्ट), पसंदीदा भाषा, और एक वैकल्पिक वेबसाइट लिंक शामिल होते हैं। कुछ खाता मेटाडेटा कभी नहीं बदलते (उदा. संख्यात्मक user ID और created date), कुछ समय के साथ धीरे-धीरे बदलते हैं, जबकि अन्य एट्रिब्यूट्स अधिक बार बदलते हैं। लोग नौकरी बदलते हैं और स्थानांतरित होते हैं। कंपनियाँ अपनी जानकारी अपडेट करती हैं। जब आप ऐतिहासिक पोस्ट्स एकत्र कर रहे हों, तो यह समझना महत्वपूर्ण है कि कुछ मेटाडेटा पोस्ट किए जाने के समय जैसा था, जबकि अन्य मेटाडेटा क्वेरी सबमिट किए जाने के समय जैसा होता है। सभी ऐतिहासिक APIs में, उपयोगकर्ता की प्रोफ़ाइल विवरण, डिस्प्ले नेम, और प्रोफ़ाइल ‘home’ एट्रिब्यूट्स क्वेरी के समय के मानों के अनुसार अपडेट हो जाते हैं। X.com और X के मोबाइल ऐप्स में, एक बटन पर क्लिक करके और अपनी फ़ोटो गैलरी ब्राउज़ करके पोस्ट में फ़ोटो और वीडियो जोड़े जा सकते हैं। अब जब इन्हें मूलभूत कार्रवाइयों के रूप में एकीकृत कर दिया गया है, तो इस तरह साझा किए गए वीडियो और फ़ोटो को ‘नेटिव’ मीडिया कहा जाता है। कई क्वेरी Operators इन ‘नेटिव’ संसाधनों के साथ काम करते हैं, जिनमेंhas:videos, has:images, और has:media शामिल हैं। ये केवल उस मीडिया सामग्री से मेल खाते हैं जिसे X की सुविधाओं के माध्यम से साझा किया गया हो। X प्लेटफ़ॉर्म के बाहर होस्ट किए गए अन्य मीडिया से मिलान करने के लिए, आपको ऐसे Operators का उपयोग करना होगा जो URL metadata पर मिलान करते हैं।
इसलिए, Historical PowerTrack और Full-Archive Search के उत्पाद विवरणों में जाने से पहले, आइए देखें कि X एक उत्पाद और प्लेटफ़ॉर्म के रूप में समय के साथ कैसे विकसित हुआ।
X समयरेखा
नीचे आपको X की एक चुनी हुई समयरेखा मिलेगी। इनमें से अधिकांश X अपडेट्स ने किसी न किसी रूप में उपयोगकर्ता व्यवहार, पोस्ट JSON सामग्री, क्वेरी Operators, या इन तीनों को मूल रूप से प्रभावित किया। API प्लेटफ़ॉर्म के रूप में X को देखें, तो निम्नलिखित घटनाओं ने किसी न किसी तरह उन JSON payloads को प्रभावित किया जिनका उपयोग पोस्ट्स को encode करने के लिए किया जाता है। बदले में, यही JSON विवरण इस बात को प्रभावित करते हैं कि X के historical APIs उनका मिलान कैसे करते हैं।
ध्यान दें कि यह समयरेखा सामान्यतः सटीक है, लेकिन संपूर्ण नहीं है।
- अक्टूबर
- @replies एक प्रचलित परंपरा बन जाता है।
- Cashtags जून 2012 में क्लिक किए जा सकने वाले/खोजे जा सकने वाले लिंक बन गए।
- नवंबर - Favorites पेश किए गए।
- जनवरी -
in_reply_toमेटाडेटा और UI reply button के साथ @replies एक प्रथम-श्रेणी ऑब्जेक्ट बन जाते हैं। - अप्रैल - रीट्वीट एक प्रचलित परंपरा बन जाते हैं।
- अगस्त - #hashtags पोस्ट्स को खोजने और व्यवस्थित करने के लिए एक प्रमुख साधन के रूप में उभरते हैं।
- फ़रवरी - स्टॉक टिकर प्रतीकों पर चर्चा के लिए
$cashtagsएक आम प्रचलन बन गए। - मई - पोस्ट बॉडी के आगे “Via @” जोड़कर रीट्वीट ‘beta’ पेश किया गया।
- जून - सत्यापित खाते शुरू किए गए।
- अगस्त - “RT @” पैटर्न और नए
retweet_statusमेटाडेटा के साथ रीट्वीट एक प्रथम-श्रेणी ऑब्जेक्ट बन गए। - अक्टूबर - सूची सुविधा लॉन्च की गई।
- नवंबर - Post Geotagging API लॉन्च किया गया, जिससे उपयोगकर्ताओं को तृतीय-पक्ष ऐप्स के ज़रिए स्थान साझा करने का पहला तरीका मिला।
- जून - पोस्ट्स की जियो-टैगिंग के लिए X Places पेश किया गया।
- अगस्त - वेबसाइटों के लिए पोस्ट बटन लॉन्च किया गया। इससे लिंक शेयर करना आसान हो गया।
- मई - Follow बटन पेश किया गया, जिससे वेबसाइटों से जुड़े अकाउंट्स को फ़ॉलो करना आसान हो गया।
- अगस्त - नेटिव फ़ोटो पेश की गईं।
- जून - $Cashtags क्लिक करने और खोजने योग्य लिंक बन जाते हैं।
- मार्च - फ़ोटो टैगिंग और अधिकतम चार फ़ोटो का समर्थन. Extended X Entities मेटाडेटा पेश किया गया।
- अप्रैल - X UI में इमोजी के लिए मूल समर्थन जोड़ा गया। कम से कम 2008 से पोस्ट्स में इमोजी का व्यापक रूप से उपयोग होता रहा है।
- अप्रैल - X के ‘पोस्ट’ यूज़र-इंटरफ़ेस डिज़ाइन में बदलाव के कारण कम पोस्ट्स जियो-टैग की गईं।
- अक्टूबर - X Polls पेश किए गए. शुरुआत में, Polls में 24 घंटे की मतदान अवधि के साथ दो विकल्प समर्थित थे। नवंबर में, Polls ने 5 मिनट से सात दिनों तक की मतदान अवधि के साथ चार विकल्पों का समर्थन करना शुरू किया। Poll metadata फ़रवरी 2017 में उपलब्ध कराया गया (केवल enriched native format में)।
- फ़रवरी - पोस्ट कंपोज़र में नेटिव तौर पर होस्ट किए गए खोजने योग्य GIFs.
- मई - “140 के साथ और अधिक” (dmw140) की घोषणा की गई, जिसमें पोस्ट के 140-वर्णीय संदेश के संदर्भ में रिप्लाई और संलग्न मीडिया को संभालने के नए तरीकों की योजनाएँ बताई गईं।
- जून - नेटिव वीडियो समर्थन
- जून - कोटेड रीट्वीट सामान्य रूप से उपलब्ध हुए।
- जून - फ़ोटो में जोड़ने के लिए स्टिकर्स पेश किए गए.
- सितंबर - ‘नेटिव अटैचमेंट्स’ पेश किए गए, जिनमें अंत में आने वाला URL 140 वर्णों में नहीं गिना जाता था (“dmw140, भाग 1”).
- फ़रवरी - पोस्ट मेटाडेटा में X Poll मेटाडेटा शामिल किया गया (केवल enriched native format में)।
- अप्रैल - ‘Simplified Replies’ पेश किया गया, जिसमें replied-to-accounts को 140 अक्षरों की सीमा में नहीं गिना जाता था (“dmw140, part 2”)।
- मई - GDPR updates user.time_zone को null पर सेट किया गया, user.utc_offset को null पर सेट किया गया, user.profile_background_image_url को default value पर सेट किया गया
- जून - quoteTweet formatting changes के फ़ॉर्मैटिंग बदलावों को अपडेट करना
- 29 सितंबर - पोस्ट्स को संपादित करने की सुविधा एक छोटे परीक्षण समूह के लिए जारी की गई। जहाँ प्रासंगिक हो, संपादित पोस्ट मेटाडेटा को पोस्ट ऑब्जेक्ट में जोड़ा गया। इसमें edit_history और edit_controls ऑब्जेक्ट्स शामिल हैं। यह मेटाडेटा उन पोस्ट्स के लिए वापस नहीं किया जाएगा जो editable functionality जोड़े जाने से पहले बनाए गए थे। इन मेटाडेटा के लिए कोई संबंधित Operators नहीं हैं। पोस्ट संपादन कैसे काम करता है, इसके बारे में अधिक जानने के लिए Edit Posts fundamentals देखें
lang: Operator है, जिसका उपयोग किसी निर्दिष्ट भाषा में पोस्ट्स का मिलान करने के लिए किया जाता है। X एक language classification service प्रदान करता है (जो 50 से अधिक भाषाओं का समर्थन करती है), और X APIs हर पोस्ट के लिए जनरेट किए गए JSON में यह मेटाडेटा उपलब्ध कराते हैं। इसलिए, यदि कोई पोस्ट Spanish में लिखी गई है, तो “lang” JSON attribute को “es” पर सेट किया जाता है। इसलिए, यदि आप lang:es clause के साथ एक filter बनाते हैं, तो वह केवल उन पोस्ट संदेशों से मेल खाएगा जिन्हें Spanish के रूप में वर्गीकृत किया गया है।
यह समयरेखा जानकारी प्राप्त पोस्ट डेटा की बेहतर व्याख्या करने में भी मदद कर सकती है। मान लीजिए आप 2008 और 2012 Summer Olympics के बारे में सामग्री साझा किए जाने का अध्ययन कर रहे थे। यदि आप केवल is:retweet Operator लागू करते, तो 2008 में कोई डेटा मेल नहीं खाता। हालांकि, 2012 के लिए संभवतः लाखों रीट्वीट होते। इससे आप संभावित रूप से गलत निष्कर्ष निकाल सकते थे कि 2008 में रीट्वीट उपयोगकर्ताओं की प्रचलित पद्धति नहीं थे, या बस किसी ने उन Olympics के बारे में Retweet नहीं किया। चूँकि रीट्वीट 2009 में first-class object बन गए, इसलिए 2008 में उनकी पहचान करने में मदद के लिए आपको ”RT @” rule clause जोड़ना होगा।
रीट्वीट और पोस्ट language classification, दोनों ही पोस्ट attributes के उदाहरण हैं जिनका लंबा इतिहास है और जिनसे जुड़ी कई product details हैं। नीचे हम इनके साथ-साथ अन्य attribute classes के बारे में भी अधिक विस्तार से चर्चा करेंगे, जो X Data का मिलान करने और उसे समझने के लिए महत्वपूर्ण हैं।
फ़िल्टर लिखते समय एक महत्वपूर्ण बात यह समझना है कि जिन metadata पर Operators match करते हैं, उन सभी की “born on” तारीखें होती हैं। अगर आप किसी ऐसे Operator के साथ फ़िल्टर बनाते हैं जो उस metadata पर काम करता है जिसे पोस्ट किए जाने के बाद जोड़ा गया था, तो false negative मिलेगा। उदाहरण के लिए, मान लें कि आप उन सभी पोस्ट्स में रुचि रखते हैं जिनमें ‘snow’ का उल्लेख हो और जिनमें कोई वीडियो साझा किया गया हो। अगर आप has:videos Operator के साथ एक rule बनाते हैं, जो native वीडियो वाले पोस्ट्स पर match करता है, तो वह clause 2015 से पहले के किसी भी पोस्ट्स पर match नहीं करेगा।
हालाँकि, X पर वीडियो साझा करना 2015 से बहुत पहले से आम था। उससे पहले, उपयोगकर्ता कहीं और host किए गए वीडियो के links साझा करते थे, लेकिन 2015 में X ने वीडियो शेयरिंग की नई सुविधाएँ सीधे platform में जोड़ दीं। अपनी रुचि के इन पुराने पोस्ट्स को खोजने के लिए, आप url:”youtube.com” जैसा कोई rule clause शामिल कर सकते हैं।
ध्यान दें, Search APIs में metadata के ‘backfilled’ होने के कुछ उदाहरण हैं, जब उसका index फिर से बनाया गया। इसका एक अच्छा उदाहरण cashtag operator शुरू होने के बाद Search index फिर से बनाया गया, और इस प्रक्रिया में 2006 की शुरुआती Post bodies सहित सभी Post bodies से symbol entity निकाली गई, जबकि उस समय $ का उपयोग मुख्य रूप से slang के लिए होता था; “I hope it $oon!”.
कुछ मेटाडेटा, जैसे X खाते की संख्यात्मक ID, शुरू से ही मौजूद रहे हैं (और ऐसे खाता मेटाडेटा का उदाहरण हैं जो कभी नहीं बदलते)। अन्य मेटाडेटा 2006 में X की शुरुआत के काफी समय बाद जोड़े गए। नए मेटाडेटा के उदाहरणों में Retweets मेटाडेटा, पोस्ट लोकेशन, URL शीर्षक और विवरण, तथा ‘native’ मीडिया शामिल हैं। नीचे पोस्ट विशेषताओं के कुछ सबसे सामान्य प्रकार दिए गए हैं, जो X प्लेटफ़ॉर्म के इन अपडेट से बुनियादी रूप से प्रभावित हुए हैं।
इनके लिए फ़िल्टरिंग/मैचिंग व्यवहार, अधिकांश मामलों में, इस बात पर निर्भर करता है कि कौन-सा ऐतिहासिक Post API इस्तेमाल किया जाता है। यह तय करने में मदद के लिए कि आपके शोध और उपयोग-प्रकरण के लिए कौन-सा उत्पाद सबसे उपयुक्त है, नीचे दिए गए विशेषता-विवरणों में उच्च-स्तरीय उत्पाद जानकारी शामिल है।
चूंकि X मूल रूप से एक वैश्विक, रीयल-टाइम संचार चैनल है, इसलिए पोस्ट डेटा पर शोध में अक्सर इस बात पर ज़ोर होता है कि संवाद कौन कर रहा है। अक्सर यह जानना उपयोगी होता है कि कोई X उपयोगकर्ता किस स्थान को अपना घर बताता है। कई बार किसी खाते की बायो में रुचियों और शौकों का उल्लेख आपको दिलचस्प पोस्ट्स तक पहुँचा सकता है। रुचि वाले खातों से आने वाली पोस्ट्स पर नज़र रखना भी बहुत आम है। इन सभी उपयोग-मामलों में प्रोफ़ाइल विशेषताएँ अहम होती हैं।
X पर हर खाते की एक प्रोफ़ाइल होती है, जिसमें X @handle, डिस्प्ले नाम, एक छोटी बायो, गृह स्थान (उपयोगकर्ता द्वारा दर्ज किया गया मुक्त-रूप पाठ), फ़ॉलोअर्स की संख्या और कई अन्य प्रकार का मेटाडेटा शामिल होता है। कुछ विशेषताएँ कभी नहीं बदलतीं, जैसे संख्यात्मक उपयोगकर्ता ID और खाता कब बनाया गया था। अन्य विशेषताएँ आमतौर पर दिन-प्रतिदिन, सप्ताह-दर-सप्ताह, या महीने-दर-महीने बदलती रहती हैं, जैसे किए गए पोस्ट्स की संख्या, फ़ॉलो किए जा रहे खातों की संख्या, और फ़ॉलोअर्स की संख्या। खाते की कुछ अन्य विशेषताएँ भी किसी भी समय बदल सकती हैं, लेकिन वे अपेक्षाकृत कम बार बदलती हैं: डिस्प्ले नाम, गृह स्थान, और बायो।
हर पोस्ट के JSON payload में पोस्ट के लेखक का खाता प्रोफ़ाइल मेटाडेटा शामिल होता है। यदि वह एक Retweet है, तो उसमें उस खाते का प्रोफ़ाइल मेटाडेटा भी शामिल होता है जिसने मूल पोस्ट किया था।
किसी पोस्ट के प्रोफ़ाइल मेटाडेटा की परिवर्तनशीलता पूरी तरह इस बात पर निर्भर करती है कि कौन-सा ऐतिहासिक प्रोडक्ट उपयोग किया गया है। Search APIs ऐतिहासिक पोस्ट्स को पुनर्प्राप्ति के समय जैसी प्रोफ़ाइल सेटिंग्स होती हैं उनके साथ प्रस्तुत करती हैं। Historical PowerTrack में, प्रोफ़ाइल वैसी होती है जैसी पोस्ट किए जाने के समय थी, सिवाय 2011 से पहले के डेटा के। 2011 से पुरानी पोस्ट्स के लिए, प्रोफ़ाइल मेटाडेटा सितंबर 2011 की प्रोफ़ाइल स्थिति को दर्शाता है।
रीट्वीट इस बात का एक और उदाहरण हैं कि कैसे उपयोगकर्ताओं द्वारा अपनाई गई परंपराएँ आगे चलकर आधिकारिक ऑब्जेक्ट बन गईं। रीट्वीट करना, सामग्री को दूसरों तक ‘forward’ करने के एक तरीके के रूप में उभरा। इसकी शुरुआत एक मैन्युअल प्रक्रिया के रूप में हुई, जिसमें एक पोस्ट को कॉपी/पेस्ट किया जाता था और उसके आगे “RT @” पैटर्न जोड़ा जाता था। आखिरकार, इस प्रक्रिया को नए रीट्वीट बटन के ज़रिए स्वचालित कर दिया गया, साथ ही नया JSON मेटाडेटा भी जोड़ा गया। इस तरह ‘आधिकारिक’ रीट्वीट अस्तित्व में आया और रीट्वीट करने की क्रिया एक प्रथम-श्रेणी पोस्ट इवेंट बन गई। नए रीट्वीट बटन के साथ, नया मेटाडेटा भी पेश किया गया, जैसे मूल पोस्ट का पूरा payload।
कोई पोस्ट मूल है या साझा की गई है, यह फ़िल्टरिंग के लिए एक सामान्य ‘switch’ है। कुछ मामलों में, केवल मूल सामग्री की ज़रूरत होती है। अन्य मामलों में, पोस्ट एंगेजमेंट सबसे महत्वपूर्ण होता है, इसलिए रीट्वीट अहम होते हैं। PowerTrack is:retweet Operator उपयोगकर्ताओं को रीट्वीट शामिल करने या बाहर रखने, दोनों की सुविधा देता है। अगर अगस्त 2009 से पहले का डेटा निकाला जा रहा है, तो उपयोगकर्ताओं को रीट्वीट मिलान (या गैर-मिलान) के लिए दो रणनीतियाँ अपनानी होंगी। अगस्त 2009 से पहले की अवधि के लिए, “@RT ” पैटर्न से मेल खाने की जाँच हेतु, पोस्ट संदेश की exact phrase matching के साथ जाँच करनी होती है। अगस्त 2009 के बाद की अवधि के लिए, is:retweet Operator उपलब्ध है।
किसी पोस्ट को किस भाषा में लिखा गया है, यह आम रुचि का विषय है। पोस्ट की भाषा से उसके स्थान का अनुमान लगाने में मदद मिल सकती है, और विश्लेषण या प्रदर्शन के लिए अक्सर केवल एक विशिष्ट भाषा की आवश्यकता होती है। (X प्रोफ़ाइल्स में पसंदीदा भाषा की सेटिंग भी होती है।)
किसी पोस्ट के भाषा वर्गीकरण के आधार पर फ़िल्टर करने के लिए, X के ऐतिहासिक प्रोडक्ट्स (Search API और Historical PowerTrack) काफ़ी अलग हैं। जब Search archive बनाया गया था, तब सभी पोस्ट्स में X का भाषा वर्गीकरण बैकफ़िल किया गया था। इसलिए lang: Operator पूरे पोस्ट archive के लिए उपलब्ध है। Historical PowerTrack में, X का भाषा वर्गीकरण मेटाडेटा archive में 26 मार्च 2013 से उपलब्ध है।
यह पता लगा पाना कि कोई पोस्ट कहाँ पोस्ट की गई थी (अर्थात, उसका भू-संदर्भन करना) कई उपयोग के मामलों में महत्वपूर्ण है। पोस्ट्स का भू-संदर्भन करने के तीन मुख्य तरीके हैं:
- किसी पोस्ट के संदेश में भौगोलिक संदर्भ
- उपयोगकर्ता द्वारा भू-टैग की गई पोस्ट्स
- उपयोगकर्ता द्वारा सेट की गई अकाउंट प्रोफ़ाइल की ‘होम’ लोकेशन