Chrome به‌طور عمومی تمام Third-party Cookieها را حذف نکرده است. گوگل در آوریل ۲۰۲۵ اعلام کرد رویکرد انتخاب کاربر را حفظ می‌کند و پنجره انتخاب مستقل تازه‌ای برای این موضوع ارائه نمی‌کند. اعلام رسمی تصمیم Chrome مبنای این اصلاح است. عنوان قبلی «مرگ Cookies شخص ثالث» و جمله «عصر Cookies تمام شد» تصویری نادرست از وضعیت می‌دادند. برای طراحی محصول باید هم حالت مجاز بودن Cookie و هم حالت مسدود بودن آن را در نظر بگیرید.
فهرست جایگزین‌های قدیمی هم به بازبینی نیاز داشت. در اکتبر ۲۰۲۵، گوگل بازنشستگی مجموعه‌ای از فناوری‌های Privacy Sandbox، از جمله Topics و Attribution Reporting را اعلام کرد. به‌روزرسانی برنامه Privacy Sandbox این تغییر را ثبت کرده است. FLoC نیز پیشنهاد تاریخی این مسیر بود و نباید به عنوان انتخاب جاری برای پروژه تازه معرفی شود. راهبرد محصول را بر یک API معرفی‌شده در خبری قدیمی بنا نکنید.
First-party و Third-party به زمینه استفاده مربوط‌اند
Cookie مقدار کوچکی است که مرورگر در شرایط مشخص نگه می‌دارد و در درخواست مرتبط می‌فرستد. First-party و Third-party فقط دو اسم برای دو نوع محتوای Cookie نیستند؛ زمینه سایت بالای صفحه و دامنه درخواست اهمیت دارد. یک سرویس تعبیه‌شده در سایت دیگری می‌تواند در زمینه Third-party باشد. راهنمای Third-party cookies در MDN این تفاوت را توضیح می‌دهد.
برای مثال، فروشگاهی که نشست ورود خود را در دامنه خودش نگه می‌دارد با ابزار تحلیلی که روی چند سایت حضور دارد نیاز یکسانی ندارد. ویدئوی تعبیه‌شده، پنجره گفت‌وگو و ورود فدره هم ممکن است درخواست cross-site داشته باشند، ولی هدف آن‌ها یکی نیست. قبل از تصمیم حذف یا جایگزینی، کاربرد هر جزء را ثبت کنید. عنوان کلی «Cookie تبلیغاتی» همه وابستگی‌ها را آشکار نمی‌کند.
داشتن یک script از دامنه بیرونی هم به تنهایی تمام رفتار آن را توضیح نمی‌دهد. کد ممکن است در زمینه صفحه شما اجرا شود و درخواست‌های دیگری بفرستد. دامنه منابع، مقصد درخواست‌ها و داده منتقل‌شده را کنار هم ببینید. قرارداد سرویس و تنظیم آن لازم است تا بفهمید کدام مقدار برای عملکرد اصلی و کدام مقدار برای اندازه‌گیری یا ردیابی استفاده می‌شود.
SameSite، Secure و HttpOnly چه مرزی دارند؟
ویژگی‌های Cookie رفتار ارسال و دسترسی آن را تعیین می‌کنند. HttpOnly دسترسی از JavaScript را محدود می‌کند؛ Secure ارسال را به اتصال امن وابسته می‌کند؛ SameSite به شرایط ارسال در درخواست‌های cross-site مربوط است. مرجع Set-Cookie جزئیات و محدودیت‌ها را شرح می‌دهد. هیچ یک به تنهایی مجوز معتبر کاربر یا راه‌حل کامل امنیت نیست.
اگر Cookie نشست تغییر می‌کند، سرور باید اعتبار آن را بررسی کند. مقدار ارسالی مرورگر داده مورد اعتماد بی‌قید نیست. برای عملیات تغییردهنده نیز نیازهای CSRF را با معماری و framework هماهنگ کنید. تغییر SameSite برای درست شدن یک integration باید با شناخت اثر آن بر دیگر مسیرها انجام شود. رفع یک خطای ورود نباید بی‌بررسی قرارداد حفاظت عملیات حساب را ضعیف کند.
مسدود شدن Cookie شخص ثالث را با تنظیم اشتباه Cookie یکی نگیرید. Cookie ممکن است به علت دامنه، مسیر، Secure یا سیاست مرورگر ارسال نشود. هر علت، راه اصلاح متفاوت دارد. افزودن attributeهای بیشتر بدون تشخیص علت، گاهی مشکل را پیچیده‌تر می‌کند. در مستند integration مشخص کنید چه Cookieای، در چه درخواست و برای چه وظیفه‌ای انتظار می‌رود.
وابستگی‌های سایت را به وظیفه تقسیم کنید
یک فهرست از ورود، پرداخت، ابزار تحلیل، تبلیغات و widgetهای تعبیه‌شده تهیه کنید. برای هر مورد مشخص کنید اگر Third-party Cookie در دسترس نباشد چه رفتاری از بین می‌رود. ممکن است گزارش تبلیغات تغییر کند ولی خرید همچنان کار کند؛ ممکن است ورود در یک پنجره تعبیه‌شده مشکل پیدا کند. اولویت باید بر اساس وظیفه کاربر و حساسیت آن تعیین شود.
سرویس بیرونی باید درباره حالت مسدود بودن Cookie پاسخ مشخص داشته باشد. یک عبارت تبلیغاتی «سازگار با حریم خصوصی» کافی نیست. بپرسید آیا مسیر جایگزین دارد، چه داده‌ای به سرور شما نیاز دارد و آیا کاربر باید صفحه مستقلی باز کند. پاسخ را برای همان نسخه integration ثبت کنید؛ رفتار نسخه‌های قدیمی و جدید ممکن است فرق داشته باشد.
در مسیر پرداخت یا ورود، fallback باید روشن و قابل استفاده باشد. اگر یک قابلیت تعبیه‌شده کار نمی‌کند، کاربر را با پنجره خالی رها نکنید. متن خطا باید بگوید چه اتفاقی افتاده و چه راهی برای ادامه وجود دارد، بدون اینکه جزئیات فنی غیرضروری را به کاربر تحمیل کند. مقاله طراحی پیام خطا به نوشتن همین راه ادامه مربوط است.
CHIPS برای داده جداشده در هر سایت است
CHIPS امکان Cookieهای Partitioned را برای برخی کاربردهای تعبیه‌شده فراهم می‌کند. داده در زمینه سایت بالای صفحه جدا می‌شود؛ هدف آن ساخت شناسه مشترک ردیابی بین تمام سایت‌ها نیست. مستندات CHIPS محدوده این سازوکار را توضیح می‌دهد. اگر widget شما فقط وضعیتش را در همان سایت میزبان لازم دارد، این مدل می‌تواند موضوع بررسی باشد.
Partition شدن، قرارداد داده را تغییر می‌دهد. یک مقدار ذخیره‌شده در زمینه سایت اول، الزاماً در زمینه سایت دوم همان وضعیت را ندارد. اگر کسب‌وکار انتظار ورود مشترک یا تاریخچه یکپارچه دارد، باید این انتظار را با سازوکار مناسب بررسی کند. استفاده از CHIPS برای هر مسئله Cookie، نیاز متفاوت ورود فدره و اندازه‌گیری تبلیغات را با هم مخلوط می‌کند.
ورود فدره مسیر مستقلی دارد
ورود با ارائه‌دهنده هویت، مسئله‌ای درباره انتقال هویت و انتخاب کاربر است. FedCM در این حوزه مطرح است و باید بر اساس پشتیبانی مرورگر و سرویس هویت مطالعه شود. راهنمای FedCM در MDN به این integration مربوط است. نام یک API هویت را جایگزین عمومی تمام Cookieهای شخص ثالث معرفی نکنید؛ کاربرد و طرف‌های درگیر آن مشخص‌اند.
در طراحی ورود، کاربر باید بداند کدام حساب را انتخاب می‌کند و پس از موفقیت به کجا برمی‌گردد. ثبت هویت در سرور، اعتبارسنجی پاسخ و مدیریت نشست خود سایت همچنان لازم است. حالت لغو ورود یا در دسترس نبودن ارائه‌دهنده را نیز طراحی کنید. دکمه ورود که فقط در حالت موفق کار می‌کند، قرارداد کامل یک مسیر حساس نیست.
داده First-party هم مسئولیت دارد
داده‌ای که مستقیم از کاربر یا تعامل با محصول خود دریافت می‌کنید، به‌خودی‌خود مجوز استفاده نامحدود ایجاد نمی‌کند. هدف جمع‌آوری، دسترسی تیم و مدت نگهداری باید روشن باشد. برای ثبت سفارش، اطلاعات لازم با داده تبلیغاتی یکسان نیست. از اضافه کردن فیلد فقط به دلیل ممکن بودن جمع‌آوری آن پرهیز کنید؛ هر داده اضافی نیاز نگهداری و توضیح تازه ایجاد می‌کند.
یک فروشگاه می‌تواند گزارش فروش را از سفارش‌های ثبت‌شده خودش تهیه کند، بدون اینکه ادعا کند مسیر کامل هر کاربر در همه سایت‌ها را می‌داند. این تغییر، تعریف گزارش را محدودتر و روشن‌تر می‌کند. اگر داده ورودی ناقص است، همان محدودیت را کنار نتیجه بنویسید. ارزش واقعی First-party data در ارتباط مشخص آن با محصول است، نه در تبدیل کردنش به شعار «برنده آینده».
انتقال اندازه‌گیری به سمت سرور نیز حریم خصوصی را خودکار تضمین نمی‌کند. داده همچنان می‌تواند به شخص ثالث ارسال شود و هدف استفاده همان باشد. سمت اجرای کد فقط یکی از جزئیات معماری است. منطق رضایت، حذف داده و کنترل دسترسی باید با همه مسیرهای انتقال هماهنگ باشد. قرارداد حقوقی هر حوزه را از مرجع مربوط بخوانید و از یک راهنمای فنی انتظار حکم عمومی قانونی نداشته باشید.
اندازه‌گیری را با محدودیتش گزارش کنید
Attribution پاسخ می‌دهد یک نتیجه طبق مدل شما به کدام تماس یا کمپین نسبت داده می‌شود؛ این مدل لزوماً علت واقعی خرید را اثبات نمی‌کند. اگر بخشی از مسیر کاربر دیده نمی‌شود، عدد گزارش وابسته به همان پوشش است. تغییر فناوری اندازه‌گیری ممکن است عدد را عوض کند، حتی اگر رفتار مشتری تغییر نکرده باشد. مقایسه قبل و بعد باید این تغییر روش را توضیح دهد.
برای تیم بازاریابی و توسعه، تعریف مشترکی از رویدادها بنویسید. تفاوت مشاهده محصول، شروع پرداخت و سفارش موفق باید مشخص باشد. ارسال چندباره یک رویداد می‌تواند گزارش را باد کند و نبودن شناسه مناسب، حذف تکرار را دشوار می‌کند. مقاله استراتژی‌های فروش آنلاین ادامه‌ای برای ارتباط این گزارش‌ها با تصمیم فروش است؛ معیار فنی را از نتیجه کسب‌وکار جدا نگه دارید.
قدم بعدی، فهرست کردن وابستگی‌های واقعی سایت و نوشتن رفتار هر کدام در حالت Cookie مسدود است. برای پروژه تازه، از APIهای بازنشسته شروع نکنید و برای پروژه موجود، تغییر سیاست مرورگر را با تغییر قرارداد ابزارها اشتباه نگیرید. تاریخ و منبع هر تصمیم را ثبت کنید تا بازبینی بعدی مجبور نباشد به عنوان‌های قدیمی درباره «پایان Cookie» تکیه کند.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!