Co zbiera Mixpanel

SDK Mixpanel (ładowane z cdn.mxpnl.com lub hostowane samodzielnie) inicjalizuje globalny obiekt mixpanel i identyfikuje użytkowników za pomocą pliku cookie należącego do Mixpanel, zawierającego wygenerowany distinct ID. Od tego momentu każde wywołanie mixpanel.track() raportuje ładunek zdarzenia — nazwę zdarzenia, właściwości, distinct ID oraz zestaw automatycznie przechwyconych właściwości (user agent, system operacyjny, referrer, parametry UTM, rozdzielczość ekranu, strefa czasowa) — do punktu końcowego ingestion Mixpanel. SDK obsługuje również tryb Autocapture, który obserwuje DOM i emituje zdarzenia kliknięć, wyświetleń strony i wysyłania formularzy bez jawnej instrumentacji, dramatycznie rozszerzając zakres zbieranych danych.

Gdy użytkownik się uwierzytelni i aplikacja wywoła mixpanel.identify(user_id), wszystkie kolejne zdarzenia — i, w zależności od konfiguracji, wszystkie poprzednie anonimowe zdarzenia — są powiązane z uwierzytelnioną tożsamością. Retroaktywne powiązanie jest jedną z najbardziej użytecznych funkcji Mixpanel i jedną z najbardziej narażających z perspektywy prywatności: anonimowe zachowanie przeglądania zebrane przed zgodą zostaje retroaktywnie połączone ze zidentyfikowanym profilem w momencie, gdy użytkownik się zaloguje.

Dlaczego ujęcie „analityki produktowej" nie zwalnia z obowiązku uzyskania zgody

Częstym argumentem zespołów produktowych i inżynieryjnych jest to, że dane Mixpanel służą wewnętrznym decyzjom produktowym, a nie marketingowi czy reklamie, i że to wewnętrzne ujęcie powinno być wystarczającym uzasadnieniem w ramach podstawy prawnego interesu GDPR. Argument ten jest w dużej mierze nieprawidłowy z trzech powodów, o których regulatorzy wypowiedzieli się jednoznacznie.

Przetwarzanie nadal jest przetwarzaniem danych osobowych

Niezależnie od tego, dlaczego dane są zbierane, pliki cookie są nieistotne w rozumieniu ePrivacy Article 5(3), a zdarzenia zawierają trwałe identyfikatory zgodnie z definicją danych osobowych GDPR. Analiza podstawy prawnej jest taka sama jak dla każdego innego skryptu śledzącego.

Prawnie uzasadniony interes wymaga testu równowagi

CNIL, ICO i EDPB wydały wytyczne jasno wskazujące, że prawnie uzasadniony interes dla analityki behawioralnej wymaga udokumentowanej oceny wykazującej, że przetwarzanie jest konieczne, proporcjonalne i nie narusza uzasadnionych oczekiwań użytkownika. W przypadku zewnętrznego dostawcy SaaS otrzymującego dane o zdarzeniach na poziomie użytkownika, test równowagi rzadko kończy się sukcesem bez wyraźnej zgody.

Transfer transgraniczny jest niezależny

Nawet jeśli można by ustalić prawnie uzasadniony interes dla samego zbierania danych, międzynarodowy transfer do infrastruktury Mixpanel w USA niesie własny wymóg podstawy prawnej, który zgoda lub zabezpieczenie umowne zwykle spełniają czyściej niż sam prawnie uzasadniony interes.

Natywne kontrole prywatności Mixpanel

Mixpanel udostępnia znaczący zestaw prymitywów prywatności zaprojektowanych do obsługi wdrożeń bramkowanych zgodą. Jak w przypadku większości platform, zakładają one, że decyzja o zgodzie istnieje na wyższym poziomie; same jej nie zbierają.

opt_out_tracking

Wywołanie mixpanel.opt_out_tracking() zatrzymuje wysyłanie zdarzeń przez SDK i utrwala preferencję rezygnacji między sesjami. Sparuj je z mixpanel.opt_in_tracking(), gdy użytkownik zaakceptuje kategorię analityki w Twoim CMP. SDK respektuje to ustawienie we wszystkich kolejnych wywołaniach bez konieczności ponownej inicjalizacji.

has_opted_out_tracking

Funkcja zapytania, która zwraca bieżący stan rezygnacji, przydatna do synchronizacji stanu SDK ze stanem CMP przy ładowaniu strony lub zmianie trasy.

Opcja rezydencji w EU

Mixpanel oferuje typ projektu z rezydencją danych w EU, który przechowuje dane o zdarzeniach w infrastrukturze zlokalizowanej we Frankfurt. Rozwiązuje to znaczną część problemu transferu transgranicznego i jest właściwą konfiguracją dla każdego projektu, gdzie rezydencja w EU jest twardym wymogiem. Nie eliminuje to wymogu zgody.

set_config({ ip: false })

Wyłącza przechwytywanie adresu IP, zmniejszając ślad danych osobowych każdego zdarzenia. Przydatne jako środek obrony w głąb obok bramkowania zgodą.

Integracja z CMP krok po kroku

Wzorzec integracji, który działa niezawodnie, polega na inicjalizacji Mixpanel w stanie domyślnej rezygnacji, a następnie włączeniu użytkownika, gdy zaakceptuje kategorię analityki w CMP.

1. Zainicjalizuj Mixpanel z domyślną rezygnacją

Wywołaj mixpanel.init(token, { opt_out_tracking_by_default: true }) tak wcześnie, jak to możliwe podczas uruchamiania aplikacji. To ładuje SDK, ale uniemożliwia wysyłanie jakichkolwiek zdarzeń do momentu wywołania opt_in_tracking().

2. Podłącz callback zgody

Gdy CMP wyemituje zdarzenie zaakceptowania kategorii analityki, wywołaj mixpanel.opt_in_tracking(). Zakolejkowane zdarzenia przechwycone podczas okresu rezygnacji są zwykle odrzucane; jeśli potrzebujesz je zachować, skonfiguruj jawnie zachowanie kolejkowania SDK i zaakceptuj małe ryzyko, że zdarzenia z okresu przed zgodą zostaną wysłane po zgodzie.

3. Obsłuż wycofanie zgody

Jeśli użytkownik później wycofa zgodę, wywołaj mixpanel.opt_out_tracking(). To zatrzymuje dalsze przyjmowanie zdarzeń. Dla pełnego usunięcia danych historycznych aplikacja musi dodatkowo wywołać API usuwania Mixpanel lub uruchomić żądanie usunięcia z interfejsu projektu Mixpanel.

4. Unikaj retroaktywnego łączenia tożsamości bez wyraźnej zgody

Wyłącz zachowanie retroaktywnego łączenia wywołania identify, chyba że użytkownik wyraził zgodę na powiązanie przeglądania sprzed identyfikacji ze swoim profilem. Opcje SDK Mixpanel udostępniają flagę do tego; konserwatywna wartość domyślna to „brak retroaktywnego łączenia".

5. Używaj projektu z rezydencją w EU dla ruchu z EU

Dla projektów, gdzie rezydencja w EU ma znaczenie, kieruj ruch z EU do projektu Mixpanel z rezydencją w EU, a ruch z USA/innych regionów do osobnego projektu. SDK obsługuje ładowanie różnych tokenów w zależności od wykrytego regionu użytkownika.

Częste pułapki

Cztery błędy integracji odpowiadają za większość ustaleń audytowych dotyczących wdrożeń Mixpanel.

Traktowanie Mixpanel jako zwolnionego, ponieważ służy do użytku wewnętrznego

To najczęstszy błąd. Dane są danymi osobowymi, plik cookie jest nieistotny, a transfer do strony trzeciej jest realny, niezależnie od tego, jak dane są wykorzystywane dalej. Bramkuj Mixpanel zgodą na analitykę jak każdy inny tracker.

Pozostawienie Autocapture włączonego domyślnie

Autocapture dramatycznie rozszerza zakres wysyłanych danych — każde kliknięcie, każda interakcja z polem wprowadzania, każde wyświetlenie strony. Powierzchnia ryzyka skaluje się wraz z nim. Dla większości wdrożeń SaaS, jawna instrumentacja produkuje czystsze dane i mniejszy ślad audytowy niż Autocapture; wyłącz Autocapture, chyba że masz konkretny powód, by go zachować.

Zapominanie o retroaktywnym łączeniu tożsamości

Domyślne zachowanie identify kojarzy anonimowe zdarzenia z teraz zidentyfikowanym użytkownikiem. Jeśli użytkownik zaakceptował zgodę na analitykę dopiero w momencie logowania, retroaktywne powiązanie anonimowego przeglądania sprzed zgody stwarza problem dokumentacyjny. Wyłącz retroaktywne łączenie lub jawnie ogranicz je do zdarzeń po zgodzie.

Zakodowanie na sztywno założenia o rezydencji w EU

Zaskakująco wiele zespołów kieruje cały ruch do projektu Mixpanel z rezydencją w USA, zakładając, że zgoda pokrywa kwestię rezydencji. Tak nie jest — zgoda i rezydencja to niezależne pytania dotyczące zgodności. Kieruj według wykrytego regionu, nie według globalnego domyślnego.

Lista kontrolna audytu

Sześć konkretnych pytań do odpowiedzi dla każdego wdrożenia Mixpanel obsługującego ruch z EU, UK lub Kalifornii.

• Czy Mixpanel startuje w stanie rezygnacji? Potwierdź, że SDK inicjalizuje się z opt_out_tracking_by_default: true i żadne zdarzenia nie są wysyłane przed zgodą.
• Czy opt-in uruchamia się na właściwym zdarzeniu CMP? Potwierdź, że callback zaakceptowania analityki wywołuje opt_in_tracking(), a nie bardziej permisywne zdarzenie.
• Czy Autocapture jest konieczny? Jeśli jest włączony, udokumentuj dlaczego. Jeśli nie, wyłącz go.
• Czy retroaktywne łączenie jest wyłączone? Potwierdź, że wywołanie identify nie kojarzy anonimowego zachowania sprzed zgody z nowo zidentyfikowanymi profilami.
• Czy ruch z EU jest na projekcie z rezydencją w EU? Potwierdź, że logika routingu wysyła odwiedzających z EU do tokenu projektu EU.
• Czy żądania usunięcia są zautomatyzowane? Potwierdź, że żądania DSAR uruchamiają API usuwania Mixpanel, a nie ręczny zgłoszenie.

Gdzie Mixpanel pasuje w stosie stawiającym zgodę na pierwszym miejscu

Platformy analityki produktowej zajmują kategorię regulacyjną, której zespoły produktowe często się opierają — chcą myśleć o Mixpanel jako o wewnętrznej infrastrukturze, a nie jako o trackerze strony trzeciej. Regulatorzy nie dokonują takiego rozróżnienia, a działania egzekucyjne ostatnich dwóch lat jasno pokazały, że tego nie zmienią. Właściwa architektura traktuje Mixpanel dokładnie jak każdą inną powierzchnię analityki strony trzeciej: bramkuj go za zgodą, używaj natywnych prymitywów opt-in platformy do egzekwowania bramki, kieruj ruch z EU do infrastruktury z rezydencją w EU i wyłącz funkcje (Autocapture, retroaktywne łączenie identify), które rozszerzają powierzchnię audytu bez proporcjonalnej korzyści analitycznej. Wykonane prawidłowo, zespoły produktowe zachowują dane o lejku i retencji, których potrzebują, a zespół prawny zachowuje dokumentację potrzebną do obrony wdrożenia podczas audytu.