কুকি ম্যাচিং

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

মূল পয়েন্ট: কুকি ম্যাচিং বৈশিষ্ট্যগুলি অ্যাক্সেস করার জন্য, আপনার অ্যাকাউন্ট কনফিগার করার জন্য আপনাকে অবশ্যই আপনার অ্যাকাউন্ট ম্যানেজারের সাথে যোগাযোগ করতে হবে৷ এই গাইডের অবশিষ্টাংশ অনুমান করে যে এটি ইতিমধ্যেই করা হয়েছে।

ধারণা

কুকি ম্যাচিং কি?

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

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

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

টেবিল মেলে

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

Google-হোস্ট করা ম্যাচ টেবিল

সহজ রক্ষণাবেক্ষণ, লেটেন্সি উন্নতি, এবং নির্দিষ্ট অঞ্চলের ব্যবহারকারীদের জন্য ম্যাচ ডেটা অ্যাক্সেসের জন্য, এটি সুপারিশ করা হয় যে আপনি Google-কে আপনার ম্যাচ টেবিল হোস্ট করার অনুমতি দিন। এটি আপনাকে একটি ওয়েব-নিরাপদ বেস 64-এনকোডেড স্ট্রিং নির্দিষ্ট করতে দেয় — এরপরে হোস্ট করা ম্যাচ ডেটা হিসাবে উল্লেখ করা হয়—যা একটি প্রদত্ত ব্যবহারকারীর জন্য Google ব্যবহারকারী আইডিতে ম্যাপ করা হবে। একবার একটি মিল প্রতিষ্ঠিত হলে, এটি নিম্নলিখিত উপায়ে ব্যবহার করা যেতে পারে:

• রিয়েল-টাইম বিডিং : ব্যবহারকারীর সাথে যুক্ত ইম্প্রেশনের জন্য পরবর্তী বিড অনুরোধে, Google আপনাকে তাদের Google ব্যবহারকারী আইডির সাথে মেলে থাকা হোস্ট করা ম্যাচ ডেটা পাঠাবে। Google BidRequest.user.buyeruid একটি ওয়েব-নিরাপদ বেস64-এনকোডেড স্ট্রিং হিসেবে নির্দিষ্ট করবে।

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

• ব্যবহারকারীর তালিকা : ব্যবহারকারীর তালিকাগুলি হয় Google ব্যবহারকারী আইডি বা হোস্ট করা ম্যাচ ডেটা দিয়ে তৈরি করা যেতে পারে।

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

ব্যবহারকারীর তালিকা

রিয়েল-টাইম বিডিং এপিআই দিয়ে ব্যবহারকারীর তালিকা তৈরি ও পরিচালনা করা যেতে পারে। একবার তৈরি হয়ে গেলে, আপনি নিম্নলিখিত কুকি ম্যাচিং ওয়ার্কফ্লো বা বাল্ক আপলোডার পরিষেবার মাধ্যমে এই তালিকাগুলি পূরণ করতে পারেন।

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

শুরু করা

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

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

দ্রষ্টব্য: অনুমোদিত ক্রেতারা বিডার্স রিসোর্সের সাথে তাদের অ্যাকাউন্টের জন্য কনফিগার করা কুকি ম্যাচিং NID এবং URL দেখতে পারেন।

কুকি ম্যাচিং ম্যাক্রো

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

সমর্থিত ম্যাক্রো

দরদাতারা ঐচ্ছিকভাবে %%GOOGLE_<PARAM_NAME>%% বা %%GOOGLE_<PARAM_NAME>_PAIR%% আকারে এক বা একাধিক ম্যাক্রো অন্তর্ভুক্ত করতে তাদের কুকি ম্যাচিং URL কনফিগার করতে পারেন। সমর্থিত ম্যাক্রো এবং তাদের প্রসারিত মান হল:

ম্যাক্রো	প্রসারিত মান
GOOGLE_GID	GOOGLE_USER_ID
GOOGLE_GID_PAIR	&google_gid= GOOGLE_USER_ID
GOOGLE_CVER	COOKIE_VERSION_NUMBER
GOOGLE_CVER_PAIR	&cver= COOKIE_VERSION_NUMBER
GOOGLE_ERROR	ERROR_ID
GOOGLE_ERROR_PAIR	&google_error= ERROR_ID
GOOGLE_PUSH	PIXEL_MATCH_DATA
GOOGLE_PUSH_PAIR	&google_push= PIXEL_MATCH_DATA
GOOGLE_ALL_PARAMS	google_gid= GOOGLE_USER_ID &cver= COOKIE_VERSION_NUMBER &google_error= ERROR_ID

ম্যাক্রো উদাহরণ

একজন বিডারের https://user.bidder.com/cookies এ হোস্ট করা একটি এন্ডপয়েন্টের সাথে কুকি ম্যাচিং ইন্টিগ্রেশন রয়েছে এবং তাদের বাস্তবায়নের জন্য নিম্নোক্ত ক্রমে পিক্সেল ম্যাচিং প্যারামিটার ছাড়াও প্রিসেট বিডার-সংজ্ঞায়িত প্যারামিটার প্রয়োজন: google_push , google_gid , google_cver , এবং google_error দরদাতা তাদের কুকি ম্যাচিং URL এতে সেট করে এটি সম্পন্ন করতে পারে:

https://user.bidder.com/cookies?w=0%%GOOGLE_PUSH_PAIR%%&x=1%%GOOGLE_GID_PAIR%%&y=2%%GOOGLE_CVER_PAIR%%&z=3%%GOOGLE_ERROR_PAIR%%

যখন Google পরে এই দরদাতার কাছে একটি ম্যাচের অনুরোধ পাঠায়, তখন এটি নিম্নলিখিতগুলির মতো কিছুতে প্রসারিত হবে:

https://user.bidder.com/cookies?w=0&google_push=PUSH_DATA&x=1&google_gid=GOOGLE_GID&y=2&google_cver=1&z=3

দ্রষ্টব্য: google_error প্যারামিটারটি পিক্সেল ম্যাচিং ওয়ার্কফ্লো-এর জন্য Google-এর ম্যাচ ট্যাগে পপুলেট করা হয় না এবং তাই বাদ দেওয়া হয়।

কুকি ম্যাচিং সার্ভিস ওয়ার্কফ্লো

Google-এর কুকি ম্যাচিং পরিষেবা নিম্নলিখিত তিনটি কার্যপ্রবাহ সমর্থন করে৷

দরদাতা-সূচিত: দ্বিমুখী কুকি ম্যাচিং

দ্বিমুখী কুকি ম্যাচিং একটি দরদাতা-সূচিত কর্মপ্রবাহকে বোঝায়, যেখানে তারা ব্যবহারকারীর ব্রাউজারে একটি ম্যাচ ট্যাগ রাখে যা এটিকে Google-এ নির্দেশ করে। এই ওয়ার্কফ্লোটি Google এবং দরদাতা উভয়কেই মিল টেবিল তৈরি করতে দেয়। নিম্নলিখিত এই কর্মপ্রবাহ একটি উদাহরণ.

ধাপ 1: ম্যাচ ট্যাগ রাখুন

এই প্রবাহ শুরু করার জন্য, দরদাতাকে অবশ্যই তাদের ম্যাচ ট্যাগটি এমনভাবে স্থাপন করতে হবে যাতে এটি ব্যবহারকারীর ব্রাউজারে রেন্ডার হয়। একটি ম্যাচ ট্যাগ যেটি শুধুমাত্র বিডারকে Google User ID ফেরত দেয় তা নিম্নরূপ গঠন করা যেতে পারে:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm" />

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

বিভিন্ন ব্যবহারের ক্ষেত্রে আপনি ম্যাচ ট্যাগে অন্তর্ভুক্ত করতে পারেন এমন অতিরিক্ত প্যারামিটার রয়েছে। এই প্যারামিটারগুলি সম্পর্কে আরও জানতে, ম্যাচ ট্যাগ URL প্যারামিটার দেখুন।

ধাপ 2: Google ম্যাচ ডেটা সহ রিডাইরেক্টের সাথে প্রতিক্রিয়া জানায়

ম্যাচ ট্যাগের কারণে Google-এর কুকি ম্যাচিং পরিষেবা ব্যবহারকারীর ব্রাউজার থেকে একটি অনুরোধ পাবে, যা দরদাতার কুকি ম্যাচিং URL-এ একটি HTTP 302 পুনঃনির্দেশ ইস্যু করবে। পুনঃনির্দেশের মধ্যে URL-এ Google ব্যবহারকারী আইডি এবং এর সংস্করণ নম্বর উল্লেখ করে ক্যোয়ারী প্যারামিটার অন্তর্ভুক্ত থাকবে এবং দরদাতা অনুরোধ শিরোনামে অন্তর্ভুক্ত তাদের কুকিও পাবেন। অনুশীলনে, https://ad.network.com/pixel হিসাবে নির্দিষ্ট করা একটি কুকি ম্যাচিং ইউআরএলের জন্য, পূর্ববর্তী ম্যাচ ট্যাগের জন্য রিডাইরেক্ট ইউআরএল নিচের মত দেখতে পারে:

https://ad.network.com/pixel?google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1

google_gid প্যারামিটারের মধ্য দিয়ে পাস করা Google User ID হল একটি আনপ্যাড করা ওয়েব-সেফ বেস64-এনকোডেড স্ট্রিং। একটি ম্যাচ টেবিল হোস্ট করতে বেছে নেওয়া দরদাতাদের জন্য, এটি সুপারিশ করা হয় যে তারা কুকি ম্যাচিং পরিষেবা দ্বারা ফেরত দেওয়া সঠিক স্ট্রিংটি সংরক্ষণ করুন৷ পরবর্তী বিড অনুরোধে, এটি BidRequest.user.id এর মাধ্যমে নির্দিষ্ট করা মানগুলির সাথে মিলে যাবে।

google_cver এ উল্লিখিত সংস্করণটি Google ব্যবহারকারী আইডির সংখ্যাসূচক সংস্করণ নম্বর নির্দেশ করে। একটি প্রদত্ত ব্যবহারকারীর জন্য Google ব্যবহারকারী আইডি কদাচিৎ পরিবর্তিত হবে, তারপরে এটি বৃদ্ধি করা হবে।

আপনার ম্যাচের অনুরোধ প্রক্রিয়া করার সময় যদি Google কোনো ত্রুটির সম্মুখীন হয়, তাহলে পরিবর্তে একটি google_error প্যারামিটার নির্দিষ্ট করা হবে।

ধাপ 3: বিডার প্রসেস রিডাইরেক্ট করে এবং পিক্সেল দিয়ে সাড়া দেয়

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

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

দরদাতাকে সর্বদা একটি 1x1 অদৃশ্য পিক্সেল চিত্র পরিবেশন করে প্রতিক্রিয়া জানাতে হবে, অথবা বিকল্পভাবে একটি HTTP 204 নো কন্টেন্ট প্রতিক্রিয়া প্রদান করতে হবে।

কুকি ম্যাচিং ওয়ার্কফ্লো ডায়াগ্রাম

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

ট্যাগ ইউআরএল পরামিতি মেলে

প্যারামিটার	বর্ণনা
google_nid	বিডার অ্যাকাউন্টের জন্য নেটওয়ার্ক আইডি (NID)। এই আইডিটি বিডার্স রিসোর্সের মাধ্যমে পুনরুদ্ধার করা যেতে পারে।
google_cm	Google-এর কুকি ম্যাচিং পরিষেবাকে নির্দেশ করে যে এটি কুকি ম্যাচিং করা উচিত। প্যারামিটারের মান উপেক্ষা করা হয় এবং বাদ দেওয়া হতে পারে।
google_sc	এই প্যারামিটারটি অবহেলিত। ব্যবহারকারীর জন্য Google এর কুকি সেট করে যদি কেউ উপস্থিত না থাকে। প্যারামিটারের মান উপেক্ষা করা হয় এবং বাদ দেওয়া হতে পারে। কোনো কুকি বিদ্যমান না থাকলে প্যারামিটারটি বাদ দিলে একটি ত্রুটি দেখা দেয়।
google_no_sc	এই প্যারামিটারটি অবহেলিত। এটি Google-এর কুকি ম্যাচিং পরিষেবাকে নির্দেশ করে যে এটি ব্যবহারকারীর জন্য একটি কুকি সেট করা উচিত নয় যদি একটি উপস্থিত না থাকে৷ প্যারামিটারের মান উপেক্ষা করা হয় এবং বাদ দেওয়া হতে পারে।
google_hm	তথ্য দরদাতা একটি Google-হোস্ট করা ম্যাচ টেবিলে সংরক্ষণ করতে চান. মানটি একটি ওয়েব-নিরাপদ বেস64-এনকোডেড স্ট্রিং (প্যাডিং ঐচ্ছিক)। কাঁচা ডেটা অবশ্যই 40 বাইট বা তার কম হতে হবে। উদাহরণস্বরূপ, Q29va2llIHRoYXQgaXMgdW5kZXIgNDAgdG90YWwgYnl0ZXMuLi4u ।
google_redir	একটি ইউআরএল-এনকোড করা স্ট্রিং যা একজন দরদাতা যদি Google-কে এই ম্যাচ ট্যাগের জন্য এনকোড করা ইউআরএলে HTTP 302 রিডাইরেক্ট পাঠাতে নির্দেশ দিতে চান তাহলে নির্দিষ্ট করতে পারেন। এটি অংশীদারদের কাছে একটি শৃঙ্খলিত কলে Google কে সামনের দিকে রাখার অনুমতি দেয়৷ google_hm ছাড়া বা google_cm দিয়ে নির্দিষ্ট করা হলে এর ফলে একটি ত্রুটি দেখা দেবে।
google_ula	একটি বিদ্যমান ব্যবহারকারী তালিকায় ব্যবহারকারীকে যুক্ত করতে ব্যবহৃত একটি স্ট্রিং। মানটির প্রত্যাশিত বিন্যাস হল userlistid[,timestamp] : userlistid : একটি একক সংখ্যাসূচক ব্যবহারকারী তালিকা আইডি। timestamp : POSIX ফরম্যাটে একটি ঐচ্ছিক টাইমস্ট্যাম্প, ব্যবহারকারীকে কখন ব্যবহারকারী তালিকায় যুক্ত করা হয়েছে তা নির্দেশ করে। ব্যবহারকারীকে একাধিক তালিকায় যুক্ত করতে এই URL প্যারামিটারটি পুনরাবৃত্তি করা হতে পারে।
gdpr	নির্দেশ করে যে অনুরোধটি ডেটা ব্যবহারের উপর জিডিপিআর বিধিনিষেধ সাপেক্ষে। আরও বিস্তারিত জানার জন্য, EU ব্যবহারকারীর সম্মতির প্রয়োজনীয়তা বা অনুমোদিত ক্রেতাদের IAB TCF v2.0 ডকুমেন্টেশনে কুকি ম্যাচের যোগ্যতার উপর প্রভাব দেখুন। উদাহরণ: gdpr=1
gdpr_consent	একটি TC স্ট্রিং যা শেষ-ব্যবহারকারীর সম্মতির প্রতিনিধিত্ব করে। আরো বিস্তারিত জানার জন্য, EU ব্যবহারকারীর সম্মতির প্রয়োজনীয়তা দেখুন বা TC স্ট্রিং কীভাবে পাস করা হবে? অনুমোদিত ক্রেতাদের IAB TCF v2.0 ডকুমেন্টেশনে ।
process_consent	নির্দেশ করে যে বিডার Google এর EU ব্যবহারকারীর সম্মতি নীতিতে নির্দিষ্ট করা ডেটা ব্যবহারের জন্য শেষ-ব্যবহারকারীর সম্মতি পেয়েছে। যদি অনুরোধটি EU ব্যবহারকারীর সম্মতি নীতির অধীন না হয়, বা অনুরোধে ( gdpr_consent ) অন্যান্য সম্মতি পরামিতি উপলব্ধ থাকলে, এই প্যারামিটারটি উপেক্ষা করা হয়। উদাহরণ: process_consent=T

পূর্ববর্তী পরামিতিগুলি ছাড়াও, দরদাতারা তাদের নিজস্ব নির্দিষ্ট করতে পারে, যা পুনঃনির্দেশ URL-এ পরামিতি হিসাবে যুক্ত করা হবে। মনে রাখবেন যে google_ উপসর্গের সাথে নাম দেওয়া বিডার-সংজ্ঞায়িত প্যারামিটারগুলি উপেক্ষা করা হবে কারণ সেগুলি ভবিষ্যতের বিকাশের জন্য Google দ্বারা সংরক্ষিত, এবং পরামিতিগুলির ক্রম সংরক্ষণের নিশ্চয়তা নেই৷ দরদাতা-নির্ধারিত পরামিতি সহ একটি ম্যাচ ট্যাগ দেখতে এইরকম হতে পারে:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm&extra1=xx&extra2=yy" />

URL প্যারামিটার পুনঃনির্দেশ করুন

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

প্যারামিটার	বর্ণনা
google_gid	গুগল ইউজার আইডি। অনুরোধে google_cm নির্দিষ্ট করা আছে কিনা এবং অনুরোধ সফল হয়েছে কিনা তা সেট করুন।
google_cver	কুকি সংস্করণ। অনুরোধে google_cm নির্দিষ্ট করা আছে কিনা এবং অনুরোধ সফল হয়েছে কিনা তা সেট করুন।
google_error	সামগ্রিক অনুরোধ ত্রুটি নির্দেশ করে একটি পূর্ণসংখ্যা মান। প্রাপ্ত হলে, এটি নির্দেশ করে যে কোনও অপারেশন করা হয়নি, এবং অন্য কোনও google_ প্রতিক্রিয়া পরামিতি সেট করা হবে না। সমর্থিত ত্রুটি মান নিম্নলিখিত অন্তর্ভুক্ত: 1 : ব্যবহারকারীর একটি Google কুকি আছে, কিন্তু এই কুকি ব্যবহার করে যেকোনো ট্র্যাকিং থেকে অপ্ট আউট করেছে৷ 2 : কোন বৈধ অপারেশন নির্দিষ্ট করা নেই. উদাহরণস্বরূপ, একটি নো-অপ অনুরোধ গৃহীত হয়েছিল। 3 : ব্যবহারকারীর কাছে Google কুকি নেই৷ Google কুকি ম্যাচিং পরিষেবার মাধ্যমে কুকি সেট করবে না৷ 4 : বিরোধপূর্ণ অপারেশন নির্দিষ্ট করা হয়েছে। আপনি একই অনুরোধে google_push এবং google_cm উভয় পতাকা নির্দিষ্ট করতে পারবেন না যেহেতু তাদের বিরোধপূর্ণ উদ্দেশ্য রয়েছে৷ 5 : একটি দ্বিমুখী পিক্সেল ম্যাচিং অনুরোধের অংশ হিসাবে একটি Google সার্ভারে একটি রিডাইরেক্টে একটি অবৈধ google_push প্যারামিটার পাস করা হয়েছিল৷ আপনার রিডাইরেক্টকে অবশ্যই google_push সেট করতে হবে একই মান যা আপনাকে প্রাথমিক পিক্সেল অনুরোধে পাঠানো হয়েছে। 6 : ম্যাচ ট্যাগে একটি অবৈধ NID সরবরাহ করা হয়েছে। 7 : একটি অবৈধ কুকি সনাক্ত করা হয়েছে৷ 8 : অবচয়। কোন কুকি পাওয়া যায়নি. 9 : কোন কুকি পাওয়া যায়নি, একটি পরীক্ষা কুকি সেট করার চেষ্টা করা হয়েছে। 10 : google_redir প্যারামিটারটি google_hm নির্দিষ্ট না করে ব্যবহার করা হয়েছিল, বা google_cm এর সাথে ব্যবহার করা হয়েছিল। 15 : অনুরোধটি এমন একটি অঞ্চল থেকে এসেছে যেখানে Google-এর দ্বারা হোস্ট করা ম্যাচ টেবিলের প্রয়োজন। ফলস্বরূপ, এই প্রতিক্রিয়াতে একটি Google ব্যবহারকারী আইডি নেই।
google_hm	শুধুমাত্র Google-হোস্ট করা ম্যাচ টেবিলে লেখার প্রচেষ্টা ব্যর্থ হলেই প্রদর্শিত হবে। যখন এটি ঘটে, তখন এর মান হল নিম্নলিখিত স্ট্যাটাস কোডগুলির মধ্যে একটি: 1 - নিষিদ্ধ: হোস্ট করা ম্যাচ টেবিল এন্ট্রি লিখতে গ্রাহকের অ্যাক্সেস নেই। 2 - ডিকোড ত্রুটি: প্যারামিটার মান ডিকোড করা যায়নি। 3 - পেলোড খুব দীর্ঘ: প্যারামিটার মান 40 বাইটের বেশি ডেটাতে ডিকোড করা হয়েছে৷ 4 - অভ্যন্তরীণ ত্রুটি: ডেটা সংরক্ষণ করার সময় একটি অভ্যন্তরীণ ত্রুটি ছিল৷ 5 - থ্রটলড: থ্রটলিং এর কারণে এই লেখাটি প্রক্রিয়া করা হয়নি।
google_ula	ব্যবহারকারীর তালিকা যুক্ত অপারেশনের স্থিতি, অনুরোধে একাধিক google_ula নির্দিষ্ট করা থাকলে পুনরাবৃত্তি করা হয়। বিন্যাস হল: userlistid,status code যেমন: google_ula=1234567890,0 google_ula অপারেশন নিম্নলিখিত স্ট্যাটাস কোডগুলির যেকোনো একটি ফিরিয়ে দিতে পারে: 0 - কোন ত্রুটি নেই। ব্যবহারকারীকে ব্যবহারকারীর তালিকায় যুক্ত করা হয়েছে। 2 - অনুমতি অস্বীকার করা হয়েছে। প্রদত্ত ব্যবহারকারী তালিকায় ব্যবহারকারীদের যুক্ত করার অনুমতি আপনার নেই। 5 - খারাপ ব্যবহারকারী তালিকা আইডি। সরবরাহকৃত ব্যবহারকারী তালিকা আইডি অবৈধ। 6 - ক্লোজড অ্যাট্রিবিউট আইডি। সরবরাহকৃত ব্যবহারকারী তালিকা আইডি বন্ধ করা হয়েছে। 10 - অভ্যন্তরীণ ত্রুটি। কুকি ম্যাচিং পরিষেবা একটি অভ্যন্তরীণ ত্রুটির সম্মুখীন হয়েছে; আপনি আবার ব্যবহারকারীর সাথে পুনরায় মিলানোর চেষ্টা করতে পারেন।

কুকি ম্যাচিং ওয়ার্কফ্লো উদাহরণ দৃশ্যকল্প

একটি ওয়েব পৃষ্ঠা ব্রাউজ করা সাধারণ ব্যবহারকারীর জন্য কুকি ম্যাচিং কেমন হতে পারে তা নিম্নলিখিত পরিস্থিতিতে বর্ণনা করে।

দৃশ্য 1: ব্যবহারকারী তাদের কুকিজ সাফ করে এবং একটি সাইট ব্রাউজ করে

জেন তাদের সমস্ত কুকির ক্যাশে সাফ করে। তারপর তারা ExampleNews.com-এর হোমপেজে যান।

এখানে যা ঘটে:

1. ExampleNews.com রেন্ডার করে এবং Google (বিজ্ঞাপন ম্যানেজার) থেকে বিজ্ঞাপন কল করে।
2. যেহেতু বিজ্ঞাপন ইউনিটটি গতিশীল বরাদ্দের জন্য যোগ্য, Google রিয়েল-টাইম বিডিং পরিষেবার মাধ্যমে FinestDSP এবং অন্যান্য বিডারদের কাছে বিডের অনুরোধ পাঠায়।
3. FinestDSP-এর দরদাতার আবেদন দরপত্রের অনুরোধ গ্রহণ করে এবং প্রক্রিয়া করে এবং তার বিড প্রতিক্রিয়া পাঠায়।
4. Google দরদাতাদের কাছ থেকে বিড প্রতিক্রিয়া পায়, যার মধ্যে FinestDSP-এর প্রতিক্রিয়া যা একটি ম্যাচ ট্যাগ (পিক্সেল) সহ একটি বিজ্ঞাপন নির্দিষ্ট করে।
5. FinestDSP নিলাম জিতেছে। Google জেনকে FinestDSP-এর বিজ্ঞাপন এবং ম্যাচ ট্যাগ পরিবেশন করে।
6. ম্যাচ ট্যাগটি Google-এর কুকি ম্যাচ পরিষেবাকে কল করে, google_nid এবং google_cm প্যারামিটারগুলি নির্দিষ্ট করে৷
7. কুকি ম্যাচ সার্ভিস জেনের Google কুকি পড়ে, এবং জেনের ব্রাউজারকে google_gid এবং google_cver প্যারামিটার সেট সহ FinestDSP-এর কুকি ম্যাচিং URL-এ একটি পুনঃনির্দেশ পাঠায়।
8. জেনের ব্রাউজার FinestDSP-এর কুকি ম্যাচ URL-এ পুনঃনির্দেশ লোড করে।
9. FinestDSP-এর কুকি ম্যাচিং এন্ডপয়েন্ট রিডাইরেক্ট রিকোয়েস্টকে প্রসেস করে, যার মধ্যে Google দ্বারা সেট করা URL প্যারামিটার এবং HTTP হেডারে জেনের জন্য তাদের কুকি অন্তর্ভুক্ত থাকে। FinestDSP এখন তাদের কুকির ম্যাপিং তাদের ম্যাচ টেবিলে google_gid এ সঞ্চয় করতে পারে।
10. FinestDSP একটি অদৃশ্য 1x1 পিক্সেলের সাথে পুনঃনির্দেশে সাড়া দেয়।

দৃশ্যকল্প 2: বিদ্যমান ম্যাপিং সহ ব্যবহারকারী

দৃশ্য 1 এর এক সপ্তাহ পরে, জেন আবার ExampleNews.com-এ যান। এখন যেহেতু জেনের মেশিনে বিডার এবং অ্যাড ম্যানেজার কুকি উভয়ই আছে, এখানে মিল কীভাবে কাজ করে।

1. ওয়েব পৃষ্ঠাটি রেন্ডার করে, যার ফলে Google (বিজ্ঞাপন ম্যানেজার) পৃষ্ঠায় রেন্ডার করা বিজ্ঞাপনগুলির জন্য অনুরোধ করে৷
2. বিজ্ঞাপন নিলামের সময়, Google FinestDSP সহ প্রযোজ্য দরদাতাদের কাছে একটি বিড অনুরোধ পাঠায়।
3. FinestDSP google_gid এর মতো সংকেত সহ বিড অনুরোধ গ্রহণ করে।
4. FinestDSP তার ম্যাচ টেবিলে google_gid খোঁজে, এবং জেনের সাথে যুক্ত কুকি খুঁজে পায় যা এক সপ্তাহ আগে তৈরি করা হয়েছিল (দৃশ্য 1-এ)।
5. কুকির সাথে যুক্ত তথ্যের উপর ভিত্তি করে, FinestDSP-এর বিডিং লজিক ইম্প্রেশনে একটি বিড রাখে এবং নিলামে জয়লাভ করে।
6. FinestDSP-এর কাছে থাকা তথ্যের ভিত্তিতে জেন তাদের আগ্রহের জন্য তৈরি করা একটি বিজ্ঞাপন দেখতে পারে।

দরদাতা-সূচনা: একমুখী কুকি ম্যাচিং

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

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

ধাপ 1: দরদাতার কুকি ম্যাচিং URL-এ নির্দেশিত ম্যাচ ট্যাগটি রাখুন

এই প্রবাহ শুরু করার জন্য, একজন দরদাতাকে অবশ্যই একটি ম্যাচ ট্যাগ রাখতে হবে যাতে এটি ব্যবহারকারীর ব্রাউজারে রেন্ডার হয়। গোপনীয়তা বিধিনিষেধ সহ মার্কিন যুক্তরাষ্ট্রের নয় এমন ব্যবহারকারীদের জন্য কর্মপ্রবাহের বিপরীতে, ম্যাচ ট্যাগ অবশ্যই ব্যবহারকারীর ব্রাউজারকে আপনার কুকি ম্যাচিং URL-এ নির্দেশ করবে৷ উদাহরণ স্বরূপ, https://ad.network.com/pixel হিসাবে কনফিগার করা কুকি ম্যাচিং URL এর সাথে এটি দেখতে এরকম হবে:

<img src="https://ad.network.com/pixel" />

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

ধাপ 2: Google এর কুকি ম্যাচিং পরিষেবাতে পুনঃনির্দেশ করুন৷

দরদাতার কুকি ম্যাচিং এন্ডপয়েন্টকে অবশ্যই Google-এর কুকি ম্যাচিং পরিষেবাতে পুনঃনির্দেশিত করতে হবে, যার মধ্যে google_hm প্যারামিটারটি তাদের ওয়েব-নিরাপদ বেস64-এনকোডেড কুকি ডেটা দিয়ে তৈরি করা হয়েছে। পুনঃনির্দেশ URL নিম্নলিখিত মত দেখতে হতে পারে:

https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_hm=HOSTED_MATCH_DATA

ধাপ 3: ব্যবহারকারীর ব্রাউজারটি Google-এর কুকি ম্যাচিং পরিষেবাতে পুনঃনির্দেশিত হয়

HTTP শিরোনামে Google-এর কুকি ছাড়াও Google আপনার নির্দিষ্ট করা প্যারামিটার সমেত একটি পুনঃনির্দেশ পাবে।

ধাপ 4: রিপোর্ট URL নির্দিষ্ট করা থাকলে Google সফলতা বা ত্রুটি পুনঃনির্দেশে পিক্সেল পরিবেশন করে

যদি কুকি ম্যাচিং অপারেশন সফল হয়—অথবা যদি বিডারের অ্যাকাউন্টের জন্য কোনো কুকি ম্যাচিং রিপোর্ট URL নির্দিষ্ট করা না থাকে—Google ডিফল্টরূপে 1x1 স্বচ্ছ পিক্সেল পরিবেশন করবে, এবং কর্মপ্রবাহ এখানেই শেষ হবে। পরবর্তী বিড অনুরোধে এই ব্যবহারকারীর জন্য ইম্প্রেশন BidRequest.user.buyeruid এ দরদাতার হোস্ট করা ম্যাচ ডেটা অন্তর্ভুক্ত করবে। দরদাতারা তাদের নির্দিষ্ট করা হোস্ট করা ম্যাচ ডেটা ব্যবহার করে ব্যবহারকারীর তালিকা তৈরি করতে পারে।

অন্যথায়, যদি একটি ত্রুটি ঘটে থাকে, Google google_error প্যারামিটারে নির্দিষ্ট ত্রুটির কারণ সহ দরদাতার কুকি ম্যাচিং রিপোর্ট URL-এ একটি পুনঃনির্দেশ পাঠাবে৷ যদি দরদাতার কুকি ম্যাচিং রিপোর্ট URLটি https://ad.network.com/report হয়, তাহলে পুনঃনির্দেশ URLটি এরকম দেখাবে:

<img src="https://ad.network.com/report?google_error=ERROR_ID" />

দ্রষ্টব্য: দরদাতারা অনুরোধ করতে পারেন যে তাদের অ্যাকাউন্ট সর্বদা তাদের কুকি ম্যাচিং রিপোর্ট URL-এ পুনঃনির্দেশ পায়, এমনকি সফল অপারেশনের জন্যও। এটি সক্ষম করতে, তারা তাদের প্রযুক্তিগত অ্যাকাউন্ট ম্যানেজারের সাথে যোগাযোগ করতে পারে।

ধাপ 5: ব্যবহারকারীর ব্রাউজার বিডারের কুকি ম্যাচিং রিপোর্ট URL-এ পুনঃনির্দেশ করে

ব্যবহারকারীর ব্রাউজার google_error প্যারামিটারে Google দ্বারা নির্দিষ্ট করা ত্রুটির কারণ (যদি থাকে) সহ দরদাতার কুকি ম্যাচিং রিপোর্ট URL-এ পুনঃনির্দেশিত করবে। ত্রুটি কোড ব্যাখ্যা সম্পর্কে আরও জানতে, প্যারামিটার বিবরণ দেখুন।

দ্রষ্টব্য : এই পদক্ষেপটি তখনই ঘটবে যখন বিডারের অ্যাকাউন্টটি একটি কুকি ম্যাচিং রিপোর্ট URL-এ অপারেশনের ব্যর্থতা বা সাফল্য সম্পর্কে তথ্য পাঠাতে কনফিগার করা হয়।

ধাপ 6: দরদাতা 1x1 স্বচ্ছ পিক্সেল পরিবেশন করে

দরদাতাকে অবশ্যই ব্যবহারকারীর ব্রাউজারে 1x1 স্বচ্ছ পিক্সেল পরিবেশন করে প্রতিক্রিয়া জানাতে হবে।

দ্রষ্টব্য : এই পদক্ষেপটি তখনই ঘটবে যখন বিডারের অ্যাকাউন্টটি একটি কুকি ম্যাচিং রিপোর্ট URL-এ অপারেশনের ব্যর্থতা বা সাফল্য সম্পর্কে তথ্য পাঠাতে কনফিগার করা হয়।

গোপনীয়তা বিধিনিষেধ সহ মার্কিন যুক্তরাষ্ট্রের ব্যবহারকারীদের জন্য কুকি ম্যাচিং ওয়ার্কফ্লো ডায়াগ্রাম

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

Google-এর কুকি ম্যাচিং পরিষেবাতে দরদাতার জন্য URL প্যারামিটার পুনঃনির্দেশ

প্যারামিটার	বর্ণনা
google_nid	বিডার অ্যাকাউন্টের জন্য নেটওয়ার্ক আইডি (NID)। এই আইডিটি বিডার্স রিসোর্সের মাধ্যমে পুনরুদ্ধার করা যেতে পারে।
google_sc	এই প্যারামিটারটি অবহেলিত। ব্যবহারকারীর জন্য Google এর কুকি সেট করে যদি কেউ উপস্থিত না থাকে। প্যারামিটারের মান উপেক্ষা করা হয় এবং বাদ দেওয়া হতে পারে। কোনো কুকি বিদ্যমান না থাকলে প্যারামিটারটি বাদ দিলে একটি ত্রুটি দেখা দেয়।
google_no_sc	এই প্যারামিটারটি অবহেলিত। এটি Google-এর কুকি ম্যাচিং পরিষেবাকে নির্দেশ করে যে এটি ব্যবহারকারীর জন্য একটি কুকি সেট করা উচিত নয় যদি একটি উপস্থিত না থাকে৷ প্যারামিটারের মান উপেক্ষা করা হয় এবং বাদ দেওয়া হতে পারে।
google_hm	দরদাতা একটি Google-হোস্ট করা ম্যাচ টেবিলে সঞ্চয় করতে চায় এমন ডেটা রয়েছে৷ দ্রষ্টব্য: মানটি একটি ওয়েব-নিরাপদ বেস64-এনকোডেড স্ট্রিং (প্যাডিং ঐচ্ছিক) যা 40 বাইটের বেশি হওয়া উচিত নয়। উদাহরণস্বরূপ, এটির মত দেখতে হতে পারে: Q29va2llIG51bWJlciAxIQ== ।
google_redir	একটি এনকোড করা URL যা আপনি Google কে একটি HTTP 302 পুনঃনির্দেশ পাঠাতে চান৷ নির্দিষ্ট URL ত্রুটি এবং সফল অপারেশন উভয়ের জন্য google_error প্যারামিটার সহ পুনঃনির্দেশ পাবে।
google_ula	একটি বিদ্যমান ব্যবহারকারী তালিকায় ব্যবহারকারীকে যুক্ত করতে ব্যবহৃত একটি স্ট্রিং। মানটির প্রত্যাশিত বিন্যাস হল userlistid[,timestamp] : userlistid : একটি একক সংখ্যাসূচক ব্যবহারকারী তালিকা আইডি। timestamp : POSIX ফরম্যাটে একটি ঐচ্ছিক টাইমস্ট্যাম্প, ব্যবহারকারীকে কখন ব্যবহারকারী তালিকায় যুক্ত করা হয়েছে তা নির্দেশ করে। ব্যবহারকারীকে একাধিক তালিকায় যুক্ত করতে এই URL প্যারামিটারটি পুনরাবৃত্তি করা হতে পারে।
gdpr	নির্দেশ করে যে অনুরোধটি ডেটা ব্যবহারের উপর জিডিপিআর বিধিনিষেধ সাপেক্ষে। আরও বিস্তারিত জানার জন্য, EU ব্যবহারকারীর সম্মতির প্রয়োজনীয়তা বা অনুমোদিত ক্রেতা IAB TCF v2.0 ডকুমেন্টেশনে কুকি ম্যাচের যোগ্যতার উপর প্রভাব দেখুন। উদাহরণ: gdpr=1
gdpr_consent	একটি TC স্ট্রিং যা শেষ-ব্যবহারকারীর সম্মতির প্রতিনিধিত্ব করে। আরো বিস্তারিত জানার জন্য, EU ব্যবহারকারীর সম্মতির প্রয়োজনীয়তা দেখুন বা TC স্ট্রিং কীভাবে পাস করা হবে? অনুমোদিত ক্রেতাদের IAB TCF v2.0 ডকুমেন্টেশনে ।
process_consent	নির্দেশ করে যে বিডার Google এর EU ব্যবহারকারীর সম্মতি নীতিতে নির্দিষ্ট করা ডেটা ব্যবহারের জন্য শেষ-ব্যবহারকারীর সম্মতি পেয়েছে। যদি অনুরোধটি EU ব্যবহারকারীর সম্মতি নীতির অধীন না হয়, বা অনুরোধে ( gdpr_consent ) অন্যান্য সম্মতি পরামিতি উপলব্ধ থাকলে, এই প্যারামিটারটি উপেক্ষা করা হয়। উদাহরণ: process_consent=T

Google-এর URL প্যারামিটারগুলি বিডারের কুকি ম্যাচিং রিপোর্ট URL-এ পুনঃনির্দেশ করে৷

প্যারামিটার

বর্ণনা

google_error

সামগ্রিক অনুরোধ ত্রুটি নির্দেশ করে একটি পূর্ণসংখ্যা মান। প্রাপ্ত হলে, এটি নির্দেশ করে যে কোনও অপারেশন করা হয়নি, এবং অন্য কোনও google_ প্রতিক্রিয়া পরামিতি সেট করা হবে না। সমর্থিত ত্রুটি মান নিম্নলিখিত অন্তর্ভুক্ত: 1 : ব্যবহারকারীর একটি Google কুকি আছে, কিন্তু এই কুকি ব্যবহার করে যেকোনো ট্র্যাকিং থেকে অপ্ট আউট করেছে৷ 2 : কোন বৈধ অপারেশন নির্দিষ্ট করা নেই. উদাহরণস্বরূপ, একটি নো-অপ অনুরোধ গৃহীত হয়েছিল। 3 : ব্যবহারকারীর কাছে Google কুকি নেই৷ Google কুকি ম্যাচিং পরিষেবার মাধ্যমে কুকি সেট করবে না৷ 4 : বিরোধপূর্ণ অপারেশন নির্দিষ্ট করা হয়েছে। আপনি একই অনুরোধে google_push এবং google_cm উভয় পতাকা নির্দিষ্ট করতে পারবেন না যেহেতু তাদের বিরোধপূর্ণ উদ্দেশ্য রয়েছে৷ 5 : একটি দ্বিমুখী পিক্সেল ম্যাচিং অনুরোধের অংশ হিসাবে একটি Google সার্ভারে একটি রিডাইরেক্টে একটি অবৈধ google_push প্যারামিটার পাস করা হয়েছিল৷ আপনার রিডাইরেক্টকে অবশ্যই google_push সেট করতে হবে একই মান যা আপনাকে প্রাথমিক পিক্সেল অনুরোধে পাঠানো হয়েছে। 6 : ম্যাচ ট্যাগে একটি অবৈধ NID সরবরাহ করা হয়েছে। 7 : একটি অবৈধ কুকি সনাক্ত করা হয়েছে৷ 8 : অবচয়। কোন কুকি পাওয়া যায়নি. 9 : কোন কুকি পাওয়া যায়নি, একটি পরীক্ষা কুকি সেট করার চেষ্টা করা হয়েছে। 10 : google_redir প্যারামিটারটি google_hm নির্দিষ্ট না করে ব্যবহার করা হয়েছিল, বা google_cm এর সাথে ব্যবহার করা হয়েছিল। 15 : অনুরোধটি এমন একটি অঞ্চল থেকে এসেছে যেখানে Google-এর দ্বারা হোস্ট করা ম্যাচ টেবিলের প্রয়োজন। ফলস্বরূপ, এই প্রতিক্রিয়াতে একটি Google ব্যবহারকারী আইডি নেই।

Google-প্রবর্তিত: দ্বিমুখী পিক্সেল ম্যাচিং

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

ধাপ 1: Google একটি ম্যাচ ট্যাগ রাখে

যখন একজন অংশগ্রহণকারী প্রকাশকের পৃষ্ঠা ব্যবহারকারীর ব্রাউজারে লোড হয়, এবং সেই পৃষ্ঠায় একটি বিজ্ঞাপন স্লট Google দ্বারা পূর্ণ হয়, তখন একটি ম্যাচ ট্যাগ স্থাপন করা হতে পারে যা একটি অ্যালগরিদমিকভাবে নির্বাচিত বিডার থেকে একটি পিক্সেলের অনুরোধ করে৷ Google দ্বারা স্থাপিত পিক্সেল ম্যাচিং ট্যাগটি দরদাতার কুকি ম্যাচিং ইউআরএলকে অতিরিক্ত প্যারামিটারের সাথে একত্রিত করে যা দরদাতা তাদের ম্যাচ টেবিলটি পূরণ করতে ব্যবহার করতে পারেন। https://ad.network.com/pixel হিসাবে নির্দিষ্ট করা কুকি ম্যাচিং URL এর জন্য, এটি নিম্নরূপ গঠন করা হয়েছে:

<img src="https://ad.network.com/pixel?google_gid=GOOGLE_GID&google_cver=1&google_push=PUSH_DATA" />

ধাপ 2: দরদাতাকে অবশ্যই Google-এর কুকি ম্যাচিং পরিষেবা URL-এ পুনঃনির্দেশের সাথে প্রতিক্রিয়া জানাতে হবে

পিক্সেল ম্যাচিং রিকোয়েস্ট প্রাপ্ত দরদাতাদের Google এর কুকি ম্যাচিং সার্ভিসে একটি পুনঃনির্দেশের সাথে সাড়া দিতে হবে যা নিম্নরূপ গঠন করা হয়েছে:

https://cm.g.doubleclick.net/pixel?google_nid=GOOGLE_NID&google_push=PUSH_DATA

মনে রাখবেন যে পূর্ববর্তী পুনঃনির্দেশ URLটি বিডার-ইনিশিয়েটেড কুকি ম্যাচিং ওয়ার্কফ্লো- এর জন্য ম্যাচ ট্যাগে ব্যবহৃত URL-এর অনুরূপ। Pixel Matching-এ, google_cm প্যারামিটারটি google_push প্যারামিটার দ্বারা প্রতিস্থাপিত হয় এবং এর মান অবশ্যই Google এর অনুরোধে প্রদত্ত মানের সমান হতে হবে। এছাড়াও দরদাতা-সূচিত কর্মপ্রবাহের অনুরূপ, অতিরিক্ত ব্যবহারের ক্ষেত্রে অতিরিক্ত পরামিতিগুলি নির্দিষ্ট করা যেতে পারে।

সতর্কতা: google_cm এবং google_push পরামিতিগুলি কখনই Google-এর কুকি ম্যাচিং পরিষেবাতে একই অনুরোধে উপস্থিত হওয়া উচিত নয়৷

ধাপ 3: Google রিডাইরেক্ট প্রক্রিয়া করে এবং পিক্সেল দিয়ে সাড়া দেয়

Google লগ করে যে ব্যবহারকারীর জন্য একটি মিল তৈরি করা হয়েছে, এবং ক্যোয়ারী প্যারামিটারের মাধ্যমে অনুরোধ করা যেকোনো অতিরিক্ত ক্রিয়াকলাপ পরিচালনা করে অবশেষে, Google একটি 1x1 স্বচ্ছ পিক্সেলের সাথে প্রতিক্রিয়া জানায়।

পিক্সেল ম্যাচিং ওয়ার্কফ্লো ডায়াগ্রাম

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

Google ম্যাচ ট্যাগ অনুরোধের পরামিতি

প্যারামিটার	বর্ণনা
google_gid	গুগল ইউজার আইডি। গোপনীয়তা বিধিনিষেধ সহ মার্কিন যুক্তরাষ্ট্রের নয় এমন ব্যবহারকারীদের জন্য, এটি সর্বদা Google-এর ম্যাচ ট্যাগে নির্দিষ্ট করা হবে।
google_cver	কুকি সংস্করণ। এটি সর্বদা Google এর ম্যাচ ট্যাগে নির্দিষ্ট করা হবে।
google_push	নির্দেশ করে যে এই অনুরোধটি Pixel ম্যাচিং ওয়ার্কফ্লো শুরু করছে। দরদাতার পুনঃনির্দেশ প্রতিক্রিয়াতে সংশ্লিষ্ট প্যারামিটারের মাধ্যমে মানটি অবশ্যই ফেরত দিতে হবে।
gdpr_consent	একটি TC স্ট্রিং যা শেষ-ব্যবহারকারীর সম্মতির প্রতিনিধিত্ব করে। আরও বিস্তারিত জানার জন্য, [EU ব্যবহারকারীর সম্মতির প্রয়োজনীয়তা](/authorized-buyers/rtb/cookie-guide#eu-user-consent-requirements) দেখুন, অথবা **টিসি স্ট্রিং কীভাবে পাস করা হবে?** [অনুমোদিত ক্রেতাদের IAB TCF v2.0 ডকুমেন্টেশন](//support.google.com/th398buyers/th987/th/support.google.com/th38buyers) দেখুন।

বিডার পিক্সেল ম্যাচিং রিডাইরেক্ট প্যারামিটার

প্যারামিটার	বর্ণনা
google_nid	বিডার অ্যাকাউন্টের জন্য নেটওয়ার্ক আইডি (NID)। এই আইডিটি বিডার্স রিসোর্সের মাধ্যমে পুনরুদ্ধার করা যেতে পারে।
google_push	নির্দেশ করে যে এই রিডাইরেক্টটি Pixel ম্যাচিং ওয়ার্কফ্লো সম্পূর্ণ করছে। সংশ্লিষ্ট Google ম্যাচ ট্যাগ থেকে মান এখানে উল্লেখ করা আবশ্যক।
google_hm	দরদাতা একটি Google-হোস্ট করা ম্যাচ টেবিলে সঞ্চয় করতে চায় এমন ডেটা রয়েছে৷ দ্রষ্টব্য: মানটি একটি ওয়েব-নিরাপদ বেস64-এনকোডেড স্ট্রিং (প্যাডিং ঐচ্ছিক) যা 40 বাইটের বেশি হওয়া উচিত নয়। উদাহরণস্বরূপ, এটির মত দেখতে হতে পারে: Q29va2llIG51bWJlciAxIQ== ।
google_ula	একটি বিদ্যমান ব্যবহারকারী তালিকায় ব্যবহারকারীকে যুক্ত করতে ব্যবহৃত একটি স্ট্রিং। মানটির প্রত্যাশিত বিন্যাস হল userlistid[,timestamp] : userlistid : একটি একক সংখ্যাসূচক ব্যবহারকারী তালিকা আইডি। timestamp : POSIX ফরম্যাটে একটি ঐচ্ছিক টাইমস্ট্যাম্প, ব্যবহারকারীকে কখন ব্যবহারকারী তালিকায় যুক্ত করা হয়েছে তা নির্দেশ করে। ব্যবহারকারীকে একাধিক তালিকায় যুক্ত করতে এই URL প্যারামিটারটি পুনরাবৃত্তি করা হতে পারে।
gdpr_consent	একটি TC স্ট্রিং যা শেষ-ব্যবহারকারীর সম্মতির প্রতিনিধিত্ব করে। আরও তথ্যের জন্য, [ইইউ ব্যবহারকারীর সম্মতি প্রয়োজনীয়তা] (/অনুমোদিত-ক্রেতারা/আরটিবি/কুকি-গাইড#ইইউ-ব্যবহারকারী-কনসেন্ট-রিকিউরমেন্টস), বা ** টিসি স্ট্রিংটি কীভাবে পাস করা হবে? ** [অনুমোদিত ক্রেতারা আইএবি টিসিএফ ভি 2.0 ডকুমেন্টেশন] (// সাপোর্ট.গোওগল/অ্যুথরাইজডব্লিউইউইউইউইউইউইউইউইউইউইউইউইউইউইউইউইউইউইউইউইউইআর) ৯৯) দেখুন।

গুগল-উদ্যোগী: একমুখী পিক্সেল ম্যাচিং

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

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

পদক্ষেপ 1: গুগল একটি ম্যাচ ট্যাগ রাখে

গুগল একটি অ্যালগরিদমিকভাবে নির্বাচিত দরদাতার জন্য একটি ম্যাচ ট্যাগ রাখে। ম্যাচের ট্যাগটিতে google_push প্যারামিটার অন্তর্ভুক্ত রয়েছে। এখানে একটি উদাহরণ:

<img src="https://ad.network.com/pixel?google_push=PUSH_DATA" />

পদক্ষেপ 2: ব্যবহারকারীর ব্রাউজার দরদাতাদের রান্নার ম্যাচিং ইউআরএল থেকে পিক্সেল অনুরোধ করে

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

পদক্ষেপ 3: গুগলের কুকি ম্যাচিং পরিষেবাতে পুনঃনির্দেশ

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

https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_hm=HOSTED_MATCH_DATA&google_push=PUSH_DATA

পদক্ষেপ 4: ব্যবহারকারীর ব্রাউজারটি গুগলের কুকি ম্যাচিং পরিষেবাতে পুনঃনির্দেশিত হয়েছে

গুগল এইচটিটিপি শিরোনামে গুগলের কুকি ছাড়াও আপনার নির্দিষ্ট করা পরামিতিগুলি সমন্বিত একটি পুনঃনির্দেশ পাবেন। যদি অপারেশনটি সফল হয় তবে পরবর্তী বিড অনুরোধগুলিতে এই ব্যবহারকারীর জন্য ছাপগুলি বিডারের হোস্টেড ম্যাচের ডেটা BidRequest.user.buyeruid অন্তর্ভুক্ত করবে। দরদাতারা তাদের নির্দিষ্ট করা হোস্ট ম্যাচ ডেটা ব্যবহার করে ব্যবহারকারী তালিকাগুলিও জনপ্রিয় করতে পারে।

অবশেষে, গুগল ব্যবহারকারীর ব্রাউজারে একটি 1x1 স্বচ্ছ পিক্সেল ফেরত দেয়।

কুকি ম্যাচ সহায়তা

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

কুকি ম্যাচ সহায়তা কীভাবে কাজ করে

1. কোনও বিজ্ঞাপন স্থাপন করার সময়, গুগল অ্যালগরিদমিকভাবে একটি অংশগ্রহণকারী এক্সচেঞ্জ নির্বাচন করে এবং একটি কুকি ম্যাচ সহায়তা ট্যাগ রাখে যা নিম্নলিখিত কাঠামো রয়েছে:

   <img src="https://ob.exchange.com/pixel?google_gid=GOOGLE_GID&google_cver=1"/>

   সাবধানতা: গোপনীয়তার বিধিনিষেধ সহ মার্কিন যুক্তরাষ্ট্রের ব্যবহারকারীদের জন্য, কুকি ম্যাচ সহায়তা google_gid প্যারামিটার অন্তর্ভুক্ত করবে না।

2. গুগলের সিএমএ ম্যাচ ট্যাগের ফলে এক্সচেঞ্জের কুকি ম্যাচিং ইউআরএল একটি পিক্সেল অনুরোধ পাওয়ার কারণ হয়।

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

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

বিধিনিষেধ

নতুন ম্যাচের জন্য অনুরোধের ক্যাপ ফ্রিকোয়েন্সি

গুগল-হোস্টেড ম্যাচ টেবিলে নতুন প্রবেশকারী ব্যবহারকারীদের জন্য কুকি ম্যাচিং পরিষেবাতে কলগুলির সংখ্যা সীমাবদ্ধ করার জন্য দরদাতারা দায়বদ্ধ। হোস্টেড ম্যাচ টেবিলের একটি এন্ট্রি 14 দিনের মধ্যে মেয়াদোত্তীর্ণ হিসাবে বিবেচিত হতে পারে, যার পরে এটি সতেজ করা যায়।

সতর্কতা: গুগল পরিবেশন সময়ে ফ্রিকোয়েন্সি ক্যাপিং প্রয়োগ করে না। যাইহোক, এটি পর্যায়ক্রমে পর্যবেক্ষণ করে যে আপনি ফ্রিকোয়েন্সি ক্যাপিং নীতিকে সম্মান করছেন এবং লঙ্ঘনের ক্ষেত্রে পরিষেবাটি বাধাগ্রস্ত করার অধিকার সংরক্ষণ করে।

সমস্ত পিক্সেল ম্যাচের অনুরোধে সাড়া দিন

পিক্সেল ম্যাচিং ওয়ার্কফ্লো ব্যবহার করে দরদাতারা google_push প্যারামিটার সহ প্রতিক্রিয়া সহ সমস্ত আগত পিক্সেল ম্যাচের অনুরোধগুলির প্রতিক্রিয়া জানাবে বলে আশা করা হচ্ছে। এটি গুগলকে ব্যবহার পর্যবেক্ষণ করে নীতিগুলি প্রয়োগ করতে দেয়। যদি কোনও দরদাতার প্রতিক্রিয়া হার 90%এর চেয়ে কম হয় তবে গুগল তাদের অ্যাকাউন্টে প্রেরিত পিক্সেল ম্যাচের অনুরোধগুলির সংখ্যাটি থ্রোটল করবে।

এইচটিটিপিএস এন্ডপয়েন্টগুলি ব্যবহার করুন

এটি প্রয়োজনীয় যে সমস্ত কুকি ম্যাচিং ওয়ার্কফ্লোতে ব্যবহৃত এন্ডপয়েন্টগুলি এইচটিটিপিএস ব্যবহার করে।

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

ইইউ ব্যবহারকারীর সম্মতি প্রয়োজনীয়তা

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

• টিসিএফভি 2: এর মধ্যে gdpr এবং gdpr_consent পরামিতি অন্তর্ভুক্ত রয়েছে। বিশদগুলির জন্য, অনুমোদিত ক্রেতাদের আইএবি টিসিএফ ভি 2.0 ডকুমেন্টেশনের সাথে পরামর্শ করুন।
• process_consent : বিডার প্রয়োজনীয় ব্যবহারকারীর সম্মতি অর্জন করেছে এমন একটি ঘোষণা।

উদাহরণ

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

একটি দরদাতা-হোস্টেড ম্যাচ টেবিলটি পপুলেট করুন

একজন দরদাতা তাদের ম্যাচ ট্যাগে কেবলমাত্র google_nid এবং google_cm প্যারামিটার সরবরাহ করে তাদের নিজস্ব ম্যাচ টেবিলটি পপুলেট করতে কুকি ম্যাচিং ওয়ার্কফ্লো ব্যবহার করতে পারেন। এটি দেখতে এরকম হতে পারে:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_cm" />

যদি দরদাতার কুকি ম্যাচিং ইউআরএলটি https://ad.network.com/pixel?id=1 এ সেট করা থাকে এবং কুকি ম্যাচিং অপারেশন সফল হয়, তবে বিডারের ম্যাচ ট্যাগের প্রতিক্রিয়া হিসাবে গুগল প্রেরণ করে:

https://ad.network.com/pixel?id=1&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1

যদি কুকি ম্যাচিং অপারেশন ব্যর্থ হয় কারণ ব্যবহারকারীর গুগল কুকি না থাকে তবে প্রতিক্রিয়াটি হবে:

https://ad.network.com/pixel?id=1&google_error=3

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

দ্রষ্টব্য: ম্যাচ ট্যাগে দেখা দরদাতা-সংজ্ঞায়িত প্যারামিটার id যখন গুগল দরদাতাদের কুকি ম্যাচিং ইউআরএল-তে পুনর্নির্দেশ করে তখন এটি পাস করা হয়।

একক ব্যবহারকারীর তালিকায় যুক্ত করুন

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

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345" />

একটি সফল প্রতিক্রিয়ার জন্য, যেখানে দরদাতাদের কুকি ম্যাচিং ইউআরএলটি https://ad.network.com/pixel , গুগলের পুনঃনির্দেশ ইউআরএল হবে:

https://ad.network.com/pixel?google_ula=12345,0

মূল বিষয়: google_ula মান 12345,0 , এটি নির্দেশ করে যে ব্যবহারকারীকে আইডি 12345 সহ একটি ব্যবহারকারী তালিকায় যুক্ত করা উচিত এবং এই ক্ষেত্রে টাইমস্ট্যাম্পটি 0 এ সেট করা আছে যে এটি অনির্ধারিত রেখে দেওয়া হচ্ছে। বিকল্পভাবে, কেবল ব্যবহারকারী তালিকা আইডি সরবরাহ করা যেতে পারে।

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

• https://ad.network.com/pixel?google_error=3

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

https://ad.network.com/pixel?google_ula=12345,2

একাধিক ব্যবহারকারী তালিকায় যুক্ত করুন

দরদাতারা নির্দিষ্ট করতে পারেন যে কোনও ব্যবহারকারীকে ম্যাচ ট্যাগের একাধিক google_ula প্যারামিটারগুলি অন্তর্ভুক্ত করে একাধিক ব্যবহারকারী তালিকায় যুক্ত করা উচিত। অনুশীলনে, এটি দেখতে দেখতে:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345,7654321&google_ula=45678" />

প্রতিটি ব্যবহারকারীর তালিকার জন্য অপারেশনের স্থিতি একইভাবে পুনঃনির্দেশে স্বতন্ত্র google_ula পরামিতিগুলির মাধ্যমে রিপোর্ট করা হয়:

https://ad.network.com/pixel?google_ula=12345,2&google_ula=45678,0

পূর্ববর্তী পুনঃনির্দেশে, আমরা দেখতে পাচ্ছি যে অপারেশনটি আইডি 45678 সহ ব্যবহারকারী তালিকার জন্য সফল হয়েছে, তবে ব্যবহারকারী তালিকা আইডি 12345 জন্য ব্যর্থ হয়েছে কারণ দরদাতার এটি অ্যাক্সেস করার অনুমতি ছিল না।

কুকি ম্যাচিং ওয়ার্কফ্লো দিয়ে পদক্ষেপ নিন এবং ব্যবহারকারীর তালিকায় যুক্ত করুন

কুকি ম্যাচিং সম্পাদন করতে এবং ব্যবহারকারীকে একক অনুরোধে ব্যবহারকারী তালিকায় যুক্ত করতে, একটি দরদাতার ম্যাচ ট্যাগের মধ্যে google_cm এবং google_ula অন্তর্ভুক্ত করা উচিত:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345&google_cm" />

গুগল দ্বারা নির্দিষ্ট করা পুনর্নির্দেশের ইউআরএলটিতে google_gid , google_cver এবং google_ula অন্তর্ভুক্ত থাকবে। এটি নিম্নলিখিত মত দেখতে পারে:

https://ad.network.com/pixel?id=&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1&google_ula=12345,0

গুগল-হোস্টেড ম্যাচ টেবিলে একটি ম্যাচ সংরক্ষণ করুন

যদি কোনও দরদাতা তাদের কুকি ডেটা কোনও গুগল-হোস্টেড ম্যাচ টেবিলে সঞ্চয় করতে চান এবং গুগল ব্যবহারকারী আইডির সাথে তাদের নিজস্ব ম্যাচ টেবিলে ম্যাচ সঞ্চয় করতে চান না, তবে তাদের ম্যাচ ট্যাগটি অবশ্যই google_hm প্যারামিটার অন্তর্ভুক্ত করতে হবে যেখানে এর মানটি অবশ্যই একটি ওয়েব-সেফ বেস 64-এনকোড স্ট্রিং হতে হবে। এমন কোনও ব্যবহারকারীর জন্য যেখানে দরদাতার আনকোডড কুকি ডেটা Cookie number 1! , এনকোডেড মানটি Q29va2llIG51bWJlciAxIQ== হবে, যা নিম্নলিখিতগুলির মতো একটি ম্যাচ ট্যাগে ব্যবহৃত হবে:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D" />

একটি সফল প্রতিক্রিয়ার জন্য, যেখানে দরদাতার কুকি ম্যাচিং ইউআরএলটি https://cookie-monster.com/pixel , গুগলের পুনর্নির্দেশের ইউআরএল হবে:

https://cookie-monster.com/pixel

google_gid প্যারামিটারটি পুনঃনির্দেশে নেই কারণ ম্যাচ ট্যাগটিতে google_cm অন্তর্ভুক্ত ছিল না, এবং google_hm সফল প্রতিক্রিয়াগুলিতে অন্তর্ভুক্ত নয়। ভবিষ্যতে এই ব্যবহারকারীর জন্য ছাপগুলির জন্য বিড অনুরোধগুলিতে, দরদাতারা তাদের হোস্টেড ম্যাচের ডেটা BidRequest.user.buyeruid পাবেন।

যদি দরদাতার পরিবর্তে কোনও ম্যাচ ট্যাগ ব্যবহার করা হয় যেখানে google_hm এর মান বেস 64-এনকোড করা হয়নি-যেমন chocolate_chunk! - পুনর্নির্দেশের ইউআরএলটি নিম্নলিখিতগুলির মতো দেখতে পারে:

https://cookie-monster.com/pixel?google_hm=2

পূর্ববর্তী পুনর্নির্দেশের ইউআরএলটিতে 2 এর একটি google_hm মান অন্তর্ভুক্ত রয়েছে, যা অপারেশনটি ব্যর্থ হয়েছে কারণ মানটি ডিকোড করা যায় না বলে পরামর্শ দেয়।

ব্যবহারকারীর তালিকা সহ দরদাতা এবং গুগল-হোস্টেড ম্যাচের টেবিলগুলি

যদি কোনও দরদাতা গুগল-হোস্টেড ব্যবহারকারী তালিকা ছাড়াও তাদের নিজস্ব ব্যবহারের তালিকাটি হোস্ট করে এবং উভয় টেবিলের সাথে মেলে এবং একটি প্রদত্ত ব্যবহারকারী তালিকায় ব্যবহারকারীকে যুক্ত করতে একটি একক ম্যাচ ট্যাগ চায় তবে তাদের ম্যাচ ট্যাগটি অবশ্যই google_cm , google_hm এবং google_ula পরামিতি অন্তর্ভুক্ত করতে হবে। যদি দরদাতার কুকি ডেটা Cookie number 1! , এনকোডেড মানটি Q29va2llIG51bWJlciAxIQ== হবে যা নিম্নলিখিতগুলির মতো একটি ম্যাচ ট্যাগ তৈরি করবে:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D&google_cm&google_ula=12345" />

একটি সফল প্রতিক্রিয়ার জন্য, যেখানে দরদাতাদের কুকি ম্যাচিং ইউআরএলটি https://cookie-monster.com/pixel , গুগলের পুনর্নির্দেশের ইউআরএলটি নিম্নলিখিতগুলির মতো দেখাবে:

https://cookie-monster.com/pixel?google_gid=ABCDETC&google_cver=1&google_ula=12345,0

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

,

কুকি ম্যাচিং এমন একটি বৈশিষ্ট্য যা আপনাকে আপনার কুকির সাথে মেলে দেয় example এই গাইডটি কুকি ম্যাচিংয়ের ক্ষেত্রে ব্যবহৃত ধারণাগুলি, পাশাপাশি বিভিন্ন কুকি ম্যাচিং ওয়ার্কফ্লো এবং নির্দিষ্ট ব্যবহারের ক্ষেত্রে তাদের যে কোনও বৈচিত্র্য থাকতে পারে তা বর্ণনা করে।

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

ধারণা

কুকি ম্যাচ কি?

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

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

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

ম্যাচ টেবিল

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

গুগল-হোস্টেড ম্যাচের টেবিলগুলি

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

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

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

• ব্যবহারকারীর তালিকা : ব্যবহারকারীর তালিকাগুলি গুগল ব্যবহারকারী আইডি বা হোস্টেড ম্যাচের ডেটাগুলির সাথে পপুলেশন করা যেতে পারে।

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

ব্যবহারকারীর তালিকা

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

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

শুরু করা

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

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

দ্রষ্টব্য: অনুমোদিত ক্রেতারা বিডার্স রিসোর্সের সাথে তাদের অ্যাকাউন্টগুলির জন্য কনফিগার করা কুকি ম্যাচিং এনআইডি এবং ইউআরএল দেখতে পারেন।

কুকি ম্যাচিং ম্যাক্রো

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

সমর্থিত ম্যাক্রো

দরদাতারা %%GOOGLE_<PARAM_NAME>%% বা %%GOOGLE_<PARAM_NAME>_PAIR%% আকারে এক বা একাধিক ম্যাক্রো অন্তর্ভুক্ত করতে তাদের কুকি ম্যাচিং ইউআরএলকে বিকল্পভাবে কনফিগার করতে পারেন। সমর্থিত ম্যাক্রো এবং তাদের প্রসারিত মানগুলি হ'ল:

ম্যাক্রো	প্রসারিত মান
গুগল_জিড	GOOGLE_USER_ID
গুগল_জিআইডি_পায়ার	& google_gid = GOOGLE_USER_ID
গুগল_সিভার	COOKIE_VERSION_NUMBER
গুগল_সিভার_পায়ার	& সিভার = COOKIE_VERSION_NUMBER
গুগল_রর	ERROR_ID
Google_error_pair	& google_error = ERROR_ID
গুগল_পুশ	PIXEL_MATCH_DATA
গুগল_পশ_পায়ার	& গুগল_পুশ = PIXEL_MATCH_DATA
গুগল_ল_প্যারামস	google_gid = GOOGLE_USER_ID এবং সিভার = COOKIE_VERSION_NUMBER এবং গুগল_রর = ERROR_ID

ম্যাক্রো উদাহরণ

একজন দরদাতার https://user.bidder.com/cookies এ হোস্ট করা একটি শেষ পয়েন্টের সাথে একটি কুকি ম্যাচিং ইন্টিগ্রেশন রয়েছে এবং তাদের বাস্তবায়নের জন্য নিম্নলিখিত ক্রমে পিক্সেল ম্যাচিং পরামিতিগুলি ছাড়াও প্রিসেট বিডার-ডিফাইন্ড প্যারামিটারগুলির প্রয়োজন: google_push , google_gid , google_cver এবং google_error । দরদাতা তাদের কুকি ম্যাচিং ইউআরএল সেট করে এটি সম্পাদন করতে পারে:

https://user.bidder.com/cookies?w=0%%GOOGLE_PUSH_PAIR%%&x=1%%GOOGLE_GID_PAIR%%&y=2%%GOOGLE_CVER_PAIR%%&z=3%%GOOGLE_ERROR_PAIR%%

গুগল পরে যখন এই দরদাতাকে একটি ম্যাচের অনুরোধ প্রেরণ করে, তখন এটি নিম্নলিখিতগুলির মতো কিছুতে প্রসারিত হবে:

https://user.bidder.com/cookies?w=0&google_push=PUSH_DATA&x=1&google_gid=GOOGLE_GID&y=2&google_cver=1&z=3

দ্রষ্টব্য: google_error প্যারামিটারটি পিক্সেল ম্যাচিং ওয়ার্কফ্লোয়ের জন্য গুগলের ম্যাচ ট্যাগে পপুলেটেড নয় এবং তাই এটি বাদ দেওয়া হয়।

কুকি ম্যাচিং সার্ভিস ওয়ার্কফ্লো

গুগলের কুকি ম্যাচিং পরিষেবা নিম্নলিখিত তিনটি কর্মপ্রবাহকে সমর্থন করে।

বিডার-উদ্যোগে: দ্বিদলীয় কুকি ম্যাচিং

দ্বি-নির্দেশমূলক কুকি ম্যাচিং একটি দরদাতাকে-উদ্যোগী ওয়ার্কফ্লোকে বোঝায়, যেখানে তারা ব্যবহারকারীর ব্রাউজারে একটি ম্যাচ ট্যাগ রাখে যা এটি গুগলে নির্দেশ দেয়। এই ওয়ার্কফ্লো গুগল এবং দরদাতাকে উভয়ই ম্যাচের টেবিলগুলি পপুলেট করতে দেয়। নিম্নলিখিতটি এই কর্মপ্রবাহের একটি উদাহরণ।

পদক্ষেপ 1: ম্যাচ ট্যাগ রাখুন

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

<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm" />

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

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

পদক্ষেপ 2: গুগল ম্যাচের ডেটা সহ পুনর্নির্দেশের সাথে প্রতিক্রিয়া জানায়

ম্যাচের ট্যাগটি গুগলের কুকি ম্যাচিং পরিষেবাটি ব্যবহারকারীর ব্রাউজারের কাছ থেকে একটি অনুরোধ গ্রহণ করবে, যা বিডারের কুকি ম্যাচিং ইউআরএলটিতে একটি HTTP 302 পুনর্নির্দেশ জারি করবে। পুনঃনির্দেশে গুগল ব্যবহারকারী আইডি এবং ইউআরএলে এর সংস্করণ নম্বর নির্দিষ্ট করে ক্যোয়ারী প্যারামিটারগুলি অন্তর্ভুক্ত করা হবে এবং দরদাতার অনুরোধ শিরোনামগুলিতে অন্তর্ভুক্ত তাদের কুকিও পাবেন। অনুশীলনে, https://ad.network.com/pixel হিসাবে নির্দিষ্ট একটি কুকি ম্যাচিং ইউআরএল জন্য, পূর্ববর্তী ম্যাচ ট্যাগের পুনর্নির্দেশের ইউআরএলটি নিম্নলিখিতগুলির মতো দেখতে পারে:

https://ad.network.com/pixel?google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1

google_gid প্যারামিটারের মাধ্যমে পাস করা গুগল ব্যবহারকারী আইডিটি একটি আনপ্যাডেড ওয়েব-নিরাপদ বেস 64-এনকোডযুক্ত স্ট্রিং। দরদাতারা একটি ম্যাচ টেবিল হোস্ট করতে পছন্দ করে, এটি সুপারিশ করা হয় যে তারা কুকি ম্যাচিং পরিষেবাটি দ্বারা ফিরে আসা সঠিক স্ট্রিংটি সংরক্ষণ করে। পরবর্তী বিআইডি অনুরোধগুলিতে, এটি BidRequest.user.id এর মাধ্যমে নির্দিষ্ট মানগুলির সাথে মিলে যাবে।

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

গুগল যদি আপনার ম্যাচের অনুরোধটি প্রক্রিয়াকরণের সময় কোনও ত্রুটির মুখোমুখি হয় তবে পরিবর্তে একটি google_error প্যারামিটার নির্দিষ্ট করা হবে।

পদক্ষেপ 3: বিডার প্রক্রিয়াগুলি পুনঃনির্দেশ করে এবং পিক্সেলের সাথে প্রতিক্রিয়া জানায়

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

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

দরদাতাকে সর্বদা 1x1 অদৃশ্য পিক্সেল চিত্র পরিবেশন করে অবশ্যই প্রতিক্রিয়া জানাতে হবে বা বিকল্পভাবে HTTP 204 কোনও সামগ্রীর প্রতিক্রিয়া ফেরত দেয় না ।

কুকি ম্যাচিং ওয়ার্কফ্লো ডায়াগ্রাম

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

ট্যাগ ট্যাগ ইউআরএল পরামিতি

প্যারামিটার	বর্ণনা
google_nid	বিডার অ্যাকাউন্টের জন্য নেটওয়ার্ক আইডি (এনআইডি)। এই আইডি দরদাতাদের সংস্থার মাধ্যমে পুনরুদ্ধার করা যেতে পারে।
google_cm	গুগলের কুকি ম্যাচিং পরিষেবাটিকে ইঙ্গিত করে যে এটি কুকি ম্যাচিং করা উচিত। প্যারামিটারের মান উপেক্ষা করা হয় এবং বাদ দেওয়া যেতে পারে।
google_sc	এই প্যারামিটারটি অবহেলিত। যদি কেউ উপস্থিত না থাকে তবে ব্যবহারকারীর জন্য গুগলের কুকিটি সেট করে। প্যারামিটারের মান উপেক্ষা করা হয় এবং বাদ দেওয়া যেতে পারে। কোনও কুকি না থাকলে প্যারামিটারটি বাদ দেওয়ার ফলে ত্রুটি হয়।
google_no_sc	এই প্যারামিটারটি অবহেলিত। এটি গুগলের কুকি ম্যাচিং পরিষেবাটিকে নির্দেশ করে যে এটি উপস্থিত না থাকলে এটি ব্যবহারকারীর জন্য কোনও কুকি সেট করা উচিত নয়। প্যারামিটারের মান উপেক্ষা করা হয় এবং বাদ দেওয়া যেতে পারে।
google_hm	ডেটা দরদাতা একটি গুগল-হোস্টেড ম্যাচ টেবিলে সঞ্চয় করতে চায়। মানটি হ'ল একটি ওয়েব-নিরাপদ বেস 64-এনকোডড স্ট্রিং (প্যাডিং al চ্ছিক)। কাঁচা ডেটা অবশ্যই 40 বাইট বা তার চেয়ে কম হতে হবে। উদাহরণস্বরূপ, Q29va2llIHRoYXQgaXMgdW5kZXIgNDAgdG90YWwgYnl0ZXMuLi4u ।
google_redir	একটি ইউআরএল-এনকোডেড স্ট্রিং যা কোনও দরদাতারা এই ম্যাচ ট্যাগের জন্য এনকোডেড ইউআরএলে HTTP 302 পুনর্নির্দেশ পাঠাতে গুগলকে নির্দেশ দিতে চান কিনা তা নির্দিষ্ট করতে পারে। এটি গুগলকে অংশীদারদের শৃঙ্খলিত কলটিতে সামনে রাখার অনুমতি দেয়। এটি google_hm ছাড়া বা google_cm ছাড়া নির্দিষ্ট করা হলে একটি ত্রুটি ঘটবে।
google_ula	একটি স্ট্রিং ব্যবহারকারীকে বিদ্যমান ব্যবহারকারীর তালিকায় যুক্ত করতে ব্যবহৃত হয়। মানটির প্রত্যাশিত ফর্ম্যাটটি হ'ল userlistid[,timestamp] : userlistid : একটি একক সংখ্যাসূচক ব্যবহারকারী তালিকা আইডি। timestamp : পোসিক্স ফর্ম্যাটে একটি al চ্ছিক টাইমস্ট্যাম্প, যখন ব্যবহারকারী ব্যবহারকারীর তালিকায় যুক্ত করা হয়েছে তখন তা নির্দেশ করে। এই ইউআরএল প্যারামিটারটি ব্যবহারকারীকে একাধিক তালিকায় যুক্ত করতে পুনরাবৃত্তি করা যেতে পারে।
gdpr	ইঙ্গিত দেয় যে অনুরোধটি ডেটা ব্যবহারের উপর জিডিপিআর বিধিনিষেধের সাপেক্ষে। আরও বিশদের জন্য, EU ব্যবহারকারীর সম্মতির প্রয়োজনীয়তাগুলি দেখুন, বা অনুমোদিত ক্রেতাদের আইএবি টিসিএফ ভি 2.0 ডকুমেন্টেশনে কুকি ম্যাচের যোগ্যতার উপর প্রভাব । উদাহরণ: gdpr=1
gdpr_consent	একটি টিসি স্ট্রিং যা শেষ ব্যবহারকারীর সম্মতি উপস্থাপন করে। আরও বিশদের জন্য, EU ব্যবহারকারীর সম্মতির প্রয়োজনীয়তাগুলি দেখুন, বা কীভাবে টিসি স্ট্রিং পাস হবে? অনুমোদিত ক্রেতাদের আইএবি টিসিএফ ভি 2.0 ডকুমেন্টেশনে ।
process_consent	ইঙ্গিত দেয় যে দরদাতা গুগলের ইইউ ব্যবহারকারী সম্মতি নীতিতে নির্দিষ্ট করা ডেটা ব্যবহারের জন্য শেষ ব্যবহারকারীর সম্মতি অর্জন করেছে। যদি অনুরোধটি ইইউ ব্যবহারকারী সম্মতি নীতি সাপেক্ষে না হয়, বা যদি অনুরোধে ( gdpr_consent ) অন্য সম্মতি পরামিতি পাওয়া যায় তবে এই প্যারামিটারটি উপেক্ষা করা হবে। উদাহরণ: process_consent=T

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

<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm&extra1=xx&extra2=yy" />

ইউআরএল পরামিতিগুলি পুনর্নির্দেশ করুন

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

প্যারামিটার	বর্ণনা
google_gid	গুগল ব্যবহারকারী আইডি। অনুরোধে google_cm নির্দিষ্ট করা আছে কিনা তা সেট করুন এবং অনুরোধটি সফল হয়েছিল।
google_cver	কুকি সংস্করণ। অনুরোধে google_cm নির্দিষ্ট করা আছে কিনা তা সেট করুন এবং অনুরোধটি সফল হয়েছিল।
google_error	সামগ্রিক অনুরোধ ত্রুটি নির্দেশ করে একটি পূর্ণসংখ্যার মান। যখন প্রাপ্ত হয়, এটি ইঙ্গিত দেয় যে কোনও অপারেশন সম্পাদন করা হয়নি, এবং অন্য কোনও google_ প্রতিক্রিয়া পরামিতি সেট করা হবে না। সমর্থিত ত্রুটি মানগুলির মধ্যে নিম্নলিখিতগুলি অন্তর্ভুক্ত রয়েছে: 1 : ব্যবহারকারীর একটি গুগল কুকি রয়েছে তবে এই কুকিটি ব্যবহার করে কোনও ট্র্যাকিং থেকে বেরিয়ে এসেছেন। 2 : কোনও বৈধ অপারেশন নির্দিষ্ট করা হয়নি। উদাহরণস্বরূপ, একটি নো-অপের অনুরোধ প্রাপ্ত হয়েছিল। 3 : ব্যবহারকারীর কোনও গুগল কুকি নেই। গুগল কুকি ম্যাচিং পরিষেবার মাধ্যমে কুকি সেট করবে না। 4 : বিবাদী অপারেশন নির্দিষ্ট করা হয়েছে। তাদের বিরোধী উদ্দেশ্য থাকার কারণে আপনাকে একই অনুরোধে google_push এবং google_cm উভয় পতাকা নির্দিষ্ট করার অনুমতি নেই। 5 : একটি অবৈধ google_push প্যারামিটার একটি দ্বি নির্দেশমূলক পিক্সেল ম্যাচিং অনুরোধের অংশ হিসাবে একটি গুগল সার্ভারে পুনঃনির্দেশে পাস করা হয়েছিল। আপনার পুনঃনির্দেশটি অবশ্যই প্রাথমিক পিক্সেল অনুরোধে আপনার কাছে পাস করা একই মানটিতে google_push সেট করতে হবে। 6 : ম্যাচ ট্যাগে একটি অবৈধ এনআইডি সরবরাহ করা হয়েছিল। 7 : একটি অবৈধ কুকি সনাক্ত করা হয়েছিল। 8 : অবমূল্যায়িত। কোনও কুকি পাওয়া যায় নি। 9 : কোনও কুকি পাওয়া যায় নি, একটি পরীক্ষা কুকি সেট করার চেষ্টা করা হয়। 10 : google_redir প্যারামিটারটি google_hm নির্দিষ্ট না করে ব্যবহার করা হয়েছিল, বা google_cm ছাড়াও ব্যবহৃত হয়েছিল। 15 : অনুরোধটি এমন একটি অঞ্চল থেকে এসেছে যেখানে গুগলের ম্যাচ টেবিলটি গুগল দ্বারা হোস্ট করা প্রয়োজন। ফলস্বরূপ, এই প্রতিক্রিয়াটিতে গুগল ব্যবহারকারী আইডি থাকে না।
google_hm	গুগল-হোস্টেড ম্যাচ টেবিলটিতে লেখার প্রচেষ্টা ব্যর্থ হলে কেবল তখনই উপস্থিত হয়। যখন এটি ঘটে তখন এর মান নিম্নলিখিত স্থিতি কোডগুলির মধ্যে একটি: 1 - নিষিদ্ধ: গ্রাহকের হোস্টেড ম্যাচ টেবিল এন্ট্রি লেখার অ্যাক্সেস নেই। 2 - ডিকোড ত্রুটি: প্যারামিটারের মানটি ডিকোড করা যায়নি। 3 - পে -লোড খুব দীর্ঘ: প্যারামিটারের মান 40 টিরও বেশি বাইটে ডেটা ডিকোড করা হয়েছে। 4 - অভ্যন্তরীণ ত্রুটি: ডেটা সংরক্ষণ করার অভ্যন্তরীণ ত্রুটি ছিল। 5 - থ্রোটলড: থ্রোটলিংয়ের কারণে এই লেখাটি প্রক্রিয়া করা হয়নি।
google_ula	ব্যবহারকারীর তালিকার স্থিতি অপারেশন যুক্ত করুন, অনুরোধে একাধিক google_ula নির্দিষ্ট করা থাকলে পুনরাবৃত্তি করুন। বিন্যাস হল: userlistid,status code প্রাক্তন: google_ula=1234567890,0 google_ula অপারেশন নিম্নলিখিত স্থিতি কোডগুলির যে কোনওটি ফিরিয়ে দিতে পারে: 0 - কোনও ত্রুটি নেই। ব্যবহারকারী ব্যবহারকারীর তালিকায় যুক্ত করা হয়েছে। 2 - অনুমতি অস্বীকার। প্রদত্ত ব্যবহারকারী তালিকায় ব্যবহারকারীদের যুক্ত করার অনুমতি আপনার নেই। 5 - খারাপ ব্যবহারকারী তালিকা আইডি। সরবরাহিত ব্যবহারকারী তালিকা আইডি অবৈধ। 6 - বদ্ধ বৈশিষ্ট্য আইডি। সরবরাহিত ব্যবহারকারী তালিকা আইডি বন্ধ রয়েছে। 10 - অভ্যন্তরীণ ত্রুটি। কুকি ম্যাচিং পরিষেবাটি একটি অভ্যন্তরীণ ত্রুটির মুখোমুখি হয়েছে; আপনি আবার ব্যবহারকারীকে আবার ম্যাচ করার চেষ্টা করতে পারেন।

কুকি ম্যাচিং ওয়ার্কফ্লো উদাহরণ পরিস্থিতি

নিম্নলিখিত পরিস্থিতিগুলি বর্ণনা করে যে কুকি ম্যাচিংটি কোনও ওয়েব পৃষ্ঠা ব্রাউজ করার জন্য কোনও সাধারণ ব্যবহারকারীর জন্য দেখতে কেমন হতে পারে।

দৃশ্য 1: ব্যবহারকারী তাদের কুকিজ সাফ করে এবং একটি সাইট ব্রাউজ করে

জেন তাদের সমস্ত কুকিজের ক্যাশে সাফ করে। এরপরে তারা পরীক্ষা -নিরীক্ষা ডটকমের হোমপেজে যান।

এখানে যা ঘটে:

1. PERPLENEWS.COM রেন্ডার করে এবং গুগল (বিজ্ঞাপন পরিচালক) থেকে বিজ্ঞাপনগুলি কল করে।
2. যেহেতু এডি ইউনিট গতিশীল বরাদ্দের জন্য যোগ্য, গুগল রিয়েল-টাইম বিডিং পরিষেবার মাধ্যমে ফিনস্টডিএসপি এবং অন্যান্য দরদাতাদের বিড অনুরোধ প্রেরণ করে।
3. ফিনস্টডিএসপি -র বিডার অ্যাপ্লিকেশন বিডের অনুরোধটি গ্রহণ করে এবং প্রক্রিয়া করে এবং এর বিড প্রতিক্রিয়া প্রেরণ করে।
4. গুগল ফিনস্টডিএসপি -র প্রতিক্রিয়া সহ দরদাতাদের কাছ থেকে বিড প্রতিক্রিয়া গ্রহণ করে যা একটি ম্যাচ ট্যাগ (পিক্সেল) সহ একটি বিজ্ঞাপন নির্দিষ্ট করে।
5. ফিনস্টডিএসপি নিলাম জিতেছে। গুগল জেনকে ফাইনস্টডিএসপি -র বিজ্ঞাপন এবং ম্যাচ ট্যাগ পরিবেশন করে।
6. ম্যাচ ট্যাগটি গুগলের কুকি ম্যাচ পরিষেবাটিকে কল করে, google_nid এবং google_cm প্যারামিটারগুলি নির্দিষ্ট করে।
7. কুকি ম্যাচ পরিষেবাটি জেনের গুগল কুকি পড়ে এবং জেনের ব্রাউজারটিকে google_gid এবং google_cver প্যারামিটার সেটগুলির সাথে ফিনস্টডিএসপি -র কুকি ম্যাচিং ইউআরএল -তে একটি পুনঃনির্দেশ প্রেরণ করে।
8. জেনের ব্রাউজারটি ফিনেস্টডিএসপি -র কুকি ম্যাচের ইউআরএলে পুনর্নির্দেশটি লোড করে।
9. ফিনস্টডিএসপি -র কুকি ম্যাচিং এন্ডপয়েন্টটি পুনর্নির্দেশের অনুরোধটি প্রক্রিয়া করে, যার মধ্যে গুগল দ্বারা নির্ধারিত ইউআরএল পরামিতি এবং এইচটিটিপি শিরোনামে জেনের জন্য তাদের কুকি অন্তর্ভুক্ত রয়েছে। ফিনস্টডিএসপি এখন তাদের কুকির ম্যাপিংটি তাদের ম্যাচের টেবিলে google_gid সঞ্চয় করতে পারে।
10. ফিনস্টডিএসপি একটি অদৃশ্য 1x1 পিক্সেল দিয়ে পুনঃনির্দেশকে সাড়া দেয়।

দৃশ্য 2: বিদ্যমান ম্যাপিং সহ ব্যবহারকারী

দৃশ্য 1 এর এক সপ্তাহ পরে, জেন আবার এক্সপ্লিনিউজ ডটকম পরিদর্শন করে। এখন যে জেন তাদের মেশিনে বিডার এবং অ্যাড ম্যানেজার কুকিজ উভয়ই রয়েছে, এখানে ম্যাচিং কীভাবে কাজ করে তা এখানে।

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

বিডার-উদ্যোগী: একমুখী কুকি ম্যাচিং

একমুখী কুকি ম্যাচিং দ্বি -নির্দেশমূলক কর্মপ্রবাহের মতো, এটি কেবল গুগল হোস্ট করে এবং একটি ম্যাচের টেবিলটিকে পপুলেট করে এমন পরিবর্তন করা ব্যতীত। এটি এমন উদাহরণগুলিতে ব্যবহার করা যেতে পারে যেখানে দরদাতাকে তাদের নিজস্ব ম্যাচ টেবিলে গুগল ব্যবহারকারী আইডি হোস্ট করার অনুমতি দেওয়া হয় না। এই প্রবাহটি ব্যবহার করার জন্য, দরদাতাদের অবশ্যই গুগলকে ম্যাচ টেবিলটি হোস্ট করার অনুমতি দিতে হবে, গুগলের কুকি ম্যাচিং পরিষেবাটিতে অনুরোধগুলিতে google_cm আর নির্দিষ্ট করতে পারে না এবং ফলস্বরূপ তাদের নিজস্ব ম্যাচ টেবিলটি পপুলেশন করতে google_gid গ্রহণ করবে না। গুগল একবার ব্যবহারকারীর জন্য একটি ম্যাচ প্রতিষ্ঠা করার পরে, দরদাতারা তাদের নিজস্ব কুকি ডেটা ব্যবহার করে ব্যবহারকারী তালিকায় যুক্ত করতে পারেন। একইভাবে, এই ব্যবহারকারীদের জন্য বিডের অনুরোধগুলি গুগল ব্যবহারকারী আইডি বাদ দেবে, তবে হোস্ট করা ম্যাচের ডেটা অন্তর্ভুক্ত করবে। An example of the revised workflow is summarized in the following steps.

Note : This workflow is required for users from US states with privacy restrictions, but bidders may optionally adopt this workflow for other regions as well.

Step 1: Place the match tag directed to bidder's Cookie Matching URL

In order to initiate this flow, a bidder must place a match tag such that it renders in the user's browser. Unlike the workflow for users not from a US state with privacy restrictions, the match tag must direct the user's browser to your Cookie Matching URL. For example, with a Cookie Matching URL configured as https://ad.network.com/pixel , it would look like:

<img src="https://ad.network.com/pixel" />

When loading in the user's browser, it will request a pixel from the bidder's Cookie Matching URL. This request will contain their cookie in the HTTP header, which should be extracted for the next step.

Step 2: Redirect to Google's Cookie Matching service

The bidder's cookie matching endpoint must redirect to Google's Cookie Matching service, including the google_hm parameter populated with their web-safe base64-encoded cookie data. The redirect URL might look like the following:

https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_hm=HOSTED_MATCH_DATA

Step 3: User's browser is redirected to Google's Cookie Matching service

Google will receive a redirect containing the parameters you specified, in addition to Google's cookie in the HTTP headers.

Step 4: Google serves pixel on success or error redirect if report URL specified

If the cookie matching operation is successful—or if no Cookie Matching Report URL has been specified for the bidder's account—Google will serve a 1x1 transparent pixel by default, and the workflow will end here. Impressions for this user in subsequent bid requests will include the bidder's hosted match data in BidRequest.user.buyeruid . Bidders can also populate user lists using the hosted match data they specified.

Otherwise, if an error occurred, Google will send a redirect to the bidder's Cookie Matching Report URL with the cause of the error specified in the google_error parameter. If the bidder's Cookie Matching Report URL were https://ad.network.com/report , the redirect URL would look like:

<img src="https://ad.network.com/report?google_error=ERROR_ID" />

Note: Bidders may request that their account always receive redirects to their Cookie Matching Report URL, even for successful operations. To enable this, they may contact their Technical Account Manager.

Step 5: User's browser redirects to bidder's Cookie Matching Report URL

The user's browser will redirect to the bidder's Cookie Matching Report URL, including the error reason (if any) specified by Google in the google_error parameter. To learn more about interpreting the error code, see the parameter description .

Note : This step will only occur if the bidder's account is configured to send information about the operation's failure or success to a Cookie Matching Report URL.

Step 6: Bidder serves 1x1 transparent pixel

The bidder must respond by serving a 1x1 transparent pixel to the user's browser.

Note : This step will only occur if the bidder's account is configured to send information about the operation's failure or success to a Cookie Matching Report URL.

Cookie Matching workflow diagram for users from US states with privacy restrictions

The default workflow for users in US states with privacy restrictions is illustrated by the following diagram, where requests and responses are represented by an arrow, and the data items that accompany them are listed in parentheses.

URL Parameters for bidder redirect to Google's Cookie Matching service

প্যারামিটার	বর্ণনা
google_nid	Network ID (NID) for the bidder account. This ID can be retrieved through the Bidders resource.
google_sc	এই প্যারামিটারটি অবহেলিত। Sets Google's cookie for the user if one is not present. The value of the parameter is ignored and may be omitted. Omitting the parameter results in an error if no cookie exists.
google_no_sc	এই প্যারামিটারটি অবহেলিত। This indicates to Google's Cookie Matching Service that it shouldn't set a cookie for the user if one is not present. The value of the parameter is ignored and may be omitted.
google_hm	Contains data that the bidder wants to store in a Google-hosted match table. Note: The value is a web-safe base64-encoded string (padding optional) that must not exceed 40 bytes. For example, this might look like: Q29va2llIG51bWJlciAxIQ== .
google_redir	An encoded URL that you want Google to send an HTTP 302 redirect. The specified URL will receive redirects with the google_error parameter for both errors and successful operations.
google_ula	A string used to add the user to an existing user list. The value's expected format is userlistid[,timestamp] : userlistid : a single numerical user list ID. timestamp : an optional timestamp in POSIX format, indicates when the user has been added to the user list. This URL parameter may be repeated to add the user to multiple lists.
gdpr	Indicates that the request is subject to GDPR restrictions on data usage. For more detail, see EU user consent requirements , or Impact on cookie match eligibility in the Authorized Buyers IAB TCF v2.0 documentation . Example: gdpr=1
gdpr_consent	A TC string that represents the end-user consent. For more detail, see EU user consent requirements , or How will the TC string be passed? in the Authorized Buyers IAB TCF v2.0 documentation .
process_consent	Indicates that the bidder has obtained end-user consent for the data uses specified in Google's EU User Consent Policy . If the request is not subject to the EU User Consent Policy, or if there are other consent parameters available on the request ( gdpr_consent ), this parameter is ignored. Example: process_consent=T

URL Parameters for Google redirect to Bidder's Cookie Matching Report URL

প্যারামিটার

বর্ণনা

google_error

An integer value indicating the overall request error. When received, it indicates that no operations have been performed, and no other google_ response parameters will be set. The supported error values include the following: 1 : User has a Google cookie, but has opted out of any tracking using this cookie. 2 : No valid operations specified. for example, a no-op request was received. 3 : User does not have a Google cookie. Google won't set the cookie through the Cookie Matching Service. 4 : Conflicting operations specified. You are not allowed to specify both the google_push and google_cm flags on the same request since they have conflicting purposes. 5 : An invalid google_push parameter was passed in a redirect to a Google server as part of a bidirectional Pixel Matching request. Your redirect must set google_push to the same value passed to you in the initial pixel request. 6 : An invalid NID was supplied in the match tag. 7 : An invalid cookie was detected. 8 : Deprecated. No cookie found. 9 : No cookie found, an attempt to set a test cookie is made. 10 : The google_redir parameter was used without google_hm being specified, or was used in addition to google_cm . 15 : The request comes from a region where Google requires the match table to be hosted by Google. As a result, this response does not contain a Google User ID.

Google-initiated: Bidirectional Pixel Matching

Bidirectional Pixel Matching is a workflow for Google's Cookie Matching Service where Google attempts to match a Google User ID with an algorithmically selected bidder other than the Real-Time Bidding auction winner. When an ad is placed, Google will place a match tag directing the user's browser to load a transparent pixel from the chosen bidder's Cookie Matching URL. This will enable both Google and the bidder to populate a match table with a given user. The following is an example of this workflow.

Step 1: Google places a match tag

When a participating publisher's page loads in the user's browser, and an ad slot on that page is filled by Google, a match tag may be placed that requests a pixel from an algorithmically selected bidder. The Pixel Matching tag placed by Google combines the bidder's Cookie Matching URL with additional parameters the bidder can use to populate their match table. For a Cookie Matching URL specified as https://ad.network.com/pixel , it is structured as follows:

<img src="https://ad.network.com/pixel?google_gid=GOOGLE_GID&google_cver=1&google_push=PUSH_DATA" />

Step 2: Bidder must respond with redirect to Google's Cookie Matching Service URL

Bidders receiving pixel matching requests are required to respond with a redirect to Google's Cookie Matching Service that is structured as follows:

https://cm.g.doubleclick.net/pixel?google_nid=GOOGLE_NID&google_push=PUSH_DATA

Note that the preceding redirect URL is similar to that of the URL used in the match tag for the Bidder-Initiated Cookie Matching Workflow . In Pixel Matching, the google_cm parameter is replaced by the google_push parameter, and its value must be equal to the value provided by Google in the request. Also similar to the bidder-initiated workflow, additional parameters can be specified to fulfill additional use cases.

Warning: the google_cm and google_push parameters should never appear in the same request to Google's Cookie Matching Service.

Step 3: Google processes redirect and responds with pixel

Google logs that a match has been created for the user, and handles any additional operations requested through query parameters Finally, Google responds with a 1x1 transparent pixel.

Pixel Matching workflow diagram

This workflow is illustrated by the following diagram, where requests and responses are represented by an arrow, and the data items that accompany them are listed in parentheses.

Google match tag request parameters

প্যারামিটার	বর্ণনা
google_gid	Google User ID. For users not from a US state with privacy restrictions, this will always be specified in Google's match tag.
google_cver	The cookie version. This will always be specified in Google's match tag.
google_push	Indicates that this request is initiating the Pixel Matching workflow. The value must be returned through the corresponding parameter in the bidder's redirect response.
gdpr_consent	A TC string that represents the end-user consent. For more detail, see [EU user consent requirements](/authorized-buyers/rtb/cookie-guide#eu-user-consent-requirements), or **How will the TC string be passed?** in the [Authorized Buyers IAB TCF v2.0 documentation](//support.google.com/authorizedbuyers/answer/9789378).

Bidder Pixel Matching redirect parameters

প্যারামিটার	বর্ণনা
google_nid	Network ID (NID) for the bidder account. This ID can be retrieved through the Bidders resource.
google_push	Indicates that this redirect is completing the Pixel Matching workflow. The value from the corresponding Google match tag must be specified here.
google_hm	Contains data that the bidder wants to store in a Google-hosted match table. Note: The value is a web-safe base64-encoded string (padding optional) that must not exceed 40 bytes. For example, this might look like: Q29va2llIG51bWJlciAxIQ== .
google_ula	A string used to add the user to an existing user list. The value's expected format is userlistid[,timestamp] : userlistid : a single numerical user list ID. timestamp : an optional timestamp in POSIX format, indicates when the user has been added to the user list. This URL parameter may be repeated to add the user to multiple lists.
gdpr_consent	A TC string that represents the end-user consent. For more detail, see [EU user consent requirements](/authorized-buyers/rtb/cookie-guide#eu-user-consent-requirements), or **How will the TC string be passed?** in the [Authorized Buyers IAB TCF v2.0 documentation](//support.google.com/authorizedbuyers/answer/9789378).

Google-initiated: Unidirectional Pixel Matching

Unidirectional Pixel Matching differs from the Bidirectional workflow in that Google's match tag does not include a parameter specifying the Google User ID, but will continue to populate a Google-hosted match table. This can be used in instances where the bidder is not permitted to host Google User IDs in their own match table. An example of the revised workflow is summarized in the following steps.

Note : This workflow is required for users from US states with privacy restrictions, but bidders may optionally adopt this workflow for other regions as well.

Step 1: Google places a match tag

Google places a match tag for an algorithmically selected bidder. The match tag includes the google_push parameter. এখানে একটি উদাহরণ:

<img src="https://ad.network.com/pixel?google_push=PUSH_DATA" />

Step 2: User's browser requests pixel from bidder's Cooking Matching URL

The user's browser requests a pixel from the bidder's Cookie Matching URL, including the bidder's cookie in the HTTP headers.

Step 3: Redirect to Google's Cookie Matching Service

The bidder's cookie matching endpoint must redirect to Google's Cookie Matching service, including the google_hm parameter populated with their web-safe base64-encoded cookie data. The redirect URL might look like the following:

https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_hm=HOSTED_MATCH_DATA&google_push=PUSH_DATA

Step 4: User's browser is redirected to Google's Cookie Matching service

Google will receive a redirect containing the parameters you specified, in addition to Google's cookie in the HTTP headers. If the operation was successful, impressions for this user in subsequent bid requests will include the bidder's hosted match data in BidRequest.user.buyeruid . Bidders can also populate user lists using the hosted match data they specified.

Finally, Google returns a 1x1 transparent pixel to the user's browser.

Cookie Match Assist

Open Bidding allows exchanges to use bidder initiated and Google initiated cookie matching workflows, to match a Google User ID with their cookie. Cookie Match Assist (CMA) is an additional feature for exchanges that enables them to build match tables with their own bidders.

How Cookie Match Assist works

1. When placing an ad, Google algorithmically selects a participating exchange and places a Cookie Match Assist tag that has the following structure:

   <img src="https://ob.exchange.com/pixel?google_gid=GOOGLE_GID&google_cver=1"/>

   Caution: For users from US states with privacy restrictions, Cookie Match Assist won't include the google_gid parameter.

2. Google's CMA match tag causes the exchange's Cookie Matching URL to receive a pixel request.

   Note: Unlike the Google-initiated workflows, this excludes the google_push parameter.
3. The exchange's Cookie Matching endpoint receives the request, where its own cookie matching service is responsible for matching the user ID with one of its bidders. In the following diagram, the exchange's cookie matching service responds to the user's browser with a redirect to one of its bidder's endpoints.
4. The bidder receives the request, along with any parameters specified by the exchange to match the user ID with their cookie.

Note: Depending on the exchange's implementation, an additional redirect from the bidder to the exchange could be used to set the cookie in a match table hosted by the exchange.

বিধিনিষেধ

Cap frequency of requests for fresh matches

Bidders are responsible for limiting the number of calls to the Cookie Matching service for users who have a fresh entry in the Google-hosted match table. An entry in the hosted match table may be considered expired in 14 days, after which it can be refreshed.

Warning: Google does not enforce frequency capping at serving time. However, it does periodically monitor that you are respecting the frequency capping policy, and reserves the right to interrupt the service in case of violation.

Respond to all pixel match requests

Bidders using the Pixel Matching workflow are expected to respond to all incoming Pixel Match requests with a response including the google_push parameter. This allows Google to enforce policies by monitoring usage. If a bidder's response rate is less than 90%, Google will throttle the number of Pixel Match requests sent to their account.

Use HTTPS endpoints

It is required that endpoints used in all Cookie Matching workflows use HTTPS.

When responding to a Pixel Match request sent to you over HTTPS, you are required to redirect to the Cookie Matching Service over HTTPS. Likewise, a Cookie Match Assist endpoint that redirects to bidders must also use HTTPS. If you send requests to Google over HTTP more often than once every 2 minutes, the number of match requests sent to your account will be throttled.

EU user consent requirements

Cookie Matching requests that are subject to Google's EU User Consent Policy should indicate end-user consent. Such requests are required to indicate that consent has been gathered using one of the following ways:

• TCFv2: This includes gdpr and gdpr_consent parameters. For details, consult the Authorized Buyers IAB TCF v2.0 documentation .
• process_consent : a declaration that the bidder has obtained necessary user consent.

উদাহরণ

The following examples illustrate how to use the Cookie Matching service to accomplish specific objectives. Note that unless stated otherwise, it is assumed that the user being acted upon is not from a US state with privacy restrictions.

Populate a bidder-hosted match table

A bidder can use the Cookie Matching workflow to populate their own match table by providing only the google_nid and google_cm parameters in their match tag. এটি দেখতে এরকম হতে পারে:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_cm" />

If the bidder's Cookie Matching URL is set to https://ad.network.com/pixel?id=1 , and the cookie matching operation is successful, the redirect Google sends in response to the bidder's match tag might look like:

https://ad.network.com/pixel?id=1&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1

If the cookie matching operation fails because the user does not have a Google cookie, the response would be:

https://ad.network.com/pixel?id=1&google_error=3

The error code is dependent on the underlying cause of the error. To learn more about possible error codes for the Cookie Matching workflow, see the redirect URL parameters .

Note: The bidder-defined parameter id seen in the match tag is passed along as-is when Google redirects to the bidder's Cookie Matching URL.

Add to single user list

The google_ula parameter can be specified in a bidder's match tag to add the user to a user list with the given ID. If the Google or bidder-hosted match table has a fresh entry for the user, the bidder can place a match tag including the google_nid and google_ula parameters to add the user to the specified list without initiating the full Cookie Matching workflow. See the restrictions on invoking the Cookie Matching Service for more deails. The corresponding match tag may look like:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345" />

For a successful response, where the bidder's Cookie Matching URL is https://ad.network.com/pixel , Google's redirect URL would be:

https://ad.network.com/pixel?google_ula=12345,0

Key Point: The value of google_ula is 12345,0 , indicating that the user should be added to a user list with ID 12345 , and in this case the timestamp is set to 0 to indicate that it is being left unspecified. Alternatively, just the user list ID could have been provided.

If there is an overall error— for example, there is no Google cookie for the user— the redirect URL will include the google_error parameter:

• https://ad.network.com/pixel?google_error=3

If there is an error specifically concerning adding the user to the list, you will receive google_ula in the redirect. Unlike the corresponding match tag parameter, this replaces the timestamp with a status code to indicate the operation's success. For example, if the request failed because the bidder account didn't have access to the specified user list, the redirect URL would be:

https://ad.network.com/pixel?google_ula=12345,2

Add to multiple user lists

Bidders can specify that a user should be added to multiple user lists by including multiple google_ula parameters in the match tag. In practice, this may look like:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345,7654321&google_ula=45678" />

The status of the operation for each user list is similarly reported through distinct google_ula parameters in the redirect:

https://ad.network.com/pixel?google_ula=12345,2&google_ula=45678,0

In the preceding redirect, we can see that the operation succeeded for the user list with ID 45678 , but failed for user list ID 12345 because the bidder didn't have permission to access it.

Step through Cookie Matching workflow and add to user list

To perform cookie matching and add the user to a user list in a single request, a bidder's match tag should include google_cm and google_ula :

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345&google_cm" />

The redirect URL specified by Google would include google_gid , google_cver , and google_ula . এটি নিম্নলিখিত মত দেখতে পারে:

https://ad.network.com/pixel?id=&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1&google_ula=12345,0

Store a match in a Google-hosted match table

If a bidder wants to store their cookie data in a Google-hosted match table, and does not intend to store match with the Google User ID in their own match table, their match tag must include the google_hm parameter where its value must be a web-safe base64-encoded string. For a user where the bidder's unencoded cookie data is Cookie number 1! , the encoded value would be Q29va2llIG51bWJlciAxIQ== , which would be used in a match tag like the following:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D" />

For a successful response, where the bidder's Cookie Matching URL is https://cookie-monster.com/pixel , Google's redirect URL would be:

https://cookie-monster.com/pixel

The google_gid parameter is not in the redirect because the match tag did not include google_cm , and google_hm is not included in successful responses. In future bid requests for impressions for this user, the bidder will receive their hosted match data in BidRequest.user.buyeruid .

If the bidder instead used a match tag where the value of google_hm was not base64-encoded—such as chocolate_chunk! —the redirect URL might look like the following:

https://cookie-monster.com/pixel?google_hm=2

The preceding redirect URL includes a google_hm value of 2 , suggesting that the operation failed because the value couldn't be decoded.

Bidder and Google-hosted match tables with user lists

If a bidder hosts their own use list in addition to a Google-hosted user list, and wants a single match tag to match both tables and add the user to a given user list, their match tag must include the google_cm , google_hm , and google_ula parameters. If the bidder's cookie data is Cookie number 1! , the encoded value would be Q29va2llIG51bWJlciAxIQ== , which would produce a match tag like the following:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D&google_cm&google_ula=12345" />

For a successful response, where the bidder's Cookie Matching URL is https://cookie-monster.com/pixel , Google's redirect URL would look like the following:

https://cookie-monster.com/pixel?google_gid=ABCDETC&google_cver=1&google_ula=12345,0

On receiving the redirect, the bidder can match the Google User ID specified in google_gid with their cookie data in their match table. In addition, they can determine that the Google-hosted match table and user list operations were successful. As a consequence, any Pretargeting the bidder configured to target the specified user list ID will now cause the bidder to receive bid requests for impressions from the user. Likewise, in these bid requests, the bidder will receive their hosted match data in BidRequest.user.buyeruid .

,

Cookie Matching is a feature that lets you match your cookie—for example, an ID for a user that browsed your website—with a corresponding bidder-specific Google User ID, and construct user lists that can help you make more effective bidding choices. This guide describes concepts used in Cookie Matching, as well as different Cookie Matching workflows, and any variations they may have for certain use cases.

Key Point: In order to access cookie matching features, you must contact your Account Manager to configure your account. The remainder of this guide assumes this has already been done.

ধারণা

What is Cookie Matching?

Domain owners typically set the contents of cookies for users that browse their site, which are used to identify users within that domain. Even if two domain owners would otherwise agree to exchanging this data, the security model of internet browsers restricts one from reading a cookie set by another domain.

In the context of digital advertising, Google identifies users with cookies that belong to the doubleclick.net domain, and bidders participating in Real-Time Bidding may have their own domain where they identify some set of users they would like to show ads. Cookie Matching enables the bidder to match their cookies with Google's, such that they can determine whether an impression sent in a bid request is associated with one of users being targeted, they will receive either their own cookie data or a bidder-specific Google User ID that is an encrypted form of the doubleclick.net cookie in the bid request.

The cookie matching service described in this guide facilitates the creation and maintenance of the association between a bidder's cookie and the Google User ID, and also allows one to populate user lists.

Match tables

A match table can be used to map an ID or other data from one domain to another. Bidders can use the Cookie Matching Service to populate their own match tables by mapping their cookie for a given user to the user's Google User ID, or to populate a match table hosted by Google. Match tables are necessary for a bidder's bidder application to access cookie data for the user being shown the impression.

Google-hosted match tables

For easier maintenance, latency improvements, and access to match data for users in certain regions, it is recommended that you allow Google to host your match table. This lets you specify a web-safe base64-encoded string — hereafter referred to as hosted match data—that will be mapped to the Google User ID for a given user. Once a match has been established, it can be used in the following ways:

• Real-Time Bidding : In subsequent bid requests for impressions associated with the user, Google will send you the hosted match data you matched with their Google User ID. Google will specify BidRequest.user.buyeruid as a web-safe base64-encoded string.

  Key Point: For users detected to originate from US states with privacy restrictions, the Google User ID won't be specified in the bid request. You will still receive your hosted match data, which can be used to inform your bidding logic.
  Caution: By default, the value in buyeruid is a web-safe base64-encoded string, and should be equivalent to what you send in google_hm . If you are receiving unexpected buyeruid values in the bid request, it may indicate that you are sending an unencoded google_hm value. To disable encoding in the bid request, contact your Technical Account Manager.

• User Lists : User lists can be populated with either Google User IDs or hosted match data.

  Caution: For users detected to originate from US states with privacy restrictions, using a Google User ID to populate user lists is deprecated, and will eventually be sunset. It is recommended that bidders populate user lists with their hosted match data for these users.
• Pretargeting : You can configure your pretargeting such that you only receive bid requests containing hosted match data. This can be used to eliminate less relevant impressions for users outside of your cookie space.

ব্যবহারকারীর তালিকা

User lists can be created and managed with the Real-Time Bidding API . Once created, you can populate these lists with the following Cookie Matching workflows, or through the Bulk Uploader Service .

Key Point: User lists can be populated with both Google User IDs and hosted match data, and intermixing these is possible. Note that when specifying the latter, they must have already been added to a Google-hosted match table. For users from US states with privacy restrictions, you must use modified workflows that add hosted match data to user lists rather than the Google User ID.

শুরু করা

In order to get started with Cookie Matching, you must contact your Technical Account Manager, who can enable specific workflows and help you configure the following:

• Cookie Matching Network ID (NID) : A string ID uniquely identifying a bidder account for Cookie Matching and other related operations.
• Cookie Matching URL : The base URL for an endpoint that will accept and handle incoming requests as part of the Cookie Matching workflows. Bidders can embed macros in this URL to control the ordering of parameters passed to it in Cookie Matching workflows.
• Match Tag : The tag you must place in a user's browser for the bidder-initiated Cookie Matching workflow. This can be served alongside ads, or placed on web properties outside of ads.
• Cookie Matching Report URL (optional): In the Unidirectional Cookie Matching Workflow, this is an optional URL that can be provided to specify an endpoint that will receive error details in the event that cookie matching fails through an HTTP 302 redirect. By default, responses will only be sent to this URL if there was an error with the cookie matching operation, but bidder's may request that the redirect always be sent.
• Cookie Match Assist URL : For exchanges implementing the Cookie Match Assist workflow , this is the base URL of the endpoint intended to respond to incoming requests.
• Cookie Match Assist Quota : For exchanges implementing the Cookie Match Assist workflow , this is the maximum number of requests that their Cookie Matching URL can receive every second. This is intended to prevent CMA requests from overloading the exchange's servers with requests.

Note: Authorized Buyers can view the Cookie Matching NID and URL configured for their accounts with the Bidders resource.

Cookie matching macros

In any of the supported Cookie Matching workflows , a bidder's Cookie Matching URL typically has parameters appended in a non-guaranteed ordering. Bidders with integrations requiring consistent ordering of parameters can place macros in their Cookie Matching URL to indicate their placement.

Supported macros

Bidders can optionally configure their Cookie Matching URL to include one or more macros in the form of either %%GOOGLE_<PARAM_NAME>%% or %%GOOGLE_<PARAM_NAME>_PAIR%% . The supported macros and their expanded values are:

ম্যাক্রো	Expanded value
GOOGLE_GID	GOOGLE_USER_ID
GOOGLE_GID_PAIR	&google_gid= GOOGLE_USER_ID
GOOGLE_CVER	COOKIE_VERSION_NUMBER
GOOGLE_CVER_PAIR	&cver= COOKIE_VERSION_NUMBER
GOOGLE_ERROR	ERROR_ID
GOOGLE_ERROR_PAIR	&google_error= ERROR_ID
GOOGLE_PUSH	PIXEL_MATCH_DATA
GOOGLE_PUSH_PAIR	&google_push= PIXEL_MATCH_DATA
GOOGLE_ALL_PARAMS	google_gid= GOOGLE_USER_ID &cver= COOKIE_VERSION_NUMBER &google_error= ERROR_ID

ম্যাক্রো উদাহরণ

A bidder has a cookie matching integration with an endpoint hosted at https://user.bidder.com/cookies , and their implementation requires preset bidder-defined parameters in addition to Pixel Matching parameters in the following order: google_push , google_gid , google_cver , and google_error . The bidder can accomplish this by setting their Cookie Matching URL to:

https://user.bidder.com/cookies?w=0%%GOOGLE_PUSH_PAIR%%&x=1%%GOOGLE_GID_PAIR%%&y=2%%GOOGLE_CVER_PAIR%%&z=3%%GOOGLE_ERROR_PAIR%%

When Google later sends a match request to this bidder, it will be expanded to something like the following:

https://user.bidder.com/cookies?w=0&google_push=PUSH_DATA&x=1&google_gid=GOOGLE_GID&y=2&google_cver=1&z=3

Note: The google_error parameter is not populated in Google's match tag for the Pixel Matching workflow, and so is excluded.

Cookie Matching Service workflows

Google's Cookie Matching Service supports the following three workflows.

Bidder-initiated: Bidirectional Cookie Matching

Bidirectional Cookie Matching refers to a bidder-initiated workflow, where they place a match tag in the user's browser that directs it to Google. This workflow allows both Google and the bidder to populate match tables. The following is an example of this workflow.

Step 1: Place the match tag

In order to initiate this flow, the bidder must place their match tag such that it renders in the user's browser. A match tag that only returns the Google User ID to the bidder may be structured as follows:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm" />

Note: The BIDDER_ACCOUNT_NID should be replaced by the NID for the bidder account. This is provided by Technical Account Managers during configuration of cookie matching for a bidder account, and can also be viewed with the Real-time Bidding API's Bidders resource .

There are additional parameters you can include in the match tag to fulfill different use cases. To learn more about these parameters, see Match Tag URL Parameters .

Step 2: Google responds with redirect including match data

The match tag will cause Google's Cookie Matching Service to receive a request from the user's browser, which will issue an HTTP 302 redirect to the bidder's Cookie Matching URL. The redirect will include query parameters specifying the Google User ID and its version number in the URL, and the bidder will also receive their cookie included in the request headers. In practice, for a cookie matching URL specified as https://ad.network.com/pixel , the redirect URL for the previous match tag could look like the following:

https://ad.network.com/pixel?google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1

The Google User ID passed through the google_gid parameter is an unpadded web-safe base64-encoded string. For bidders choosing to host a match table, it is recommended that they store the exact string returned by the Cookie Matching Service. In subsequent bid requests, this will correspond to values specified through BidRequest.user.id .

The version specified in google_cver indicates the numeric version number for the Google User ID. The Google User ID for a given user will infrequently change, after which this will be incremented.

If Google encounters an error while processing your match request, a google_error parameter will instead be specified.

Step 3: Bidder processes redirect and responds with pixel

The bidder receives a redirect to their cookie matching URL including parameters they specified in the first step, and those Google provided in the second step. In addition, they will also receive their cookie in the HTTP headers. If the operation was successful, a bidder hosting their own match table could match their cookie to the Google User ID included in the response. It is recommended that bidders store the exact string returned by the Cookie Matching Service.

If the operation was unsuccessful, the bidder will receive a google_error parameter in the redirect. This is a numeric value corresponding to different error states that identify the particular error that occurred. You can learn more about the possible error values in the description of the google_error URL parameter. If you receive an error, you may attempt to match for that user again by placing a new match tag.

The bidder must always respond by serving a 1x1 invisible pixel image, or alternatively return an HTTP 204 No Content response.

Cookie Matching workflow diagram

This workflow is illustrated by the following diagram, where requests and responses are represented by an arrow, and the data items that accompany them are listed in parentheses.

Match Tag URL Parameters

প্যারামিটার	বর্ণনা
google_nid	Network ID (NID) for the bidder account. This ID can be retrieved through the Bidders resource.
google_cm	Indicates to Google's Cookie Matching Service that it should perform cookie matching. The value of the parameter is ignored and may be omitted.
google_sc	এই প্যারামিটারটি অবহেলিত। Sets Google's cookie for the user if one is not present. The value of the parameter is ignored and may be omitted. Omitting the parameter results in an error if no cookie exists.
google_no_sc	এই প্যারামিটারটি অবহেলিত। This indicates to Google's Cookie Matching Service that it shouldn't set a cookie for the user if one is not present. The value of the parameter is ignored and may be omitted.
google_hm	Data the bidder wants to store in a Google-hosted match table. The value is a web-safe base64-encoded string (padding optional). The raw data must be 40 bytes or less. For example, Q29va2llIHRoYXQgaXMgdW5kZXIgNDAgdG90YWwgYnl0ZXMuLi4u .
google_redir	A URL-encoded string that a bidder can specify if they want to direct Google to send the HTTP 302 redirect to the encoded URL for this match tag. This allows Google to be placed at the front in a chained call to partners. This will result in an error if specified without google_hm , or with google_cm .
google_ula	A string used to add the user to an existing user list. The value's expected format is userlistid[,timestamp] : userlistid : a single numerical user list ID. timestamp : an optional timestamp in POSIX format, indicates when the user has been added to the user list. This URL parameter may be repeated to add the user to multiple lists.
gdpr	Indicates that the request is subject to GDPR restrictions on data usage. For more detail, see EU user consent requirements , or Impact on cookie match eligibility in the Authorized Buyers IAB TCF v2.0 documentation . Example: gdpr=1
gdpr_consent	A TC string that represents the end-user consent. For more detail, see EU user consent requirements , or How will the TC string be passed? in the Authorized Buyers IAB TCF v2.0 documentation .
process_consent	Indicates that the bidder has obtained end-user consent for the data uses specified in Google's EU User Consent Policy . If the request is not subject to the EU User Consent Policy, or if there are other consent parameters available on the request ( gdpr_consent ), this parameter is ignored. Example: process_consent=T

In addition to the earlier parameters, bidders may specify their own, which will be appended as parameters to the redirect URL. Note that bidder-defined parameters named with the google_ prefix will be ignored because those are reserved by Google for future development, and preservation of the parameters' ordering is not guaranteed. A match tag including bidder-defined parameters may look like:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm&extra1=xx&extra2=yy" />

Redirect URL Parameters

The redirect URL is built from the base Cookie Matching URL configured for a bidder's account, including google_ and bidder-defined parameters depending on those specified in the match tag. The following google_ response parameters are defined:

প্যারামিটার	বর্ণনা
google_gid	Google User ID. Set if google_cm is specified in the request and the request was successful.
google_cver	Cookie version. Set if google_cm is specified in the request and the request was successful.
google_error	An integer value indicating the overall request error. When received, it indicates that no operations have been performed, and no other google_ response parameters will be set. The supported error values include the following: 1 : User has a Google cookie, but has opted out of any tracking using this cookie. 2 : No valid operations specified. for example, a no-op request was received. 3 : User does not have a Google cookie. Google won't set the cookie through the Cookie Matching Service. 4 : Conflicting operations specified. You are not allowed to specify both the google_push and google_cm flags on the same request since they have conflicting purposes. 5 : An invalid google_push parameter was passed in a redirect to a Google server as part of a bidirectional Pixel Matching request. Your redirect must set google_push to the same value passed to you in the initial pixel request. 6 : An invalid NID was supplied in the match tag. 7 : An invalid cookie was detected. 8 : Deprecated. No cookie found. 9 : No cookie found, an attempt to set a test cookie is made. 10 : The google_redir parameter was used without google_hm being specified, or was used in addition to google_cm . 15 : The request comes from a region where Google requires the match table to be hosted by Google. As a result, this response does not contain a Google User ID.
google_hm	Only appears if the attempt to write to the Google-hosted match table fails. When that happens, its value is one of the following status codes: 1 - Forbidden: The customer doesn't have access to write hosted match table entries. 2 - Decode error: The parameter value couldn't be decoded. 3 - Payload too long: The parameter value decoded into more than 40 bytes of data. 4 - Internal error: There was an internal error storing the data. 5 - Throttled: This write was not processed due to throttling.
google_ula	Status of user list add operation, repeated if multiple google_ula were specified in the request. বিন্যাস হল: userlistid,status code Ex: google_ula=1234567890,0 The google_ula operation can return any of the following status codes: 0 - No error. The user has been added to the user list. 2 - Permission denied. You don't have permission to add users to the given user list. 5 - Bad user list ID. The supplied user list ID is invalid. 6 - Closed attribute ID. The supplied user list ID is closed. 10 - Internal error. The Cookie Matching service has encountered an internal error; you can try re-matching the user again.

Cookie Matching workflow example scenarios

The following scenarios describe what cookie matching might look like for a typical user browsing a web page.

Scenario 1: User clears their cookies and browses a site

Jane clears their cache of all cookies. They then visit the homepage of ExampleNews.com.

এখানে যা ঘটে:

1. ExampleNews.com renders, and calls ads from Google (Ad Manager).
2. Because the ad unit is eligible for dynamic allocation, Google sends bid requests to FinestDSP and other bidders through the Real-Time Bidding service.
3. FinestDSP's bidder application receives and processes the bid request, and sends its bid response.
4. Google receives bid responses from bidders, including FinestDSP's response that specifies an ad with a match tag (pixel).
5. FinestDSP wins the auction. Google serves FinestDSP's ad and match tag to Jane.
6. The match tag calls Google's Cookie Match Service, specifying the google_nid and google_cm parameters.
7. The Cookie Match Service reads Jane's Google cookie, and sends Jane's browser a redirect to FinestDSP's Cookie Matching URL with the google_gid and google_cver parameters set.
8. Jane's browser loads the redirect to FinestDSP's Cookie Match URL.
9. FinestDSP's cookie matching endpoint processes the redirect request, which includes URL parameters set by Google, and their cookie for Jane in the HTTP headers. FinestDSP can now store the mapping of their cookie to the google_gid in their match table.
10. FinestDSP responds to the redirect with an invisible 1x1 pixel.

Scenario 2: User with existing mapping

A week after Scenario 1, Jane visits ExampleNews.com again. Now that Jane has both bidder and Ad Manager cookies on their machine, here's how matching works.

1. The web page renders, causing Google (Ad Manager) to request ads that will be rendered on the page.
2. During the ad auction, Google sends a bid request to applicable bidders, including FinestDSP.
3. FinestDSP receives the bid request, including signals such as the google_gid .
4. FinestDSP looks up the google_gid in its match table, and finds the cookie associated with Jane that was created a week earlier (in Scenario 1).
5. Based on information associated with the cookie, FinestDSP's bidding logic places a bid on the impression, and wins the auction.
6. Jane might see an ad tailored to their interests, based on information that FinestDSP possesses.

Bidder-initiated: Unidirectional Cookie Matching

Unidirectional Cookie Matching is similar to the Bidirectional workflow, except that it is altered such that only Google hosts and populates a match table. This can be used in instances where the bidder is not permitted to host Google User IDs in their own match table. In order to use this flow, bidders must allow Google to host the match table, can no longer specify google_cm in requests to Google's Cookie Matching Service, and will consequently not receive google_gid to populate their own match table. Once Google has established a match for a user, bidders can add them to user lists using their own cookie data. Similarly, bid requests for these users will exclude the Google User ID, but include hosted match data. An example of the revised workflow is summarized in the following steps.

Note : This workflow is required for users from US states with privacy restrictions, but bidders may optionally adopt this workflow for other regions as well.

Step 1: Place the match tag directed to bidder's Cookie Matching URL

In order to initiate this flow, a bidder must place a match tag such that it renders in the user's browser. Unlike the workflow for users not from a US state with privacy restrictions, the match tag must direct the user's browser to your Cookie Matching URL. For example, with a Cookie Matching URL configured as https://ad.network.com/pixel , it would look like:

<img src="https://ad.network.com/pixel" />

When loading in the user's browser, it will request a pixel from the bidder's Cookie Matching URL. This request will contain their cookie in the HTTP header, which should be extracted for the next step.

Step 2: Redirect to Google's Cookie Matching service

The bidder's cookie matching endpoint must redirect to Google's Cookie Matching service, including the google_hm parameter populated with their web-safe base64-encoded cookie data. The redirect URL might look like the following:

https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_hm=HOSTED_MATCH_DATA

Step 3: User's browser is redirected to Google's Cookie Matching service

Google will receive a redirect containing the parameters you specified, in addition to Google's cookie in the HTTP headers.

Step 4: Google serves pixel on success or error redirect if report URL specified

If the cookie matching operation is successful—or if no Cookie Matching Report URL has been specified for the bidder's account—Google will serve a 1x1 transparent pixel by default, and the workflow will end here. Impressions for this user in subsequent bid requests will include the bidder's hosted match data in BidRequest.user.buyeruid . Bidders can also populate user lists using the hosted match data they specified.

Otherwise, if an error occurred, Google will send a redirect to the bidder's Cookie Matching Report URL with the cause of the error specified in the google_error parameter. If the bidder's Cookie Matching Report URL were https://ad.network.com/report , the redirect URL would look like:

<img src="https://ad.network.com/report?google_error=ERROR_ID" />

Note: Bidders may request that their account always receive redirects to their Cookie Matching Report URL, even for successful operations. To enable this, they may contact their Technical Account Manager.

Step 5: User's browser redirects to bidder's Cookie Matching Report URL

The user's browser will redirect to the bidder's Cookie Matching Report URL, including the error reason (if any) specified by Google in the google_error parameter. To learn more about interpreting the error code, see the parameter description .

Note : This step will only occur if the bidder's account is configured to send information about the operation's failure or success to a Cookie Matching Report URL.

Step 6: Bidder serves 1x1 transparent pixel

The bidder must respond by serving a 1x1 transparent pixel to the user's browser.

Note : This step will only occur if the bidder's account is configured to send information about the operation's failure or success to a Cookie Matching Report URL.

Cookie Matching workflow diagram for users from US states with privacy restrictions

The default workflow for users in US states with privacy restrictions is illustrated by the following diagram, where requests and responses are represented by an arrow, and the data items that accompany them are listed in parentheses.

URL Parameters for bidder redirect to Google's Cookie Matching service

প্যারামিটার	বর্ণনা
google_nid	Network ID (NID) for the bidder account. This ID can be retrieved through the Bidders resource.
google_sc	এই প্যারামিটারটি অবহেলিত। Sets Google's cookie for the user if one is not present. The value of the parameter is ignored and may be omitted. Omitting the parameter results in an error if no cookie exists.
google_no_sc	এই প্যারামিটারটি অবহেলিত। This indicates to Google's Cookie Matching Service that it shouldn't set a cookie for the user if one is not present. The value of the parameter is ignored and may be omitted.
google_hm	Contains data that the bidder wants to store in a Google-hosted match table. Note: The value is a web-safe base64-encoded string (padding optional) that must not exceed 40 bytes. For example, this might look like: Q29va2llIG51bWJlciAxIQ== .
google_redir	An encoded URL that you want Google to send an HTTP 302 redirect. The specified URL will receive redirects with the google_error parameter for both errors and successful operations.
google_ula	A string used to add the user to an existing user list. The value's expected format is userlistid[,timestamp] : userlistid : a single numerical user list ID. timestamp : an optional timestamp in POSIX format, indicates when the user has been added to the user list. This URL parameter may be repeated to add the user to multiple lists.
gdpr	Indicates that the request is subject to GDPR restrictions on data usage. For more detail, see EU user consent requirements , or Impact on cookie match eligibility in the Authorized Buyers IAB TCF v2.0 documentation . Example: gdpr=1
gdpr_consent	A TC string that represents the end-user consent. For more detail, see EU user consent requirements , or How will the TC string be passed? in the Authorized Buyers IAB TCF v2.0 documentation .
process_consent	Indicates that the bidder has obtained end-user consent for the data uses specified in Google's EU User Consent Policy . If the request is not subject to the EU User Consent Policy, or if there are other consent parameters available on the request ( gdpr_consent ), this parameter is ignored. Example: process_consent=T

URL Parameters for Google redirect to Bidder's Cookie Matching Report URL

প্যারামিটার

বর্ণনা

google_error

An integer value indicating the overall request error. When received, it indicates that no operations have been performed, and no other google_ response parameters will be set. The supported error values include the following: 1 : User has a Google cookie, but has opted out of any tracking using this cookie. 2 : No valid operations specified. for example, a no-op request was received. 3 : User does not have a Google cookie. Google won't set the cookie through the Cookie Matching Service. 4 : Conflicting operations specified. You are not allowed to specify both the google_push and google_cm flags on the same request since they have conflicting purposes. 5 : An invalid google_push parameter was passed in a redirect to a Google server as part of a bidirectional Pixel Matching request. Your redirect must set google_push to the same value passed to you in the initial pixel request. 6 : An invalid NID was supplied in the match tag. 7 : An invalid cookie was detected. 8 : Deprecated. No cookie found. 9 : No cookie found, an attempt to set a test cookie is made. 10 : The google_redir parameter was used without google_hm being specified, or was used in addition to google_cm . 15 : The request comes from a region where Google requires the match table to be hosted by Google. As a result, this response does not contain a Google User ID.

Google-initiated: Bidirectional Pixel Matching

Bidirectional Pixel Matching is a workflow for Google's Cookie Matching Service where Google attempts to match a Google User ID with an algorithmically selected bidder other than the Real-Time Bidding auction winner. When an ad is placed, Google will place a match tag directing the user's browser to load a transparent pixel from the chosen bidder's Cookie Matching URL. This will enable both Google and the bidder to populate a match table with a given user. The following is an example of this workflow.

Step 1: Google places a match tag

When a participating publisher's page loads in the user's browser, and an ad slot on that page is filled by Google, a match tag may be placed that requests a pixel from an algorithmically selected bidder. The Pixel Matching tag placed by Google combines the bidder's Cookie Matching URL with additional parameters the bidder can use to populate their match table. For a Cookie Matching URL specified as https://ad.network.com/pixel , it is structured as follows:

<img src="https://ad.network.com/pixel?google_gid=GOOGLE_GID&google_cver=1&google_push=PUSH_DATA" />

Step 2: Bidder must respond with redirect to Google's Cookie Matching Service URL

Bidders receiving pixel matching requests are required to respond with a redirect to Google's Cookie Matching Service that is structured as follows:

https://cm.g.doubleclick.net/pixel?google_nid=GOOGLE_NID&google_push=PUSH_DATA

Note that the preceding redirect URL is similar to that of the URL used in the match tag for the Bidder-Initiated Cookie Matching Workflow . In Pixel Matching, the google_cm parameter is replaced by the google_push parameter, and its value must be equal to the value provided by Google in the request. Also similar to the bidder-initiated workflow, additional parameters can be specified to fulfill additional use cases.

Warning: the google_cm and google_push parameters should never appear in the same request to Google's Cookie Matching Service.

Step 3: Google processes redirect and responds with pixel

Google logs that a match has been created for the user, and handles any additional operations requested through query parameters Finally, Google responds with a 1x1 transparent pixel.

Pixel Matching workflow diagram

This workflow is illustrated by the following diagram, where requests and responses are represented by an arrow, and the data items that accompany them are listed in parentheses.

Google match tag request parameters

প্যারামিটার	বর্ণনা
google_gid	Google User ID. For users not from a US state with privacy restrictions, this will always be specified in Google's match tag.
google_cver	The cookie version. This will always be specified in Google's match tag.
google_push	Indicates that this request is initiating the Pixel Matching workflow. The value must be returned through the corresponding parameter in the bidder's redirect response.
gdpr_consent	A TC string that represents the end-user consent. For more detail, see [EU user consent requirements](/authorized-buyers/rtb/cookie-guide#eu-user-consent-requirements), or **How will the TC string be passed?** in the [Authorized Buyers IAB TCF v2.0 documentation](//support.google.com/authorizedbuyers/answer/9789378).

Bidder Pixel Matching redirect parameters

প্যারামিটার	বর্ণনা
google_nid	Network ID (NID) for the bidder account. This ID can be retrieved through the Bidders resource.
google_push	Indicates that this redirect is completing the Pixel Matching workflow. The value from the corresponding Google match tag must be specified here.
google_hm	Contains data that the bidder wants to store in a Google-hosted match table. Note: The value is a web-safe base64-encoded string (padding optional) that must not exceed 40 bytes. For example, this might look like: Q29va2llIG51bWJlciAxIQ== .
google_ula	A string used to add the user to an existing user list. The value's expected format is userlistid[,timestamp] : userlistid : a single numerical user list ID. timestamp : an optional timestamp in POSIX format, indicates when the user has been added to the user list. This URL parameter may be repeated to add the user to multiple lists.
gdpr_consent	A TC string that represents the end-user consent. For more detail, see [EU user consent requirements](/authorized-buyers/rtb/cookie-guide#eu-user-consent-requirements), or **How will the TC string be passed?** in the [Authorized Buyers IAB TCF v2.0 documentation](//support.google.com/authorizedbuyers/answer/9789378).

Google-initiated: Unidirectional Pixel Matching

Unidirectional Pixel Matching differs from the Bidirectional workflow in that Google's match tag does not include a parameter specifying the Google User ID, but will continue to populate a Google-hosted match table. This can be used in instances where the bidder is not permitted to host Google User IDs in their own match table. An example of the revised workflow is summarized in the following steps.

Note : This workflow is required for users from US states with privacy restrictions, but bidders may optionally adopt this workflow for other regions as well.

Step 1: Google places a match tag

Google places a match tag for an algorithmically selected bidder. The match tag includes the google_push parameter. এখানে একটি উদাহরণ:

<img src="https://ad.network.com/pixel?google_push=PUSH_DATA" />

Step 2: User's browser requests pixel from bidder's Cooking Matching URL

The user's browser requests a pixel from the bidder's Cookie Matching URL, including the bidder's cookie in the HTTP headers.

Step 3: Redirect to Google's Cookie Matching Service

The bidder's cookie matching endpoint must redirect to Google's Cookie Matching service, including the google_hm parameter populated with their web-safe base64-encoded cookie data. The redirect URL might look like the following:

https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_hm=HOSTED_MATCH_DATA&google_push=PUSH_DATA

Step 4: User's browser is redirected to Google's Cookie Matching service

Google will receive a redirect containing the parameters you specified, in addition to Google's cookie in the HTTP headers. If the operation was successful, impressions for this user in subsequent bid requests will include the bidder's hosted match data in BidRequest.user.buyeruid . Bidders can also populate user lists using the hosted match data they specified.

Finally, Google returns a 1x1 transparent pixel to the user's browser.

Cookie Match Assist

Open Bidding allows exchanges to use bidder initiated and Google initiated cookie matching workflows, to match a Google User ID with their cookie. Cookie Match Assist (CMA) is an additional feature for exchanges that enables them to build match tables with their own bidders.

How Cookie Match Assist works

1. When placing an ad, Google algorithmically selects a participating exchange and places a Cookie Match Assist tag that has the following structure:

   <img src="https://ob.exchange.com/pixel?google_gid=GOOGLE_GID&google_cver=1"/>

   Caution: For users from US states with privacy restrictions, Cookie Match Assist won't include the google_gid parameter.

2. Google's CMA match tag causes the exchange's Cookie Matching URL to receive a pixel request.

   Note: Unlike the Google-initiated workflows, this excludes the google_push parameter.
3. The exchange's Cookie Matching endpoint receives the request, where its own cookie matching service is responsible for matching the user ID with one of its bidders. In the following diagram, the exchange's cookie matching service responds to the user's browser with a redirect to one of its bidder's endpoints.
4. The bidder receives the request, along with any parameters specified by the exchange to match the user ID with their cookie.

Note: Depending on the exchange's implementation, an additional redirect from the bidder to the exchange could be used to set the cookie in a match table hosted by the exchange.

বিধিনিষেধ

Cap frequency of requests for fresh matches

Bidders are responsible for limiting the number of calls to the Cookie Matching service for users who have a fresh entry in the Google-hosted match table. An entry in the hosted match table may be considered expired in 14 days, after which it can be refreshed.

Warning: Google does not enforce frequency capping at serving time. However, it does periodically monitor that you are respecting the frequency capping policy, and reserves the right to interrupt the service in case of violation.

Respond to all pixel match requests

Bidders using the Pixel Matching workflow are expected to respond to all incoming Pixel Match requests with a response including the google_push parameter. This allows Google to enforce policies by monitoring usage. If a bidder's response rate is less than 90%, Google will throttle the number of Pixel Match requests sent to their account.

Use HTTPS endpoints

It is required that endpoints used in all Cookie Matching workflows use HTTPS.

When responding to a Pixel Match request sent to you over HTTPS, you are required to redirect to the Cookie Matching Service over HTTPS. Likewise, a Cookie Match Assist endpoint that redirects to bidders must also use HTTPS. If you send requests to Google over HTTP more often than once every 2 minutes, the number of match requests sent to your account will be throttled.

EU user consent requirements

Cookie Matching requests that are subject to Google's EU User Consent Policy should indicate end-user consent. Such requests are required to indicate that consent has been gathered using one of the following ways:

• TCFv2: This includes gdpr and gdpr_consent parameters. For details, consult the Authorized Buyers IAB TCF v2.0 documentation .
• process_consent : a declaration that the bidder has obtained necessary user consent.

উদাহরণ

The following examples illustrate how to use the Cookie Matching service to accomplish specific objectives. Note that unless stated otherwise, it is assumed that the user being acted upon is not from a US state with privacy restrictions.

Populate a bidder-hosted match table

A bidder can use the Cookie Matching workflow to populate their own match table by providing only the google_nid and google_cm parameters in their match tag. এটি দেখতে এরকম হতে পারে:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_cm" />

If the bidder's Cookie Matching URL is set to https://ad.network.com/pixel?id=1 , and the cookie matching operation is successful, the redirect Google sends in response to the bidder's match tag might look like:

https://ad.network.com/pixel?id=1&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1

If the cookie matching operation fails because the user does not have a Google cookie, the response would be:

https://ad.network.com/pixel?id=1&google_error=3

The error code is dependent on the underlying cause of the error. To learn more about possible error codes for the Cookie Matching workflow, see the redirect URL parameters .

Note: The bidder-defined parameter id seen in the match tag is passed along as-is when Google redirects to the bidder's Cookie Matching URL.

Add to single user list

The google_ula parameter can be specified in a bidder's match tag to add the user to a user list with the given ID. If the Google or bidder-hosted match table has a fresh entry for the user, the bidder can place a match tag including the google_nid and google_ula parameters to add the user to the specified list without initiating the full Cookie Matching workflow. See the restrictions on invoking the Cookie Matching Service for more deails. The corresponding match tag may look like:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345" />

For a successful response, where the bidder's Cookie Matching URL is https://ad.network.com/pixel , Google's redirect URL would be:

https://ad.network.com/pixel?google_ula=12345,0

Key Point: The value of google_ula is 12345,0 , indicating that the user should be added to a user list with ID 12345 , and in this case the timestamp is set to 0 to indicate that it is being left unspecified. Alternatively, just the user list ID could have been provided.

If there is an overall error— for example, there is no Google cookie for the user— the redirect URL will include the google_error parameter:

• https://ad.network.com/pixel?google_error=3

If there is an error specifically concerning adding the user to the list, you will receive google_ula in the redirect. Unlike the corresponding match tag parameter, this replaces the timestamp with a status code to indicate the operation's success. For example, if the request failed because the bidder account didn't have access to the specified user list, the redirect URL would be:

https://ad.network.com/pixel?google_ula=12345,2

Add to multiple user lists

Bidders can specify that a user should be added to multiple user lists by including multiple google_ula parameters in the match tag. In practice, this may look like:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345,7654321&google_ula=45678" />

The status of the operation for each user list is similarly reported through distinct google_ula parameters in the redirect:

https://ad.network.com/pixel?google_ula=12345,2&google_ula=45678,0

In the preceding redirect, we can see that the operation succeeded for the user list with ID 45678 , but failed for user list ID 12345 because the bidder didn't have permission to access it.

Step through Cookie Matching workflow and add to user list

To perform cookie matching and add the user to a user list in a single request, a bidder's match tag should include google_cm and google_ula :

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345&google_cm" />

The redirect URL specified by Google would include google_gid , google_cver , and google_ula . এটি নিম্নলিখিত মত দেখতে পারে:

https://ad.network.com/pixel?id=&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1&google_ula=12345,0

Store a match in a Google-hosted match table

If a bidder wants to store their cookie data in a Google-hosted match table, and does not intend to store match with the Google User ID in their own match table, their match tag must include the google_hm parameter where its value must be a web-safe base64-encoded string. For a user where the bidder's unencoded cookie data is Cookie number 1! , the encoded value would be Q29va2llIG51bWJlciAxIQ== , which would be used in a match tag like the following:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D" />

For a successful response, where the bidder's Cookie Matching URL is https://cookie-monster.com/pixel , Google's redirect URL would be:

https://cookie-monster.com/pixel

The google_gid parameter is not in the redirect because the match tag did not include google_cm , and google_hm is not included in successful responses. In future bid requests for impressions for this user, the bidder will receive their hosted match data in BidRequest.user.buyeruid .

If the bidder instead used a match tag where the value of google_hm was not base64-encoded—such as chocolate_chunk! —the redirect URL might look like the following:

https://cookie-monster.com/pixel?google_hm=2

The preceding redirect URL includes a google_hm value of 2 , suggesting that the operation failed because the value couldn't be decoded.

Bidder and Google-hosted match tables with user lists

If a bidder hosts their own use list in addition to a Google-hosted user list, and wants a single match tag to match both tables and add the user to a given user list, their match tag must include the google_cm , google_hm , and google_ula parameters. If the bidder's cookie data is Cookie number 1! , the encoded value would be Q29va2llIG51bWJlciAxIQ== , which would produce a match tag like the following:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D&google_cm&google_ula=12345" />

For a successful response, where the bidder's Cookie Matching URL is https://cookie-monster.com/pixel , Google's redirect URL would look like the following:

https://cookie-monster.com/pixel?google_gid=ABCDETC&google_cver=1&google_ula=12345,0

On receiving the redirect, the bidder can match the Google User ID specified in google_gid with their cookie data in their match table. In addition, they can determine that the Google-hosted match table and user list operations were successful. As a consequence, any Pretargeting the bidder configured to target the specified user list ID will now cause the bidder to receive bid requests for impressions from the user. Likewise, in these bid requests, the bidder will receive their hosted match data in BidRequest.user.buyeruid .

,

Cookie Matching is a feature that lets you match your cookie—for example, an ID for a user that browsed your website—with a corresponding bidder-specific Google User ID, and construct user lists that can help you make more effective bidding choices. This guide describes concepts used in Cookie Matching, as well as different Cookie Matching workflows, and any variations they may have for certain use cases.

Key Point: In order to access cookie matching features, you must contact your Account Manager to configure your account. The remainder of this guide assumes this has already been done.

ধারণা

What is Cookie Matching?

Domain owners typically set the contents of cookies for users that browse their site, which are used to identify users within that domain. Even if two domain owners would otherwise agree to exchanging this data, the security model of internet browsers restricts one from reading a cookie set by another domain.

In the context of digital advertising, Google identifies users with cookies that belong to the doubleclick.net domain, and bidders participating in Real-Time Bidding may have their own domain where they identify some set of users they would like to show ads. Cookie Matching enables the bidder to match their cookies with Google's, such that they can determine whether an impression sent in a bid request is associated with one of users being targeted, they will receive either their own cookie data or a bidder-specific Google User ID that is an encrypted form of the doubleclick.net cookie in the bid request.

The cookie matching service described in this guide facilitates the creation and maintenance of the association between a bidder's cookie and the Google User ID, and also allows one to populate user lists.

Match tables

A match table can be used to map an ID or other data from one domain to another. Bidders can use the Cookie Matching Service to populate their own match tables by mapping their cookie for a given user to the user's Google User ID, or to populate a match table hosted by Google. Match tables are necessary for a bidder's bidder application to access cookie data for the user being shown the impression.

Google-hosted match tables

For easier maintenance, latency improvements, and access to match data for users in certain regions, it is recommended that you allow Google to host your match table. This lets you specify a web-safe base64-encoded string — hereafter referred to as hosted match data—that will be mapped to the Google User ID for a given user. Once a match has been established, it can be used in the following ways:

• Real-Time Bidding : In subsequent bid requests for impressions associated with the user, Google will send you the hosted match data you matched with their Google User ID. Google will specify BidRequest.user.buyeruid as a web-safe base64-encoded string.

  Key Point: For users detected to originate from US states with privacy restrictions, the Google User ID won't be specified in the bid request. You will still receive your hosted match data, which can be used to inform your bidding logic.
  Caution: By default, the value in buyeruid is a web-safe base64-encoded string, and should be equivalent to what you send in google_hm . If you are receiving unexpected buyeruid values in the bid request, it may indicate that you are sending an unencoded google_hm value. To disable encoding in the bid request, contact your Technical Account Manager.

• User Lists : User lists can be populated with either Google User IDs or hosted match data.

  Caution: For users detected to originate from US states with privacy restrictions, using a Google User ID to populate user lists is deprecated, and will eventually be sunset. It is recommended that bidders populate user lists with their hosted match data for these users.
• Pretargeting : You can configure your pretargeting such that you only receive bid requests containing hosted match data. This can be used to eliminate less relevant impressions for users outside of your cookie space.

ব্যবহারকারীর তালিকা

User lists can be created and managed with the Real-Time Bidding API . Once created, you can populate these lists with the following Cookie Matching workflows, or through the Bulk Uploader Service .

Key Point: User lists can be populated with both Google User IDs and hosted match data, and intermixing these is possible. Note that when specifying the latter, they must have already been added to a Google-hosted match table. For users from US states with privacy restrictions, you must use modified workflows that add hosted match data to user lists rather than the Google User ID.

শুরু করা

In order to get started with Cookie Matching, you must contact your Technical Account Manager, who can enable specific workflows and help you configure the following:

• Cookie Matching Network ID (NID) : A string ID uniquely identifying a bidder account for Cookie Matching and other related operations.
• Cookie Matching URL : The base URL for an endpoint that will accept and handle incoming requests as part of the Cookie Matching workflows. Bidders can embed macros in this URL to control the ordering of parameters passed to it in Cookie Matching workflows.
• Match Tag : The tag you must place in a user's browser for the bidder-initiated Cookie Matching workflow. This can be served alongside ads, or placed on web properties outside of ads.
• Cookie Matching Report URL (optional): In the Unidirectional Cookie Matching Workflow, this is an optional URL that can be provided to specify an endpoint that will receive error details in the event that cookie matching fails through an HTTP 302 redirect. By default, responses will only be sent to this URL if there was an error with the cookie matching operation, but bidder's may request that the redirect always be sent.
• Cookie Match Assist URL : For exchanges implementing the Cookie Match Assist workflow , this is the base URL of the endpoint intended to respond to incoming requests.
• Cookie Match Assist Quota : For exchanges implementing the Cookie Match Assist workflow , this is the maximum number of requests that their Cookie Matching URL can receive every second. This is intended to prevent CMA requests from overloading the exchange's servers with requests.

Note: Authorized Buyers can view the Cookie Matching NID and URL configured for their accounts with the Bidders resource.

Cookie matching macros

In any of the supported Cookie Matching workflows , a bidder's Cookie Matching URL typically has parameters appended in a non-guaranteed ordering. Bidders with integrations requiring consistent ordering of parameters can place macros in their Cookie Matching URL to indicate their placement.

Supported macros

Bidders can optionally configure their Cookie Matching URL to include one or more macros in the form of either %%GOOGLE_<PARAM_NAME>%% or %%GOOGLE_<PARAM_NAME>_PAIR%% . The supported macros and their expanded values are:

ম্যাক্রো	Expanded value
GOOGLE_GID	GOOGLE_USER_ID
GOOGLE_GID_PAIR	&google_gid= GOOGLE_USER_ID
GOOGLE_CVER	COOKIE_VERSION_NUMBER
GOOGLE_CVER_PAIR	&cver= COOKIE_VERSION_NUMBER
GOOGLE_ERROR	ERROR_ID
GOOGLE_ERROR_PAIR	&google_error= ERROR_ID
GOOGLE_PUSH	PIXEL_MATCH_DATA
GOOGLE_PUSH_PAIR	&google_push= PIXEL_MATCH_DATA
GOOGLE_ALL_PARAMS	google_gid= GOOGLE_USER_ID &cver= COOKIE_VERSION_NUMBER &google_error= ERROR_ID

ম্যাক্রো উদাহরণ

A bidder has a cookie matching integration with an endpoint hosted at https://user.bidder.com/cookies , and their implementation requires preset bidder-defined parameters in addition to Pixel Matching parameters in the following order: google_push , google_gid , google_cver , and google_error . The bidder can accomplish this by setting their Cookie Matching URL to:

https://user.bidder.com/cookies?w=0%%GOOGLE_PUSH_PAIR%%&x=1%%GOOGLE_GID_PAIR%%&y=2%%GOOGLE_CVER_PAIR%%&z=3%%GOOGLE_ERROR_PAIR%%

When Google later sends a match request to this bidder, it will be expanded to something like the following:

https://user.bidder.com/cookies?w=0&google_push=PUSH_DATA&x=1&google_gid=GOOGLE_GID&y=2&google_cver=1&z=3

Note: The google_error parameter is not populated in Google's match tag for the Pixel Matching workflow, and so is excluded.

Cookie Matching Service workflows

Google's Cookie Matching Service supports the following three workflows.

Bidder-initiated: Bidirectional Cookie Matching

Bidirectional Cookie Matching refers to a bidder-initiated workflow, where they place a match tag in the user's browser that directs it to Google. This workflow allows both Google and the bidder to populate match tables. The following is an example of this workflow.

Step 1: Place the match tag

In order to initiate this flow, the bidder must place their match tag such that it renders in the user's browser. A match tag that only returns the Google User ID to the bidder may be structured as follows:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm" />

Note: The BIDDER_ACCOUNT_NID should be replaced by the NID for the bidder account. This is provided by Technical Account Managers during configuration of cookie matching for a bidder account, and can also be viewed with the Real-time Bidding API's Bidders resource .

There are additional parameters you can include in the match tag to fulfill different use cases. To learn more about these parameters, see Match Tag URL Parameters .

Step 2: Google responds with redirect including match data

The match tag will cause Google's Cookie Matching Service to receive a request from the user's browser, which will issue an HTTP 302 redirect to the bidder's Cookie Matching URL. The redirect will include query parameters specifying the Google User ID and its version number in the URL, and the bidder will also receive their cookie included in the request headers. In practice, for a cookie matching URL specified as https://ad.network.com/pixel , the redirect URL for the previous match tag could look like the following:

https://ad.network.com/pixel?google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1

The Google User ID passed through the google_gid parameter is an unpadded web-safe base64-encoded string. For bidders choosing to host a match table, it is recommended that they store the exact string returned by the Cookie Matching Service. In subsequent bid requests, this will correspond to values specified through BidRequest.user.id .

The version specified in google_cver indicates the numeric version number for the Google User ID. The Google User ID for a given user will infrequently change, after which this will be incremented.

If Google encounters an error while processing your match request, a google_error parameter will instead be specified.

Step 3: Bidder processes redirect and responds with pixel

The bidder receives a redirect to their cookie matching URL including parameters they specified in the first step, and those Google provided in the second step. In addition, they will also receive their cookie in the HTTP headers. If the operation was successful, a bidder hosting their own match table could match their cookie to the Google User ID included in the response. It is recommended that bidders store the exact string returned by the Cookie Matching Service.

If the operation was unsuccessful, the bidder will receive a google_error parameter in the redirect. This is a numeric value corresponding to different error states that identify the particular error that occurred. You can learn more about the possible error values in the description of the google_error URL parameter. If you receive an error, you may attempt to match for that user again by placing a new match tag.

The bidder must always respond by serving a 1x1 invisible pixel image, or alternatively return an HTTP 204 No Content response.

Cookie Matching workflow diagram

This workflow is illustrated by the following diagram, where requests and responses are represented by an arrow, and the data items that accompany them are listed in parentheses.

Match Tag URL Parameters

প্যারামিটার	বর্ণনা
google_nid	Network ID (NID) for the bidder account. This ID can be retrieved through the Bidders resource.
google_cm	Indicates to Google's Cookie Matching Service that it should perform cookie matching. The value of the parameter is ignored and may be omitted.
google_sc	এই প্যারামিটারটি অবহেলিত। Sets Google's cookie for the user if one is not present. The value of the parameter is ignored and may be omitted. Omitting the parameter results in an error if no cookie exists.
google_no_sc	এই প্যারামিটারটি অবহেলিত। This indicates to Google's Cookie Matching Service that it shouldn't set a cookie for the user if one is not present. The value of the parameter is ignored and may be omitted.
google_hm	Data the bidder wants to store in a Google-hosted match table. The value is a web-safe base64-encoded string (padding optional). The raw data must be 40 bytes or less. For example, Q29va2llIHRoYXQgaXMgdW5kZXIgNDAgdG90YWwgYnl0ZXMuLi4u .
google_redir	A URL-encoded string that a bidder can specify if they want to direct Google to send the HTTP 302 redirect to the encoded URL for this match tag. This allows Google to be placed at the front in a chained call to partners. This will result in an error if specified without google_hm , or with google_cm .
google_ula	A string used to add the user to an existing user list. The value's expected format is userlistid[,timestamp] : userlistid : a single numerical user list ID. timestamp : an optional timestamp in POSIX format, indicates when the user has been added to the user list. This URL parameter may be repeated to add the user to multiple lists.
gdpr	Indicates that the request is subject to GDPR restrictions on data usage. For more detail, see EU user consent requirements , or Impact on cookie match eligibility in the Authorized Buyers IAB TCF v2.0 documentation . Example: gdpr=1
gdpr_consent	A TC string that represents the end-user consent. For more detail, see EU user consent requirements , or How will the TC string be passed? in the Authorized Buyers IAB TCF v2.0 documentation .
process_consent	Indicates that the bidder has obtained end-user consent for the data uses specified in Google's EU User Consent Policy . If the request is not subject to the EU User Consent Policy, or if there are other consent parameters available on the request ( gdpr_consent ), this parameter is ignored. Example: process_consent=T

In addition to the earlier parameters, bidders may specify their own, which will be appended as parameters to the redirect URL. Note that bidder-defined parameters named with the google_ prefix will be ignored because those are reserved by Google for future development, and preservation of the parameters' ordering is not guaranteed. A match tag including bidder-defined parameters may look like:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm&extra1=xx&extra2=yy" />

Redirect URL Parameters

The redirect URL is built from the base Cookie Matching URL configured for a bidder's account, including google_ and bidder-defined parameters depending on those specified in the match tag. The following google_ response parameters are defined:

প্যারামিটার	বর্ণনা
google_gid	Google User ID. Set if google_cm is specified in the request and the request was successful.
google_cver	Cookie version. Set if google_cm is specified in the request and the request was successful.
google_error	An integer value indicating the overall request error. When received, it indicates that no operations have been performed, and no other google_ response parameters will be set. The supported error values include the following: 1 : User has a Google cookie, but has opted out of any tracking using this cookie. 2 : No valid operations specified. for example, a no-op request was received. 3 : User does not have a Google cookie. Google won't set the cookie through the Cookie Matching Service. 4 : Conflicting operations specified. You are not allowed to specify both the google_push and google_cm flags on the same request since they have conflicting purposes. 5 : An invalid google_push parameter was passed in a redirect to a Google server as part of a bidirectional Pixel Matching request. Your redirect must set google_push to the same value passed to you in the initial pixel request. 6 : An invalid NID was supplied in the match tag. 7 : An invalid cookie was detected. 8 : Deprecated. No cookie found. 9 : No cookie found, an attempt to set a test cookie is made. 10 : The google_redir parameter was used without google_hm being specified, or was used in addition to google_cm . 15 : The request comes from a region where Google requires the match table to be hosted by Google. As a result, this response does not contain a Google User ID.
google_hm	Only appears if the attempt to write to the Google-hosted match table fails. When that happens, its value is one of the following status codes: 1 - Forbidden: The customer doesn't have access to write hosted match table entries. 2 - Decode error: The parameter value couldn't be decoded. 3 - Payload too long: The parameter value decoded into more than 40 bytes of data. 4 - Internal error: There was an internal error storing the data. 5 - Throttled: This write was not processed due to throttling.
google_ula	Status of user list add operation, repeated if multiple google_ula were specified in the request. বিন্যাস হল: userlistid,status code Ex: google_ula=1234567890,0 The google_ula operation can return any of the following status codes: 0 - No error. The user has been added to the user list. 2 - Permission denied. You don't have permission to add users to the given user list. 5 - Bad user list ID. The supplied user list ID is invalid. 6 - Closed attribute ID. The supplied user list ID is closed. 10 - Internal error. The Cookie Matching service has encountered an internal error; you can try re-matching the user again.

Cookie Matching workflow example scenarios

The following scenarios describe what cookie matching might look like for a typical user browsing a web page.

Scenario 1: User clears their cookies and browses a site

Jane clears their cache of all cookies. They then visit the homepage of ExampleNews.com.

এখানে যা ঘটে:

1. ExampleNews.com renders, and calls ads from Google (Ad Manager).
2. Because the ad unit is eligible for dynamic allocation, Google sends bid requests to FinestDSP and other bidders through the Real-Time Bidding service.
3. FinestDSP's bidder application receives and processes the bid request, and sends its bid response.
4. Google receives bid responses from bidders, including FinestDSP's response that specifies an ad with a match tag (pixel).
5. FinestDSP wins the auction. Google serves FinestDSP's ad and match tag to Jane.
6. The match tag calls Google's Cookie Match Service, specifying the google_nid and google_cm parameters.
7. The Cookie Match Service reads Jane's Google cookie, and sends Jane's browser a redirect to FinestDSP's Cookie Matching URL with the google_gid and google_cver parameters set.
8. Jane's browser loads the redirect to FinestDSP's Cookie Match URL.
9. FinestDSP's cookie matching endpoint processes the redirect request, which includes URL parameters set by Google, and their cookie for Jane in the HTTP headers. FinestDSP can now store the mapping of their cookie to the google_gid in their match table.
10. FinestDSP responds to the redirect with an invisible 1x1 pixel.

Scenario 2: User with existing mapping

A week after Scenario 1, Jane visits ExampleNews.com again. Now that Jane has both bidder and Ad Manager cookies on their machine, here's how matching works.

1. The web page renders, causing Google (Ad Manager) to request ads that will be rendered on the page.
2. During the ad auction, Google sends a bid request to applicable bidders, including FinestDSP.
3. FinestDSP receives the bid request, including signals such as the google_gid .
4. FinestDSP looks up the google_gid in its match table, and finds the cookie associated with Jane that was created a week earlier (in Scenario 1).
5. Based on information associated with the cookie, FinestDSP's bidding logic places a bid on the impression, and wins the auction.
6. Jane might see an ad tailored to their interests, based on information that FinestDSP possesses.

Bidder-initiated: Unidirectional Cookie Matching

Unidirectional Cookie Matching is similar to the Bidirectional workflow, except that it is altered such that only Google hosts and populates a match table. This can be used in instances where the bidder is not permitted to host Google User IDs in their own match table. In order to use this flow, bidders must allow Google to host the match table, can no longer specify google_cm in requests to Google's Cookie Matching Service, and will consequently not receive google_gid to populate their own match table. Once Google has established a match for a user, bidders can add them to user lists using their own cookie data. Similarly, bid requests for these users will exclude the Google User ID, but include hosted match data. An example of the revised workflow is summarized in the following steps.

Note : This workflow is required for users from US states with privacy restrictions, but bidders may optionally adopt this workflow for other regions as well.

Step 1: Place the match tag directed to bidder's Cookie Matching URL

In order to initiate this flow, a bidder must place a match tag such that it renders in the user's browser. Unlike the workflow for users not from a US state with privacy restrictions, the match tag must direct the user's browser to your Cookie Matching URL. For example, with a Cookie Matching URL configured as https://ad.network.com/pixel , it would look like:

<img src="https://ad.network.com/pixel" />

When loading in the user's browser, it will request a pixel from the bidder's Cookie Matching URL. This request will contain their cookie in the HTTP header, which should be extracted for the next step.

Step 2: Redirect to Google's Cookie Matching service

The bidder's cookie matching endpoint must redirect to Google's Cookie Matching service, including the google_hm parameter populated with their web-safe base64-encoded cookie data. The redirect URL might look like the following:

https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_hm=HOSTED_MATCH_DATA

Step 3: User's browser is redirected to Google's Cookie Matching service

Google will receive a redirect containing the parameters you specified, in addition to Google's cookie in the HTTP headers.

Step 4: Google serves pixel on success or error redirect if report URL specified

If the cookie matching operation is successful—or if no Cookie Matching Report URL has been specified for the bidder's account—Google will serve a 1x1 transparent pixel by default, and the workflow will end here. Impressions for this user in subsequent bid requests will include the bidder's hosted match data in BidRequest.user.buyeruid . Bidders can also populate user lists using the hosted match data they specified.

Otherwise, if an error occurred, Google will send a redirect to the bidder's Cookie Matching Report URL with the cause of the error specified in the google_error parameter. If the bidder's Cookie Matching Report URL were https://ad.network.com/report , the redirect URL would look like:

<img src="https://ad.network.com/report?google_error=ERROR_ID" />

Note: Bidders may request that their account always receive redirects to their Cookie Matching Report URL, even for successful operations. To enable this, they may contact their Technical Account Manager.

Step 5: User's browser redirects to bidder's Cookie Matching Report URL

The user's browser will redirect to the bidder's Cookie Matching Report URL, including the error reason (if any) specified by Google in the google_error parameter. To learn more about interpreting the error code, see the parameter description .

Note : This step will only occur if the bidder's account is configured to send information about the operation's failure or success to a Cookie Matching Report URL.

Step 6: Bidder serves 1x1 transparent pixel

The bidder must respond by serving a 1x1 transparent pixel to the user's browser.

Note : This step will only occur if the bidder's account is configured to send information about the operation's failure or success to a Cookie Matching Report URL.

Cookie Matching workflow diagram for users from US states with privacy restrictions

The default workflow for users in US states with privacy restrictions is illustrated by the following diagram, where requests and responses are represented by an arrow, and the data items that accompany them are listed in parentheses.

URL Parameters for bidder redirect to Google's Cookie Matching service

প্যারামিটার	বর্ণনা
google_nid	Network ID (NID) for the bidder account. This ID can be retrieved through the Bidders resource.
google_sc	এই প্যারামিটারটি অবহেলিত। Sets Google's cookie for the user if one is not present. The value of the parameter is ignored and may be omitted. Omitting the parameter results in an error if no cookie exists.
google_no_sc	এই প্যারামিটারটি অবহেলিত। This indicates to Google's Cookie Matching Service that it shouldn't set a cookie for the user if one is not present. The value of the parameter is ignored and may be omitted.
google_hm	Contains data that the bidder wants to store in a Google-hosted match table. Note: The value is a web-safe base64-encoded string (padding optional) that must not exceed 40 bytes. For example, this might look like: Q29va2llIG51bWJlciAxIQ== .
google_redir	An encoded URL that you want Google to send an HTTP 302 redirect. The specified URL will receive redirects with the google_error parameter for both errors and successful operations.
google_ula	A string used to add the user to an existing user list. The value's expected format is userlistid[,timestamp] : userlistid : a single numerical user list ID. timestamp : an optional timestamp in POSIX format, indicates when the user has been added to the user list. This URL parameter may be repeated to add the user to multiple lists.
gdpr	Indicates that the request is subject to GDPR restrictions on data usage. For more detail, see EU user consent requirements , or Impact on cookie match eligibility in the Authorized Buyers IAB TCF v2.0 documentation . Example: gdpr=1
gdpr_consent	A TC string that represents the end-user consent. For more detail, see EU user consent requirements , or How will the TC string be passed? in the Authorized Buyers IAB TCF v2.0 documentation .
process_consent	Indicates that the bidder has obtained end-user consent for the data uses specified in Google's EU User Consent Policy . If the request is not subject to the EU User Consent Policy, or if there are other consent parameters available on the request ( gdpr_consent ), this parameter is ignored. Example: process_consent=T

URL Parameters for Google redirect to Bidder's Cookie Matching Report URL

প্যারামিটার

বর্ণনা

google_error

An integer value indicating the overall request error. When received, it indicates that no operations have been performed, and no other google_ response parameters will be set. The supported error values include the following: 1 : User has a Google cookie, but has opted out of any tracking using this cookie. 2 : No valid operations specified. for example, a no-op request was received. 3 : User does not have a Google cookie. Google won't set the cookie through the Cookie Matching Service. 4 : Conflicting operations specified. You are not allowed to specify both the google_push and google_cm flags on the same request since they have conflicting purposes. 5 : An invalid google_push parameter was passed in a redirect to a Google server as part of a bidirectional Pixel Matching request. Your redirect must set google_push to the same value passed to you in the initial pixel request. 6 : An invalid NID was supplied in the match tag. 7 : An invalid cookie was detected. 8 : Deprecated. No cookie found. 9 : No cookie found, an attempt to set a test cookie is made. 10 : The google_redir parameter was used without google_hm being specified, or was used in addition to google_cm . 15 : The request comes from a region where Google requires the match table to be hosted by Google. As a result, this response does not contain a Google User ID.

Google-initiated: Bidirectional Pixel Matching

Bidirectional Pixel Matching is a workflow for Google's Cookie Matching Service where Google attempts to match a Google User ID with an algorithmically selected bidder other than the Real-Time Bidding auction winner. When an ad is placed, Google will place a match tag directing the user's browser to load a transparent pixel from the chosen bidder's Cookie Matching URL. This will enable both Google and the bidder to populate a match table with a given user. The following is an example of this workflow.

Step 1: Google places a match tag

When a participating publisher's page loads in the user's browser, and an ad slot on that page is filled by Google, a match tag may be placed that requests a pixel from an algorithmically selected bidder. The Pixel Matching tag placed by Google combines the bidder's Cookie Matching URL with additional parameters the bidder can use to populate their match table. For a Cookie Matching URL specified as https://ad.network.com/pixel , it is structured as follows:

<img src="https://ad.network.com/pixel?google_gid=GOOGLE_GID&google_cver=1&google_push=PUSH_DATA" />

Step 2: Bidder must respond with redirect to Google's Cookie Matching Service URL

Bidders receiving pixel matching requests are required to respond with a redirect to Google's Cookie Matching Service that is structured as follows:

https://cm.g.doubleclick.net/pixel?google_nid=GOOGLE_NID&google_push=PUSH_DATA

Note that the preceding redirect URL is similar to that of the URL used in the match tag for the Bidder-Initiated Cookie Matching Workflow . In Pixel Matching, the google_cm parameter is replaced by the google_push parameter, and its value must be equal to the value provided by Google in the request. Also similar to the bidder-initiated workflow, additional parameters can be specified to fulfill additional use cases.

Warning: the google_cm and google_push parameters should never appear in the same request to Google's Cookie Matching Service.

Step 3: Google processes redirect and responds with pixel

Google logs that a match has been created for the user, and handles any additional operations requested through query parameters Finally, Google responds with a 1x1 transparent pixel.

Pixel Matching workflow diagram

This workflow is illustrated by the following diagram, where requests and responses are represented by an arrow, and the data items that accompany them are listed in parentheses.

Google match tag request parameters

প্যারামিটার	বর্ণনা
google_gid	Google User ID. For users not from a US state with privacy restrictions, this will always be specified in Google's match tag.
google_cver	The cookie version. This will always be specified in Google's match tag.
google_push	Indicates that this request is initiating the Pixel Matching workflow. The value must be returned through the corresponding parameter in the bidder's redirect response.
gdpr_consent	A TC string that represents the end-user consent. For more detail, see [EU user consent requirements](/authorized-buyers/rtb/cookie-guide#eu-user-consent-requirements), or **How will the TC string be passed?** in the [Authorized Buyers IAB TCF v2.0 documentation](//support.google.com/authorizedbuyers/answer/9789378).

Bidder Pixel Matching redirect parameters

প্যারামিটার	বর্ণনা
google_nid	Network ID (NID) for the bidder account. This ID can be retrieved through the Bidders resource.
google_push	Indicates that this redirect is completing the Pixel Matching workflow. The value from the corresponding Google match tag must be specified here.
google_hm	Contains data that the bidder wants to store in a Google-hosted match table. Note: The value is a web-safe base64-encoded string (padding optional) that must not exceed 40 bytes. For example, this might look like: Q29va2llIG51bWJlciAxIQ== .
google_ula	A string used to add the user to an existing user list. The value's expected format is userlistid[,timestamp] : userlistid : a single numerical user list ID. timestamp : an optional timestamp in POSIX format, indicates when the user has been added to the user list. This URL parameter may be repeated to add the user to multiple lists.
gdpr_consent	A TC string that represents the end-user consent. For more detail, see [EU user consent requirements](/authorized-buyers/rtb/cookie-guide#eu-user-consent-requirements), or **How will the TC string be passed?** in the [Authorized Buyers IAB TCF v2.0 documentation](//support.google.com/authorizedbuyers/answer/9789378).

Google-initiated: Unidirectional Pixel Matching

Unidirectional Pixel Matching differs from the Bidirectional workflow in that Google's match tag does not include a parameter specifying the Google User ID, but will continue to populate a Google-hosted match table. This can be used in instances where the bidder is not permitted to host Google User IDs in their own match table. An example of the revised workflow is summarized in the following steps.

Note : This workflow is required for users from US states with privacy restrictions, but bidders may optionally adopt this workflow for other regions as well.

Step 1: Google places a match tag

Google places a match tag for an algorithmically selected bidder. The match tag includes the google_push parameter. এখানে একটি উদাহরণ:

<img src="https://ad.network.com/pixel?google_push=PUSH_DATA" />

Step 2: User's browser requests pixel from bidder's Cooking Matching URL

The user's browser requests a pixel from the bidder's Cookie Matching URL, including the bidder's cookie in the HTTP headers.

Step 3: Redirect to Google's Cookie Matching Service

The bidder's cookie matching endpoint must redirect to Google's Cookie Matching service, including the google_hm parameter populated with their web-safe base64-encoded cookie data. The redirect URL might look like the following:

https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_hm=HOSTED_MATCH_DATA&google_push=PUSH_DATA

Step 4: User's browser is redirected to Google's Cookie Matching service

Google will receive a redirect containing the parameters you specified, in addition to Google's cookie in the HTTP headers. If the operation was successful, impressions for this user in subsequent bid requests will include the bidder's hosted match data in BidRequest.user.buyeruid . Bidders can also populate user lists using the hosted match data they specified.

Finally, Google returns a 1x1 transparent pixel to the user's browser.

Cookie Match Assist

Open Bidding allows exchanges to use bidder initiated and Google initiated cookie matching workflows, to match a Google User ID with their cookie. Cookie Match Assist (CMA) is an additional feature for exchanges that enables them to build match tables with their own bidders.

How Cookie Match Assist works

1. When placing an ad, Google algorithmically selects a participating exchange and places a Cookie Match Assist tag that has the following structure:

   <img src="https://ob.exchange.com/pixel?google_gid=GOOGLE_GID&google_cver=1"/>

   Caution: For users from US states with privacy restrictions, Cookie Match Assist won't include the google_gid parameter.

2. Google's CMA match tag causes the exchange's Cookie Matching URL to receive a pixel request.

   Note: Unlike the Google-initiated workflows, this excludes the google_push parameter.
3. The exchange's Cookie Matching endpoint receives the request, where its own cookie matching service is responsible for matching the user ID with one of its bidders. In the following diagram, the exchange's cookie matching service responds to the user's browser with a redirect to one of its bidder's endpoints.
4. The bidder receives the request, along with any parameters specified by the exchange to match the user ID with their cookie.

Note: Depending on the exchange's implementation, an additional redirect from the bidder to the exchange could be used to set the cookie in a match table hosted by the exchange.

বিধিনিষেধ

Cap frequency of requests for fresh matches

Bidders are responsible for limiting the number of calls to the Cookie Matching service for users who have a fresh entry in the Google-hosted match table. An entry in the hosted match table may be considered expired in 14 days, after which it can be refreshed.

Warning: Google does not enforce frequency capping at serving time. However, it does periodically monitor that you are respecting the frequency capping policy, and reserves the right to interrupt the service in case of violation.

Respond to all pixel match requests

Bidders using the Pixel Matching workflow are expected to respond to all incoming Pixel Match requests with a response including the google_push parameter. This allows Google to enforce policies by monitoring usage. If a bidder's response rate is less than 90%, Google will throttle the number of Pixel Match requests sent to their account.

Use HTTPS endpoints

It is required that endpoints used in all Cookie Matching workflows use HTTPS.

When responding to a Pixel Match request sent to you over HTTPS, you are required to redirect to the Cookie Matching Service over HTTPS. Likewise, a Cookie Match Assist endpoint that redirects to bidders must also use HTTPS. If you send requests to Google over HTTP more often than once every 2 minutes, the number of match requests sent to your account will be throttled.

EU user consent requirements

Cookie Matching requests that are subject to Google's EU User Consent Policy should indicate end-user consent. Such requests are required to indicate that consent has been gathered using one of the following ways:

• TCFv2: This includes gdpr and gdpr_consent parameters. For details, consult the Authorized Buyers IAB TCF v2.0 documentation .
• process_consent : a declaration that the bidder has obtained necessary user consent.

উদাহরণ

The following examples illustrate how to use the Cookie Matching service to accomplish specific objectives. Note that unless stated otherwise, it is assumed that the user being acted upon is not from a US state with privacy restrictions.

Populate a bidder-hosted match table

A bidder can use the Cookie Matching workflow to populate their own match table by providing only the google_nid and google_cm parameters in their match tag. এটি দেখতে এরকম হতে পারে:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_cm" />

If the bidder's Cookie Matching URL is set to https://ad.network.com/pixel?id=1 , and the cookie matching operation is successful, the redirect Google sends in response to the bidder's match tag might look like:

https://ad.network.com/pixel?id=1&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1

If the cookie matching operation fails because the user does not have a Google cookie, the response would be:

https://ad.network.com/pixel?id=1&google_error=3

The error code is dependent on the underlying cause of the error. To learn more about possible error codes for the Cookie Matching workflow, see the redirect URL parameters .

Note: The bidder-defined parameter id seen in the match tag is passed along as-is when Google redirects to the bidder's Cookie Matching URL.

Add to single user list

The google_ula parameter can be specified in a bidder's match tag to add the user to a user list with the given ID. If the Google or bidder-hosted match table has a fresh entry for the user, the bidder can place a match tag including the google_nid and google_ula parameters to add the user to the specified list without initiating the full Cookie Matching workflow. See the restrictions on invoking the Cookie Matching Service for more deails. The corresponding match tag may look like:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345" />

For a successful response, where the bidder's Cookie Matching URL is https://ad.network.com/pixel , Google's redirect URL would be:

https://ad.network.com/pixel?google_ula=12345,0

Key Point: The value of google_ula is 12345,0 , indicating that the user should be added to a user list with ID 12345 , and in this case the timestamp is set to 0 to indicate that it is being left unspecified. Alternatively, just the user list ID could have been provided.

If there is an overall error— for example, there is no Google cookie for the user— the redirect URL will include the google_error parameter:

• https://ad.network.com/pixel?google_error=3

If there is an error specifically concerning adding the user to the list, you will receive google_ula in the redirect. Unlike the corresponding match tag parameter, this replaces the timestamp with a status code to indicate the operation's success. For example, if the request failed because the bidder account didn't have access to the specified user list, the redirect URL would be:

https://ad.network.com/pixel?google_ula=12345,2

Add to multiple user lists

Bidders can specify that a user should be added to multiple user lists by including multiple google_ula parameters in the match tag. In practice, this may look like:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345,7654321&google_ula=45678" />

The status of the operation for each user list is similarly reported through distinct google_ula parameters in the redirect:

https://ad.network.com/pixel?google_ula=12345,2&google_ula=45678,0

In the preceding redirect, we can see that the operation succeeded for the user list with ID 45678 , but failed for user list ID 12345 because the bidder didn't have permission to access it.

Step through Cookie Matching workflow and add to user list

To perform cookie matching and add the user to a user list in a single request, a bidder's match tag should include google_cm and google_ula :

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345&google_cm" />

The redirect URL specified by Google would include google_gid , google_cver , and google_ula . এটি নিম্নলিখিত মত দেখতে পারে:

https://ad.network.com/pixel?id=&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1&google_ula=12345,0

Store a match in a Google-hosted match table

If a bidder wants to store their cookie data in a Google-hosted match table, and does not intend to store match with the Google User ID in their own match table, their match tag must include the google_hm parameter where its value must be a web-safe base64-encoded string. For a user where the bidder's unencoded cookie data is Cookie number 1! , the encoded value would be Q29va2llIG51bWJlciAxIQ== , which would be used in a match tag like the following:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D" />

For a successful response, where the bidder's Cookie Matching URL is https://cookie-monster.com/pixel , Google's redirect URL would be:

https://cookie-monster.com/pixel

The google_gid parameter is not in the redirect because the match tag did not include google_cm , and google_hm is not included in successful responses. In future bid requests for impressions for this user, the bidder will receive their hosted match data in BidRequest.user.buyeruid .

If the bidder instead used a match tag where the value of google_hm was not base64-encoded—such as chocolate_chunk! —the redirect URL might look like the following:

https://cookie-monster.com/pixel?google_hm=2

The preceding redirect URL includes a google_hm value of 2 , suggesting that the operation failed because the value couldn't be decoded.

Bidder and Google-hosted match tables with user lists

If a bidder hosts their own use list in addition to a Google-hosted user list, and wants a single match tag to match both tables and add the user to a given user list, their match tag must include the google_cm , google_hm , and google_ula parameters. If the bidder's cookie data is Cookie number 1! , the encoded value would be Q29va2llIG51bWJlciAxIQ== , which would produce a match tag like the following:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D&google_cm&google_ula=12345" />

For a successful response, where the bidder's Cookie Matching URL is https://cookie-monster.com/pixel , Google's redirect URL would look like the following:

https://cookie-monster.com/pixel?google_gid=ABCDETC&google_cver=1&google_ula=12345,0

On receiving the redirect, the bidder can match the Google User ID specified in google_gid with their cookie data in their match table. In addition, they can determine that the Google-hosted match table and user list operations were successful. As a consequence, any Pretargeting the bidder configured to target the specified user list ID will now cause the bidder to receive bid requests for impressions from the user. Likewise, in these bid requests, the bidder will receive their hosted match data in BidRequest.user.buyeruid .