সুরক্ষিত অডিয়েন্স API নিলামের বিলম্ব উন্নত করুন

সুরক্ষিত শ্রোতা API দক্ষতার সাথে কাজ করে তা নিশ্চিত করা সবার স্বার্থে:

• ওয়েব ব্রাউজ করা লোকেরা চায় সাইটগুলি দ্রুত লোড হোক। এর অর্থ হল ডেভেলপারদের প্রোটেক্টেড অডিয়েন্স এপিআই দিয়ে দক্ষতার সাথে তৈরি করা উচিত যাতে সীমিত ডিভাইস রিসোর্স, যেমন কম্পিউট বা নেটওয়ার্ক রিসোর্স, যা সাইট এবং তাদের এম্বেড করা বিজ্ঞাপন লোড করার জন্য প্রয়োজনীয়, অতিরিক্ত ব্যবহার না করে।
• প্রকাশকরা চান তাদের সাইটগুলি দ্রুত লোড হোক, ব্যবহারকারীদের একটি দক্ষ এবং প্রতিক্রিয়াশীল অভিজ্ঞতা প্রদান করে৷ প্রকাশকরাও তাদের রাজস্ব বাড়াতে কার্যকর বিজ্ঞাপন চান।
• বিজ্ঞাপনদাতা এবং বিজ্ঞাপন প্রযুক্তিগুলি সর্বশ্রেষ্ঠ উপযোগ প্রদানের জন্য তাদের বিজ্ঞাপনগুলি দ্রুত প্রদর্শন করতে চায়৷

এই ডকুমেন্টটি একটি সুরক্ষিত শ্রোতা API বাস্তবায়নের জন্য কিছু সর্বোত্তম অনুশীলনের রূপরেখা দেয়, যাতে আপনার সাইটটি সর্বাধিক দক্ষতার সাথে কাজ করে তা নিশ্চিত করতে।

ক্রেতা (দরদাতা) সর্বোত্তম অনুশীলন

আপনি সুরক্ষিত দর্শক API নিলাম দক্ষতার জন্য অপ্টিমাইজ করছেন তা নিশ্চিত করতে, এই সেরা অনুশীলনগুলি অনুসরণ করুন৷

কম স্বার্থ গ্রুপ মালিক

প্রোটেক্টেড অডিয়েন্স এপিআই বিডারদেরকে সুরক্ষিত করতে যেভাবে ব্রাউজারটি সাইট আইসোলেশন ব্যবহার করে ওয়েবে বিভিন্ন উৎসকে রক্ষা করে, ব্রাউজারটি ব্যক্তিগত স্বার্থ গোষ্ঠীর মালিকদের রক্ষা করার জন্য ব্যয়বহুল সম্পদ (যেমন অপারেটিং সিস্টেম প্রসেস) ব্যবহার করে।

এই অতি ব্যয়বহুল সম্পদের ব্যয় কমানোর জন্য, স্বল্প সংখ্যক স্বার্থ গোষ্ঠীর মালিক থাকা অত্যন্ত গুরুত্বপূর্ণ। বিভিন্ন সাবডোমেনের মালিকানাধীন বিভিন্ন স্বার্থ গ্রুপ থাকা এড়িয়ে চলুন। উদাহরণস্বরূপ, যদি adtech.example cats.adtech.example এবং dogs.adtech.example এর মালিকানাধীন স্বার্থ গ্রুপ থাকে, তাহলে ব্রাউজার সম্ভবত তাদের বিডিং স্ক্রিপ্ট চালানোর জন্য দুটি পৃথক প্রক্রিয়া ব্যবহার করবে।

কম স্বার্থ গ্রুপ বিডিং

ক্রেতার generateBid() স্ক্রিপ্ট, যেমন একটি নতুন পরিষ্কার জাভাস্ক্রিপ্ট এক্সিকিউশন এনভায়রনমেন্ট সেট আপ করা এবং generateBid() কোড পার্সিং এবং লোড করার আগে ব্রাউজারটিকে অবশ্যই গুরুত্বপূর্ণ সেটআপ এবং প্রস্তুতি নিতে হবে।

• আগ্রহের গোষ্ঠীগুলি যে ব্যবহারকারীদের প্রতিনিধিত্ব করে যারা একটি সক্রিয় বিজ্ঞাপন প্রচারের বর্তমান লক্ষ্য নয় তাদের খালি বিজ্ঞাপন সৃজনশীল তালিকা থাকা উচিত। এটি প্রোটেক্টেড অডিয়েন্স এপিআইকে প্রাসঙ্গিক বিজ্ঞাপন ছাড়াই স্বার্থ গোষ্ঠীর জন্য generateBid() চালানো থেকে বাধা দেয়।
• অনুরূপ আগ্রহের গোষ্ঠীগুলিকে একত্রিত করা হলে generateBid() চালানোর সংখ্যা হ্রাস পাবে৷ একটি আগ্রহ গোষ্ঠীর userBiddingSignals সম্পত্তি ব্যবহারকারী সম্পর্কে অতিরিক্ত মেটাডেটা সঞ্চয় করতে ব্যবহার করা যেতে পারে, তাই কম আগ্রহের গোষ্ঠীর মানে কম কার্যকর টার্গেটিং নেই৷
• প্রোটেক্টেড অডিয়েন্স এপিআই বিক্রেতা-নির্দিষ্ট সীমাকে সমর্থন করে আগ্রহের গোষ্ঠীর সংখ্যা, এবং ক্রেতাদের জন্য তাদের আগ্রহের গ্রুপগুলির আপেক্ষিক অগ্রাধিকার নির্দিষ্ট করার জন্য একটি API। এই সীমাগুলি চালানোর জন্য বিডিং স্ক্রিপ্টের সংখ্যা উল্লেখযোগ্যভাবে কমাতে ব্যবহার করা যেতে পারে।

আপনার কী/মান পরিষেবাতে বিডিং থেকে আগ্রহের গোষ্ঠীগুলিকে ফিল্টার করুন৷

যদি একজন ক্রেতা তাদের রিয়েল-টাইম বিশ্বস্ত বিডিং সিগন্যাল সার্ভারে নির্ধারণ করতে পারে যে নির্দিষ্ট স্বার্থ গোষ্ঠীর বিড করা উচিত নয় (যেমন প্রচারাভিযানটি অক্ষম, বিরতি, বা বাজেটের বাইরে, বা এই নির্দিষ্ট প্রকাশকের উপর বিড করা উচিত নয়), তারা নির্দেশ করতে পারে বিশ্বস্ত বিডিং সিগন্যাল আনার priorityVector প্রতিক্রিয়া সহ ব্রাউজারে এটি। যদি priorityVector এবং prioritySignals এর স্পার্স ডট প্রোডাক্ট নেতিবাচক হয়, তাহলে ব্রাউজার এই আগ্রহ গ্রুপের জন্য generateBid() আহ্বান করা এড়িয়ে যাবে। আপনি ব্যাখ্যাকারীর "ফিল্টারিং এবং অগ্রাধিকারমূলক স্বার্থ গোষ্ঠী" বিভাগে এই প্রক্রিয়া সম্পর্কে আরও পড়তে পারেন।

জাভাস্ক্রিপ্ট এক্সিকিউশন এনভায়রনমেন্ট পুনঃব্যবহার করুন

ব্রাউজার generateBid() এক্সিকিউট করার আগে, এটিকে অবশ্যই একটি নতুন জাভাস্ক্রিপ্ট এক্সিকিউশন এনভায়রনমেন্ট শুরু করতে হবে। এটি একটি উল্লেখযোগ্য পরিমাণ সময় নিতে পারে, একটি ন্যূনতম generateBid() নিজে কার্যকর করতে যত সময় নিতে পারে তার সমান। গ্রুপ-বাই-অরিজিন বা হিমায়িত-প্রসঙ্গ এক্সিকিউশন মোড ব্যবহার করে এই সময়টি সংরক্ষণ করা যেতে পারে।

group-by-origin মোড সেই ক্ষেত্রে এক্সিকিউশন এনভায়রনমেন্ট পুনঃব্যবহার করতে পারে যেখানে আগ্রহের গোষ্ঠী একই মূলে যোগদান করা হয়েছে এবং সম্ভবত আপনার বিডিং স্ক্রিপ্টে পরিবর্তনের প্রয়োজন হবে না; আরও জানতে, ব্যাখ্যাকারীতে group-by-origin বিবরণ দেখুন। হিমায়িত-প্রসঙ্গ মোড সম্ভাব্য সকল এক্সিকিউশন এনভায়রনমেন্ট পুনরায় ব্যবহার করতে পারে কিন্তু আপনার বিডিং স্ক্রিপ্টে পরিবর্তনের প্রয়োজন হতে পারে; আরও জানতে, ব্যাখ্যাকারীতে frozen-context বিবরণ দেখুন।

বিডিং স্ক্রিপ্টগুলি পুনরায় ব্যবহার করুন

যদি সম্ভব হয় স্বার্থ গোষ্ঠীর জন্য একই বিডিং স্ক্রিপ্ট ব্যবহার করুন। এটি ব্রাউজারকে একাধিক স্ক্রিপ্ট ডাউনলোড, পার্স এবং কম্পাইল করতে বাধা দেয় (যা অতিরিক্ত নেটওয়ার্ক অনুরোধ করে)। একই স্ক্রিপ্ট ব্যবহার করার সময় দরদাতারা এখনও আগ্রহের গোষ্ঠীর তথ্যের (যেমন name বা userBiddingSignals ) উপর ভিত্তি করে বিডিং আলাদা করতে পারে।

HTTP ক্যাশে কন্ট্রোল হেডার ছাড়া, বিডিং স্ক্রিপ্ট ক্যাশে করা হয় না। স্ক্রিপ্টটি অপ্রয়োজনীয়ভাবে আনা হয় না তা নিশ্চিত করতে উপযুক্ত শিরোনামগুলি নির্দিষ্ট করুন৷ সমান্তরালভাবে চলমান পৃষ্ঠায় একাধিক নিলাম থাকলে, একই দরদাতার বিডিং স্ক্রিপ্ট পুনরায় ব্যবহার করা হবে যদি এটি ইতিমধ্যেই মেমরিতে থাকে, ক্যাশিং শব্দার্থকে উপেক্ষা করে। যদি নিলামগুলি ক্রমানুসারে চলে, তাহলে ব্রাউজারটি HTTP ক্যাশিং প্রক্রিয়া মেনে চলবে।

মনে রাখবেন যে ব্রাউজারটি বিড করার সময় ( generateBid() ) এবং রিপোর্টিং সময় ( reportWin() এর জন্য) বিডিং স্ক্রিপ্ট লোড করে। যদি ক্যাশে কন্ট্রোল হেডার সেট করা না থাকে, তাহলে ব্রাউজার একই স্ক্রিপ্ট দুবার আনবে, প্রতিটি সময়ের জন্য একবার।

অতএব, আমরা আপনার সমস্ত স্ক্রিপ্টে ক্যাশে নিয়ন্ত্রণ শিরোনাম সেট করার পরামর্শ দিই।

trustedBiddingSignalsUrls পুনরায় ব্যবহার করুন

নেটওয়ার্ক লেটেন্সি এবং রিসোর্স ব্যবহার খুবই তাৎপর্যপূর্ণ হতে পারে। কম রিয়েল-টাইম বিশ্বস্ত বিডিং সিগন্যাল আনা এই বিলম্ব কমাতে সাহায্য করতে পারে।

বিশ্বস্ত বিডিং সিগন্যাল ফেচগুলিকে একত্রিত করা যেতে পারে যখন trustedBiddingSignalsUrl একাধিক আগ্রহের গোষ্ঠীর মধ্যে পুনরায় ব্যবহার করা হয়৷ যখন সম্ভব, সমস্ত আগ্রহ গ্রুপের জন্য একই trustedBiddingSignalsUrl ব্যবহার করুন।

একটি নির্দিষ্ট ওয়েব পৃষ্ঠায় বিজ্ঞাপন স্লট জুড়ে বিশ্বস্ত বিডিং সিগন্যাল ফেচগুলি ক্যাশে করা হয়েছে তা নিশ্চিত করতে উপযুক্ত HTTP ক্যাশে নিয়ন্ত্রণ শিরোনামগুলি নির্দিষ্ট করুন৷ trustedBiddingSignalsSlotSizeMode slot-size সেট করা এড়িয়ে চলুন কারণ অনুরোধ করা ইউআরএল আলাদা হওয়ার কারণে স্লটের আকার ভিন্ন হলে এটি বিজ্ঞাপন স্লট জুড়ে ক্যাশিং প্রতিরোধ করবে।

ছোট রিয়েল-টাইম বিশ্বস্ত বিডিং সিগন্যাল পাওয়া যায়

নেটওয়ার্ক লেটেন্সি খুব তাৎপর্যপূর্ণ হতে পারে, এবং এটি রিয়েল-টাইম বিশ্বস্ত বিডিং সিগন্যাল আনার সময় কতটা ডেটা স্থানান্তরিত হয় তার দ্বারা সরাসরি প্রভাবিত হয়।

রিয়েল-টাইম বিশ্বস্ত বিডিং সিগন্যাল পরিষেবার পরিবর্তে আগ্রহের গোষ্ঠীতে বিজ্ঞাপন-নির্দিষ্ট বা আগ্রহ-গোষ্ঠী-নির্দিষ্ট ডেটা সংরক্ষণ করা পছন্দ করুন৷ রিয়েল-টাইম বিশ্বস্ত বিডিং সিগন্যাল ডেটা শুধুমাত্র সেই সত্যিকারের রিয়েল-টাইম সিগন্যালের জন্য সংরক্ষণ করুন, যেমন ক্যাম্পেইন বাজেটিং বা কিল-সুইচ।

যেকোন সংকেত যা দৈনিক বা তার বেশি সময়ের ভিত্তিতে আপডেট করা যেতে পারে তা আগ্রহের গোষ্ঠীতে সংরক্ষণ করা উচিত এবং দৈনিক আপডেটগুলি ব্যবহার করে আপডেট করা উচিত।

"আপনার কী/মূল্য পরিষেবাতে বিডিং থেকে আগ্রহের গোষ্ঠীগুলিকে ফিল্টার করুন" বিভাগে বর্ণিত সুদ গোষ্ঠীগুলির জন্য বিশ্বস্ত বিডিং সংকেতগুলি ফেরত দেবেন না যা ফিল্টার করা হয়েছে৷

স্বার্থ গ্রুপ অগ্রাধিকার

প্রকাশক পৃষ্ঠাগুলিতে ব্রাউজার সংস্থানগুলি কীভাবে ব্যবহার করা হয় তা সীমিত করতে বিক্রেতারা টাইমআউট ব্যবহার করবে। যখন perBuyerCumulativeTimeouts ব্যবহার করা হয় ক্রেতাদের তাদের বিশ্বস্ত বিডিং সিগন্যাল আনতে এবং তাদের বিডিং স্ক্রিপ্টগুলি কার্যকর করতে কতক্ষণ সীমিত করতে, ক্রেতাদের জন্য এটি গুরুত্বপূর্ণ যে তারা তাদের আগ্রহের গোষ্ঠীগুলিকে অগ্রাধিকার দেয় যাতে নিলামে জয়ী হওয়ার সম্ভাবনা বেশি থাকে তারা প্রথমে সম্পাদন করে৷ উদাহরণস্বরূপ, যদি perBuyerCumulativeTimeouts 100 ms-এ সেট করা থাকে এবং একজন দরদাতার বিশ্বস্ত বিডিং সিগন্যাল আনতে 50 ms লাগে এবং প্রতিটি generateBid() ইনভোকেশান 10ms লাগে এবং তাদের একটি ডিভাইসে 10টি স্বার্থ গোষ্ঠী উপস্থিত থাকে, তাহলে তাদের আগ্রহের গোষ্ঠীর মাত্র অর্ধেক হবে বিড গণনা করার সুযোগ। এই উদাহরণে ক্রেতার তাদের আগ্রহের গোষ্ঠীগুলিকে অগ্রাধিকার দেওয়া উচিত যাতে সর্বাধিক-সম্ভাব্য-টু-জিত থেকে কম-সম্ভাব্য-টু-জয় হয়৷

আগ্রহের গোষ্ঠীগুলি তাদের priority ক্ষেত্রের সাথে সংজ্ঞায়িত স্ট্যাটিক অগ্রাধিকার ধারণ করতে পারে। আগ্রহের গোষ্ঠীগুলি গতিশীল অগ্রাধিকারগুলিও ব্যবহার করতে পারে যা তাদের বিশ্বস্ত বিডিং সংকেত পরিষেবাতে গণনা করা যেতে পারে এবং বিশ্বস্ত বিডিং সংকেত আনার priorityVector প্রতিক্রিয়া সহ ব্রাউজারে ফিরে আসে৷

মনে রাখবেন যে যখন ব্রাউজার আগ্রহের গোষ্ঠীগুলিকে সর্বোচ্চ অগ্রাধিকার থেকে সর্বনিম্ন পর্যন্ত চালায়, তখন এটি বিভিন্ন যোগদানের উত্স থেকে আগ্রহের গোষ্ঠীগুলিকে ছেদ করতে পারে যা group-by-origin অপ্টিমাইজেশানকে হারাতে পারে।

বিক্রেতার সর্বোত্তম অনুশীলন

আপনি সুরক্ষিত দর্শক API নিলাম দক্ষতার জন্য নিরীক্ষণ এবং অপ্টিমাইজ করছেন তা নিশ্চিত করুন৷

নিলাম সমান্তরাল

আধুনিক নেটওয়ার্ক সংযোগ এবং মাল্টি-কোর প্রসেসর একসাথে একাধিক ক্রিয়াকলাপ সম্পাদন করে একটি দুর্দান্ত কাজ করে। ব্রাউজারটি অন্যান্য ক্রিয়াকলাপের সাথে সমান্তরালে একটি সুরক্ষিত শ্রোতা নিলাম চালাতে পারে। যত তাড়াতাড়ি সম্ভব runAdAuction() কল করার মাধ্যমে এটি সর্বোত্তমভাবে সহজতর করা যেতে পারে। runAdAuction() এর জন্য কিছু ইনপুট প্রাথমিকভাবে উপলব্ধ নাও হতে পারে, উদাহরণস্বরূপ, যেগুলিকে প্রাসঙ্গিক প্রতিক্রিয়াতে ব্রাউজারে ফেরত পাঠানো হয়, ব্রাউজারটি উপলব্ধ হওয়ার আগে runAdAution() কল করার অনুমতি দেয় এবং পরে এই ইনপুটগুলি প্রদান করে। জাভাস্ক্রিপ্ট প্রতিশ্রুতি ব্যবহার করে সময়। নিলামের সম্ভাব্য সর্বনিম্ন লেটেন্সি অর্জন করতে, যখন interestGroupBuyers ইনপুট জানা যায় তখন runAdAuction() কল করা উচিত। এটি নিলামের অনেক অংশকে অবিলম্বে শুরু করার অনুমতি দেয়, যার মধ্যে দরদাতার রিয়েল-টাইম বিডিং সিগন্যাল পাওয়া যায়।

আপনার নিলাম নিরীক্ষণ

আপনার নিলামে মেট্রিক্স সংগ্রহ করুন। ব্রাউজারটি বিক্রেতাদের per-buyer বিলম্বের মেট্রিক্সের প্রতিবেদন করতে পারে যা একজন বিক্রেতার নিলামে কীভাবে সময় ব্যয় হয় সে সম্পর্কে অনেক অন্তর্দৃষ্টি প্রদান করে। বিক্রেতারা তাদের নিলাম অপ্টিমাইজ করার উপায়গুলি সন্ধান করতে এই মেট্রিকগুলি ব্যবহার করতে পারে, কীভাবে সবচেয়ে কার্যকরভাবে টাইমআউট সেট করতে হয় তা জানানো সহ। বিক্রেতারা তাদের আরও অপ্টিমাইজ করতে সহায়তা করার জন্য ক্রেতার সাথে একটি নির্দিষ্ট ক্রেতার লেটেন্সি মেট্রিক্স শেয়ার করতে পারে।

দরদাতাদের তাদের নিজস্ব স্বার্থ গোষ্ঠীর বিডিং কর্মক্ষমতা সম্পর্কে অন্তর্দৃষ্টি থাকতে পারে, কিন্তু তারা অন্য দরদাতাদের সাথে এটি তুলনা করতে সক্ষম নাও হতে পারে। বিভিন্ন দরদাতাদের জন্য আপেক্ষিক জয়ের হার এবং বিড প্রত্যাখ্যানের হারের তুলনা করা এমন ক্ষেত্রে সনাক্ত করতে সাহায্য করতে পারে যেখানে সুদ গোষ্ঠীগুলি কখনই কার্যকর বিড তৈরি করে না বা অননুমোদিত সৃজনশীলগুলির সাথে অতিরিক্ত বিডিংয়ের কারণে বিডিং কম্পিউট রিসোর্স নষ্ট হয়েছিল।

ধীর বিড স্ক্রিপ্ট থেকে রক্ষা করুন

বিডিং স্ক্রিপ্টগুলি যেগুলি অতিরিক্ত সময় নেয় সেগুলি জড়িত প্রত্যেকের জন্য সুরক্ষিত দর্শক API নিলামকে কমিয়ে দিতে পারে৷ টাইমআউট ব্যবহার করা ধীর নিলাম প্রতিরোধ করতে পারে যখন নিলাম ধীর হয় তখনও রাজস্ব পুনরুদ্ধার করতে পারে।

বিক্রেতাদের ধীর নিলাম প্রতিরোধ করতে perBuyerCumulativeTimeouts ব্যবহার করা উচিত এবং যখন নিলাম ধীর হয় এবং সময় শেষ হয়ে যায় তখনও বিডগুলি গ্রহণ করা উচিত। perBuyerCumulativeTimeouts ব্যবহার করা perBuyerTimeouts এবং perBuyerGroupLimits ব্যবহার করার চেয়ে পছন্দনীয় কারণ perBuyerCumulativeTimeouts সুদের গ্রুপের সংখ্যা বা generateBid() এর গতি সম্পর্কে মতামত দেয় না (যেমন অনেক স্বার্থ গোষ্ঠী যারা দ্রুত বিড করে এবং কিছু স্বার্থ গোষ্ঠী যারা ধীরে ধীরে বিড করে উভয় সময় শেষ করতে পারে)।

একটি সামগ্রিক নিলামের সময়সীমা কার্যকর করতে নিলাম কনফিগারেশন signal ক্ষেত্র ব্যবহার করাও এমন ক্ষেত্রে অত্যধিক দীর্ঘ নিলাম প্রতিরোধ করার জন্য একটি ভাল ধারণা যেখানে বিশ্বস্ত স্কোরিং সিগন্যাল সংগ্রহ করা এবং scoreAd() কার্যকর করতে খুব বেশি সময় লাগে৷

গুরুত্বপূর্ণ: নিলামের সময় সম্পর্কে একটি নোট - লোকেরা প্রায়শই জিজ্ঞাসা করে "একটি সুরক্ষিত শ্রোতা নিলামে কতক্ষণ লাগে?", "বিক্রেতার সময়সীমা কী সেট করা উচিত?" অথবা "একজন ক্রেতার কোন বিলম্বের জন্য অপ্টিমাইজ করা উচিত?"। এই প্রশ্নগুলোর উত্তর নির্ভর করে নিলামে অংশগ্রহণকারীরা কিসের জন্য অপ্টিমাইজ করছে তার উপর। বিক্রেতারা ওয়েবসাইট বিজ্ঞাপনের আয় বাড়াতে চাইতে পারে, সেক্ষেত্রে তাদের বিভিন্ন সময়সীমার সাথে পরীক্ষা করা উচিত যাতে আয় সর্বাধিক হয়। ডেস্কটপ এবং মোবাইলের জন্য আলাদা টাইমআউট থাকা দরকারী হতে পারে। সুরক্ষিত শ্রোতাদের ব্যবহার সময়ের সাথে সাথে পরিবর্তিত হতে পারে যখন গ্রহণ বৃদ্ধি পায়, নিলামে অংশগ্রহণকারীরা তাদের যুক্তিকে অপ্টিমাইজ করে, বা কম্পিউটারের বিকাশ ঘটে, তাই অব্যাহত পরীক্ষা-নিরীক্ষা উপকারী হতে পারে। ক্রেতারা যদি সবচেয়ে বেশি নিলাম জেতার জন্য অপ্টিমাইজ করে থাকেন, তাহলে তাদের উচিত তাদের বিশ্বস্ত বিডিং সিগন্যাল লেটেন্সি এবং generateBid() লেটেন্সি নিরীক্ষণ এবং অপ্টিমাইজ করা এবং তাদের আগ্রহের গোষ্ঠীগুলিকে অগ্রাধিকার দেওয়ার কথা বিবেচনা করা যাতে বিক্রেতারা কঠোর সময়সীমা নির্ধারণ করে তারা প্রথমে তাদের সেরা বিড তৈরি করে৷

এরপর কি?

আমরা প্রত্যেকের জন্য কাজ করে এমন একটি API তৈরি নিশ্চিত করতে আপনার সাথে কথোপকথনে নিযুক্ত হতে চাই।

API নিয়ে আলোচনা কর

অন্যান্য গোপনীয়তা স্যান্ডবক্স API-এর মতো, এই APIটি নথিভুক্ত এবং সর্বজনীনভাবে আলোচনা করা হয় ।

API এর সাথে পরীক্ষা করুন

আপনি সুরক্ষিত শ্রোতা API সম্পর্কে কথোপকথনে পরীক্ষা করতে এবং অংশগ্রহণ করতে পারেন৷