परिचय
एनालिटिक्स मेट्रिक्स भागीदारों और विज्ञापनदाताओं को यह समझने में मदद करते हैं कि वे X पर जिन सामग्रियों का प्रचार करते हैं, उनका प्रदर्शन कैसा है। इसमें impressions, clicks, video views और spend जैसी जानकारी शामिल होती है। इसके अलावा, भागीदार और विज्ञापनदाता उन विभिन्न audience segments के लिए भी विस्तृत मेट्रिक्स प्राप्त कर सकते हैं, जिन तक वे पहुँचते हैं। Ads API, विस्तृत campaign performance metrics प्राप्त करने के दो तरीकों का समर्थन करता है: synchronously और asynchronously। synchronous analytics calls में, अनुरोधित मेट्रिक्स रिस्पॉन्स में वापस मिल जाते हैं। asynchronous analytics एंडपॉइंट्स में, अनुरोधित मेट्रिक्स संबंधित “job” की processing पूरी होने के बाद डाउनलोड की जा सकने वाली results file में उपलब्ध होते हैं। synchronous endpoint छोटे time ranges का समर्थन करता है और real-time campaign optimization के लिए आदर्श है। वहीं, asynchronous एंडपॉइंट्स बहुत लंबे time ranges का समर्थन करते हैं और इसलिए कहीं अधिक डेटा प्राप्त करने के लिए बनाए गए हैं, जो reporting या historical backfills तैयार करने के लिए आदर्श है। समकालिक और असमकालिक एनालिटिक्स एंडपॉइंट्स के बीच के अंतर नीचे दी गई तालिका में संक्षेप में दिए गए हैं। यह जानकारी डेवलपर्स को यह तय करने में मदद करने के लिए है कि एंडपॉइंट्स के किस सेट का उपयोग किया जाए।- इसका आशय उन jobs की अधिकतम संख्या से है जो किसी भी समय प्रोसेसिंग स्थिति में हो सकती हैं।
- रीयल-टाइम ऑप्टिमाइज़ेशन: परफ़ॉर्मेंस मेट्रिक्स का उपयोग करके सक्रिय अभियानों को अपडेट करना
- सिंक्रोनाइज़ेशन: नियमित रूप से निर्धारित बैकग्राउंड सिंक
- नए खाते का ऑन-बोर्डिंग: पुराने डेटा को बैकफ़िल करना
- Entities: entity type के साथ अधिकतम 20 entity IDs, जिनके लिए आप analytics का अनुरोध करना चाहते हैं
- Time range: आरंभ और समाप्ति समय, जिन्हें ISO 8601 में व्यक्त किया जाता है
- नोट: इन्हें पूरे घंटों में व्यक्त किया जाना चाहिए
- Metric groups: संबंधित metrics के एक या अधिक सेट (हर metric group के metrics की सूची के लिए Metrics and Segmentation देखें)
- Granularity: aggregation के उस स्तर को निर्दिष्ट करता है जिस पर metrics लौटाए जाने चाहिए
- Placement: यह निर्धारित करता है कि metrics उन ads के लिए निकाले जाएँ जो X पर या X के बाहर serve हुए
- नोट: हर अनुरोध में केवल एक placement value निर्दिष्ट की जा सकती है
start_time और end_time अनुरोध पैरामीटर का उपयोग करें। इन मानों को नीचे बताए गए तरीके से निर्दिष्ट granularity के अनुरूप होना चाहिए।
TOTAL: कोई भी समय सीमा निर्दिष्ट करें (endpoint की सीमाओं के भीतर)DAY: start time और end time, दोनों के मान account के time zone में मध्यरात्रि के अनुरूप होने चाहिएHOUR: कोई भी समय सीमा निर्दिष्ट करें (endpoint की सीमाओं के भीतर)
start_time=2019-01-01T00:00:00Z और end_time=2019-01-02T00:00:00Z वाला अनुरोध analytics metrics का केवल एक दिन का डेटा लौटाएगा (दो दिन का नहीं), क्योंकि यह समय सीमा केवल 24 घंटे की अवधि को कवर करती है।
विभाजन
यह केवल हमारे asynchronous analytics एंडपॉइंट्स के माध्यम से उपलब्ध है। सेगमेंटेशन partners और advertisers को metrics को विशिष्ट targeting values के अनुसार विभाजित रूप में प्राप्त करने की सुविधा देता है। Segmented metrics का अनुरोध करने के लिए segmentation_type अनुरोध पैरामीटर का उपयोग करें। Segmentation विकल्पों के बारे में अधिक जानकारी के लिए, Metrics and Segmentation देखें।
Ads API के आंकड़े X Ads UI में दिखने वाले आंकड़ों से मेल क्यों नहीं खाते?
- सुनिश्चित करें कि आपने दोनों placements के लिए डेटा अनुरोध किया है:
ALL_ON_TWITTERऔरPUBLISHER_NETWORK,SPOTLIGHT, औरTREND. - ध्यान रखें कि Ads API में end times exclusive होते हैं; जबकि Ads UI में वे inclusive होते हैं
- जैसे ही reporting metrics उपलब्ध होते हैं, आप उन्हें प्राप्त कर सकते हैं। वे लगभग real-time में उपलब्ध होते हैं। हालांकि, ये शुरुआती नतीजे केवल अनुमान होते हैं, इसलिए इनमें बदलाव होना स्वाभाविक है। Spend डेटा को छोड़कर, metrics 24 घंटे बाद अंतिम रूप ले लेते हैं।
- Spend metrics आम तौर पर event के 3 दिनों के भीतर अंतिम हो जाते हैं। हालांकि, हम event की तारीख से 14 दिनों तक billing डेटा प्रोसेस करते हैं (उदाहरण के लिए, spam filtering के लिए)।
- Active Entities endpoint का उपयोग करें
null क्यों हैं?
- संभव है कि campaign ने अनुरोधित समयावधि के दौरान serve न किया हो
- यह तय करने के लिए कि analytics किन entities के लिए और किस समयावधि के लिए प्राप्त करना है, Active Entities endpoint का उपयोग करें
null मान क्यों दिखाता है?
- UI इन मानों को 0s के रूप में दिखाता है, लेकिन दोनों मान समतुल्य हैं
- analytics में हम निम्नलिखित placement values का समर्थन करते हैं:
ALL_ON_TWITTERऔरPUBLISHER_NETWORK,SPOTLIGHT, औरTREND(यानी, X Audience Platform)
- हाँ। Entity की status analytics metrics की उपलब्धता को प्रभावित नहीं करती।
- यह अपेक्षित नहीं है कि Segmented डेटा 100% non-segmented डेटा तक roll-up हो, क्योंकि यह जानकारी जिस तरीके से निकाली जाती है, उसके कारण।
- हम multi-segmentation का समर्थन नहीं करते।
- जिन क्वेरियों पर रेट लिमिट लागू होती है (यानी जो
HTTP 429स्टेटस कोड लौटाती हैं), उनमें आपकोx-rate-limit-resetहेडर की जांच करनी चाहिए और केवल बताए गए समय पर या उसके बाद ही पुनर्प्रयास करना चाहिए। - जिन क्वेरियों के परिणामस्वरूप HTTP 503 Service Unavailable स्टेटस कोड मिलता है, उनमें आपको
retry-afterहेडर की जांच करनी चाहिए और केवल बताए गए समय के बाद ही पुनर्प्रयास करना चाहिए। - जो एप्लिकेशन पुनर्प्रयास के लिए बताए गए समय का पालन नहीं करते, उनकी Ads API तक पहुंच बिना किसी सूचना के रद्द की जा सकती है या सीमित की जा सकती है।
billed_charge_local_microको छोड़कर, सभी analytics मेट्रिक्स 24 घंटे बाद स्थिर हो जाते हैं और फिर उनमें कोई बदलाव नहीं होता।billed_charge_local_microमेट्रिक, डेटा लौटाए जाने के बाद अधिकतम 3 दिनों तक एक अनुमानित मान होता है।- 24 घंटे बाद, यह मेट्रिक ज़्यादा खर्च के लिए दिए गए क्रेडिट (दिए गए
end_timeके बाद सर्व किए गए ads) और ऐसे billable events के कारण घट सकता है जिन्हें junk माना जाता है। 24 घंटे बाद इस मेट्रिक में बहुत कम बदलाव होता है। - अधिक जानकारी के लिए, कृपया एनालिटिक्स देखें।
- हमेशा
start_timeऔरend_timeदोनों दें। - 7 दिनों से अधिक पुरानी किसी भी एंटिटी का डेटा न खींचें।
- डेटा का अनुरोध (आदर्श रूप से)
HOURग्रैन्युलैरिटी के साथ करें, क्योंकि आप मेट्रिक्स को हमेशा एग्रीगेट और रोल-अप करकेDAYऔरTOTALग्रैन्युलैरिटी प्राप्त कर सकते हैं। - डेटा का अनुरोध (आदर्श रूप से)
line_itemsऔरpromoted_tweetsस्तर पर करें, क्योंकि आप इन मेट्रिक्स को हमेशा एग्रीगेट और रोल-अप करके पूरे ads एंटिटी हाइरार्की में कुल मान प्राप्त कर सकते हैं (यानी campaign, funding instrument, या account स्तरों पर)। - analytics मेट्रिक्स के मान अपनी तरफ़ (लोकल रूप से) सहेजें और संग्रहित करें।
- 30 दिनों से अधिक पुराने डेटा के लिए बार-बार क्वेरी न करें। यह डेटा नहीं बदलेगा और इसे लोकल रूप से संग्रहित किया जाना चाहिए।
- सभी गैर-सेगमेंटेड डेटा रीयल-टाइम होता है और किसी इवेंट के होने के कुछ सेकंड के भीतर उपलब्ध हो जाना चाहिए।
- conversion मेट्रिक्स और non-conversion मेट्रिक्स को अलग-अलग अनुरोधों में समूहित करें।
- ऊपर दिए गए “Fetching Real-time, Non-segmented Data” के लिए दिए गए दिशानिर्देश देखें। अतिरिक्त सलाह नीचे दी गई है।
- अधिकांश सेगमेंटेड डेटा प्रकारों में, कभी-कभी डेटा को पूरा होने में 1 घंटे तक लग सकता है।
INTERESTSके आधार पर सेगमेंट किए गए डेटा में 12 घंटे तक की देरी हो सकती है। - यह अपेक्षित नहीं है कि सेगमेंटेड डेटा, इस जानकारी के निकाले जाने के तरीके के कारण, गैर-सेगमेंटेड डेटा से 100% मेल खाए।
- डेटा को बैकफ़िल करते समय (यानी, कोई नया विज्ञापनदाता खाता जोड़ते समय), आपको
start_timeऔरend_timeके छोटे-छोटे खंडों में कई अनुरोध करने पड़ सकते हैं। - अपने फ़ेच को 30-दिन की तिथि-विंडो तक सीमित रखें।
- इन अनुरोधों को थ्रॉटल करें और इन्हें समय के साथ फैलाकर भेजें, ताकि इन फ़ेच के लिए आपकी रेट लिमिट्स समाप्त न हों।
fetch_stats) देख सकते हैं, जो इन सर्वोत्तम प्रथाओं में से कुछ को दर्शाती है।
किसी इकाई पर कौन-से मेट्रिक्स लागू होंगे, यह campaign objective पर निर्भर करता है। इस गाइड का उपयोग करके तय करें कि प्रत्येक उद्देश्य प्रकार के लिए कौन-से प्रासंगिक मेट्रिक समूह फ़ेच करने हैं, और अतिरिक्त व्युत्पन्न मेट्रिक्स की गणना कैसे की जा सकती है।
प्रासंगिक मेट्रिक समूह: ENGAGEMENT और BILLING। अगर क्रिएटिव में मीडिया का उपयोग किया गया है, तो MEDIA भी लागू है।
प्रासंगिक मीट्रिक समूह:
ENGAGEMENT, BILLING, और WEB_CONVERSION। अगर क्रिएटिव में मीडिया का उपयोग किया गया है, तो MEDIA भी लागू होता है।
संबंधित मेट्रिक समूह:
ENGAGEMENT, BILLING, MOBILE_CONVERSION, और LIFE_TIME_VALUE_MOBILE_CONVERSION। अगर क्रिएटिव्स में मीडिया या वीडियो ऐप कार्ड का इस्तेमाल किया गया है, तो MEDIA और VIDEO भी लागू हैं।
प्रासंगिक मेट्रिक समूह:
ENGAGEMENT और BILLING। अगर क्रिएटिव्स में मीडिया का उपयोग किया गया है, तो MEDIA भी लागू है।
संबंधित मेट्रिक समूह:
ENGAGEMENT और BILLING। अगर क्रिएटिव्स में मीडिया का उपयोग किया जाता है, तो MEDIA भी लागू है।
प्रासंगिक मेट्रिक समूह:
ENGAGEMENT, BILLING, और VIDEO.
संबंधित मेट्रिक समूह:
ENGAGEMENT, BILLING, और VIDEO.
यह दस्तावेज़ प्रत्येक इकाई प्रकार के लिए हमारे Analytics में उपलब्ध मेट्रिक्स का एक अवलोकन है, साथ ही प्रत्येक मेट्रिक के लिए उपलब्ध सेगमेंटेशन का भी।
*
ENGAGEMENT मेट्रिक्स परिवार के कुछ मेट्रिक्स account और funding instrument स्तर पर उपलब्ध नहीं हैं। विवरण के लिए ENGAGEMENT अनुभाग देखें।
वीडियो मेट्रिक्स की परिभाषा में बदलाव के बारे में सूचना:
VIDEO metrics group के भीतर video_total_views मेट्रिक उन सभी views की रिपोर्ट करेगा जो MRC मानक के अनुसार कम से कम 2 सेकंड तक कम से कम 50% in-view रहे हों।
कम से कम 3 सेकंड तक 100% in view वाली हमारी मूल video view परिभाषा VIDEO metrics group में नए video_3s100pct_views मेट्रिक के रूप में उपलब्ध रहेगी। मूल view परिभाषा के आधार पर बोली लगाना जारी रखने और उसी आधार पर शुल्क लिया जाने के लिए, नए उपलब्ध VIEW_3S_100PCT bid_unit का उपयोग करें।
मोबाइल कन्वर्ज़न के आँकड़े केवल उन विज्ञापनदाता खातों के लिए उपलब्ध हैं जिनमें MACT सक्षम है।
लाइफटाइम मोबाइल कन्वर्ज़न आँकड़े केवल उन विज्ञापनदाता खातों के लिए उपलब्ध हैं जिनके लिए MACT सक्षम है।
विभाजन रिपोर्टिंग से किसी दिए गए targeting type के मानों के आधार पर विभाजित मेट्रिक्स प्राप्त किए जा सकते हैं। इसकी अतिरिक्त जटिलता के कारण विभाजन केवल asynchronous analytics queries के माध्यम से उपलब्ध है।
MEDIA_CREATIVE या ORGANIC_TWEET entities के लिए विभाजन समर्थित नहीं है।
कुछ सेगमेंटेशन types के लिए अतिरिक्त पैरामीटर पास करने होते हैं। उनका दस्तावेज़ीकरण नीचे दिया गया है।
CITIES या POSTAL_CODES के आधार पर विभाजन करते समय, API केवल targeted locations लौटाएगा। Region और metro सेगमेंटेशन targeted और non-targeted, दोनों locations लौटाएगा।
कैंपेन मेट्रिक्स उनके कैंपेन उद्देश्यों पर निर्भर करते हैं। लागू उद्देश्यों के आधार पर उपयोग के लिए व्युत्पन्न मेट्रिक्स की गणना कैसे की जाए, यह तय करने हेतु इस गाइड का उपयोग करें।
कोई भी
metric जिसके साथ कर्ली ब्रैकेट्स नहीं हैं, वह Ads API के analytics endpoints द्वारा लौटाया जाता है। {कर्ली ब्रैकेट्स} से घिरा कोई भी नाम उस श्रेणी के लिए एक व्युत्पन्न मेट्रिक को दर्शाता है।
एंगेजमेंट्स
APP_INSTALLS और APP_ENGAGEMENTS
फ़ॉलोअर्स
LEAD_GENERATION
VIDEO_VIEWS
PROMOTED_ACCOUNT के placement_type के लिए ऊपर दिए गए FOLLOWERS ऑब्जेक्टिव को देखें। इस ऑब्जेक्टिव के साथ अन्य सभी प्लेसमेंट के लिए, संबंधित डेराइव्ड मेट्रिक्स हेतु ENGAGEMENTS देखें।
Active Entities endpoint को हमारे synchronous और asynchronous एनालिटिक्स एंडपॉइंट्स के साथ उपयोग करने के लिए डिज़ाइन किया गया है, क्योंकि यह बताता है कि analytics का अनुरोध किन campaigns के लिए किया जाना चाहिए। यह ads entities का विवरण और उनकी metrics में बदलाव कब हुआ, यह लौटाकर ऐसा करता है। इस endpoint का उपयोग करने से आपका code और analytics फ़ेच करने का logic काफ़ी सरल हो जाएगा।
इस guide में endpoint और उसके data source के बारे में जानकारी और संदर्भ शामिल हैं। यह उपयोग दिशानिर्देश और उदाहरण अनुरोधों की एक श्रृंखला भी प्रदान करता है, जो दिखाती है कि हमारे analytics एंडपॉइंट्स के साथ Active Entities का उपयोग कैसे किया जाए। सारांश अनुभाग अनुशंसित दृष्टिकोण का उच्च-स्तरीय विवरण देता है।
जब भी किसी ads entity metric में बदलाव होता है, हम उस बदलाव की जानकारी दर्ज करते हैं। इन परिवर्तन इवेंट्स को हर घंटे के बकेट में संग्रहीत किया जाता है और इनमें entity का विवरण, साथ ही वह समय भी शामिल होता है जिस पर बदलाव लागू होता है। यह दूसरा हिस्सा ज़रूरी है, क्योंकि परिवर्तन इवेंट्स हमेशा उस समय से मेल नहीं खाते जब उन्हें दर्ज किया गया था। इसका एक सामान्य कारण billing adjustments है, लेकिन इसके अलावा भी अन्य कारण हो सकते हैं।
Active Entities अनुरोध ads accounts के अंतर्गत आते हैं और इनमें तीन आवश्यक query पैरामीटर होते हैं: entity, start_time, और end_time।
twurl -H ads-api.x.com "/11/stats/accounts/18ce54d4x5t/active_entities?entity=PROMOTED_TWEET&start_time=2019-03-05T00:00:00Z&end_time=2019-03-06T00:00:00Z"
निम्न entity मान समर्थित हैं: CAMPAIGN, FUNDING_INSTRUMENT, LINE_ITEM, MEDIA_CREATIVE, PROMOTED_ACCOUNT, और PROMOTED_TWEET। यह उन entity type को दर्शाता है जिन्हें हमारे एनालिटिक्स एंडपॉइंट्स समर्थन करते हैं।
start_time और end_time मान ISO 8601 में होने चाहिए और यह निर्दिष्ट करते हैं कि किन hourly buckets के लिए query की जानी है। इन्हें पूरे घंटों में व्यक्त किया जाना चाहिए।
यह एंडपॉइंट तीन वैकल्पिक पैरामीटर का भी समर्थन करता है, जिनका उपयोग नतीजों को फ़िल्टर करने के लिए किया जा सकता है: funding_instrument_ids, campaign_ids, और line_item_ids। ये ads hierarchy के सभी स्तरों पर और किसी भी निर्दिष्ट entity type के साथ काम करते हैं।
ऊपर दिए गए अनुरोध के लिए Active Entities रिस्पॉन्स नीचे दर्शाया गया है।
data ऐरे में हर उस इकाई के लिए एक ऑब्जेक्ट शामिल होता है जिसे बाद के एनालिटिक्स अनुरोध में शामिल किया जाना चाहिए। आपको इस सेट से बाहर के IDs के लिए एनालिटिक्स का अनुरोध नहीं करना चाहिए।
हर ऑब्जेक्ट में चार फ़ील्ड्स होते हैं: entity_id, activity_start_time, activity_end_time, और placements। गतिविधि के आरंभ और समाप्ति समय उस समय-सीमा को दर्शाते हैं, जिस पर संबंधित इकाई की परिवर्तन इवेंट लागू होती हैं, और इसी आधार पर यह तय होता है कि बाद के एनालिटिक्स अनुरोधों में कौन-सी तारीखें निर्दिष्ट की जानी चाहिए। placements ऐरे में निम्नलिखित मान हो सकते हैं: ALL_ON_TWITTER, PUBLISHER_NETWORK, SPOTLIGHT, और TREND। यह बताता है कि दिए गए entity ID के लिए किन placements का अनुरोध किया जाना चाहिए।
एनालिटिक्स अनुरोध कैसे किए जाएँ, यह Active Entities एंडपॉइंट से निर्धारित होना चाहिए। नीचे दिए गए उपयोग दिशानिर्देश एनालिटिक्स synchronization का समर्थन करने के लिए लिखे गए हैं, ताकि पार्टनर अपने data store को Twitter के साथ सिंक में रख सकें। दूसरे शब्दों में, यह बताता है कि नियमित रूप से शेड्यूल किए गए background syncs कैसे चलाए जाएँ।
डेवलपर को दो निर्णय लेने होते हैं।
- Active Entities information का अनुरोध कितनी बार किया जाए और, इस प्रकार, एनालिटिक्स को कितनी बार pull किया जाए।
- एनालिटिक्स अनुरोध के
start_timeऔरend_timeमान तय करने के लिए activity के start और end time का उपयोग कैसे किया जाए।
- Active Entities अनुरोध करें।
- रिस्पॉन्स को placement के अनुसार विभाजित करें।
ALL_ON_TWITTERके लिए एक समूह,PUBLISHER_NETWORKके लिए एक,SPOTLIGHTके लिए एक, औरTRENDके लिए एक। - प्रत्येक placement समूह के लिए, निम्न कार्य करें।
- entity IDs निकालें।
- एनालिटिक्स के
start_timeऔरend_timeमान निर्धारित करें।- न्यूनतम
activity_start_timeढूँढें। इस मान को नीचे की ओर round करें। - अधिकतम
activity_end_timeढूँढें। इस मान को ऊपर की ओर round करें।
- न्यूनतम
- एनालिटिक्स अनुरोध करें।
- entity IDs को 20 के बैच में समूहित करें।
- #3b के
start_timeऔरend_timeमानों का उपयोग करें। - उपयुक्त
placementमान निर्दिष्ट करें।
- अपने data store में लिखें।
start_time, पिछले अनुरोध के end_time के बराबर हो।
नोट: किसी समय-विंडो का अनुरोध केवल एक बार किया जाना चाहिए। किसी समय-विंडो का एक से अधिक बार अनुरोध करने से अनावश्यक एनालिटिक्स अनुरोध होंगे। (अपवाद नीचे दिया गया है।)
start_time और end_time टाइमस्टैम्प के उदाहरण दिखाती है।
परिवर्तन इवेंट्स को जिस तरह संग्रहीत किया जाता है, उसके कारण ऊपर दिए गए सभी चार Active Entities अनुरोध उसी प्रति-घंटा बकेट को क्वेरी करते हैं, जो इस उपयोग के मामले के लिए आवश्यक है। हालांकि, मौजूदा घंटे के बाद इस प्रति-घंटा बकेट को फिर क्वेरी नहीं किया जाना चाहिए।
हम गतिविधि के शुरू और खत्म होने के समय के साथ काम करने के लिए निम्नलिखित तरीका सुझाते हैं। Active Entities रिस्पॉन्स में मौजूद सभी ऑब्जेक्ट्स में
activity_start_time का न्यूनतम मान और activity_end_time का अधिकतम मान ढूंढें। फिर इन मानों को इस तरह संशोधित करें कि न्यूनतम गतिविधि आरंभ समय को नीचे की ओर राउंड किया जाए और अधिकतम गतिविधि समाप्ति समय को ऊपर की ओर राउंड किया जाए। विशेष रूप से, दोनों टाइमस्टैम्प में घंटे, मिनट और सेकंड को शून्य पर सेट करें और समाप्ति समय में एक दिन जोड़ दें, जैसा कि नीचे दी गई तालिका में दिखाया गया है। बाद के एनालिटिक्स अनुरोधों में यही आरंभ और समाप्ति समय निर्दिष्ट किए जाने चाहिए।
नोट: यह महत्वपूर्ण है कि टाइमस्टैम्प में घंटे, मिनट और सेकंड शून्य पर सेट करके शामिल किए जाएँ। अन्यथा, अगर केवल तारीख भेजी जाती है, तो हम मान लेंगे कि आप ads account के timezone में मध्यरात्रि से शुरू होकर मध्यरात्रि पर समाप्त होने वाले एनालिटिक्स का अनुरोध कर रहे हैं, जो शायद वांछनीय न हो। उदाहरण के लिए, अगर न्यूनतम गतिविधि आरंभ समय 2019-02-28T01:30:07Z है और -08:00:00 ऑफ़सेट वाले किसी ads account के लिए टाइमस्टैम्प छोड़ दिया जाता है, तो एनालिटिक्स अनुरोध 01:30 और 08:00 के बीच हुए बदलावों को शामिल नहीं करेगा।
वैकल्पिक रूप से, अगर आप पूरे दिनों तक विस्तार किए बिना केवल लौटाई गई गतिविधि समय विंडो के लिए एनालिटिक्स का अनुरोध करना चाहते हैं, तो ऐसा कर सकते हैं। इस तरीके का उपयोग करने पर, व्युत्पन्न आरंभ और समाप्ति समय क्रमशः 2019-03-04T20:00:00Z और 2019-03-05T15:00:00Z होंगे। (ध्यान दें कि अगर आप एनालिटिक्स अनुरोध में
DAY granularity निर्दिष्ट करते हैं, तो इस तरह की ranges स्वीकार नहीं की जाती हैं।)
यह अनुभाग दिखाता है कि सिंक्रोनस एनालिटिक्स एंडपॉइंट के साथ Active Entities का उपयोग कैसे किया जाता है। (पठनीयता के लिए रिस्पॉन्स में थोड़ा-सा बदलाव किया गया है।) इस उदाहरण में, Active Entities एंडपॉइंट को हर घंटे की शुरुआत में कॉल किया जाता है, और हर अनुरोध पिछले घंटे को देखता है। रिस्पॉन्स यह तय करता है कि सिंक्रोनस एनालिटिक्स एंडपॉइंट का उपयोग कैसे किया जाए।
पहला Active Entities अनुरोध 03:00:00 पर किया जाता है। रिस्पॉन्स से पता चलता है कि line item dvcz7 के metrics बदल गए हैं और ये परिवर्तन इवेंट 02:02:55 से 02:28:12 के बीच की विंडो पर लागू होते हैं।
start_time और end_time मान क्रमशः 2019-02-11T00:00:00Z और 2019-02-12T00:00:00Z पर सेट किए जाते हैं। हम देखते हैं कि नीचे दिए गए प्रत्येक metrics array में तीसरा तत्व शून्य नहीं है, जैसा कि सक्रिय entities की जानकारी के आधार पर अपेक्षित था।
- POST stats/jobs/accounts/:account_id एंडपॉइंट का उपयोग करके जॉब बनाएं।
- यह पता लगाने के लिए कि जॉब की प्रोसेसिंग पूरी हुई है या नहीं, GET stats/jobs/accounts/:account_id एंडपॉइंट पर नियमित अंतराल पर अनुरोध करें।
- जॉब की प्रोसेसिंग पूरी हो जाने पर, डेटा फ़ाइल डाउनलोड करें।
- डेटा फ़ाइल को अनज़िप करें।
segmentation_type अनुरोध पैरामीटर का उपयोग करें।
यह अनुभाग दिखाता है कि असमकालिक एनालिटिक्स एंडपॉइंट्स का उपयोग कैसे करें।
POST stats/jobs/accounts/:account_id एंडपॉइंट का उपयोग करके job बनाकर शुरुआत करें। नीचे दिया गया उदाहरण एक सप्ताह की अवधि के लिए किसी विशिष्ट line item के engagement metrics—जैसे impressions, likes, clicks आदि—का अनुरोध करता है। (ध्यान दें कि अनुरोधित समय-सीमा 20 मार्च तक जाती है, लेकिन उसमें 20 मार्च शामिल नहीं है, क्योंकि timestamp मध्यरात्रि पर सेट है।)
id और id_str दोनों रिस्पॉन्स attributes में दिखता है।
इसके बाद, आपको यह जांचना होगा कि पिछले रिस्पॉन्स के id_str का उपयोग करके बनाया गया job प्रोसेसिंग पूरी कर चुका है या नहीं, जैसा कि रिस्पॉन्स में "status": "SUCCESS" से पता चलता है। इसका मतलब है कि डेटा डाउनलोड के लिए तैयार है। url field में डाउनलोड लिंक होता है।
job_ids पैरामीटर का उपयोग करेंगे, जिसमें अधिकतम 200 job IDs निर्दिष्ट की जा सकती हैं।
इसके बाद, सूचीबद्ध url मान का उपयोग करके डेटा फ़ाइल डाउनलोड करें।
https://ads-api.x.com/stats/accounts/:account_id/reach/campaigns
GET https://ads-api.x.com/12/stats/accounts/18ce54d4x5t/reach/campaigns?campaign_ids=8fgzf&start_time=2017-05-19&end_time=2017-05-26
https://ads-api.x.com/stats/accounts/:account_id/reach/funding_instruments
उदाहरण रिस्पॉन्स
end_time - start_time) अनुमत है।
https://ads-api.x.com/12/stats/accounts/:account_id
उदाहरण रिस्पॉन्स
start_timeऔरend_timeमान यह निर्दिष्ट करते हैं कि किन घंटेवार buckets को query करना है।- लौटाई गई
dataarray में हर उस entity के लिए एक object शामिल होगा जिसे बाद के analytics अनुरोधों में शामिल किया जाना चाहिए। - महत्वपूर्ण: बाद के analytics अनुरोधों में जिन तिथियों को निर्दिष्ट किया जाना चाहिए, उनका निर्धारण
activity_start_timeऔरactivity_end_timeमानों के आधार पर किया जाना चाहिए।- ये मान उन समय-सीमाओं को दर्शाते हैं जिन पर संग्रहीत change events लागू होते हैं। यह प्रत्येक entity के लिए लौटाया जाता है।
end_time - start_time) की अनुमति है।
https://ads-api.x.com/12/stats/accounts/:account_id/active_entities
उदाहरण अनुरोध
GET https://ads-api.x.com/12/stats/accounts/18ce54d4x5t/active_entities?entity=PROMOTED_TWEET&start_time=2019-02-28&end_time=2019-03-01