Using Query Strings to Test Adobe Analytics Data

Have you ever wanted to run a specific scenario in Adobe Analytics, but couldn’t find the exact page flow or variable combination in your own data? This happens to me often. I want to view visitors going down a specific path or setting a specific eVar, but even after spending a lot of time building granular segments, I still can’t mock up or test the scenario I want. If I could isolate the right traffic, I could test out specific website paths, test to see if eVars are behaving as I’d expect and so on. While there are a few “techy” ways to do this with JavaScript, if you are not super-technical (like me), this post will show how you can do this yourself with no tagging required.

Query String & Processing Rule

One way you can mock-up or test the data you want is to use query strings and an Adobe Analytics processing rule. Query strings are parameters appended to page URL’s and you can set them to whatever you want. Adobe Analytics processing rules allow you to set Adobe Analytics variables using rules instead of JavaScript code. When you combine the two, you can pick and choose what data you want to capture in Adobe Analytics later on through an easy application of segmentation.

To start, you will want to come up with a query string parameter that you will use for the times you want to make your own data. In this case, I will use the query string of “?qa_test=” in the URL. For example, if I want to count an instance of the Analytics Demystified home page in my data set, I would make the URL look like this:

https://analyticsdemystified.com?qa_test=XXX

Next, you can set up a processing rule that will look for this query string and pass anything found AFTER the equals sign to an Adobe Analytics variable. In this case, I have created a new sProp called QA Test [p11]. Here is what the processing rule using the query string and this new sProp looks like:

Once this processing rule is active, any URL that has a “?qa_test=” query string will pass the value to the sProp which means that I can run as many test scenarios as I want. To demonstrate this, let’s go through an example. Let’s say that I want to view a specific website path. The path I want is one in which a visitor enters on the home page, views a blog post of mine talking about my Sydney Australia class and then exits on the Eventbrite link to register for the class.

To start, I would copy and paste the URL of my home page and append the appropriate query string (“EntryHomePage:AustraliaPost:LinkOutEventbrite” in this case) like this:

Next, I would repeat this for the URL of the Australia blog post, making sure to append the same query string parameter and value:

Lastly, I would click the link to Eventbrite, which would count as an exit link (so it doesn’t need the query string parameter):

In this scenario, we have sent two hits into Adobe Analytics and then had one exit link. Depending upon how you build your segment later (Hit vs. Visit), it doesn’t even matter if you click on other pages in between the ones you care about. If you later use a Visit segment, it will include all hits, but if you use a Hit segment, it will only include the ones you have designated (more on that later). If you want to test that your hits are coming through, you can use the Real-Time reports to view your QA Test sProp values in near real-time (Note: Processing Rule data will not appear in the Experience Cloud Debugger):

Using Your Data

Once you have passed the data you need, the next step is to build a segment that isolates this data. As mentioned above, a Hit segment will show only the pages that had the query string parameter, but a Visit/Visitor segment container will bring back other pages viewed in the same session or by the same browser. In this case, let’s use a Hit container so we only see the specific data we intentionally added. To do this, you simply make a Hit segment with the sProp11 equal to the value you placed in the query string:

Here we can see that there is 1 Unique Visitor, 1 Visit and 2 Page Views for the segment. This looks correct, so we can save it and begin applying it to reports. With the segment applied, we can check out the results. In this case, I will add a Pages and Exit Links table to see if the data looks as I expect (which it does):

Obviously, this is a very simple example, but it still illustrates that you can use a query string and processing rule to isolate whatever traffic you want.

Advanced Uses

If you want to get a bit more sophisticated with this approach and you don’t want to spend your life setting query strings on each page, another way to use this concept is to simply begin a visit with a query string and then use an “entry” segment to include all data taking place after the initial query string. To do this, I suggest that you begin by clearing your cookies or use a private or incognito browser window. Once you have that, paste in the entry page URL with the desired query string like this:

Once you have done this, you can surf the site however you want to generate the traffic you want to see in your reports. Watching the sequence below, you can see that I have chosen to view the Demystified home page,  then a page detailed some training days we are doing in Chicago later this year, then a page about the AAEC, then a page showing when Demystified folks are speaking at events and then back to the home page.

Once you have completed this, you can create a new segment that looks for Visits that began with the chosen query string parameter. This can be done a few ways using a URL variable or using the Entry version of the QA Test sProp as shown here (note that the query string doesn’t have to be the first page of the visit):

When that segment is applied, you will see the pages and paths that took place accordingly:

Test New Flow Instances

This concept can also be used to test out specific Adobe Analytics features. For example, let’s pretend that you don’t trust that Adobe has really addressed the “repeated instances” in Flow visualizations described in this post. To test this, you can use the entry query string concept again to model a specific path. In this case, I am using ?qa_test=EntryPageTest2″ on the first URL of the session and, in the session, I am visiting a few pages on the Demystified website. You will notice in the page sequence below that I am purposely refreshing two pages in my session (Adobe Analytics Expert Council and Adobe Analytics Audit):

Once that session has processed, I can create a new segment that looks for pages where the entry value in my QA Test sProp equals “EntryPageTest2” per the description above. Next, I can apply this segment to a Flow Visualization. In the video below, notice that I am first looking at the path flow where repeat instances are disabled. In that case, I see the pages in the order I viewed them and the page refreshes don’t appear. But once I change the setting to include the repeat instances (as was always the case prior to last week’s ADobe release), I can once again see the same page repeated three times for the AAEC page and two times for the Audit page.

Therefore, using the query string parameter, I can do some very detailed tests and make sure that everything in Adobe Analytics is working as I would expect.

Summary

As you can see, this technique can be used whenever you want to be prescriptive about the data you are viewing in Adobe Analytics. And since it requires no tagging, anyone [who has Admin rights] can do it. I have found this especially useful when I want to test out the differences between Hit, Visit and Visitor segments and testing segments in general. The above has mainly shown how the technique can be applied to pathing/flow sequences, but it can also be used to test out any type of Adobe Analytics tagging.