Analytics vs Adblockers

Analytics vs Adblockers

Earlier last year we were tasked with a seemingly simple request: migrate a client’s analytics from Google Analytics to Matomo. What was initially seen as a simple migration ended up becoming a long and arduous couple months of debugging, re-evaluating client expectations and learning a new system.

Why Matomo

It all started when our client realized they needed more control over their data. They had privacy concerns over having their customer data living elsewhere (with google). We set them up with Matomo’s frontend tracking, and doing our best to mimic the functionality found in Google Analytics. But as the first reports rolled in, it became clear something was off. Data wasn’t adding up and there was a disparity in revenue between Matomo and our system. And that’s when we discovered the culprit: adblockers

Matomo and Cookies

At the root of the problem were cookies, identifiers that Matomo uses to track users. They’re essential for connecting actions like “add to cart” or “purchase” back to a single user. But adblockers, in their pursuit of privacy, weren’t having it. Not only did they block the cookies, but they also stopped Matomo’s requests from ever reaching the server. The result was entire user sessions vanishing into thin air.

The plan became to retreat into the security of our backend.

Backend Tracking?

Once we landed on backend tracking, felt like the solution we needed from the start. Instead of relying on the browser to send data, we would quietly handle everything on the server. For actions like cart updates and purchases—anything revenue-related—it was the perfect solution as it completely bypassed adblockers.

There was a small but unignorable catch. Backend tracking couldn’t capture frontend events like page views. But we decided to live with it. Page views didn’t matter as much as knowing where the dollars were flowing (or leaking).

screenshot of matomo dashboard

The Beauty of Open Source

Here’s where things got tricky. Matomo under the hood has a a bunch of rules and flows for how they identify users like, Cookies, visitor IDs, IP addresses, geolocation. On the frontend, Matomo happily handled all that for us. But moving things to the backend? Now it was our responsibility to handle, and this information isn’t exactly documented.

The problem faced would go something like this:

A repeat customer adds something to their cart, we pass that onto the backend which in turn passes that to Matomo. Matomo then looks for identifying details and if one of those click into place, it will assign the session to that user using that piece of info. If the data it received did not line up with what was used to identify that user in the past, then it would misattribute the session and that user would have their history lost.

To make the systems play nice, we had to dig deep into Matomo’s inner workings. We had to learn its secrets, ensuring every frontend and backend request aligned perfectly. It was just like playing broken telephone, except it was our job to make sure that everyone spoke loud and clear with each other.

Fortunately one of the reasons we picked Matomo is because it was Open Source which is the only reason that this didn’t become a complete blocker. If we had gone with a closed source, third party solution, we would not have been able to get the information we needed as they would have fought tooth and nail to keep their logic under wraps.

image of people playing broken telephone

Speed or Reliability? Why not both.

Now, we had a system. But there was another challenge: speed. Backend tracking is only useful if it doesn’t slow down critical actions like checking out. Every millisecond counts in e-commerce. Slowdowns can make impatient shoppers abandon their carts, costing thousands in lost revenue.

To solve this, we leveraged the use of backend workers in our Redis queue.

Here’s how it worked: whenever a critical event (like a cart update or purchase) occurred, the backend handed it off to a worker. The worker quietly processed the data and sent it to Matomo while the shopper happily continued on their way. The result? Zero noticeable delay for the user and minimal strain on our backend.

image of laravel queue

Is it finally over?

After months of fine-tuning, testing and lots of learning about how Matomo ticked, the new analytics system was live. Backend tracking handled the mission-critical data, leading to the goal of 100% of revenue getting captured. Frontend tracking captured everything else for the majority of users (94%, to be exact). Both systems played nice with each other and the user’s didn’t notice a thing.

In the end, we built a system that was faster, more robust, and truly future-proof. In a world where adblockers are becoming more commonplace, we’ve managed to cement our client in their niche with a truly impenetrable analytics system that will provide invaluable data for years to come.

Contact Us

We are customer obsessed!
Our team is ready to take care of every need.


“The Idextrus team delivered us a product that was within budget, on time and exceeded our performance expectations. We now feel that we are set for the next chapter of our business growth and were very pleased with the professionalism, diligence and creativity of the Idextrus team.”

Tim Harris, Founder & CEO

La Tienda Logo

“The Idextrus team delivered us a product that was within budget, on time and exceeded our performance expectations. We now feel that we are set for the next chapter of our business growth and were very pleased with the professionalism, diligence and creativity of the Idextrus team.”

Tim Harris, Founder & CEO

Grayed out Tienda logo