Embrace, Don’t Replace - The Benefits of Integrating Feature Flag Data with Existing Analytics Solutions

Written by: Elliott Landon
7 min read

If you do your research, you will notice that many feature flag management tools provide “out-of-the-box” insights into how end users react to new components of a feature. This approach might be initially appealing—after all, you could argue that a feature flag management and analytics “all-in-one” approach might seem more convenient.

The convenience can be short-lived, however, as growing companies are often seen relying on a more customizable data forwarding pattern, often involving more than one analytics platform (such as Google Analytics for marketing, Datadog for monitoring and so on). In other words, if you already perform user analytics or if you’re poised to scale as a company in the next few years, chaining your user analytics capabilities to your feature flagging system can be seen as paying a premium for short-term convenience instead of investing in long-term functionality and flexibility.

At CloudBees, we have a philosophy called “embrace don’t replace.” In most large enterprises, the reality is that you can’t simply rip out a tool and replace it. Tools that have been in use for a while are probably in place for a good reason. The stakes are high, and security and compliance are major concerns. Multiple teams—such as product, marketing and engineering—are using the same analytics tools. These companies still need to innovate and deliver software faster and faster, but it’s difficult to evolve if you want to replace deeply integrated tools that have multiple purposes and stakeholders. 

Rather than insisting on migrating to new tools to manage these challenges, we want to empower developers and DevOps engineers to choose their own tools. Everything we do at CloudBees stems from the “embrace don’t replace” philosophy, including our approach to feature flags and analytics.

A/B Testing and Feature Flags

Many tools start with an all-in-one approach to analytics. From a product management perspective or for smaller companies, it may make sense—it’s one less tool that you need to keep open in a separate tab, and user analytics add important insights when using feature flags. Feature flags allow you to experiment, and of course, it’s valuable to perform A/B testing on the user experience side as well as the technical performance side. Monitoring both sides together in a single tab is a popular solution among startups and other companies that are looking to spin up a feature flagging system quickly.

However, large enterprise companies don’t tend to use all-in-one tools for their analytics. They will most likely rely on their favorite best-in-class analytics platform, and will have existing processes and a whole team already in place to manage user analytics. There is no reason to pay for some users to monitor features within their feature flag management tool while continuing to maintain a license to their other analytics tools—especially when the other tools are the standard across your company. Siloing data and double-paying for analytics isn’t a good solution for the long term.

Imagine that you’re a small startup that’s just beginning to scale your development processes and use feature flags. You hope to build more momentum in the marketplace and eventually get acquired by a larger enterprise. If you choose to rely on an all-in-one approach, you’ll get user analytics capabilities now, but you’ll probably have to transition to something more sophisticated like Google Analytics or Snowflake during the acquisition. The costs will be much lower if you’re already using a tool that integrates with them, like CloudBees Feature Management.

Basically, “embrace don’t replace” is an argument for finding the highest quality tool for each task. Given the engineering power needed to build a best-in-class tool, it’s unlikely that any all-in-one feature management and experimentation tool will ever be able to provide best-in-class analytics. Developers and DevOps engineers need the freedom and flexibility to choose the best tools and technology for each phase of their work.

Specialization: The Advantage of Modular Tools

Bear with me for a quick detour into the world of economics. “Embrace don’t replace” has a lot in common with the theory of economic specialization. In this theory, a country (or company) focuses on breaking down larger, more complex tasks into smaller ones, allowing workers to specialize and become world-class experts within a narrow field. Adam Smith, the originator of the theory, said that specialization (the division of labor) leads to increased productivity. Few countries, or companies, have the resources to be the best at everything. Instead, we specialize and then trade with one another.

It’s easy to take this idea and see how it might translate to software. Different tools have different strengths, and given the right amount of flexibility, a company can hand-select a range of extremely specialized tools that are best-in-class within their limited scope and integrate them with each other, rather than relying on a single tool that does a few things well and others not so well. 

Specialization is key to practicing DevOps successfully in the enterprise. Unlike small startups, enterprises must consistently deliver mission-critical, revenue-generating applications across legacy, traditional and modern environments. It’s much more difficult and costly to transition tools. “Embrace don’t replace” allows developers and DevOps engineers to choose the tools and technology they need for innovation, while ensuring security and compliance. 

Engineering and product teams use tools like CloudBees Feature Management for fine-grained control and measurement of feature releases. They integrate with other best-in-class data tools for user analytics, and you get the best of both worlds.

No Analytics = No Touching of Customer Data

“Embrace don’t replace” also affects our approach to customers’ end-user data. We deliberately don’t track any kind of personally identifiable information (PII); in fact, our architecture makes it impossible for us to do so. We built the CloudBees Feature Management architecture around privacy, with the flags’ configuration only being read on the end-user’s SDK (mobile app, web app or a backend system)—meaning that it compares the ruleset with locally available attributes.

This process centers on our impression handler. The rules for each feature flag are configured on our servers and shipped to each end device, which then decides for itself whether it meets the specific criteria. The impression handler acts as an event listener—it is essentially an empty function that is called whenever a flag is evaluated. It is a flexible, customizable function that gives autonomy back to product and development teams. This allows them to decide how to push data and where to push that data, all of which can be modified with each unique use case. Inside the impression handler, your team can call Google Analytics or any other analytics tool or data lake, because all that is required is the data platform’s API or SDK, thus allowing tailored integrations for each company’s usage. In the future, if you need to switch from Google Analytics to Segment, for example, you can just delete the code pointing to Google Analytics and direct it to your new tool.

You can learn the specifics about how the impression handler works across the different SDKs in our documentation. Customer data never makes its way back to our servers, which helps us more easily comply with enterprise security requirements. CloudBees Feature Management is SOC2 Type II compliant and fully compliant with GDPR regulations at the application level.

Parting Thoughts

The CloudBees “embrace don’t replace” philosophy led us to build a feature flag management tool that focuses on developers and software delivery. This approach opens the door for custom integrations, enabling enterprise scale and ensuring that PII data never leaves end users. Teams get the flexibility to integrate with any and all analytics or monitoring platforms they need. 

To practice DevOps in the enterprise most effectively, you need to embrace choice across teams, tools and technology. For greater long-term flexibility, it makes sense to manage your feature flags and your analytics tools independently.


If you’d like to learn more about CloudBees Feature Management, contact us for a free demo.

Stay up to date

We'll never share your email address and you can opt out at any time, we promise.