Mixpanel EU-dataresidentie: hosts, verloren events, AVG

Mixpanel EU-dataresidentie betekent dat de events van je project worden verwerkt en opgeslagen in de EU-datacenters van Mixpanel. Er hoort één harde regel bij: elke afzender moet posten naar het EU-ingestie-endpoint, api-eu.mixpanel.com. Stuur je dezelfde events naar de standaard api.mixpanel.com, dan worden ze niet in de wachtrij gezet, doorgestuurd of gemarkeerd. Ze verschijnen gewoon nooit.

India werkt op dezelfde manier met api-in.mixpanel.com. De residentie wordt gekozen bij het aanmaken van het project, kan later niet worden omgezet, en elke tool die naar het project schrijft (browser-SDK, backend, CDP, forwarders van derden) moet apart de juiste host krijgen.

De meeste problemen komen uit dat laatste, en het werd deze zomer erger. Mixpanel stuurde vroeger events door die oudere EU-projecten op de VS-host ontvingen. Volgens de EU-residentiedocumentatie eindigde die doorsturing van VS naar EU in juli 2026 voor de meeste EU-projecten die vóór 18 augustus 2025 zijn aangemaakt. Setups die er ongemerkt op leunden, vielen stil. Werk je aan de bredere residentievraag voor je stack, begin dan bij de gids over EU-dataresidentie voor marketingtools; dit artikel blijft bij Mixpanel.

Wat Mixpanel EU-residentie dekt

EU-residentie is een opslagkeuze op projectniveau. Je vinkt "EU Data Residency" aan bij het aanmaken van het project, en vanaf dan verwerkt en bewaart Mixpanel de data van dat project in de EU in plaats van in de Amerikaanse standaard. Mixpanel heeft een parallel programma voor India dat het aan de Digital Personal Data Protection Act koppelt.

Drie dingen volgen uit het feit dat het op projectniveau werkt. Je organisatie kan VS- en EU-projecten naast elkaar hebben. De projecttoken verraadt zijn regio niet. Niets verderop kan het uit de token afleiden. En de interface verhuist mee: EU-projecten staan op eu.mixpanel.com, India-projecten op in.mixpanel.com, en daarom hebben SSO-postback-URL's voor de EU het voorvoegsel eu. nodig.

Wat het niet dekt, is het pad voordat de data Mixpanel bereikt. Mixpanel zegt dat zelf: komen events binnen via een customer data platform, dan kan het niet garanderen ("cannot guarantee") dat ingestie, verwerking en opslag in de EU blijven. Je pipeline is jouw probleem.

Ingestiehosts voor VS-, EU- en India-projecten

Ingestie is niet de enige regionale host. Elke API-familie heeft er een. Verander je alleen de trackinghost, dan raken je exports en queryscripts nog steeds de VS-hosts en falen ze tegen een EU-project.

De India-kolom komt van de India-residentiepagina van Mixpanel, die dezelfde families plus Data Pipelines en Lexicon Schemas onder data-in. en in. vermeldt. De EU-pagina spiegelt dit met -eu en eu..

Waarom events naar de verkeerde host verloren gaan

De formulering van Mixpanel is botweg: er wordt geen data opgenomen in een project met EU-residentie tenzij je implementatie die naar de EU-ingestie-URL stuurt. De India-pagina zegt hetzelfde over api-in.mixpanel.com.

Het pijnlijke is dat de verkeerde host het verzoek niet afwijst op een manier die de meeste tools opmerken. Het /track-endpoint neemt de token voor lief, dus een afzender die naar de VS-host wijst kan geslaagde antwoorden zien terwijl het EU-project leeg blijft. Je merkt het aan een vlakke grafiek, meestal een week later.

Debug dus vanuit het project. Vertrouw hier nooit de logs van de afzender. Open de Events-weergave in het EU-project, stuur één event en kijk of het binnenkomt. Niets binnen een minuut of twee betekent dat de host fout is of dat de token bij een ander project hoort.

Je residentie controleren en een bestaand project verhuizen

Controleren is snel. Project Settings toont een waarde voor Data Residency; of kijk naar de adresbalk, waar eu. of in. voor mixpanel.com het verraadt. Ik zou de waarde noteren in het document waarin je integraties staan, want elke tool die je later koppelt heeft hem nodig.

Verhuizen is het lastige. De documentatie van Mixpanel stelt dat als de verkeerde residentielocatie is gekozen, "you will need to create a new project with the applicable data storage option and migrate all your existing data," en dat Mixpanel bij de migratie niet kan helpen. In de praktijk betekent dat:

1. Maak een nieuw project met EU- (of India-)residentie en wijs elke afzender naar de nieuwe host en token.
2. Importeer de geschiedenis die je nodig hebt opnieuw en zet het oude project pas uit als rapporten en dashboards op het nieuwe zijn herbouwd.

Op die pagina's staat niet of een gemigreerde geschiedenis haar oorspronkelijke ID's of dashboards behoudt. Ik heb geen gedocumenteerde sluiproute gevonden en zou aannemen dat die er niet is.

Mixpanel-dataresidentie en AVG: IP's en doorgiften

Residentie beantwoordt één AVG-vraag goed: waar de opgeslagen data staat. Met een EU-project staat je eventgeschiedenis niet in de VS, waardoor een doorgifte onder hoofdstuk V uit het opslagbeeld verdwijnt. De AVG-gids voor URL-verkorters behandelt de plichten op artikelniveau die overblijven.

Het IP-adres is het detail dat mensen missen. Server-side afzenders voegen meestal het IP van de bezoeker toe als eigenschap ip, zodat Mixpanel het event kan geolokaliseren in plaats van iedereen op de server van de afzender te plaatsen. Volgens de geolocatiedocumentatie van Mixpanel wordt het IP gebruikt om land, regio en stad af te leiden en daarna weggegooid voordat het event wordt opgeslagen. Goed. Maar het IP reist wel mee in het verzoek, en een verzoek naar api.mixpanel.com is een verzoek naar een Amerikaans endpoint. Een verkeerde host is dus niet alleen een dataverliesbug. Het zijn ook persoonsgegevens die de EU verlaten naar een endpoint waarvan je verwerkingsregister zegt dat je het niet gebruikt.

Heb je geen locatie op stadsniveau nodig, dan kun je ip als 0 sturen en slaat Mixpanel geolocatie helemaal over. Al het andere blijft aan jou: rechtsgrond, toestemming voor cookies die de browser-SDK plaatst, de verwerkersovereenkomst en wat elke forwardingtool aan zijn kant bewaart. Het artikel Schrems II en trackingpixels behandelt hoe het doorgiftedebat uitpakt voor tags aan de browserkant.

Events naar het EU-ingestie-endpoint sturen vanuit elke tool

Elke afzender heeft een eigen instelling nodig. Er is geen schakelaar voor het hele account, dus maak een lijst en pas ze stuk voor stuk aan:

• Browser-SDK. Stel api_host in bij init, bijvoorbeeld mixpanel.init(TOKEN, { api_host: "https://api-eu.mixpanel.com" }), of de host api-in voor India.
• Server-SDK's en ruwe HTTP-aanroepen: laat de host wijzen naar api-eu.mixpanel.com (elke SDK heeft daarvoor een eigen configuratieoptie) of POST direct naar https://api-eu.mixpanel.com/track.
• CDP's, reverse-ETL-jobs en no-codeconnectors: zoek hun regio- of endpointveld, en vraag de leverancier schriftelijk als je het niet kunt vinden.
• Forwarders van derden die namens jou posten, zoals een linkverkorter die klikken verstuurt. Zij kunnen je residentie evenmin uit de token afleiden.

Controleer ze daarna stuk voor stuk in het EU-project. Eén testevent per afzender volstaat.

Uitgewerkt voorbeeld: de Mixpanel-forwarder van Elido

Elido stuurt elke klik op een korte link door naar Mixpanel als een server-side link_click-event met de slug, link-ID, land, apparaat, bestemming, tijdstempel en het ip van de bezoeker, afgekapt tot /24 (IPv4) of /48 (IPv6). Sinds 22 september 2026 heeft het verbindingsvenster een veld Data residency met drie opties, en elke optie verwijst naar een vaste host:

• Verenigde Staten: api.mixpanel.com (ook gebruikt als het veld leeg is)
• EU: api-eu.mixpanel.com
• India: api-in.mixpanel.com

De waarde wordt bij het opslaan gevalideerd; alles buiten die drie wordt afgewezen, zodat een typefout niet kan veranderen in een stille terugval naar de VS-host. Verbindingen die zijn opgeslagen voordat het veld bestond hebben geen waarde en blijven naar de VS-host gaan. Is je project EU-resident, open dan de Mixpanel-verbinding opnieuw met Update key, plak de projecttoken opnieuw (het venster toont de opgeslagen nooit), kies EU en sla op.

Dit is de beperking die ik uitgeschreven zou willen zien als ik dit beoordeelde. De knop Test connection kan de regio niet bewijzen. Hij stuurt één link_click gemarkeerd met elido_test: true en toont het antwoord van Mixpanel, maar /track accepteert elke token en controleert de residentie niet, dus een groen resultaat op de verkeerde host ziet er hetzelfde uit als een groen resultaat op de juiste. Het paneel zegt dat ook in zijn toelichting. Het bewijs is dat dat testevent in de Events-weergave van je EU-project aankomt.

Wees aan de kant van Elido duidelijk over wat residentie in Mixpanel wel en niet oplevert. Elido bewaart ook eigen klikrijen, met het IP van de bezoeker aan de edge afgekapt (IPv4 /24, IPv6 /48) plus stad en de volledige user-agent, en biedt geen vastpinnen van een regio per werkruimte, dus je kunt voor die rijen geen opslagregio kiezen zoals je dat in Mixpanel doet. Onze lijst van subverwerkers noemt wie met de data in aanraking komt. Zet beide opslagen in je verwerkingsregister. Wil je linkklikken in een EU-Mixpanel-project zonder zelf een forwarder te schrijven, start dan een werkruimte en koppel hem via de Mixpanel-integratie.

Twee hiaten om te kennen: de forwarder stuurt altijd het afgekapte ip (er is nu geen schakelaar voor ip: 0, behalve de modus zonder persoonsgegevens die alleen via de API werkt en het weglaat), en hij zet geen $insert_id, wat de gids voor Mixpanel-linktracking behandelt naast de distinct_id per link. Voor de bredere keuze waar klikdata moet staan, zie Mixpanel vs GA4 voor linkanalytics.

Gerelateerd op de blog

• Mixpanel-linktracking: klikken op korte links als events - setup, eigenschappen en verificatie voor de forwarder.
• EU-dataresidentie voor marketingtools: een DPO-checklist - wat je DPO vraagt naast de opslaglocatie.
• Is Google Analytics AVG-conform? - dezelfde vraag voor een tool zonder residentieoptie.
• Server-side conversietracking met korte links: een gids - waarom events de browser verlaten en wat dat verandert.