The Problem - Analytics breaks silently
Website analytics issues do not manifest as some incidents that other kind of bugs do. They slip through the crack silently. You get to know about them only when you are looking at the dashboard and what you see doesn't make sense, and your gut finally says, probably I should check the analytics instrumentation for any implementation issues, let's check the code.
It would have saved a lot of time and avoid making bad business decisions if that was done automatically for every PR that changes the analytics instrumentation code.
Let's get it done in the next 15 mins!
First, make your analytics free from vendor lock-in using RudderStack SDK
Currently you might have one or more analytics SDKs (Google Analytics, Amplitude, Google Ads, etc.) in your website. This slows down your website. And because they are tightly integrated with your app as code, if you want to switch to another vendor, you'll have to import their SDK and make the changes in the code. A long error-prone process.
In the next 5 mins, you'll get rid of all of them without breaking the analytics.
To do that, you need one SDK to rule them all. Provided by event streaming tools such as Segment or its self-hosted alternative RudderStack.
After setting it up, you will be able to collect events from your websites (source) and send it to any analytics/marketing service of your choice (destination).
With that in place, if you ever need to switch to a different analytics service, it will be a quick dashboard settings change, not a code change in your website.
Here’s how to replace all your analytics and marketing tool SDKs with one RudderStack SDK
Step 1: Create your dashboard to control your data sources/destinations settings. This dashboard controls only these settings. The actual customer event data will not flow through this service. You will either self-host the event streaming server to process customer event data i.e. the data plane or use a cloud-hosted data plane to quickly get started. Source code - https://github.com/rudderlabs/rudder-server
Step 2: Replace all your existing analytics SDKs with one RudderStack SDK
tl;dr: add these 5 lines of code in your website
// Step 1: Install the SDK - `npm i @rudderstack/analytics-js`
// Step 2: Initalize the SDK
import { RudderAnalytics } from '@rudderstack/analytics-js';
const rudderAnalytics = new RudderAnalytics();
rudderAnalytics.load(process.env.WRITE_KEY, process.env.DATA_PLANE_URL, {});
// Q: How to generate your WRITE_KEY and DATA_PLANE_URL?
// A: Create a new JavaScript source at https://app.rudderstack.com
export { rudderAnalytics };
// Step 3: Call event tracking methods such as `page`, `track`, `identify`, etc. as needed
rudderAnalytics.page();
// NOTICE: This code works only if you have set up your browser-side code to use `npm` modules. Follow the quickstart guide otherwise - https://www.rudderstack.com/docs/sources/event-streams/sdks/rudderstack-javascript-sdk/quickstart/
You made the change in your website code. Raised a PR, not merged yet.
When you visit your test server link to your website. In your RudderStack source live events dashboard, you should now see the events flowing.

But events are not flowing to your previous destinations yet. So let’s fix that.
Step 3: Add your original analytics/marketing services as destinations in your RudderStack dashboard to restore your old analytics services. These services are supported as the destinations out of the box, others can be supported either via webhook or by building your own custom integration - https://github.com/rudderlabs/rudder-transformer/blob/develop/CONTRIBUTING.md#building-your-first-custom-rudderstack-source-integration
Now, when you visit your test server again, you should be able to see these events in your analytics services as they were flowing earlier. The destination live events will show you everything you need at this point.
With the analytics instrumentation done, half the battle is won.
You are in control now, free from the analytics vendor lock-in
You can merge at this step, but wait!
Before you merge the PR, let’s do something that will ensure that you do not accidentally break your analytics in future.
We will add a GitHub Action to review your PRs for analytics instrumentation and data quality issues.
Second, make your analytics fail-proof using AI-powered GitHub workflow
Let’s use this GitHub action - https://github.com/rudderlabs/rudder-ai-reviewer
With this, you will never break your analytics instrumentation and your data quality issues will never end up in production.
Create .github/workflows/rudder-ai-reviewer.yml in your repo:
name: Rudder AI Reviewer
on:
pull_request:
types: [opened, synchronize]
permissions:
contents: read # Required to checkout the repository
pull-requests: write # Required to post review comments
jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd # v5.0.1
- name: Rudder AI Reviewer
uses: rudderlabs/rudder-ai-reviewer@v1
with:
source-id: ${{ secrets.RUDDERSTACK_SOURCE_ID }}
service-access-token: ${{ secrets.RUDDERSTACK_SERVICE_ACCESS_TOKEN }}
Commit, push, open a PR that touches any instrumentation code. The reviewer runs automatically. The action will detect the RudderStack SDK and the instrumentation changes automatically, review using AI, suggest fixes as inline review comments.
Now, you can go ahead and merge the PR if Rudder AI Reviewer does not give you any warning.
In future, you'll automatically receive reviews on PRs that impacts the analytics instrumentation or data quality.
Go ahead and explore the tools I mentioned here for more details




Top comments (0)