راهنمای یکپارچهسازی رضایت کوکی Amplitude Product Analytics: کتاب راهنمای پیادهسازی ۲۰۲۶
Amplitude جایگاه غیرمعمولی در پشته داده مدرن اشغال میکند. نه کاملاً یک مدیر برچسب است، نه کاملاً یک پلتفرم داده مشتری، و نه کاملاً یک ابزار تحلیل بازاریابی — بلکه یک محصول تحلیل رفتاری است که برای ضبط هر تعاملی که کاربر با یک محصول دیجیتال دارد، دوختن آن رویدادها به نشستها و سفرهای کاربری، و بازگرداندن نتیجه به آزمایش، شخصیسازی و انتساب درآمد طراحی شده است. این غنا همان چیزی است که محصول را ارزشمند میکند. همچنین همان چیزی است که رضایت را به تنها مهمترین تصمیم یکپارچهسازی تبدیل میکند که یک تیم هنگام استقرار آن خواهد گرفت. درست انجام دهید و Amplitude برای سالها بینش محصول قابل دفاع به شما میدهد. اشتباه انجام دهید و همان SDK به یکی از قابل مشاهدهترین موارد در فهرست اجرایی یک نهاد نظارتی تبدیل میشود، زیرا SDKهای تحلیل رفتاری که قبل از رضایت فعال میشوند دقیقاً همان الگویی است که کارگروه بنر کوکی EDPB، CNIL و ICO طی سه سال گذشته هدف قرار دادهاند.
چرا Amplitude به رضایت نیاز دارد
SDK مرورگر پیشفرض Amplitude و SDKهای موبایل Amplitude بسیار بیشتر از ثبت بازدیدهای صفحه انجام میدهند. در هنگام مقداردهی اولیه، یک شناسه دستگاه در حافظه first-party قرار میدهند، یک شناسه نشست ایجاد میکنند، ارجاعدهنده را ضبط میکنند، UTM و شناسههای کلیک را از URL تجزیه میکنند، و شروع به صفبندی رویدادهای ضبط شده خودکار میکنند: بازدیدهای صفحه، کلیکهای عنصر، تعاملات فرم، دانلود فایلها و — در آخرین نسخهها — پخش مجدد نشست. همچنین آن رویدادها را با موقعیت جغرافیایی مشتق از IP، دادههای دستگاه مشتق از user-agent و، در صورت پیکربندی، غنیسازی شخص ثالث از شرکای داده غنی میکنند.
هر یک از این مراحل یک مبنای قانونی رضایت جداگانه را درگیر میکند. ذخیره یک شناسه دستگاه یک عملیات ذخیرهسازی و دسترسی طبق ماده ۵(۳) دستورالعمل ePrivacy است که در منطقه اقتصادی اروپا، بریتانیا و هر حوزه قضایی که همان استاندارد را وارد کرده، نیازمند رضایت قبلی، آزادانه داده شده، خاص، آگاهانه و بدون ابهام است. ضبط رویدادهای رفتاری مرتبط با آن شناسه پردازش دادههای شخصی تحت GDPR است. غنیسازی با دادههای شخص ثالث یک رابطه کنترلکننده ثانویه را معرفی میکند. CCPA و CPRA همان پردازش را به عنوان فروش یا اشتراکگذاری طبقهبندی میکنند مگر اینکه ناشر یک قرارداد ارائهدهنده خدمات با محدوده مناسب با Amplitude داشته باشد — که در دسترس است، اما تنها در صورتی که یکپارچهسازی برای غیرفعال کردن ویژگیهای تبلیغاتی پیکربندی شده باشد.
آنچه Amplitude قبل از رضایت جمعآوری میکند — و آنچه باید سرکوب کنید
رایجترین اشتباه پیادهسازی، برخورد با Amplitude به عنوان یک ابزار تحلیل سبک است که میتواند در کنار بنر کوکی اجرا شود. نمیتواند. در یک فراخوانی پیشفرض amplitude.init()، SDK در اولین رندر صفحه حداقل یک کوکی یا ورودی حافظه محلی مینویسد، یک فراخوانی identify ارسال میکند و شروع به بافر کردن رویدادها میکند. هیچ یک از اینها قبل از اینکه کاربر صریحاً دسته رضایت مربوطه را پذیرفته باشد، مجاز نیست.
بنابراین یک یکپارچهسازی مطابق باید amplitude.init() را تا زمانی که CMP سیگنال داده باشد که دسته رضایت تحلیل اعطا شده است به تأخیر بیندازد. SDK نباید اصلاً از یک تگ <script> دروازهبندی شده با رضایت که به سیگنال هدف ۸ (تحلیل) یا هدف ۱ (ذخیرهسازی و دسترسی) CMP وابسته است، بارگذاری شود، بسته به اینکه کدام چارچوب CMP نمایش میدهد. اگر SDK باید زودتر بارگذاری شود — به عنوان مثال زیرا در کد برنامه بسته شده و نمیتواند به تنبلی واکشی شود — فراخوانی مقداردهی اولیه باید defaultTracking: false و optOut: true را پاس کند تا قبل از ثبت رضایت هیچ رویدادی ارسال نشود، و سپس یک رویداد opt-in به تعویق افتاده باید آن پرچمها را جابجا کند.
کوکیها و حافظهای که Amplitude مینویسد
Browser SDK 2.x به طور پیشفرض یک کوکی first-party واحد به نام AMP_{apiKey} با انقضای یک سال مینویسد که شامل شناسه دستگاه و متادیتای نشست است. نسخههای قدیمیتر همچنین amplitude_id_{apiKey} را مینوشتند. SDKهای موبایل همان شناسه را در داخل حافظه sandbox برنامه ذخیره میکنند. پخش مجدد نشست یک کوکی ثانویه اضافه میکند، AMP_MKTG_{apiKey}، و شرکای غنیسازی Amplitude ممکن است کوکیهای شخص ثالث اضافی را در صورت فعال بودن ماژولهای هدفگذاری آزمایش یا مخاطبان تنظیم کنند. همه اینها غیرضروری هستند و نیاز به رضایت دارند.
نگاشت Amplitude به چارچوبهای رضایت
Amplitude به طور بومی Google Consent Mode v2، IAB TCF یا IAB Global Privacy Platform را پیادهسازی نمیکند. این یک نقص نیست — Amplitude یک پلتفرم تحلیل first-party است، نه یک فروشنده فناوری تبلیغات — اما به این معنی است که مسئولیت یکپارچهسازی بر عهده ناشر است. الگویی که در عمل کار میکند این است که هر ماژول Amplitude را به عنوان یک دروازه رضایت جداگانه در نظر بگیرید و آن را به یک سیگنال خاصی که CMP در حال حاضر نمایش میدهد متصل کنید.
- رویدادهای تحلیل اصلی به هدف تحلیل مرتبط میشوند. در اصطلاح TCF این معمولاً هدف ۸ است (اندازهگیری عملکرد محتوا) همراه با هدف ۱ (ذخیرهسازی و/یا دسترسی به اطلاعات). برای Google Consent Mode این به analytics_storage نگاشته میشود.
- پخش مجدد نشست باید پشت یک سیگنال سختگیرانهتر باشد. پخش مجدد DOM رندر شده را ضبط میکند، از جمله مقادیر فرم مگر اینکه به صراحت ماسک شده باشند، بنابراین یک opt-in جداگانه ترجیحات یا عملکردی مناسب است، و پخش مجدد باید حتی زمانی که تحلیل اعطا شده است به طور پیشفرض خاموش باشد.
- مخاطبان، کوهورتها و غنیسازی شخص ثالث به هدف بازاریابی مرتبط میشوند. در اصطلاح TCF این هدف ۷ است (اندازهگیری عملکرد تبلیغات) یا هدف ۹ (اعمال تحقیقات بازار). برای Google Consent Mode این به ad_storage و ad_user_data نگاشته میشود.
- آزمایش — Amplitude Experiment میتواند با تخصیص ناشناس و موقت تحت پایه منافع مشروع اجرا شود، اما تخصیص دائمی مرتبط با شناسه کاربر نیاز به همان رضایت مانند تحلیل اصلی دارد.
الگوی یکپارچهسازی که کار میکند
پیادهسازی مرجعی که از بررسی یک نهاد نظارتی جان سالم به در میبرد چهار قطعه متحرک دارد: یک CMP که یک رویداد بلادرنگ را هنگامی که کاربر رضایت را تغییر میدهد نمایش میدهد، یک بارگذار SDK به تعویق افتاده که تنها پس از آتش گرفتن آن رویداد برای دسته مربوطه Amplitude را واکشی میکند، یک نگهبان سطح نشست که opt-out را بدون از دست دادن شناسه دستگاه ناشناس قبلی کاربر در جایی که قانون اجازه میدهد رعایت میکند، و یک پل سمت سرور برای رویدادهایی که واقعاً نیاز به جمعآوری صرف نظر از رضایت دارند — مانند تلهمتری امنیتی یا تشخیص کلاهبرداری — که از طریق یک endpoint جداگانه با پایه قانونی خودش مسیریابی میشوند.
پیادهسازی وب
در وب، خالصترین الگو این است که وضعیت رضایت CMP را از طریق یک شیء window.__cmp_consent یا فراخوانی استاندارد __tcfapi نمایش دهید، سپس یک اسکریپت bootstrap کوچک برای اشتراک به تغییرات رضایت داشته باشید. وقتی رضایت تحلیل از false به true برمیگردد، bootstrap SDK Amplitude را از CDN مدیریتشده CMP واکشی میکند، amplitude.init(apiKey, undefined, { defaultTracking: true }) را فراخوانی میکند و هر رویدادی که در حین انتظار رضایت در حافظه در صف بود را پخش مجدد میکند. وقتی رضایت به false برمیگردد، bootstrap amplitude.setOptOut(true) را فراخوانی میکند، کوکی AMP_ را از طریق انقضای document.cookie پاک میکند و هر حالتی که در حافظه است را حذف میکند. به طور حیاتی، bootstrap هرگز نباید Amplitude را به طور تنبلانه در همان جریان درخواست به عنوان رندر بنر مقداردهی اولیه کند — SDK باید منتظر یک اعطای صریح باشد.
پیادهسازی موبایل
در iOS، معادل این است که Amplitude framework را وارد شده نگه دارید اما Amplitude.instance().initialize(apiKey: apiKey) را تا زمانی که جریان رضایت درون برنامه یک سیگنال تحلیل مثبت بازگردانده است به تعویق بیندازید. پرامپت ATT یک نگرانی جداگانه است: ATT بر IDFA حاکم است، در حالی که شناسه Amplitude UUID خود SDK است که در sandbox برنامه ذخیره شده است. هر دو در EEA نیاز به رضایت دارند، اما پایههای قانونی و پرامپتها متمایز هستند. در Android همان منطق با Amplitude.getInstance().initializeApolloClient() یا معادل آن بسته به نسخه SDK اعمال میشود.
حالت سمت سرور
Amplitude از ورود سمت سرور از طریق HTTP V2 API پشتیبانی میکند. رویدادهای سمت سرور از رضایت معاف نیستند — پایه قانونی داده را دنبال میکند، نه حملونقل را — اما ورود سمت سرور به ناشر کنترل کامل بر اینکه کدام فیلدها ارسال میشوند را میدهد که رعایت رضایت جزئی را آسانتر میکند. یک الگوی رایج این است که یک مجموعه رویداد فقط ضروری حداقلی را سمت سرور تحت منافع مشروع ضبط کنید و تنها پس از اینکه کاربر رضایت تحلیل را در کلاینت اعطا کرده است آن رویدادها را با جزئیات رفتاری غنی کنید.
اعتبارسنجی یکپارچهسازی
مرحله اعتبارسنجی همان چیزی است که ناشران اغلب از آن صرف نظر میکنند و نهادهای نظارتی اغلب بررسی میکنند. یک استقرار Amplitude که به درستی یکپارچه شده باید چهار بررسی را پشت سر بگذارد. اول، یک مرورگر با بنر رضایت نشان داده شده اما بدون انتخاب باید صفر درخواست به api.amplitude.com یا api.eu.amplitude.com و صفر کوکی AMP_ در document.cookie ایجاد کند. دوم، رد کردن دسته تحلیل باید آن حالت را حفظ کند — بدون رویداد، بدون کوکی، بدون ورودی حافظه محلی با پیشوند AMP_. سوم، پذیرفتن تحلیل باید یک identify واحد و سپس ترافیک رویداد تولید کند، و کوکی AMP_ باید با یک ویژگی SameSite سازگار با سیاست CMP ناشر ظاهر شود. چهارم، پس گرفتن رضایت باید بلافاصله رویدادهای بیشتری را متوقف کرده و شناسههای ذخیره شده را پاک کند — پاکسازی تأخیری یک یافته است.
مسیر حسابرسی به طور جداگانه اهمیت دارد. بر اساس دستورالعملهای بنر کوکی ۲۰۲۳ EDPB و اولویتهای کارگروه ۲۰۲۶ تجدید نظر شده، نهادهای نظارتی انتظار دارند که ناشر بتواند برای هر رویداد در پروژه Amplitude ثابت کند که کاربری که آن را ایجاد کرده در لحظه ضبط رضایت معتبری داده بود. این نیازمند آن است که گزارش رضایت CMP بر اساس شناسه دستگاه یا شناسه نشست قابل جستجو باشد، و بار رویداد Amplitude یک فیلد نسخه رضایت حامل باشد که به آن گزارش برمیگردد. ذخیره رشته رضایت به عنوان یک ویژگی کاربر سفارشی در هر رویداد سادهترین روش برای قابل حسابرسی کردن آن پیوند است.
انتخاب منطقه و محل اقامت داده مناسب
Amplitude دو منطقه تولید را اداره میکند: آمریکا (api.amplitude.com) و اتحادیه اروپا (api.eu.amplitude.com). برای ترافیک EEA و بریتانیا، منطقه اتحادیه اروپا پیشفرض مناسب است — دادهها را در EEA نگه میدارد و سطح ریسک انتقال را که حکم Schrems II و چارچوب حریم خصوصی داده EU-US در مرکز هر بررسی تحلیل قرار داده است، کاهش میدهد. تغییر منطقه عطف به ماسبق نیست: دادههای موجود در جایی که اول بار ورودی شدند باقی میمانند. بنابراین برای ناشرانی که استقرار CMP را برنامهریزی میکنند، ارزش دارد قبل از مقیاسبندی منطقه را تأیید کنید و انتخاب را در اعلامیه حریم خصوصی مستند کنید تا زنجیره پایه قانونی از جمعآوری تا ذخیرهسازی پاک باشد. یک منطقه انتخاب شده به درستی، همراه با یک SDK دروازهبندی شده درست و یک گزارش رضایت قابل جستجو، همان چیزی است که یک استقرار Amplitude را از یک ریسک نظارتی به یک بخش قابل دفاع از پشته تحلیل تبدیل میکند.