সর্বোত্তম অনুশীলন এবং সীমাবদ্ধতা

BatchJobService ব্যবহার করার সময় এই নির্দেশিকাগুলো বিবেচনা করুন।

থ্রুপুট উন্নত করুন

  • অনেক ছোট ছোট কাজের চেয়ে কম সংখ্যক বড় কাজ বেশি পছন্দনীয়।

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

  • একই ধরনের অপারেশনগুলোর মধ্যে, সেগুলোকে প্যারেন্ট রিসোর্স অনুযায়ী গ্রুপ করলে পারফরম্যান্স উন্নত হতে পারে। উদাহরণস্বরূপ, যদি আপনার কাছে একাধিক AdGroupCriterionOperation অবজেক্ট থাকে, তবে বিভিন্ন অ্যাড গ্রুপের ক্রাইটেরিয়াকে প্রভাবিত করে এমন অপারেশনগুলোকে একসাথে মেশানোর পরিবর্তে, অ্যাড গ্রুপ অনুযায়ী অপারেশনগুলোকে গ্রুপ করা বেশি কার্যকর।

ব্যাচ স্প্লিটিং-এ পারমাণবিকতা

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

  • একই AdGroup লক্ষ্য করে LISTING_GROUP ক্রাইটেরিয়ার ( AdGroupCriterion.listing_group ) জন্য পরপর AdGroupCriterionOperation অপারেশনগুলো ( create , update , এবং remove ) চালানো (যদি গ্রুপের কোনো অপারেশন ব্যর্থ হয়, তবে এটি CriterionError.LISTING_GROUP_ERROR_IN_ANOTHER_OPERATION সাথে ব্যর্থ হয়)।
  • একই AssetGroup লক্ষ্য করে পরপর AssetGroupListingGroupFilterOperation অপারেশনগুলো ( create , update এবং remove ) চালানো হলে (গ্রুপের কোনো অপারেশন ব্যর্থ হলে BatchJobError.ASSET_GROUP_LISTING_GROUP_FILTER_TRANSACTION_FAILURE ত্রুটির সাথে ব্যর্থ হয়)।
  • একটি AssetGroupOperation ( create ) এর ঠিক পরেই একই AssetGroup লক্ষ্য করে সর্বোচ্চ ৯৯৯টি AssetGroupAssetOperation ( create ) অপারেশন চালানো হয় (গ্রুপের কোনো অপারেশন ব্যর্থ হলে এটি BatchJobError.ASSET_GROUP_AND_ASSET_GROUP_ASSET_TRANSACTION_FAILURE সাথে ব্যর্থ হয়)। প্রতিটি AssetGroupOperation ( update বা remove ) তার নিজস্ব স্বতন্ত্র একক-অপারেশন সাব-ব্যাচে সম্পাদিত হয়।
  • ব্র্যান্ড গাইডলাইন সক্রিয় করা একটি পারফরম্যান্স ম্যাক্স CampaignOperation ( create ) ( brand_guidelines_enabled true সেট করে অথবা সেট না করে রেখে, কারণ এটি ডিফল্টরূপে true থাকে যদি না স্পষ্টভাবে false সেট করা হয় বা ভ্রমণের লক্ষ্যের জন্য পারফরম্যান্স ম্যাক্স ক্যাম্পেইন তৈরি করা হয়) এর ঠিক পরেই একই Campaign লক্ষ্য করে ৯৯৯টি পর্যন্ত CampaignAssetOperation ( create ) চালানো হয় (গ্রুপের কোনো অপারেশন ব্যর্থ হলে BatchJobError.CAMPAIGN_AND_CAMPAIGN_ASSET_TRANSACTION_FAILURE সাথে ব্যর্থ হয়)। রিটেইল পারফরম্যান্স ম্যাক্স ক্যাম্পেইন (মার্চেন্ট সেন্টার ফিড সহ) একই অ্যাটমিক সাব-ব্যাচে ব্র্যান্ড CampaignAsset রিসোর্স লিঙ্ক না করেই তৈরি করা যেতে পারে।

AssetGroup এবং Performance Max Campaign তৈরির সাব-ব্যাচ উভয়ের জন্য (প্রতি সাব-ব্যাচে মোট ১,০০০টি পর্যন্ত অপারেশন; ৯৯৯-এর বেশি যেকোনো চাইল্ড create অপারেশন পরবর্তী নন-অ্যাটমিক সাব-ব্যাচে চলে যাবে):

  • মূল create অপারেশন ( AssetGroup বা Campaign উপর resource_name ) এবং এর পরবর্তী চাইল্ড create অপারেশনগুলো ( AssetGroupAsset এর উপর asset_group অথবা CampaignAsset উপর campaign )-কে অবশ্যই একই নেগেটিভ টেম্পোরারি আইডি উল্লেখ করতে হবে।
  • নতুন Asset রিসোর্সের জন্য যেকোনো পূর্বশর্ত AssetOperation ( create ) অপারেশন প্যারেন্ট AssetGroupOperation বা CampaignOperation ( create )- এর আগে রাখুন; কখনোই প্যারেন্ট create এবং এর চাইল্ড লিঙ্ক create অপারেশনের মধ্যে রাখবেন না (যা অবিলম্বে অ্যাটমিক সাব-ব্যাচটি বন্ধ করে দেবে এবং প্যারেন্ট রিসোর্স তৈরিকে তার লিঙ্ক করা অ্যাসেটগুলো থেকে বিচ্ছিন্ন করে দেবে)।

যখন একটি অ্যাটমিক সাব-ব্যাচ ব্যর্থ হয়, তখন ত্রুটিপূর্ণ অপারেশনটির BatchJobResult.status এ অন্তর্নিহিত ভ্যালিডেশন ত্রুটিটি থাকে এবং সেই সাব-ব্যাচের বাকি অপারেশনগুলো সংশ্লিষ্ট ট্রানজ্যাকশন ত্রুটিসহ রোলব্যাক করা হয়। মূল কারণের ত্রুটি শনাক্ত করতে একই AdGroup , AssetGroup , বা Campaign ID শেয়ার করা সংলগ্ন BatchJobResult এন্ট্রিগুলো পরীক্ষা করুন।

এই গ্রুপগুলির কোনোটিতে সম্পর্কিত অপারেশনগুলি যদি ধারাবাহিকভাবে যোগ করা না হয়, তাহলে Google Ads API সেগুলিকে আলাদা সাব-ব্যাচে ভাগ করে দেয়, যার ফলে পরিবর্তনটি ন্যূনতম অ্যাসেট প্রয়োজনীয়তা পূরণে ব্যর্থ হয় অথবা লিস্টিং গ্রুপ ট্রি অসম্পূর্ণ থেকে যায়। বিস্তারিত জানার জন্য ব্যাচ জবে লিস্টিং গ্রুপ ফিল্টার ব্যবহার এবং পারফরম্যান্স ম্যাক্স ব্যাচ প্রসেসিং দেখুন।

যৌক্তিক দলবদ্ধকরণ

যখন কোনো প্রোডাক্ট টার্গেটিং হায়ারার্কি পরিবর্তন করা হয় (যেমন পারফরম্যান্স ম্যাক্স ক্যাম্পেইনে AssetGroupListingGroupFilterOperation অথবা শপিং ক্যাম্পেইনে AdGroupCriterionOperation ) বা একটি নতুন AssetGroup বা পারফরম্যান্স ম্যাক্স Campaign তৈরি করা হয়, তখন একই প্যারেন্ট রিসোর্সকে ( AssetGroup , AdGroup বা Campaign ) টার্গেট করে এমন সমস্ত অপারেশনকে ধারাবাহিকভাবে গ্রুপ করুন। এটি ব্যাকএন্ড লক কনটেনশন কমায় এবং পরস্পর নির্ভরশীল ট্রিগুলোকে একসাথে রাখে।

ডেটার সামঞ্জস্যতা

যেহেতু প্রতিটি অ্যাটমিক সাব-ব্যাচ ট্রানজ্যাকশনের শেষে লিস্টিং গ্রুপ ফিল্টার ট্রি এবং পারফরম্যান্স ম্যাক্স অ্যাসেট রিকোয়ারমেন্ট যাচাই করা হয়, তাই একটি জবের মধ্যে বা একাধিক সমান্তরাল জবের মধ্যে একই প্যারেন্ট রিসোর্সের আপডেটগুলোকে বিচ্ছিন্ন রেঞ্জে বিভক্ত করা পরিহার করুন।

যুগপৎ সমস্যা এড়িয়ে চলুন

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

  • একই জবে একই অবজেক্টকে পরিবর্তনকারী একাধিক অপারেশন জমা দেবেন না, কারণ এর ফলাফল অপ্রত্যাশিত হতে পারে।

সর্বোত্তমভাবে ফলাফল পুনরুদ্ধার করুন

  • কাজের অবস্থা খুব ঘন ঘন যাচাই করবেন না, নইলে রেট লিমিট এরর হওয়ার ঝুঁকি থাকবে।

  • পেজিনেশন রাউন্ড ট্রিপ কমানোর জন্য ListBatchJobResults কল করার সময় page_size সেট না করে রাখুন (অথবা এটিকে সর্বোচ্চ 1000 -এ সেট করুন), এবং শুধুমাত্র তখনই response_content_type MUTABLE_RESOURCE এ সেট করুন, যদি আপনার অ্যাপ্লিকেশন resource_name বাইরেও ফেরত আসা রিসোর্স ফিল্ডগুলো পরীক্ষা করে।

  • ফলাফলের ক্রম আপলোডের ক্রমের অনুরূপ।

অতিরিক্ত ব্যবহার নির্দেশিকা

  • একটি ব্যাচ জব বাতিল হওয়ার আগে কতক্ষণ চলতে পারবে, তার জন্য আপনি একটি সর্বোচ্চ সীমা নির্ধারণ করতে পারেন। নতুন ব্যাচ জব তৈরি করার সময়, metadata.execution_limit_seconds ফিল্ডটিতে আপনার পছন্দের সময়সীমা সেকেন্ডে সেট করুন। যদি metadata.execution_limit_seconds সেট করা না থাকে, তবে কোনো ডিফল্ট সময়সীমা থাকে না।

  • যদিও প্রোটোকলের সীমা প্রতি অনুরোধে ১০,০০০ অপারেশন, আমরা প্রতি AddBatchJobOperationsRequest এ ১,০০০-এর বেশি অপারেশন যোগ না করার এবং বাকি অপারেশনগুলো একই জবে আপলোড করার জন্য sequence_token ব্যবহার করার পরামর্শ দিই। অপারেশনের আকারের উপর নির্ভর করে, একটি একক AddBatchJobOperationsRequest এ খুব বেশি অপারেশন পাঠালে BatchJobError.REQUEST_TOO_LARGE ত্রুটি দেখা দিতে পারে। আপনি অপারেশনের সংখ্যা কমিয়ে এবং AddBatchJobOperationsRequest টি পুনরায় চেষ্টা করে এই ত্রুটিটি সমাধান করতে পারেন।

সীমাবদ্ধতা

  • প্রতিটি BatchJob সর্বোচ্চ দশ লক্ষ অপারেশন সমর্থন করে। AddBatchJobOperations কল করার সময় এই সীমা অতিক্রম করলে একটি ResourceCountLimitExceededError.RESOURCE_LIMIT ত্রুটি ফেরত আসে (যেখানে ErrorDetails.resource_count_detailsResourceLimitType.BATCH_JOB_OPERATIONS_PER_JOB থাকে)।

  • প্রতিটি অ্যাকাউন্টে একই সময়ে সর্বোচ্চ ১০০টি সক্রিয় বা অপেক্ষাধীন কাজ থাকতে পারে। MutateBatchJob ব্যবহার করে ব্যাচ জব তৈরি করার সময় এই সীমা অতিক্রম করলে একটি ResourceCountLimitExceededError.RESOURCE_LIMIT ত্রুটি ফেরত আসে (যেখানে ErrorDetails.resource_count_detailsResourceLimitType.BATCH_JOBS_PER_CUSTOMER থাকে)।

  • ৭ দিনের বেশি পুরোনো অমীমাংসিত কাজগুলো স্বয়ংক্রিয়ভাবে মুছে ফেলা হয়।

  • প্রতিটি AddBatchJobOperationsRequest , প্রতি অনুরোধে ১০,০০০ মিউটেট অপারেশনের একটি নির্দিষ্ট সীমা রয়েছে। একটি অনুরোধে ১০,০০০-এর বেশি অপারেশন করা হলে BatchJobError.REQUEST_TOO_LARGE ত্রুটি দেখা দেয়।

  • ListBatchJobResultsRequest এর page_size ফিল্ডের জন্য:

    • যদি page_size সেট করা না থাকে বা এর মান 0 হয়, তাহলে এটি ডিফল্টভাবে সর্বোচ্চ মান 1000 এ সেট হয়ে যায়।
    • যদি page_size 1000 বেশি হয়, অথবা 0 এর কম হয়, তাহলে API একটি BatchJobError.INVALID_PAGE_SIZE ত্রুটি ফেরত দেয়।
  • প্রতিটি AddBatchJobOperationsRequest এর সর্বোচ্চ আকার ৪১,৯৩৭,৯২০ বাইট। আপনি এই সীমা অতিক্রম করলে, একটি BatchJobError.REQUEST_TOO_LARGE ত্রুটি পাবেন (অথবা ট্রান্সপোর্ট লেয়ারে প্রত্যাখ্যাত হলে একটি INTERNAL_ERROR )। অনুরোধ জমা দেওয়ার আগে আপনি এর সিরিয়ালাইজড আকার নির্ধারণ করতে পারেন এবং এটি খুব বড় হলে উপযুক্ত ব্যবস্থা নিতে পারেন:

    জাভা

    
    static final int MAX_REQUEST_BYTES = 41_937_920;
    
    // ... (code to get the AddBatchJobOperationsRequest object)
    
    int sizeInBytes = request.getSerializedSize();
    

    সি#

    
    const int MAX_REQUEST_BYTES = 41_937_920;
    
    // ... (code to get the AddBatchJobOperationsRequest object)
    
    int sizeInBytes = request.CalculateSize();
    

    পিএইচপি

    
    const MAX_REQUEST_BYTES = 41937920;
    
    // ... (code to get the AddBatchJobOperationsRequest object)
    
    $size_in_bytes = $request->byteSize();
    

    পাইথন

    
    MAX_REQUEST_BYTES = 41_937_920
    
    # ... (code to get the AddBatchJobOperationsRequest object)
    
    size_in_bytes = type(request).pb(request).ByteSize()
    

    রুবি

    
    MAX_REQUEST_BYTES = 41_937_920
    
    # ... (code to get the AddBatchJobOperationsRequest object)
    
    size_in_bytes = request.to_proto.bytesize
    

    পার্ল

    
    use JSON::XS;
    use constant MAX_REQUEST_BYTES => 41937920;
    
    # ... (code to get the AddBatchJobOperationsRequest object)
    
    # The Perl client library uses REST/JSON; UTF-8 JSON byte length provides a
    # conservative upper-bound estimate of the serialized request size.
    my $json_encoder = JSON::XS->new->utf8->convert_blessed;
    my $size_in_bytes = length($json_encoder->encode($request));
    

একক মিউটেট অপারেশনের আকার

যদিও সামগ্রিক অনুরোধটি ৪১,৯৩৭,৯২০ বাইট পর্যন্ত হতে পারে, ব্যাচের মধ্যে একটি একক MutateOperation এর সিরিয়ালাইজড আকার ১০,৪৮৪,৫০৪ বাইটে (১০ MiB বিয়োগ ১,২৫৬ বাইট) সীমাবদ্ধ। এই সীমা অতিক্রম করলে একটি BatchJobError.REQUEST_TOO_LARGE ত্রুটি ফেরত আসে। উল্লেখ্য যে, যদিও BatchJobError.REQUEST_TOO_LARGE এর রেফারেন্স ডকুমেন্টেশনে ১০,৪৮৪,৫০৪-বাইটের থ্রেশহোল্ডের কথা উল্লেখ করা হয়েছে, AddBatchJobOperations এই একই ত্রুটি কোডটি ফেরত দেয় যখন তিনটি অনুরোধ থ্রেশহোল্ডের (মোট ৪১,৯৩৭,৯২০ অনুরোধ বাইট, ১০,৪৮৪,৫০৪ একক-অপারেশন বাইট, অথবা প্রতি কলে ১০,০০০ অপারেশন) যেকোনো একটি অতিক্রম করা হয়, এবং ত্রুটির message ফিল্ডে উল্লেখ করা থাকে কোন সীমাটি লঙ্ঘিত হয়েছে।