Case 004 · Analytics architecture and implementation
Centralized User Event Pipeline for a SaaS Platform
A self-serve SaaS platform had accumulated analytics tools through separate frontend integrations. The engagement replaced that sprawl with one vendor-independent event pipeline serving product, growth, marketing, and backend systems.
Engagement facts
| Fact | Detail |
|---|---|
| Client | Self-serve SaaS company and online service |
| Counterparts | Engineering, product, growth, and marketing teams |
| Period | March to May 2026 |
| Format | Three months, 120 hours, remote and flexible |
| Stack | TypeScript, RudderStack, Amazon Redshift, event bus, AWS |
| Fee | CAD $28,800, invoiced at CAD $240 per hour |
Destinations integrated
The pipeline connected Google Analytics, Mixpanel, Amplitude, Hotjar, Microsoft Clarity, HubSpot, Intercom, the client’s internal event bus, and Amazon Redshift. It was designed to support further destinations without another frontend integration.
Measured outcome
Page load and bandwidth utilization fell by 70%, while the tracked user cohort returned to 100%. Calls previously lost to ad blockers were counted again through the first-party collection path.
One unified user ID now follows a person across every destination, and analytics vendors can be added, removed, or replaced without changing application code.
How the work ran
- Inventory the tools and define the questions. Every analytics tag was catalogued with its page-weight cost and blocking behaviour. Each team described the questions it needed to answer, allowing requirements rather than vendor preferences to drive the design.
- Choose what to build and what to buy. The collection layer was built in-house to preserve vendor independence. RudderStack was selected for routing because its existing integration catalogue covered the required destinations.
- Implement, cut over, and onboard. The pipeline was put into production and each team was onboarded to the platforms suited to its work, so the new infrastructure arrived with active users and operating practices.
Architecture register
| ID | Layer and result | Classification |
|---|---|---|
| L-01 | Vendor-independent collection. One custom frontend library collects events, page views, and identity attributes behind a single interface. A first-party endpoint reduced the effect of analytics blocking, contributing to 70% lower page load and bandwidth use and restoring the tracked cohort to 100%. | Collection |
| L-02 | Central routing with RudderStack. One stream feeds many destinations. Adding or replacing a vendor became a configuration change rather than a frontend release, while identity resolution moved into one central layer. | Routing |
| L-03 | Client-owned analytics space in Amazon Redshift. The event stream lands in a warehouse where it can be joined with product and billing data without depending on a SaaS vendor’s retention window. | Warehouse |
| L-04 | Internal event bus integration. Backend services consume the same user-behaviour stream as the analytics tools, giving product and operational systems a shared source of truth. | Backend |
| L-05 | Unified user identity. Anonymous-to-known identity is resolved once and carried across session replay, product analytics, CRM, and warehouse queries. | Identity |
What was left with the client
A production tracking library owned by the client, a documented event taxonomy and identity plan, a configured pipeline with a dozen mapped destinations, a Redshift analytics space, an internal event bus integration, and team-specific onboarding on the new platforms.
Client identity is available under NDA. Figures as measured at engagement close.
Explore Blobb’s architecture work or book a call to discuss a similar analytics system.