Какво събира Mixpanel

Mixpanel SDK (зареден от cdn.mxpnl.com или самостоятелно хостван) инициализира глобален mixpanel обект и идентифицира потребителите с бисквитка, собственост на Mixpanel, съдържаща генериран уникален идентификатор. От този момент нататък всяко обаждане към mixpanel.track() докладва полезен товар на събитие — име на събитие, свойства, уникалния идентификатор и набор от автоматично заснети свойства (потребителски агент, операционна система, препращач, UTM параметри, разделителна способност на екрана, часова зона) — към крайната точка за приемане на Mixpanel. SDK също поддържа режим Autocapture, който наблюдава DOM и излъчва събития за кликване, преглед на страница и изпращане на формуляр без изрична инструментация, като драматично разширява повърхността на това, което се събира.

След като потребителят се удостовери и приложението извика mixpanel.identify(user_id), всички последващи събития — и, в зависимост от конфигурацията, всички предишни анонимни събития — се свързват с удостоверената идентичност. Ретроактивната асоциация е една от най-полезните функции на Mixpanel и една от най-разкриващите от гледна точка на поверителността: анонимното поведение при сърфиране, събрано преди съгласието, се свързва ретроактивно с идентифициран профил в момента, в който този потребител влезе.

Защо рамката "Продуктова аналитика" не ви освобождава от съгласие

Често срещан аргумент от продуктовите и инженерните екипи е, че данните на Mixpanel са за вътрешни продуктови решения, а не за маркетинг или реклама, и че това рамкиране за вътрешна употреба трябва да е достатъчно обосновка съгласно основанието на законния интерес на GDPR. Аргументът е до голяма степен неправилен по три причини, за които регулаторите са били изрични.

Обработката все още е обработка на лични данни

Независимо защо се събират данните, бисквитките са несъществени съгласно ePrivacy Article 5(3) и събитията носят постоянни идентификатори съгласно дефиницията на GDPR за лични данни. Анализът на законното основание е същият като при всеки друг скрипт за проследяване.

Законният интерес изисква тест за балансиране

CNIL, ICO и EDPB са написали ръководства, които оставят ясно, че законният интерес за поведенческа аналитика изисква документирана оценка, показваща че обработката е необходима, пропорционална и не отменя разумните очаквания на потребителя. За трета страна SaaS доставчик, получаващ данни за събития на ниво потребител, този тест за балансиране рядко успява без изрично съгласие.

Трансграничният трансфер е независим

Дори ако можете да установите законен интерес за самото събиране, международният трансфер към инфраструктурата на Mixpanel в САЩ носи собствено изискване за законно основание, което съгласието или договорна защита обикновено удовлетворяват по-ясно от самия законен интерес.

Собствени контроли за поверителност на Mixpanel

Mixpanel излага значителен набор от примитиви за поверителност, които са проектирани да поддържат внедрявания, блокирани от съгласие. Както при повечето платформи, те предполагат, че решението за съгласие съществува нагоре по веригата; те самите не го събират.

opt_out_tracking

Обаждането към mixpanel.opt_out_tracking() спира SDK от изпращане на събития и запазва предпочитанието за отказ през сесиите. Съчетайте го с mixpanel.opt_in_tracking(), когато потребителят приеме категорията аналитика във вашия CMP. SDK зачита тази настройка през всички последващи обаждания без да изисква повторна инициализация.

has_opted_out_tracking

Функция за заявка, която връща текущото състояние на отказ, полезна за синхронизиране на състоянието на SDK с вашето състояние на CMP при зареждане на страница или промяна на маршрут.

Опцията за резиденция в EU

Mixpanel предлага тип проект с резиденция на данни в EU, който запазва данните за събития в инфраструктура, базирана в Frankfurt. Това адресира значителна част от загрижеността за трансграничен трансфер и е правилната конфигурация за всеки проект, където резиденцията в EU е твърдо изискване. Това не елиминира изискването за съгласие.

set_config({ ip: false })

Деактивира заснемането на IP адрес, намалявайки отпечатъка от лични данни на всяко събитие. Полезна като мярка за защита в дълбочина заедно с блокирането чрез съгласие.

Стъпка по стъпка интеграция с CMP

Моделът на интеграция, който работи надеждно, е да инициализирате Mixpanel в състояние на отказ по подразбиране, след това да включите потребителя, когато той приеме категорията аналитика в CMP.

1. Инициализирайте Mixpanel с отказ по подразбиране

Извикайте mixpanel.init(token, { opt_out_tracking_by_default: true }) възможно най-рано в началното зареждане на вашето приложение. Това зарежда SDK, но го предотвратява от изпращане на каквито и да е събития, докато не бъде извикан opt_in_tracking().

2. Свържете обратното обаждане за съгласие

Когато CMP задейства своето събитие за приета категория аналитика, извикайте mixpanel.opt_in_tracking(). Събитията в опашка, които са били заснети по време на периода на отказ, обикновено се изхвърлят; ако трябва да ги запазите, конфигурирайте изрично поведението на опашката на SDK и приемете малкия риск, че събития от периода преди съгласието се изпращат след съгласието.

3. Обработете отмяната

Ако потребителят по-късно отмени съгласието, извикайте mixpanel.opt_out_tracking(). Това спира по-нататъшното приемане на събития. За пълно изтриване на исторически данни приложението трябва допълнително да извика API за изтриване на Mixpanel или да задейства заявка за изтриване от потребителския интерфейс на проекта Mixpanel.

4. Избягвайте ретроактивното сливане на идентичности без изрично съгласие

Деактивирайте поведението на ретроактивно сливане на обаждането identify, освен ако потребителят не е дал съгласие да бъде неговото сърфиране преди идентификация обвързано с неговия профил. Опциите на SDK на Mixpanel излагат флаг за това; консервативната стойност по подразбиране е "без ретроактивно сливане".

5. Използвайте проект с резиденция в EU за трафик от EU

За проекти, където резиденцията в EU има значение, насочете трафика от EU към проект на Mixpanel с резиденция в EU, а трафика от САЩ/други към отделен проект. SDK поддържа зареждане на различни токени в зависимост от открития регион на потребителя.

Често срещани капани

Четири грешки при интеграция отчитат повечето от констатациите от одит на внедряванията на Mixpanel.

Третиране на Mixpanel като освободен, защото е за вътрешна употреба

Това е най-често срещаната грешка. Данните са лични данни, бисквитката е несъществена, а трансферът към трета страна е реален, независимо как се използват данните по-надолу. Блокирайте Mixpanel под съгласие за аналитика като всеки друг тракер.

Оставяне на Autocapture включен по подразбиране

Autocapture драматично разширява повърхността на това, което се изпраща — всяко кликване, всяка интеракция с поле за въвеждане, всеки преглед на страница. Повърхността на риска се мащабира с нея. За повечето SaaS внедрявания изричната инструментация произвежда по-чисти данни и по-малък отпечатък при одит от Autocapture; изключете Autocapture, освен ако нямате конкретна причина да го запазите.

Забравяне на ретроактивното сливане на идентичности

Поведението на identify по подразбиране асоциира анонимни събития с вече идентифицирания потребител. Ако потребителят е приел съгласие за аналитика само в момента, в който е влязъл, ретроактивната асоциация на неговото анонимно сърфиране преди съгласието създава проблем с документацията. Деактивирайте ретроактивното сливане или го ограничете изрично до събития след съгласието.

Хардкодиране на предположението за резиденция в EU

Изненадващо голям брой екипи насочват целия трафик към проект на Mixpanel с резиденция в САЩ при предположението, че съгласието покрива въпроса за резиденцията. Не покрива — съгласието и резиденцията са независими въпроси за съответствие. Насочвайте по открит регион, а не по глобална стойност по подразбиране.

Контролен списък за одит

Шест конкретни въпроса, на които да отговорите за всяко внедряване на Mixpanel, докосващо трафик от EU, UK или Калифорния.

• Стартира ли Mixpanel в отказ? Потвърдете, че SDK се инициализира с opt_out_tracking_by_default: true и никакви събития не се задействат преди съгласието.
• Задейства ли се opt-in при правилното събитие на CMP? Потвърдете, че обратното обаждане за приета аналитика извиква opt_in_tracking(), а не по-разрешително събитие.
• Необходим ли е Autocapture? Ако е включен, документирайте защо. Ако не, деактивирайте го.
• Деактивирано ли е ретроактивното сливане? Потвърдете, че обаждането identify не асоциира анонимно поведение преди съгласието с новоидентифицирани профили.
• Трафикът от EU ли е на проект с резиденция в EU? Потвърдете, че логиката за насочване изпраща посетители от EU към токен на проект в EU.
• Автоматизирани ли са заявките за изтриване? Потвърдете, че заявките DSAR задействат API за изтриване на Mixpanel, а не ръчен билет.

Къде се вписва Mixpanel в стек, ориентиран към съгласие

Платформите за продуктова аналитика заемат регулаторна категория, на която продуктовите екипи често се противопоставят — те искат да мислят за Mixpanel като за вътрешна инфраструктура, а не като за тракер на трета страна. Регулаторите не правят това разграничение и действията по прилагане от последните две години оставиха ясно, че няма да го направят. Правилната архитектура третира Mixpanel точно като всяка друга повърхност за аналитика на трета страна: блокирайте го зад съгласие, използвайте собствените примитиви за opt-in на платформата, за да наложите блокирането, насочете трафика от EU към инфраструктура с резиденция в EU и деактивирайте функциите (Autocapture, ретроактивно сливане при identify), които разширяват повърхността за одит без пропорционална аналитична полза. Направено правилно, продуктовите екипи запазват данните за фунията и задържането, от които се нуждаят, а юридическият екип запазва документацията, необходима за защита на внедряването при одит.