SUPP-121: Repair broken changelog redirects in Data Clean-Up and EU Residency docs

docs/data-governance/data-clean-up.mdx

@@ -20,17 +20,17 @@
 
 #### Blocking events that are not queried
 
 [Lexicon](/docs/data-governance/lexicon) is our data dictionary in Mixpanel, and is where project owners and admins can add / manage descriptions for all events and properties to organize your data.
 
 - Order by volume descending. Are your users querying events with large volume? If not, you might want to think about blocking these events. Blocking events means that they will no longer be ingested in Mixpanel. This is especially helpful for apps, since you don’t need to release new app versions and wait for users to download the latest versions for the code change to take effect (we still recommend that you clean up the code on the backend though!).
 - Sometimes, customers may still want these large volume events because they rely on them downstream (via data pipelines). But if you’re not querying the events in Mixpanel itself, you shouldn’t send it in - if you’re on the [events plan](/docs/pricing#monthly-events-calculation), this increases your utilization; also, this clutters up the UI for users who don’t need to see it there. You could hide the event in the UI in Lexicon, but our recommended approach is to not send this data into Mixpanel at all.
 - If you’re leveraging our SDKs and want to continue doing so for ease of leveraging our ID management and default properties, an alternative is to route events from [Mixpanel’s SDKs via a proxy in your own domain](/docs/tracking-methods/sdks/javascript). This way, you get to push the events required for backend analyses directly into your warehouse, and send only the events users query in our UI to Mixpanel
 
 #### Cleaning up display names and adding descriptions for events
 
 It’s always helpful to add descriptions to your events so users know where they are triggered. If you’re an owner or admin, you can add the descriptions directly on the UI itself. You could also export the data into a CSV, update the description there, then import it back into Lexicon if it’s easier to clean up that way. If you leverage Segment, mParticle, or Avo.app, you can use that to import your event names and descriptions that way too.
 
 If you use Figma to identify your events, some customers add their links to the event descriptions as well.
 
 #### Adding tags to events
 
@@ -74,11 +74,11 @@
 
 ### Cleaning up user profiles
 
 If you want to clean up old user profile properties that are no longer being used, you can use our [Engage API](/reference/profile-delete-property) to remove these old user properties. We also provide a ‘people_unset’ method in the Mixpanel-utils Library [here](https://github.com/mixpanel/mixpanel-utils#unset-properties).
 
 ## 2. Deleting problematic data
 
 Data Deletion allows you to delete noisy or sensitive data from your Mixpanel project, helping you maintain the integrity of your analytics project, and preserve a clear view of user behavior.
 
 You might find this useful if you:
 - accidentally send Personal Identifiable Information (PII) in a property
@@ -106,7 +106,7 @@
 ### Who can use Data Deletion?
 
 You can use the Data Deletion tool in these scenarios:
 - Your Mixpanel role is Owner or Admin
 - Your data does not extend beyond the past 180 days (event time, not ingestion time)
 - Your event volumes are below 5 billion events per month, any month over the trailing 3 months
 - Your project has not had more than 10 deletes over the past calendar month
@@ -173,7 +173,7 @@
 
 ## 3. Drop Filters
 
 Drop Filters let you stop unwanted events from being ingested and stored into Mixpanel going forward. Where [Data Deletion](#2-deleting-problematic-data) addresses *past* problematic data, Drop Filters address it *proactively* — events matching your filter rules are dropped at ingestion and never stored, never queried, and never counted.
 
 You might find this useful if you:
 - Have **unwanted events** (e.g. test or staging events) leaking into your production project
@@ -203,7 +203,7 @@
 ### How to use
 
 <Warning>
     Dropped events are not stored and cannot be recovered. Review your filter carefully before saving. Filters are active within 10 minutes after creation and while drop filters can be deleted, the data dropped while they were active cannot be recovered unless sent to Mixpanel again.
 </Warning>
 
 <Frame>
@@ -246,5 +246,5 @@
 
 ### Other resources
 
-- [Event Approval](/changelogs/2023-06-01-event-approval)
+- [Event Approval](/changelogs#vet-new-events-and-ensure-data-trust-with-event-approval)
 - [Recovering from a hot shard](/docs/debugging/distinct-id-limits)

docs/privacy/eu-residency.mdx

@@ -4,17 +4,17 @@
 
 
 ## Overview
 Mixpanel believes in respecting and protecting people’s fundamental online privacy and data rights, which is why we've built Mixpanel's analysis tools in compliance with industry best practices and global data regulations like the GDPR and the CCPA.
 
 Visit our [Privacy Hub](https://mixpanel.com/legal/privacy-hub/) to see how we comply with various privacy guidelines.
 
 ## Storing Your Data in the European Union
 By default, Mixpanel stores user data on its US Servers via the Google Cloud Platform. However, Mixpanel also provides you with the option to process and store your customers' personal data in Europe via our [EU Data Residency Program](https://mixpanel.com/legal/eu-data-residency). 
 You can enable this by selecting the "EU Data Residency" option when creating a new project and using our EU subdomain during all API calls.
 
 <Warning>
 Important: For new EU projects created on or after August 18, 2025, no data will be ingested into your new EU data residency project unless your SDK is sending data to the EU endpoint. Ensure you are using the EU endpoint in your SDK configuration.
-For EU Projects created before August 18, 2025, US-to-EU Data Forwarding ends July 2026, please ensure you are using the EU endpoint in your SDK configuration. See [changelog here](/changelogs/2026-02-20-eu-forwarding-deprecation).
+For EU Projects created before August 18, 2025, US-to-EU Data Forwarding ends July 2026, please ensure you are using the EU endpoint in your SDK configuration. See [changelog here](/changelogs#deprecation-notice-legacy-us-to-eu-data-forwarding-ends-july-2026-for-eu-projects).
 </Warning>
 
 For existing EU projects created prior to August 18, 2025, we encourage you to update your SDK configuration to use the dedicated EU endpoint. This is a best practice that ensures your project is correctly aligned with its data residency.
@@ -27,11 +27,11 @@
 | [Data Pipelines API](/reference/create-warehouse-pipeline) | `data.mixpanel.com/api/2.0/nessie` | `data-eu.mixpanel.com/api/2.0/nessie` |
 | [Lexicon Schemas API](/reference/lexicon-schemas-api) | `mixpanel.com/api/app/projects` | `eu.mixpanel.com/api/app/projects` |
 
 You can find where your data is stored under Project Settings > Data Residency for existing projects. Additionally, projects stored in the EU will have a URL that starts with 'eu.mixpanel.com', whereas projects stored in the US will have a 'mixpanel.com' URL. If the wrong Data Residency location was chosen before implementation, you will need to create a new project with the applicable data storage option and migrate all your existing data. Mixpanel cannot assist with migrating an existing project with the wrong residency location. You can find out more about creating a new project [here](/docs/orgs-and-projects/managing-projects#creating-projects).
 
 
 ## Using Our SDKs
 Next, you'll need to set the server location to EU when initializing the Mixpanel library. You can find instructions for the required config settings for each SDK below:
 - [JavaScript](/docs/tracking-methods/sdks/javascript#eu-data-residency)
 - [Objective-C](/docs/tracking-methods/sdks/ios#eu-data-residency)
 - [Swift](/docs/tracking-methods/sdks/swift#eu-data-residency)
@@ -44,13 +44,13 @@
 - [Flutter](/docs/tracking-methods/sdks/flutter#eu-data-residency)
 
 ## Log in via SSO
 If you want the IdP-initiated flow to direct to [eu.mixpanel.com](https://eu.mixpanel.com/), prepend "eu." to your postback URL. For example, `mixpanel.com/security/login/1` would need to be changed to `eu.mixpanel.com/security/login/1`.
 
 ## EU Residency and CDPs
 
 If you are coming to use Mixpanel from a Customer Data Platform (CDP), we cannot guarantee that data ingestion, processing, and storage will always stay within the EU region. Please work with your CDP to ensure they are sending your data to the EU endpoint. 
 
 The following diagram shows how Mixpanel's Data Residency works:
 
 <Frame>
 ![image](/images/230121513-b3a8bb84-4a64-45d9-ad41-f38b3fe977ea.png)