A single message broke through the clamorous haze of Slack, and booped me on the nose. It read:

“Did you guys see this? Apparently HighTouch is being accused of ripping off Rudderstack. They use Analytics.js, just like us, right?”

Huh. Maybe I should pay attention to this.

Seemingly minutes later, someone posted a link to a response post from the founder of HighTouch, where he explained their usage of the open-source library, Analytics.js for data collection, and their rationale for doing so. In his explanation, he pointed to us (MetaRouter) and Rudderstack, who both use the Analytics.js as well, indicating that the usage of that open-source library is commonplace across the CDI and CDP landscape (which is true).

Huh (again). One of my favorite things about data is its objective, dispassionate form - and yet here before me laid data drama… client-side library drama. What a time to be alive.

So… it seemed to me like a good time to deep dive on MetaRouter’s own usage of the Analytics.js library. Let’s go.

When we first set out to build MetaRouter, we were focused exclusively on building an infrastructure for real-time server-side integration of digital behavioral data across our customers’ entire marketing analytics ad-tech and lake-housing landscape. In order to do that, we spent the vast majority of our time and energy figuring out how to route and transform tens of thousands of events per second to dozens of destinations while upholding real-time SLAs in a customer’s completely private single-tenant environment. This robust setup ensures real-time data activation and seamless data flow, enhancing the overall efficiency of data handling.

Essentially, we wanted to focus on crafting a purpose-built, server-side infrastructure - not re-inventing the wheel with analytics.

But we also knew, for any of this to be possible, we were going to need a way to collect the event data first, particularly for customers who didn’t already have an event tracking ecosystem in place. After some diligence, we decided to use Analytics.js as the default-supported event specification within MetaRouter for a few reasons:

1. We loved the eventing syntax: its clean, pragmatic, and fairly performant - at least by the standards of the internet 5 years ago when we chose it. It was also fairly human readable, and engineers weren’t required to map in data to confusing canonical eVar structures or minified parameter syntax. It was just like, “hey, pass in your sku as ‘sku’ and we’re good”. We liked that.
2. We were big fans of Segment: most of us had been users of Segment in various capacities in past lives, so we were comfortable with it. We knew Segment had built the library well and had a lot of success with it, so we had confidence it would scale for our use-cases as well.
3. It was open source: I feel like I don’t need to say this again, but Analytics.js is open source, licensed under MIT. It was opened up expressly for the purpose of people using it. We always found it amusing that Segment still heavily branded it as a Segment tool, kept all the documentation for it on their domain, and absolutely littered the code-base with explicit references to themselves and their endpoints. But I can’t really blame them - they did the hard work, and of course part of their strategy for open-sourcing it was driving more leads to their business. But in the end, they didn’t have to open-source it, so I am grateful they did.
4. We wanted to be schema agnostic: MetaRouter never wanted to differentiate itself on our analytics libraries, and in fact, we didn’t want to require one at all. Many of our customers bring their own clickstream or analytics ecosystems to the table, and don’t use Analytics.js at all. Its one of the things that makes our platform great for bigger Enterprises who are far enough along on the data maturity curve to want complete autonomy and control over their data structures. As such, we knew that making huge investments in building our own opinionated event schema was going to be counter to our core mission of giving enterprises back TOTAL control over their data. So instead, we provide essentially vanilla Analytics.js as a default option in our platform that can speed up onboarding, but never require it.

‍

Choosing a pre-built, open source library meant we could focus on innovation around and on top of the core analytics framework - like our Identity Enrichment, Anonymous Cross-Domain, and Consent Enforcement tools. Analytics.js was a wonderful foundation to build upon for us, and we’re in Segment’s debt for it, and Google’s before them.

We love open source, and the open source community, and we have always been transparent when and where we use it. And that won’t ever change.

‍