تطبیق کوکی

تطبیق کوکی ویژگی‌ای است که به شما امکان می‌دهد کوکی خود را - به عنوان مثال، شناسه کاربری که وب‌سایت شما را مرور کرده است - با شناسه کاربر Google خاص پیشنهاد دهنده مطابقت دهید و فهرست‌های کاربری بسازید که می‌تواند به شما کمک کند انتخاب‌های پیشنهادی مؤثرتری داشته باشید. این راهنما مفاهیم مورد استفاده در Cookie Matching و همچنین گردش‌های کاری مختلف Cookie Matching و هر گونه تغییراتی که ممکن است برای موارد استفاده خاص داشته باشند را شرح می‌دهد.

مفاهیم

تطبیق کوکی چیست؟

صاحبان دامنه معمولاً محتویات کوکی ها را برای کاربرانی که سایت آنها را مرور می کنند تنظیم می کنند که برای شناسایی کاربران در آن دامنه استفاده می شود. حتی اگر دو صاحب دامنه در غیر این صورت با مبادله این داده ها موافقت کنند، مدل امنیتی مرورگرهای اینترنتی فرد را از خواندن کوکی تنظیم شده توسط دامنه دیگر محدود می کند.

در زمینه تبلیغات دیجیتال، Google کاربران را با کوکی‌هایی که به دامنه doubleclick.net تعلق دارند شناسایی می‌کند و پیشنهاد دهندگانی که در مناقصه بلادرنگ شرکت می‌کنند ممکن است دامنه خود را داشته باشند که در آن تعدادی از کاربرانی را که می‌خواهند تبلیغات نشان دهند شناسایی می‌کنند. تطبیق کوکی به پیشنهاددهنده امکان می‌دهد کوکی‌های خود را با کوکی‌های Google تطبیق دهد، به طوری که آنها می‌توانند تعیین کنند که آیا نمایش ارسال شده در یک درخواست پیشنهاد با یکی از کاربران مورد هدف مرتبط است یا خیر، آنها داده‌های کوکی خود را دریافت خواهند کرد یا یک شناسه کاربر Google خاص پیشنهاد دهنده را دریافت خواهند کرد. که یک فرم رمزگذاری شده از کوکی doubleclick.net در درخواست پیشنهاد است.

سرویس تطبیق کوکی که در این راهنما توضیح داده شده است، ایجاد و حفظ ارتباط بین کوکی پیشنهاددهنده و شناسه کاربری Google را تسهیل می‌کند، و همچنین به فرد اجازه می‌دهد لیست‌های کاربران را پر کند.

جداول مطابقت

یک جدول تطبیق می تواند برای نگاشت یک شناسه یا داده های دیگر از یک دامنه به دامنه دیگر استفاده شود. مناقصه‌دهندگان می‌توانند از سرویس تطبیق کوکی‌ها برای پر کردن جدول‌های تطبیق خود با نگاشت کوکی خود برای یک کاربر معین در شناسه کاربر Google کاربر، یا برای پر کردن جدول تطبیق میزبانی شده توسط Google استفاده کنند. جداول تطبیق برای برنامه مناقصه‌دهنده برای دسترسی به داده‌های کوکی برای کاربر که برداشت نشان داده می‌شود، ضروری است.

جداول مسابقه میزبانی شده توسط گوگل

برای نگهداری آسان‌تر، بهبود تأخیر، و دسترسی به داده‌های مطابقت برای کاربران در مناطق خاص، توصیه می‌شود به Google اجازه دهید جدول مسابقه شما را میزبانی کند. این به شما امکان می‌دهد یک رشته رمزگذاری شده مبتنی بر وب ایمن (که از این به بعد به عنوان داده‌های بازی میزبانی‌شده نامیده می‌شود) را مشخص کنید که به شناسه کاربری Google برای یک کاربر معین نگاشت می‌شود. هنگامی که یک مسابقه ایجاد شد، می توان از آن به روش های زیر استفاده کرد:

• مناقصه بلادرنگ : در درخواست‌های پیشنهادی بعدی برای نمایش‌های مرتبط با کاربر، Google داده‌های بازی میزبانی‌شده را که با شناسه کاربری Google آنها مطابقت داده‌اید برای شما ارسال می‌کند. در پیاده سازی OpenRTB گوگل، BidRequest.user.buyeruid این را به عنوان یک رشته کدگذاری شده با پایه 64 ایمن وب مشخص می کند. اگر نقطه پایان مناقصه شما برای استفاده از پروتکل منسوخ شده Google RTB پیکربندی شده است، آن را به صورت بایت های رمزگشایی شده از طریق فیلد BidRequest.hosted_match_data دریافت خواهید کرد.

• فهرست‌های کاربر : فهرست‌های کاربران را می‌توان با شناسه‌های کاربری Google یا داده‌های بازی میزبانی شده پر کرد.

• پیش هدف گذاری : می توانید پیش هدف گذاری خود را به گونه ای پیکربندی کنید که فقط درخواست های پیشنهادی حاوی داده های مسابقه میزبانی شده را دریافت کنید. این می تواند برای حذف برداشت های کمتر مرتبط برای کاربران خارج از فضای کوکی شما استفاده شود.

لیست های کاربران

لیست‌های کاربر را می‌توان با API پیشنهادی بلادرنگ ایجاد و مدیریت کرد. پس از ایجاد، می‌توانید این فهرست‌ها را با گردش‌های کاری تطبیق کوکی که در زیر توضیح داده شده است، یا از طریق سرویس آپلود انبوه پر کنید.

شروع به کار

برای شروع با Cookie Matching، باید با مدیر حساب فنی خود تماس بگیرید، که می‌تواند گردش‌های کاری خاص را فعال کند و به شما در پیکربندی موارد زیر کمک کند:

• شناسه شبکه تطبیق کوکی (NID) : شناسه رشته ای که منحصراً یک حساب پیشنهاد دهنده برای تطبیق کوکی و سایر عملیات مرتبط را شناسایی می کند.
• نشانی اینترنتی تطبیق کوکی : نشانی وب پایه برای نقطه پایانی که درخواست‌های دریافتی را به عنوان بخشی از گردش‌های کاری تطبیق کوکی می‌پذیرد و رسیدگی می‌کند. پیشنهاد دهندگان می توانند ماکروها را در این URL جاسازی کنند تا ترتیب پارامترهای ارسال شده به آن را در گردش کار Cookie Matching کنترل کنند.
• Match Tag : برچسبی که باید در مرورگر کاربر برای گردش کار Cookie Matching آغاز شده توسط پیشنهاد دهنده قرار دهید. این را می توان در کنار تبلیغات ارائه کرد یا در ویژگی های وب خارج از تبلیغات قرار داد.
• URL گزارش تطبیق کوکی (اختیاری): در گردش کار تطبیق کوکی یک جهته، این یک URL اختیاری است که می تواند برای تعیین نقطه پایانی ارائه شود که در صورت عدم موفقیت تطبیق کوکی از طریق تغییر مسیر HTTP 302، جزئیات خطا را دریافت می کند. به‌طور پیش‌فرض، پاسخ‌ها تنها در صورتی به این URL ارسال می‌شوند که در عملیات تطبیق کوکی خطایی وجود داشته باشد، اما پیشنهاددهنده ممکن است درخواست کند که تغییر مسیر همیشه ارسال شود.
• نشانی اینترنتی کمک تطبیق کوکی : برای صرافی‌هایی که گردش کار کمک تطبیق کوکی را اجرا می‌کنند، این نشانی وب پایه نقطه پایانی است که برای پاسخ به درخواست‌های دریافتی در نظر گرفته شده است.
• سهمیه کمک تطبیق کوکی : برای صرافی هایی که گردش کار کمک تطبیق کوکی را اجرا می کنند، این حداکثر تعداد درخواست هایی است که URL تطبیق کوکی آنها می تواند در هر ثانیه دریافت کند. این به منظور جلوگیری از بارگیری بیش از حد درخواست‌های CMA با درخواست‌ها، سرورهای صرافی است.

ماکروهای تطبیق کوکی

در هر یک از جریان‌های کاری Cookie Matching پشتیبانی شده، URL تطبیق کوکی پیشنهاددهنده معمولاً دارای پارامترهایی است که در یک سفارش غیر تضمینی اضافه شده‌اند. پیشنهاد دهندگان با ادغام هایی که به ترتیب ثابت پارامترها نیاز دارند، می توانند ماکروها را در URL تطبیق کوکی خود قرار دهند تا جایگذاری آنها را تضمین کنند.

ماکروهای پشتیبانی شده

پیشنهاد دهندگان می توانند به صورت اختیاری URL تطبیق کوکی خود را طوری پیکربندی کنند که یک یا چند ماکرو به شکل %%GOOGLE_<PARAM_NAME>%% یا %%GOOGLE_<PARAM_NAME>_PAIR%% داشته باشد. ماکروهای پشتیبانی شده و مقادیر گسترش یافته آنها عبارتند از:

مثال ماکرو

یک پیشنهاد دهنده دارای یک ادغام تطبیق کوکی با یک نقطه پایانی است که در https://user.bidder.com.cookies میزبانی می شود، و اجرای آنها به پارامترهای از پیش تعیین شده پیشنهاد دهنده علاوه بر پارامترهای Pixel Matching به ترتیب زیر نیاز دارد: 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 در حال حاضر از سه گردش کار برای موارد مختلف استفاده می کند که در زیر توضیح داده شده است.

پیشنهاد دهنده: تطبیق کوکی دو جهته

تطبیق کوکی دوطرفه به یک جریان کاری آغاز شده توسط پیشنهاددهنده اشاره دارد، جایی که آنها یک تگ مطابقت را در مرورگر کاربر قرار می دهند که آن را به Google هدایت می کند. این گردش کار به Google و پیشنهاد دهنده اجازه می دهد تا جداول مطابقت را پر کنند. در زیر یک مثال ساده از این گردش کار آورده شده است.

مرحله 1: تگ مسابقه را قرار دهید

برای شروع این جریان، پیشنهاد دهنده باید تگ مطابقت خود را به گونه ای قرار دهد که در مرورگر کاربر رندر شود. یک تگ تطبیق ساده که فقط شناسه کاربری Google را به پیشنهاد دهنده برمی گرداند ممکن است به صورت زیر ساختار یابد:

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

پارامترهای اضافی وجود دارد که می توانید در تگ مطابقت بگنجانید تا موارد استفاده مختلف را برآورده کنید. برای کسب اطلاعات بیشتر در مورد این پارامترها، به Match Tag URL Parameters مراجعه کنید.

مرحله 2: Google با تغییر مسیر از جمله داده های مطابقت پاسخ می دهد

تگ تطبیق باعث می‌شود سرویس تطبیق کوکی Google درخواستی از مرورگر کاربر دریافت کند که یک تغییر مسیر HTTP 302 به URL تطبیق کوکی پیشنهاد دهنده صادر می‌کند. تغییر مسیر شامل پارامترهای پرس و جو می شود که شناسه کاربری Google و شماره نسخه آن را در URL مشخص می کند و پیشنهاد دهنده کوکی خود را که در سرصفحه های درخواست موجود است نیز دریافت می کند. در عمل، برای URL منطبق با کوکی که به‌عنوان https://ad.network.com/pixel مشخص شده است، نشانی اینترنتی تغییر مسیر برای برچسب تطبیق ساده همانطور که در بالا مشاهده می‌شود می‌تواند به شکل زیر باشد:

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

شناسه کاربر Google که از طریق پارامتر google_gid ارسال می‌شود، یک رشته رمزگذاری‌شده مبتنی بر وب بی‌خطر است. برای مناقصه‌دهندگانی که برای میزبانی میز مسابقه انتخاب می‌کنند، توصیه می‌شود که رشته‌ای را که توسط سرویس تطبیق کوکی بازگردانده شده است، ذخیره کنند. در درخواست‌های پیشنهادی بعدی، این با مقادیر مشخص‌شده از طریق BidRequest.user.id در OpenRTB یا BidRequest.google_user_id در پروتکل منسوخ شده Google RTB مطابقت دارد.

نسخه مشخص شده در google_cver شماره نسخه عددی شناسه کاربری Google را نشان می دهد. شناسه کاربری Google برای یک کاربر خاص به ندرت تغییر می‌کند و پس از آن این مقدار افزایش می‌یابد.

اگر Google هنگام پردازش درخواست مطابقت شما با خطا مواجه شود، در عوض یک پارامتر google_error مشخص می‌شود.

مرحله 3: مناقصه‌گر تغییر مسیر را پردازش می‌کند و با پیکسل پاسخ می‌دهد

پیشنهاد دهنده یک تغییر مسیر به URL مطابق کوکی خود شامل پارامترهایی که در مرحله اول مشخص کرده است و پارامترهایی که Google در مرحله دوم ارائه کرده است دریافت می کند. علاوه بر این، آنها کوکی خود را در هدرهای HTTP نیز دریافت خواهند کرد. اگر عملیات موفقیت‌آمیز بود، پیشنهاد دهنده‌ای که میز تطابق خود را میزبانی می‌کند، می‌تواند کوکی خود را با شناسه کاربر Google موجود در پاسخ مطابقت دهد. توصیه می شود که پیشنهاد دهندگان رشته دقیقی را که توسط سرویس تطبیق کوکی برگردانده شده است ذخیره کنند.

اگر عملیات ناموفق بود، پیشنهاد دهنده یک پارامتر google_error در تغییر مسیر دریافت می کند. این یک مقدار عددی مربوط به حالت های خطای مختلف است که خطای خاصی را که رخ داده است مشخص می کند. در اینجا می‌توانید درباره مقادیر خطای احتمالی اطلاعات بیشتری کسب کنید. اگر خطایی دریافت کردید، می‌توانید با قرار دادن یک تگ مطابقت جدید، دوباره برای آن کاربر مطابقت کنید.

پیشنهاد دهنده باید همیشه با ارائه یک تصویر پیکسل نامرئی 1×1 پاسخ دهد، یا در عوض یک پاسخ HTTP 204 بدون محتوا را برگرداند.

نمودار گردش کار تطبیق کوکی

این گردش کار با نمودار زیر نشان داده شده است، جایی که درخواست‌ها و پاسخ‌ها با یک فلش نشان داده می‌شوند و اقلام داده‌ای که با آنها همراه هستند در داخل پرانتز فهرست شده‌اند.

مطابقت با پارامترهای URL برچسب

علاوه بر پارامترهای فوق، پیشنهاد دهندگان ممکن است پارامترهای خود را مشخص کنند که به عنوان پارامتر به URL تغییر مسیر اضافه می شود. توجه داشته باشید که پارامترهای مناقصه‌گذار که با پیشوند google_ نام‌گذاری شده‌اند نادیده گرفته می‌شوند، زیرا این پارامترها توسط Google برای توسعه آینده رزرو شده‌اند و حفظ ترتیب پارامترها تضمین نمی‌شود. یک برچسب تطبیق شامل پارامترهای تعیین شده توسط پیشنهاد دهنده ممکن است به شکل زیر باشد:

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

تغییر مسیر پارامترهای URL

URL تغییر مسیر از URL اصلی تطبیق کوکی که برای حساب پیشنهاد دهنده پیکربندی شده است، شامل google_ و پارامترهای تعیین شده توسط پیشنهاد دهنده بسته به مواردی که در تگ مطابقت مشخص شده است، ساخته شده است. پارامترهای پاسخ google_ زیر تعریف شده است:

سناریوهای نمونه گردش کار تطبیق کوکی

سناریوهای زیر توضیح می‌دهند که تطبیق کوکی‌ها برای یک کاربر معمولی که در حال مرور یک صفحه وب است چگونه به نظر می‌رسد.

سناریو 1: کاربر کوکی های خود را پاک می کند و یک سایت را مرور می کند

جین کش آنها را از همه کوکی ها پاک می کند. سپس از صفحه اصلی ExampleNews.com بازدید می کنند.

این چیزی است که اتفاق می افتد:

1. ExampleNews.com تبلیغات را از Google (Ad Manager) رندر می کند و فراخوانی می کند.
2. از آنجایی که واحد تبلیغات برای تخصیص پویا واجد شرایط است، Google درخواست‌های پیشنهاد قیمت را از طریق سرویس بیدرنگ مناقصه به FinestDSP و سایر پیشنهاد دهندگان ارسال می‌کند.
3. برنامه پیشنهادی FinestDSP درخواست پیشنهاد را دریافت و پردازش می کند و پاسخ پیشنهاد خود را ارسال می کند.
4. Google پاسخ‌های پیشنهادی را از مناقصه‌دهندگان دریافت می‌کند، از جمله پاسخ FinestDSP که تبلیغی را با برچسب مطابقت (پیکسل) مشخص می‌کند.
5. FinestDSP برنده حراج است. Google آگهی FinestDSP و تگ مطابقت را به جین ارائه می کند.
6. تگ مطابقت با مشخص کردن پارامترهای google_nid و google_cm ، سرویس Google's Cookie Match را فراخوانی می‌کند.
7. سرویس Cookie Match کوکی گوگل جین را می خواند و مرورگر جین را با تنظیم پارامترهای google_gid و google_cver به URL تطبیق کوکی FinestDSP تغییر مسیر می دهد.
8. مرورگر جین تغییر مسیر را به URL مطابقت کوکی FinestDSP بارگیری می کند.
9. نقطه پایانی تطبیق کوکی FinestDSP درخواست تغییر مسیر را پردازش می کند که شامل پارامترهای URL تنظیم شده توسط Google و کوکی آنها برای Jane در هدرهای HTTP است. FinestDSP اکنون می تواند نگاشت کوکی خود را در google_gid در جدول تطبیق خود ذخیره کند.
10. FinestDSP با یک پیکسل نامرئی 1x1 به تغییر مسیر پاسخ می دهد.

سناریو 2: کاربر با نقشه های موجود

یک هفته پس از سناریو 1، جین دوباره از ExampleNews.com بازدید می کند. اکنون که جین هم کوکی‌های مناقصه‌دهنده و هم کوکی‌های Ad Manager را روی دستگاه خود دارد، در اینجا نحوه کار تطبیق آمده است.

1. صفحه وب رندر می شود و باعث می شود Google (Ad Manager) تبلیغاتی را که در صفحه نمایش داده می شود درخواست کند.
2. در طول حراج آگهی، Google یک درخواست پیشنهاد برای پیشنهاد دهندگان قابل اجرا، از جمله FinestDSP ارسال می کند.
3. FinestDSP درخواست پیشنهاد را دریافت می کند، از جمله سیگنال هایی مانند google_gid .
4. FinestDSP google_gid در جدول تطبیق خود جستجو می کند و کوکی مرتبط با جین را که یک هفته قبل (در سناریو 1) ایجاد شده است، پیدا می کند.
5. بر اساس اطلاعات مرتبط با کوکی، منطق مناقصه FinestDSP پیشنهادی را بر روی نمایش قرار می دهد و برنده حراج می شود.
6. جین ممکن است بر اساس اطلاعاتی که FinestDSP دارد، آگهی متناسب با علایق آنها ببیند.

پیشنهاد دهنده: تطبیق کوکی یک طرفه

تطبیق کوکی یک جهته مشابه گردش کار دوطرفه است، با این تفاوت که به گونه‌ای تغییر می‌کند که فقط Google یک جدول مطابقت را میزبانی و پر می‌کند. این را می توان در مواردی استفاده کرد که پیشنهاد دهنده مجاز نیست شناسه های کاربر Google را در جدول مطابقت خود میزبانی کند. برای استفاده از این جریان، پیشنهاد دهندگان باید به Google اجازه دهند تا جدول مسابقه را میزبانی کند، دیگر نمی‌توانند google_cm در درخواست‌های سرویس تطبیق کوکی Google مشخص کنند، و در نتیجه google_gid برای پر کردن جدول مطابقت خود دریافت نخواهند کرد. هنگامی که Google برای یک کاربر مطابقت ایجاد کرد، پیشنهاد دهندگان می‌توانند با استفاده از داده‌های کوکی خود، آنها را به فهرست کاربران اضافه کنند. به طور مشابه، درخواست‌های پیشنهاد برای این کاربران، شناسه کاربری Google را حذف می‌کنند، اما شامل داده‌های مطابقت میزبانی‌شده می‌شوند. یک مثال ساده از گردش کار اصلاح شده در مراحل زیر خلاصه شده است.

مرحله 1: تگ تطبیق را در آدرس اینترنتی تطبیق کوکی پیشنهاد دهنده قرار دهید

برای شروع این جریان، پیشنهاد دهنده باید تگ تطبیق را طوری قرار دهد که در مرورگر کاربر رندر شود. برخلاف گردش کار برای کاربرانی که از ایالت های ایالات متحده با محدودیت های حریم خصوصی نیستند، تگ مطابقت باید مرورگر کاربر را به URL تطبیق کوکی شما هدایت کند. به عنوان مثال، با یک URL تطبیق کوکی که به صورت https://ad.network.com/pixel پیکربندی شده است، به نظر می رسد:

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

هنگام بارگیری در مرورگر کاربر، یک پیکسل از URL تطبیق کوکی پیشنهاد دهنده درخواست می کند. این درخواست حاوی کوکی آنها در هدر HTTP است که باید برای مرحله بعدی استخراج شود.

مرحله 2: به سرویس Google's Cookie Matching هدایت شوید

نقطه پایانی تطبیق کوکی پیشنهاد دهنده باید به سرویس Google's Cookie Matching هدایت شود، از جمله پارامتر google_hm که با داده‌های کوکی کدگذاری شده با پایگاه 64 ایمن وب وی پر شده است. URL تغییر مسیر ممکن است به شکل زیر باشد:

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

مرحله 3: مرورگر کاربر به سرویس Google's Cookie Matching هدایت می شود

Google یک تغییر مسیر حاوی پارامترهایی که شما مشخص کرده‌اید، به اضافه کوکی Google در سرصفحه‌های HTTP دریافت می‌کند.

مرحله 4: اگر نشانی اینترنتی گزارش مشخص شده باشد، Google در صورت موفقیت یا خطا، پیکسل را ارائه می دهد

اگر عملیات تطبیق کوکی موفقیت آمیز باشد - یا اگر هیچ نشانی اینترنتی گزارش تطبیق کوکی برای حساب پیشنهاد دهنده مشخص نشده باشد - Google به طور پیش‌فرض یک پیکسل شفاف 1x1 ارائه می‌کند و گردش کار در اینجا به پایان می‌رسد. نمایش‌های نشان‌داده‌شده برای این کاربر در درخواست‌های پیشنهادی بعدی شامل داده‌های مطابقت میزبانی شده پیشنهاددهنده در BidRequest.user.buyeruid برای OpenRTB یا BidRequest.hosted_match_data برای پروتکل منسوخ شده Google RTB خواهد بود. پیشنهاد دهندگان همچنین می توانند لیست های کاربران را با استفاده از داده های بازی میزبانی شده که مشخص کرده اند پر کنند.

در غیر این صورت، اگر خطایی رخ داده باشد، Google یک تغییر مسیر به نشانی اینترنتی گزارش تطبیق کوکی پیشنهاد دهنده با دلیل خطای مشخص شده در پارامتر google_error ارسال می کند. اگر نشانی وب گزارش تطبیق کوکی پیشنهاد دهنده https://ad.network.com/report باشد، نشانی اینترنتی تغییر مسیر به این صورت خواهد بود:

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

مرحله 5: مرورگر کاربر به URL گزارش تطبیق کوکی پیشنهاد دهنده هدایت می شود

مرورگر کاربر به نشانی اینترنتی گزارش تطبیق کوکی پیشنهاد دهنده، از جمله دلیل خطا (در صورت وجود) که توسط Google در پارامتر google_error مشخص شده است، هدایت می شود. برای کسب اطلاعات بیشتر در مورد تفسیر کد خطا، به توضیحات پارامتر مراجعه کنید.

مرحله 6: پیشنهاد دهنده پیکسل شفاف 1x1 را ارائه می دهد

پیشنهاد دهنده باید با ارائه یک پیکسل شفاف 1x1 به مرورگر کاربر پاسخ دهد.

نمودار گردش کار تطبیق کوکی برای کاربران ایالت های ایالات متحده با محدودیت های حریم خصوصی

گردش کار پیش‌فرض برای کاربران در ایالت‌های ایالات متحده با محدودیت‌های حریم خصوصی با نمودار زیر نشان داده شده است، جایی که درخواست‌ها و پاسخ‌ها با یک فلش نشان داده می‌شوند، و اقلام داده‌ای که آنها را همراهی می‌کنند در پرانتز فهرست شده‌اند.

پارامترهای URL برای پیشنهاد دهنده به سرویس تطبیق کوکی Google هدایت می شود

پارامترهای URL برای Google به URL گزارش تطبیق کوکی پیشنهاد دهنده هدایت می‌شوند

توسط Google: تطبیق پیکسل دو جهته

تطبیق پیکسلی دوطرفه یک گردش کاری برای سرویس تطبیق کوکی Google است که در آن Google تلاش می‌کند شناسه کاربری Google را با پیشنهاددهنده‌ای که به‌طور الگوریتمی انتخاب شده به غیر از برنده مزایده بی‌درنگ، مطابقت دهد. هنگامی که یک تبلیغ قرار می گیرد، Google یک تگ تطبیقی ​​قرار می دهد که مرورگر کاربر را هدایت می کند تا یک پیکسل شفاف از URL تطبیق کوکی پیشنهاد دهنده منتخب بارگیری کند. این کار هم گوگل و هم پیشنهاد دهنده را قادر می‌سازد تا جدول تطبیقی ​​را با کاربر مشخصی پر کنند. در زیر یک مثال ساده از این گردش کار آورده شده است.

مرحله 1: گوگل یک تگ مسابقه قرار می دهد

وقتی صفحه ناشر شرکت‌کننده در مرورگر کاربر بارگیری می‌شود، و یک جایگاه تبلیغاتی در آن صفحه توسط Google پر می‌شود، ممکن است یک برچسب تطبیقی ​​قرار داده شود که از یک پیشنهاددهنده الگوریتمی انتخاب شده یک پیکسل درخواست می‌کند. تگ Pixel Matching که توسط Google قرار داده شده است، URL تطبیق کوکی پیشنهاد دهنده را با پارامترهای اضافی ترکیب می کند که پیشنهاد دهنده می تواند برای پر کردن جدول مطابق خود از آنها استفاده کند. برای یک URL تطبیق کوکی که به عنوان https://ad.network.com/pixel مشخص شده است، ساختار آن به صورت زیر است:

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

مرحله 2: پیشنهاد دهنده باید با تغییر مسیر به URL سرویس تطبیق کوکی Google پاسخ دهد

مناقصه‌گرانی که درخواست‌های تطبیق پیکسل را دریافت می‌کنند، باید با تغییر مسیر به سرویس تطبیق کوکی Google که ساختار آن به‌صورت زیر است، پاسخ دهند:

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

توجه داشته باشید که URL تغییر مسیر فوق مشابه URL مورد استفاده در تگ تطبیق برای گردش کار تطبیق کوکی های آغاز شده توسط Bidder است. در Pixel Matching، پارامتر google_cm با پارامتر google_push جایگزین می شود و مقدار آن باید برابر با مقدار ارائه شده توسط Google در درخواست باشد. همچنین مشابه گردش کار آغاز شده توسط پیشنهاد دهنده، پارامترهای اضافی را می توان برای انجام موارد استفاده اضافی مشخص کرد.

مرحله 3: گوگل تغییر مسیر را پردازش می کند و با پیکسل پاسخ می دهد

Google گزارش می دهد که یک مطابقت برای کاربر ایجاد شده است، و هرگونه عملیات اضافی درخواست شده را از طریق پارامترهای پرس و جو انجام می دهد در نهایت، Google با یک پیکسل شفاف 1x1 پاسخ می دهد.

نمودار گردش کار مطابق با پیکسل

این گردش کار با نمودار زیر نشان داده شده است، جایی که درخواست‌ها و پاسخ‌ها با یک فلش نشان داده می‌شوند و اقلام داده‌ای که با آنها همراه هستند در داخل پرانتز فهرست شده‌اند.

پارامترهای درخواست تگ مطابقت Google

پارامترهای تغییر مسیر مطابق با پیکسل مناقصه

ایجاد شده توسط Google: تطبیق پیکسل یک طرفه

تطبیق پیکسل یک طرفه با گردش کار دو طرفه متفاوت است زیرا برچسب Google's Tag شامل پارامتری نیست که شناسه کاربر Google را مشخص می کند ، اما همچنان به جمع یک جدول مسابقه میزبان Google ادامه خواهد داد. این می تواند در مواردی که پیشنهاد دهنده مجاز به میزبانی شناسه های کاربر Google در جدول مسابقه خودشان نیست ، استفاده شود. یک نمونه ساده از گردش کار اصلاح شده در مراحل زیر خلاصه شده است.

مرحله 1: Google یک برچسب مسابقه را قرار می دهد

Google یک برچسب مسابقه را برای یک پیشنهاد دهنده انتخاب شده الگوریتمی قرار می دهد. برچسب مسابقه شامل پارامتر google_push است. در اینجا یک مثال است:

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

مرحله 2: مرورگر کاربر پیکسل را از URL تطبیق پخت و پز پیشنهاد دهنده درخواست می کند

مرورگر کاربر درخواست پیکسل از URL تطبیق کوکی پیشنهاد دهنده ، از جمله کوکی پیشنهاد دهنده در هدر HTTP دارد.

مرحله 3: به سرویس تطبیق کوکی Google تغییر مسیر دهید

نقطه پایانی کوکی پیشنهاد دهنده باید به سرویس تطبیق کوکی Google ، از جمله پارامتر google_hm که با داده های کوکی رمزگذاری شده با وب سایت خود اختصاص داده شده است ، هدایت کند. URL تغییر مسیر ممکن است مانند موارد زیر به نظر برسد:

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

مرحله 4: مرورگر کاربر به سرویس تطبیق کوکی Google هدایت می شود

Google علاوه بر کوکی Google در عناوین HTTP ، یک تغییر مسیر حاوی پارامترهایی را که مشخص کرده اید دریافت می کند. اگر این عملیات موفقیت آمیز بود ، برداشت برای این کاربر در درخواست های پیشنهادی بعدی شامل داده های مسابقه میزبان پیشنهاد دهنده در BidRequest.user.buyeruid برای OpenRTB یا BidRequest.hosted_match_data برای پروتکل RTB کاهش یافته Google است. داوطلبان همچنین می توانند لیست های کاربر را با استفاده از داده های مطابقت میزبانی شده که مشخص کرده اند جمع کنند.

سرانجام ، Google یک پیکسل شفاف 1x1 را به مرورگر کاربر باز می گرداند.

کمک مسابقه کوکی

مناقصه باز به مبادلات اجازه می دهد تا از محل کار با پیشنهاد دهنده استفاده کنند و Google با شروع گردش کار کوکی را آغاز کنند تا یک شناسه کاربر Google را با کوکی خود مطابقت دهند. کوکی Match Assist (CMA) یک ویژگی اضافی برای صرافی ها است که آنها را قادر می سازد تا میزهای مسابقه را با داوطلبان خود بسازند.

چگونه کمک کوکی کبریت کار می کند

1. هنگام قرار دادن یک آگهی ، Google به صورت الگوریتمی یک تبادل شرکت کننده را انتخاب می کند و یک برچسب کمک کوکی را که ساختار زیر را دارد قرار می دهد:

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

2. برچسب CMA Match Google باعث می شود URL تطبیق کوکی Exchange یک درخواست پیکسل دریافت کند.

3. نقطه پایانی کوکی Exchange این درخواست را دریافت می کند ، جایی که سرویس تطبیق کوکی خود وظیفه تطبیق شناسه کاربر با یکی از داوطلبان خود را بر عهده دارد. در نمودار زیر ، سرویس تطبیق کوکی مبادله با تغییر مسیر به یکی از نقاط پایانی پیشنهاد دهنده خود به مرورگر کاربر پاسخ می دهد.
4. پیشنهاد دهنده درخواست را به همراه هر پارامتر مشخص شده توسط Exchange دریافت می کند تا شناسه کاربر را با کوکی خود مطابقت دهد.

محدودیت ها

فرکانس کلاه درخواست برای مسابقات تازه

داوطلبان وظیفه محدود کردن تعداد تماس های مربوط به سرویس تطبیق کوکی را برای کاربرانی که ورود تازه ای در جدول مسابقه میزبان Google دارند ، محدود می کنند. ورود در جدول مسابقه میزبان ممکن است در 14 روز منقضی شود که پس از آن می توان آن را تازه کرد.

به تمام درخواست های مطابقت پیکسل پاسخ دهید

انتظار می رود داوطلبان با استفاده از گردش کار تطبیق پیکسل با پاسخ از جمله پارامتر google_push به کلیه درخواست های مسابقه پیکسل ورودی پاسخ دهند. این به Google اجازه می دهد تا با نظارت بر استفاده ، سیاست ها را اجرا کند. اگر نرخ پاسخ داوطلب به زیر 90 ٪ کاهش یابد ، Google تعداد درخواست های مطابقت پیکسل را که به حساب آنها ارسال شده است ، باز می کند.

از نقاط پایانی HTTPS استفاده کنید

لازم است که نقاط پایانی مورد استفاده در تمام گردش کار تطبیق کوکی از HTTPS استفاده کنید.

هنگام پاسخ به درخواست مسابقه پیکسل که از طریق HTTPS برای شما ارسال شده است ، شما را ملزم به تغییر مسیر به سرویس تطبیق کوکی از طریق HTTPS می کنید. به همین ترتیب ، یک نقطه پایانی کوکی که به سمت داوطلبان هدایت می شود نیز باید از HTTPS استفاده کند. اگر بیشتر از هر 2 دقیقه درخواست هایی را از طریق HTTP به Google ارسال کنید ، تعداد درخواست های مسابقه ارسال شده به حساب شما مورد بررسی قرار می گیرد.

الزامات رضایت کاربر اتحادیه اروپا

درخواست های تطبیق کوکی که مشمول سیاست رضایت کاربر اتحادیه اروپا هستند باید رضایت کاربر نهایی را نشان دهند. چنین درخواست هایی لازم است تا نشان دهند که رضایت با استفاده از یکی از روشهای زیر جمع آوری شده است:

• TCFV2: این شامل پارامترهای gdpr و gdpr_consent است. برای جزئیات بیشتر ، با مستندات خریداران مجاز IAB TCF v2.0 مشورت کنید.
• process_consent : بیانیه ای مبنی بر اینکه داوطلب رضایت کاربر لازم را به دست آورده است.

نمونه ها

مثالهای زیر نحوه استفاده از سرویس تطبیق کوکی را برای دستیابی به اهداف خاص نشان می دهد. توجه داشته باشید که مگر اینکه در غیر این صورت بیان نشده باشد ، فرض بر این است که کاربر تحت عمل قرار می گیرد از یک کشور ایالات متحده با محدودیت های حریم خصوصی نیست.

یک میز مسابقه به میزبان پیشنهاد دهنده را جمع کنید

یک پیشنهاد دهنده می تواند با ارائه فقط پارامترهای google_nid و google_cm در برچسب مسابقه خود ، از گردش کار تطبیق کوکی برای جمع آوری جدول بازی خود استفاده کند. این ممکن است به نظر برسد:

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

اگر URL تطبیق کوکی پیشنهاد دهنده روی https://ad.network.com/pixel?id=1 تنظیم شده باشد ، و عملیات تطبیق کوکی موفقیت آمیز است ، تغییر مسیر Google در پاسخ به برچسب مسابقه پیشنهاد دهنده ممکن است به نظر برسد:

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

اگر عملیات تطبیق کوکی به دلیل عدم موفقیت کاربر کوکی گوگل انجام شود ، پاسخ این است:

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

کد خطا به علت اصلی خطا بستگی دارد. برای کسب اطلاعات بیشتر در مورد کدهای خطای احتمالی برای گردش کار تطبیق کوکی ، به پارامترهای URL تغییر مسیر مراجعه کنید.

به لیست کاربر تک اضافه کنید

پارامتر google_ula را می توان در برچسب مسابقه پیشنهاد دهنده مشخص کرد تا کاربر را با شناسه داده شده به لیست کاربر اضافه کند. اگر جدول مسابقه Google یا Bidder-به میزبانی ورودی تازه ای برای کاربر داشته باشد ، پیشنهاد دهنده می تواند یک برچسب مسابقه از جمله پارامترهای google_nid و google_ula را برای اضافه کردن کاربر به لیست مشخص شده بدون شروع گردش کار کامل کوکی اضافه کند. محدودیت های فراخوانی سرویس تطبیق کوکی را برای DEAIL های بیشتر مشاهده کنید. برچسب مسابقه مربوطه ممکن است به نظر برسد:

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

برای پاسخ موفق ، جایی که URL مطابق با کوکی پیشنهاد دهنده https://ad.network.com/pixel است ، URL تغییر مسیر Google خواهد بود:

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

اگر یک خطای کلی وجود داشته باشد - به عنوان مثال ، هیچ کوکی Google برای کاربر وجود ندارد - URL تغییر مسیر شامل پارامتر google_error است:

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

اگر خطایی در مورد اضافه کردن کاربر به لیست خطایی وجود داشته باشد ، google_ula در تغییر مسیر دریافت خواهید کرد. بر خلاف پارامتر برچسب تطابق مربوطه ، این جایگزین Timestamp با کد وضعیت می شود تا موفقیت عملیات را نشان دهد. به عنوان مثال ، اگر درخواست به دلیل عدم دسترسی به حساب داوطلب به لیست کاربر مشخص شده ، URL تغییر مسیر باشد:

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" />

URL تغییر مسیر مشخص شده توسط Google شامل google_gid ، google_cver و google_ula است. این ممکن است مانند موارد زیر باشد:

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

ذخیره یک مسابقه در یک میز مسابقه میزبان Google

اگر یک پیشنهاد دهنده بخواهد داده های کوکی خود را در یک جدول مسابقه میزبان Google ذخیره کند ، و قصد ندارد در جدول بازی خود با شناسه کاربر Google مطابقت داشته باشد ، برچسب مسابقه آنها باید شامل پارامتر google_hm باشد که در آن مقدار آن باید یک وب باشد -Safe Base64 رمزگذاری شده. برای کاربر که داده های کوکی نامشخص پیشنهاد دهنده Cookie number 1! ، مقدار رمزگذاری شده Q29va2llIG51bWJlciAxIQ== خواهد بود ، که در یک برچسب مسابقه مانند موارد زیر استفاده می شود:

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

برای یک پاسخ موفق ، جایی که URL مطابق با کوکی پیشنهاد دهنده https://cookie-monster.com/pixel است ، URL تغییر مسیر Google خواهد بود:

https://cookie-monster.com/pixel

پارامتر google_gid در تغییر مسیر نیست زیرا برچسب مسابقه شامل google_cm نیست و google_hm در پاسخ های موفق گنجانده نشده است. در درخواست های پیشنهادی آینده برای برداشت برای این کاربر ، پیشنهاد دهنده داده های مسابقه میزبان خود را در BidRequest.user.buyeruid برای OpenRTB یا BidRequest.hosted_match_data برای پروتکل RTB کاهش یافته Google دریافت می کند.

اگر پیشنهاد دهنده به جای آن از یک برچسب مسابقه استفاده می کرد که در آن مقدار google_hm رمزگذاری شده Base64 نبود-از جمله chocolate_chunk! - URL تغییر مسیر ممکن است مانند موارد زیر به نظر برسد:

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

URL تغییر مسیر فوق شامل مقدار google_hm 2 است ، نشان می دهد که این عملیات شکست خورده است زیرا مقدار رمزگشایی نمی شود.

میزهای مسابقه داوطلب و میزبان Google با لیست های کاربر

اگر یک پیشنهاد دهنده علاوه بر لیست کاربر میزبان Google ، میزبان لیست استفاده خود باشد و یک برچسب تطبیق واحد را با هر دو جدول مطابقت داده و کاربر را به لیست کاربر مشخص اضافه کند ، برچسب مسابقه آنها باید شامل 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" />

برای پاسخ موفق ، جایی که URL مطابق با کوکی پیشنهاد دهنده https://cookie-monster.com/pixel است ، URL تغییر مسیر Google مانند موارد زیر خواهد بود:

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

در هنگام دریافت تغییر مسیر ، پیشنهاد دهنده می تواند با شناسه کاربر Google که در google_gid مشخص شده است با داده های کوکی خود در جدول مسابقه خود مطابقت دهد. علاوه بر این ، آنها می توانند تعیین کنند که جدول بازی میزبان Google و عملیات لیست کاربر موفقیت آمیز بوده است. به عنوان یک نتیجه ، هرگونه پیش نمایش پیشنهاد دهنده پیکربندی شده برای هدف قرار دادن شناسه لیست کاربر مشخص شده ، اکنون باعث می شود که پیشنهاد دهنده درخواست های پیشنهادی را برای برداشت از کاربر دریافت کند. به همین ترتیب ، در این درخواست های پیشنهادی ، داوطلب داده های مسابقه میزبان خود را در BidRequest.user.buyeruid برای OpenRTB یا BidRequest.hosted_match_data برای پروتکل RTB کاهش یافته دریافت می کند.

تطبیق کوکی ویژگی ای است که شما را قادر می سازد تا با کوکی خود مطابقت داشته باشید-برای مثال ، شناسه ای برای کاربر که وب سایت شما را مرور کرده است-با شناسه کاربر Google مخصوص پیشنهاد دهنده مربوطه ، و ساخت لیست های کاربر را ایجاد کنید که می تواند به شما در انتخاب پیشنهادات مؤثرتری کمک کند. این راهنما مفاهیم مورد استفاده در تطبیق کوکی ها ، و همچنین گردش کار های مختلف کوکی و هرگونه تغییر آنها را برای موارد خاص استفاده می کند.

مفاهیم

تطبیق کوکی چیست؟

صاحبان دامنه به طور معمول محتویات کوکی ها را برای کاربرانی که سایت خود را مرور می کنند ، تنظیم می کنند که برای شناسایی کاربران در آن دامنه استفاده می شود. حتی اگر دو صاحب دامنه در غیر این صورت با تبادل این داده ها موافقت کنند ، مدل امنیتی مرورگرهای اینترنتی یکی را از خواندن کوکی که توسط دامنه دیگری تعیین شده است محدود می کند.

در زمینه تبلیغات دیجیتال ، Google کاربرانی را با کوکی هایی که متعلق به دامنه doubleclick.net هستند ، شناسایی می کند و داوطلبان شرکت کننده در زمان واقعی ممکن است دامنه خاص خود را داشته باشند که در آنجا مجموعه ای از کاربران را که می خواهند تبلیغات خود را نشان دهند شناسایی می کنند. تطبیق کوکی ، پیشنهاد دهنده را قادر می سازد تا کوکی های خود را با Google مطابقت دهد ، به گونه ای که می تواند تعیین کند که آیا تصور ارسال شده در درخواست پیشنهاد با یکی از کاربران مورد هدف قرار می گیرد ، آنها داده های کوکی خود را دریافت می کنند یا یک شناسه کاربر Google خاص پیشنهاد دهنده این یک شکل رمزگذاری شده از کوکی doubleclick.net در درخواست پیشنهاد است.

سرویس تطبیق کوکی که در این راهنما شرح داده شده است ، ایجاد و حفظ ارتباط بین کوکی پیشنهاد دهنده و شناسه کاربر Google را تسهیل می کند ، و همچنین به یک نفر اجازه می دهد تا لیست های کاربر را جمع کند.

میزهای مطابقت

از یک جدول مسابقه می توان برای نقشه برداری شناسه یا داده های دیگر از یک دامنه به دامنه دیگر استفاده کرد. داوطلبان می توانند از سرویس تطبیق کوکی برای جمع آوری جداول مسابقه خود با نقشه برداری از کوکی خود برای کاربر خاص به شناسه کاربر Google کاربر استفاده کنند ، یا یک جدول مسابقه میزبان Google را جمع کنند. جداول مسابقه برای دسترسی به پیشنهادات داوطلب برای دسترسی به داده های کوکی برای کاربر که این تصور را نشان می دهد ، ضروری است.

جداول مسابقه میزبان Google

برای نگهداری آسان تر ، بهبود تأخیر و دسترسی به داده های مطابقت برای کاربران در مناطق خاص ، توصیه می شود که به Google اجازه دهید جدول مسابقه خود را میزبان کنید. این امر به شما امکان می دهد یک رشته رمزگذاری شده با پایه Web-Safe64 را مشخص کنید-از این پس به عنوان داده های مسابقه میزبان-که برای یک کاربر خاص به شناسه کاربر Google نقشه برداری می شود. پس از برقراری مسابقه ، می توان از روشهای زیر استفاده کرد:

• مناقصه در زمان واقعی : در درخواست های پیشنهادی بعدی برای برداشت های مرتبط با کاربر ، Google داده های مسابقه میزبان را که با شناسه کاربر Google خود مطابقت داده اید برای شما ارسال می کند. در اجرای OpenRTB Google ، BidRequest.user.buyeruid این را به عنوان یک رشته رمزگذاری شده Web-Safe64 مشخص می کند. اگر نقطه پایانی مناقصه شما برای استفاده از پروتکل مستهلک Google RTB پیکربندی شده باشد ، این مورد را به عنوان بایت رمزگشایی شده از طریق قسمت BidRequest.hosted_match_data دریافت خواهید کرد.

• لیست های کاربر : لیست های کاربر می توانند با شناسه های کاربر Google یا داده های مطابقت میزبان جمع شوند.

• پیش نمایش : شما می توانید پیش نمایش خود را به گونه ای پیکربندی کنید که فقط درخواست های پیشنهادی حاوی داده های مسابقه میزبان را دریافت کنید. این می تواند برای از بین بردن برداشت های کمتر مرتبط برای کاربران خارج از فضای کوکی شما استفاده شود.

لیست های کاربران

لیست های کاربر را می توان با API مناقصه در زمان واقعی ایجاد و مدیریت کرد. پس از ایجاد ، می توانید این لیست ها را با گردش کار تطبیق کوکی که در زیر شرح داده شده است ، یا از طریق سرویس بارگذاری فله جمع کنید.

شروع به کار

برای شروع کار با تطبیق کوکی ، باید با مدیر حساب فنی خود تماس بگیرید که می تواند گردش کار خاص را فعال کند و به شما در پیکربندی موارد زیر کمک کند:

• شناسه شبکه تطبیق کوکی (NID) : شناسه رشته ای که به طور منحصر به فرد یک حساب پیشنهاد دهنده برای تطبیق کوکی و سایر عملیات مرتبط را شناسایی می کند.
• URL تطبیق کوکی : URL پایه برای یک نقطه پایانی که درخواست های دریافتی را به عنوان بخشی از گردش کار تطبیق کوکی می پذیرد و کنترل می کند. داوطلبان می توانند ماکروها را در این URL تعبیه کنند تا ترتیب پارامترهای منتقل شده به آن در گردش کار تطبیق کوکی را کنترل کنند.
• برچسب مسابقه : برچسب شما باید در مرورگر کاربر برای گردش کار تطبیق کوکی با پیشنهاد دهنده قرار دهید. این را می توان در کنار تبلیغات سرو کرد ، یا در ویژگی های وب خارج از تبلیغات قرار داده شود.
• URL گزارش تطبیق کوکی (اختیاری): در گردش کار تطبیق کوکی یک طرفه ، این یک URL اختیاری است که می تواند برای مشخص کردن یک نقطه پایانی ارائه شود که در صورت عدم موفقیت تطبیق کوکی از طریق تغییر مسیر HTTP 302 ، جزئیات خطا را دریافت می کند. به طور پیش فرض ، در صورت بروز خطایی در عملیات تطبیق کوکی ، پاسخ ها فقط به این آدرس اینترنتی ارسال می شوند ، اما ممکن است پیشنهاد دهنده درخواست کند که این تغییر مسیر همیشه ارسال شود.
• URL Assist Cookie Match : برای مبادلات اجرای گردش کار Assist Cookie Match ، این URL پایه نقطه پایانی است که برای پاسخ به درخواست های دریافتی در نظر گرفته شده است.
• سهمیه کمک کوکی Match : برای مبادلات اجرای گردش کار Assist Cookie Match ، این حداکثر تعداد درخواستهایی است که URL مطابق با کوکی آنها می تواند هر ثانیه را دریافت کند. این در نظر گرفته شده است تا از درخواست های CMA از اضافه بار سرورهای مبادله با درخواست جلوگیری شود.

کوکی تطبیق ماکرو

در هر یک از گردش کار های تطبیق کوکی پشتیبانی شده ، URL تطبیق کوکی یک پیشنهاد دهنده به طور معمول دارای پارامترهایی است که در یک سفارش غیر ضمانت نامه ضمیمه شده است. داوطلبان با ادغام هایی که نیاز به سفارش مداوم پارامترها دارند می توانند ماکروها را در URL تطبیق کوکی خود قرار دهند تا جای خود را تضمین کنند.

ماکروهای پشتیبانی شده

داوطلبان می توانند به صورت اختیاری URL تطبیق کوکی خود را پیکربندی کنند تا یک یا چند ماکرو را در قالب %%GOOGLE_<PARAM_NAME>%% یا %%GOOGLE_<PARAM_NAME>_PAIR%% درج کنند. ماکروهای پشتیبانی شده و مقادیر گسترده آنها عبارتند از:

نمونه کلان

یک پیشنهاد دهنده دارای ادغام تطبیق کوکی با یک نقطه پایانی است که در 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%%

هنگامی که گوگل بعداً درخواست مسابقه را به این پیشنهاد دهنده ارسال می کند ، به مواردی مانند موارد زیر گسترش می یابد:

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 در حال حاضر از سه گردش کار برای موارد مختلف استفاده که در زیر شرح داده شده است ، پشتیبانی می کند.

پیشنهاد دهنده: تطبیق کوکی دو طرفه

تطبیق کوکی دو طرفه به یک گردش کار با پیشنهاد دهنده مراجعه کننده اشاره دارد ، جایی که آنها یک برچسب مسابقه را در مرورگر کاربر قرار می دهند که آن را به Google هدایت می کند. این گردش کار به Google و پیشنهاد دهنده اجازه می دهد تا جداول مسابقه را جمع کنند. در زیر یک نمونه ساده از این گردش کار آورده شده است.

مرحله 1: برچسب مسابقه را قرار دهید

برای شروع این جریان ، پیشنهاد دهنده باید برچسب مسابقه خود را به گونه ای قرار دهد که در مرورگر کاربر ارائه شود. یک برچسب تطابق ساده که فقط شناسه کاربر Google را به پیشنهاد دهنده برمی گرداند ممکن است به شرح زیر باشد:

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

پارامترهای اضافی وجود دارد که می توانید در برچسب مسابقه قرار دهید تا موارد استفاده متفاوتی را انجام دهید. برای کسب اطلاعات بیشتر در مورد این پارامترها ، به پارامترهای URL Tag Tag Tag مراجعه کنید.

مرحله 2: گوگل با تغییر مسیر از جمله داده های مطابقت پاسخ می دهد

برچسب مسابقه باعث می شود سرویس تطبیق کوکی Google درخواستی از مرورگر کاربر دریافت کند ، که یک تغییر مسیر HTTP 302 را به آدرس URL تطبیق کوکی پیشنهاد دهنده صادر می کند. تغییر مسیر شامل پارامترهای پرس و جو است که شناسه کاربر Google و شماره نسخه آن را در URL مشخص می کند ، و پیشنهاد دهنده نیز کوکی خود را موجود در هدرهای درخواست دریافت می کند. در عمل ، برای یک URL تطبیق کوکی که به عنوان https://ad.network.com/pixel مشخص شده است ، URL تغییر مسیر برای برچسب مسابقه ساده همانطور که در بالا مشاهده می شود می تواند مانند موارد زیر باشد:

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

شناسه کاربر Google که از طریق پارامتر google_gid منتقل شده است ، یک رشته بدون سیستم ایمن از وب است. برای داوطلبان تصمیم به میزبانی یک جدول مسابقه ، توصیه می شود که آنها رشته دقیقی را که توسط سرویس تطبیق کوکی بازگردانده شده است ، ذخیره کنند. در درخواست های پیشنهادی بعدی ، این با مقادیر مشخص شده از طریق BidRequest.user.id در OpenRTB یا BidRequest.google_user_id در پروتکل RTB کاهش یافته Google مطابقت دارد.

نسخه مشخص شده در google_cver شماره نسخه عددی را برای شناسه کاربر Google نشان می دهد. شناسه کاربر Google برای یک کاربر خاص به ندرت تغییر می کند ، پس از آن این افزایش می یابد.

اگر Google هنگام پردازش درخواست مسابقه خود با خطایی روبرو شود ، در عوض یک پارامتر google_error مشخص می شود.

مرحله 3: فرآیندهای پیشنهاد دهنده تغییر مسیر داده و با پیکسل پاسخ می دهند

داوطلب تغییر مسیر به URL تطبیق کوکی خود از جمله پارامترهایی که در مرحله اول مشخص کرده اند ، و آنهایی که Google در مرحله دوم ارائه شده است ، دریافت می کند. علاوه بر این ، آنها همچنین کوکی خود را در هدرهای HTTP دریافت می کنند. اگر این عملیات موفقیت آمیز بود ، یک پیشنهاد دهنده میزبان میز مسابقه خود می تواند با کوکی آنها با شناسه کاربر Google که در پاسخ قرار دارد مطابقت داشته باشد. توصیه می شود که داوطلبان رشته دقیقی را که توسط سرویس تطبیق کوکی بازگردانده شده است ، ذخیره کنند.

اگر این عملیات ناموفق باشد ، داوطلب یک پارامتر google_error را در تغییر مسیر دریافت می کند. این یک مقدار عددی است که مربوط به خطای مختلف است که خطای خاصی را که رخ داده است شناسایی می کنند. می توانید در مورد مقادیر خطای احتمالی در اینجا اطلاعات بیشتری کسب کنید. اگر خطایی دریافت کردید ، ممکن است با قرار دادن یک برچسب مسابقه جدید ، دوباره برای آن کاربر مطابقت داشته باشید.

پیشنهاد دهنده همیشه باید با ارائه یک تصویر پیکسل 1x1 نامرئی پاسخ دهد ، یا در عوض پاسخ HTTP 204 بدون پاسخ محتوا را برگرداند.

نمودار گردش کار تطبیق کوکی

این گردش کار توسط نمودار زیر نشان داده شده است ، جایی که درخواست ها و پاسخ ها توسط یک فلش نشان داده می شوند ، و موارد داده ای که همراه با آنها هستند در پرانتز ذکر شده اند.

پارامترهای URL برچسب مطابقت

علاوه بر پارامترهای فوق ، داوطلبان ممکن است خود را مشخص کنند ، که به عنوان پارامترهای URL تغییر مسیر ضمیمه می شوند. توجه داشته باشید که پارامترهای تعریف شده پیشنهاد شده با پیشوند google_ نادیده گرفته می شوند زیرا این موارد توسط Google برای توسعه آینده محفوظ است و حفظ سفارش پارامترها تضمین نمی شود. برچسب مسابقه شامل پارامترهای تعریف شده پیشنهاد دهنده ممکن است به نظر برسد:

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

پارامترهای URL را هدایت کنید

URL تغییر مسیر از URL تطبیق کوکی پایه ساخته شده است که برای حساب پیشنهاد دهنده تنظیم شده است ، از جمله google_ و پارامترهای تعریف شده پیشنهاد شده بسته به موارد مشخص شده در برچسب مسابقه. پارامترهای پاسخ google_ زیر تعریف شده است:

سناریوهای مثال گردش کار تطبیق کوکی

سناریوهای زیر توضیح می دهد که تطبیق کوکی ممکن است برای یک کاربر معمولی که در یک صفحه وب مرور می کند ، باشد.

سناریو 1: کاربر کوکی های خود را پاک می کند و یک سایت را مرور می کند

جین حافظه پنهان همه کوکی ها را پاک می کند. آنها سپس به صفحه اصلی Examplenews.com مراجعه می کنند.

این چیزی است که اتفاق می افتد:

1. Examplenews.com ارائه می دهد و تبلیغات را از Google (مدیر تبلیغات) فراخوانی می کند.
2. از آنجا که واحد تبلیغاتی واجد شرایط تخصیص پویا است ، Google از طریق سرویس مناقصه در زمان واقعی درخواست های پیشنهاد را به FinestDSP و سایر داوطلبان ارسال می کند.
3. درخواست پیشنهاد دهنده FinestDSP درخواست پیشنهاد را دریافت و پردازش می کند و پاسخ پیشنهاد خود را ارسال می کند.
4. Google پاسخ پیشنهادات را از داوطلبان دریافت می کند ، از جمله پاسخ FinestDSP که یک تبلیغ را با برچسب مسابقه (پیکسل) مشخص می کند.
5. FinestDSP در حراج پیروز می شود. Google تبلیغات تبلیغاتی و برچسب FinestDSP را به جین ارائه می دهد.
6. برچسب Match با سرویس Cookie Match Google تماس می گیرد و پارامترهای google_nid و google_cm را مشخص می کند.
7. سرویس کلوچه Match Google Cookie Jane را می خواند ، و مرورگر جین را به URL تطبیق کوکی FinestDSP با تنظیم پارامترهای google_gid و google_cver ارسال می کند.
8. مرورگر جین تغییر مسیر را به URL Match Cookie FinestDSP بارگیری می کند.
9. Finestdsp's Cookie مطابق نقطه پایان درخواست تغییر مسیر را پردازش می کند ، که شامل پارامترهای URL است که توسط Google تنظیم شده است ، و کوکی آنها برای جین در هدرهای HTTP. FinestDSP اکنون می تواند نقشه برداری کوکی خود را در جدول مسابقه خود در google_gid ذخیره کند.
10. FinestDSP با پیکسل 1x1 نامرئی به تغییر مسیر پاسخ می دهد.

سناریو 2: کاربر با نقشه برداری موجود

یک هفته پس از سناریو 1 ، جین دوباره از Examplenews.com بازدید می کند. اکنون که جین هم در دستگاه خود کوکی های پیشنهاد دهنده و هم مدیر تبلیغاتی دارد ، در اینجا نحوه عملکرد تطبیق آورده شده است.

1. صفحه وب ارائه می شود و باعث می شود Google (مدیر AD) درخواست تبلیغاتی را که در صفحه ارائه می شود درخواست کند.
2. در حراج تبلیغات ، Google یک درخواست پیشنهاد را برای داوطلبان قابل اجرا ، از جمله FinestDSP ارسال می کند.
3. FinestDSP درخواست پیشنهاد را دریافت می کند ، از جمله سیگنالهایی مانند google_gid .
4. FinestDSP در جدول مسابقه خود google_gid را جستجو می کند و کوکی مرتبط با جین را که یک هفته قبل ایجاد شده است (در سناریو 1) پیدا می کند.
5. براساس اطلاعات مرتبط با کوکی ، منطق مناقصه FinestDSP پیشنهاد این تصور را می دهد و حراج را برنده می کند.
6. جین ممکن است بر اساس اطلاعاتی که FinestDSP در اختیار دارد ، تبلیغی متناسب با علایق خود را ببیند.

پیشنهاد دهنده: تطبیق کوکی یک طرفه

تطبیق کوکی یک طرفه شبیه به گردش کار دو طرفه است ، به جز این که به گونه ای تغییر یافته است که فقط Google میزبان یک جدول مسابقه است و جمع می کند. این می تواند در مواردی که پیشنهاد دهنده مجاز به میزبانی شناسه های کاربر Google در جدول مسابقه خودشان نیست ، استفاده شود. برای استفاده از این جریان ، داوطلبان باید به Google اجازه دهند تا جدول مسابقه را میزبانی کنند ، دیگر نمی توانند google_cm در درخواست خدمات تطبیق کوکی Google مشخص کنند ، و در نتیجه google_gid برای جمع آوری جدول مسابقه خود دریافت نمی کنند. هنگامی که Google یک مسابقه را برای کاربر ایجاد کرد ، داوطلبان می توانند با استفاده از داده های کوکی خود ، آنها را به لیست های کاربر اضافه کنند. Similarly, bid requests for these users will exclude the Google User ID, but include hosted match data. A simple example of the revised workflow is summarized in the steps below.

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 for OpenRTB, or BidRequest.hosted_match_data for the deprecated Google RTB Protocol. 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" />

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 .

Step 6: Bidder serves 1x1 transparent pixel

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

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 diagram below, 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

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

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. Below is a simple 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 above 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.

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 diagram below, 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

Bidder Pixel Matching redirect parameters

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. A simple example of the revised workflow is summarized in the steps below.

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 for OpenRTB, or BidRequest.hosted_match_data for the deprecated Google RTB Protocol. 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"/>

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

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 diagram below, 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.

محدودیت ها

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.

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 drops below 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 examples below 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 .

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

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 redirect above, 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 . This might look like the following:

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

Storing 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 for OpenRTB, or BidRequest.hosted_match_data for the deprecated Google RTB protocol.

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 above redirect URL includes a google_hm value of 2 , suggesting that the operation failed because the value could not 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 پارامترها 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 for OpenRTB, or BidRequest.hosted_match_data for the deprecated Google RTB protocol.

Cookie Matching is a feature that enables you to 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.

مفاهیم

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. In Google's OpenRTB implementation, BidRequest.user.buyeruid will specify this as a web-safe base64-encoded string. If your bidding endpoint is configured to use the deprecated Google RTB protocol, you will receive this as decoded bytes through the BidRequest.hosted_match_data field.

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

• 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 Cookie Matching workflows described below, or through the Bulk Uploader Service .

شروع به کار

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.

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 guarantee 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:

Macro example

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

Cookie Matching Service workflows

Google's Cookie Matching Service currently supports three workflows for different use cases that are described below.

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. Below is a simple 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 simple 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" />

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 simple match tag as seen above 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 in OpenRTB, or BidRequest.google_user_id in the deprecated Google RTB protocol.

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 here . 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 diagram below, where requests and responses are represented by an arrow, and the data items that accompany them are listed in parentheses.

Match Tag URL Parameters

In addition to the above 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:

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. A simple example of the revised workflow is summarized in the steps below.

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 for OpenRTB, or BidRequest.hosted_match_data for the deprecated Google RTB Protocol. 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" />

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 .

Step 6: Bidder serves 1x1 transparent pixel

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

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 diagram below, 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

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

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. Below is a simple 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 above 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.

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 diagram below, 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

Bidder Pixel Matching redirect parameters

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. A simple example of the revised workflow is summarized in the steps below.

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 for OpenRTB, or BidRequest.hosted_match_data for the deprecated Google RTB Protocol. 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"/>

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

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 diagram below, 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.

محدودیت ها

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.

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 drops below 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 examples below 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 .

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

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 redirect above, 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 . This might look like the following:

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

Storing 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 for OpenRTB, or BidRequest.hosted_match_data for the deprecated Google RTB protocol.

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 above redirect URL includes a google_hm value of 2 , suggesting that the operation failed because the value could not 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 پارامترها 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 for OpenRTB, or BidRequest.hosted_match_data for the deprecated Google RTB protocol.