Ръководство за интегриране на съгласие за бисквитки за FullStory цифрово изживяване и запис на сесии: Наръчник 2026
FullStory е доминиращата платформа в категорията анализ на цифровото изживяване по една причина: улавя всичко по подразбиране. Докато традиционните аналитични инструменти записват дискретни събития, инструментирани от разработчика, а платформите за продуктова аналитика записват взаимодействия плюс автоматично уловен допълнителен материал, FullStory улавя пълния рендериран DOM, следата на курсора, времето на натискане на клавиши, поведението при превъртане, ядосаните кликвания, мъртвите кликвания, мрежовите заявки и JavaScript грешките — и ги свързва в записи на сесии, през които анализаторът може да превърта кадър по кадър. Това покритие е продуктът. Именно затова FullStory се намира на пресечната точка на най-строгите правила за съгласие във всеки съвременен режим за поверителност. Насоките на EDPB за запис на сесии от 2023 г. и приоритетите на работната група за 2026 г. третират записа на сесии като отделна, по-строга категория за съгласие. CNIL беше най-публичният регулатор по темата, но не е единственият — Garante, ICO, испанската AEPD и нидерландската AP също са изразили съгласувани позиции. Разгръщане на FullStory, конфигурирано за улавяне с приоритет на съгласието, с правилно маскиране, правилно ограничаване и правилна одитна следа, е един от най-мощните инструменти, които издател може да използва; такова, което не е конфигурирано по този начин, е една от най-лесните цели, които регулаторът ще намери.
Защо FullStory попада в най-строгата категория за съгласие
Стандартната инициализация на FullStory прави всичко, което прави всеки инструмент за запис на сесии, плюс повече. Тя задава бисквитки от първа страна под пространството от имена fs_uid и fs_lua, съдържащи постоянния идентификатор на посетителя и времевия печат за последна активност, генерира идентификатор на сесия под fs_session и започва да предава рендерирания DOM към rs.fullstory.com в рамките на милисекунди след зареждане на страницата. Потокът включва всяко събитие за въвеждане, всяко движение на мишката, всяка позиция на превъртане, всеки преход на страница и — когато модулът за мрежово улавяне е активиран — всеки XHR и fetch отговор, издаден от страницата, с включени тела на отговора, освен ако операторът не е конфигурирал потискане.
Всяко от тези улавяния активира отделна порта за съгласие. Постоянството на идентификатора на посетителя е операция за съхранение и достъп съгласно Член 5(3) от Директивата ePrivacy, изискваща предварително, свободно дадено, конкретно, информирано и недвусмислено съгласие в ЕИП, Обединеното кралство и всяка юрисдикция, приела същия стандарт. Записването на рендерирания DOM е обработка на лични данни съгласно GDPR, тъй като визуалният запис е достатъчен за идентифициране и разкриване на съществено съдържание за потребителя. Улавянето на потока от натискания на клавиши е особена чувствителност: всичко, което потребителят въведе в поле на формуляр, се улавя кадър по кадър, и ако полето не е маскирано, записът включва въведеното съдържание. EDPB изрично заяви, че улавянето чрез запис на сесии е категория, изискваща изрично, детайлно съгласие, различно от общото съгласие за анализ — и че маскирането е допълнение към съгласието, а не негов заместник.
Какво записва FullStory преди съгласие — и какво трябва да бъде потиснато
Стандартното бързо стартиране на FullStory инсталира проследяващия фрагмент директно в <head> на страницата. Това работи, както е документирано, и е източникът на най-честата грешка при спазването: фрагментът се изпълнява преди банерът за бисквитки да е рендериран, бисквитките fs_uid и fs_session се записват в рамките на милисекунди, а потокът за запис на сесии започва да тече към rs.fullstory.com независимо от това, какво потребителят реши по-късно. Всеки европейски регулатор, произнесъл се по този модел, е стигнал до едно и също решение: бисквитките, зададени преди съгласие, са незаконни, записът, уловен преди съгласие, е незаконна обработка, а издателят носи отговорността.
Следователно съответстващата интеграция трябва да предотврати инициализацията на фрагмента на FullStory, докато не бъде предоставена съответната категория за съгласие. Моделът, който работи в производство, е API FS.consent() комбиниран с отложен запис: фрагментът се зарежда с FullStory({ orgId: 'XXX', recordOnlyThisIFrame: false }) и веднага се извиква FS.shutdown(), след което FS.restart() и FS.consent(true) се извикват само след като CMP сигнализира, че категорията за запис на сесии е предоставена. Алтернативният модел е условното инжектиране на скрипт — фрагментът на FullStory се добавя към DOM само след предоставяне на съгласие — което е по-чисто, но изисква операторът да загуби всяко свързване на идентичности преди съгласие, което FullStory иначе би предоставил.
Бисквитките и хранилището, записвани от FullStory
Фрагментът на FullStory записва следните идентификатори при инициализацията, всички от които са несъществени и изискват съгласие: fs_uid с многогодишно изтичане, съдържащ постоянния идентификатор на посетителя, fs_lua с времевия печат за последна активност на потребителя, fs_session с идентификатора на сесията, и маркерите за записно-състояние, използвани вътрешно от FullStory. Оттеглянето на съгласие следователно трябва едновременно да изтрие тези бисквитки и да извика FS.consent(false), последвано от FS.shutdown(), за да спре по-нататъшното улавяне, а издателят трябва да изпрати заявка за изтриване чрез крайната точка за поверителност на FullStory за предишните записи на потребителя.
Съпоставяне на FullStory с рамки за съгласие
FullStory не внедрява нативно IAB TCF или IAB Global Privacy Platform — той е платформа за цифрово изживяване от първа страна, а не доставчик на рекламни технологии. Той предоставя нативен API за съгласие и поддържа модел за маскиране с частна настройка по подразбиране, който работи независимо от състоянието на съгласие. Моделът, преживяващ проверката на регулатора, третира всеки модул на FullStory като отделна порта, обвързана с конкретен сигнал от CMP.
- Записът на сесии и пълният DOM поток се обвързват с специализирана категория за запис на сесии или изследвания, която е отделна от общата аналитика. Насоките на EDPB са изрични по този въпрос — съгласието за запис трябва да бъде отделно и детайлно, а не обединено с аналитика или маркетинг.
- Мрежовото улавяне е зад по-строга подпорта в рамките на същата категория, тъй като улавя тела на HTTP отговори, които могат да съдържат лични данни, несвързани с видимия интерфейс. Мрежовото улавяне трябва да е изключено по подразбиране и да се активира само за конкретни пътища на приложението, при които операторът е потвърдил, че телата на отговора не включват чувствителни данни.
- Свързването на идентичности чрез FS.identify() може да работи с временен идентификатор на сесия на основата на законен интерес, когато потребителят е анонимен, но свързването на идентификация с постоянен идентификатор от първа страна между сесии изисква същото съгласие като записа на сесии.
- Топлинните карти и анализите за конверсия, получени от потока за запис на сесии, наследяват портата от горния поток — те не са отделни повърхности за съгласие, а са продукти надолу по веригата от същите уловени данни.
Моделът на интеграция, който работи
Референтното разгръщане има четири части: CMP, която предоставя събитие за промяна на съгласието в реално време, отложено стартиране, инициализиращо FullStory с потиснато улавяне чрез FS.shutdown(), слушател за съгласие, извикващ FS.consent(true) и FS.restart(), когато портата за запис на сесии се отвори, и конфигурация за маскиране с частна настройка по подразбиране, строго потискаща всяко поле за въвеждане, освен ако изрично не е разрешено.
Маскиране с частна настройка по подразбиране
Слоят за маскиране на FullStory работи независимо от съгласието и трябва да бъде конфигуриран агресивно дори когато е предоставено съгласие. CSS класът fs-mask върху всеки елемент потиска съдържанието на елемента от записа; CSS класът fs-exclude изключва елемента изцяло от DOM потока; класът fs-block блокира и съдържанието, и структурата. Съгласно правилата за специалните категории на GDPR и дефиницията за чувствителна лична информация на CCPA, всяко поле, което би могло да улови здравна информация, финансови данни, правителствени идентификатори, биометрични данни, точно геолокация или съдържание на лични комуникации, трябва да използва атрибутите за маскиране независимо от състоянието на съгласие на потребителя. Препоръчителната позиция е да се приложи fs-mask на ниво формуляр, а не на ниво поле — разработчик, добавящ ново поле към съществуващ формуляр, е много по-малко вероятно да си спомни да го маскира индивидуално, отколкото да работи в рамките на обвивка за маскиране на ниво формуляр, която го улавя автоматично.
Избор на регион и местоположение на данните
FullStory управлява отделни крайни точки за поглъщане в САЩ и ЕС. За трафик от ЕИП и Обединеното кралство крайната точка на ЕС е правилният избор по подразбиране — тя задържа поглъщането, обработката и съхранението в рамките на ЕИП и намалява излагането на Schrems II, което би носило всяко разгръщане на запис на сесии в американски регион. Крайната точка се конфигурира за всяка организация в FullStory и не може да бъде променяна retroактивно, затова изборът на регион трябва да бъде направен преди мащабирането и документиран в известието за поверителност, така че веригата от правни основания да е чиста от събирането до съхранението.
Валидиране на интеграцията и одитната следа
Стъпката за валидиране е това, което проверяват регулаторите и което издателите най-често пропускат при инструменти за запис на сесии. Правилно интегрираното разгръщане на FullStory трябва да преминава четири теста по ред. Първо, чиста браузърна сесия с показан банер, но без направен избор, трябва да генерира нулеви заявки към rs.fullstory.com извън извличането на файла на SDK и нулеви бисквитки fs_ в document.cookie. Второ, отказването от съгласие за запис на сесии трябва да запази това състояние — без улавяне, без идентификатор, без запис. Трето, приемането на съгласие за запис на сесии трябва да генерира очакваната бисквитка fs_uid, едно единствено събитие FS.consent(true) и DOM потока, течащ към конфигурираната регионална крайна точка, с маскираните полета, потвърдени за улавяне само на заместителя за маска. Четвърто, оттеглянето на съгласие трябва незабавно да спре по-нататъшното улавяне, да изтрие бисквитките fs_ и да задейства заявка за изтриване чрез крайната точка за поверителност на FullStory за предишните записи на потребителя.
Очакването за одитна следа е там, където инструментите за запис на сесии са изправени пред най-строг контрол. Насоките на EDPB за банери с бисквитки от 2023 г. и обновените приоритети на работната група за 2026 г. изрично посочват, че издателят трябва да може да докаже, за всеки конкретен запис на сесия в проекта на FullStory, че потребителят, генерирал го, е дал валидно съгласие за запис на сесии в момента на улавяне. Стандартният модел е да се зададат версията на съгласието и времевият печат като потребителски променливи в идентификатора на FullStory чрез FS.setUserVars({ consent_version: 'v3', consent_ts: ts }), така че всеки отделен запис да може да бъде проследен до конкретен запис в дневника на съгласие. Правилно ограниченото разгръщане, съчетано с атрибути за маскиране, по подразбиране приети като частни, и път за изтриване, активиращ се при оттегляне, е това, което превръща покритието на FullStory от концентриран регулаторен риск в защитима част от стека за цифрово изживяване на издателя.