Skip to main content

अवलोकन

परिचय

A/B परीक्षण विज्ञापनदाताओं को X पर जिन उपयोगकर्ताओं तक वे पहुँच रहे हैं, उन्हें अलग-अलग खंडों में बाँटने की सुविधा देता है, ताकि वे यह समझ सकें कि अभियान के प्रदर्शन को बेहतर बनाने के लिए सबसे प्रभावी अनुकूलन कैसे किया जाए और अपनी मार्केटिंग रणनीतियों के लिए उपयोगी सीख हासिल की जा सके। इन खंडों—जिन्हें उपयोगकर्ता समूह splits कहा जाता है—को यादृच्छिक रूप से बनाया जाता है और ये परस्पर अनन्य होते हैं। यादृच्छिकीकरण से परिणामों को प्रभावित करने वाले कारक समान रूप से वितरित हो जाते हैं। दूसरे शब्दों में, समूहों के बीच या उनके अपेक्षित व्यवहार में कोई अंतर्निहित अंतर नहीं होता। इसी वजह से, जब किसी एक उपयोगकर्ता समूह पर कोई एक variation लागू किया जाता है और बाकी पर नहीं, तो अभियान के प्रदर्शन में जो अंतर दिखाई देता है, उसे उस variation से जोड़ा जा सकता है। हालाँकि एक साथ कई variations का परीक्षण करना संभव है, हम दृढ़ता से अनुशंसा करते हैं कि एक समय में केवल एक variation का ही परीक्षण करें। इससे अभियान के प्रदर्शन में देखे गए अंतर के कारणी कारक को स्पष्ट रूप से अलग किया जा सकता है। Variations को campaign स्तर पर सेट किया जाता है। उदाहरण के लिए, अगर विज्ञापनदाता किसी नए creative की प्रभावशीलता जाँचना चाहता है, तो उसे दो एक जैसे campaign बनाने चाहिए, जिनमें केवल creative अलग हो। भविष्य में, हम लाइन आइटम स्तर पर variations के समर्थन की योजना बना रहे हैं।

उपयोग के परिदृश्य

A/B परीक्षण का उपयोग आमतौर पर (1) उन परफ़ॉर्मेंस ग्राहकों के लिए अनुकूलन संबंधी उपयोग के परिदृश्यों का समर्थन करने के लिए किया जाता है, जो यह समझना चाहते हैं कि X पर सबसे अच्छा क्या काम करता है ताकि वे अपने निवेश को अनुकूलित कर सकें, और (2) उन ब्रांड विज्ञापनदाताओं के लिए सीखने संबंधी उपयोग के परिदृश्यों का, जो इन जानकारियों का उपयोग अपनी मार्केटिंग रणनीति तय करने के लिए करना चाहते हैं।  API किसी भी अभियान वेरिएबल के लिए A/B परीक्षण का समर्थन करेगा, जिनमें शामिल हैं:
  • क्रिएटिव 
  • टार्गेटिंग 
  • बोली का प्रकार
  • बोली की इकाई

A/B परीक्षण

A/B परीक्षण विज्ञापनदाताओं को X पर उन उपयोगकर्ताओं को अलग-अलग खंडों में बाँटने की सुविधा देता है, जिन तक वे पहुँच रहे हैं, ताकि वे समझ सकें कि अभियान के प्रदर्शन को बेहतर बनाने के लिए सबसे प्रभावी तरीका क्या है और अपनी मार्केटिंग रणनीतियों के लिए उपयोगी सीख हासिल कर सकें। इन खंडों—जिन्हें उपयोगकर्ता समूह splits कहा जाता है—को यादृच्छिक रूप से बनाया जाता है और ये परस्पर अनन्य होते हैं। यादृच्छीकरण के कारण, परिणामों को प्रभावित करने वाले कारक समान रूप से वितरित होते हैं। दूसरे शब्दों में, समूहों के बीच या उनके अपेक्षित व्यवहार में कोई अंतर्निहित अंतर नहीं होता। इसी वजह से, जब किसी एक उपयोगकर्ता समूह पर केवल एक वेरिएशन लागू किया जाता है और बाकी पर नहीं, तो अभियान के प्रदर्शन में दिखने वाले अंतर का श्रेय उसी वेरिएशन को दिया जा सकता है। हालाँकि एक साथ कई वेरिएशन का परीक्षण करना संभव है, हम दृढ़ता से सलाह देते हैं कि एक समय में केवल एक वेरिएशन का ही परीक्षण करें। इससे अभियान के प्रदर्शन में देखे गए अंतर के कारण बनने वाले कारक को अलग से समझा जा सकता है। वेरिएशन या तो campaign स्तर पर या ad group स्तर पर सेट किए जाते हैं। Ads API में ad group को लाइन आइटम के माध्यम से सेट किया जाता है। ad group स्तर के वेरिएशन के उदाहरण के तौर पर, यदि कोई विज्ञापनदाता किसी नए creative की प्रभावशीलता जाँचना चाहता है, तो उसे 2 एक जैसे ad groups वाला एक campaign बनाना चाहिए, जिसमें केवल creative का अंतर हो।

उपयोग के मामले

A/B परीक्षण का उपयोग प्रायः (1) उन performance ग्राहकों के लिए अनुकूलन संबंधी उपयोग मामलों के समर्थन में किया जाता है, जो यह समझना चाहते हैं कि अपने निवेश को बेहतर बनाने के लिए X पर सबसे अच्छा क्या काम करता है, और (2) उन brand विज्ञापनदाताओं के लिए सीखने संबंधी उपयोग मामलों के समर्थन में, जो इन जानकारियों का उपयोग अपनी marketing रणनीति तय करने में करना चाहते हैं।  API किसी भी campaign variable के लिए A/B परीक्षण का समर्थन करेगा, जिनमें शामिल हैं:
  • Creative
  • Targeting
  • Bid type
  • Bid unit

एट्रिब्यूट्स

A/B टेस्ट्स को नेस्टेड संरचनाओं के रूप में निरूपित किया जाता है। A/B टेस्ट के लिए टॉप-लेवल फ़ील्ड्स होते हैं और उपयोगकर्ता समूह ऑब्जेक्ट्स की एक array होती है, जिनमें से प्रत्येक में उसका वर्णन करने वाले फ़ील्ड्स का एक सेट होता है। उच्च स्तर पर, प्रत्येक A/B टेस्ट में निम्नलिखित जानकारी शामिल होना अनिवार्य है।
  • परीक्षण की अवधि, जिसे start_time और end_time फ़ील्ड्स द्वारा निरूपित किया जाता है
  • वह स्तर जिस पर विभाजन होगा, जिसे entity_type फ़ील्ड द्वारा निरूपित किया जाता है
  • कम से कम दो (और अधिकतम 30) उपयोगकर्ता समूह, जिनमें से प्रत्येक को user_groups array में एक ऑब्जेक्ट के रूप में निरूपित किया जाता है
प्रत्येक उपयोगकर्ता समूह में निम्नलिखित जानकारी शामिल होना अनिवार्य है।
  • उपयोगकर्ताओं का वह प्रतिशत जिसे दिए गए उपयोगकर्ता समूह को आवंटित किया जाना चाहिए, जिसे size फ़ील्ड द्वारा निरूपित किया जाता है
  • campaign IDs/line item IDs, जो दिए गए उपयोगकर्ता समूह के लिए उपयोगकर्ताओं का पूल बनाते हैं, जिन्हें entity_ids array द्वारा निरूपित किया जाता है
वैकल्पिक रूप से, A/B टेस्ट्स और उपयोगकर्ता समूहों के लिए name और description मान सेट किए जा सकते हैं। वैलिडेशन नियमों और अन्य प्रतिबंधों के बारे में जानकारी नीचे दी गई है। अन्य metadata, जैसे ID या created at समय, भी शामिल होते हैं, लेकिन वे X द्वारा अपने-आप सेट किए जाते हैं। campaign स्तर के लिए एक उदाहरण A/B टेस्ट entity नीचे दिखाई गई है।
लाइन आइटम स्तर के लिए एक उदाहरण A/B टेस्ट एंटिटी नीचे दिखाई गई है.

उपयोग

नीचे दिए गए उपखंड A/B Tests को बनाने और अपडेट करने के बारे में बताते हैं। पढ़ना और हटाना, अन्य सभी Ads API endpoints की तरह ही काम करते हैं।

बनाना

POST accounts/:account_id/ab_tests endpoint का उपयोग करके एक A/B टेस्ट बनाएं। यह endpoint केवल JSON POST body स्वीकार करता है। Content-Type को application/json पर सेट होना चाहिए। विज्ञापनदाता द्वारा दो या अधिक campaign सेट अप करने के बाद, एक A/B टेस्ट बनाया जा सकता है। जैसा कि ऊपर बताया गया है, A/B टेस्ट में अनिवार्य रूप से ये शामिल होने चाहिए: टेस्ट अवधि, split level, और कम से कम दो उपयोगकर्ता समूह। प्रत्येक उपयोगकर्ता समूह में उन उपयोगकर्ताओं का प्रतिशत बताना आवश्यक है जिन्हें उसमें आवंटित किया जाना चाहिए, साथ ही campaign ID भी देनी होती हैं जो उसके user pool का हिस्सा होंगी। इनमें से प्रत्येक के बारे में अधिक विवरण नीचे दिया गया है। टेस्ट अवधि:
  • start_time और end_time मानों को
    • भविष्य में होना चाहिए (उस समय के सापेक्ष जब A/B टेस्ट बनाया जाता है)
    • campaign/लाइन आइटम की flight date के साथ overlap होना चाहिए
  • non-app-based campaign के लिए टेस्ट कम से कम एक दिन तक चलना चाहिए और app-based campaign के लिए कम से कम पाँच दिन तक चलना चाहिए
Split level:
  • entity_type को CAMPAIGN या LINE_ITEM पर सेट किया जा सकता है
User group:
  • प्रत्येक उपयोगकर्ता समूह को user_groups array में एक object के रूप में दर्शाया जाता है
    • कम से कम दो उपयोगकर्ता समूह आवश्यक हैं
    • अधिकतम 30 उपयोगकर्ता समूह की अनुमति है
  • प्रत्येक उपयोगकर्ता समूह का आकार 1.00 और 99.00 के बीच किसी संख्यात्मक मान के string representation का उपयोग करके सेट किया जाता है
    • ध्यान दें: सभी object में size मानों का योग अनिवार्य रूप से 100.00 होना चाहिए
  • campaign ID को प्रत्येक उपयोगकर्ता समूह के entity_ids array में निर्दिष्ट किया जाना चाहिए
वैकल्पिक रूप से, A/B टेस्ट के लिए या एक या अधिक उपयोगकर्ता समूह के लिए name और description सेट करें। निम्न अनुरोध campaign level पर एक A/B टेस्ट बनाता है, जो चार दिनों तक चलता है और इसमें दो उपयोगकर्ता समूह हैं, जिनमें प्रत्येक में 50% उपयोगकर्ता हैं। पहला उपयोगकर्ता समूह campaign f2qcw और f2tht पर आधारित है; दूसरा उपयोगकर्ता समूह campaign f2rqi और f2tws पर आधारित है। यह अनुरोध entity के कुछ हिस्सों में name और description भी जोड़ता है। twurl -X POST -H ads-api.x.com “/8/accounts/18ce54d4x5t/ab_tests” -d ’{“end_time”: “2020-12-05T01:00:00Z”, “entity_type” : “CAMPAIGN”, “start_time”: “2020-12-01T01:00:00Z”, “user_groups”: [{“entity_ids”: [“f2qcw”, “f2tht”], “size”: “50.00”, “name”: “first group”},{“entity_ids”: [“f2rqi”, “f2tws”], “size”: “50.00”, “name”: “second group”, “description”: “second AB test group”}], “name”: “first AB test”, “description”: “documentation example”}’
लाइन आइटम स्तर पर A/B परीक्षण के लिए कैंपेन और लाइन आइटम स्तर पर A/B परीक्षण के बीच मुख्य अंतर entity_type का होता है। लाइन आइटम स्तर पर A/B परीक्षणों के लिए हमें इसे ‘entity_type’ = ‘LINE_ITEM’ पर सेट करना होता है। यह नीचे पहले से बनाए गए A/B परीक्षण पर की जाने वाली सभी कार्रवाइयों पर लागू होता है।  आवश्यकताएँ:
  1. A/B परीक्षण कैंपेन के सभी लाइन आइटम split test में शामिल होने चाहिए।
  2. लाइन आइटम स्तर पर केवल समान विभाजन की अनुमति है।
  3. 1 split test में अनुमत user group लाइन आइटम की संख्या 5 से कम या उसके बराबर होनी चाहिए। 
  4. प्रत्येक user group के लिए केवल 1 लाइन आइटम.

अपडेट करना

PUT accounts/:account_id/ab_tests/:ab_test_id एंडपॉइंट का उपयोग करके किसी A/B टेस्ट को अपडेट करें। इस एंडपॉइंट के लिए अनुरोध में JSON blob भेजना आवश्यक है। Content-Type को application/json पर सेट होना चाहिए। अन्य update एंडपॉइंट्स की तरह, PUT accounts/:account_id/ab_tests/:ab_test_id एंडपॉइंट में A/B टेस्ट ID का संदर्भ URL में दिया जाना आवश्यक है। सामान्य तौर पर, A/B टेस्ट्स को केवल तभी अपडेट किया जा सकता है जब उनका status SCHEDULED हो। इसका एक अपवाद है: A/B टेस्ट के LIVE रहने के दौरान भी उसके end_time को अपडेट किया जा सकता है। यह एंडपॉइंट object IDs के साथ partial JSON को सपोर्ट करता है। निम्नलिखित सिद्धांत लागू होते हैं:
  • objects या elements जोड़ने या हटाने के लिए, पूरा array (और उसकी substructures) पास करें; यह एक replacement ऑपरेशन है
  • अन्यथा, key names या IDs का संदर्भ देकर मौजूदा फ़ील्ड्स में बदलाव करें (बदलें, जोड़ें, हटाएँ)
    • किसी फ़ील्ड को हटाने के लिए, उसका मान null पर सेट करें
    • जो फ़ील्ड्स पास नहीं की जातीं, उनमें कोई बदलाव नहीं होता
उदाहरण के लिए, पहले बनाए गए A/B टेस्ट में तीसरा उपयोगकर्ता समूह जोड़ने के लिए हमें user_groups array भेजना होगा, जिसमें दो मौजूदा उपयोगकर्ता समूह objects के साथ वह नया object भी शामिल हो जिसे हम जोड़ना चाहते हैं। इसे user_groups array को फिर से बनाने की तरह समझें; डेटा ऐसे पास करें जैसे आप शुरुआत में ही इसे इसी तरह बना रहे हों (उपयोगकर्ता समूह object IDs पास न करें)। अपडेट अनुरोध में user_groups array को निम्नानुसार दर्शाया जा सकता है।
ध्यान दें कि सभी ऑब्जेक्ट में size मानों का योग अभी भी 100.00 है। अगर हमने पहले दो ऑब्जेक्ट के लिए इन्हें अपडेट नहीं किया होता—जो पहले 50.00 प्रत्येक पर सेट थे—तो अनुरोध विफल हो जाता। अगर, इसके बजाय, हम सिर्फ़ पहले उपयोगकर्ता समूह में एक विवरण जोड़ना चाहते, तो update request में user_groups array को इस प्रकार दर्शाया जाता।
हम उपयोगकर्ता समूह ऑब्जेक्ट को उसकी ID से संदर्भित करते हैं और केवल वही फ़ील्ड शामिल करते हैं जिसे हम बदलना चाहते हैं।

अनुरोध के उदाहरण

यह अनुभाग अपडेट अनुरोधों के कुछ अतिरिक्त उदाहरण देता है। इन्हें क्रमवार किए गए कॉल के रूप में समझें। JSON ब्लॉब्स को पठनीयता के लिए फ़ॉर्मैट किया गया है। रिस्पॉन्स शामिल नहीं किए गए हैं। निम्नलिखित संशोधन करने के लिए, अनुरोध इस प्रकार होगा। (यह ऊपर पहले इस्तेमाल किए गए उदाहरण जैसा ही है।)
  1. नाम या विवरण के बिना तीसरा उपयोगकर्ता समूह जोड़ता है
  2. प्रत्येक उपयोगकर्ता समूह में उपयोगकर्ताओं का प्रतिशत बदलता है
twurl -X PUT -H ads-api.x.com “/8/accounts/18ce54d4x5t/ab_tests/hr7l0” -d ’
निम्नलिखित बदलाव करने के लिए, अनुरोध इस प्रकार दिखाया जाएगा।
  1. A/B टेस्ट का विवरण हटाता है
  2. पहले उपयोगकर्ता समूह में एक विवरण जोड़ता है
  3. दूसरे उपयोगकर्ता समूह में एक एंटिटी id (f2syz) जोड़ता है
twurl -X PUT -H ads-api.x.com “/8/accounts/18ce54d4x5t/ab_tests/hr7l0” -d ’
तीसरे संशोधन के लिए यह आवश्यक है कि हम नई entity ID के साथ दोनों मौजूदा entity IDs भी पास करें। ध्यान दें कि तीसरे उपयोगकर्ता समूह में कोई बदलाव नहीं किया गया। निम्नलिखित संशोधन करने के लिए, अनुरोध इस प्रकार दर्शाया जाएगा।
  1. दूसरे उपयोगकर्ता समूह को हटाता है
  2. प्रत्येक उपयोगकर्ता समूह में उपयोगकर्ताओं का प्रतिशत बदलता है

API संदर्भ

AB परीक्षण

GET accounts/:account_id/ab_tests

कुछ या सभी A/B टेस्ट के विवरण पुनर्प्राप्त करें।
संसाधन URL
https://ads-api.x.com/12/accounts/:account_id/ab_tests
पैरामीटर
उदाहरण अनुरोध
GET https://ads-api.x.com/12/accounts/18ce54d4x5t/ab_tests
उदाहरण प्रतिक्रिया

POST accounts/:account_id/ab_tests

एक नया A/B Test बनाएँ। सभी पैरामीटर अनुरोध बॉडी में भेजे जाते हैं, और application/json का Content-Type आवश्यक है।
संसाधन URL
https://ads-api.x.com/12/accounts/:account_id/ab_tests
पैरामीटर

उपयोगकर्ता समूह

उदाहरण अनुरोध

POST https://ads-api.x.com/12/accounts/18ce54d4x5t/ab_tests -d '{"end_time": "2022-05-30T01:00:00Z", "entity_type" : "CAMPAIGN", "start_time": "2022-05-25T01:00:00Z", "user_groups": [{"entity_ids": ["f2qcw", "f2tht"], "size": "50.00", "name": "first group"},{"entity_ids": ["f2rqi", "f2tws"], "size": "50.00", "name": "second group", "description": "second AB test group"}], "name": "first AB test", "description": "documentation example"}'

उदाहरण प्रतिक्रिया

PUT accounts/:account_id/ab_tests/:ab_test_id

निर्दिष्ट A/B Test को अपडेट करता है। सभी पैरामीटर अनुरोध body में भेजे जाते हैं, और application/json का Content-Type आवश्यक है। यह endpoint object IDs के साथ आंशिक JSON का समर्थन करता है। निम्नलिखित सिद्धांत लागू होते हैं:
  • objects या elements जोड़ने या हटाने के लिए, पूरा array (और उसकी substructures) पास करें; यह एक replacement operation है
    • इसे array को फिर से बनाने के समान समझें
  • अन्यथा, key names या IDs का संदर्भ देकर मौजूदा फ़ील्ड्स को संशोधित करें (बदलें, जोड़ें, हटाएँ)
    • किसी फ़ील्ड को हटाने के लिए, उसका मान null पर सेट करें
    • जो फ़ील्ड्स पास नहीं किए जाते हैं, उनमें कोई बदलाव नहीं किया जाता
सामान्यतः, A/B Tests को केवल तभी अपडेट किया जा सकता है, जब status SCHEDULED हो। एक अपवाद है: A/B Test के end_time को LIVE रहने पर भी अपडेट किया जा सकता है।
संसाधन URL
https://ads-api.x.com/12/accounts/18ce54d4x5t/:ab_test_id
पैरामीटर

उपयोगकर्ता समूह

उदाहरण अनुरोध
यह अनुरोध निम्नलिखित बदलाव करता है।
  1. A/B Test का विवरण हटाता है
  2. समाप्ति समय बदलता है
  3. पहले उपयोगकर्ता समूह में एक विवरण जोड़ता है
  4. प्रत्येक उपयोगकर्ता समूह में उपयोगकर्ताओं का प्रतिशत बदलता है
  5. दूसरे उपयोगकर्ता समूह में एक entity ID (f2syz) जोड़ता है
PUT https://ads-api.x.com/12/accounts/18ce54d4x5t/ab_tests/hr7l0 -d '{"description": null, "end_time": "2022-06-01T01:00:00Z", "user_groups": [{"id": "p1bcx", "description": "first AB test group", "size": "60.00"},{"id": "p1bcy", "size": "40.00", "entity_ids": ["f2rqi", "f2tws", "f2syz"]}]}'
उदाहरण प्रतिक्रिया

DELETE accounts/:account_id/ab_tests/:ab_test_id

निर्दिष्ट A/B Test हटाएँ। नोट: A/B Test को हटाने की कार्रवाई पूर्ववत नहीं की जा सकती, और इसके बाद इस संसाधन को हटाने के किसी भी प्रयास पर HTTP 404 लौटेगा।
संसाधन URL
https://ads-api.x.com/12/accounts/:account_id/ab_tests/:ab_test_id
पैरामीटर
उदाहरण अनुरोध
DELETE https://ads-api.x.com/12/accounts/18ce54d4x5t/ab_tests/hr7l0

उदाहरण प्रतिक्रिया