Real-Time Analytics

Routy keeps four per-event lists: clicks, conversions, page views and impressions. A row is one event, not a total, and on the conversions list each row carries the click that produced it, so a single deposit reads back to the link, account, traffic source, tracker and sub-ids behind it without a second lookup.

These are the lists you sit in front of during a launch or a debug session. A campaign went live ten minutes ago and you want to see the first clicks land. A postback is being tested and you need to know whether the conversion came back and which click it attached to. A new traffic source is sending its first visitors and you want to check the click id is arriving. The clicks, page views and impressions lists open on the last six hours and the conversions list on the last seven days, because that is the window those questions live in. Monthly totals are the aggregated reports' job, not this one.

• A clicks list where each row carries the IP and country, the brand, link, account, traffic source and affiliate tracker, parameter A and B, the external click id, the dynamic parameter, device, browser, operating system, the referrer and the full query string the click arrived with.
• A conversions list where each row carries the conversion type, value and currency, whether it arrived as a postback or from an account integration, and the same click fields as above.
• Filters you can stack: account, brand, software, link, traffic source, tracker, device, operating system, country, conversion type, conversion source, click id, dynamic parameter and free text. On the clicks list, offer, partner and network filters cover traffic that came through one of your sub-affiliate networks; those three columns are empty on clicks that didn't.
• Scrolling that stays the same speed at the bottom of a long list as at the top. The conversions and page-view lists page by keyset cursor rather than by counting rows, so the thousandth page costs what the first one did.
• Sorting on more than one column at once. sortBy takes a comma-separated list and each field carries its own direction, so -conversionDate,+value is newest first, then smallest value first.
• Test traffic in the list and out of your figures. A click with ?test=true on it is recorded and flagged as a test, and it doesn't land in your production metrics.
• The same four lists over the API: GET /v1/reports/events/clicks, /conversions, /impressions and /page-views, up to 200 rows a request.

Two limits worth knowing before you plan around these lists. They hold the last three months of clicks and page views, and a request with a from date older than that is refused; anything further back comes from an export or the click archive. And the impression pixel runs no geolocation and no device detection, so country, city, device, browser and operating system are empty on every impression row, and the country filter on that list matches nothing.

Reading a list

Open Events and pick Clicks, Conversions, Page views or Impressions. The list loads the default window, you narrow it with the filters, and the refresh button reloads it. There is no push connection, so a list shows what was recorded when you loaded it and the newest events appear on the next load.

A click is published to the queue as the redirect happens rather than written on the redirect path, which is what keeps the redirect fast. In practice that means a visitor can already be on the advertiser's page when the click reaches the list.

Paging

The conversions and page-view lists page by keyset cursor. The response carries a nextCursor holding the last row's date and id, you send those back as cursorDate and cursorId, and the next page comes from an index seek instead of a count of skipped rows. That is the default when you don't pass a sort.

Passing sortBy switches the list to offset paging, where offset is capped at 1000. A page is 100 rows by default and 200 at most. A bad sortBy field, a negative offset or a date range that ends before it starts comes back as a 400 with a message, so a mistyped sort tells you what it didn't recognise.

What the lists don't do

They don't aggregate. There is no total by day, no grouping and no chart here, because a row is an event. For sums, rates and anything you'd put in front of a client, use the report builder or the BI dashboards.

A total tells you 412 clicks arrived. It doesn't tell you whether the click id came through, which link the fourth one hit, or whether the conversion that fired two minutes ago attached to the right click. Those are the questions that come up in the first fifteen minutes of a launch and all the way through an integration test, and the only answer is the individual event with its fields visible.

The conversion-plus-click row is the part that saves the most time. When a partner's figures and yours disagree, the argument is usually about one conversion: which click it was credited to, what country that click came from, what sub-id it carried. Having both halves on one row means you can answer that from the screen rather than by exporting two reports and joining them in a spreadsheet.

For everyday reporting these lists are the wrong tool, and deliberately so. They hold three months, they don't aggregate, and they open on a six-hour window.