মোবাইল ওভারভিউ জন্য অ্যাট্রিবিউশন রিপোর্টিং

মতামত প্রদান

সাম্প্রতিক আপডেট

  • আসন্ন পরিবর্তন এবং পরিচিত সমস্যাগুলির তালিকা আপডেট করা হয়েছে৷
  • সম্পূর্ণ নমনীয় ইভেন্ট-লেভেল কনফিগারেশনের সেতু হিসাবে লাইট নমনীয় ইভেন্ট-লেভেল কনফিগারেশন প্রবর্তন করা হয়েছে
  • 2023 সালের সেপ্টেম্বর থেকে, registerWebSource , registerWebTrigger , registerAppSource এবং registerAppTrigger অবশ্যই এমন ক্ষেত্রগুলির জন্য স্ট্রিং ব্যবহার করতে হবে যা একটি সংখ্যাসূচক মান আশা করে (যেমন priority , source_event_id , debug_key , trigger_data deduplication_key ইত্যাদি) ,
  • Q4 2023-এ, Google ক্লাউডে অ্যাগ্রিগেশন পরিষেবা ব্যবহার করে সারাংশ রিপোর্ট তৈরি করতে Android অ্যাট্রিবিউশন রিপোর্টিং API-এ Google ক্লাউড সমর্থন যোগ করা হবে, আরও নির্দিষ্ট সময় এখানে প্রতিফলিত হয়েছে। Google ক্লাউডের সাথে অ্যাগ্রিগেশন পরিষেবা সেট আপ করার বিষয়ে আরও তথ্যের জন্য স্থাপনার নির্দেশিকা দেখুন।
  • অনন্য গন্তব্যের সংখ্যার জন্য নতুন গোপনীয়তা সংরক্ষণের হার সীমা।
  • লুকব্যাক উইন্ডো ট্রিগার ফিল্টারগুলির জন্য আপডেট করা কার্যকারিতা Q1 2024 এ আসবে, আরও তথ্যের জন্য নোটটি দেখুন।

ওভারভিউ

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

এই API এর নিম্নলিখিত কাঠামোগত প্রক্রিয়া রয়েছে যা গোপনীয়তা উন্নত করার জন্য একটি কাঠামো অফার করে, যা এই পৃষ্ঠার পরবর্তী বিভাগগুলি আরও বিশদে বর্ণনা করে:

পূর্ববর্তী প্রক্রিয়া দুটি ভিন্ন অ্যাপ বা ডোমেন জুড়ে ব্যবহারকারীর পরিচয় লিঙ্ক করার ক্ষমতা সীমিত করে।

অ্যাট্রিবিউশন রিপোর্টিং API নিম্নলিখিত ব্যবহারের ক্ষেত্রে সমর্থন করে:

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

উচ্চ স্তরে, অ্যাট্রিবিউশন রিপোর্টিং API নিম্নরূপ কাজ করে, যা এই নথির পরবর্তী বিভাগগুলি আরও বিশদে বর্ণনা করে:

  1. বিজ্ঞাপন প্রযুক্তি অ্যাট্রিবিউশন রিপোর্টিং API ব্যবহার করার জন্য একটি তালিকাভুক্তি প্রক্রিয়া সম্পন্ন করে ।
  2. বিজ্ঞাপন প্রযুক্তি অ্যাট্রিবিউশন রিপোর্টিং এপিআই-এর সাহায্যে অ্যাট্রিবিউশন উৎস—বিজ্ঞাপন ক্লিক বা ভিউ-এর নিবন্ধন করে ।
  3. বিজ্ঞাপন প্রযুক্তি নিবন্ধন করে — বিজ্ঞাপনদাতা অ্যাপ বা ওয়েবসাইটে ব্যবহারকারীর রূপান্তর — অ্যাট্রিবিউশন রিপোর্টিং API-এর সাহায্যে৷
  4. অ্যাট্রিবিউশন রিপোর্টিং এপিআই অ্যাট্রিবিউশন সোর্সের সাথে ট্রিগারের সাথে মেলে—একটি রূপান্তর অ্যাট্রিবিউশন—এবং এক বা একাধিক ট্রিগার ইভেন্ট-লেভেল এবং বিজ্ঞাপন প্রযুক্তিতে সমষ্টিগত প্রতিবেদনের মাধ্যমে অফ-ডিভাইস পাঠানো হয়।

অ্যাট্রিবিউশন রিপোর্টিং এপিআই-এ অ্যাক্সেস পান

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

একটি অ্যাট্রিবিউশন উত্স নিবন্ধন করুন (ক্লিক করুন বা দেখুন)

অ্যাট্রিবিউশন রিপোর্টিং এপিআই বিজ্ঞাপনের ক্লিক এবং ভিউকে অ্যাট্রিবিউশন উৎস হিসেবে বোঝায়। একটি বিজ্ঞাপন ক্লিক বা বিজ্ঞাপন দৃশ্য নিবন্ধন করতে, registerSource() কল করুন। এই API নিম্নলিখিত পরামিতি আশা করে:

  • অ্যাট্রিবিউশন সোর্স ইউআরআই: অ্যাট্রিবিউশন সোর্সের সাথে যুক্ত মেটাডেটা আনার জন্য প্ল্যাটফর্ম এই ইউআরআই-কে একটি অনুরোধ জারি করে।
  • ইনপুট ইভেন্ট: হয় একটি InputEvent অবজেক্ট (একটি ক্লিক ইভেন্টের জন্য) অথবা null (একটি ভিউ ইভেন্টের জন্য)।

এপিআই যখন অ্যাট্রিবিউশন সোর্স ইউআরআই-এর কাছে একটি অনুরোধ করে, তখন বিজ্ঞাপন প্রযুক্তিকে নিম্নলিখিত ক্ষেত্রগুলির সাথে একটি নতুন HTTP হেডার Attribution-Reporting-Register-Source এ অ্যাট্রিবিউশন সোর্স মেটাডেটার সাথে সাড়া দেওয়া উচিত:

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

    যখন একটি ট্রিগার প্রাপ্ত হয়, API সর্বোচ্চ উৎস অগ্রাধিকার মান সহ মিলে যাওয়া অ্যাট্রিবিউশন উৎস খুঁজে পায় এবং একটি প্রতিবেদন তৈরি করে। প্রতিটি বিজ্ঞাপন প্রযুক্তি প্ল্যাটফর্ম তার নিজস্ব অগ্রাধিকার কৌশল সংজ্ঞায়িত করতে পারে। অগ্রাধিকার কীভাবে অ্যাট্রিবিউশনকে প্রভাবিত করে সে সম্পর্কে আরও বিশদ বিবরণের জন্য, অগ্রাধিকারের উদাহরণ বিভাগটি দেখুন।

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

ঐচ্ছিকভাবে, অ্যাট্রিবিউশন সোর্স মেটাডেটা প্রতিক্রিয়া অ্যাট্রিবিউশন রিপোর্টিং রিডাইরেক্ট হেডারে অতিরিক্ত ডেটা অন্তর্ভুক্ত করতে পারে। ডেটাতে পুনঃনির্দেশিত URL রয়েছে, যা একাধিক বিজ্ঞাপন প্রযুক্তিকে একটি অনুরোধ নিবন্ধনের অনুমতি দেয় ৷

বিকাশকারী গাইডে উদাহরণগুলি অন্তর্ভুক্ত রয়েছে যা দেখায় কিভাবে উত্স নিবন্ধন গ্রহণ করতে হয় ৷

নিম্নলিখিত পদক্ষেপগুলি একটি উদাহরণ কর্মপ্রবাহ দেখায়:

  1. অ্যাড টেক SDK API-কে অ্যাট্রিবিউশন সোর্স রেজিস্ট্রেশন শুরু করার জন্য কল করে, API-কে কল করার জন্য একটি URI উল্লেখ করে:

    registerSource(
    Uri.parse("https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA"),
    myClickEvent);

  2. API একটি অনুরোধ করে https://adtech.example/attribution_source? AD_TECH_PROVIDED_METADATA , নিম্নলিখিত শিরোনামগুলির একটি ব্যবহার করে:

    <!-- For click events -->
Attribution-Reporting-Source-Info: navigation

<!-- For view events -->
Attribution-Reporting-Source-Info: event

  3. এই বিজ্ঞাপন প্রযুক্তির HTTPS সার্ভার নিম্নলিখিতগুলি ধারণকারী হেডারগুলির সাথে উত্তর দেয়:

    Attribution-Reporting-Register-Source: {
    "destination": "android-app://com.advertiser.example",
    "source_event_id": "234",
    "expiry": "60000",
    "priority": "5"
}
Attribution-Reporting-Redirect:
https://adtechpartner1.example?their_ad_click_id=567
Attribution-Reporting-Redirect:
https://adtechpartner2.example?their_ad_click_id=890

  4. এপিআই Attribution-Reporting-Redirect নির্দিষ্ট করা প্রতিটি ইউআরএলে একটি অনুরোধ করে। এই উদাহরণে, দুটি বিজ্ঞাপন প্রযুক্তি অংশীদার URL নির্দিষ্ট করা হয়েছে, তাই API একটি অনুরোধ করে https://adtechpartner1.example?their_ad_click_id=567 এবং আরেকটি অনুরোধ করে https://adtechpartner2.example?their_ad_click_id=890 ।

  5. এই বিজ্ঞাপন প্রযুক্তির HTTPS সার্ভার নিম্নলিখিতগুলি ধারণকারী হেডারগুলির সাথে উত্তর দেয়:

    Attribution-Reporting-Register-Source: {
    "destination": "android-app://com.advertiser.example",
    "source_event_id": "789",
    "expiry": "120000",
    "priority": "2"
}

পূর্ববর্তী ধাপে দেখানো অনুরোধের ভিত্তিতে তিনটি নেভিগেশন (ক্লিক) অ্যাট্রিবিউশন উত্স নিবন্ধিত হয়েছে।

WebView থেকে একটি অ্যাট্রিবিউশন উৎস নিবন্ধন করুন

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

যেহেতু বিজ্ঞাপন প্রযুক্তিগুলি ওয়েব এবং ওয়েবভিউ জুড়ে সাধারণ কোড ব্যবহার করে, তাই ওয়েবভিউ HTTP 302 পুনঃনির্দেশ অনুসরণ করে এবং প্ল্যাটফর্মে বৈধ নিবন্ধনগুলি পাস করে৷ আমরা এই দৃশ্যের জন্য Attribution-Reporting-Redirect হেডারকে সমর্থন করার পরিকল্পনা করি না, তবে আপনার যদি কোনও প্রভাবিত ব্যবহারের ক্ষেত্রে থাকে তবে যোগাযোগ করুন ।

একটি ট্রিগার নিবন্ধন করুন (রূপান্তর)

বিজ্ঞাপন প্রযুক্তির প্ল্যাটফর্মগুলি registerTrigger() পদ্ধতি ব্যবহার করে ট্রিগারগুলি - যেমন ইনস্টল বা পোস্ট-ইনস্টল ইভেন্টগুলির মতো রূপান্তরগুলি নিবন্ধন করতে পারে৷

registerTrigger() পদ্ধতিটি ট্রিগার URI পরামিতি আশা করে। ট্রিগারের সাথে যুক্ত মেটাডেটা আনার জন্য API এই URI-তে একটি অনুরোধ জারি করে।

API পুনঃনির্দেশ অনুসরণ করে। বিজ্ঞাপন প্রযুক্তি সার্ভারের প্রতিক্রিয়াতে Attribution-Reporting-Register-Trigger নামে একটি HTTP শিরোনাম অন্তর্ভুক্ত করা উচিত, যা এক বা একাধিক নিবন্ধিত ট্রিগারের তথ্য উপস্থাপন করে। হেডারের বিষয়বস্তু JSON-এনকোড করা উচিত এবং নিম্নলিখিত ক্ষেত্রগুলি অন্তর্ভুক্ত করা উচিত:

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

ঐচ্ছিকভাবে, বিজ্ঞাপন প্রযুক্তি সার্ভারের প্রতিক্রিয়া অ্যাট্রিবিউশন রিপোর্টিং রিডাইরেক্ট হেডারে অতিরিক্ত ডেটা অন্তর্ভুক্ত করতে পারে। ডেটাতে পুনঃনির্দেশিত URL রয়েছে, যা একাধিক বিজ্ঞাপন প্রযুক্তিকে একটি অনুরোধ নিবন্ধনের অনুমতি দেয় ।

একাধিক বিজ্ঞাপন প্রযুক্তি Attribution-Reporting-Redirect ফিল্ডে রিডাইরেক্ট অথবা registerTrigger() পদ্ধতিতে একাধিক কল ব্যবহার করে একই ট্রিগার ইভেন্ট নিবন্ধন করতে পারে। একই বিজ্ঞাপন প্রযুক্তি একই ট্রিগার ইভেন্টের জন্য একাধিক প্রতিক্রিয়া প্রদান করে এমন ক্ষেত্রে রিপোর্টে ডুপ্লিকেট ট্রিগার অন্তর্ভুক্ত করা এড়াতে আমরা আপনাকে ডিডপ্লিকেশন কী ফিল্ড ব্যবহার করার পরামর্শ দিই। কিভাবে এবং কখন একটি ডিডুপ্লিকেশন কী ব্যবহার করবেন সে সম্পর্কে আরও জানুন।

বিকাশকারী গাইডে এমন উদাহরণ রয়েছে যা দেখায় কিভাবে ট্রিগার নিবন্ধন গ্রহণ করতে হয় ।

নিম্নলিখিত পদক্ষেপগুলি একটি উদাহরণ কর্মপ্রবাহ দেখায়:

  1. অ্যাড টেক SDK একটি প্রাক-নথিভুক্ত URI ব্যবহার করে ট্রিগার রেজিস্ট্রেশন শুরু করতে API-কে কল করে। আরও তথ্যের জন্য একটি গোপনীয়তা স্যান্ডবক্স অ্যাকাউন্টের জন্য তালিকাভুক্তি দেখুন।

    registerTrigger(
    Uri.parse("https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA"));

  2. API একটি অনুরোধ করে https://adtech.example/attribution_trigger? AD_TECH_PROVIDED_METADATA

  3. এই বিজ্ঞাপন প্রযুক্তির HTTPS সার্ভার নিম্নলিখিতগুলি ধারণকারী হেডারগুলির সাথে উত্তর দেয়:

    Attribution-Reporting-Register-Trigger: {
    "event_trigger_data": [{
    "trigger_data": "1122",
    // This returns 010 for click-through conversions (CTCs) and 0 for
    // view-through conversions (VTCs) in reports
    "priority": "3",
    "deduplication_key": "3344"
    }],
}
Attribution-Reporting-Redirect: https://adtechpartner.example?app_install=567

  4. এপিআই Attribution-Reporting-Redirect নির্দিষ্ট করা প্রতিটি ইউআরএলে একটি অনুরোধ করে। এই উদাহরণে, শুধুমাত্র একটি URL নির্দিষ্ট করা হয়েছে, তাই API https://adtechpartner.example?app_install=567 এ অনুরোধ করে।

  5. এই বিজ্ঞাপন প্রযুক্তির HTTPS সার্ভার নিম্নলিখিতগুলি ধারণকারী হেডারগুলির সাথে উত্তর দেয়:

    Attribution-Reporting-Register-Trigger: {
"event_trigger_data":[{
  "trigger_data": "5566",
  "priority": "3",
  "deduplication_key": "3344"
}]
}

    পূর্ববর্তী ধাপে অনুরোধের ভিত্তিতে দুটি ট্রিগার নিবন্ধিত হয়।

অ্যাট্রিবিউশন ক্ষমতা

নিম্নলিখিত বিভাগগুলি ব্যাখ্যা করে যে কীভাবে অ্যাট্রিবিউশন রিপোর্টিং API রূপান্তরকে অ্যাট্রিবিউশন উত্সের সাথে ট্রিগার করে।

উত্স-অগ্রাধিকারযুক্ত অ্যাট্রিবিউশন অ্যালগরিদম প্রয়োগ করা হয়েছে৷

অ্যাট্রিবিউশন রিপোর্টিং API একটি অ্যাট্রিবিউশন উত্সের সাথে একটি ট্রিগার (রূপান্তর) মেলানোর জন্য একটি উত্স-অগ্রাধিকারযুক্ত অ্যাট্রিবিউশন অ্যালগরিদম নিয়োগ করে৷

অগ্রাধিকার পরামিতিগুলি উত্সগুলিতে ট্রিগারের অ্যাট্রিবিউশন কাস্টমাইজ করার উপায় সরবরাহ করে:

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

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

ট্রিগার ফিল্টার

উত্স এবং ট্রিগার নিবন্ধন নিম্নলিখিতগুলি করার জন্য অতিরিক্ত ঐচ্ছিক কার্যকারিতা অন্তর্ভুক্ত করে:

  • কিছু ট্রিগারকে বেছে বেছে ফিল্টার করুন, কার্যকরভাবে তাদের উপেক্ষা করুন।
  • উৎস ডেটার উপর ভিত্তি করে ইভেন্ট-স্তরের রিপোর্টের জন্য ট্রিগার ডেটা বেছে নিন।
  • ইভেন্ট-স্তরের রিপোর্ট থেকে একটি ট্রিগার বাদ দিতে বেছে নিন।

নির্বাচনীভাবে ট্রিগার ফিল্টার করতে, বিজ্ঞাপন প্রযুক্তি উৎস এবং ট্রিগার নিবন্ধনের সময় কী এবং মান সমন্বিত ফিল্টার ডেটা নির্দিষ্ট করতে পারে। যদি একই কী উৎস এবং ট্রিগার উভয়ের জন্য নির্দিষ্ট করা হয়, তাহলে ছেদ খালি থাকলে ট্রিগার উপেক্ষা করা হয়। উদাহরণস্বরূপ, একটি উত্স নির্দিষ্ট করতে পারে "product": ["1234"] , যেখানে product ফিল্টার কী এবং 1234 হল মান। যদি ট্রিগার ফিল্টারটি "product": ["1111"] , তাহলে ট্রিগারটি উপেক্ষা করা হয়। যদি কোন ট্রিগার ফিল্টার কী ম্যাচিং product না থাকে, তাহলে ফিল্টার উপেক্ষা করা হয়।

আরেকটি দৃশ্য যেখানে বিজ্ঞাপন প্রযুক্তি প্ল্যাটফর্মগুলি বেছে বেছে ট্রিগারগুলি ফিল্টার করতে চাইতে পারে তা হল একটি ছোট মেয়াদোত্তীর্ণ উইন্ডোকে জোর করা। ট্রিগার রেজিস্ট্রেশনে, একটি বিজ্ঞাপন প্রযুক্তি (সেকেন্ডের মধ্যে) রূপান্তর হওয়ার সময় থেকে একটি লুকব্যাক উইন্ডো নির্দিষ্ট করতে পারে; উদাহরণস্বরূপ, একটি 7 দিনের লুকব্যাক উইন্ডোকে এভাবে সংজ্ঞায়িত করা হবে: "_lookback_window": 604800 // 7d

একটি ফিল্টার মেলে কিনা তা নির্ধারণ করতে, API প্রথমে লুকব্যাক উইন্ডোটি পরীক্ষা করবে। যদি পাওয়া যায়, উৎসটি নিবন্ধিত হওয়ার পর থেকে সময়কাল লুকব্যাক উইন্ডোর সময়কালের চেয়ে ছোট বা সমান হতে হবে।

বিজ্ঞাপন প্রযুক্তি প্ল্যাটফর্মগুলি উৎস ইভেন্ট ডেটার উপর ভিত্তি করে ট্রিগার ডেটাও বেছে নিতে পারে। উদাহরণস্বরূপ, source_type স্বয়ংক্রিয়ভাবে API দ্বারা navigation বা event হিসাবে তৈরি হয়। ট্রিগার নিবন্ধনের সময়, trigger_data "source_type": ["navigation"] এবং "source_type": ["event"] এর জন্য একটি ভিন্ন মান হিসাবে।

ট্রিগারগুলিকে ইভেন্ট-স্তরের রিপোর্ট থেকে বাদ দেওয়া হয় যদি নিম্নলিখিতগুলির মধ্যে কোনটি সত্য হয়:

  • কোনো trigger_data নির্দিষ্ট নেই।
  • উত্স এবং ট্রিগার একই ফিল্টার কী নির্দিষ্ট করে, কিন্তু মান মেলে না। মনে রাখবেন, এই ক্ষেত্রে, ইভেন্ট-স্তর এবং সমষ্টিগত প্রতিবেদন উভয়ের জন্যই ট্রিগার উপেক্ষা করা হয়।

পোস্ট-ইনস্টল অ্যাট্রিবিউশন

কিছু ক্ষেত্রে, পোস্ট-ইন্সটল ট্রিগারগুলিকে একই অ্যাট্রিবিউশন সোর্সে অ্যাট্রিবিউট করার প্রয়োজন আছে যেটি ইন্সটলকে চালিত করেছে, এমনকি যদি আরও সম্প্রতি ঘটেছে এমন অন্যান্য যোগ্য অ্যাট্রিবিউশন সোর্সও থাকে।

এপিআই বিজ্ঞাপন প্রযুক্তিকে একটি পোস্ট-ইনস্টল অ্যাট্রিবিউশন সময় সেট করার অনুমতি দিয়ে এই ব্যবহারের ক্ষেত্রে সমর্থন করতে পারে:

  • একটি অ্যাট্রিবিউশন সোর্স রেজিস্টার করার সময়, একটি ইনস্টল অ্যাট্রিবিউশন উইন্ডো নির্দিষ্ট করুন যেখানে ইনস্টলগুলি প্রত্যাশিত (সাধারণত 2-7 দিন, 1 থেকে 30 দিন গৃহীত পরিসর)৷ সেকেন্ডের সংখ্যা হিসাবে এই সময় উইন্ডোটি নির্দিষ্ট করুন।
  • একটি অ্যাট্রিবিউশন সোর্স রেজিস্টার করার সময়, একটি পোস্ট-ইনস্টল অ্যাট্রিবিউশন এক্সক্লুসিভিটি উইন্ডো নির্দিষ্ট করুন যেখানে যেকোন পোস্ট-ইনস্টল ট্রিগার ইভেন্টগুলি সেই অ্যাট্রিবিউশন সোর্সের সাথে যুক্ত হওয়া উচিত যা ইনস্টলকে চালিত করে (সাধারণত 7-30 দিন, স্বীকৃত পরিসর 0 থেকে 30 দিন)। সেকেন্ডের সংখ্যা হিসাবে এই সময় উইন্ডোটি নির্দিষ্ট করুন।
  • অ্যাট্রিবিউশন রিপোর্টিং এপিআই যাচাই করে যখন একটি অ্যাপ ইনস্টল হয় এবং অভ্যন্তরীণভাবে সোর্স-অগ্রাধিকারযুক্ত অ্যাট্রিবিউশন সোর্সে ইনস্টলটিকে অ্যাট্রিবিউট করে। যাইহোক, ইনস্টলটি বিজ্ঞাপন প্রযুক্তিতে পাঠানো হয় না এবং প্ল্যাটফর্মের নিজ নিজ হারের সীমার সাথে গণনা করা হয় না।
  • যেকোনো ডাউনলোড করা অ্যাপের জন্য অ্যাপ ইনস্টলের বৈধতা পাওয়া যায়।
  • পোস্ট-ইন্সটল অ্যাট্রিবিউশন উইন্ডোর মধ্যে যে কোনও ভবিষ্যত ট্রিগারগুলি বৈধ ইনস্টলের মতো একই অ্যাট্রিবিউশন উত্সে অ্যাট্রিবিউট করা হয়, যতক্ষণ না সেই অ্যাট্রিবিউশন উত্সটি যোগ্য।

ভবিষ্যতে, আমরা আরও উন্নত অ্যাট্রিবিউশন মডেলগুলিকে সমর্থন করার জন্য ডিজাইনটি প্রসারিত করার অন্বেষণ করতে পারি।

নিম্নলিখিত সারণীতে বিজ্ঞাপন প্রযুক্তিগুলি কীভাবে পোস্ট-ইনস্টল অ্যাট্রিবিউশন ব্যবহার করতে পারে তার একটি উদাহরণ দেখায়৷ অনুমান করুন সমস্ত অ্যাট্রিবিউশন উত্স এবং ট্রিগার একই বিজ্ঞাপন প্রযুক্তি নেটওয়ার্ক দ্বারা নিবন্ধিত হচ্ছে এবং সমস্ত অগ্রাধিকার একই৷

ঘটনা যেদিন ঘটনা ঘটে নোট
1 ক্লিক করুন 1 install_attribution_window 172800 (2 দিন) এ সেট করা হয়েছে এবং post_install_exclusivity_window সেট করা হয়েছে 864000 (10 দিন)
যাচাইকৃত ইনস্টল 2 API অভ্যন্তরীণভাবে যাচাইকৃত ইনস্টলগুলিকে বৈশিষ্ট্যযুক্ত করে, কিন্তু সেই ইনস্টলগুলিকে ট্রিগার হিসাবে বিবেচনা করা হয় না। অতএব, এই সময়ে কোন রিপোর্ট পাঠানো হয় না.
ট্রিগার 1 (প্রথম ওপেন) 2 বিজ্ঞাপন প্রযুক্তি দ্বারা নিবন্ধিত প্রথম ট্রিগার। এই উদাহরণে, এটি একটি প্রথম খোলার প্রতিনিধিত্ব করে তবে যেকোনো ট্রিগার প্রকার হতে পারে।
ক্লিক 1-এ অ্যাট্রিবিউট করা হয়েছে (যাচাইকৃত ইনস্টলের অ্যাট্রিবিউশন মেলে)।
2 ক্লিক করুন 4 ক্লিক 1 হিসাবে install_attribution_window এবং post_install_exclusivity_window এর জন্য একই মান ব্যবহার করে
ট্রিগার 2 (ইনস্টল করার পরে) 5 দ্বিতীয় ট্রিগার বিজ্ঞাপন প্রযুক্তি দ্বারা নিবন্ধিত. এই উদাহরণে, এটি একটি ক্রয়ের মতো একটি পোস্ট-ইনস্টল রূপান্তরকে উপস্থাপন করে।
ক্লিক 1-এ অ্যাট্রিবিউট করা হয়েছে (যাচাইকৃত ইনস্টলের অ্যাট্রিবিউশন মেলে)।
ক্লিক 2 বাতিল করা হয়েছে এবং ভবিষ্যতে অ্যাট্রিবিউশনের জন্য যোগ্য নয়।

নিম্নলিখিত তালিকাটি পোস্ট-ইনস্টল অ্যাট্রিবিউশন সম্পর্কিত কিছু অতিরিক্ত নোট প্রদান করে:

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

অ্যাপ- এবং ওয়েব-ভিত্তিক ট্রিগার পাথের সমস্ত সমন্বয় সমর্থিত

অ্যাট্রিবিউশন রিপোর্টিং API একটি একক অ্যান্ড্রয়েড ডিভাইসে নিম্নলিখিত ট্রিগার পাথগুলির অ্যাট্রিবিউশন সক্ষম করে:

  • অ্যাপ-টু-অ্যাপ: ব্যবহারকারী একটি অ্যাপে একটি বিজ্ঞাপন দেখেন, তারপর সেই অ্যাপে বা অন্য ইনস্টল করা অ্যাপে রূপান্তর করেন।
  • অ্যাপ-টু-ওয়েব: ব্যবহারকারী একটি অ্যাপে একটি বিজ্ঞাপন দেখেন, তারপর একটি মোবাইল বা অ্যাপ ব্রাউজারে রূপান্তরিত করেন।
  • ওয়েব-টু-অ্যাপ: ব্যবহারকারী একটি মোবাইল বা অ্যাপ ব্রাউজারে একটি বিজ্ঞাপন দেখেন, তারপর একটি অ্যাপে রূপান্তরিত করেন।
  • ওয়েব-টু-ওয়েব: ব্যবহারকারী একটি মোবাইল বা অ্যাপ ব্রাউজারে একটি বিজ্ঞাপন দেখেন, তারপর একই ব্রাউজারে বা একই ডিভাইসে অন্য ব্রাউজারে রূপান্তর করেন৷

আমরা ওয়েব ব্রাউজারগুলিকে নতুন ওয়েব-প্রকাশিত কার্যকারিতা সমর্থন করার অনুমতি দিই, যেমন কার্যকারিতা যা ওয়েবের অ্যাট্রিবিউশন রিপোর্টিং API-এর জন্য গোপনীয়তা স্যান্ডবক্সের মতো, যা অ্যাপ এবং ওয়েব জুড়ে অ্যাট্রিবিউশন সক্ষম করতে Android API-কে কল করতে পারে৷

ক্রস অ্যাপ এবং ওয়েব পরিমাপের জন্য ট্রিগার পাথ সমর্থন করার জন্য বিজ্ঞাপন প্রযুক্তি এবং অ্যাপগুলিকে যে পরিবর্তনগুলি করতে হবে সে সম্পর্কে জানুন৷

একটি একক অ্যাট্রিবিউশন উৎসের জন্য একাধিক ট্রিগারকে অগ্রাধিকার দিন

একটি একক অ্যাট্রিবিউশন উত্স একাধিক ট্রিগার হতে পারে। উদাহরণস্বরূপ, একটি ক্রয় প্রবাহে একটি "অ্যাপ ইনস্টল" ট্রিগার, এক বা একাধিক "অ্যাড-টু-কার্ট" ট্রিগার এবং একটি "ক্রয়" ট্রিগার জড়িত থাকতে পারে। প্রতিটি ট্রিগার উৎস-অগ্রাধিকারযুক্ত অ্যাট্রিবিউশন অ্যালগরিদম অনুসারে এক বা একাধিক অ্যাট্রিবিউশন উত্সকে দায়ী করা হয়, যা এই পৃষ্ঠায় পরে বর্ণিত হয়েছে৷

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

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

একাধিক বিজ্ঞাপন প্রযুক্তিকে অ্যাট্রিবিউশন উত্স বা ট্রিগার নিবন্ধন করার অনুমতি দিন

একাধিক বিজ্ঞাপন প্রযুক্তির জন্য অ্যাট্রিবিউশন রিপোর্ট পাওয়া সাধারণ, সাধারণত ক্রস-নেটওয়ার্ক ডিডপ্লিকেশন করা। তাই, API একাধিক বিজ্ঞাপন প্রযুক্তিকে একই অ্যাট্রিবিউশন উৎস বা ট্রিগার নিবন্ধন করার অনুমতি দেয়। API থেকে পোস্টব্যাক পেতে একটি বিজ্ঞাপন প্রযুক্তিকে অবশ্যই অ্যাট্রিবিউশন উত্স এবং ট্রিগার উভয়ই নিবন্ধন করতে হবে এবং বিজ্ঞাপন প্রযুক্তি API-এর সাথে নিবন্ধিত অ্যাট্রিবিউশন উত্স এবং ট্রিগারগুলির মধ্যে অ্যাট্রিবিউশন করা হয়৷

যে বিজ্ঞাপনদাতারা ক্রস-নেটওয়ার্ক ডিডপ্লিকেশন করার জন্য একটি তৃতীয় পক্ষকে ব্যবহার করতে চান তারা নিম্নলিখিতগুলির মতো একটি কৌশল ব্যবহার করে এটি চালিয়ে যেতে পারেন:

  • এপিআই থেকে রেজিস্টার এবং রিপোর্ট পেতে একটি ইন-হাউস সার্ভার সেট আপ করা।
  • একটি বিদ্যমান মোবাইল পরিমাপ অংশীদার ব্যবহার করা অব্যাহত।

অ্যাট্রিবিউশন উত্স

অ্যাট্রিবিউশন সোর্স রিডাইরেক্ট registerSource() পদ্ধতিতে সমর্থিত:

  1. যে বিজ্ঞাপন প্রযুক্তিটি registerSource() পদ্ধতিকে কল করে তারা তাদের প্রতিক্রিয়াতে একটি অতিরিক্ত Attribution-Reporting-Redirect ক্ষেত্র প্রদান করতে পারে, যা অংশীদার বিজ্ঞাপন প্রযুক্তির পুনঃনির্দেশ URLগুলির সেটকে প্রতিনিধিত্ব করে৷
  2. API তারপর রিডাইরেক্ট ইউআরএলগুলিকে কল করে যাতে অংশীদার বিজ্ঞাপন প্রযুক্তি দ্বারা অ্যাট্রিবিউশন উত্স নিবন্ধিত হতে পারে৷

একাধিক অংশীদার বিজ্ঞাপন প্রযুক্তি URLগুলি Attribution-Reporting-Redirect ক্ষেত্রে তালিকাভুক্ত করা যেতে পারে এবং অংশীদার বিজ্ঞাপন প্রযুক্তিগুলি তাদের নিজস্ব Attribution-Reporting-Redirect ক্ষেত্র নির্দিষ্ট করতে পারে না৷

এপিআই প্রতিটি কল registerSource() এ বিভিন্ন বিজ্ঞাপন প্রযুক্তির অনুমতি দেয়।

ট্রিগার

ট্রিগার নিবন্ধনের জন্য, তৃতীয় পক্ষগুলি একইভাবে সমর্থিত: বিজ্ঞাপন প্রযুক্তিগুলি হয় অতিরিক্ত Attribution-Reporting-Redirect ক্ষেত্র ব্যবহার করতে পারে, অথবা তারা প্রত্যেকে registerTrigger() পদ্ধতিতে কল করতে পারে৷

যখন একজন বিজ্ঞাপনদাতা একই ট্রিগার ইভেন্ট নিবন্ধন করতে একাধিক বিজ্ঞাপন প্রযুক্তি ব্যবহার করেন, তখন একটি ডিডপ্লিকেশন কী ব্যবহার করা উচিত। ডিডুপ্লিকেশন কী একই বিজ্ঞাপন প্রযুক্তি প্ল্যাটফর্মের দ্বারা নিবন্ধিত একই ইভেন্টের এই বারবার রিপোর্টগুলিকে দ্ব্যর্থহীন করতে কাজ করে৷ উদাহরণস্বরূপ, একটি বিজ্ঞাপন প্রযুক্তির ট্রিগার নিবন্ধন করার জন্য তাদের SDK সরাসরি API কল করতে পারে এবং অন্য বিজ্ঞাপন প্রযুক্তির কলের রিডাইরেক্ট ক্ষেত্রে তাদের URL থাকতে পারে। যদি কোন ডিডপ্লিকেশন কী প্রদান না করা হয়, তাহলে ডুপ্লিকেট ট্রিগারগুলি প্রতিটি বিজ্ঞাপন প্রযুক্তিতে অনন্য হিসাবে রিপোর্ট করা হতে পারে।

ডুপ্লিকেট ট্রিগার পরিচালনা করুন

একটি বিজ্ঞাপন প্রযুক্তি API এর সাথে একই ট্রিগার একাধিকবার নিবন্ধন করতে পারে। পরিস্থিতিতে নিম্নলিখিত অন্তর্ভুক্ত:

  • ব্যবহারকারী একই ক্রিয়া (ট্রিগার) একাধিকবার করে। উদাহরণস্বরূপ, ব্যবহারকারী একই রিপোর্টিং উইন্ডোতে একই পণ্য একাধিকবার ব্রাউজ করে।
  • বিজ্ঞাপনদাতা অ্যাপ রূপান্তর পরিমাপের জন্য একাধিক SDK ব্যবহার করে, যেগুলো সব একই বিজ্ঞাপন প্রযুক্তিতে পুনঃনির্দেশিত হয়। উদাহরণস্বরূপ, বিজ্ঞাপনদাতা অ্যাপ দুটি পরিমাপ অংশীদার ব্যবহার করে, MMP #1 এবং MMP #2। উভয় MMPs বিজ্ঞাপন প্রযুক্তি #3 এ পুনঃনির্দেশিত করে। একটি ট্রিগার ঘটলে, উভয় MMPই সেই ট্রিগারটিকে অ্যাট্রিবিউশন রিপোর্টিং API-এর সাথে নিবন্ধন করে। বিজ্ঞাপন প্রযুক্তি #3 তারপর দুটি পৃথক পুনঃনির্দেশ পায়—একটি MMP #1 থেকে এবং একটি MMP #2 থেকে—একই ট্রিগারের জন্য।

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

প্রস্তাবিত পদ্ধতি: ডিডুপ্লিকেশন কী

বিজ্ঞাপনদাতা অ্যাপের জন্য প্রস্তাবিত পদ্ধতি হল যে কোনও বিজ্ঞাপন প্রযুক্তি বা SDK-এ একটি অনন্য ডিডপ্লিকেশন কী পাস করা যা এটি রূপান্তর পরিমাপের জন্য ব্যবহার করছে। যখন একটি রূপান্তর ঘটে, অ্যাপটি বিজ্ঞাপন প্রযুক্তি বা SDK-তে একটি অনুলিপি কী পাস করে। সেই বিজ্ঞাপন প্রযুক্তি বা SDKগুলি তারপরে Attribution-Reporting-Redirect এ নির্দিষ্ট করা URL-এ একটি প্যারামিটার ব্যবহার করে রিডাইরেক্টে ডিডপ্লিকেশন কী পাস করা চালিয়ে যায়।

বিজ্ঞাপন প্রযুক্তিগুলি একটি প্রদত্ত ডিডপ্লিকেশন কী দিয়ে শুধুমাত্র প্রথম ট্রিগার নিবন্ধন করতে বা একাধিক ট্রিগার বা সমস্ত ট্রিগার নিবন্ধন করতে বেছে নিতে পারে৷ ডুপ্লিকেট ট্রিগার নিবন্ধন করার সময় বিজ্ঞাপন প্রযুক্তিগুলি deduplication_key নির্দিষ্ট করতে পারে৷

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

বিকল্প পদ্ধতি: বিজ্ঞাপন প্রযুক্তি প্রতি-বিজ্ঞাপনদাতা ট্রিগার প্রকারে একমত

এমন পরিস্থিতিতে যেখানে বিজ্ঞাপন প্রযুক্তিগুলি ডিডপ্লিকেশন কী ব্যবহার করতে চায় না, বা যেখানে বিজ্ঞাপনদাতা অ্যাপ একটি ডিডুপ্লিকেশন কী পাস করতে পারে না, সেখানে একটি বিকল্প বিকল্প বিদ্যমান। প্রদত্ত বিজ্ঞাপনদাতার রূপান্তর পরিমাপকারী সমস্ত বিজ্ঞাপন প্রযুক্তিকে প্রতিটি বিজ্ঞাপনদাতার জন্য বিভিন্ন ট্রিগার প্রকার সংজ্ঞায়িত করতে একসাথে কাজ করতে হবে।

বিজ্ঞাপন প্রযুক্তি যা ট্রিগার রেজিস্ট্রেশন কল শুরু করে—উদাহরণস্বরূপ, SDK-এ Attribution-Reporting-Redirect নির্দিষ্ট করা URL-এ একটি প্যারামিটার অন্তর্ভুক্ত করে, যেমন duplicate_trigger_id । সেই duplicate_trigger_id প্যারামিটারে সেই বিজ্ঞাপনদাতার জন্য SDK নাম এবং ট্রিগার প্রকারের মতো তথ্য অন্তর্ভুক্ত থাকতে পারে। বিজ্ঞাপন প্রযুক্তিগুলি তখন ইভেন্ট-স্তরের রিপোর্টগুলিতে এই ডুপ্লিকেট ট্রিগারগুলির একটি উপসেট পাঠাতে পারে। বিজ্ঞাপন প্রযুক্তিগুলিও তাদের একত্রিতকরণ কীগুলিতে এই duplicate_trigger_id অন্তর্ভুক্ত করতে পারে।

ক্রস-নেটওয়ার্ক অ্যাট্রিবিউশন উদাহরণ

এই বিভাগে বর্ণিত উদাহরণে, বিজ্ঞাপনদাতা দুটি পরিবেশনকারী বিজ্ঞাপন প্রযুক্তি প্ল্যাটফর্ম (Ad tech A এবং Ad tech B) এবং একটি পরিমাপ অংশীদার (MMP) ব্যবহার করছেন।

শুরু করার জন্য, Ad tech A, Ad tech B, এবং MMP প্রত্যেককে অবশ্যই অ্যাট্রিবিউশন রিপোর্টিং API ব্যবহার করার জন্য তালিকাভুক্তি সম্পূর্ণ করতে হবে। আরও তথ্যের জন্য একটি গোপনীয়তা স্যান্ডবক্স অ্যাকাউন্টের জন্য তালিকাভুক্তি দেখুন।

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

দিন 1: ব্যবহারকারী বিজ্ঞাপন প্রযুক্তি A দ্বারা পরিবেশিত একটি বিজ্ঞাপনে ক্লিক করে৷

বিজ্ঞাপন প্রযুক্তি A তাদের URI দিয়ে registerSource() কল করে। API URI-তে একটি অনুরোধ করে এবং ক্লিকটি Ad tech A-এর সার্ভার প্রতিক্রিয়া থেকে মেটাডেটার সাথে নিবন্ধিত হয়।

অ্যাড টেক A-তে Attribution-Reporting-Redirect হেডারে MMP-এর URIও অন্তর্ভুক্ত রয়েছে। এপিআই এমএমপির ইউআরআই-তে একটি অনুরোধ করে এবং ক্লিকটি এমএমপির সার্ভারের প্রতিক্রিয়া থেকে মেটাডেটার সাথে নিবন্ধিত হয়।

দিন 2: অ্যাড টেক বি দ্বারা পরিবেশিত একটি বিজ্ঞাপনে ব্যবহারকারী ক্লিক করে

অ্যাড টেক বি তাদের URI দিয়ে registerSource() কল করে। এপিআই ইউআরআই-এর কাছে একটি অনুরোধ করে এবং ক্লিকটি অ্যাড টেক বি-এর সার্ভারের প্রতিক্রিয়া থেকে মেটাডেটার সাথে নিবন্ধিত হয়।

Ad tech A-এর মতো, Ad tech Bও MMP-এর URI-কে Attribution-Reporting-Redirect হেডারে অন্তর্ভুক্ত করেছে। এপিআই এমএমপির ইউআরআই-তে একটি অনুরোধ করে এবং ক্লিকটি এমএমপির সার্ভারের প্রতিক্রিয়া থেকে মেটাডেটার সাথে নিবন্ধিত হয়।

দিন 3: ব্যবহারকারী বিজ্ঞাপন প্রযুক্তি A দ্বারা পরিবেশিত একটি বিজ্ঞাপন দেখেন৷

এপিআই একইভাবে সাড়া দেয় যেভাবে এটি 1 দিনে করেছিল, বিজ্ঞাপন প্রযুক্তি A এবং MMP-এর জন্য একটি ভিউ নিবন্ধিত করা ছাড়া।

দিন 4: ব্যবহারকারী অ্যাপটি ইনস্টল করে, যা রূপান্তর পরিমাপের জন্য MMP ব্যবহার করে

MMP তাদের URI দিয়ে registerTrigger() কল করে। API URL-এ একটি অনুরোধ করে, এবং রূপান্তরটি MMP-এর সার্ভার প্রতিক্রিয়া থেকে মেটাডেটার সাথে নিবন্ধিত হয়।

MMP-এ Attribution-Reporting-Redirect হেডারে অ্যাড টেক A এবং অ্যাড টেক B-এর URIগুলিও অন্তর্ভুক্ত রয়েছে। এপিআই অ্যাড টেক এ এবং অ্যাড টেক বি এর সার্ভারগুলিতে অনুরোধ করে এবং সার্ভারের প্রতিক্রিয়াগুলি থেকে মেটাডেটা অনুসারে রূপান্তরটি নিবন্ধিত হয়৷

নিম্নলিখিত চিত্রটি পূর্ববর্তী তালিকায় বর্ণিত প্রক্রিয়াটিকে চিত্রিত করে:

অ্যাট্রিবিউশন রিপোর্টিং API ব্যবহারকারীর ক্রিয়াগুলির একটি সিরিজে কীভাবে প্রতিক্রিয়া জানায় তার উদাহরণ।

অ্যাট্রিবিউশন নিম্নরূপ কাজ করে:

  • বিজ্ঞাপন প্রযুক্তি A ভিউয়ের চেয়ে বেশি ক্লিকের অগ্রাধিকার সেট করে এবং সেইজন্য 1 দিনে ক্লিকের জন্য ইনস্টল করা হয়।
  • অ্যাড টেক বি 2 য় দিনে ইনস্টল অ্যাট্রিবিউট করে।
  • MMP ভিউ থেকে বেশি ক্লিকের অগ্রাধিকার সেট করে এবং ২য় দিনে ক্লিকের জন্য ইন্সটল অ্যাট্রিবিউট করে। দিন 2-এর ক্লিক হল সর্বোচ্চ অগ্রাধিকার, সাম্প্রতিকতম বিজ্ঞাপন ইভেন্ট।

রিডাইরেক্ট ছাড়াই ক্রস-নেটওয়ার্ক অ্যাট্রিবিউশন

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

উচ্চ স্তরের প্রবাহ

  1. সোর্স রেজিস্ট্রেশনে, সার্ভিং অ্যাড টেক নেটওয়ার্ক তাদের সোর্স অ্যাগ্রিগেশন কী শেয়ার করে।
  2. ট্রিগার রেজিস্ট্রেশনে, বিজ্ঞাপনদাতা বা পরিমাপ অংশীদার কোন সোর্স-সাইড কী টুকরা ব্যবহার করতে চান তা বেছে নেন এবং তাদের অ্যাট্রিবিউশন কনফিগারেশন নির্দিষ্ট করে।
  3. অ্যাট্রিবিউশনটি অ্যাট্রিবিউশন কনফিগারেশন, শেয়ার্ড কী এবং যেকোন উৎসের উপর ভিত্তি করে তৈরি করা হয় যা প্রকৃতপক্ষে সেই বিজ্ঞাপনদাতা বা পরিমাপ অংশীদার দ্বারা নিবন্ধিত হয়েছিল (যেমন অন্য পরিবেশনকারী বিজ্ঞাপন প্রযুক্তি নেটওয়ার্ক থেকে যা রিডাইরেক্ট সক্ষম করেছে)।
  4. যদি ট্রিগারটি একটি নন-রিডাইরেক্টিং সার্ভিং বিজ্ঞাপন প্রযুক্তি থেকে উৎসের জন্য দায়ী করা হয়, তাহলে বিজ্ঞাপনদাতা বা পরিমাপ অংশীদার একটি সমষ্টিগত প্রতিবেদন পেতে পারে যা উত্স এবং ট্রিগার মূল অংশগুলিকে ধাপ #2 এ সংজ্ঞায়িত করে।

উত্স নিবন্ধন

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

একই বিজ্ঞাপনদাতার জন্য একটি ট্রিগার নিবন্ধন করে এমন যেকোনো বিজ্ঞাপন প্রযুক্তিতে শেয়ার্ড অ্যাগ্রিগেশন কীগুলি উপলব্ধ। যাইহোক, এটা সার্ভিং বিজ্ঞাপন প্রযুক্তি এবং ট্রিগার পরিমাপ বিজ্ঞাপন প্রযুক্তির উপর নির্ভর করে যে কি ধরনের একত্রীকরণ কী প্রয়োজন, তাদের নাম এবং কীভাবে কীগুলিকে পাঠযোগ্য মাত্রায় ডিকোড করতে হয়।

ট্রিগার নিবন্ধন

ট্রিগার রেজিস্ট্রেশনে, পরিমাপ বিজ্ঞাপন প্রযুক্তি প্রতিটি ট্রিগার কী অংশে কোন সোর্স-সাইড কী অংশগুলি প্রয়োগ করতে হবে তা বেছে নেয়, বিজ্ঞাপন প্রযুক্তি পরিবেশন করে শেয়ার করা যেকোনো সহ।

অতিরিক্তভাবে, পরিমাপের বিজ্ঞাপন প্রযুক্তিটি অবশ্যই একটি নতুন অ্যাট্রিবিউশন কনফিগারেশন এপিআই কল ব্যবহার করে তাদের জলপ্রপাত অ্যাট্রিবিউশন লজিক নির্দিষ্ট করতে হবে। এই কনফিগারেশনে, বিজ্ঞাপন প্রযুক্তি উত্সের অগ্রাধিকার, মেয়াদোত্তীর্ণ এবং উত্সগুলির জন্য ফিল্টারগুলি নির্দিষ্ট করতে পারে যে তাদের কোনও দৃশ্যমানতা ছিল না (উদাহরণস্বরূপ, উত্সগুলি যা পুনর্নির্দেশ ব্যবহার করে না)।

অ্যাট্রিবিউশন

অ্যাট্রিবিউশন রিপোর্টিং এপিআই তাদের অ্যাট্রিবিউশন কনফিগারেশন, ভাগ করা কীগুলি এবং তারা নিবন্ধিত যে কোনও উত্সের ভিত্তিতে পরিমাপ বিজ্ঞাপন প্রযুক্তির জন্য উত্স-অগ্রাধিকারযুক্ত, শেষ-স্পর্শের বৈশিষ্ট্য সম্পাদন করে। যেমন:

  • ব্যবহারকারী এ, বি, সি এবং ডি দ্বারা পরিবেশন করা বিজ্ঞাপনগুলিতে ক্লিক করেছেন ব্যবহারকারী তখন বিজ্ঞাপনদাতার অ্যাপটি ইনস্টল করেছেন, যা একটি পরিমাপ বিজ্ঞাপন প্রযুক্তি অংশীদার (এমএমপি) ব্যবহার করে।
  • বিজ্ঞাপন প্রযুক্তি একটি এর উত্সগুলি এমএমপিতে পুনঃনির্দেশ করে।
  • বিজ্ঞাপন বি এবং সি পুনর্নির্দেশ করে না, তবে তাদের সমষ্টি কীগুলি ভাগ করে নেয়।
  • অ্যাড টেক ডি উভয়ই পুনর্নির্দেশ করে না বা একত্রিতকরণ কীগুলি ভাগ করে না।

এমএমপি বিজ্ঞাপন টেক এ থেকে একটি উত্স নিবন্ধভুক্ত করে এবং একটি অ্যাট্রিবিউশন কনফিগারেশন সংজ্ঞায়িত করে যাতে বিজ্ঞাপন প্রযুক্তি বি এবং বিজ্ঞাপন প্রযুক্তি ডি অন্তর্ভুক্ত থাকে

এমএমপির জন্য এখন বৈশিষ্ট্য অন্তর্ভুক্ত:

  • অ্যাড টেক এ, যেহেতু এমএমপি সেই বিজ্ঞাপন প্রযুক্তির পুনঃনির্দেশ থেকে একটি উত্স নিবন্ধভুক্ত করেছে।
  • অ্যাড টেক বি, যেহেতু অ্যাড টেক বি ভাগ করা কীগুলি এবং এমএমপি তাদের অ্যাট্রিবিউশন কনফিগারেশনে এটি অন্তর্ভুক্ত করেছে।

এমএমপির জন্য অ্যাট্রিবিউশন অন্তর্ভুক্ত নয়:

  • অ্যাড টেক সি, যেহেতু এমএমপি তাদের অ্যাট্রিবিউশন কনফিগারেশনে এটি অন্তর্ভুক্ত করেনি।
  • বিজ্ঞাপন প্রযুক্তি ডি, যেহেতু তারা পুনর্নির্দেশ বা ভাগ করে না।

ডিবাগিং

পুনর্নির্দেশ ছাড়াই ক্রস-নেটওয়ার্ক অ্যাট্রিবিউশনটির জন্য ডিবাগিং সমর্থন করার জন্য, একটি অতিরিক্ত ক্ষেত্র, shared_debug_key , বিজ্ঞাপন প্রযুক্তিগুলির জন্য উত্স নিবন্ধকরণ সেট করার জন্য উপলব্ধ। যদি মূল উত্স নিবন্ধকরণে সেট করা হয় তবে এটি পুনর্নির্দেশ ছাড়াই ক্রস-নেটওয়ার্ক অ্যাট্রিবিউশনটির জন্য ট্রিগার নিবন্ধকরণের সময় debug_key হিসাবে সংশ্লিষ্ট প্রাপ্ত উত্সটিতেও সেট করা হবে। এই ডিবাগ কীটি ইভেন্ট এবং সামগ্রিক প্রতিবেদনে source_debug_key হিসাবে সংযুক্ত রয়েছে।

এই ডিবাগ বৈশিষ্ট্যটি কেবলমাত্র নিম্নলিখিত পরিস্থিতিতে পুনর্নির্দেশ ছাড়াই ক্রস-নেটওয়ার্ক অ্যাট্রিবিউশনের জন্য সমর্থিত হবে:

  • অ্যাপ্লিকেশন পরিমাপে অ্যাপ্লিকেশন যেখানে এডিআইডি অনুমোদিত
  • অ্যাপ্লিকেশন উত্স এবং ওয়েব ট্রিগার উভয় জুড়ে এডিআইডি অনুমোদিত এবং মেলে যেখানে ওয়েব পরিমাপে অ্যাপ্লিকেশন
  • ওয়েব টু ওয়েব পরিমাপ (একই ব্রাউজার অ্যাপে) যখন ar_debug `উত্স এবং ট্রিগার উভয় ক্ষেত্রেই উপস্থিত থাকে

পুনর্নির্দেশ ছাড়াই ক্রস-নেটওয়ার্ক অ্যাট্রিবিউশন জন্য মূল আবিষ্কার

মূল আবিষ্কারের উদ্দেশ্য হ'ল কীভাবে বিজ্ঞাপন প্রযুক্তিগুলি (সাধারণত এমএমপিএস) ক্রস-নেটওয়ার্ক অ্যাট্রিবিউশনের উদ্দেশ্যে তাদের অ্যাট্রিবিউশন কনফিগারেশনটি প্রয়োগ করে যখন এক বা একাধিক পরিবেশনকারী বিজ্ঞাপন প্রযুক্তিগুলি ভাগ করা সমষ্টি কীগুলি ব্যবহার করে (উপরের পুনঃনির্দেশগুলি ছাড়াই ক্রস-নেটওয়ার্ক অ্যাট্রিবিউশন হিসাবে বর্ণিত)।

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

  • সমস্ত সম্ভাব্য কীগুলির তালিকা বড়:
    • একটি পরিবেশনকারী বিজ্ঞাপন নেটওয়ার্ক একটি জটিল ব্যবহারকারী অধিগ্রহণ উদ্যোগ সম্পাদন করছে যার মধ্যে 20 টি প্রচারণা অন্তর্ভুক্ত রয়েছে, প্রতিটি 10 ​​টি বিজ্ঞাপন গ্রুপ সহ এবং প্রতিটি বিজ্ঞাপন গোষ্ঠী 5 টি ক্রিয়েটিভ সহ প্রতি সপ্তাহে পারফরম্যান্সের ভিত্তিতে রিফ্রেশ করা হয়।
  • সমস্ত সম্ভাব্য কীগুলির তালিকা অজানা:
    • একটি পরিবেশনকারী বিজ্ঞাপন নেটওয়ার্ক অনেকগুলি মোবাইল অ্যাপ্লিকেশন জুড়ে বিজ্ঞাপন পরিবেশন করছে যেখানে প্রকাশক অ্যাপ আইডির সম্পূর্ণ তালিকা প্রচার প্রচারে জানা যায় না।
    • একজন বিজ্ঞাপনদাতা একাধিক পরিবেশনকারী বিজ্ঞাপন নেটওয়ার্কগুলিতে কাজ করছেন যা উত্স নিবন্ধকরণে এমএমপিকে পুনর্নির্দেশ করছে না; প্রতিটি পরিবেশনকারী বিজ্ঞাপন নেটওয়ার্কের একটি আলাদা কী কাঠামো এবং মান রয়েছে, যা এমএমপির সাথে আগে থেকেই ভাগ করা যায় না।

কী আবিষ্কার প্রবর্তনের সাথে:

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

সংক্ষেপে, কী আবিষ্কার এমএমপিগুলিকে অগ্রিম কীগুলি আগাম না জেনে এবং এগুলি যুক্ত শব্দের ব্যয়ে উত্স কীগুলির একটি বৃহত পরিমাণে প্রক্রিয়াজাতকরণ এড়াতে সক্ষম করে।

ডেইজি চেইন পুনর্নির্দেশ

কোনও উত্স বা ট্রিগার রেজিস্ট্রেশন এইচটিটিপিএস সার্ভার-প্রতিক্রিয়াগুলিতে একাধিক Attribution-Reporting-Redirect শিরোনাম সরবরাহ করে, একটি বিজ্ঞাপন প্রযুক্তি একক নিবন্ধকরণ এপিআই কল দিয়ে একাধিক উত্স এবং ট্রিগার নিবন্ধকরণ সম্পাদন করতে অ্যাট্রিবিউশন রিপোর্টিং এপিআই ব্যবহার করতে পারে।

সার্ভার-প্রতিক্রিয়াতে, বিজ্ঞাপন প্রযুক্তিতে একটি ইউআরএল সহ একটি একক Location (302 পুনর্নির্দেশ) শিরোনামও অন্তর্ভুক্ত থাকতে পারে, যার ফলস্বরূপ অন্য একটি নিবন্ধের দিকে পরিচালিত করে, একটি নির্দিষ্ট সীমা পর্যন্ত।

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

ব্রাউজারগুলি দ্বারা ব্যবহৃত রেজিস্টারউইবসোর্স এবং রেজিস্টার ওয়েবট্রিগারের জন্য পুনঃনির্দেশগুলি গৃহীত হয় না। আরও বিশদ ক্রস ওয়েব এবং অ্যাপ্লিকেশন বাস্তবায়ন গাইডে পাওয়া যাবে।

অ্যাট্রিবিউশন রিপোর্টে পরিমাপের ডেটা দেখুন

অ্যাট্রিবিউশন রিপোর্টিং এপিআই নিম্নলিখিত ধরণের প্রতিবেদনগুলি সক্ষম করে, এই পৃষ্ঠায় পরে আরও বিশদে বর্ণিত:

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

এই দুটি প্রতিবেদনের ধরণগুলি একে অপরের পরিপূরক এবং একই সাথে ব্যবহার করা যেতে পারে।

ইভেন্ট-স্তরের প্রতিবেদন

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

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

ইভেন্ট-স্তরের প্রতিবেদনে নিম্নলিখিতগুলির মতো ডেটা রয়েছে:

  • গন্তব্য: বিজ্ঞাপনদাতা অ্যাপ প্যাকেজের নাম বা ETLD+1 যেখানে ট্রিগারটি ঘটেছে
  • অ্যাট্রিবিউশন উত্স আইডি: একই অ্যাট্রিবিউশন উত্স আইডি যা একটি অ্যাট্রিবিউশন উত্স নিবন্ধকরণের জন্য ব্যবহৃত হয়েছিল
  • ট্রিগার প্রকার: অ্যাট্রিবিউশন উত্সের ধরণের উপর নির্ভর করে কম-বিশ্বস্ততা ট্রিগার ডেটা 1 বা 3 বিট

সমস্ত প্রতিবেদনে প্রয়োগ করা গোপনীয়তা-সংরক্ষণ প্রক্রিয়া

অ্যাট্রিবিউশন উত্স এবং ট্রিগার সম্পর্কিত অগ্রাধিকারের পরে নিম্নলিখিত সীমাগুলি প্রয়োগ করা হয়।

বিজ্ঞাপন প্রযুক্তির সংখ্যার সীমাবদ্ধতা

নিম্নলিখিতগুলির বর্তমান প্রস্তাব সহ এপিআই থেকে প্রতিবেদনগুলি নিবন্ধন বা পেতে পারে এমন বিজ্ঞাপন প্রযুক্তির সংখ্যার সীমাবদ্ধতা রয়েছে:

  • প্রতি {উত্স অ্যাপ্লিকেশন, গন্তব্য অ্যাপ্লিকেশন, 30 দিন, ডিভাইস} প্রতি অ্যাট্রিবিউশন উত্স সহ 100 বিজ্ঞাপন প্রযুক্তি}
  • প্রতি {উত্স অ্যাপ্লিকেশন, গন্তব্য অ্যাপ্লিকেশন, 30 দিন, ডিভাইস} প্রতি বৈশিষ্ট্যযুক্ত ট্রিগার সহ 10 বিজ্ঞাপন প্রযুক্তি}
  • 20 বিজ্ঞাপন প্রযুক্তিগুলি একটি একক অ্যাট্রিবিউশন উত্স বা ট্রিগার নিবন্ধন করতে পারে ( Attribution-Reporting-Redirect মাধ্যমে)

অনন্য গন্তব্য সংখ্যা সীমাবদ্ধ

এই সীমাগুলি প্রদত্ত ব্যবহারকারীর অ্যাপ্লিকেশন ব্যবহারের আচরণটি বোঝার জন্য প্রচুর সংখ্যক অ্যাপ্লিকেশনকে জিজ্ঞাসা করে বিজ্ঞাপন প্রযুক্তির একটি সেটকে একত্রিত করা কঠিন করে তোলে।

  • সমস্ত নিবন্ধিত উত্স জুড়ে, সমস্ত বিজ্ঞাপন প্রযুক্তি জুড়ে, এপিআই প্রতি মিনিটে প্রতি উত্স অ্যাপ্লিকেশন প্রতি 200 টিরও বেশি অনন্য গন্তব্য সমর্থন করে না।
  • সমস্ত নিবন্ধিত উত্স জুড়ে, একটি একক বিজ্ঞাপন প্রযুক্তির জন্য, এপিআই প্রতি মিনিটে প্রতি উত্স অ্যাপ্লিকেশন প্রতি 50 টিরও বেশি অনন্য গন্তব্য সমর্থন করে না। এই সীমাটি একটি বিজ্ঞাপন প্রযুক্তি পূর্বে উল্লিখিত হারের সীমা থেকে পুরো বাজেট ব্যবহার করতে বাধা দেয়।

মেয়াদোত্তীর্ণ উত্সগুলি হারের সীমাবদ্ধতার দিকে গণনা করে না।

প্রতি দিন উত্স অ্যাপ্লিকেশন প্রতি একটি রিপোর্টিং উত্স

প্রদত্ত বিজ্ঞাপন প্রযুক্তি প্ল্যাটফর্ম একই দিনে প্রদত্ত ডিভাইসের জন্য কোনও প্রকাশক অ্যাপে উত্সগুলি নিবন্ধ করতে কেবল একটি প্রতিবেদনের উত্স ব্যবহার করতে পারে। এই হারের সীমা অতিরিক্ত গোপনীয়তা বাজেট অ্যাক্সেস করতে অ্যাড টেকগুলি একাধিক প্রতিবেদনের উত্স ব্যবহার করতে বাধা দেয়।

নিম্নলিখিত দৃশ্যটি বিবেচনা করুন, যেখানে একটি একক বিজ্ঞাপন প্রযুক্তি একক ডিভাইসের জন্য কোনও প্রকাশক অ্যাপে উত্সগুলি নিবন্ধ করতে একাধিক প্রতিবেদনের উত্স ব্যবহার করতে চায়।

  1. বিজ্ঞাপন টেক এ এর ​​রিপোর্টিং অরিজিন 1 অ্যাপ বি তে একটি উত্স নিবন্ধভুক্ত করে
  2. 12 ঘন্টা পরে, অ্যাড টেক এ এর ​​রিপোর্টিং অরিজিন 2 অ্যাপ্লিকেশন বি তে একটি উত্স নিবন্ধ করার চেষ্টা করে

দ্বিতীয় উত্স, অ্যাড টেক এ এর ​​রিপোর্টিং অরিজিন 2 এর জন্য, এপিআই দ্বারা প্রত্যাখ্যান করা হবে। অ্যাড টেক এ এর ​​রিপোর্টিং অরিজিন 2 পরের দিন পর্যন্ত অ্যাপ্লিকেশন বিতে একই ডিভাইসে সফলভাবে কোনও উত্স নিবন্ধন করতে সক্ষম হবে না।

কোলডাউন এবং রেট সীমা

কোনও {উত্স, গন্তব্য} জোড়ের মধ্যে ব্যবহারকারীর পরিচয় ফাঁসের পরিমাণ সীমাবদ্ধ করতে, এপিআই কোনও ব্যবহারকারীর জন্য নির্দিষ্ট সময়কালে প্রেরিত মোট তথ্যের পরিমাণকে থ্রোটল করে।

বর্তমান প্রস্তাবটি হ'ল প্রতিটি বিজ্ঞাপন প্রযুক্তিটি প্রতি {উত্স অ্যাপ্লিকেশন, গন্তব্য অ্যাপ্লিকেশন, 30 দিন, ডিভাইস} প্রতি 100 টি বৈশিষ্ট্যযুক্ত ট্রিগারগুলিতে সীমাবদ্ধ করা}

অনন্য গন্তব্য সংখ্যা

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

বর্তমান প্রস্তাবটি হ'ল প্রতিটি বিজ্ঞাপন প্রযুক্তিটি প্রতি উত্স অ্যাপ্লিকেশন প্রতি এক্স-এক্সপায়ারড উত্সগুলির সাথে 100 টি স্বতন্ত্র গন্তব্যগুলিতে সীমাবদ্ধ করা।

ইভেন্ট-স্তরের প্রতিবেদনে গোপনীয়তা-সংরক্ষণের ব্যবস্থা প্রয়োগ করা হয়

ট্রিগার ডেটার সীমিত বিশ্বস্ততা

এপিআই ভিউ-থ্রু ট্রিগারগুলির জন্য 1 বিট এবং ক্লিক-থ্রু ট্রিগারগুলির জন্য 3 বিট সরবরাহ করে। অ্যাট্রিবিউশন উত্সগুলি মেটাডেটার সম্পূর্ণ 64 বিট সমর্থন করে চলেছে।

ট্রিগারগুলিতে প্রকাশিত তথ্যগুলি কীভাবে হ্রাস করতে হয় তা আপনার মূল্যায়ন করা উচিত যাতে তারা ইভেন্ট-স্তরের প্রতিবেদনে উপলব্ধ সীমিত সংখ্যক বিট নিয়ে কাজ করে।

ডিফারেনশিয়াল গোপনীয়তা শব্দের জন্য কাঠামো

এই এপিআইয়ের একটি লক্ষ্য হ'ল প্রতিটি উত্স ইভেন্টের জন্য শোরগোলের আউটপুট তৈরি করতে কে-এলোমেলো প্রতিক্রিয়াগুলি ব্যবহার করে স্থানীয় ডিফারেনশিয়াল গোপনীয়তার প্রয়োজনীয়তাগুলি পূরণ করার জন্য ইভেন্ট-স্তরের পরিমাপকে অনুমতি দেওয়া।

কোনও অ্যাট্রিবিউশন উত্স ইভেন্টটি সত্যভাবে রিপোর্ট করা হয়েছে কিনা তা নিয়ে শব্দ প্রয়োগ করা হয়। সম্ভাব্যতা $ 1-পি $ সহ ডিভাইসে একটি অ্যাট্রিবিউশন উত্স নিবন্ধিত হয় যা অ্যাট্রিবিউশন উত্সটি স্বাভাবিক হিসাবে নিবন্ধিত হয় এবং সম্ভাব্যতা $ পি $ দিয়ে ডিভাইসটি এলোমেলোভাবে এপিআইয়ের সমস্ত সম্ভাব্য আউটপুট রাজ্যের মধ্যে চয়ন করে (কিছুতেই রিপোর্ট না করে , বা একাধিক নকল প্রতিবেদন প্রতিবেদন করা)।

কে-এলোমেলো প্রতিক্রিয়া হ'ল একটি অ্যালগরিদম যা নিম্নলিখিত সমীকরণটি সন্তুষ্ট হলে এপসিলন পৃথকভাবে ব্যক্তিগত হয়:

\[ p = \frac{k}{k + e^ε - 1} \]

Ε এর কম মানের জন্য, সত্য আউটপুট কে-এলোমেলো প্রতিক্রিয়া প্রক্রিয়া দ্বারা সুরক্ষিত। সঠিক শব্দের পরামিতিগুলি অগ্রগতিতে কাজ করে এবং নিম্নলিখিতগুলির বর্তমান প্রস্তাব সহ প্রতিক্রিয়ার ভিত্তিতে পরিবর্তনের সাপেক্ষে:

  • নেভিগেশন উত্সগুলির জন্য পি = 0.24%
  • ইভেন্ট উত্সগুলির জন্য পি = 0.00025%

উপলব্ধ ট্রিগারগুলিতে সীমাবদ্ধতা (রূপান্তর)

নিম্নলিখিতগুলির বর্তমান প্রস্তাব সহ অ্যাট্রিবিউশন উত্স অনুসারে ট্রিগারগুলির সংখ্যার সীমাবদ্ধতা রয়েছে:

  • এডি ভিউ অ্যাট্রিবিউশন উত্সগুলির জন্য 1-2 ট্রিগার (2 টি ট্রিগার কেবল পোস্ট-ইনস্টল অ্যাট্রিবিউশনের ক্ষেত্রে উপলব্ধ)
  • ক্লিক বিজ্ঞাপনের উত্সগুলির জন্য 3 টি ট্রিগার

প্রতিবেদন প্রেরণের জন্য নির্দিষ্ট সময় উইন্ডোজ (ডিফল্ট আচরণ)

বিজ্ঞাপন ভিউ অ্যাট্রিবিউশন উত্সগুলির জন্য ইভেন্ট-স্তরের প্রতিবেদনগুলি উত্সের মেয়াদ শেষ হওয়ার 1 ঘন্টা পরে প্রেরণ করা হয়। এই মেয়াদোত্তীর্ণ তারিখটি কনফিগার করা যেতে পারে তবে এটি 1 দিনেরও কম বা 30 দিনের বেশি হতে পারে না। যদি দুটি ট্রিগারকে কোনও বিজ্ঞাপন ভিউ অ্যাট্রিবিউশন উত্স ( পোস্ট-ইনস্টল অ্যাট্রিবিউশনের মাধ্যমে) হিসাবে দায়ী করা হয় তবে ইভেন্ট-স্তরের প্রতিবেদনগুলি নিম্নলিখিত হিসাবে উল্লিখিত প্রতিবেদন উইন্ডো বিরতিতে প্রেরণ করা যেতে পারে।

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

  • 2 দিন: ডিভাইসটি অ্যাট্রিবিউশন উত্সটি নিবন্ধিত হওয়ার প্রায় 2 দিন পরে ঘটে যাওয়া সমস্ত ট্রিগার সংগ্রহ করে। অ্যাট্রিবিউশন উত্সটি নিবন্ধিত হওয়ার 2 দিন এবং 1 ঘন্টা পরে প্রতিবেদনটি প্রেরণ করা হয়।
  • 7 দিন: ডিভাইসটি 2 দিনের বেশি ঘটে যাওয়া সমস্ত ট্রিগার সংগ্রহ করে তবে অ্যাট্রিবিউশন উত্সটি নিবন্ধিত হওয়ার 7 দিনের বেশি পরে নেই। অ্যাট্রিবিউশন উত্সটি নিবন্ধিত হওয়ার 7 দিন এবং 1 ঘন্টা পরে প্রতিবেদনটি প্রেরণ করা হয়।
  • সময়ের একটি কাস্টম দৈর্ঘ্য, একটি অ্যাট্রিবিউশন উত্সের "মেয়াদোত্তীর্ণ" বৈশিষ্ট্য দ্বারা সংজ্ঞায়িত। প্রতিবেদনটি নির্দিষ্ট মেয়াদোত্তীর্ণ সময়ের 1 ঘন্টা পরে প্রেরণ করা হয়। এই মানটি 1 দিনেরও কম বা 30 দিনের বেশি হতে পারে না।

নমনীয় ইভেন্ট-স্তরের কনফিগারেশন

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

এই অতিরিক্ত নমনীয়তা দুটি পর্যায়ে এপিআই রিপোর্টিং এপিআইতে প্রবর্তিত হবে:

  • পর্ব 1: লাইট নমনীয় ইভেন্ট স্তরের কনফিগারেশন
    • এই সংস্করণটি সম্পূর্ণ বৈশিষ্ট্যগুলির একটি উপসেট সরবরাহ করে এবং দ্বিতীয় ধাপে স্বাধীনভাবে ব্যবহার করা যেতে পারে।
  • দ্বিতীয় ধাপ: নমনীয় ইভেন্ট স্তরের কনফিগারেশনের সম্পূর্ণ সংস্করণ

প্রথম ধাপ (লাইট নমনীয় ইভেন্ট স্তর) ব্যবহার করা যেতে পারে:

  • রিপোর্টিং উইন্ডোজের সংখ্যা নির্দিষ্ট করে প্রতিবেদনের ফ্রিকোয়েন্সি পরিবর্তিত করুন
  • উত্স রেজিস্ট্রেশন প্রতি গুণাবলীর সংখ্যা পরিবর্তিত করুন
  • উপরের পরামিতিগুলি হ্রাস করে মোট শব্দের পরিমাণ হ্রাস করুন
  • ডিফল্টগুলি ব্যবহার না করে উইন্ডোজ রিপোর্টিং কনফিগার করুন

দ্বিতীয় ধাপ (সম্পূর্ণ নমনীয় ইভেন্টের স্তর) পর্যায় 1 এবং:: এ সমস্ত ক্ষমতা করতে ব্যবহার করা যেতে পারে:

  • একটি প্রতিবেদনে ট্রিগার ডেটা কার্ডিনালিটি পরিবর্তিত করুন
  • ট্রিগার ডেটা কার্ডিনালিটি হ্রাস করে মোট শব্দের পরিমাণ হ্রাস করুন

ডিফল্ট কনফিগারেশনের একটি মাত্রা হ্রাস করা বিজ্ঞাপন প্রযুক্তিটিকে অন্য মাত্রা বাড়ানোর অনুমতি দেয়। বিকল্পভাবে, ইভেন্ট স্তরের প্রতিবেদনে মোট শব্দের মোট পরিমাণ উপরে উল্লিখিত পরামিতিগুলি হ্রাস করে হ্রাস করা যেতে পারে।

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

  • সর্বোচ্চ 20 টি মোট প্রতিবেদন, বিশ্বব্যাপী এবং প্রতি ট্রিগার_ডাটা
  • ট্রিগার_ডাটা প্রতি সর্বোচ্চ 5 সম্ভাব্য রিপোর্টিং উইন্ডোজ
  • সর্বাধিক 32 ট্রিগার ডেটা কার্ডিনালিটি (প্রথম ধাপের জন্য প্রযোজ্য নয়: লাইট নমনীয় ইভেন্ট স্তর)

বিজ্ঞাপন প্রযুক্তিগুলি এই বৈশিষ্ট্যটি ব্যবহার শুরু করার সাথে সাথে পরামর্শ দেওয়া উচিত যে এক্সট্রিমা মানগুলি ব্যবহারের ফলে প্রচুর পরিমাণে শব্দ হতে পারে বা গোপনীয়তার স্তরগুলি পূরণ না করা হলে নিবন্ধন করতে ব্যর্থ হতে পারে।

সমষ্টিগত প্রতিবেদন

সমষ্টিগত প্রতিবেদনগুলি ব্যবহার করার আগে আপনাকে অবশ্যই আপনার ক্লাউড অ্যাকাউন্ট সেট আপ করতে হবে এবং সমষ্টিগত প্রতিবেদনগুলি গ্রহণ শুরু করতে হবে।

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

  • ট্রিগার মানগুলির জন্য প্রতিবেদনগুলি যেমন রাজস্ব
  • আরও ট্রিগার প্রকার পরিচালনা

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

ডায়াগ্রামে প্রদর্শিত অ্যাট্রিবিউশন রিপোর্টিং এপিআই কীভাবে প্রস্তুত এবং সংহত প্রতিবেদনগুলি প্রেরণ করে তার সামগ্রিক নকশাটি নিম্নরূপ:

  1. ডিভাইসটি বিজ্ঞাপন প্রযুক্তিতে এনক্রিপ্ট করা সমষ্টিগত প্রতিবেদনগুলি প্রেরণ করে। একটি উত্পাদন পরিবেশে, বিজ্ঞাপন প্রযুক্তিগুলি সরাসরি এই প্রতিবেদনগুলি ব্যবহার করতে পারে না।
  2. বিজ্ঞাপন প্রযুক্তি সমষ্টিগত জন্য সমষ্টি পরিষেবাগুলিতে একত্রিতযোগ্য প্রতিবেদনের একটি ব্যাচ প্রেরণ করে।
  3. সমষ্টি পরিষেবা সমষ্টিগত প্রতিবেদনগুলির একটি ব্যাচ পড়ে, ডিক্রিপ্টস এবং তাদের সমষ্টি করে।
  4. চূড়ান্ত সমষ্টিগুলি সংক্ষিপ্ত প্রতিবেদনে বিজ্ঞাপন প্রযুক্তিতে ফেরত পাঠানো হয়।
প্রক্রিয়াটি যে অ্যাট্রিবিউশন রিপোর্টিং এপিআই ব্যবহার করে একত্রিতযোগ্য প্রতিবেদনগুলি প্রস্তুত এবং প্রেরণের জন্য ব্যবহার করে।

সমষ্টিগত প্রতিবেদনে অ্যাট্রিবিউশন উত্সগুলির সাথে সম্পর্কিত নিম্নলিখিত ডেটা রয়েছে:

  • গন্তব্য: অ্যাপের প্যাকেজের নাম বা ETLD+1 ওয়েব ইউআরএল যেখানে ট্রিগারটি ঘটেছে।
  • তারিখ: অ্যাট্রিবিউশন উত্স দ্বারা প্রতিনিধিত্ব করা ইভেন্টটি ঘটেছিল।
  • পে -লোড: ট্রিগার মানগুলি, এনক্রিপ্ট করা কী/মান জোড়া হিসাবে সংগৃহীত, যা সমষ্টি সমষ্টিতে বিশ্বস্ত সমষ্টি পরিষেবাতে ব্যবহৃত হয়।

সমষ্টি পরিষেবা

নিম্নলিখিত পরিষেবাগুলি একত্রিতকরণ কার্যকারিতা সরবরাহ করে এবং সমষ্টিগত ডেটার অনুপযুক্ত অ্যাক্সেস থেকে রক্ষা করতে সহায়তা করে।

এই পরিষেবাগুলি বিভিন্ন পক্ষ দ্বারা পরিচালিত হয়, যা পরে এই পৃষ্ঠায় আরও বিশদে বর্ণিত হয়েছে:

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

বিজ্ঞাপন প্রযুক্তি প্ল্যাটফর্মগুলি অবশ্যই আগাম, একটি সমষ্টি পরিষেবা স্থাপন করতে হবে যা গুগল দ্বারা সরবরাহিত বাইনারিগুলির উপর ভিত্তি করে।

এই সমষ্টি পরিষেবা মেঘে হোস্ট করা একটি বিশ্বস্ত এক্সিকিউশন এনভায়রনমেন্ট (টিইই) এ কাজ করে। একটি টি নিম্নলিখিত সুরক্ষা সুবিধা দেয়:

  • এটি নিশ্চিত করে যে টিইতে অপারেটিং কোডটি গুগল দ্বারা প্রদত্ত নির্দিষ্ট বাইনারি। যদি এই শর্তটি সন্তুষ্ট না হয় তবে সমষ্টি পরিষেবা এটি পরিচালনা করার জন্য ডিক্রিপশন কীগুলি অ্যাক্সেস করতে পারে না।
  • এটি বাহ্যিক পর্যবেক্ষণ বা টেম্পারিং থেকে বিচ্ছিন্ন করে চলমান প্রক্রিয়াটির চারপাশে সুরক্ষা সরবরাহ করে।

এই সুরক্ষা সুবিধাগুলি এনক্রিপ্ট করা ডেটা অ্যাক্সেস করার মতো সংবেদনশীল ক্রিয়াকলাপ সম্পাদনের জন্য একটি সমষ্টি পরিষেবাটির জন্য এটি নিরাপদ করে তোলে।

সমষ্টি পরিষেবাটির নকশা, কর্মপ্রবাহ এবং সুরক্ষা বিবেচনার বিষয়ে আরও তথ্যের জন্য, গিটহাবের সমষ্টি পরিষেবা নথিটি দেখুন।

কী পরিচালনা পরিষেবা

এই পরিষেবাটি যাচাই করে যে একটি সমষ্টি পরিষেবা বাইনারিটির অনুমোদিত সংস্করণ চালাচ্ছে এবং তারপরে বিজ্ঞাপন প্রযুক্তিতে তাদের ট্রিগার ডেটার জন্য সঠিক ডিক্রিপশন কীগুলির সাথে সমষ্টি পরিষেবা সরবরাহ করে।

সমষ্টিগত প্রতিবেদন অ্যাকাউন্টিং

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

সমষ্টিগত প্রতিবেদনগুলি এপিআই

একত্রিতযোগ্য প্রতিবেদনে অবদান তৈরির জন্য এপিআই ইভেন্ট-স্তরের প্রতিবেদনের জন্য কোনও অ্যাট্রিবিউশন উত্স নিবন্ধভুক্ত করার সময় একই বেস এপিআই ব্যবহার করে। নিম্নলিখিত বিভাগগুলি এপিআইয়ের এক্সটেনশনগুলি বর্ণনা করে।

সমষ্টিগত উত্স ডেটা নিবন্ধন করুন

যখন এপিআই অ্যাট্রিবিউশন উত্স ইউআরআইয়ের কাছে একটি অনুরোধ করে, বিজ্ঞাপন প্রযুক্তি এইচটিটিপি হেডার Attribution-Reporting-Register-Source নামে একটি নতুন ক্ষেত্রের সাথে সাড়া দিয়ে histogram_contributions নামক সমষ্টি কীগুলির একটি aggregation_keys নিবন্ধন করতে পারে, key_name হিসাবে কী এবং key_piece হিসাবে মান:

  • (কী) মূল নাম: কীটির নামের জন্য একটি স্ট্রিং। চূড়ান্ত কী গঠনের জন্য ট্রিগার-সাইড কীগুলির সাথে একত্রিত করতে যোগদানের কী হিসাবে ব্যবহৃত হয়।
  • (মান) কী টুকরা: কীটির জন্য বিটস্ট্রিং মান।

চূড়ান্ত হিস্টোগ্রাম বালতি কীটি এই টুকরোগুলি এবং ট্রিগার-পাশের টুকরোগুলিতে বাইনারি বা অপারেশন সম্পাদন করে ট্রিগার সময়ে সম্পূর্ণরূপে সংজ্ঞায়িত করা হয়।

চূড়ান্ত কীগুলি সর্বোচ্চ 128 বিটগুলিতে সীমাবদ্ধ; এর চেয়ে দীর্ঘ কীগুলি কাটা হয়। এর অর্থ হ'ল JSON এ হেক্স স্ট্রিংগুলি সর্বাধিক 32 ডিজিটের মধ্যে সীমাবদ্ধ হওয়া উচিত।

সমষ্টি কীগুলি কীভাবে কাঠামোগত হয় এবং আপনি কীভাবে সংহতকরণ কীগুলি কনফিগার করতে পারেন সে সম্পর্কে আরও জানুন ।

নিম্নলিখিত উদাহরণে, একটি বিজ্ঞাপন প্রযুক্তি নিম্নলিখিতগুলি সংগ্রহ করতে এপিআই ব্যবহার করে:

  • একটি প্রচার স্তরে সামগ্রিক রূপান্তর গণনা
  • একটি জিও স্তরে সামগ্রিক ক্রয়ের মান 
// This is where the Attribution-Reporting-Register-Source object appears when
// an ad tech registers an attribution source.

// Attribution source metadata specifying histogram contributions in aggregate report.
Attribution-Reporting-Register-Source:
…
aggregation_keys: {
  // Generates a "0x159" key piece named (low order bits of the key) for the key
  // named "campaignCounts".
  // User saw an ad from campaign 345 (out of 511).

  "campaignCounts": "0x159",
  // Generates a "0x5" key piece (low order bits of the key) for the key name "geoValue"
  // Source-side geo region = 5 (US), out of a possible ~100 regions.
  "geoValue": "0x5"
}

সমষ্টিগত ট্রিগার নিবন্ধন করুন

ট্রিগার নিবন্ধকরণে দুটি অতিরিক্ত ক্ষেত্র অন্তর্ভুক্ত রয়েছে।

প্রথম ক্ষেত্রটি ট্রিগার পাশের সামগ্রিক কীগুলির একটি তালিকা নিবন্ধন করতে ব্যবহৃত হয়। বিজ্ঞাপন প্রযুক্তিটি এইচটিটিপি হেডার Attribution-Reporting-Register-Trigger , তালিকার প্রতিটি সামগ্রিক কীগুলির জন্য নিম্নলিখিত ক্ষেত্রগুলির সাথে aggregatable_trigger_data ক্ষেত্রের সাথে প্রতিক্রিয়া জানাতে হবে:

  • কী টুকরা: কীটির জন্য বিটস্ট্রিং মান।
  • উত্স কীগুলি: অ্যাট্রিবিউশন উত্স সাইড কীগুলির নাম সহ স্ট্রিংগুলির একটি তালিকা যা ট্রিগার কীটি চূড়ান্ত কীগুলি গঠনের জন্য একত্রিত করা উচিত।

দ্বিতীয় ক্ষেত্রটি মানগুলির একটি তালিকা নিবন্ধন করতে ব্যবহৃত হয় যা প্রতিটি কীতে অবদান রাখতে পারে। বিজ্ঞাপন প্রযুক্তির এইচটিটিপি হেডার Attribution-Reporting-Register-Trigger aggregatable_values ​​ক্ষেত্রের সাথে প্রতিক্রিয়া জানাতে হবে। দ্বিতীয় ক্ষেত্রটি মানগুলির একটি তালিকা নিবন্ধন করতে ব্যবহৃত হয় যা প্রতিটি কীতে অবদান রাখতে পারে, যা পরিসীমা $ [1, 2^{16}] $ এর মধ্যে পূর্ণসংখ্যা হতে পারে $

প্রতিটি ট্রিগার সমষ্টিগত প্রতিবেদনে একাধিক অবদান রাখতে পারে। যে কোনও প্রদত্ত উত্স ইভেন্টে মোট অবদানের পরিমাণ একটি $ এল 1 $ প্যারামিটার দ্বারা আবদ্ধ, যা প্রদত্ত উত্সের জন্য সমস্ত সামগ্রিক কীগুলিতে সর্বাধিক অবদানের (মান) যোগফল। $ L1 $ উত্স ইভেন্টের জন্য হিস্টোগ্রাম অবদানের L1 সংবেদনশীলতা বা আদর্শকে বোঝায়। এই সীমা অতিক্রম করে ভবিষ্যতের অবদানগুলি নিঃশব্দে বাদ দেয়। প্রাথমিক প্রস্তাবটি হ'ল $ L1 $ থেকে $ 2^{16} $ (65536) সেট করা।

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

নিম্নলিখিত উদাহরণে, গোপনীয়তার বাজেট প্রতিটিটিতে $ L1 $ অবদান বিভক্ত করে campaignCounts এবং geoValue মধ্যে সমানভাবে বিভক্ত হয়:

// This is where the Attribution-Reporting-Register-Trigger object appears
// when an ad tech registers a conversion trigger.

// Specify a list of dictionaries that generates aggregation keys.
Attribution-Reporting-Register-Trigger:{
    …
    "aggregatable_trigger_data":

    [
    // Each dictionary independently adds pieces to multiple source keys.
    {
    // Conversion type purchase = 2 at a 9-bit offset, i.e. 2 << 9.
    // A 9-bit offset is needed because there are 511 possible campaigns, which
    // will take up 9 bits in the resulting key.
        "key_piece": "0x400",// Conversion type purchase = 2
        // Apply this key piece to:
        "source_keys": ["campaignCounts"]
    },
    {
    // Purchase category shirts = 21 at a 7-bit offset, i.e. 21 << 7.
    // A 7-bit offset is needed because there are ~100 regions for the geo key,
    // which will take up 7 bits of space in the resulting key.
        "key_piece": "0xA80",
        // Apply this key piece to:
        "source_keys": ["geoValue", "nonMatchingIdsListedHereAreIgnored"]
    }
    ]

    // Specify an amount of an abstract value which can be integers in [1, 2^16] to
    // contribute to each key that is attached to aggregation keys in the order that
    // they're generated.
    aggregatable_values:
    {
    // Privacy budget for each key is L1 / 2 = 2^15 (32768).
    // Conversion count was 1.
    // Scale the count to use the full budget allocated: 1 * 32768 = 32768.
        "campaignCounts": 32768,

    // Purchase price was $52.
    // Purchase values for the app range from $1 to $1,024 (integers only).
    // Scaling factor applied is 32768 / 1024 = 32.
    // For $52 purchase, scale the value by 32 ($52 * 32 = $1,664).
        "geoValue": 1664
    }
}

পূর্ববর্তী উদাহরণ নিম্নলিখিত হিস্টোগ্রাম অবদান উত্পন্ন করে:

[
  // campaignCounts:
  {
    "key": "0x559", // = 0x159 | 0x400
    "value": 32768
  },
  // geoValue:
  {
    "key": "0xA85",  // = 0x5 | 0xA80
    "value": 1664
  }
]

সঠিক মানগুলি, প্রয়োগ করা মডুলো শব্দগুলি পাওয়ার জন্য স্কেলিং উপাদানগুলি উল্টানো যেতে পারে: 

L1 = 65536
trueCampaignCounts = campaignCounts / (L1 / 2)
trueGeoValue = geoValue / (L1 / 2) * 1024

ডিফারেনশিয়াল গোপনীয়তা

এই এপিআইয়ের একটি লক্ষ্য হ'ল একটি কাঠামো রয়েছে যা পৃথকভাবে ব্যক্তিগত সামগ্রিক পরিমাপকে সমর্থন করতে পারে। নিম্নলিখিত বিতরণের সাথে শব্দ বাছাইয়ের মতো $ L1 $ বাজেটের আনুপাতিক শব্দ যুক্ত করে এটি অর্জন করা যেতে পারে:

\[ Laplace(\frac{L1}{ε}) \]

সুরক্ষিত শ্রোতা এপিআই এবং অ্যাট্রিবিউশন রিপোর্টিং এপিআই ইন্টিগ্রেশন

সুরক্ষিত শ্রোতা এবং অ্যাট্রিবিউশন রিপোর্টিং এপিআই জুড়ে ক্রস-এপিআই সংহতকরণ অ্যাডটেকগুলি বিভিন্ন পুনরায় বিপণন কৌশলগুলি জুড়ে তাদের অ্যাট্রিবিউশন পারফরম্যান্সকে মূল্যায়ন করতে সক্ষম করে যাতে কোন ধরণের শ্রোতারা সর্বোচ্চ আরওআই সরবরাহ করে তা বোঝার জন্য।

এই ক্রস-এপিআই সংহতকরণের মাধ্যমে, অ্যাডটেকগুলি করতে পারে:

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

যখন কোনও ব্যবহারকারী কোনও বিজ্ঞাপনে দেখেন বা ক্লিক করেন:

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

সুরক্ষিত দর্শকদের মধ্যে এটি কীভাবে সক্ষম করা হয়েছে সে সম্পর্কে আরও তথ্যের জন্য, সুরক্ষিত শ্রোতাদের এপিআই ব্যাখ্যার প্রাসঙ্গিক বিভাগটি দেখুন।

নিবন্ধকরণের অগ্রাধিকার, গুণাবলী এবং প্রতিবেদনের উদাহরণ

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

  • সমস্ত অ্যাট্রিবিউশন উত্স এবং ট্রিগারগুলি একই বিজ্ঞাপনদাতার জন্য একই বিজ্ঞাপন প্রযুক্তি দ্বারা নিবন্ধিত হয়।
  • প্রথম ইভেন্ট রিপোর্টিং উইন্ডো চলাকালীন সমস্ত অ্যাট্রিবিউশন উত্স এবং ট্রিগারগুলি ঘটছে (প্রাথমিকভাবে কোনও প্রকাশক অ্যাপে বিজ্ঞাপনগুলি প্রদর্শন করার 2 দিনের মধ্যে)।

কোনও ব্যবহারকারী যেখানে নিম্নলিখিতটি করেন তা বিবেচনা করুন:

  1. ব্যবহারকারী একটি বিজ্ঞাপন দেখেন। অ্যাড টেক 0 এর অগ্রাধিকার সহ এপিআইয়ের সাথে একটি অ্যাট্রিবিউশন উত্স নিবন্ধভুক্ত করে (দেখুন #1 দেখুন)।
  2. ব্যবহারকারী 0 এর অগ্রাধিকার সহ নিবন্ধিত একটি বিজ্ঞাপন দেখেন (দেখুন #2)।
  3. ব্যবহারকারী 1 এর অগ্রাধিকার সহ নিবন্ধিত একটি বিজ্ঞাপন ক্লিক করে ( #1 ক্লিক করুন)।
  4. ব্যবহারকারী কোনও বিজ্ঞাপনদাতা অ্যাপে রূপান্তর করে (অবতরণ পৃষ্ঠায় পৌঁছায়)। বিজ্ঞাপন প্রযুক্তি 0 (রূপান্তর #1) এর অগ্রাধিকার সহ এপিআইয়ের সাথে একটি ট্রিগার নিবন্ধন করে।
    • ট্রিগারগুলি নিবন্ধিত হওয়ার সাথে সাথে এপিআই রিপোর্ট তৈরির আগে প্রথমে অ্যাট্রিবিউশন সম্পাদন করে।
    • এখানে 3 টি অ্যাট্রিবিউশন উত্স উপলব্ধ রয়েছে: #1 দেখুন, #2 দেখুন, এবং #1 ক্লিক করুন। এপিআই #1 ক্লিক করার জন্য এই ট্রিগারটিকে দায়ী করে কারণ এটি সর্বোচ্চ অগ্রাধিকার এবং সাম্প্রতিকতম।
    • দেখুন #1 এবং দেখুন #2 বাতিল করা হয়েছে এবং ভবিষ্যতের অ্যাট্রিবিউশনের জন্য আর যোগ্য নয়।
  5. ব্যবহারকারী 1 (রূপান্তর #2) এর অগ্রাধিকার সহ নিবন্ধিত বিজ্ঞাপনদাতা অ্যাপে তাদের কার্টে একটি আইটেম যুক্ত করে।
    • ক্লিক করুন #1 হ'ল একমাত্র যোগ্য অ্যাট্রিবিউশন উত্স। এপিআই #1 ক্লিক করতে এই ট্রিগারটিকে দায়ী করে।
  6. ব্যবহারকারী বিজ্ঞাপনদাতা অ্যাপে তাদের কার্টে একটি আইটেম যুক্ত করে, 1 (রূপান্তর #3) এর অগ্রাধিকার সহ নিবন্ধিত।
    • ক্লিক করুন #1 হ'ল একমাত্র যোগ্য অ্যাট্রিবিউশন উত্স। এপিআই #1 ক্লিক করতে এই ট্রিগারটিকে দায়ী করে।
  7. ব্যবহারকারী বিজ্ঞাপনদাতা অ্যাপে তাদের কার্টে একটি আইটেম যুক্ত করে, 1 (রূপান্তর #4) এর অগ্রাধিকার সহ নিবন্ধিত।
    • ক্লিক করুন #1 হ'ল একমাত্র যোগ্য অ্যাট্রিবিউশন উত্স। এপিআই #1 ক্লিক করতে এই ট্রিগারটিকে দায়ী করে।
  8. ব্যবহারকারী বিজ্ঞাপনদাতা অ্যাপে ক্রয় করেন, 2 (রূপান্তর #5) এর অগ্রাধিকার সহ নিবন্ধিত।
    • ক্লিক করুন #1 হ'ল একমাত্র যোগ্য অ্যাট্রিবিউশন উত্স। এপিআই #1 ক্লিক করতে এই ট্রিগারটিকে দায়ী করে।

ইভেন্ট-স্তরের প্রতিবেদনে নিম্নলিখিত বৈশিষ্ট্য রয়েছে:

  • ডিফল্টরূপে, একটি ক্লিকের জন্য দায়ী প্রথম 3 টি ট্রিগার এবং একটি ভিউতে দায়ী প্রথম ট্রিগার প্রযোজ্য প্রতিবেদন উইন্ডোজ পরে প্রেরণ করা হয়।
  • রিপোর্টিং উইন্ডোর মধ্যে, যদি উচ্চতর অগ্রাধিকারের সাথে নিবন্ধিত ট্রিগার থাকে তবে তারা অগ্রাধিকার গ্রহণ করে এবং সাম্প্রতিক ট্রিগারটি প্রতিস্থাপন করে।
  • পূর্ববর্তী উদাহরণে, বিজ্ঞাপন প্রযুক্তি 2 দিনের রিপোর্টিং উইন্ডোর পরে 3 টি ইভেন্টের প্রতিবেদন গ্রহণ করে, রূপান্তর #2, রূপান্তর #3, এবং রূপান্তর #5 এর জন্য।
    • সমস্ত 5 ট্রিগার #1 ক্লিক করার জন্য দায়ী করা হয়। ডিফল্টরূপে, এপিআই প্রথম 3 টি ট্রিগারগুলির জন্য প্রতিবেদনগুলি প্রেরণ করবে: রূপান্তর #1, রূপান্তর #2, এবং রূপান্তর #3।
    • তবে রূপান্তর #4 এর অগ্রাধিকার ( 1 ) রূপান্তর #1 এর অগ্রাধিকার ( 0 ) এর চেয়ে বেশি। রূপান্তর #4 এর ইভেন্ট রিপোর্টে রূপান্তর #1 এর ইভেন্ট প্রতিবেদনটি প্রেরণ করা হবে।
    • অতিরিক্তভাবে, রূপান্তর #5 এর অগ্রাধিকার ( 2 ) অন্য কোনও ট্রিগারের চেয়ে বেশি। রূপান্তর #5 এর ইভেন্টের প্রতিবেদনে রূপান্তর #4 এর প্রতিবেদনটি প্রেরণ করার জন্য প্রতিস্থাপন করা হয়েছে।

সমষ্টিগত প্রতিবেদনের নিম্নলিখিত বৈশিষ্ট্যগুলি রয়েছে:

  • ট্রিগারগুলি নিবন্ধিত হওয়ার কয়েক ঘন্টা পরে, এনক্রিপ্ট করা সমষ্টিগত প্রতিবেদনগুলি প্রক্রিয়া করার সাথে সাথে বিজ্ঞাপন প্রযুক্তিতে প্রেরণ করা হয়।

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

  • এটি কখন এবং কীভাবে একত্রিতযোগ্য প্রতিবেদনগুলি ব্যাচ করা যায় এবং সমষ্টি পরিষেবাটিতে প্রেরণ করা যায় সে সম্পর্কে এটি।

  • ইভেন্ট-স্তরের প্রতিবেদনের সাথে তুলনা করে, এনক্রিপ্ট করা সমষ্টিগত প্রতিবেদনগুলি আরও ট্রিগারগুলিকে কোনও উত্সকে দায়ী করতে পারে।

  • পূর্ববর্তী উদাহরণে, 5 টি সমষ্টিগত প্রতিবেদনগুলি প্রেরণ করা হয়, প্রতিটি নিবন্ধিত ট্রিগারের জন্য একটি।

ট্রানজিশনাল ডিবাগিং রিপোর্ট

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

অ্যাপ্লিকেশন-টু-ওয়েব এবং ওয়েব-টু-অ্যাপ্লিকেশন পরিমাপের সাথে ডিবাগিং প্রতিবেদনের বিশদগুলির জন্য ট্রানজিশনাল ডিবাগিং প্রতিবেদনের গাইডটি পড়ুন।

অ্যাট্রিবিউশন-সাবসেস ডিবাগিং রিপোর্ট

উত্স এবং ট্রিগার রেজিস্ট্রেশন উভয়ই একটি নতুন 64-বিট debug_key ক্ষেত্র (স্ট্রিং হিসাবে ফর্ম্যাট করা) গ্রহণ করে, যা বিজ্ঞাপন প্রযুক্তি পপুলেট করে। source_debug_key এবং trigger_debug_key ইভেন্ট-স্তরের এবং সামগ্রিক প্রতিবেদনে উভয়ই আনল্টারড পাস করা হয়।

যদি উত্স এবং ট্রিগার ডিবাগ কী উভয় দিয়েই কোনও প্রতিবেদন তৈরি করা হয় তবে একটি ডুপ্লিকেট ডিবাগ প্রতিবেদনটি .well-known/attribution-reporting/debug/report-event-attribution ডিবাগ প্রতিবেদনগুলি উভয় ডিবাগ কী ক্ষেত্র সহ সাধারণ প্রতিবেদনের সাথে সমান। Including these keys in both allows tying normal reports to the separate stream of debug reports.

  • For event-level reports:
    • Duplicate debug reports are sent with limited delay and therefore aren't suppressed by limits on available triggers , which allows ad tech to understand the impact of those limits for event-level reports.
    • Event-level reports associated with false trigger events will not have trigger_debug_key s. This allows ad tech to more closely understand how noise is applied in the API.
  • For aggregatable reports:
    • We will support a new debug_cleartext_payload field which contains the decrypted payload, only if both source_debug_key and trigger_debug_key are set.

Verbose debugging reports

Verbose debugging reports allow developers to monitor certain failures in the attribution source or trigger registrations. These debugging reports are sent with limited delay after attribution source or trigger registrations to a . well-known/attribution-reporting/debug/verbose endpoint.

Each verbose report contains the following fields:

  • Type : what caused the report to be generated. See the full list of verbose report types .
    • In general, there are source verbose reports and trigger verbose reports.
    • Source verbose reports require the advertising ID to be available to the publisher app, and trigger verbose reports require the advertising ID to be available to the advertiser app.
    • Trigger verbose reports (with the exception of trigger-no-matching-source ) can optionally include the source_debug_key . This can only be included if the advertising ID is also available to the publisher app.
  • Body : The report's body, which depends on its type.

Ad techs need to opt in to receive verbose debugging reports using a new debug_reporting dictionary field in the Attribution-Reporting-Register_Source and Attribution-Reporting-Register-Trigger headers.

  • Source verbose reports require opt-in on the source registration header only.
  • Trigger debug reports require opt-in on the trigger registration header only.

How to use debug reports

If a conversion took place (according to your existing measurement system) and a debug report was received for that conversion, this means the trigger was successfully registered.

For each debug attribution report, check if you're receiving a regular attribution report that matches the two debug keys.

When there's no match, it can be for a number of reasons.

Works as intended:

  • Privacy-preserving API behaviors:
    • A user hits the report rate limit—causing all subsequent reports to not be sent in the time period; or a source is removed due to the pending destination limit.
    • For event-level reports: the report is subject to randomized response (noise) and is suppressed, or you may receive a randomized report.
    • For event-level reports: the limit of three (for clicks) or one (for views) reports has been reached, and subsequent reports have no explicit priority set, or a priority that is lower than existing reports.
    • The contribution limits for aggregatable reports have been exceeded.
  • Ad tech-defined business logic:
    • A trigger is filtered out via filters or priority rules.
  • Time delays or interactions with network availability (eg, the user turns off their device for an extended period of time).

Unintended causes:

  • Implementation issues:
    • The source header is misconfigured.
    • The trigger header is misconfigured.
    • Other configuration issues.
  • Device or network issues:
    • Failures due to network conditions.
    • Source or trigger registration response doesn't reach the client.
    • API bug.

Future considerations & open questions

The Attribution Reporting API is a work in progress. We're also exploring future potential features, such as non-last-click attribution models and cross-device measurement use cases.

Additionally, we'd like to seek feedback from the community on a few issues:

  1. Are there any use cases where you'd like the API to send out reports for the verified install? These reports would count against ad tech platforms' respective rate limits.
  2. Do you foresee any difficulties with passing the InputEvent from the app to ad tech for source registration?
  3. Do you have any special attribution use cases for pre-loaded apps or re-installed apps?