Originally reported by TechRepublic. Source: techrepublic.com
What the Integration Does
Feature delivery platform Split Software announced a two-way integration with Google Analytics designed to eliminate a common data silo in software engineering: the gap between website analytics and code performance data. By connecting the two systems, DevOps and engineering teams can see how a new feature actually affects key business metrics — such as page load time, session completion, and conversion rates — without switching between tools.
Dave Karow, Split’s continuous development evangelist at the time of the announcement, described the integration as providing bidirectional data flow: teams can pull performance, conversion, and business data from Google Analytics into Split, and push feature flag exposure data from Split into Google Analytics.
“This tracking makes it easier to watch the metrics that your organization cares about.”
— Dave Karow, Split Software
The Problem It Solves: Two Separate Data Silos
Before this integration, teams typically had to correlate feature releases manually with Google Analytics reports — a slow, error-prone process. A performance regression introduced by a new feature might not become visible in aggregate analytics until the feature had already reached a large portion of users. Karow noted that in practice, it can be difficult to catch a problem before a feature reaches at least 50% of users.
“It sounds bad to hear that one in five users would get an error, but if you’re rolling this out to only 5% of your users, it is OK.”
— Dave Karow, Split Software
The integration addresses this by making feature exposure data available inside Google Analytics for segmentation, so teams can isolate exactly which user segments were exposed to a new feature and what happened to their session metrics as a result.
Key Capabilities of the Integration
- Ingest from Google Analytics into Split: Pull web performance, conversion, and business data from Google Analytics to measure the impact of new features within Split’s statistical analysis engine.
- Revenue-based outcome measurement: Use metrics such as average revenue per cart to determine whether a new feature improves business results.
- Export feature flag impressions to Google Analytics: Send a record of every Split feature flag exposure (called an impression) to Google Analytics, enabling segmentation analysis by feature variant.
- Segment Google Analytics data by feature exposure: Analyze session data or goal completions segmented by which version of a feature a user saw.
- Instant feature kill switch: Immediately disable any feature in Split that causes a measurable degradation in performance indicators tracked by Google Analytics — without requiring a new deployment.
How the Integration Works Technically
Split tracks code performance through a JavaScript SDK that customers embed in their web applications. When a feature flag is evaluated, Split records an impression that includes a timestamp, the affected users, the feature in question, and the targeting rule that was applied. This creates a full audit trail tied directly to user experience data.
Customers access this capability through the Split Tracker plug-in, which provides the code to include in applications as well as documentation covering configuration and usage. The plug-in handles the data exchange between Split’s platform and Google Analytics without requiring a separate deployment cycle each time teams need to adjust feature rollout percentages.
“Teams are literally able to change this via remote control.”
— Dave Karow, Split Software
Progressive Delivery: The Underlying Philosophy
This integration sits within Split’s broader engineering philosophy of progressive delivery — an evolution of continuous delivery suited for teams already practicing agile, Scrum, or DevOps. Progressive delivery extends the CI/CD model by adding controlled rollout mechanisms, real-time observability, and statistical validation of feature impact before a full release.
Core practices in progressive delivery include:
- Canary deployments: Releasing a new feature to a small percentage of users first.
- A/B testing: Comparing two or more variants of a feature to measure their relative impact.
- Feature flags: Decoupling feature release from code deployment, allowing teams to enable or disable features independently of a deploy.
- Observability: Continuously monitoring real user impact during a staged rollout.
A structured ownership model accompanies each feature through its lifecycle: the development team owns the feature at initial release and is responsible for fixing early bugs; the project manager takes ownership once the feature reaches production; and a business team assumes responsibility when the feature is available to all users.
Why This Matters for DevOps Teams
The practical value of this integration is that it gives engineering teams credible, production-based evidence to support technical decisions in conversations with business stakeholders. When a new feature shows a measurable drop in conversion rate or an increase in page load time — even at 5% rollout — teams have the data to justify pausing the rollout and investing time in performance fixes before the feature reaches all users.
“Some things you just don’t know until you’re in production, like users doing things you don’t expect. This allows development teams to confirm the impact of new initiatives with statistical rigor before declaring ‘done’ and moving on.”
— Dave Karow, Split Software
By merging Google Analytics behavioral data with Split’s feature flag impression data, teams can move from gut-feel release decisions to statistically validated ones — reducing deployment risk and accelerating the feedback loop between shipping code and understanding its real-world impact.