The Problem We Were Solving
Music labels spend significant budgets on digital advertising — Spotify Canvas ads, YouTube pre-rolls, social campaigns. But the analytics they had access to stopped at the click. Did those listeners actually stream the track? Did they follow the artist? Did the campaign drive real engagement, or just impressions?
BGF Plugin was built to answer those questions. It's a SaaS platform that sits between the ad platform and the streaming service, capturing listener behavior data in real time and surfacing it in a dashboard that actually makes sense to a marketing team.
Key insight: The music industry had mature ad tools but almost no attribution layer between ad spend and streaming outcomes. That gap was the product.
Architecture Decisions
We made a few early calls that shaped the entire build. The first was data collection strategy: rather than polling streaming APIs, we built an event-ingestion pipeline that processes listener events as they happen. This meant we needed a stack that could handle bursty, high-volume write loads without breaking the bank on infrastructure.
Why ClickHouse over PostgreSQL
For the analytics layer we chose ClickHouse over PostgreSQL. The query patterns for this type of product are almost entirely analytical — aggregations over time windows, campaign comparisons, funnel analysis. PostgreSQL would have worked, but ClickHouse gave us order-of-magnitude better query performance on large datasets and made real-time dashboards genuinely fast.
-- Example: listeners per campaign over last 7 days
SELECT
campaign_id,
toDate(event_time) AS day,
uniq(listener_id) AS unique_listeners,
count() AS total_events
FROM listener_events
WHERE event_time >= now() - INTERVAL 7 DAY
GROUP BY campaign_id, day
ORDER BY day DESC
What We Shipped
The final product includes a real-time campaign dashboard, listener funnel analytics, artist follow-through tracking, a label-level overview with multi-campaign comparison, and a white-label export layer for agency clients.
Lessons From the Build
A few things we'd do the same way again, and a few we'd change.
- Start with the data model. The shape of your events table is the most important architectural decision in an analytics product. We spent two weeks on it before writing any application code. Worth it.
- Multi-tenancy from day one. We used row-level security in PostgreSQL for the application layer and tenant partitioning in ClickHouse. Retrofitting this would have been painful.
- Don't over-engineer the frontend early. The first dashboard was built with server-rendered charts. We only moved to a real-time WebSocket layer in v2, once we understood the actual usage patterns.
BGF Plugin is live in production. You can explore it at bgfplugin.ru. If you're building something similar — or something completely different — we'd love to hear about it.