Using Report Builder to learn the Adobe Analytics API using-report-builder-to-learn-the-adobe-analytics-api

Report Builder is something we all know & love. So what if I told you that you could use what you know about Report Builder to advance your Adobe Analytics skillset even further? In this video, we will walk through how to take debug Report Builder requests and use them to learn how to craft your own Analytics API queries.

Transcript
Hi, this is Jen Lasser with Adobe Analytics Product Management. In this video, I’m going to show you how to easily use Report Builder to start learning our analytics API.
So you may or may not know but Report Builder is a friendly UI that interacts with our analytics API on your behalf. By stepping through the Report Builder Wizard, you are crafting an API call that will ask Adobe for data, return it, and parse it into excel. This process translates to a QAPI request, a GET API request, and then finally we do some parsing logic on our side to render the data in Excel as you would expect to see it. So by pulling up a debugger side by side with Report Builder, you can actually see the requests that go out to our API, and find the API logic behind them that was written for you. So, let’s go ahead and try this out.
In Report Builder, we’re gonna go ahead and create a request just by going through the two steps of the wizard.
So I’ll start with a very simple request. I’ll pick a pages report for yesterday.
Aggregated is fine. We’ll skip segments for now. We’ll go next. And then I’ll just select visits here.
I’ll select a cell to import the data to.
And then before I click finish, I’m gonna pull up a debugger.
So I’ll just do a split screen here so you can see both.
In the debugger you’re gonna be able to see a bunch of requests that are going out. But we wanna focus in on just the requests related to the API calls that Report Builder is making. So I’m using Charles here as my debugger. You can really use any third party debugger that you’d like.
And we’re just gonna filter the debugger down to any calls that say report dot.
So back in report builder here, I’m gonna click finish. And as that runs we should see two calls go out, Report.Queue and then when the data is ready to be returned to Report Builder and parsed, we’ll see a Report.Get Request.
And then the data you see renders in Report Builder. So within the queue request on the Request tab, this is where you’re gonna find the API logic that was written for you. Now, it reads left to right which is a little hard to see so you can just hit Ctrl+C or copy and paste it over to the notepad and hit Ctrl+V.
From the notepad it’ll format it in a more readable format. And what you see here is everything you need to write your own API request. Aside from the small authentication logic needed at the beginning, this is exactly how you would write a request to query your API. So at the top here you have different report level settings. So we chose yesterday’s data, and you can see that represented in the dateFrom and the dateTo.
We also selected Visits and that’s our only metric. So that’s our sortBy here, and you can see our reportSuite as well. Below those report settings you’ll see the metrics that have been selected. So we just have visits in here. Elements represents the dimensions. So we have a pages report, top 10, and then the request is closed off. So this is a very simple example. But just wanted to show you very quickly how you can debug your requests and really start breaking down the API calls made for you. So before I wrap up, I’m going to do one more example. And this one will be a little bit more complex. I wanna show you this because even if you already know the API, you can still use this approach to maybe learn a few more advanced ways to make your query’s, or advance things to include in your query’s such as classifications, or calculated metrics, or segments. So let’s do one more request. We’ll go and add it here.
So this time I’m gonna pick something that has a classification so I can show you how that’s represented.
So I’ll do last touch channel detail. We’ll do campaign. Let’s apply a segment this time. So maybe I want just desktop customers.
Let’s choose a longer date range. We’ll do last week. Let’s break it down by day.
Moving to the next screen, let’s give this a second dimension. And let’s do last touch channel detail. Maybe we want our top campaigns with the underlying tracking codes.
I’ll even change the filters here. So instead of top 10, top 10, let’s just do the top five campaigns.
And for details, let’s exclude anything that says unspecified 'cause we don’t wanna see anything that doesn’t have a tracking code. We’ll hit okay, hit okay, and then we’ll add in a couple metrics. So let’s add in visits and let’s add in a calculated metric as well of visits per visitors.
I’ll go ahead and select our cell here.
Let’s start a new Charles session and we’ll go ahead and click finish.
So in Charles we’ll reduce down just to the report calls that are going out.
Can see we’ve already gotten our queue call. On the request tab we’ll have our report description here. So we’ll copy that, paste it over to the notepad, and now you can see a much larger request than the first simple example that we did. So still the same structure there’s just a lot more elements included in here. Now we can see the segments that we had applied. At Adobe we think of them as IDs. So you’re not gonna see the friendly name here, you’ll just see that ID.
We also chose to apply a granularity, so you’ll see dateGranularity by day.
Down in the metrics section, we have visits like we did before but we also have our calculated metric. And just like segments, we refer to these as ID’s as well. So see that in the list. Under elements, so we chose two dimensions in the Report Builder Wizard. The first one was a classification of campaign on the last touch channel detail. And you can see that represented here. So classification of campaign on the base ID of last touch channel detail. And we changed the filter to top five. Followed by the second dimension of last touch channel detail, where we applied a search for things that did not contain unspecified.
So, no matter the level of user that you are of our API, using Report Builder to learn how to craft API requests, I think, is applicable to all. From a basic request to something a bit more advanced that leverages calculated metric segments. You can really learn it all by using Report Builder which is something that we all know and love already.
If you wanna learn more about our API go to the developer documentation in the description of this video. So we hope you found this video helpful and hope you take this forward and use Report Builder to start learning our analytics API soon.

UPDATE: Report Builder updated how it requests the data slightly. You can still use the approach from this video, but the information will be slightly different in a debugger.

In a debugger:

1 - Search for api5.omniture.com. The number might vary from 1-5 depending on your data center.

2 - Go to the Request tab

3 - Search for ‘Report.Queue’ in the request.

There is also an alternate method to debugging requests like this, and it works just as well. You can turn on Report Builder logging from the Options menu and that will record the same information as a debugger would. Logs can be found under Documents > ReportBuilderLogs, and will be organized by day. You can search the file for ‘Report.Queue’ to find each of your requests. Logs also help with troubleshooting any issues.

For more information on this feature, visit the documentation.

recommendation-more-help
b5d9c99f-be9f-4b96-8809-4e7d6ae353ba