Custom Analytics and Reporting Dashboard Development
We had a project: an e-commerce platform with 50 million order rows. Management wanted "one screen showing all KPIs." Queries against PostgreSQL were taking 20 seconds and bringing the database to its knees. After migrating to ClickHouse with materialized views, the dashboard loaded in 1.2 seconds. We've been tackling such tasks for over five years and know how to avoid common pitfalls.
An analytics dashboard is an interface for visualizing business metrics in real time. Developing one requires integrating multiple sources and fast aggregation. Key requirements: load speed, flexible filtering, and correct aggregation. Users shouldn't wait 30 seconds for a page to open. Below are the typical bottlenecks and our solutions.
Why analytics dashboards are slow
The main cause is heavy queries against an OLTP database. For example, SELECT * FROM orders JOIN users ... without indexes. Result: timeout or load average 200. We solve this with three approaches: materialized views, a separate analytical database, and Redis caching.
ClickHouse is a columnar DBMS for real-time analytical data processing (ClickHouse Documentation).
Materialized views
CREATE MATERIALIZED VIEW daily_revenue AS
SELECT
DATE_TRUNC('day', created_at) AS date,
SUM(amount) AS revenue,
COUNT(*) AS orders
FROM orders
WHERE status = 'completed'
GROUP BY 1;
CREATE UNIQUE INDEX ON daily_revenue (date);
-- Refresh on schedule
REFRESH MATERIALIZED VIEW CONCURRENTLY daily_revenue;
Separate analytical DB: replicate from OLTP into ClickHouse or a read-replica PostgreSQL. All heavy queries go there.
Redis cache: results of expensive queries are cached with a TTL of 5–60 minutes. On data update, the cache is invalidated. This architecture reduces production load by a factor of 10.
How Redis caching works
We set TTL per query based on data update frequency. For critical metrics, 5 minutes; for long-lived ones, 60 minutes. When data changes in the source, a cache invalidation signal is sent via pub/sub.
How to choose a visualization library
The choice depends on chart complexity. For the React stack, we use Recharts—well documented, customizable via props. For heatmaps or treemaps, we use Apache ECharts (more powerful but heavier). For rapid prototyping, Tremor fits—ready-made components with Tailwind. In our tests, ECharts renders 10,000 points in 200 ms, Recharts in 150 ms on the same dataset. Tremor lags in performance with large volumes (over 5,000 points). Typical widgets:
| Widget |
Purpose |
Example |
| KPI card |
Single number with trend |
Revenue yesterday vs week |
| Line/Area chart |
Time trends |
DAU over a month |
| Bar chart |
Category comparison |
Sales by region |
| Funnel |
Conversion funnel |
Visits → Cart → Purchase |
| Table |
Paginated details |
Order list for a period |
How to set up ETL for the dashboard
The ETL process includes several steps, each affecting speed and data accuracy:
- Identify data sources. We list all necessary tables, APIs, and files (CSV, Excel).
- Set up replication. Use Debezium or pglogical for continuous sync from OLTP to the analytical DB.
- Build materialized views. Aggregate data by time hierarchies (day, week, month).
- Configure caching. Save results of slow queries in Redis with TTL 5–15 minutes.
- Monitor and alert. Track replication lag and resource consumption.
Comparison of ClickHouse and PostgreSQL for analytical workloads:
| Characteristic |
ClickHouse |
PostgreSQL |
| Aggregation speed (GROUP BY) on 10M rows |
0.2 sec |
8 sec |
| Data compression |
5-10x |
2-3x |
| Materialized view support |
Yes (CONCURRENTLY) |
Yes (REFRESH) |
| Indexing for analytics |
Partitioning + primary key |
B-tree, indexes |
ClickHouse is on average 40x faster on analytical queries, as confirmed by our projects handling up to 1000 requests per minute.
What's included in the work
We deliver not just code, but a fully documented solution:
- Architecture diagram with data sources and ETL processes
- Dashboard source code (React/Next.js or Vue/Nuxt) with comments
- Docker configuration for local development and deployment
- Access to repository and CI/CD pipeline
- Client team training (2–3 workshops)
- 6 months warranty support
Our experience: over 10 dashboard projects for retail, fintech, and logistics. We guarantee stable performance under loads up to 1000 requests per minute.
Filters and drill-down
Global filters (period, region, category) must apply to all widgets simultaneously. Drill-down: click a data point on a chart → detailed table for that slice.
The URL should reflect filter state (?period=last30d®ion=Moscow) for saving and sharing a specific dashboard view.
Export and sharing
- Export to Excel/CSV – table data download
- Export to PDF – dashboard snapshot (puppeteer or print CSS) – generation takes 5 seconds for 50 widgets
- Scheduled reports – automatic email delivery on a schedule
- Public URL – read-only dashboard access via link (no login)
Timelines
MVP (5–10 widgets, global filters, main data sources): 6–8 weeks. Full-featured dashboard with widget builder, drill-down, export, and scheduled reports: 3–4 months.
If you need a dashboard that won't break under load and will be understandable to management, contact us. We'll evaluate your project in 2 days and provide a realistic plan and cost. Request a preliminary consultation to determine the optimal architecture.
Setup Web Analytics: GA4, GTM, Yandex.Metrica, and Amplitude
We often see: conversion rate 1.2%, traffic grows, but conversion stays flat. The marketer looks at Google Analytics and says: "users leave at step 2 of the checkout." The developer opens the same step — no errors, Sentry is silent. So it's not a JS bug, but a UX issue or skewed data from analytics. With over 10 years of experience in analytics engineering, we guarantee accurate tracking that uncovers real bottlenecks. Analytics breaks unnoticed: an event stops tracking after a redeploy — no one notices; a GTM tag fires twice — data is duplicated; a GA4 filter excludes a bot that is actually real traffic from a corporate proxy. An audit of your current tags will find the cause within a week.
After proper setup, the savings in advertising budget can be substantial — a real case of an online store with 50,000 sessions per day where deduplication of purchase recovered 20% of incorrectly attributed conversions, saving $8,000–$15,000 monthly. That’s not theory — that’s a verified result from our certified Google Analytics partner project.
Why do GA4 events duplicate and how to fix it?
Universal Analytics is gone, replaced by GA4's event-based model. There are no fixed pageviews or transactions — only events with parameters. This is more flexible but requires proper event design. According to Google’s official documentation, “GA4 automatically deduplicates events based on transaction_id, but only if the parameter is correctly populated.” Many implementations miss this.
Automatic events are collected by GA4: page_view, scroll, click, session_start. Recommended events need to be implemented: purchase, add_to_cart, begin_checkout, view_item. Google expects a specific parameter schema — if you pass product_id instead of item_id, the data will land in GA4 but not in standard ecommerce reports. Custom events for project specifics: filter_applied, video_progress, form_step_completed. Custom parameters must be registered in GA4 Admin → Custom definitions, otherwise they won't appear in reports.
A common mistake is the purchase event being duplicated. Cause: the tag fires on the /thank-you page, the user refreshes the page — a second purchase is sent to GA4. Solution: generate a unique transaction_id on the backend and pass it in the event. In our experience, 80% of e-commerce stores have this issue. GA4 deduplicates based on it (in theory — verify with DebugView). Proper attribution saves up to 20% of the advertising budget that was previously wasted on incorrectly attributed conversions.
How to set up the data layer to avoid data loss?
GTM is a tool for managing tags without code deployment. But "no code" doesn't mean "no architecture." The data layer is the foundation. We pass data from the application to GTM via dataLayer.push(). Structure: event + contextual data. For e-commerce: before opening a product page — push with product data. GTM tag reads from the data layer, not from the DOM.
window.dataLayer = window.dataLayer || [];
dataLayer.push({
event: 'view_item',
ecommerce: {
items: [{
item_id: 'SKU-12345',
item_name: 'Product name',
price: 1990.00,
currency: 'USD'
}]
}
});
Bad practice: GTM tag parses the DOM — looks for the price in span.price, the name in h1. This breaks with any layout change. Good practice: always use the data layer. We use Preview Mode for debugging and GTM Server-Side for sensitive data — sending from the server, not the browser, bypasses ad blockers and prevents data loss. A properly implemented data layer reduces tracking errors by 95%.
How does Yandex.Metrica complement web analytics?
For a Russian audience, Metrica is a must — especially Webvisor. Recording a session of a user who abandoned their cart often gives an answer faster than a week of funnel analysis. Goals in Metrica: event-based (via ym(COUNTER_ID, 'reachGoal', 'GOAL_NAME')) or automatic (button click, page visit). Integration with CRM via Metrica Plus — passing offline conversions. Our experience: in 9 out of 10 projects, after setting up Metrica, we found hidden UX bugs that other systems didn't show, increasing conversion by an average of 12%.
What does product analytics give in Amplitude?
Amplitude is a product tool, unlike marketing-oriented GA4 and Metrica. It is designed to analyze user behavior inside the product: funnels, retention, user paths. Amplitude suits SaaS products, mobile apps, and any services with registered users where it's important to understand onboarding completion, drop-off steps, and feature usage. Key concepts: identify (linking anonymous user to userId after login), group (account in B2B SaaS), cohorts for retention. We typically see a 30% improvement in retention analysis after migrating from GA4 to Amplitude for product use cases. Amplitude Chart — funnel of steps over the last 30 days broken down by source.
Monitoring Data Quality
Analytics without monitoring is a black box. We set up:
- GA4 Realtime — check after every deploy that key events are coming in
- Alerting in GA4 — anomaly in the number of
purchase events (sharp drop = something broke)
- GTM Preview in staging before production
- Manual funnel tests once a week — simply go through the buyer journey and verify everything is tracked
What we check after each deploy
- All recommended events present in DebugView
- No duplicates (count
purchase per 100 sessions)
- Data layer structure unchanged after frontend update
What the work includes
| Component |
Description |
| Audit of existing tags |
Check current GTM tags, data layer, duplicates, and errors |
| Event schema design |
Documentation: event list, parameters, triggers |
| GA4 + GTM setup |
Create configuration, tags, custom definitions |
| Yandex.Metrica |
Install counter, create goals, set up Webvisor |
| Amplitude (optional) |
Set up client and server SDK, cohorts |
| QA and monitoring |
Testing in Preview Mode, alerting |
| Training and handover |
Access, instructions for adding new events, console |
Process and timeline
- Audit of existing tags and data (2 days)
- Event schema design (2 days)
- Data layer development and tag setup (3–5 days)
- QA in Preview Mode and staging (2 days)
- Deploy and dashboard setup (1 day)
| Scenario |
Timeline |
| Basic GA4 + GTM setup |
1 week |
| Full e-commerce tracking + Metrica |
2–3 weeks |
| Server-side GTM + Amplitude |
3–5 weeks |
Cost is calculated individually. Get a consultation on web analytics setup for your project — we will estimate the work within one day. Contact us to get started with a free audit of your current tracking.