Ad Manager SOAP API হল আপনার Ad Manager ডেটা পড়া এবং লেখা এবং রিপোর্ট চালানোর জন্য একটি লিগ্যাসি API। যদি আপনি মাইগ্রেট করতে পারেন, তাহলে আমরা Ad Manager API (বিটা) ব্যবহার করার পরামর্শ দিচ্ছি। তবে, Ad Manager SOAP API ভার্সনগুলি তাদের সাধারণ জীবনচক্রের জন্য সমর্থিত। আরও তথ্যের জন্য, Ad Manager SOAP API অবচয় সময়সূচী দেখুন।
নিম্নলিখিত নির্দেশিকাটিতে Ad Manager SOAP API এবং Ad Manager API (বিটা) এর মধ্যে পার্থক্যগুলি বর্ণনা করা হয়েছে।
শেখা
স্ট্যান্ডার্ড অ্যাড ম্যানেজার SOAP API পরিষেবা পদ্ধতিতে অ্যাড ম্যানেজার API-তে সমতুল্য ধারণা রয়েছে। অ্যাড ম্যানেজার API-তে একক সত্তা পড়ার পদ্ধতিও রয়েছে। নিম্নলিখিত টেবিলে Order পদ্ধতির জন্য একটি উদাহরণ ম্যাপিং দেখানো হয়েছে:
| সাবান পদ্ধতি | REST পদ্ধতি |
|---|---|
getOrdersByStatement | networks.orders.getnetworks.orders.list |
প্রমাণীকরণ করুন
অ্যাড ম্যানেজার এপিআই (বিটা) দিয়ে প্রমাণীকরণ করতে, আপনি আপনার বিদ্যমান অ্যাড ম্যানেজার এসওএপি এপিআই ক্রেডেনশিয়াল ব্যবহার করতে পারেন অথবা নতুন তৈরি করতে পারেন। যেকোনো বিকল্পের ক্ষেত্রে, আপনাকে প্রথমে আপনার গুগল ক্লাউড প্রোজেক্টে অ্যাড ম্যানেজার এপিআই সক্ষম করতে হবে। আরও বিস্তারিত জানার জন্য, প্রমাণীকরণ দেখুন।
যদি আপনি একটি ক্লায়েন্ট লাইব্রেরি ব্যবহার করেন, তাহলে আপনার পরিষেবা অ্যাকাউন্ট কী ফাইলের পাথে পরিবেশ পরিবর্তনশীল GOOGLE_APPLICATION_CREDENTIALS সেট করে অ্যাপ্লিকেশন ডিফল্ট শংসাপত্র সেট আপ করুন। আরও বিস্তারিত জানার জন্য, অ্যাপ্লিকেশন ডিফল্ট শংসাপত্র কীভাবে কাজ করে তা দেখুন।
যদি আপনি ইনস্টলড অ্যাপ্লিকেশন শংসাপত্র ব্যবহার করেন, তাহলে নিম্নলিখিত ফর্ম্যাটে একটি JSON ফাইল তৈরি করুন এবং পরিবেশ ভেরিয়েবলটিকে তার পথে সেট করুন:
{
"client_id": "CLIENT_ID",
"client_secret": "CLIENT_SECRET",
"refresh_token": "REFRESH_TOKEN",
"type": "authorized_user"
}
নিম্নলিখিত মানগুলি প্রতিস্থাপন করুন:
-
CLIENT_ID: আপনার নতুন অথবা বিদ্যমান ক্লায়েন্ট আইডি। -
CLIENT_SECRET: আপনার নতুন বা বিদ্যমান ক্লায়েন্ট গোপনীয়তা। REFRESH_TOKEN: আপনার নতুন বা বিদ্যমান রিফ্রেশ টোকেন।
লিনাক্স বা ম্যাকওএস
export GOOGLE_APPLICATION_CREDENTIALS=KEY_FILE_PATHজানালা
set GOOGLE_APPLICATION_CREDENTIALS=KEY_FILE_PATH
ফিল্টারের পার্থক্যগুলি বুঝুন
অ্যাড ম্যানেজার এপিআই (বিটা) কোয়েরি ভাষা সমস্ত প্রকাশক কোয়েরি ভাষা (PQL) বৈশিষ্ট্য সমর্থন করে, তবে উল্লেখযোগ্য বাক্য গঠনের পার্থক্য রয়েছে।
Order অবজেক্ট তালিকাভুক্ত করার এই উদাহরণটি বাইন্ড ভেরিয়েবল অপসারণ, কেস সংবেদনশীল অপারেটর এবং ORDER BY এবং LIMIT ক্লজগুলিকে পৃথক ক্ষেত্র দিয়ে প্রতিস্থাপনের মতো প্রধান পরিবর্তনগুলি চিত্রিত করে:
বিজ্ঞাপন পরিচালক SOAP API
<filterStatement>
<query>WHERE name like "PG_%" and lastModifiedDateTime >= :lastModifiedDateTime ORDER BY id ASC LIMIT 500</query>
<values>
<key>lastModifiedDateTime</key>
<value xmlns:ns2="https://www.google.com/apis/ads/publisher/v202502" xsi:type="ns2:DateTimeValue">
<value>
<date>
<year>2024</year>
<month>1</month>
<day>1</day>
</date>
<hour>0</hour>
<minute>0</minute>
<second>0</second>
<timeZoneId>America/New_York</timeZoneId>
</value>
</value>
</values>
</filterStatement>
বিজ্ঞাপন পরিচালক API (বিটা)
JSON ফর্ম্যাট
{
"filter": "displayName = \"PG_*\" AND updateTime > \"2024-01-01T00:00:00-5:00\"",
"pageSize": 500,
"orderBy": "name"
}
ইউআরএল এনকোড করা আছে
GET https://admanager.googleapis.com/v1/networks/123/orders?filter=displayName+%3D+\"PG_*\"+AND+updateTime+%3E+\"2024-01-01T00%3A00%3A00-5%3A00\"
অ্যাড ম্যানেজার এপিআই (বিটা) সমস্ত PQL ক্ষমতা সমর্থন করে, অ্যাড ম্যানেজার SOAP এপিআই থেকে নিম্নলিখিত সিনট্যাক্স পার্থক্যগুলি সহ:
অ্যাড ম্যানেজার এপিআই (বিটা) তে
ANDএবংORঅপারেটর দুটি কেস সেনসিটিভ । ছোট হাতের অক্ষরandএবংorখালি আক্ষরিক অনুসন্ধান স্ট্রিং হিসেবে বিবেচনা করা হয়, যা অ্যাড ম্যানেজার এপিআই (বিটা) তে বিভিন্ন ক্ষেত্র জুড়ে অনুসন্ধান করার জন্য একটি বৈশিষ্ট্য।বড় হাতের অপারেটর ব্যবহার করুন
// Matches unarchived Orders where order.notes has the value 'lorem ipsum'. notes = "lorem ipsum" AND archived = falseছোট হাতের অক্ষরকে আক্ষরিক হিসেবে বিবেচনা করা হবে
// Matches unarchived Orders where order.notes has the value 'lorem ipsum' // and any field in the order has the literal value 'and'. notes = "lorem ipsum" and archived = false*অক্ষরটি স্ট্রিং ম্যাচিংয়ের জন্য একটি ওয়াইল্ডকার্ড। অ্যাড ম্যানেজার এপিআই (বিটা)likeঅপারেটর সমর্থন করে না।বিজ্ঞাপন পরিচালক SOAP API PQL
// Matches orders where displayName starts with the string 'PG_' displayName like "PG_%"বিজ্ঞাপন পরিচালক API (বিটা)
// Matches orders where displayName starts with the string 'PG_' displayName = "PG_*"ক্ষেত্রের নামগুলি তুলনামূলক অপারেটরের বাম দিকে উপস্থিত হওয়া উচিত:
বৈধ ফিল্টার
updateTime > "2024-01-01T00:00:00Z"অবৈধ ফিল্টার
"2024-01-01T00:00:00Z" < updateTimeঅ্যাড ম্যানেজার এপিআই (বিটা) বাইন্ড ভেরিয়েবল সমর্থন করে না। সমস্ত মান অবশ্যই ইনলাইন করতে হবে।
স্পেস ধারণকারী স্ট্রিং লিটারেলগুলিকে অবশ্যই ডাবল কোটেশনে মোড়ানো উচিত, উদাহরণস্বরূপ,
"Foo bar"। স্ট্রিং লিটারেল মোড়ানোর জন্য আপনি একক উদ্ধৃতি ব্যবহার করতে পারবেন না।
ধারা অনুসারে ক্রম সরান
অ্যাড ম্যানেজার এপিআই (বিটা) তে সাজানোর ক্রম নির্দিষ্ট করা ঐচ্ছিক। আপনি যদি আপনার ফলাফল সেটের জন্য সাজানোর ক্রম নির্দিষ্ট করতে চান, তাহলে PQL ORDER BY ক্লজটি সরিয়ে orderBy ফিল্ডটি সেট করুন:
GET networks/${NETWORK_CODE}/orders?orderBy=updateTime+desc
অফসেট থেকে পৃষ্ঠাঙ্কন টোকেনে স্থানান্তর করুন
অ্যাড ম্যানেজার এপিআই (বিটা) বৃহৎ ফলাফল সেটের মাধ্যমে পেজিংয়ের জন্য LIMIT এবং OFFSET ক্লজের পরিবর্তে পেজিনেশন টোকেন ব্যবহার করে।
বিজ্ঞাপন পরিচালক API (বিটা) পৃষ্ঠার আকার নিয়ন্ত্রণ করার জন্য একটি pageSize প্যারামিটার ব্যবহার করে। বিজ্ঞাপন পরিচালক SOAP API-তে LIMIT ক্লজের বিপরীতে, পৃষ্ঠার আকার বাদ দিলে সম্পূর্ণ ফলাফল সেট ফেরত আসে না । পরিবর্তে, তালিকা পদ্ধতিটি 50 এর একটি ডিফল্ট পৃষ্ঠার আকার ব্যবহার করে। নিম্নলিখিত উদাহরণটি URL প্যারামিটার হিসাবে pageSize এবং pageToken সেট করে:
# Initial request
GET networks/${NETWORK_CODE}/orders?pageSize=50
# Next page
GET networks/${NETWORK_CODE}/orders?pageSize=50&pageToken=${TOKEN_FROM_INITIAL_REQUEST}
Ad Manager SOAP API-এর বিপরীতে, Ad Manager API (Beta) অতিরিক্ত পৃষ্ঠা থাকলেও অনুরোধ করা পৃষ্ঠার আকারের চেয়ে কম ফলাফল দিতে পারে। অতিরিক্ত ফলাফল আছে কিনা তা নির্ধারণ করতে nextPageToken ফিল্ড ব্যবহার করুন।
যদিও পেজিনেশনের জন্য অফসেটের প্রয়োজন হয় না, আপনি মাল্টিথ্রেডিংয়ের জন্য skip ফিল্ড ব্যবহার করতে পারেন। মাল্টিথ্রেডিং করার সময়, একই ফলাফল সেট থেকে পড়ছেন তা নিশ্চিত করার জন্য প্রথম পৃষ্ঠা থেকে পেজিনেশন টোকেন ব্যবহার করুন:
# First thread
GET networks/${NETWORK_CODE}/orders?pageSize=50&pageToken=${TOKEN_FROM_INITIAL_REQUEST}
# Second thread
GET networks/${NETWORK_CODE}/orders?pageSize=50&pageToken=${TOKEN_FROM_INITIAL_REQUEST}&skip=50
মাইগ্রেট রিপোর্ট
SOAP API শুধুমাত্র অবচিত রিপোর্ট টুলে রিপোর্ট পড়তে এবং চালাতে পারে। বিপরীতে, REST API শুধুমাত্র ইন্টারেক্টিভ রিপোর্ট পড়তে, লিখতে এবং চালাতে পারে।
রিপোর্টিং টুল এবং API গুলির একটি আলাদা ID স্পেস থাকে। SOAP API তে SavedQuery এর ID REST API তে ব্যবহার করা যাবে না।
যদি আপনি SavedQuery ব্যবহার করেন, তাহলে আপনি UI-তে একটি ইন্টারেক্টিভ রিপোর্টে রিপোর্টটি মাইগ্রেট করতে পারেন এবং দুটি আইডি স্পেসের মধ্যে একটি ম্যাপিং তৈরি করতে পারেন। রিপোর্ট মাইগ্রেট করার বিষয়ে আরও তথ্যের জন্য, "রিপোর্টগুলিকে ইন্টারেক্টিভ রিপোর্টে মাইগ্রেট করুন" দেখুন।
API এর পার্থক্যগুলি বুঝুন
SOAP API এবং REST API কীভাবে রিপোর্ট সংজ্ঞা এবং ফলাফল পরিচালনা করে তার মধ্যে কিছু পার্থক্য রয়েছে:
যখন কোনও রিপোর্ট শুধুমাত্র
NAMEঅনুরোধ করে, তখন SOAP API স্বয়ংক্রিয়ভাবে ফলাফলগুলিতে একটি সংশ্লিষ্টIDমাত্রা যোগ করে। REST API-তে, ফলাফলগুলিতে অন্তর্ভুক্ত করার জন্য আপনাকেReportDefinitionএIDমাত্রা স্পষ্টভাবে যোগ করতে হবে।SOAP API-তে মেট্রিক্সের জন্য স্পষ্ট প্রকার ছিল না। REST API একটি ডেটা টাইপ সংজ্ঞায়িত করে, যা
Dimensionenum মানের উপর নথিভুক্ত। মনে রাখবেন যেENUMমাত্রাগুলি খোলা enums । ফলাফল বিশ্লেষণ করার সময় আপনাকে অবশ্যই নতুন এবং অজানা enum মানগুলি পরিচালনা করতে হবে।SOAP API
DimensionsএবংDimensionAttributesআলাদা করে। REST API-তে একটি ইউনিফাইডDimensionenum আছে যাতে উভয়ই থাকে।SOAP API-তে মাত্রার সংখ্যার কোনও সীমা ছিল না। ইন্টারেক্টিভ রিপোর্টগুলিতে UI এবং API উভয় ক্ষেত্রেই 10টি মাত্রার সীমা রয়েছে। একই ID স্পেস দ্বারা বিভক্ত মাত্রাগুলিকে একটি একক মাত্রা হিসাবে গণনা করা হয়। উদাহরণস্বরূপ,
ORDER_NAME,ORDER_ID, এবংORDER_START_DATEসহ সীমা গণনা করার সময় শুধুমাত্র 1টি মাত্রা হিসাবে গণনা করা হয়।