Посібник з інтеграції Cookie Consent для Heap Auto-Capture Product Analytics: Посібник 2026 для видавців
Heap незвичайна в екосистемі продуктової аналітики через те, що вона робить за замовчуванням. Тоді як Mixpanel, Amplitude та PostHog просять видавця інструментувати важливі події, Heap автоматично захоплює все та дозволяє аналітику ретроактивно визначати події з захопленого потоку. Ця модель автоматичного захоплення є визначальною функцією продукту та причиною, чому команди вибирають її; це також причина, чому стандартне розгортання Heap несе одну з найширших поверхонь поведінкових даних серед усіх інструментів, які видавець, ймовірно, встановить. Кожен клік, дотик, прокрутка, взаємодія з формою, перехід між сторінками та клік у гніві захоплюється проти постійного ідентифікатора в межах мілісекунд після завантаження сторінки — що означає, що кожна з цих операцій породжує зобов'язання щодо згоди. Хороша новина полягає в тому, що Heap з моменту придбання компанією Contentsquare поставляється з одним із найбільш деталізованих API згоди в просторі продуктової аналітики; робота полягає в правильному підключенні до поверхні автоматичного захоплення, шару ідентичності та модуля відтворення сеансу, який додає інтеграція Contentsquare.
Чому Heap вимагає згоди — і чому відповідь ширша за типову аналітику
Стандартна ініціалізація Heap виконує кілька дій під час першого відображення сторінки. Вона встановлює сторонній файл cookie першої сторони під _hp2_id.{envId}, що містить постійний ідентифікатор користувача, файл cookie сеансу під _hp2_ses_id.{envId} з ідентифікатором сеансу, файл cookie частоти вибірки під _hp2_props.{envId} та маркер _hp2_loaded, що вказує на ініціалізацію SDK. Вона генерує відмінний ідентифікатор, якщо він ще не існує, захоплює початковий перегляд сторінки з реферером, параметрами UTM та ідентифікаторами кліків, і негайно починає записувати кожну наступну взаємодію проти цього ідентифікатора — кліки, дотики, зміни форм, зміни маршрутів, власні події та, коли інтеграція Contentsquare увімкнена, повний відрендерений DOM diff для відтворення сеансу.
Кожна з цих діяльностей активує окремий шлюз згоди. Збереження ідентифікатора користувача є операцією зберігання та доступу відповідно до Статті 5(3) Директиви ePrivacy і вимагає попередньої, вільно наданої, конкретної, інформованої та однозначної згоди в усій EEA, UK та будь-якій юрисдикції, що прийняла той самий стандарт. Захоплення потоку подій автоматичного захоплення є обробкою персональних даних відповідно до GDPR, оскільки комбінація ідентифікатора, IP-адреси та поведінкового сліду достатня для ідентифікації особи. Відтворення сеансу знаходиться в окремій, суворішій категорії відповідно до рекомендацій EDPB щодо відтворення сеансів — відтворення захоплює відрендерений DOM та будь-які незамасковані поля введення і вимагає явної, деталізованої згоди, що відрізняється від загальної аналітичної згоди. CCPA та CPRA розглядають таку ж обробку як продаж або передачу, якщо видавець не має відповідного договору з постачальником послуг з Heap — що Heap пропонує, але договір набирає чинності лише тоді, коли інтеграція налаштована для режиму постачальника послуг.
Що Heap записує до отримання згоди — і що потрібно придушити
Стандартний quickstart, що постачається з панеллю керування Heap, встановлює фрагмент відстеження безпосередньо в <head> сторінки. Це працює так, як задокументовано, і є джерелом найбільш поширеної помилки відповідності в розгортаннях Heap: фрагмент запускається до того, як відрендерено банер cookie, файли cookie _hp2_ записуються в мілісекундах, а потік автоматичного захоплення починає надходити до heapanalytics.com незалежно від того, що пізніше вирішить користувач. Кожен європейський регулятор, який виніс рішення щодо цього шаблону, виніс однаковий висновок: файли cookie, встановлені до отримання згоди, є незаконними, і відповідальність несе видавець.
Тому сумісна інтеграція повинна запобігати завантаженню фрагмента Heap до надання відповідної категорії згоди. Два шаблони, що працюють у виробництві, — це умовне впровадження скрипту — фрагмент додається до DOM лише після того, як CMP сигналізує про згоду — та попереднє завантаження фрагмента з heap.load(appId, { disableTextCapture: true, secureCookie: true, autocapture: false }) як відкладений bootstrap і потім виклик heap.startAutoCapture() після реєстрації згоди. Шаблон умовного впровадження є чистішим і саме його тепер рекомендує документація Heap. Шаблон відкладеного bootstrap — правильний вибір, коли видавцю потрібне стабільне глобальне посилання для зшивання ідентичності, але не можна дозволити автоматичному захопленню спрацьовувати до отримання згоди.
Файли cookie та сховище, які записує Heap
Фрагмент Heap записує такі ідентифікатори під час ініціалізації, всі з яких не є обов'язковими і вимагають згоди: _hp2_id.{envId} зі строком дії 14 місяців, що містить ідентифікатор користувача, _hp2_ses_id.{envId} зі строком дії сеансу 30 хвилин, _hp2_props.{envId} для частоти вибірки та поширення властивостей та _hp2_loaded як маркер завантаження. Інтегрований із Contentsquare модуль відтворення сеансу додає буфер запису в пам'яті, який скидається до кінцевої точки Heap кожні кілька секунд і може окремо зберігати невеликий ідентифікатор сеансу відтворення. Відкликання згоди тому повинно і анулювати файли cookie _hp2_, і надіслати запит на видалення через GDPR API Heap для попередніх записів та потоку подій користувача.
Зіставлення Heap з рамками згоди
Heap не реалізує IAB TCF або IAB Global Privacy Platform нативно — це платформа продуктової аналітики першої сторони, а не постачальник adtech — але інтегрується з Google Consent Mode v2 через мостове з'єднання на стороні видавця, надає нативний API вибору та відмови, а також підтримує шар редагування чутливих властивостей, який працює незалежно від стану згоди. Шаблон, що витримує перевірку регулятора, розглядає кожен модуль Heap як окремий шлюз, прив'язаний до певного сигналу CMP.
- Автоматичне захоплення та основний потік подій прив'язані до аналітичної мети. У термінах TCF це найчастіше мета 8 (вимірювання ефективності контенту) у поєднанні з метою 1 (зберігання та/або доступ до інформації). Для Consent Mode це відображається на analytics_storage.
- Відтворення сеансу через інтеграцію Contentsquare знаходиться за суворішим, окремим шлюзом, оскільки відтворення захоплює відрендерений DOM та будь-які незамасковані поля введення, а рекомендації EDPB щодо відтворення сеансів розглядають це як категорію, що вимагає явної та деталізованої згоди, відмінної від загальної аналітики.
- Ідентифікація користувача через heap.identify() може виконуватися з ефемерним ідентифікатором сеансу на підставі законного інтересу, коли користувач анонімний, але зшивання ідентифікації з постійним ідентифікатором першої сторони через сеанси вимагає тієї ж згоди, що й аналітика, оскільки саме тоді ідентифікатор стає відстежуваною точкою даних рівня користувача.
- Міжсайтове або міжпродуктове поширення ідентичності через identity API вимагає маркетингового шлюзу, оскільки перетинає межу від продуктової аналітики до маркетингової атрибуції на рівні користувача.
Шаблон інтеграції, що працює
Референсне розгортання має чотири частини: CMP, що надає подію зміни згоди в реальному часі, відкладений bootstrap, що завантажує Heap із вимкненим автоматичним захопленням, слухач згоди, який вмикає автоматичне захоплення і запускає буфер відтворення сеансу, коли відкриваються відповідні шлюзи, та шлях відкликання, який викликає heap.resetIdentity(), зупиняє автоматичне захоплення, анулює файли cookie _hp2_ та відправляє запит на видалення через кінцеву точку GDPR Heap.
Веб-реалізація
У вебі найчистіший шаблон — умовне завантаження фрагмента Heap — тег <script> впроваджується лише після надання аналітичної категорії. Підпишіться на подію зміни згоди CMP. Коли аналітична категорія переходить у значення true, впровадьте фрагмент Heap з secureCookie: true, disableTextCapture: false для повного автоматичного захоплення та будь-якою конфігурацією, специфічною для середовища. Коли згода на відтворення сеансу переходить у значення true і інтеграція Contentsquare увімкнена, буфер відтворення активується автоматично. Коли будь-який шлюз відкликається, викличте heap.resetIdentity(), потім видаліть елемент скрипта Heap, анулюйте файли cookie _hp2_ через document.cookie та викличте GDPR API видалення для ідентифікатора користувача.
Редагування чутливих властивостей
Heap постачається з шаром редагування, який працює незалежно від стану згоди і який видавці повинні використовувати навіть після отримання згоди. Атрибут data-heap-redact-text у полі форми пригнічує захоплений текстовий вміст; атрибут data-heap-redact-attributes пригнічує атрибути елемента. Відповідно до правил спеціальних категорій GDPR та визначення конфіденційної особистої інформації CCPA, будь-яке поле, що може захоплювати медичну інформацію, фінансові деталі, державні ідентифікатори, біометричні дані, точну геолокацію або вміст приватних комунікацій, повинно використовувати атрибути редагування незалежно від стану згоди користувача. Встановлення атрибутів на рівні форми є найбезпечнішим шаблоном — він пригнічує всю форму навіть тоді, коли розробник додає нове поле, яке він забуває позначити індивідуально.
Вибір регіону: резиденція даних ЄС vs США
Heap використовує окремі кінцеві точки прийому ЄС та США. Для трафіку EEA та UK кінцева точка ЄС є правильним значенням за замовчуванням; вона зберігає прийом, обробку та зберігання в межах EEA і зменшує ризик Schrems II, який несе будь-яке аналітичне розгортання в регіоні США. Кінцева точка встановлюється через конфігурацію фрагмента і не може бути змінена ретроактивно — існуючі дані залишаються там, де вони були вперше отримані. Для видавців, які планують розгортання Heap, тому варто підтвердити регіон до масштабування та задокументувати вибір у повідомленні про конфіденційність, щоб ланцюг правової основи був чистим від збору до зберігання.
Перевірка інтеграції та аудиторський слід
Крок перевірки — це те, що регулятори перевіряють і що видавці найчастіше пропускають. Правильно інтегроване розгортання Heap повинно пройти чотири тести послідовно. По-перше, чиста сесія браузера з відображеним банером, але без зробленого вибору, повинна дати нуль запитів до heapanalytics.com окрім отримання файлу SDK та нуль файлів cookie _hp2_ у document.cookie. По-друге, відмова від аналітики повинна зберігати цей стан — без автоматичного захоплення, без ідентифікатора, без запису. По-третє, прийняття аналітики повинно дати очікуваний файл cookie _hp2_id з правильними атрибутами SameSite та трафік подій, що надходить до налаштованої регіональної кінцевої точки. По-четверте, відкликання згоди повинно негайно зупинити подальше автоматичне захоплення та відтворення, анулювати файли cookie _hp2_ та ініціювати запит на видалення через GDPR API Heap.
Очікування аудиторського сліду відповідно до рекомендацій EDPB щодо банера cookie 2023 року та оновлених пріоритетів робочої групи 2026 полягає в тому, що видавець може довести для будь-якої події в проекті Heap, що користувач, який її згенерував, надав дійсну згоду в момент захоплення. Стандартний шаблон полягає в установці версії згоди та позначки часу як властивостей користувача для відмінного ідентифікатора через heap.addUserProperties({ consent_version: 'v3', consent_ts: ts }), щоб будь-яка окрема подія була відстежувана до конкретного запису журналу згоди. Правильно налаштоване розгортання у поєднанні з атрибутами редагування, що за замовчуванням пригнічують чутливі поля, та шляхом видалення, який активується при відкликанні, — це те, що перетворює модель автоматичного захоплення Heap з регуляторного ризику концентрації на одну з найпотужніших та найбільш захищених частин аналітичного стеку продуктів видавця.