Gabay sa Integrasyon ng Cookie Consent para sa Heap Auto-Capture Product Analytics: 2026 Playbook para sa mga Publisher
Natatangi ang Heap sa ecosystem ng product analytics dahil sa ginagawa nito bilang default. Habang hinahiling ng Mixpanel, Amplitude, at PostHog sa publisher na i-instrument ang mga kaganapang mahalaga, awtomatikong kinukuha ng Heap ang lahat at hinahayaan ang analyst na tukuyin ang mga kaganapan nang retroaktibo mula sa nakuhang stream. Ang auto-capture na modelong ito ang nagtatakda na katangian ng produkto at ang dahilan kung bakit pinipili ito ng mga koponan; ito rin ang dahilan kung bakit ang default na deployment ng Heap ay nagtataglay ng isa sa pinakamalawak na behavioral data surface ng anumang tool na malamang na i-install ng publisher. Bawat klik, tap, scroll, pakikipag-ugnayan sa form, paglipat ng pahina, at galit na klik ay naitala laban sa isang patuloy na identifier sa loob ng ilang millisecond ng pag-load ng pahina — na nangangahulugang ang bawat isa sa mga operasyong iyon ay nagdudulot ng obligasyon sa consent. Ang magandang balita ay ang Heap, mula nang makuha ito ng Contentsquare, ay nagpapadala na ngayon ng isa sa mas detalyadong consent API sa espasyo ng product analytics; ang trabaho ay ang tamang pagkonekta nito sa buong auto-capture surface, ang identity layer, at ang session-replay module na idinagdag ng integrasyon ng Contentsquare.
Bakit nangangailangan ng consent ang Heap — at bakit mas malawak ang sagot kaysa sa karaniwang analytics
Ang default na initialization ng Heap ay gumagawa ng ilang bagay sa unang paint ng pahina. Nagtatakda ito ng first-party cookie sa ilalim ng _hp2_id.{envId} na naglalaman ng patuloy na user identifier, isang session cookie sa ilalim ng _hp2_ses_id.{envId} na may session identifier, isang sample-rate cookie sa ilalim ng _hp2_props.{envId}, at isang _hp2_loaded marker na nagpapahiwatig na nailalabas na ang SDK. Gumagawa ito ng natatanging identifier kung wala pa ito, kinukuha ang unang pageview na may referrer, mga UTM parameter, at mga click identifier, at agad na nagsisimulang itala ang bawat kasunod na pakikipag-ugnayan laban sa identifier na iyon — mga klik, tap, pagbabago ng form, pagbabago ng ruta, custom na kaganapan, at kapag pinagana ang integrasyon ng Contentsquare, ang buong rendered DOM diff para sa session replay.
Ang bawat isa sa mga aktibidad na iyon ay nagpapagana ng hiwalay na consent gate. Ang pagpapanatili ng user identifier ay isang storage-and-access na operasyon sa ilalim ng Article 5(3) ng ePrivacy Directive at nangangailangan ng dating ibinigay, libreng ibinigay, tiyak, may kaalaman, at walang kalabuan na consent sa buong EEA, UK, at anumang hurisdiksyon na nag-import ng parehong pamantayan. Ang pagkuha ng auto-capture event stream ay pagpoproseso ng personal na datos sa ilalim ng GDPR dahil ang kombinasyon ng identifier, IP address, at behavioral trace ay sapat upang matukoy ang isang indibidwal. Ang session replay ay nasa hiwalay, mas mahigpit na kategorya sa ilalim ng session-replay guidance ng EDPB — kinukuha ng replay ang rendered DOM at anumang hindi natakpan na input field at nangangailangan ng tahasang, granular na consent na naiiba mula sa generic na analytics consent. Itinuturing ng CCPA at CPRA ang parehong pagpoproseso bilang isang pagbebenta o pagbabahagi maliban kung ang publisher ay may nauugnay na service-provider contract sa Heap — na inaalok ng Heap, ngunit ang kontrata ay magkakabisa lamang kapag ang integrasyon ay na-configure para sa service-provider mode.
Ano ang isinusulat ng Heap bago ang consent — at ano ang dapat sugpuin
Ang standard na quickstart na kasama ng Heap dashboard ay nag-i-install ng tracking snippet nang direkta sa <head> ng pahina. Gumagana iyon ayon sa dokumentasyon at siyang pinagmulan ng pinakakaraniwang kabiguan sa pagsunod sa mga deployment ng Heap: ang snippet ay tumatakbo bago ma-render ang banner ng cookie, ang mga _hp2_ cookie ay nasusulat sa loob ng ilang millisecond, at ang auto-capture stream ay nagsisimulang dumaan sa heapanalytics.com anuman ang mapagpasyahan ng user sa ibang pagkakataon. Bawat regulador sa Europa na nagdesisyon sa pattern na ito ay nagdesisyon sa parehong paraan: ang mga cookie na naitakda bago ang consent ay ilegal, at ang publisher ang may hawak ng responsibilidad.
Ang isang kumplikadong integrasyon ay dapat na pigilan ang pag-load ng Heap snippet hanggang sa maibigay ang nauugnay na kategorya ng consent. Ang dalawang pattern na gumagana sa production ay conditional script injection — ang snippet ay idinagdag sa DOM pagkatapos lamang na ma-signal ng CMP ang consent — at pre-loading ng snippet gamit ang heap.load(appId, { disableTextCapture: true, secureCookie: true, autocapture: false }) bilang deferred bootstrap at pagkatapos ay pagtawag ng heap.startAutoCapture() kapag naitala na ang consent. Ang pattern ng conditional injection ay mas malinis at ang inirerekomenda na ngayon ng dokumentasyon ng Heap. Ang pattern ng deferred bootstrap ay ang tamang pagpipilian kapag kailangan ng publisher ng matatag na global na sanggunian para sa identity stitching ngunit hindi maaaring payagan ang auto-capture na mag-apoy bago ang consent.
Ang mga cookie at storage na isinusulat ng Heap
Ang Heap snippet ay nagsusulat ng mga sumusunod na identifier sa initialization, lahat ng mga ito ay hindi esensyal at nangangailangan ng consent: _hp2_id.{envId} na may 14-buwang pag-expire na naglalaman ng user identifier, _hp2_ses_id.{envId} na may 30-minutong session expiry, _hp2_props.{envId} para sa sample-rate at property propagation, at _hp2_loaded bilang load marker. Ang Contentsquare-integrated session-replay module ay nagdaragdag ng in-memory recording buffer na naglilinis sa Heap endpoint tuwing ilang segundo at maaaring magpanatili ng maliit na replay-session identifier nang hiwalay. Ang pag-withdraw ng consent ay dapat kaya mag-expire ng mga _hp2_ cookie at mag-signal ng kahilingan sa pagtanggal sa pamamagitan ng GDPR API ng Heap para sa mga nakaraang recording at event stream ng user.
Pagmamapa ng Heap sa mga consent framework
Hindi native na nag-iimplementa ang Heap ng IAB TCF o ng IAB Global Privacy Platform — ito ay isang first-party product analytics platform, hindi isang ad-tech vendor — ngunit nag-iintegrate ito sa Google Consent Mode v2 sa pamamagitan ng publisher-side bridging, nagbubunyag ng native opt-in at opt-out API, at sumusuporta ng sensitive-property redaction layer na gumagana anuman ang estado ng consent. Ang pattern na nakaligtas sa pagsusuri ng regulador ay tinatrato ang bawat module ng Heap bilang hiwalay na gate na nakatali sa isang tiyak na CMP signal.
- Ang auto-capture at core event stream ay nakatali sa layunin ng analytics. Sa mga termino ng TCF ito ay kadalasang purpose 8 (sukatan ang performance ng nilalaman) na sinasamahan ng purpose 1 (mag-store at/o mag-access ng impormasyon). Para sa Consent Mode ito ay nagmamapa sa analytics_storage.
- Ang session replay sa pamamagitan ng integrasyon ng Contentsquare ay nasa likod ng mas mahigpit, hiwalay na gate dahil kinukuha ng replay ang rendered DOM at anumang hindi natakpan na input field, at itinuturing ng session-replay guidance ng EDPB ito bilang kategorya na nangangailangan ng tahasang at granular na consent na naiiba mula sa generic na analytics.
- Ang user identification sa pamamagitan ng heap.identify() ay maaaring tumakbo gamit ang isang panandaliang session identifier sa ilalim ng legitimate-interest basis kapag ang user ay anonymous, ngunit ang pag-stitch ng identification sa isang persistent first-party identifier sa mga session ay nangangailangan ng parehong consent bilang analytics dahil iyon ang oras na ang identifier ay nagiging isang traceable user-level data point.
- Ang cross-site o cross-product identity propagation sa pamamagitan ng identity API ay nangangailangan ng marketing gate dahil lumalagpas ito sa hangganan mula sa product analytics patungo sa user-level marketing attribution.
Ang pattern ng integrasyon na gumagana
Ang reference deployment ay may apat na bahagi: isang CMP na nagbubunyag ng real-time consent change event, isang deferred bootstrap na naglo-load ng Heap na may naka-disable na auto-capture, isang consent listener na nag-i-flip ng auto-capture sa on at nagsisimula ng session-replay buffer kapag nabuksan ang mga nauugnay na gate, at isang withdrawal path na tumatawag ng heap.resetIdentity(), tumitigil ng auto-capture, nag-e-expire ng mga _hp2_ cookie, at nagpapadala ng kahilingan sa pagtanggal sa pamamagitan ng GDPR endpoint ng Heap.
Implementasyon sa web
Sa web ang pinakamainam na pattern ay ang mag-load ng Heap snippet nang kondisyonal — ang tag na <script> ay iniinjeksyon pagkatapos lamang na maibigay ang kategorya ng analytics. Mag-subscribe sa consent change event ng CMP. Kapag ang kategorya ng analytics ay nagtransisyon sa true, i-inject ang Heap snippet na may secureCookie: true, disableTextCapture: false para sa buong auto-capture, at anumang environment-specific na configuration. Kapag ang session-replay consent ay nagtransisyon sa true at ang integrasyon ng Contentsquare ay pinagana, ang replay buffer ay awtomatikong ina-activate. Kapag ang alinman sa gate ay umurong, tawagin ang heap.resetIdentity() na sinusundan ng pag-alis ng Heap script element, i-expire ang mga _hp2_ cookie sa pamamagitan ng document.cookie, at i-invoke ang GDPR-deletion API para sa identifier ng user.
Redaksyon ng sensitibong property
Nagpapadala ang Heap ng redaction layer na gumagana anuman ang estado ng consent at na dapat gamitin ng mga publisher kahit na naibigay na ang consent. Ang attribute na data-heap-redact-text sa isang form field ay sumusugpo ng nakuhang text content; ang attribute na data-heap-redact-attributes ay sumusugpo ng mga attribute ng elemento. Sa ilalim ng mga tuntunin ng special-category ng GDPR at ng kahulugan ng sensitive-personal-information ng CCPA, ang anumang field na maaaring kumuha ng impormasyon sa kalusugan, detalye sa pananalapi, mga identifier ng pamahalaan, biometric na datos, tiyak na geolocation, o nilalaman ng mga pribadong komunikasyon ay dapat gumamit ng mga redaction attribute anuman ang estado ng consent ng user. Ang pagtatakda ng mga attribute sa antas ng form ay ang pinakaligtas na pattern — sumusugpo ito ng buong form kahit kapag ang isang developer ay nagdagdag ng bagong field na nakalimutang markahan nang indibidwal.
Pagpili ng rehiyon: EU vs US data residency
Nag-ooperate ang Heap ng hiwalay na EU at US ingestion endpoint. Para sa trapiko ng EEA at UK ang EU endpoint ang tamang default; pinapanatili nito ang ingestion, pagpoproseso, at storage sa loob ng EEA at binabawasan ang exposure sa Schrems II na tinataglay ng anumang US-region analytics deployment. Ang endpoint ay itinatakda sa pamamagitan ng snippet configuration at hindi maaaring baguhin nang retroaktibo — nananatili ang mga umiiral na datos kung saan ito unang na-ingest. Para sa mga publisher na nagpaplano ng rollout ng Heap, sulit na kaya kumpirmahing ang rehiyon bago mag-scale, at sulit na idokumento ang pagpili sa abiso sa privacy upang ang lawful-basis chain ay malinis mula sa koleksyon hanggang sa storage.
Pag-validate ng integrasyon at ng audit trail
Ang validation step ang sinusuri ng mga regulador at ang madalas na nilalaktawan ng mga publisher. Ang tamang integrated na deployment ng Heap ay dapat pumasa sa apat na pagsubok nang sunud-sunod. Una, ang malinis na session ng browser na may banner na ipinapakita ngunit walang pagpipiliang ginawa ay dapat gumawa ng zero na kahilingan sa heapanalytics.com higit sa SDK file fetch at zero na _hp2_ cookie sa document.cookie. Pangalawa, ang pagtanggi sa analytics ay dapat panatilihin ang estadong iyon — walang auto-capture, walang identifier, walang recording. Pangatlo, ang pagtanggap ng analytics ay dapat gumawa ng inaasahang _hp2_id cookie na may tamang SameSite attribute at event traffic na dumadaloy sa configured na region endpoint. Pang-apat, ang pag-withdraw ng consent ay dapat agad na ihinto ang karagdagang auto-capture at replay, mag-expire ng mga _hp2_ cookie, at mag-trigger ng kahilingan sa pagtanggal sa pamamagitan ng GDPR API ng Heap.
Ang inaasahan sa audit trail sa ilalim ng 2023 cookie banner guidelines ng EDPB at ng na-renew na 2026 task force priorities ay ang publisher ay maaaring mapatunayan, para sa anumang partikular na kaganapan sa Heap project, na ang user na lumikha nito ay nagbigay ng wastong consent sa sandali ng pagkuha. Ang standard na pattern ay ang itakda ang consent version at timestamp bilang mga user property sa distinct ID sa pamamagitan ng heap.addUserProperties({ consent_version: 'v3', consent_ts: ts }) upang ang anumang indibidwal na kaganapan ay masubaybayan pabalik sa isang tiyak na entry sa log ng consent. Ang tamang na-gate na deployment, kasama ang mga redaction attribute na nagsusupress ng sensitibong mga field bilang default at isang deletion path na ina-activate sa pag-withdraw, ay ang nagbabago ng auto-capture model ng Heap mula sa isang regulatory concentration risk patungo sa isa sa pinaka-makapangyarihan at mapagtatanggol na bahagi ng product analytics stack ng publisher.