راهنمای یکپارچهسازی رضایت کوکی تحلیل محصول Heap Auto-Capture: راهنمای ناشران ۲۰۲۶
هیپ در اکوسیستم تحلیل محصول به خاطر کاری که به طور پیشفرض انجام میدهد غیرمعمول است. در جایی که Mixpanel، Amplitude و PostHog از ناشر میخواهند رویدادهای مهم را ابزارسازی کند، هیپ همه چیز را به طور خودکار ضبط میکند و اجازه میدهد تحلیلگر رویدادها را به صورت بازگشتی از جریان ضبطشده تعریف کند. این مدل auto-capture ویژگی تعریفکننده محصول است و دلیلی که تیمها آن را انتخاب میکنند؛ همچنین دلیلی است که یک استقرار پیشفرض هیپ یکی از گستردهترین سطوح داده رفتاری هر ابزاری را حمل میکند که ناشر احتمالاً نصب خواهد کرد. هر کلیک، لمس، اسکرول، تعامل فرم، انتقال صفحه و کلیک خشمگین در برابر یک شناسه پایدار در عرض میلیثانیههای بارگذاری صفحه ضبط میشود — که به این معناست که هر یک از این عملیاتها یک تعهد رضایت ایجاد میکند. خبر خوب این است که هیپ، از زمان تملک توسط Contentsquare، با یکی از APIهای رضایت با دانهبندی دقیقتر در فضای تحلیل محصول عرضه میشود؛ کار در واقع سیمکشی صحیح آن در سراسر سطح auto-capture، لایه هویت و ماژول پخش مجدد جلسهای است که یکپارچهسازی Contentsquare اضافه میکند.
چرا هیپ به رضایت نیاز دارد — و چرا پاسخ گستردهتر از تحلیل معمولی است
یک راهاندازی پیشفرض هیپ چند کار در اولین رندر صفحه انجام میدهد. یک کوکی طرف اول زیر _hp2_id.{envId} حاوی شناسه کاربر پایدار، یک کوکی جلسه زیر _hp2_ses_id.{envId} با شناسه جلسه، یک کوکی نرخ نمونه زیر _hp2_props.{envId} و یک نشانگر _hp2_loaded که نشان میدهد SDK راهاندازی شده تنظیم میکند. شناسه متمایز را در صورتی که وجود نداشته باشد تولید میکند، نمای صفحه اولیه را با ارجاعدهنده، پارامترهای UTM و شناسههای کلیک ضبط میکند و بلافاصله شروع به ضبط هر تعامل بعدی در برابر آن شناسه میکند — کلیکها، لمسها، تغییرات فرم، تغییرات مسیر، رویدادهای سفارشی و هنگامی که یکپارچهسازی Contentsquare فعال است، تفاضل DOM رندرشده کامل برای پخش مجدد جلسه.
هر یک از این فعالیتها یک دروازه رضایت جداگانه را فعال میکند. ماندگاری شناسه کاربر یک عملیات ذخیرهسازی و دسترسی تحت ماده ۵(۳) دستورالعمل ePrivacy است و نیاز به رضایت قبلی، آزادانه داده شده، خاص، آگاهانه و بدون ابهام در سراسر EEA، بریتانیا و هر حوزه قضایی که همان استاندارد را وارد کرده دارد. ضبط جریان رویداد auto-capture پردازش دادههای شخصی تحت GDPR است زیرا ترکیب شناسه، آدرس IP و اثر رفتاری برای شناسایی یک فرد کافی است. پخش مجدد جلسه در یک دسته جداگانه و سختگیرانهتر تحت راهنمای پخش مجدد جلسه EDPB قرار دارد — پخش مجدد DOM رندرشده و هر فیلد ورودی بدون ماسک را ضبط میکند و نیاز به رضایت صریح و دانهبندی دارد که از رضایت تحلیلی عمومی متمایز است. CCPA و CPRA همان پردازش را به عنوان فروش یا اشتراکگذاری تلقی میکنند مگر اینکه ناشر قرارداد ارائهدهنده خدمات مربوطه با هیپ داشته باشد — که هیپ ارائه میدهد، اما قرارداد فقط زمانی لازمالاجراست که یکپارچهسازی برای حالت ارائهدهنده خدمات پیکربندی شده باشد.
هیپ قبل از رضایت چه مینویسد — و چه چیزی باید سرکوب شود
راهاندازی سریع استاندارد که با داشبورد هیپ عرضه میشود، قطعه ردیابی را مستقیماً در <head> صفحه نصب میکند. این طبق مستندات کار میکند و منبع رایجترین شکست انطباق در استقرارهای هیپ است: قطعه قبل از رندر بنر کوکی اجرا میشود، کوکیهای _hp2_ در عرض میلیثانیهها نوشته میشوند و جریان auto-capture شروع به جاری شدن به heapanalytics.com میکند صرف نظر از اینکه کاربر بعداً چه تصمیمی میگیرد. هر تنظیمکننده اروپایی که درباره این الگو حکم داده به همان شکل حکم کرده است: کوکیهای تنظیمشده قبل از رضایت غیرقانونی هستند و ناشر مسئولیت را به عهده دارد.
بنابراین یک یکپارچهسازی مطابق باید از بارگذاری قطعه هیپ تا زمانی که دسته رضایت مربوطه داده شده جلوگیری کند. دو الگویی که در تولید کار میکنند تزریق اسکریپت شرطی هستند — قطعه فقط پس از اینکه CMP رضایت را سیگنال میدهد به DOM اضافه میشود — و پیشبارگذاری قطعه با heap.load(appId, { disableTextCapture: true, secureCookie: true, autocapture: false }) به عنوان بوتاسترپ تأخیری و سپس فراخوانی heap.startAutoCapture() پس از ثبت رضایت. الگوی تزریق شرطی تمیزتر است و الگویی است که مستندات هیپ اکنون توصیه میکند. الگوی بوتاسترپ تأخیری انتخاب درستی است زمانی که ناشر به یک مرجع جهانی پایدار برای بخیه هویت نیاز دارد اما نمیتواند اجازه دهد auto-capture قبل از رضایت فعال شود.
کوکیها و فضای ذخیرهسازی که هیپ مینویسد
قطعه هیپ هنگام راهاندازی شناسههای زیر را مینویسد که همه غیر ضروری هستند و نیاز به رضایت دارند: _hp2_id.{envId} با انقضای ۱۴ ماهه حاوی شناسه کاربر، _hp2_ses_id.{envId} با انقضای جلسه ۳۰ دقیقهای، _hp2_props.{envId} برای نرخ نمونه و انتشار ویژگی، و _hp2_loaded به عنوان نشانگر بارگذاری. ماژول پخش مجدد جلسه یکپارچهشده با Contentsquare یک بافر ضبط درونحافظهای اضافه میکند که هر چند ثانیه به نقطه پایانی هیپ خالی میشود و ممکن است یک شناسه جلسه پخش مجدد کوچک را جداگانه پایدار کند. بنابراین لغو رضایت باید هم کوکیهای _hp2_ را منقضی کند و هم از طریق API GDPR هیپ برای ضبطها و جریان رویداد قبلی کاربر یک درخواست حذف سیگنال دهد.
نگاشت هیپ به چارچوبهای رضایت
هیپ به صورت بومی IAB TCF یا پلتفرم حریم خصوصی جهانی IAB را پیادهسازی نمیکند — یک پلتفرم تحلیل محصول طرف اول است، نه یک فروشنده فناوری تبلیغات — اما از طریق پلسازی از طرف ناشر با Google Consent Mode v2 یکپارچه میشود، یک API بومی opt-in و opt-out را نمایان میکند و یک لایه بازنگری ویژگی حساس را که صرف نظر از وضعیت رضایت عمل میکند پشتیبانی میکند. الگویی که بررسی یک تنظیمکننده را پشت سر میگذارد هر ماژول هیپ را به عنوان یک دروازه جداگانه متصل به یک سیگنال CMP خاص در نظر میگیرد.
- Auto-capture و جریان رویداد اصلی به هدف تحلیلی متصل میشوند. در اصطلاح TCF این معمولاً هدف ۸ (اندازهگیری عملکرد محتوا) همراه با هدف ۱ (ذخیره و/یا دسترسی به اطلاعات) است. برای Consent Mode این به analytics_storage نگاشت میشود.
- پخش مجدد جلسه از طریق یکپارچهسازی Contentsquare پشت یک دروازه سختگیرانهتر و جداگانه قرار دارد زیرا پخش مجدد DOM رندرشده و هر فیلد ورودی بدون ماسک را ضبط میکند و راهنمای پخش مجدد جلسه EDPB آن را به عنوان دستهای تلقی میکند که نیاز به رضایت صریح و دانهبندی متمایز از تحلیل عمومی دارد.
- شناسایی کاربر از طریق heap.identify() میتواند با یک شناسه جلسه موقت تحت مبنای منافع مشروع زمانی که کاربر ناشناس است اجرا شود، اما بخیه کردن شناسایی به یک شناسه طرف اول پایدار در جلسات نیاز به همان رضایت تحلیل دارد زیرا آن زمانی است که شناسه به یک نقطه داده در سطح کاربر قابل ردیابی تبدیل میشود.
- انتشار هویت بین سایتها یا بین محصولات از طریق API هویت نیاز به دروازه بازاریابی دارد زیرا از مرز تحلیل محصول به انتساب بازاریابی در سطح کاربر عبور میکند.
الگوی یکپارچهسازی که کار میکند
استقرار مرجع چهار بخش دارد: یک CMP که یک رویداد تغییر رضایت در زمان واقعی را نمایان میکند، یک بوتاسترپ تأخیری که هیپ را با auto-capture غیرفعال بارگذاری میکند، یک شنونده رضایت که auto-capture را روشن میکند و بافر پخش مجدد جلسه را هنگامی که دروازههای مربوطه باز میشوند شروع میکند، و یک مسیر لغو که heap.resetIdentity() را فراخوانی میکند، auto-capture را متوقف میکند، کوکیهای _hp2_ را منقضی میکند و یک درخواست حذف از طریق نقطه پایانی GDPR هیپ ارسال میکند.
پیادهسازی وب
در وب تمیزترین الگو بارگذاری شرطی قطعه هیپ است — تگ <script> فقط پس از اینکه دسته تحلیلی داده شده تزریق میشود. مشترک رویداد تغییر رضایت CMP شوید. هنگامی که دسته تحلیلی به حقیقی تبدیل میشود، قطعه هیپ را با secureCookie: true، disableTextCapture: false برای auto-capture کامل و هر پیکربندی مخصوص محیط تزریق کنید. هنگامی که رضایت پخش مجدد جلسه به حقیقی تبدیل میشود و یکپارچهسازی Contentsquare فعال است، بافر پخش مجدد به طور خودکار فعال میشود. هنگامی که هر دروازهای لغو میشود، heap.resetIdentity() را به دنبال حذف عنصر اسکریپت هیپ فراخوانی کنید، کوکیهای _hp2_ را از طریق document.cookie منقضی کنید و API حذف GDPR را برای شناسه کاربر فعال کنید.
بازنگری ویژگی حساس
هیپ با یک لایه بازنگری که صرف نظر از وضعیت رضایت عمل میکند عرضه میشود و ناشران باید حتی زمانی که رضایت داده شده از آن استفاده کنند. ویژگی data-heap-redact-text در یک فیلد فرم محتوای متن ضبطشده را سرکوب میکند؛ ویژگی data-heap-redact-attributes ویژگیهای عنصر را سرکوب میکند. تحت قوانین دسته ویژه GDPR و تعریف اطلاعات شخصی حساس CCPA، هر فیلدی که ممکن است اطلاعات بهداشتی، جزئیات مالی، شناسههای دولتی، دادههای بیومتریک، موقعیت مکانی دقیق یا محتوای ارتباطات خصوصی را ضبط کند باید از ویژگیهای بازنگری صرف نظر از وضعیت رضایت کاربر استفاده کند. تنظیم ویژگیها در سطح فرم امنترین الگو است — کل فرم را حتی زمانی که یک توسعهدهنده یک فیلد جدید اضافه میکند که فراموش میکند جداگانه علامتگذاری کند سرکوب میکند.
انتخاب منطقه: اقامت داده اتحادیه اروپا در مقابل ایالات متحده
هیپ نقاط پایانی ورودی جداگانه اتحادیه اروپا و ایالات متحده را اداره میکند. برای ترافیک EEA و بریتانیا نقطه پایانی اتحادیه اروپا پیشفرض درستی است؛ ورود، پردازش و ذخیرهسازی را در داخل EEA نگه میدارد و قرارگیری در معرض Schrems II را که هر استقرار تحلیلی منطقه ایالات متحده حمل میکند کاهش میدهد. نقطه پایانی از طریق پیکربندی قطعه تنظیم میشود و نمیتوان آن را به صورت پسگرایانه تغییر داد — دادههای موجود در جایی که اولین بار وارد شدند باقی میمانند. بنابراین برای ناشرانی که استقرار هیپ را برنامهریزی میکنند ارزش دارد قبل از مقیاسگذاری منطقه را تأیید کنند و انتخاب را در اطلاعیه حریم خصوصی مستند کنند تا زنجیره مبنای قانونی از جمعآوری تا ذخیرهسازی پاک باشد.
تأیید یکپارچهسازی و مسیر حسابرسی
مرحله تأیید چیزی است که تنظیمکنندگان بررسی میکنند و ناشران اغلب آن را نادیده میگیرند. یک استقرار هیپ صحیح یکپارچهشده باید چهار آزمون را به ترتیب پشت سر بگذارد. اول، یک جلسه مرورگر تمیز با بنر نشان داده شده اما بدون انتخاب انجام شده باید صفر درخواست به heapanalytics.com فراتر از واکشی فایل SDK و صفر کوکی _hp2_ در document.cookie تولید کند. دوم، رد کردن تحلیل باید آن وضعیت را حفظ کند — بدون auto-capture، بدون شناسه، بدون ضبط. سوم، پذیرفتن تحلیل باید کوکی _hp2_id مورد انتظار با ویژگیهای SameSite صحیح و ترافیک رویداد جاری شده به نقطه پایانی منطقه پیکربندیشده تولید کند. چهارم، لغو رضایت باید فوراً auto-capture و پخش مجدد بیشتر را متوقف کند، کوکیهای _hp2_ را منقضی کند و یک درخواست حذف از طریق API GDPR هیپ راهاندازی کند.
انتظار مسیر حسابرسی تحت دستورالعملهای بنر کوکی ۲۰۲۳ EDPB و اولویتهای کارگروه تجدیدنظر ۲۰۲۶ این است که ناشر بتواند برای هر رویداد معینی در پروژه هیپ ثابت کند که کاربری که آن را تولید کرده در لحظه ضبط رضایت معتبر داده بود. الگوی استاندارد تنظیم نسخه رضایت و مهر زمانی به عنوان ویژگیهای کاربر در ID متمایز از طریق heap.addUserProperties({ consent_version: 'v3', consent_ts: ts }) است تا هر رویداد فردی به یک ورودی گزارش رضایت خاص قابل ردیابی باشد. یک استقرار به درستی دروازهبندیشده، همراه با ویژگیهای بازنگری که به طور پیشفرض فیلدهای حساس را سرکوب میکنند و یک مسیر حذف که در صورت لغو فعال میشود، چیزی است که مدل auto-capture هیپ را از یک خطر تمرکز نظارتی به یکی از قدرتمندترین و قابل دفاعترین بخشهای پشته تحلیل محصول ناشر تبدیل میکند.