Real Time Reports via the Reporting API

Did you know that since the release on June 20th, you can get data out of the Reporting API with seconds of latency?

This is a case where the Reporting API added functionality before the Adobe Analytics web UI!

So what can we do with that “real time data”? And how does it work?

Use Cases

Let’s see what this real time reporting thing can do: you can pull a metric with up to 3 break down elements. An example would be “pageviews” broken down by “page”, “prop1” and “prop2”. Or maybe “event1” (could be “Searches“) broken down by “eVar1” (maybe “Search Terms”).

While there is no way of getting “Visits” and “Visitors” metrics out of the real time reports, you have access to a lot of other metrics, from the simple “pageviews” and “instances” via all the “eventXX” Success Events all the way to “orders”, “units” and “revenue”!

The possible elements that you can use cover pretty much everything available in Adobe Analytics, including all “propXX” and “eVarYY” custom “variables“.

Use case 1 — the media industry: have a dashboard that shows which articles are gaining, which ones are losing and which ones are the most popular. Put it up on a screen where the editors sit to give them real time data. They will love it!

Use case 2 — retail: put up a dashboard that shows real time orders and revenue, maybe broken down by product category. Merchandising folk might like it as well as marketers.

Use case 3 — travel: make a dashboard that shows live searches. What flights / hotels are people looking for right now?

Use case 4 — marketing: use an extra eVar to capture tracking codes and you can build a dashboard that allows you to watch campaign results in real time. You can pass a filter in the report description! Might put one up next to the email marketer that only shows tracking codes for email campaigns…

How to

First of all, you can read the doc. It is short and to the point, with a nice 3-step approach to getting your first real time report out of the system.

It is short enough, actually, that I think a little bit more information is in order…

So, real time reporting is not like any of the other reports that the Reporting API gives you. Usually, you create a report description, you queue it, then you wait a bit and finally you retrieve the result and do with it whatever it is you do, most likely cache it in a local database.

For real time reporting, you first have to declare the report or reports. There is a method called ReportSuite.GetRealTimeConfiguration that tells you what the real time setup is for a given report suite, and then there’s ReportSuite.SaveRealTimeConfiguration for defining it.

Just to be clear: you have to do that first!

Without a real time configuration there are no real time reports.

But once you have defined the configuration, you can now pull reports to your hearts content. The documentation says you should ideally pull frequently, like every 15 — 30 seconds or so. Yup, that’s pretty frequent.

And the Reporting API reacts very quickly! There is no queueing, you just request the report and get back the data. I would say that for real time reports, you can forego the local caching of results and just display them straight as they come back.

So how do you pull those reports?

Use Report.GetRealTimeReport. You will have to pass a realTimeReportDescription parameter, which can be very simple; just the report suite ID and a metric, like so:

// minimum configuration
{
    "reportDescription": {
        "reportSuiteID": "rsid",
        "metrics": [
            { "id": "revenue" }
        ]
    }
}

There are other parameters that you can set, specifically around the time frame of the data that will be reported, or the type of metric (“gainers”, “losers”, “most popular”), and others. The documentation is pretty verbose here.

As a result, the Reporting API hands you a reportResponse structure that contains the report. This is actually the same structure that you get for all other reports. As I mentioned before, it makes sense to use a debugger to take apart the structure…

So, easy enough to do, lot’s of interesting applications for it… I’d say get coding!

I’d love to see what you do with it!

About

German expat living in Switzerland (formerly UK and France). Consultant and member of the Multi-Solutions Group at Adobe, working with the Digital Marketing Suite. Father of 4 girls.

Tagged with: , , ,
Posted in Automation, Integration, Principles
12 comments on “Real Time Reports via the Reporting API
  1. Jan,

    We knew about and have rolled out Use case 1 across our newsrooms in the UK 🙂 Looking good… Working on referring Tweets to give even more insight to journalists now.

    James

    Like

  2. Jan Exner says:

    Nice one James!

    I was hoping someone would speak up.

    Like

  3. […] features, let’s use the new anomaly detection that was introduced in February 2013. Like real time reporting, it is currently only available in the Reporting API, giving developers a real […]

    Like

  4. […] wo wir gerade bei großen Dashboards sind: Real-Time Reports kann man auch via Reporting API abrufen, d.h. man kann die Daten in selbstgebaute Dashboards einfließen […]

    Like

  5. […] you want to work with real time reports, take a look at […]

    Like

  6. I like this approach Jan! Adobe also offers the ‘real time’ api but it’s only available to Premium Customers but this circumvents that. You mentioned that visits and visitors are not available to the Reporting API’s version of real time reports but I think we can get around that with DTM.

    Using the _satellite.visitorSessionPagesViewed() method we can attempt to determine what page in the session we’re on. If it’s equal to 1 we can send in a success event and count them as a new visit.

    Like

  7. Matt Kopka says:

    Hi Jan, related to real-time is the set up of marketing analytics real time report.

    I’m wanting to view Revenue in the real-time report by the Campaign code that drove it.
    However when I try to configure this in the report I get the below message pop up.

    ========================================
    The following dimensions which you have selected do not “persist” in the Real-Time Reports like they do elsewhere in Adobe Analytics: “Tracking Code”. This means that the metric you have selected must be set on the same hit (server call) as the value for the given dimension in order to be reflected as tied to that value in the Real-Time Reports. If the value occurred on a previous hit earlier in the user’s visit, or in a previous visit, the metric will not be tied to it in these reports only.

    To use this dimension with a metric that may occur later in the visit, such as Revenue, use JavaScript or another means to cause the value to be passed into a Custom Traffic variable on pages or hits where the metric occurs. That Custom Traffic variable can then be used in the Real-Time Report to show the relationship between your selected metric and the desired dimension.
    ===============================================================

    Is there anywhere an example of the necessary set up needed to achieve this end-to-end? Have you an example of the code used to ‘use JavaScript or another means to cause the value to be passed into a Custom Traffic variable on pages or hits where the metric occurs’ and the variables needed as part of this?

    Thanks
    Matt

    Like

    • Jan Exner says:

      Hi Matt,

      You essentially persist the tracking code yourself (in a cookie), and track it again on the thank you page. That sounds like an article I should write…

      Like

  8. Matt says:

    Happy to ‘sponsor’ the post with a glance at your Amazon wish list if it gets it out there quicker ; )

    Like

    • Jan Exner says:

      I’ll do my best, don’t worry about sponsoring.

      The solution needs two parts: a) writing tracking code into cookie when there is one, and b) reading that cookie and tracking it into a prop on your conversion page.

      If you use DTM, you’d make a PLR with a condition that your tracking code Data Element (you have one, right?) must not be empty, then within the rule just use _satellite.setCookie(“rttc”, _satellite.getVar(“tracking code”));

      How do you check for not empty? put .+ into the filed and switch to Regex enabled.

      Then you make a second rule that fires on your conversion page, or amend an existing one. Again, you want a piece of script. All it does is read the cookie (_satellite.readCookie(“rttc”)), put the value into a prop, and then delete the cookie (_satellite.removeCookie(“rttc”)).

      If you do NOT use DTM, you’d do it in the doPlugins() method. Simply add code that writes the cookie if s.campaign has a value (if (s.campaign !== “”)). If you’re on H, you’d use s.c_w() to write the cookie, on AppMeasurement it’d be s.Util.cookieWrite().

      The second thing to add would be for the conversion page. Probably easy to just see whether s.events contains your conversion event (if (s.events.indexOf(“purchase”) >= 0)), then read the cookie (s.c_r() or s.Util.cookieRead()) and stick it into the prop.

      I’ll do a proper post, maybe for the 15th.

      Like

  9. Matt Kopka says:

    LEGEND. Thanks – will let you know I get on. Best, Matt

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 1,398 other followers

%d bloggers like this: