Hva Mixpanel samler inn

Mixpanel SDK (lastet fra cdn.mxpnl.com eller selvhostet) initialiserer et globalt mixpanel-objekt og identifiserer brukere med en Mixpanel-eid informasjonskapsel som inneholder en generert distinkt ID. Fra det øyeblikket rapporterer hvert kall til mixpanel.track() en hendelseslast — hendelsesnavn, egenskaper, den distinkte ID-en og et sett med automatisk innhentede egenskaper (brukeragent, operativsystem, henviser, UTM-parametere, skjermoppløsning, tidssone) — til Mixpanels inntak-endepunkt. SDK-en støtter også en Autocapture-modus som overvåker DOM-en og sender klikk-, sidevisnings- og skjemainnsendingshendelser uten eksplisitt instrumentering, noe som dramatisk utvider overflaten av det som samles inn.

Når en bruker autentiserer seg og applikasjonen kaller mixpanel.identify(user_id), blir alle påfølgende hendelser — og, avhengig av konfigurasjon, alle tidligere anonyme hendelser — assosiert med den autentiserte identiteten. Den retroaktive assosiasjonen er en av Mixpanels mest nyttige funksjoner og en av de mest eksponerende fra et personvernperspektiv: anonym surfeatferd innsamlet før samtykke blir retroaktivt knyttet til en identifisert profil i det øyeblikket brukeren logger inn.

Hvorfor «produktanalyse»-innrammingen ikke fritar deg fra samtykke

Et vanlig argument fra produkt- og utviklingsteam er at Mixpanel-data er for interne produktbeslutninger, ikke for markedsføring eller annonsering, og at denne interne bruk-innrammingen bør være tilstrekkelig begrunnelse under GDPRs grunnlag for berettiget interesse. Argumentet er i stor grad feil av tre grunner som regulatorer har vært eksplisitte om.

Behandlingen er fortsatt behandling av personopplysninger

Uavhengig av hvorfor dataene samles inn, er informasjonskapslene ikke-essensielle under ePrivacy Article 5(3) og hendelsene bærer vedvarende identifikatorer under GDPRs definisjon av personopplysninger. Analysen av rettslig grunnlag er den samme som for ethvert annet sporingsskript.

Berettiget interesse krever en avveiningsvurdering

CNIL, ICO og EDPB har alle skrevet veiledning som gjør det klart at berettiget interesse for atferdsanalyse krever en dokumentert vurdering som viser at behandlingen er nødvendig, forholdsmessig og ikke overstyrer brukerens rimelige forventninger. For en tredjeparts SaaS-leverandør som mottar hendelsesdata på brukernivå, lykkes sjelden denne avveiningsvurderingen uten eksplisitt samtykke.

Grensekryssende overføring er uavhengig

Selv om du kunne etablere berettiget interesse for selve innsamlingen, har den internasjonale overføringen til Mixpanels amerikanske infrastruktur sitt eget krav til rettslig grunnlag som samtykke eller en kontraktsmessig sikkerhet vanligvis tilfredsstiller renere enn berettiget interesse alene.

Innebygde personvernkontroller i Mixpanel

Mixpanel eksponerer et meningsfylt sett med personvernprimitiver som er designet for å støtte samtykke-styrte implementeringer. Som med de fleste plattformer antar de at samtykkesbeslutningen eksisterer oppstrøms; de samler den ikke inn selv.

opt_out_tracking

Kallet mixpanel.opt_out_tracking() stopper SDK-en fra å sende hendelser og bevarer opt-out-preferansen på tvers av økter. Par det med mixpanel.opt_in_tracking() når brukeren aksepterer analysekategorien i din CMP. SDK-en respekterer denne innstillingen på tvers av alle påfølgende kall uten å kreve re-initialisering.

has_opted_out_tracking

En spørrefunksjon som returnerer gjeldende opt-out-tilstand, nyttig for å synkronisere SDK-tilstanden med din CMP-tilstand ved sidelasting eller ruteendring.

EU-residensalternativet

Mixpanel tilbyr en EU-dataresidensprosjekttype som holder hendelsesdata innenfor Frankfurt-basert infrastruktur. Dette adresserer en meningsfull del av bekymringen rundt grensekryssende overføring og er riktig konfigurasjon for ethvert prosjekt der EU-residens er et hardt krav. Det eliminerer ikke samtykkekravet.

set_config({ ip: false })

Deaktiverer innhenting av IP-adresse, noe som reduserer personopplysningsavtrykket for hver hendelse. Nyttig som et forsvar-i-dybden-tiltak sammen med samtykke-styring.

Trinnvis CMP-integrasjon

Integrasjonsmønsteret som fungerer pålitelig er å initialisere Mixpanel i en opt-out-tilstand som standard, deretter velge brukeren inn når de aksepterer analysekategorien i CMP-en.

1. Initialiser Mixpanel med opt-out som standard

Kall mixpanel.init(token, { opt_out_tracking_by_default: true }) så tidlig som mulig i applikasjonsoppstarten din. Dette laster SDK-en men hindrer den fra å sende noen hendelser før opt_in_tracking() kalles.

2. Koble til samtykke-tilbakekallet

Når CMP-en utløser sin analyse-kategori-akseptert-hendelse, kall mixpanel.opt_in_tracking(). Køede hendelser som ble fanget under opt-out-perioden blir vanligvis forkastet; hvis du trenger å beholde dem, konfigurer SDK-ens køatferd eksplisitt og aksepter den lille risikoen for at hendelser fra før-samtykke-perioden sendes etter samtykke.

3. Håndter tilbaketrekking

Hvis brukeren senere trekker tilbake samtykket, kall mixpanel.opt_out_tracking(). Dette stopper videre hendelsesinntak. For full sletting av historiske data må applikasjonen i tillegg kalle Mixpanels slette-API eller utløse en sletteforespørsel fra Mixpanel-prosjektets brukergrensesnitt.

4. Unngå retroaktiv identitetssammenslåing uten eksplisitt samtykke

Deaktiver identify-kallets retroaktive sammenslåingsatferd med mindre brukeren har samtykket til å få sin pre-identifikasjons-surfing knyttet til sin profil. Mixpanels SDK-alternativer eksponerer et flagg for dette; den konservative standarden er «ingen retroaktiv sammenslåing».

5. Bruk EU-residensprosjektet for EU-trafikk

For prosjekter der EU-residens betyr noe, rut EU-trafikk til et EU-residens Mixpanel-prosjekt og US/annen trafikk til et separat prosjekt. SDK-en støtter lasting av forskjellige token betinget av brukerens oppdagede region.

Vanlige fallgruver

Fire integrasjonsfeil står for de fleste revisjonsfunnene på Mixpanel-implementeringer.

Behandle Mixpanel som unntatt fordi det er intern bruk

Dette er den enkelt vanligste feilen. Dataene er personopplysninger, informasjonskapselen er ikke-essensiell, og tredjepartsoverføringen er reell uavhengig av hvordan dataene brukes nedstrøms. Styr Mixpanel under analysesamtykke som enhver annen sporer.

La Autocapture være på som standard

Autocapture utvider dramatisk overflaten av det som sendes — hvert klikk, hver inndatafelt-interaksjon, hver sidevisning. Risikooverflaten skalerer med den. For de fleste SaaS-implementeringer produserer eksplisitt instrumentering renere data og et mindre revisjonsavtrykk enn Autocapture; slå av Autocapture med mindre du har en spesifikk grunn til å beholde den.

Glemme den retroaktive identitetssammenslåingen

Standard identify-atferd assosierer anonyme hendelser med den nå-identifiserte brukeren. Hvis brukeren aksepterte analysesamtykke først i det øyeblikket de logget inn, skaper retroaktiv assosiasjon av deres pre-samtykke anonyme surfing et dokumentasjonsproblem. Deaktiver retroaktiv sammenslåing eller begrens den eksplisitt til post-samtykke-hendelser.

Hardkode EU-residensantagelsen

Et overraskende antall team ruter all trafikk til et US-residens Mixpanel-prosjekt under antagelsen om at samtykke dekker residensspørsmålet. Det gjør det ikke — samtykke og residens er uavhengige samsvarsspørsmål. Rut etter oppdaget region, ikke etter global standard.

Revisionssjekkliste

Seks konkrete spørsmål å besvare for enhver Mixpanel-implementering som berører EU-, UK- eller California-trafikk.

• Starter Mixpanel i opt-out? Bekreft at SDK-en initialiseres med opt_out_tracking_by_default: true og ingen hendelser utløses før samtykke.
• Utløses opt-in på riktig CMP-hendelse? Bekreft at analyse-akseptert-tilbakekallet kaller opt_in_tracking(), ikke en mer tillatt hendelse.
• Er Autocapture nødvendig? Hvis den er på, dokumenter hvorfor. Hvis ikke, deaktiver den.
• Er retroaktiv sammenslåing deaktivert? Bekreft at identify-kallet ikke assosierer pre-samtykke anonym atferd med nylig identifiserte profiler.
• Er EU-trafikk på et EU-residensprosjekt? Bekreft at rutingslogikk sender EU-besøkende til et EU-prosjekttoken.
• Er sletteforespørsler automatisert? Bekreft at DSAR-forespørsler utløser Mixpanels slette-API i stedet for en manuell billett.

Hvor Mixpanel passer i en samtykke-først-stack

Produktanalyseplattformer okkuperer en regulatorisk kategori som produktteam ofte motsetter seg — de vil tenke på Mixpanel som intern infrastruktur, ikke som en tredjeparts-sporer. Regulatorer gjør ikke den distinksjonen, og håndhevingsaksjonene de siste to årene har gjort det klart at de ikke vil gjøre det. Riktig arkitektur behandler Mixpanel nøyaktig som enhver annen tredjeparts analyseoverflate: styr den bak samtykke, bruk plattformens innebygde opt-in-primitiver for å håndheve styringen, rut EU-trafikk til EU-residensinfrastruktur, og deaktiver funksjonene (Autocapture, retroaktiv identify-sammenslåing) som utvider revisjonsoverflaten uten proporsjonal analytisk fordel. Gjort riktig beholder produktteam trakt- og retensjonsdataene de trenger, og juridisk team beholder dokumentasjonen det trenger for å forsvare implementeringen under revisjon.