O que Recolle Mixpanel

O SDK de Mixpanel (cargado desde cdn.mxpnl.com ou autoaloxado) inicializa un obxecto global mixpanel e identifica usuarios cunha cookie propiedade de Mixpanel que contén un ID distinto xerado. Desde ese momento, cada chamada a mixpanel.track() informa unha carga útil de evento — nome do evento, propiedades, o ID distinto e un conxunto de propiedades capturadas automaticamente (axente de usuario, sistema operativo, referente, parámetros UTM, resolución de pantalla, fuso horario) — ao punto final de inxestión de Mixpanel. O SDK tamén admite un modo Autocapture que vixía o DOM e emite eventos de clic, visualización de páxina e envío de formularios sen instrumentación explícita, ampliando drasticamente a superficie do que se recolle.

Unha vez que un usuario se autentica e a aplicación chama a mixpanel.identify(user_id), todos os eventos posteriores — e, dependendo da configuración, todos os eventos anónimos anteriores — asócianse coa identidade autenticada. A asociación retroactiva é unha das características máis útiles de Mixpanel e unha das máis expostas desde unha perspectiva de privacidade: o comportamento de navegación anónimo recollido antes do consentimento vincúlase retroactivamente a un perfil identificado no momento en que ese usuario inicia sesión.

Por que o Enfoque de "Analítica de Produto" Non te Exime do Consentimento

Un argumento común dos equipos de produto e enxeñería é que os datos de Mixpanel son para decisións de produto internas, non para marketing ou publicidade, e que este enfoque de uso interno debería ser xustificación suficiente baixo a base de interese lexítimo do GDPR. O argumento é en gran medida incorrecto por tres razóns sobre as que os reguladores foron explícitos.

O procesamento segue sendo procesamento de datos persoais

Independentemente de por que se estean recollendo os datos, as cookies son non esenciais baixo ePrivacy Article 5(3) e os eventos levan identificadores persistentes baixo a definición de datos persoais do GDPR. A análise da base legal é a mesma que para calquera outro script de seguimento.

O interese lexítimo require unha proba de equilibrio

A CNIL, a ICO e a EDPB escribiron todas guías deixando claro que o interese lexítimo para a analítica de comportamento require unha avaliación documentada que mostre que o procesamento é necesario, proporcionado e non anula as expectativas razoables do usuario. Para un provedor SaaS de terceiros que recibe datos de eventos a nivel de usuario, esa proba de equilibrio raramente ten éxito sen consentimento explícito.

A transferencia transfronteiriza é independente

Mesmo se puideses establecer interese lexítimo para a recollida en si, a transferencia internacional á infraestrutura estadounidense de Mixpanel leva o seu propio requisito de base legal que o consentimento ou unha salvagarda contractual normalmente satisfai máis claramente que o interese lexítimo só.

Controis Nativos de Privacidade de Mixpanel

Mixpanel expón un conxunto significativo de primitivas de privacidade que están deseñadas para soportar implementacións condicionadas por consentimento. Como coa maioría das plataformas, asumen que a decisión de consentimento existe aguas arriba; non a recollen elas mesmas.

opt_out_tracking

A chamada mixpanel.opt_out_tracking() detén o envío de eventos do SDK e persiste a preferencia de exclusión entre sesións. Emparellaa con mixpanel.opt_in_tracking() cando o usuario acepta a categoría de analítica no teu CMP. O SDK respecta esta configuración en todas as chamadas posteriores sen requirir reinicialización.

has_opted_out_tracking

Unha función de consulta que devolve o estado actual de exclusión, útil para sincronizar o estado do SDK co estado do teu CMP ao cargar a páxina ou cambiar de ruta.

A opción de residencia da EU

Mixpanel ofrece un tipo de proxecto de residencia de datos da EU que mantén os datos de eventos dentro da infraestrutura baseada en Frankfurt. Isto aborda unha porción significativa da preocupación de transferencia transfronteiriza e é a configuración correcta para calquera proxecto onde a residencia da EU sexa un requisito ríxido. Non elimina o requisito de consentimento.

set_config({ ip: false })

Desactiva a captura de enderezos IP, reducindo a pegada de datos persoais de cada evento. Útil como medida de defensa en profundidade xunto coa protección de consentimento.

Integración CMP Paso a Paso

O patrón de integración que funciona de xeito fiable é inicializar Mixpanel nun estado de exclusión por defecto, logo incluír ao usuario cando acepte a categoría de analítica no CMP.

1. Inicializar Mixpanel co valor por defecto de exclusión

Chama a mixpanel.init(token, { opt_out_tracking_by_default: true }) o antes posible no arranque da túa aplicación. Isto carga o SDK pero evita que envíe calquera evento ata que se chame a opt_in_tracking().

2. Conectar a devolución de chamada de consentimento

Cando o CMP dispara o seu evento de categoría-de-analítica-aceptada, chama a mixpanel.opt_in_tracking(). Os eventos en cola que foron capturados durante o período de exclusión normalmente descártanse; se necesitas retelos, configura explícitamente o comportamento de cola do SDK e acepta o pequeno risco de que os eventos do período previo ao consentimento se envíen despois do consentimento.

3. Xestionar a revogación

Se o usuario posteriormente revoga o consentimento, chama a mixpanel.opt_out_tracking(). Isto detén a inxestión de eventos adicional. Para a eliminación completa de datos históricos, a aplicación debe chamar adicionalmente á API de eliminación de Mixpanel ou activar unha solicitude de eliminación desde a IU do proxecto Mixpanel.

4. Evitar a fusión retroactiva de identidade sen consentimento explícito

Desactiva o comportamento de fusión retroactiva da chamada identify a non ser que o usuario consentiu ter a súa navegación previa á identificación vinculada ao seu perfil. As opcións do SDK de Mixpanel expoñen unha marca para isto; o valor por defecto conservador é "non fusión retroactiva".

5. Usar o proxecto de residencia da EU para tráfico da EU

Para proxectos onde a residencia da EU importa, dirixe o tráfico da EU a un proxecto Mixpanel de residencia da EU e o tráfico de Estados Unidos/outros a un proxecto separado. O SDK admite cargar diferentes tokens condicionais á rexión detectada do usuario.

Trampas Comúns

Catro erros de integración representan a maioría dos achados de auditoría nas implementacións de Mixpanel.

Tratar Mixpanel como exento porque é de uso interno

Este é o erro máis común. Os datos son datos persoais, a cookie é non esencial e a transferencia a terceiros é real independentemente de como se usen os datos posteriormente. Protexe Mixpanel baixo consentimento de analítica como calquera outro rastrexador.

Deixar Autocapture activado por defecto

Autocapture amplía dramaticamente a superficie do que se envía — cada clic, cada interacción de campo de entrada, cada visualización de páxina. A superficie de risco escala con el. Para a maioría das implementacións SaaS, a instrumentación explícita produce datos máis limpos e unha pegada de auditoría máis pequena que Autocapture; desactiva Autocapture a non ser que teñas unha razón específica para mantelo.

Esquecer a fusión retroactiva de identidade

O comportamento de identificación por defecto asocia eventos anónimos co usuario agora identificado. Se o usuario aceptou o consentimento de analítica só no momento en que iniciou sesión, a asociación retroactiva da súa navegación anónima previa ao consentimento crea un problema de documentación. Desactiva a fusión retroactiva ou limítaa explícitamente a eventos posteriores ao consentimento.

Codificar en duro o suposto de residencia da EU

Un número sorprendente de equipos dirixe todo o tráfico a un proxecto Mixpanel de residencia en Estados Unidos baixo o suposto de que o consentimento cobre a cuestión da residencia. Non o fai — consentimento e residencia son preguntas de cumprimento independentes. Dirixe por rexión detectada, non por defecto global.

Lista de Verificación de Auditoría

Seis preguntas concretas para responder para calquera implementación de Mixpanel que toque tráfico da EU, UK ou California.

• Mixpanel comeza en exclusión? Confirma que o SDK se inicializa con opt_out_tracking_by_default: true e que non se disparan eventos antes do consentimento.
• A inclusión dispárase no evento CMP correcto? Confirma que a devolución de chamada de analítica-aceptada chama a opt_in_tracking(), non un evento máis permisivo.
• É necesario Autocapture? Se está activado, documenta por que. Se non, desactívao.
• Está desactivada a fusión retroactiva? Confirma que a chamada de identificación non asocia comportamento anónimo previo ao consentimento con perfís recentemente identificados.
• O tráfico da EU está nun proxecto de residencia da EU? Confirma que a lóxica de enrutamento envía visitantes da EU a un token de proxecto da EU.
• Están automatizadas as solicitudes de eliminación? Confirma que as solicitudes DSAR activan a API de eliminación de Mixpanel no canto dun billete manual.

Onde Encaixa Mixpanel nunha Pila que Prioriza o Consentimento

As plataformas de analítica de produto ocupan unha categoría regulatoria á que os equipos de produto adoitan resistirse — queren pensar en Mixpanel como infraestrutura interna, non como un rastrexador de terceiros. Os reguladores non fan esa distinción, e as accións de cumprimento dos últimos dous anos deixaron claro que non o farán. A arquitectura correcta trata Mixpanel exactamente como calquera outra superficie de analítica de terceiros: protéxeo detrás do consentimento, usa as primitivas nativas de inclusión da plataforma para aplicar a protección, dirixe o tráfico da EU á infraestrutura de residencia da EU e desactiva as funcionalidades (Autocapture, fusión de identificación retroactiva) que amplían a superficie de auditoría sen beneficio analítico proporcionado. Feito correctamente, os equipos de produto manteñen os datos de embudo e retención que necesitan, e o equipo legal mantén a documentación que necesita para defender a implementación baixo auditoría.