অ্যাট্রিবিউশন রিপোর্টিং প্রস্তাবের আপডেট জানুয়ারী 2022 এ

এট্রিবিউশন রিপোর্টিং প্রস্তাবে সম্প্রদায়ের প্রতিক্রিয়ার সমাধান করার জন্য এপিআই মেকানিজম পরিবর্তন থেকে নতুন কার্যকারিতা পর্যন্ত অনেক পরিবর্তন হয়েছে।

চেঞ্জলগ

কার জন্য এই পোস্ট?

এই পোস্টটি আপনার জন্য:

  • আপনি যদি ইতিমধ্যে API বুঝতে পারেন—উদাহরণস্বরূপ, আপনি যদি WICG সংগ্রহস্থলের আলোচনা পর্যবেক্ষণ করছেন বা অংশগ্রহণ করছেন এবং 2022 সালের জানুয়ারিতে প্রস্তাবে করা পরিবর্তনের ব্যাচ বুঝতে চান।
  • আপনি যদি অ্যাট্রিবিউশন রিপোর্টিং এপিআই ব্যবহার করেন ডেমোতে বা উৎপাদনে একটি পরীক্ষায়।

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

সামনে মাইগ্রেশন

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

এই নিবন্ধটি সমষ্টিগত প্রতিবেদনের পরিবর্তনগুলিও তালিকাভুক্ত করে৷ যাইহোক, এই পরিবর্তনগুলি, বাস্তবায়িত হলে, কোন পদক্ষেপ বা স্থানান্তরের প্রয়োজন হবে না, কারণ এই লেখার সময় সমষ্টিগত প্রতিবেদনের জন্য এখনও কোন ব্রাউজার বাস্তবায়ন নেই।

নাম পরিবর্তন

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

আপনি যা দেখেছেন সমষ্টিগত প্রতিবেদন হিসাবে বর্ণনা করা হয়েছে তা এখন সংক্ষিপ্ত প্রতিবেদন হিসাবে উল্লেখ করা হবে।

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

এপিআই মেকানিজম পরিবর্তন

হেডার-ভিত্তিক উৎস নিবন্ধন (ইভেন্ট-স্তরের প্রতিবেদন)

কি পরিবর্তন হচ্ছে, এবং কেন?

ব্যবহারকারী যখন কোনো বিজ্ঞাপন দেখেন বা ক্লিক করেন, তখন ব্রাউজার—স্থানীয়ভাবে ব্যবহারকারীর ডিভাইসে—এই ইভেন্টটি রেকর্ড করে, সেই সাথে অ্যাট্রিবিউশন রিপোর্টিংয়ের জন্য নির্দিষ্ট প্যারামিটারগুলি (যেমন attributionsourceeventid , attributiondestination , attributionexpiry এবং অন্যান্য প্যারামিটার)। এই প্যারামিটারের মান অ্যাডটেক দ্বারা সেট করা হয়।

এই পরামিতি সেট করা হয় উপায় পরিবর্তন করা হয়.

পূর্ববর্তী প্রস্তাবে, পরামিতিগুলিকে ক্লায়েন্ট-সাইড অন্তর্ভুক্ত করতে হয়েছিল: হয় এইচটিএমএল অ্যাট্রিবিউট হিসাবে অ্যাঙ্কর ট্যাগে, বা একটি জেএস-ভিত্তিক কলের আর্গুমেন্ট হিসাবে। ক্লিক বা ভিউ টাইমে পরামিতি জানতে হবে।

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

হেডার-ভিত্তিক উৎস নিবন্ধনের চিত্র

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

উৎস নিবন্ধন কিভাবে কাজ করে?

  1. একটি প্রদত্ত বিজ্ঞাপনের জন্য, adtech-কে এখন একটি নির্দিষ্ট ক্লায়েন্ট-সাইড অ্যাট্রিবিউট attributionsrc সংজ্ঞায়িত করতে হবে। এই বৈশিষ্ট্যের মান হল একটি URL যেখানে ব্রাউজার একটি অনুরোধ পাঠাবে; এই অনুরোধে একটি নতুন HTTP শিরোনাম Attribution-Reporting-Source-Info অন্তর্ভুক্ত থাকবে যার মান, navigation বা event, উৎসটি যথাক্রমে ক্লিক বা ভিউ ছিল কিনা তা নির্দিষ্ট করে।
  2. এই অনুরোধটি পাওয়ার পর, ক্লিক/ভিউ ট্র্যাকিং সার্ভারটিকে একটি HTTP শিরোনাম, Attribution-Reporting-Register-Source দিয়ে সাড়া দেওয়া উচিত, যাতে কাঙ্ক্ষিত অ্যাট্রিবিউশন প্যারামিটার রয়েছে৷

  3. মূল যেটি এই শিরোনামটি ফেরত দেয় সেটিই এখন প্রতিবেদনের উত্স (পূর্বে attributionreportto হিসাবে সংজ্ঞায়িত)।

    HTTP রেসপন্স হেডার Attribution-Reporting-Register-Source : 

    {
  "source_event_id": "267630968326743374",
  "destination": "https://toasters.example",
  "expiry": "604800000"
}

প্রযুক্তিগত ব্যাখ্যাকারীতে আরও জানুন

অ্যাট্রিবিউশন উত্স নিবন্ধন করা হচ্ছে

পাবলিক আলোচনা যোগদান

সংখ্যা #261

হেডার-ভিত্তিক অ্যাট্রিবিউশন ট্রিগার (ইভেন্ট-লেভেল রিপোর্ট)

কি পরিবর্তন হচ্ছে, এবং কেন?

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

অতিরিক্তভাবে, নতুন প্রস্তাবে, রূপান্তর পৃষ্ঠায় attributionsrc অ্যাট্রিবিউট প্রয়োজন।

যুক্তি হল অনুমতির বিষয়: পূর্ববর্তী প্রস্তাবে, ট্রিগার-সাইড সাইট—সাধারণত, একটি বিজ্ঞাপনদাতা সাইট—একটি Permissions-Policy শিরোনামের মাধ্যমে বৈশিষ্ট্যটির উপর সাধারণ নিয়ন্ত্রণ ছিল, কিন্তু দানাদার, উপাদান-স্তরের নিয়ন্ত্রণ ছিল না একটি উপাদান একটি পক্ষের কাছে একটি অনুরোধ পাঠাতে পারে যা শেষ পর্যন্ত একটি অ্যাট্রিবিউশনকে ট্রিগার করবে। attributionsrc এটি পরিবর্তন করে: এই বাধ্যতামূলক মার্কার বিজ্ঞাপনদাতাকে নিরীক্ষণ করার ক্ষমতা দেয় এবং তাই কোন উপাদানগুলি একটি অ্যাট্রিবিউশনকে ট্রিগার করতে পারে তা নিয়ন্ত্রণ করে।

উল্লেখ্য যে উৎসের দিকে—সাধারণত, একটি প্রকাশক সাইট— Permissions-Policy মাধ্যমে একটি পৃষ্ঠা-ব্যাপী নিয়ন্ত্রণ, সেইসাথে attributionsrc এর মাধ্যমে একটি উপাদান-বিস্তৃত নিয়ন্ত্রণ উপস্থিত থাকে।

অ্যাট্রিবিউশন ট্রিগার কিভাবে কাজ করে?

একটি পিক্সেল অনুরোধ পাওয়ার পরে এবং এটিকে রূপান্তর হিসাবে শ্রেণীবদ্ধ করা উচিত বলে সিদ্ধান্ত নেওয়ার পরে, একটি অ্যাডটেকের একটি নতুন HTTP এর সাথে প্রতিক্রিয়া জানানো উচিত
হেডার Attribution-Reporting-Register-Event-Trigger ।

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

HTTP রেসপন্স হেডার Attribution-Reporting-Register-Event-Trigger : 

    [{
        trigger_data: (unsigned 3-bit integer),
        trigger_priority: (signed 64-bit integer),
        deduplication_key: (signed 64-bit integer)
    }]

পুনর্নির্দেশ (ঐচ্ছিক)

ঐচ্ছিকভাবে, অ্যাডটেক সার্ভারটি Attribution-Reporting-Register-Event-Trigger রিডাইরেক্ট প্রতিক্রিয়া ধারণ করতে পারে। এটির সাহায্যে, এটি তৃতীয় পক্ষগুলিকে রূপান্তর ইভেন্টটি পর্যবেক্ষণ করতে এবং ব্রাউজারকে এটিকে বৈশিষ্ট্যযুক্ত করার নির্দেশ দিতে সক্ষম করে।

পুনর্নির্দেশ ঐচ্ছিক; যখন একটি অ্যাডটেক এবং তৃতীয় পক্ষ উভয়ের পৃষ্ঠায় পিক্সেল থাকে তখন এটির প্রয়োজন হয় না৷

তৃতীয় পক্ষের প্রতিবেদনে আরও বিশদ বিবরণ।

প্রযুক্তিগত ব্যাখ্যাকারীতে আরও জানুন

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

পাবলিক আলোচনা যোগদান

ইস্যু #91

কোন ওয়ার্কলেট নেই (একত্রিত প্রতিবেদন)

কি পরিবর্তন হচ্ছে, এবং কেন?

সমষ্টিগত প্রতিবেদনের পূর্ববর্তী প্রস্তাবে, জাভাস্ক্রিপ্ট অ্যাক্সেসের প্রয়োজন ছিল একটি ওয়ার্কলেট - একটি জাভাস্ক্রিপ্ট-ভিত্তিক প্রক্রিয়া - যা এই প্রতিবেদনগুলি তৈরি করবে।

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

নতুন প্রস্তাবে বেশ কিছু সুবিধা রয়েছে:

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

ওয়ার্কলেট-মুক্ত প্রক্রিয়া কীভাবে কাজ করে?

এই ঘোষণামূলক প্রক্রিয়াটি HTTP শিরোনামের উপর ভিত্তি করে—ঠিক যেমন ইভেন্ট-লেভেল সোর্স রেজিস্ট্রেশন এবং অ্যাট্রিবিউশন ট্রিগার হেডার। পরবর্তী বিভাগে এই বিষয়ে আরো বিস্তারিত.

পাবলিক আলোচনা যোগদান

ইস্যু #194

হেডার-ভিত্তিক উৎস নিবন্ধন (একত্রিত প্রতিবেদন)

একটি সমষ্টিগত প্রতিবেদনের জন্য একটি উত্স নিবন্ধন করার জন্য একটি নতুন প্রক্রিয়া প্রস্তাব করা হয়েছে; এই মেকানিজম ইভেন্ট-লেভেল সোর্স রেজিস্ট্রেশনের মতই।

শুধুমাত্র হেডারের নাম আলাদা: Attribution-Reporting-Register-Aggregatable-Source ।

প্রযুক্তিগত ব্যাখ্যাকারীতে আরও জানুন

অ্যাট্রিবিউশন সোর্স রেজিস্ট্রেশন

হেডার-ভিত্তিক অ্যাট্রিবিউশন ট্রিগার (একত্রিত প্রতিবেদন)

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

শুধুমাত্র হেডারের নাম আলাদা: Attribution-Reporting-Register-Aggregatable-Trigger-Data ।

প্রযুক্তিগত ব্যাখ্যাকারীতে আরও জানুন

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

নতুন বৈশিষ্ট্য

থার্ড-পার্টি রিপোর্টিং (ইভেন্ট-লেভেল রিপোর্ট এবং সমষ্টিগত রিপোর্ট)

কি পরিবর্তন হচ্ছে, এবং কেন?

নতুন প্রস্তাবের দুটি দিক তৃতীয় পক্ষের রিপোর্টিং ব্যবহারের ক্ষেত্রে আরও ভালভাবে সহায়তা করতে সহায়তা করে:

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

তৃতীয় পক্ষের রিপোর্টিং কিভাবে কাজ করে?

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

যদি একটি প্রকাশক সাইটে একটি ক্লিক/ভিউ অনুরোধ (উৎস নিবন্ধন) পরবর্তীতে একাধিক পক্ষের কাছে পুনঃনির্দেশিত হয়, এই দলগুলির প্রত্যেকটি এই ভিউ বা ক্লিক (উৎস ইভেন্ট) নিবন্ধন করতে পারে।
একইভাবে, একটি অ্যাডটেক একটি বিজ্ঞাপনদাতা সাইট থেকে করা একটি নির্দিষ্ট অ্যাট্রিবিউশন অনুরোধ পুনঃনির্দেশ করতে পারে, যা একাধিক অন্যান্য পক্ষকে একটি রূপান্তর (অ্যাট্রিবিউশন ট্রিগার) নিবন্ধন করতে দেয়৷

প্রতিটি পক্ষ তাদের পৃথক প্রতিবেদনগুলি অ্যাক্সেস করতে এবং তাদের পৃথক ডেটা দিয়ে কনফিগার করতে সক্ষম ৷

রিডাইরেক্ট ছাড়াই একাধিক ট্রিগার নিবন্ধন করুন

রূপান্তর সাইডে একাধিক পিক্সেল উপাদান যুক্ত করে (প্রতি ট্রিগারে একটি) রিডাইরেক্ট ব্যবহার না করে একাধিক অ্যাট্রিবিউশন ট্রিগার নিবন্ধন করাও সম্ভব।

পাবলিক আলোচনা যোগদান

ইস্যু #91 ইস্যু #261

ভিউ-থ্রু পরিমাপ (ইভেন্ট-লেভেল রিপোর্ট এবং সমষ্টিগত রিপোর্ট)

কি পরিবর্তন হচ্ছে, এবং কেন?

নতুন প্রস্তাবে, ভিউ-থ্রু পরিমাপ এবং ক্লিক-থ্রু পরিমাপ একীভূত উপায়ে কাজ করে:

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

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

কিভাবে ভিউ-থ্রু পরিমাপ কাজ করে?

ভিউ-থ্রু পরিমাপ এবং ক্লিক-থ্রু পরিমাপ উভয়ই হেডার-ভিত্তিক নিবন্ধনের উপর নির্ভর করে।

প্রযুক্তিগত ব্যাখ্যাকারীতে আরও জানুন

ইভেন্ট-স্তরের রিপোর্ট (ক্লিক এবং ভিউ উভয়ের জন্য)

পাবলিক আলোচনা যোগদান

সংখ্যা #261

ডিবাগিং / কর্মক্ষমতা বিশ্লেষণ (ইভেন্ট-স্তরের রিপোর্ট এবং সমষ্টিগত প্রতিবেদন)

কি পরিবর্তন হচ্ছে, এবং কেন?

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

নতুন কুকি-ভিত্তিক ডিবাগিং সিস্টেমের চিত্র

ডিবাগিং কিভাবে কাজ করে?

উত্স এবং ট্রিগার নিবন্ধন উভয়ই একটি নতুন প্যারামিটার debug_key , একটি 64-বিট স্বাক্ষরবিহীন পূর্ণসংখ্যা (অর্থাৎ একটি বড় সংখ্যা) গ্রহণ করবে।

যদি উৎস এবং ট্রিগার ডিবাগ কীগুলির সাহায্যে একটি প্রতিবেদন তৈরি করা হয় এবং উৎস এবং ট্রিগার নিবন্ধকরণের সময় রিপোর্টিং মূলের কুকি জারে একটি Samesite=None ar_debug=1 কুকি উপস্থিত থাকে, তাহলে একটি ডিবাগ রিপোর্ট (JSON) একটি .well-known/attribution-reporting/debug এ পাঠানো হবে। .well-known/attribution-reporting/debug এন্ডপয়েন্ট:

{
  "source_debug_key": 1234567890987,
  "trigger_debug_key": 4567654345028
}

ইভেন্ট-স্তর এবং সমষ্টিগত প্রতিবেদনে এই দুটি নতুন প্যারামিটার অন্তর্ভুক্ত করা হবে, যাতে তারা সঠিক ডিবাগ রিপোর্টের সাথে যুক্ত হতে পারে।

প্রযুক্তিগত ব্যাখ্যাকারীতে আরও জানুন

ঐচ্ছিক: বর্ধিত ডিবাগিং রিপোর্ট

পাবলিক আলোচনা যোগদান

ইস্যু #174

ফিল্টারিং ক্ষমতা (ইভেন্ট-স্তরের প্রতিবেদন এবং সমষ্টিগত প্রতিবেদন)

কি পরিবর্তন হচ্ছে, এবং কেন?

যেহেতু তারা আজকের বিজ্ঞাপন ইকোসিস্টেমে গুরুত্বপূর্ণ ব্যবহারের ক্ষেত্রে সমর্থন করে, তাই ইভেন্ট-স্তর এবং সমষ্টিগত প্রতিবেদন উভয় ক্ষেত্রেই বেশ কয়েকটি ব্যবহারের ক্ষেত্রে সমর্থন করা হবে:

  • রূপান্তর ফিল্টারিং: উৎস-সাইড তথ্যের উপর ভিত্তি করে একটি রূপান্তর ফিল্টার করুন। উদাহরণস্বরূপ, বিজ্ঞাপন ক্লিক এবং দর্শনের জন্য বিভিন্ন ট্রিগার ডেটা (রূপান্তর ডেটা) নির্বাচন করুন৷
  • অ্যাট্রিবিউশন অমিল: ফিল্টার রূপান্তরগুলি যা ভুলভাবে চিহ্নিত করা হয়েছে; এটি একটি নির্দিষ্ট ধরনের রূপান্তর ফিল্টারিং। উদাহরণস্বরূপ, API-এ etld+1 গন্তব্য সুযোগের কারণে ভুল বিজ্ঞাপন ক্লিক/ভিউয়ের সাথে মিলে যাওয়া রূপান্তরগুলিকে ফিল্টার করুন।

ফিল্টারিং ক্ষমতা কিভাবে কাজ করে? (ইভেন্ট-স্তরের প্রতিবেদনের জন্য)

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

  {
    source_event_id: "267630968326743374",
    destination: "https://toasters.example",
    expiry: "604800000"
    source_data: {
      conversion_subdomain: ["electronics.megastore"
                              "electronics2.megastore"],
      product: "198764",
      // Note that "source_type" will be automatically generated as one of {"navigation", "event"}
    }
  }

ট্রিগার নিবন্ধন এখন একটি ঐচ্ছিক হেডার Attribution-Reporting-Filters গ্রহণ করবে।

HTTP রেসপন্স হেডার Attribution-Reporting-Filters :

{
  "conversion_subdomain": "electronics.megastore",
  "directory": "/store/electronics"
}

বিকল্পভাবে, Attribution-Reporting-Register-Event-Trigger শিরোনামটি source_data উপর ভিত্তি করে trigger_data সেট করতে নির্বাচনী ফিল্টারিং করার জন্য একটি filters ক্ষেত্রের সাথে প্রসারিত করা যেতে পারে।

যদি JSON ফিল্টারগুলির কীগুলি source_data তে কীগুলির সাথে মেলে, ট্রিগারটি হয়৷
ছেদ খালি থাকলে সম্পূর্ণ উপেক্ষা করা হয়।

প্রযুক্তিগত ব্যাখ্যাকারীতে আরও জানুন

ঐচ্ছিক অ্যাট্রিবিউশন ফিল্টার

পাবলিক আলোচনা যোগদান

ইস্যু #194
সংখ্যা #201

গোপনীয়তা সুরক্ষা পরিবর্তন

গোলমাল এবং স্বচ্ছতা (ইভেন্ট-স্তরের প্রতিবেদন এবং সমষ্টিগত প্রতিবেদন)

কি পরিবর্তন হচ্ছে, এবং কেন?

নতুন প্রস্তাবে, প্রতিবেদনের গোপনীয়তা প্রক্রিয়াগুলির মধ্যে একটি উন্নত করা হয়েছে: প্রতিবেদনগুলি এলোমেলো প্রতিক্রিয়ার সাপেক্ষে।
এর মানে হল কিছু বাস্তব রূপান্তর সঠিকভাবে রিপোর্ট করা হবে; এবং সময়ের একটি নির্দিষ্ট শতাংশ, কিছু বাস্তব রূপান্তর দমন করা হবে বা কিছু জাল রূপান্তর যোগ করা হবে ।

এই নতুন কৌশলটির কয়েকটি সুবিধা রয়েছে:

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

এই নতুন মেকানিজমটি আগের মেকানিজমকে প্রতিস্থাপন করে যেখানে সময়ের 5%, ট্রিগার ডেটা (রূপান্তর ডেটা) একটি এলোমেলো মান দিয়ে প্রতিস্থাপিত হয়েছিল।

অতিরিক্তভাবে, র্যান্ডমাইজড প্রতিক্রিয়া সম্ভাব্যতা মান রিপোর্টের মূল অংশে যোগ করা হয়েছে ( randomized_trigger_rate ক্ষেত্র)। এই ক্ষেত্রটি সম্ভাব্যতা (0 থেকে 1) নির্দিষ্ট করে যে একটি উৎস এলোমেলো প্রতিক্রিয়ার সাপেক্ষে।

এর দুটি প্রধান সুবিধা রয়েছে:

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

কিভাবে গোলমাল কাজ করে?

নতুন প্রস্তাবে, একটি উত্স নিবন্ধিত হওয়ার সময় (যেমন একটি বিজ্ঞাপন ক্লিক বা ভিউ রেকর্ড করা হয়), ব্রাউজার এলোমেলোভাবে সিদ্ধান্ত নেয় যে এটি সত্যই রূপান্তরগুলিকে দায়ী করবে এবং এই বিজ্ঞাপন ক্লিক/ভিউয়ের জন্য প্রতিবেদন পাঠাবে, বা এটি একটি জাল তৈরি করবে কিনা। পরিবর্তে আউটপুট ।

জাল আউটপুট হতে পারে:

  • কোনো রিপোর্ট নেই —ব্যবহারকারী কনভার্ট করুক না কেন;
  • এক বা একাধিক জাল রিপোর্ট — ব্যবহারকারী কনভার্ট করুক না কেন।

জাল রিপোর্টে, ট্রিগার ডেটা (রূপান্তর ডেটা) এলোমেলো: ক্লিকের জন্য একটি এলোমেলো 3-বিট মান (0 এবং 7 এর মধ্যে যে কোনও সংখ্যা) এবং ভিউগুলির জন্য একটি এলোমেলো 1-বিট মান (0 বা 1)৷

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

ক্লিকের জন্য তিনটি রিপোর্টিং উইন্ডো আছে (ক্লিকের পর 2 দিন, 7 দিন বা 30 দিন)। প্রতিটি জাল রিপোর্ট এলোমেলোভাবে রিপোর্টিং উইন্ডোগুলির একটিতে বরাদ্দ করা হয়।

আলাদাভাবে, পূর্ববর্তী প্রস্তাবে ইতিমধ্যেই বলা হয়েছে, একটি উইন্ডোর মধ্যে রিপোর্টের ক্রম এলোমেলো।

প্রযুক্তিগত ব্যাখ্যাকারীতে আরও জানুন

শোরগোল জাল রূপান্তর উদাহরণ

পাবলিক আলোচনা যোগদান

ইস্যু #84
সংখ্যা #273

রিপোর্টিং সীমাবদ্ধতা (ইভেন্ট-স্তরের রিপোর্ট এবং সমষ্টিগত রিপোর্ট)

রিপোর্টিং মূল সীমা

কি পরিবর্তন হচ্ছে, এবং কেন?

নতুন প্রস্তাবটি স্পষ্টভাবে সীমিত করে যে কতগুলি পক্ষ দুটি সাইটের মধ্যে ইভেন্ট পরিমাপ করতে পারে ।

  • প্রতি {publisher, advertiser} সোর্স রেজিস্টার করতে পারে এমন অনন্য রিপোর্টিং অরিজিনগুলির সর্বাধিক সংখ্যা (সাধারণত adtechs) প্রতি 30 দিনে 100 তে সীমাবদ্ধ করার প্রস্তাব করা হয়েছে৷ এই কাউন্টারটি প্রতিটি বিজ্ঞাপন ক্লিক বা ভিউ (সোর্স ইভেন্ট) এর জন্য বৃদ্ধি করা হবে, এমনকি যেগুলি অ্যাট্রিবিউট করা হয়নি।
  • প্রতি {publisher, advertiser} রিপোর্ট পাঠাতে পারে এমন অনন্য রিপোর্টিং উত্সের সর্বাধিক সংখ্যা (সাধারণত adtechs) প্রতি 30 দিনে 10 তে সীমাবদ্ধ করার প্রস্তাব করা হয়েছে৷ প্রতিটি বৈশিষ্ট্যযুক্ত রূপান্তরের জন্য এই কাউন্টারটি বৃদ্ধি করা হবে।

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

কুলডাউন / হার সীমা প্রতিবেদন করা

কি পরিবর্তন হচ্ছে, এবং কেন?

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

নতুন প্রস্তাবে, প্রতি {সোর্স সাইট, ডেস্টিনেশন, রিপোর্টিং অরিজিন} (সাধারণত {প্রকাশক, বিজ্ঞাপনদাতা, অ্যাডটেক}) 100টি রিপোর্ট 30 দিনের মধ্যে নির্ধারিত হতে পারে।

এই সীমার বাইরে, ব্রাউজার এই প্রদত্ত {source site, destination, reporting origin} (সাধারণত {publisher, advertiser, adtech})-এর সাথে মেলে এমন রিপোর্টের শিডিউল করা বন্ধ করে দেবে- যতক্ষণ না রোলিং 30-দিনের রিপোর্টের সংখ্যা সেই {সোর্স সাইটের জন্য 100-এর নিচে নেমে আসে। , গন্তব্য, রিপোর্টিং মূল}।

প্রযুক্তিগত ব্যাখ্যাকারীতে আরও জানুন

কুলডাউন / হার সীমা প্রতিবেদন করা

গন্তব্য ক্যাপিং (শুধুমাত্র ইভেন্ট-স্তরের রিপোর্ট)

কি পরিবর্তন হচ্ছে, এবং কেন?

ডেস্টিনেশন ক্যাপিং পরিবর্তিত হয়েছে রিপোর্টিং মূল (সাধারণত, একটি অ্যাডটেক) স্কোপের মধ্যে অন্তর্ভুক্ত করার জন্য: 100টি অনন্য মুলতুবি গন্তব্য (সাধারণত, বিজ্ঞাপনদাতা সাইট বা সাইট যেখানে রূপান্তর ঘটতে পারে) প্রতি {publisher, adtech}-এর অনুমতি দেওয়া হয়।

এটি ব্রাউজিং ইতিহাস পুনর্গঠন সীমিত করার জন্য একটি গোপনীয়তা সুরক্ষা ।

প্রযুক্তিগত ব্যাখ্যাকারীতে আরও জানুন

মুলতুবি উৎস দ্বারা আচ্ছাদিত অনন্য গন্তব্যের সংখ্যা সীমিত করা

সমস্ত সম্পদ

শিরোনাম চিত্রটি আনস্প্ল্যাশে ডায়ানা পোলেখিনার ।