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