कस्टम ऑडियंस
पार्टनर कस्टम ऑडियंस बनाने के कई तरीके हैं। कृपया ध्यान दें कि आप टार्गेटिंग से lookalike custom audiences को बाहर नहीं कर सकते। इसके अलावा, आप एक ही ad line item (ad group) में custom audience और custom audience lookalike, दोनों को टार्गेट नहीं कर सकते। ऑडियंस प्रबंधन ऑडियंस का प्रबंधन audience partners और Ads API partners के ज़रिए किया जा सकता है। हम API में custom audiences तक पहुँचने और उनका रखरखाव करने के लिए endpoints की एक शृंखला उपलब्ध कराते हैं। custom audience की जानकारी के लिए, हम 2 endpoints उपलब्ध कराते हैं:- GET accounts/:account_id/custom_audiences
- GET accounts/:account_id/custom_audiences/:custom_audience_id




- पास किया जा रहा user ID सही है और malformed नहीं है।
- पास किए जा रहे ऑडियंस नाम सही हैं और पिछले membership updates से मेल खाते हैं।
- कृपया POST commands से मिले रिस्पॉन्स की पुष्टि करें।
- कृपया पुष्टि करें कि ID Sync pixel सही तरीके से लागू किया गया है, और ID Sync process में बताए अनुसार संबंधित साइट पर इतने उपयोगकर्ता आ चुके हैं कि users को map किया जा सके। membership updates में जो उपयोगकर्ता unmapped रह जाते हैं, उन्हें target किए जा सकने वाले users में नहीं बदला जाएगा।
- targeting के लिए किसी ऑडियंस का न्यूनतम आकार 100 उपयोगकर्ता है (post match)। यदि 500 से कम उपयोगकर्ताओं वाली किसी ऑडियंस का match हो जाता है, तो वह X Ads UI में targeting के लिए उपलब्ध नहीं होगी।
- आम तौर पर ऑडियंस फ़ाइलों को प्रोसेस होने में 4-6 घंटे लगते हैं, लेकिन यह फ़ाइल के आकार पर निर्भर करता है। फ़ाइल प्रोसेस हो जाने के बाद ऑडियंस X Ads UI में उपलब्ध हो जाती हैं।
- Match Rate = 90 day active X users / प्रदान किए गए उपयोगकर्ताओं की संख्या
- आप एक test audience file दे सकते हैं और advertiser handle के रूप में “keltonlynn” का उपयोग कर सकते हैं। इसके बाद हम सत्यापित कर सकते हैं कि फ़ाइल को सही तरीके से ingest करके X UI में load किया जा सकता है।
p_user_id) क्या है?
- यह वह identifier है जिसका उपयोग आपकी company अपने प्रत्येक ग्राहक की विशिष्ट पहचान के लिए करती है।
- यह एक email address, device ID, X @handle या ID हो सकता है।
- यह आपको एक encrypted email के माध्यम से प्रदान की जाएगी। कृपया अपनी public PGP key mpp-inquiry@x.com पर भेजें, और हम आपको एक test email भेजेंगे ताकि यह सत्यापित किया जा सके कि सब कुछ सही तरह से काम कर रहा है। सत्यापन के बाद, हम आपको HMAC Key भेज देंगे।
- X एक test file (जिसमें sample email addresses, device IDs आदि होंगे) और एक resulting hash file उपलब्ध कराएगा, जिसके साथ आप अपने results को verify कर सकते हैं।
- नहीं, full data match file के लिए कोई size limitation नहीं है।
- X को फ़ाइल मिल जाने के बाद, उसे प्रोसेस होने में लगभग 1 दिन लगेगा।

p_user_id) से X IDs (tw_id) का एक मैपिंग तैयार किया जा सके। उचित रखरखाव सुनिश्चित करने के लिए यह प्रक्रिया नियमित रूप से हर 2-3 महीने में की जाएगी। मिलान पूरा होने के बाद, X इस फ़ाइल से प्राप्त आधारभूत मिलान दर कंपनी के साथ e-mail के माध्यम से साझा करेगा।
इस फ़ाइल का प्रारूप इस प्रकार होना चाहिए:
नामकरण परंपरा: FullDataMatch.[CompanyName].txt
Hashing Algorithm: HMAC_SHA-256
प्रारूप:
कॉलम 1: सामान्य identifiers का HMAC hashed मान
कॉलम 2: Partner User ID (प्रति उपयोगकर्ता अद्वितीय, फ़ाइल में अद्वितीय नहीं)
कॉलम विभाजक (CSV): hashed सामान्य उपयोगकर्ता पहचानकर्ता को Partner ID से अलग करने के लिए commas का उपयोग किया जाएगा
पंक्ति-विभाजित मान
- उदाहरण: यदि user record A का Partner User ID 1 है और common identifier 1, 2 और 3 हैं:
*सामान्य उपयोगकर्ता पहचानकर्ताओं के लिए नीचे दिया गया Hashing Directions अनुभाग देखें
2. कस्टम सेगमेंट सूचियाँ
X पर targeting के लिए ग्राहकों हेतु custom audiences बनाने के लिए कंपनी
p_user_id के रूप में उपयोगकर्ताओं की सूचियाँ प्रदान करेगी।
- पंक्ति-विभाजित मान
p_user_id-
- (ऊपर दिए गए 1. Full Data Match अनुभाग में जैसा प्रदान किया गया है, वैसा ही। यदि full data match में दिया गया मान hashed है, तो कंपनी audience file में वही hashed मान प्रदान करेगी। यदि दिया गया मान hashed नहीं है, तो कंपनी unhashed मान प्रदान करेगी।)
- पंक्ति-आधारित मान
- हैश किया गया सामान्य उपयोगकर्ता पहचानकर्ता (अर्थात ईमेल पता)
- नीचे दी गई फ़ाइल-नामकरण परंपराओं का पालन करें
- नीचे ईमेल पतों के लिए दिए गए हैशिंग निर्देशों का पालन करें (Hashing Directions में)
- audiencename: Custom Audience का नाम। यह वही नाम है जो ads.x.com campaign setup UI में audience चुनते समय दिखाई देगा, उदाहरण के लिए brand_loyalty_card_holders।
- partnername: विज्ञापनदाता की ओर से डेटा उपलब्ध कराने वाली कंपनी का नाम, उदाहरण के लिए company_name।
- handle: वह X Account (@handle) जिसे Custom Audiences का access होगा, उदाहरण के लिए @pepsi, @dietpepsi
- operation: new, add, remove, removeall, replace (विवरण नीचे)
- : सेकंड में मानक Unix epoch time, जिसका उपयोग यह सुनिश्चित करने के लिए किया जाता है कि अपलोड की गई हर audience फ़ाइल अद्वितीय हो
- filetype: फ़ाइल *.txt format में होनी चाहिए
- इसका उपयोग उन उपयोगकर्ताओं की व्यापक सूची के लिए किया जा सकता है जिन्होंने Advertiser से ऑप्ट-आउट किया है।
- X इस फ़ाइल में दी गई केवल नवीनतम सूची को ही मान्य करेगा, और इसे मेल खाने वाले
@It92I6Ev2B.Com
सामान्यीकरण के बाद: testemail_organisational_baseball+884@it92i6ev2b.com
हैश किया गया मान: 74d9584eded0ad1e5572a1c1849f3716751d371d6117a6155dad5363f4b4fbec
नोट: एन्कोड किए गए hmac और key, दोनों के वर्णों की संख्या इनपुट और एन्कोडिंग के आधार पर अलग-अलग हो सकती है।
डिवाइस IDs की हैशिंग के लिए भी वही आवश्यकताएँ लागू होंगी: SHA-256 hashing algorithm और एक common salt का उपयोग, जो हम data partners को प्रदान करते हैं। हम spaces को वैसे ही हटा देते हैं जैसे email addresses के साथ करते हैं, लेकिन IDFAs/Android IDs के लिए lowercase normalization नहीं किया जाता और IDFA/Android ID का सटीक format ही इस्तेमाल किया जाना चाहिए।
नीचे iOS और Android के लिए pre-hashing डिवाइस IDs के raw format के उदाहरण दिए गए हैं:
iOS IDFA: DD99CFF7-6186-4602-9DF2-ED3FD0B2D431
Android ID: b5bf2122961b3595
Hashed iOS IDFA: 134fb8cd95c7fd42e2793f469a447198ca5f990968db2dbadad70e723ed9750b
Hashed Android ID: 130dddff1939f229476f50bc8adab8fcb7e3525b0e9604fe8effc15e68cee4a4
X IDs को अब भी hash किया जाएगा, क्योंकि डेटा का समूह — यानी @handles की Customer List — विज्ञापनदाता के लिए निजी होता है, भले ही वह PII न हो। X IDs की hashing के लिए वही आवश्यकताएँ लागू होंगी: SHA-256 hashing algorithm और एक common salt का उपयोग, जो हम data partners को प्रदान करते हैं। X ID/@username दोनों में से spaces हटा दिए जाने चाहिए, लेकिन User IDs के लिए सामान्यीकरण की आवश्यकता नहीं है। सामान्यीकरण के लिए @usernames को lowercase में होना चाहिए। साथ ही, username के हिस्से के रूप में @ symbol शामिल नहीं होना चाहिए।
raw ID format होगा:
- User ID: 27674040
- @username: testusername
p_id के साथ डेटा भेजने वाले पार्टनरों को विज्ञापनदाता या पार्टनर के user ids को X user ids से मैप करने के लिए ID Sync प्रक्रिया से गुजरना होगा। इससे विज्ञापनदाता X पर सीधे अपने user segments को लक्षित कर सकते हैं। पार्टनरों को अपने membership updates भेजते समय param user_identifier_type का मान TALIST_PARTNER_USER_ID या TAWEB_PARTNER_USER_ID में से किसी एक पर सेट करना भी होगा।
- केवल वेब: यह विज्ञापनदाता की साइट पर एक pixel लगाकर किया जा सकता है, जैसा कि नीचे बताया गया है।
- सूची: यह CRM पेज पर बताई गई किसी भी विधि का उपयोग करके किया जा सकता है।
partner id के उदाहरण 111 और
p_user_id के उदाहरण abc का उपयोग करने पर, तैयार किया गया पिक्सेल इस प्रकार होगा:
सदस्यता अपडेट भेजना
जैसा कि हमारे endpoint दस्तावेज़ में बताया गया है, POST custom_audience_memberships endpoint के माध्यम से उपयोगकर्ताओं को भेजते समय, cookie-आधारित मिलान सक्षम करने के लिए आपको customer ID भेजनी चाहिए।
p_id के साथ डेटा भेजने वाले साझेदारों को user_identifier_type को अनिवार्य रूप से TALIST_PARTNER_USER_ID या TAWEB_PARTNER_USER_ID पर सेट करना होगा।
बाकी सभी चरण Real-Time Audience API Integration Guide में दिए गए चरणों के समान रहेंगे
यह दस्तावेज़ [Custom Audience]/x-ads-api/audiences उपयोगकर्ता डेटा के फ़ॉर्मैट की रूपरेखा बताता है।
डेटा सामान्यीकरण
डिवाइस IDs:
- IDFA - डैश सहित लोअरकेस; उदाहरण:
4b61639e-47cc-4056-a16a-c8217e029462 - AdID - डिवाइस पर जैसा मूल फ़ॉर्मैट है, वही आवश्यक है; डैश सहित, बड़े अक्षरों में नहीं; उदाहरण:
2f5f5391-3e45-4d02-b645-4575a08f86e - Android id - डिवाइस पर जैसा मूल फ़ॉर्मैट है, वही आवश्यक है; बिना डैश या स्पेस के, बड़े अक्षरों में नहीं; उदाहरण:
af3802a465767e36
- लोअरकेस, शुरुआत और अंत के स्पेस हटाकर; उदाहरण:
support@x.com
- @ के बिना, लोअरकेस में, और शुरुआत व अंत के स्पेस हटाकर; उदाहरण:
jack
- मानक पूर्णांक; उदाहरण:
143567
SHA256 का उपयोग करके hash करना चाहिए। इसके अतिरिक्त, अंतिम आउटपुट hash लोअरकेस में होना चाहिए। उदाहरण के लिए, 49e0be2aeccfb51a8dee4c945c8a70a9ac500cf6f5cb08112575f74db9b1470d और न कि 49E0BE2AECCFB51A8DEE4C945C8A70A9AC500CF6F5CB08112575F74DB9B1470D

p_user_ids) की एक सूची भेजेंगे। यह ID Sync प्रक्रिया के ज़रिए किया जाता है, जो p_user_ids और X user ID के बीच एक मैपिंग बनाती है। फिर इस मैपिंग का उपयोग X User IDs की ऐसी सूचियाँ तैयार करने के लिए किया जाता है, जिन्हें टार्गेटिंग के लिए इस्तेमाल किया जा सकता है। ये कस्टम ऑडियंस, ads.x.com Custom Audiences Web campaign setup में लेबल द्वारा निर्दिष्ट विज्ञापनदाता के विशेष @handle पर उपलब्ध कराए जाएँगे।
X एक सुरक्षित पिक्सेल उपलब्ध कराएगा, जिसे IDs (p_user_ids) को X user IDs से मैच करने के लिए पार्टनर टैग्स और साइटों पर जोड़ा जा सकता है। ID Sync प्रक्रिया पूरी हो जाने के बाद, targeting files पार्टनर द्वारा बनाई जाएँगी और एक HTTPS endpoint के माध्यम से X को उपलब्ध कराई जाएँगी। इन targeting files को X नियमित रूप से ingest करता है और फिर X UI में उपलब्ध कराता है।
X सुरक्षित पिक्सेल
X secure पिक्सेल इस प्रकार दिखाई देगा:
https://analytics.x.com/i/adsct?p_user_id=xyz&p_id=123
p_user_id - xyz उस पार्टनर user ID को दर्शाता है, जो Partner द्वारा प्रदान की जाती है
p_id - 123 Partner के लिए अद्वितीय ID को दर्शाता है (X द्वारा प्रदान की गई)
Partner HTTPS Endpoint & Targeting User File
पार्टनर को X को एक HTTPS endpoint और credentials (username/password) देने होंगे, जिनका उपयोग targeting file को नियमित रूप से ingest करने के लिए किया जा सके। एक नमूना HTTPS endpoint इस प्रकार दिखाई देगा:
- पार्टनर टार्गेटिंग यूज़र फ़ाइल
- टार्गेटिंग कन्वर्ज़न फ़ाइल
- 199.16.156.0/22
- 199.59.148.0/22
नोट्स:
हर बार जब हमें नई पार्टनर टार्गेटिंग फ़ाइल प्राप्त होती है, तो हम अपेक्षा करते हैं कि यह उन उपयोगकर्ताओं की पूरी सूची होगी जिन्हें पार्टनर हमारे लिए टार्गेट करने की सिफारिश करता है, न कि कोई वृद्धिशील सूची, जब तक कि अन्यथा सहमति न हो। हम प्रत्येक पार्टनर के साथ इस पार्टनर टार्गेटिंग फ़ाइल की डिलीवरी की आवृत्ति पर सहमति करेंगे। यदि हमें अपेक्षा के अनुसार पार्टनर टार्गेटिंग फ़ाइल प्राप्त नहीं होती है, तो हम कुछ पूर्वनिर्धारित समाप्ति समय के साथ पिछले संस्करण का उपयोग करेंगे।
Audience API को Ads API के v4 के हिस्से के रूप में लॉन्च किया गया था, और इसके साथ पुराने Audiences endpoints में कई सुधार किए गए। यह नया endpoint एक नए Audience processing backend द्वारा समर्थित है और स्थिरता, मजबूती तथा विश्वसनीयता के लिहाज़ से कई सुधार प्रदान करता है। इस गाइड का उद्देश्य Audience API और पुराने Audience upload तथा management प्रक्रियाओं के बीच के अंतर को रेखांकित करना है।
संदर्भ दस्तावेज़ Audience API के reference documentation पेज पर उपलब्ध हैं।
नोट: अपलोड से पहले सभी Audience user data को SHA-256 से hash किया जाना चाहिए। अधिक जानकारी, साथ ही स्वीकार्य user identifier प्रकारों और data normalization का विवरण, user data पेज पर उपलब्ध है।
Audience कार्यक्षमता में बदलाव
कस्टम ऑडियंस में निम्नलिखित बदलाव v4 से लागू किए गए हैं, और Ads API के v3 के sunset होने के बाद deprecated endpoints अब उपलब्ध नहीं रहेंगे:
- Deprecated TON Upload:
- GET accounts/:account_id/custom_audience_changes
- GET accounts/:account_id/custom_audience_changes/:custom_audience_change_id
- POST accounts/:account_id/custom_audience_changes
- PUT accounts/:account_id/custom_audiences/global_opt_out
- Deprecated Real Time Audiences:
- POST custom_audience_memberships
- Custom Audience:
- सभी Custom Audience endpoints पर request और रिस्पॉन्स से
list_typeपैरामीटर हटा दिया जाएगा। पहले इस पैरामीटर का उपयोग Audience के user identifier type (जैसे email, X User ID आदि) की पहचान के लिए किया जाता था। हालांकि, अब Audiences एक ही Audience के लिए कई user identifiers स्वीकार कर सकते हैं, इसलिए यह मान अब प्रासंगिक नहीं है।
- सभी Custom Audience endpoints पर request और रिस्पॉन्स से
- General:
- Audience lookback window को अपडेट किया गया है ताकि पिछले 90 दिनों के भीतर सक्रिय उपयोगकर्ताओं से मिलान किया जा सके (पहले 30 दिन)
- किसी audience को targetable बनाने के लिए आवश्यक matched users की न्यूनतम संख्या घटाकर 100 users कर दी गई है (पहले 500 users)
पूर्वापेक्षाएँ
- Ads API access
- Audience endpoint तक access के लिए, आपको allowlist में जोड़ा जाना होगा। कृपया यह फ़ॉर्म भरें और नए X Ads Products and Services Agreement को स्वीकार करें, यदि इसे शुरुआत में 2018-08-01 से पहले स्वीकार किया गया था
नोट TON Upload path के माध्यम से अपडेट या opt-out किए जा रहे किसी भी audience के लिए, TON Upload endpoint के माध्यम से अपलोड की गई एक संबंधित list होनी चाहिए, और उसे custom_audience_changes endpoint का उपयोग करके किसी Audience से संबद्ध किया जाना चाहिए।
Rate Limiting
Audience API endpoint की rate limit प्रति account 1500/1min है। एक single payload में भेजे जाने वाले users की संख्या पर कोई सीमा नहीं है। payload पर केवल निम्न constraints लागू हैं:
- operations की कुल संख्या: 2500 operations
- अधिकतम payload size: 5,000,000 bytes
id प्राप्त करें। यदि आप शुरुआत से कोई Audience बना रहे हैं, तो यह चरण आवश्यक है। यदि आप किसी मौजूदा Audience को अपडेट कर रहे हैं, तो अगले अनुभाग पर जाएँ
Custom Audience id और नीचे दिए गए जैसे एक नमूना payload के साथ POST accounts/:account_id/custom_audiences/:custom_audience_id/users का उपयोग करें:
POST https://ads-api.x.com/11/accounts/18ce54d4x5t/custom_audiences/1nmth/users
operation_type Update का उपयोग करें। नया Audience interface आपको एक ही उपयोगकर्ता के लिए कई user keys पास करने की सुविधा देता है। JSON objects की array में प्रत्येक object एक उपयोगकर्ता के अनुरूप होता है। ऊपर दिए गए उदाहरण payload का उपयोग करने पर, अनुरोध Audience में दो उपयोगकर्ताओं को जोड़ेगा, एक email और handle के साथ और दूसरा email और twitter_id के साथ।
उपयोगकर्ताओं को जोड़ने के लिए बताई गई प्रक्रिया की तरह, किसी Audience से उपयोगकर्ताओं को इस प्रकार हटाया जा सकता है:
POST https://ads-api.x.com/11/accounts/18ce54d4x5t/custom_audiences/1nmth/users
operation_type को Delete पर सेट किया जाना चाहिए, और उपयोगकर्ताओं का मिलान उन सभी कुंजियों में से किसी भी कुंजी के आधार पर किया जाएगा जो उपयोगकर्ताओं को audience में जोड़ते समय मौजूद थीं। उदाहरण के लिए, यदि किसी उपयोगकर्ता को email और twitter_id का उपयोग करके किसी audience में जोड़ा गया था, तो उसी उपयोगकर्ता को इनमें से किसी एक कुंजी का उपयोग करके हटाया जा सकता है, यानी email या twitter_id या दोनों।
इसके अलावा, एक ही अनुरोध में किसी Audience में उपयोगकर्ताओं को जोड़ना और हटाना दोनों संभव है। यह endpoint प्रति अनुरोध कई operation_type का समर्थन करता है।
ग्लोबल ऑप्ट-आउट endpoint के अप्रचलित होने के बाद, पार्टनर के लिए यह आवश्यक है कि वे उन सभी उपयोगकर्ताओं को Delete करें जिन्होंने किसी भी Audiences से ऑप्ट-आउट किया है। इसे करने के कुछ तरीके हैं:
- यह ट्रैक करें कि कौन-से उपयोगकर्ता किन Audiences का हिस्सा हैं, और उन उपयोगकर्ताओं को प्रत्येक Audience से अलग-अलग हटाएँ।
- उपयोगकर्ता को किसी Ads account से संबद्ध सभी Audiences से हटा दें।
- हम दृढ़ता से अनुशंसा करते हैं कि इस endpoint को लगभग रीयल-टाइम बैचों में कॉल करें, ताकि अचानक बढ़ने वाली कतारों से बचा जा सके, जिन्हें प्रोसेस होने में अधिक समय लगता है और जो आमतौर पर हमारे सिस्टम पर अनावश्यक लोड डालती हैं। इससे यह भी सुनिश्चित होता है कि उपयोगकर्ता campaign targeting के लिए जल्दी उपलब्ध हो जाएँ।
- एक सफल API कॉल, अनुरोध में प्राप्त
userऑब्जेक्ट्स की संख्या के अनुरूपsuccess_countऔरtotal_countलौटाएगी। - यह endpoint स्वभाव से atomic है, अर्थात या तो पूरा अनुरोध सफल होगा, या किसी भी त्रुटि की स्थिति में पूरा अनुरोध विफल हो जाएगा। त्रुटि रिस्पॉन्स मिलने पर, API के उपभोक्ताओं को सलाह दी जाती है कि वे त्रुटि ठीक करें और पूरे payload के साथ अनुरोध को फिर से भेजें।
- विफलता होने पर, पार्टनर को retries के साथ exponential backoff approach अपनाने की अनुशंसा की जाती है। उदाहरण के लिए, पहली विफलता पर तुरंत retry करें, दूसरी विफलता के बाद 1 मिनट बाद retry करें, और लगातार तीसरी विफलता के बाद 5 मिनट बाद retry करें, और इसी तरह।
end_time - start_time) की अनुमति है।
कृपया ध्यान दें कि परिणाम केवल एक geo (देश) तक सीमित होते हैं।
रिसोर्स URL
https://ads-api.x.com/12/insights/keywords/search
पैरामीटर
अनुरोध का उदाहरण
https://ads-api.x.com/5/accounts/:account_id/tailored_audiences/:tailored_audience_id/permissions
पैरामीटर
उदाहरण अनुरोध
GET https://ads-api.x.com/5/accounts/18ce54d4x5t/tailored_audiences/1nmth/permissions
उदाहरण रिस्पॉन्स
is_owner रिस्पॉन्स एट्रिब्यूट देखें।
नोट: Audiences को केवल उसी business के अंतर्गत आने वाले ads accounts के बीच साझा किया जा सकता है, या फिर तब, जब ऑडियंस के स्वामी ads account में SHARE_AUDIENCE_OUTSIDE_BUSINESS account feature मौजूद हो।
संसाधन URL
https://ads-api.x.com/5/accounts/:account_id/tailored_audiences/:tailored_audience_id/permissions
पैरामीटर
उदाहरण अनुरोध
POST https://ads-api.x.com/5/accounts/18ce54d4x5t/tailored_audiences/2906h/permissions?granted_account_id=18ce54aymz3&permission_level=READ_ONLY
उदाहरण रिस्पॉन्स
DELETE accounts/:account_id/tailored_audiences/:tailored_audience_id/permissions/:tailored_audience_permission_id
is_owner रिस्पॉन्स एट्रिब्यूट देखकर आप tailored audience के स्वामित्व की जांच कर सकते हैं।
अनुमति निरस्त होने के बाद, हम यह सुनिश्चित करते हैं कि जिसे access दिया गया account (granted_account_id) भविष्य के campaigns में उस audience को target नहीं कर पाएगा। मौजूदा campaigns साझा audiences के साथ चलते रहेंगे; campaigns बंद नहीं होते और audience को campaign से नहीं हटाया जाता। audience साझाकरण अनुमति निरस्त होने के बाद इस campaign की कॉपी बनाना संभव नहीं है।
संसाधन URL
https://ads-api.x.com/5/accounts/:account_id/tailored_audiences/:tailored_audience_id/permissions/:tailored_audience_permission_id
पैरामीटर
उदाहरण अनुरोध
DELETE https://ads-api.x.com/5/accounts/18ce54d4x5t/tailored_audiences/1nmth/permissions/ri
उदाहरण रिस्पॉन्स
custom_audience_id को लक्षित करने वाले सक्रिय या सभी line items और campaigns की सूची प्राप्त करें
उदाहरण अनुरोध
GET https://ads-api.x.com/12/accounts/18ce54d4x5t/custom_audiences/2906h/targeted
उदाहरण रिस्पॉन्स
custom_audience_id में उपयोगकर्ताओं को जोड़ने, अपडेट करने और हटाने की अनुमति देता है। यह endpoint प्रति उपयोगकर्ता कई user identifier types भी स्वीकार करता है।
request के users फ़ील्ड में दिया गया सारा डेटा, partner_user_id को छोड़कर, SHA256 का उपयोग करके hash किया हुआ होना चाहिए और normalized होना चाहिए।
बैच अनुरोध
- इस endpoint के लिए वर्तमान अधिकतम बैच आकार
2500है। बैच आकार प्रति request operations (Update/Delete) की संख्या के आधार पर निर्धारित होता है। उदाहरण के लिए, एक array में 2500 से अधिक operation objects ({"operation_type": "Update/Delete", [..] }) होने पर error मिलता है। - इस endpoint द्वारा स्वीकार किए जाने वाले request POST body का अधिकतम आकार
5,000,000bytes है। - इस endpoint के लिए रेट लिमिट्स 1 minute window में 1500 हैं।
- सभी पैरामीटर request body में भेजे जाते हैं और
application/jsonकाContent-Typeआवश्यक है। - बैच requests एक समूह के रूप में साथ-साथ असफल या सफल होते हैं, और error तथा success दोनों के लिए सभी API रिस्पॉन्स शुरुआती request के item order को बनाए रखते हैं।
success_count और total_count। ये मान हमेशा समान होने चाहिए, और ये request में मौजूद उन records की संख्या बताते हैं जिन्हें backend द्वारा प्रोसेस किया गया है। ऐसी स्थिति, जिसमें request body में भेजे गए records की संख्या success_count और total_count के बराबर नहीं हो, को error condition माना जाना चाहिए और इसके लिए retry आवश्यक है।
बैच त्रुटियाँ
- Request-level errors (जैसे, अधिकतम बैच आकार पार हो जाना) रिस्पॉन्स में
errorsobject के अंतर्गत दिखाए जाते हैं। - Item-level errors (जैसे, आवश्यक पैरामीटर का न होना) रिस्पॉन्स में
operation_errorsobject के अंतर्गत दिखाए जाते हैं। operation_errorsमें error का index input item के index को संदर्भित करता है, साथ में संबंधित error message होता है
https://ads-api.x.com/12/accounts/:account_id/custom_audiences/:custom_audience_id/users
users ऑब्जेक्ट के बहु-कुंजी दृष्टिकोण को देखते हुए, इस ऑब्जेक्ट के प्रत्येक तत्व का दस्तावेज़ीकरण नीचे किया गया है:
POST https://ads-api.x.com/12/accounts/18ce54d4x5t/custom_audiences/1nmth/users
https://ads-api.x.com/12/accounts/:account_id/custom_audiences/:custom_audience_id/permissions
पैरामीटर
उदाहरण अनुरोध
GET https://ads-api.x.com/12/accounts/18ce54d4x5t/custom_audiences/1nmth/permissions
उदाहरण रिस्पॉन्स
is_owner रिस्पॉन्स एट्रिब्यूट देखकर आप कस्टम ऑडियंस के स्वामित्व की जाँच कर सकते हैं।
नोट: Audiences केवल उसी business के अंतर्गत आने वाले ads accounts के बीच साझा किए जा सकते हैं, या तब जब ऑडियंस का स्वामी ads account SHARE_AUDIENCE_OUTSIDE_BUSINESS account feature रखता हो।
संसाधन URL
https://ads-api.x.com/12/accounts/:account_id/custom_audiences/:custom_audience_id/permissions
पैरामीटर
उदाहरण अनुरोध
DELETE accounts/:account_id/custom_audiences/:custom_audience_id/permissions/:custom_audience_permission_id
is_owner रिस्पॉन्स एट्रिब्यूट देखकर आप कस्टम ऑडियंस के स्वामित्व की जाँच कर सकते हैं।
अनुमति निरस्त होने पर, हम यह सुनिश्चित करते हैं कि जिसे access दिया गया account (granted_account_id) भविष्य के campaigns में उस audience को target नहीं कर पाएगा। मौजूदा campaigns साझा किए गए audiences के साथ चलते रहेंगे; campaigns बंद नहीं होते हैं और audience campaign से हटाया नहीं जाता। audience साझाकरण अनुमति निरस्त होने के बाद इस campaign की कॉपी बनाना संभव नहीं है।
संसाधन URL
https://ads-api.x.com/12/accounts/:account_id/custom_audiences/:custom_audience_id/permissions/:custom_audience_permission_id
पैरामीटर
उदाहरण अनुरोध
DELETE https://ads-api.x.com/12/accounts/18ce54d4x5t/custom_audiences/1nmth/permissions/ri
उदाहरण रिस्पॉन्स
https://ads-api.x.com/12/accounts/:account_id/custom_audiences
पैरामीटर
उदाहरण अनुरोध
GET https://ads-api.x.com/12/accounts/18ce54d4x5t/custom_audiences?custom_audience_ids=1nmth
उदाहरण रिस्पॉन्स
https://ads-api.x.com/12/accounts/:account_id/custom_audiences/:custom_audience_id
पैरामीटर
उदाहरण अनुरोध
GET https://ads-api.x.com/12/accounts/18ce54d4x5t/custom_audiences/2906h
उदाहरण रिस्पॉन्स
https://ads-api.x.com/12/accounts/:account_id/custom_audiences
पैरामीटर
उदाहरण अनुरोध
POST https://ads-api.x.com/12/accounts/18ce54d4x5t/custom_audiences?name=developers
उदाहरण रिस्पॉन्स
https://ads-api.x.com/12/accounts/:account_id/custom_audiences/:custom_audience_id
पैरामीटर
उदाहरण अनुरोध
PUT https://ads-api.x.com/12/accounts/18ce54d4x5t/custom_audiences/2906h?name=developers_changed
उदाहरण रिस्पॉन्स
- वर्तमान में अधिकतम बैच आकार 10 है।
- सभी पैरामीटर request body में भेजे जाते हैं और
Content-Typeकाapplication/jsonहोना आवश्यक है। - बैच अनुरोध समूह के रूप में एक साथ विफल या सफल होते हैं, और error तथा success दोनों स्थितियों में सभी API रिस्पॉन्स शुरुआती अनुरोध के आइटम क्रम को बनाए रखते हैं।
- Request-level त्रुटियाँ (जैसे, अधिकतम बैच आकार पार हो जाना) रिस्पॉन्स में
errorsobject के अंतर्गत दिखाई जाती हैं। - Item-level त्रुटियाँ (जैसे, आवश्यक पैरामीटर का न होना) रिस्पॉन्स में
operation_errorsobject के अंतर्गत दिखाई जाती हैं।
- Flexible Audiences एक बार बन जाने के बाद अपरिवर्तनीय होते हैं।
- Flexible Audiences बनाने के लिए Custom Audiences को boolean logic combinations के साथ tree structure में पास किया जाता है।
- एक Flexible Audience बनाने के लिए अधिकतम 10 Custom Audiences leaf nodes का उपयोग किया जा सकता है।
https://ads-api.x.com/12/batch/accounts/:account_id/custom_audiences
पैरामीटर
उदाहरण अनुरोध
POST https://ads-api.x.com/12/batch/accounts/18ce54d4x5t/custom_audiences
https://ads-api.x.com/12/accounts/:account_id/custom_audiences/:custom_audience_id
पैरामीटर
उदाहरण अनुरोध
DELETE https://ads-api.x.com/12/accounts/18ce54d4x5t/custom_audiences/2906h
उदाहरण रिस्पॉन्स
account_id से अधिकतम केवल एक Do Not Reach सूची संबद्ध हो सकती है
संसाधन URL
https://ads-api.x.com/12/accounts/:account_id/do_not_reach_lists
पैरामीटर
उदाहरण अनुरोध
GET https://ads-api.x.com/12/accounts/18ce54bgxky/do_not_reach_lists
उदाहरण रिस्पॉन्स
account_id से अधिकतम केवल एक Do Not Reach सूची जुड़ी हो सकती है
संसाधन URL
https://ads-api.x.com/12/accounts/:account_id/do_not_reach_lists
पैरामीटर
उदाहरण अनुरोध
POST https://ads-api.x.com/12/accounts/18ce54bgxky/do_not_reach_lists?description=A list of users to exclude
उदाहरण रिस्पॉन्स
do_not_reach_list_id में जोड़ने, अपडेट करने और हटाने की अनुमति देता है। यह endpoint वैध उपयोगकर्ता पहचानकर्ता type के रूप में केवल ईमेल स्वीकार करता है।
request के emails फ़ील्ड में दिया गया सारा डेटा SHA256 का उपयोग करके हैश किया जाना चाहिए और normalized होना चाहिए।
नोट्स
- एक
account_idमें अधिकतम केवल एक Do Not Reach सूची हो सकती है - इस सूची में जोड़े गए उपयोगकर्ताओं के लिए
expires_atटाइमस्टैम्प वर्तमान टाइमस्टैम्प से 13 महीनों से कम पर सेट होना अनिवार्य है - Do Not Reach सूची API
effective_atटाइमस्टैम्प स्वीकार नहीं करता और डिफ़ॉल्ट रूप से वर्तमान टाइमस्टैम्प का उपयोग करता है - Do Not Reach सूची खाते की किसी एक या सभी Custom Audiences से उपयोगकर्ताओं को नहीं हटाता, बल्कि खाते के लिए serve किए गए सभी campaigns में exclusion targeting के रूप में काम करता है
- वर्तमान अधिकतम बैच आकार
2500है इस endpoint के लिए। बैच आकार प्रति request operations (Update/Delete) की संख्या से निर्धारित होता है। उदाहरण के लिए, एक array में 2500 से अधिक operation objects ({"operation_type": "Update/Delete", [..] }) होने पर error होता है। - अधिकतम request POST body आकार जिसे यह endpoint स्वीकार कर सकता है,
5,000,000bytes है। - इस endpoint के लिए रेट लिमिट्स 1 मिनट की window में 1500 हैं
- सभी पैरामीटर request body में भेजे जाते हैं और
application/jsonकाContent-Typeआवश्यक है। - बैच requests एक समूह के रूप में साथ-साथ विफल या सफल होती हैं, और error तथा success दोनों के लिए सभी API रिस्पॉन्स प्रारंभिक request के item order को बनाए रखते हैं।
success_count और total_count। ये मान हमेशा समान होने चाहिए, और ये request में मौजूद उन records की संख्या बताते हैं जिन्हें backend द्वारा प्रोसेस किया गया है। ऐसी स्थिति, जहाँ request body में भेजे गए records की संख्या success_count और total_count के बराबर नहीं है, को error condition माना जाना चाहिए, और इसके लिए retry आवश्यक है।
बैच त्रुटियाँ
- request-level errors (जैसे, अधिकतम बैच आकार पार हो जाना) रिस्पॉन्स में
errorsobject के अंतर्गत दिखाए जाते हैं। - item-level errors (जैसे, आवश्यक पैरामीटर का न होना) रिस्पॉन्स में
operation_errorsobject के अंतर्गत दिखाए जाते हैं। operation_errorsमें error का index, संबंधित error message के साथ input item के index को संदर्भित करता है
https://ads-api.x.com/12/batch/accounts/:account_id/do_not_reach_lists/:do_not_reach_list_id/users
पैरामीटर
users object के multi-key approach को देखते हुए, इस object के प्रत्येक element का दस्तावेज़ीकरण नीचे किया गया है:
उदाहरण अनुरोध
https://ads-api.x.com/12/accounts/:account_id/do_not_reach_lists/:do_not_reach_list_id
पैरामीटर
कोई नहीं
उदाहरण अनुरोध
DELETE https://ads-api.x.com/12/accounts/18ce54bgxky/do_not_reach_lists/4ofrp
उदाहरण रिस्पॉन्स