Stats Aggregation

Most affiliate trackers slow down as your data grows. The reports that opened instantly when you were running 100k clicks a month start taking 30 seconds at 10 million, then 2 minutes, then time out entirely. The cause is almost always the same: the platform is running queries against the raw event log every time a report is opened, and at scale the raw event log is too big for that to be fast.

Routy speeds up rather than slowing down. In the background, Routy continuously pre-aggregates your stats — clicks, conversions, revenue — into rollup fact tables that the reports query instead. The rollup tables are designed for the kind of aggregation reports actually need, which means a query that would scan billions of raw events in a traditional setup scans thousands of rollup rows in Routy and returns in a few hundred milliseconds.

You never configure the aggregation, you never schedule the rollup jobs, and you never maintain the materialised views. It just works in the background, and your reports stay fast regardless of how much data the account has accumulated.

The aggregation system is invisible by design — you'll notice it in how the reports behave, not in any configuration surface:

• Continuous rollup of clicks, conversions, and revenue into pre-aggregated fact tables. The rollup happens every 30 seconds in the background, so the lag between an event firing and being reportable in aggregated form is under a minute in typical operation.
• Fast dashboards at any volume. Reports query the rollups rather than the raw event tables. The dashboard you opened on day one stays the same speed on day three hundred, when your account has 100× more data behind it.
• Automatic daily reconciliation that catches anything the live merge missed and keeps the recent window exactly in sync with the source of truth. The reconciliation runs every night over the recent window (typically the last 7 days) and corrects any discrepancies between the rollups and the raw events.
• Invisible engineering. There's no rollup job to schedule, no materialised view to refresh, no aggregation policy to configure. The system handles it.

The honest framing is that this is infrastructure rather than a feature. You won't open a "stats aggregation" page in the dashboard. You'll notice that reports open fast, that the live view updates within seconds, and that the dashboards don't time out as your account grows — and those are all stats aggregation doing its job.

Routy ingests every event (click, conversion, page view) into a raw event log first. From there, a background process merges new events into rollup fact tables on a 30-second cadence. The rollups are dimensional — they pre-compute the cross-tabulations that reports actually use — so a report asking for "conversions by traffic source by day for the last 30 days" reads from a rollup that has exactly those dimensions already aggregated.

A few details worth knowing:

• The 30-second cadence is the typical case. Under very heavy load the cadence may slow slightly, but it always recovers within minutes and the reconciliation pass catches any lag.
• The reconciliation pass runs nightly over the recent window. It compares the rollups against the raw event log for that window and corrects any discrepancies. Discrepancies are rare in normal operation but the reconciliation provides a safety net against any edge case the live merge could miss.
• Historical data beyond the rollup window stays in the raw event log and remains queryable, though reports against very old data fall back to scanning the raw log and are slower. The retention windows for both rollups and raw logs are configurable per plan.
• The dimensions covered by the rollups include date, hour-of-day, traffic source, link, affiliate, country, device class, and a few others. Reports asking for cross-tabulations within these dimensions are fast. Reports asking for cross-tabulations involving dimensions not in the rollup (rare in practice) fall back to scanning the raw log.

The "why" for stats aggregation isn't really a separate question — it's the reason every other reporting feature in Routy works at scale. Real-time analytics, the report builder, the BI dashboards, the data export — all of those would slow down to unusable on a high-volume account without the rollups underneath. The aggregation is the infrastructure layer that lets the rest of the reporting stack stay fast.

The competitive framing matters too. Most affiliate trackers built on top of MySQL or a similar OLTP database hit a wall at somewhere between 10M and 100M events a month, after which reports start timing out and the standard advice is "wait for the nightly batch." Routy's design — purpose-built for affiliate event volumes, with rollups as a first-class concept rather than an afterthought — is what makes the same reporting experience work for a small account doing 10k events a day and a large operation doing 10k events a second.

For accounts considering migration to or from another platform, this is one of the load-bearing reasons reporting feels different in Routy. The same numbers come back, but they come back faster, and they keep coming back faster as the account grows.