Every year, the gap between what marketers need from analytics and what privacy regulations allow them to collect narrows a little. For instance, as of 2025, GDPR enforcement fines have crossed €7.1 billion in cumulative penalties, and part of the reason is the multitude of reporting technologies available today that may not comply with privacy regulations.
That’s just one example of how non-compliance with privacy regulations can result in hefty fines. And yet, the default approach to analytics hasn’t changed much: collect as much behavioural data as possible, centralise it and build your reports on the full dataset. Attribution models, conversion tracking, audience segmentation: all of it depends on large volumes of raw data sitting in one place.
But with regulations tightening, that model is under pressure. And it’s not just regulators applying pressure. Users are opting out of tracking by rejecting cookies and choosing privacy-focused browsers and extensions with built-in protections.
Federated learning takes a different approach. Instead of dragging raw data to a central server, it sends the model to where the data already lives. Be it on user devices, on local servers and inside your own infrastructure. While it’s still a maturing technology, it’s already influencing how analytics tools are built and how privacy-conscious organisations think about their data strategy.
In this guide, we’ll explain the concept of federated learning, how it works, where it’s already being applied and how you can apply its principles to your web analytics solution.
What is federated learning?
Federated learning is a way of training machine learning models without moving the data they learn from. It doesn’t involve collecting data and moving it to a central location. Instead, it brings the model to the data.
The process works in a cycle:
- A central server sends a copy of the global model to each participating device or local server.
- Each device or server trains the model on its own local data. For example, your clickstream data stays on your server.
- Only the updated model parameters are returned, such as the mathematical weights and gradients.
- The central server aggregates these updates using an algorithm called Federated Averaging, which combines the individual updates into a single improved global model.
- That improved model gets redistributed, and the cycle starts again.
When applied in the real world, this process could help companies cut costs on false positives or negatives in areas like quality control and predictive maintenance. It could also help them maintain compliance with sector-specific data protection requirements and industry-level laws, like the EU’s Machinery Regulation, pulling model updates from IoT devices and other edge devices without ever collecting raw data.
3. Personalisation in marketing and advertising
Federated learning is beginning to make its mark in the marketing and advertising industry.
In 2024, a study introduced an FL-based ad recommendation model trained directly on users’ devices. Everything from browsing history to location data stays local but informs model updates. As a result, companies can get privacy‑preserving ad personalisation without ingesting raw interaction histories.
These examples show that federated learning is becoming more than just an experiment and is part of a broader shift to a stronger preference for privacy protecting technologies. Many organisations have working systems in place to improve data privacy, and you should expect your tools and vendors to do the same.
For instance, Matomo already prioritises privacy. It masks IP addresses by default and is able to fully anonymise them. Matomo doesn’t track visitors across sites and respects their DoNotTrack preferences.
How does federated learning compare with other privacy-preserving approaches?
Federated learning is a useful approach for training machine learning models because it ensures data privacy without requiring you to centralise large volumes of data. It supports compliance and scalability. But how does it compare to other privacy-preserving approaches? Let’s take a look.
Differential privacy
Differential privacy is a method where analysts can carefully add calibrated mathematical noise to datasets or query results. As a result, they can ask questions about a population and get approximately correct answers, but they can’t reverse-engineer whether any single person’s data was included (which is why it’s used for gradient leak prevention in some FL setups).
It’s a method Apple has used in the past to collect usage statistics from iPhones. It’s been used to improve QuickType and emoji suggestions over the years.
If you’re working on an analytics team, this method is most useful for population-level trends. For instance, aggregate conversion rates or traffic patterns rather than user-level precision. But it also means you’ll get less precise answers as you add more noise to your data, no matter how careful you are.
Privacy-first analytics tools like Matomo take a complementary approach by reducing what gets collected in the first place, through first-party tracking, cookieless options and configurable data retention.
Data minimisation and anonymisation
Data minimisation means collecting only what you strictly need for a specific purpose, and anonymisation means stripping or masking identifiers, so individuals can’t be re-identified.
Under the GDPR, data minimisation is a legal requirement (Article 5(1)(c)). Even if you anonymise data and re-identification is practically impossible, it can still be considered outside the scope of GDPR because identifiers were collected in the first place. And that counts as personal data under GDPR.
Realistically, it’s not possible to achieve true anonymisation with rich behavioural datasets. That’s why businesses need to minimise what they collect. Federated learning does this by design because only model updates are sent to different servers. Tools like Matomo apply the same principle at the analytics layer where they use IP anonymisation by default. And you can take advantage of configurable retention periods and the ability to exclude specific data types from collection entirely.
On-premise and self-hosted analytics
Running analytics on your own infrastructure means data never leaves your controlled environment. You decide where it’s stored, who can access it, how long it’s retained and how it’s processed.
In some regulated industries, on-premise deployment is a requirement. So, businesses have to deploy solutions within their own infrastructure for compliance.
But the difference between self-hosted analytics and federated learning is that they operate at different layers.
Self-hosted analytics and federated learning operate at different layers. Self-hosting controls where data is stored whereas FL controls where computation happens. They aren’t direct alternatives, but for organisations with strict data sovereignty requirements, they address complementary concerns and reinforce each other.
Note: Matomo’s self-hosted analytics product is one such example. You can choose where in the world you store your data, and you get raw data access. Essentially, none of the data leaves your servers with the right setup, which helps businesses stay compliant with GDPR and similar regulations.
The techniques we’ve discussed in this section work best in combination with each other. And while federated learning is still maturing, the principles it’s built on like local data storage and minimal transfer are already reflected in how some analytics platforms approach privacy today.
Where federated learning and Matomo share principles
Even though Matomo doesn’t use FL, we still protect user data in several ways:
- Minimising unnecessary data exposure: FL keeps raw data on the device to minimise data exposure. Matomo provides IP anonymisation, configurable data retention periods and the ability to exclude specific data types from collection entirely. It uses different mechanisms but the goal is the same: to collect and use only the necessary data.
- Reducing reliance on third-party tracking: In a federated system, raw data never travels to a central third-party server. Matomo operates as a first-party analytics platform, meaning your data is yours and not shared with or sold to third parties.
- Keeping compliance in mind: FL is driven by privacy laws such as GDPR, HIPAA and CCPA. Matomo can be configured to comply with all of these regulations and more.
- Ensuring data sovereignty: FL keeps data within its local jurisdiction. Matomo offers self-hosting through Matomo On-Premise (for free) and EU-hosting through Matomo Cloud. Your data stays under your direct control in the jurisdiction you choose.
- Focusing on transparency and trust: Because FL models use a decentralised data approach, you know what sits in your servers and why. Matomo takes a similar approach to transparency by offering an open-source codebase that anyone on your team (like a DPO or an external auditor) can access. They can see how we collect, process and store data.
Embracing federated learning and a privacy-first future
The narrowing gap between what marketers need and what regulations allow isn’t going away anytime soon. Federated learning is one of the most promising responses to that pressure. It shows that advanced models can be trained and marketers can make better decisions without infringing on a user’s privacy.
But at the end of the day, this method is still maturing. It requires complex infrastructure with significant engineering overhead, which is why only larger organisations tend to use it currently.
That said, businesses of all sizes can still build their analytics on the same privacy-first principles as FL, like owning your data and keeping it local.
That’s what Matomo was built for.
It gives businesses full data ownership without data sampling, self-hosting flexibility and support for compliance with GDPR and more. It gives your organisation a foundation for responsible analytics. One that’s already consistent with where privacy-preserving techniques like federated learning are heading.
You don’t need to wait for FL to go mainstream to start making better choices about your data.
Download Matomo On-Premise for free, or start your 21-day free trial of Matomo Cloud today.
Frequently asked questions
What is the difference between ML and federated learning?
Machine learning (ML) is a technology that learns patterns from data to make predictions or decisions. Federated learning is a specific ML method that is privacy-friendly. In traditional ML, you collect data into a central location and train your model there. In federated learning, the model travels to where the data already resides and trains locally.
What is a real-life example of federated learning?
Google’s Gboard keyboard is one of the earliest and most widely cited examples of FL. Google wanted to improve Gboard’s predictive text by learning from how millions of users typed without seeing what anyone actually typed. With FL, each phone trained a small model locally on the user’s typing patterns, and the model updates were sent back to Google’s servers to improve text prediction.
What are the three types of federated learning?
Federated learning is generally split into three types based on how the data is distributed across participants:
- Horizontal federated learning: Each participant has the same type of data (same features), but for different users. For example, localised versions of a single website collect analytics for different regions. The model learns across both sets of users without sharing the analytics data.
- Vertical federated learning: Each participant holds different types of data (different features) for the same users. For instance, a SaaS company’s website and subsequent product share overlapping users. The website has intent data, but the product has usage data. Vertical FL lets them build a richer model together without either party revealing its data.
- Federated transfer learning: Used when participants have little overlap in both users and features. The model trained in one domain is adapted to another using federated methods that bridge the gap without exposing datasets. This is the least common of the three and is still largely in the research stage.
