March might be my favorite month of the year. It usually starts, as it did a few weeks ago, with Adobe Summit, which is always a great time for learning, networking, and sharing our vision of the future of digital marketing. Then March continues with the NCAA Men’s Basketball Tournament, my favorite sporting event of the year. And this year, March is exciting for an additional reason: our latest release of Adobe Analytics, which happened today.

In this post, I want to highlight a few of the changes you should expect to see immediately relative to the SiteCatalyst portion of the Adobe Analytics toolset.

Correlations for All!

What do we want? Data correlations! Where do we want it? Everywhere! 

In my breakout session at Adobe Summit earlier this month, I shared a tip which explained that newly enabled correlations in SiteCatalyst 15 automatically populate with data going back to your SC 15 upgrade date.

That tip is already officially out of date, as our engineering team has now enabled all correlations out of the box in SiteCatalyst 15. This means no more enabling correlations in the Admin Console, and no more calling ClientCare to get a five- or 20-item correlation turned on. All possible data relationships are available automatically, and those relationships exist going back to your upgrade date.

Correlations are a key component of Adobe Analytics which allow you to discover the relationship between data dimensions. As such, they are great for answering questions that span multiple dimensions, such as “Which referring domains drove traffic to my page?” and “What browsers are most popular with my customers in Tokyo?” I’m very excited that users will now be able to answer more of these questions, faster and more completely than ever before.

Anything by Anything by Anything by Anything

An additional benefit of this change is that all correlations are now n-dimensional. In the past, the most common kind of correlation related two specific items, such as Page Name and Search Keyword. You could break down one by the other (and vice versa), but that was it; you could go no deeper. Five- and 20-item correlations allowed you to drill more deeply into your data, but those were more rarely used. With this change, you can keep drilling into your data until you find that nugget of insight that you’re looking for, whether that means breaking down Page Name by Search Keyword, or whether it means breaking down Page Name by Search Engine by Browser by Geography by Video Name, or whatever other dimensions you need.

As I hope you can see, this is a huge step forward for unlocking the value of your data within our web UI.

PTI (Push to Implement)

With this release, we are introducing the most robust one-click mobile app implementation available anywhere. With the Adobe Analytics mobile SDKs, one line of code now gets you rich user and content data, including lifecycle metrics such as installs, upgrades, launches, crashes, and more. All of this is available without implementing a single prop, eVar, or event.

I like to call it “Push to Implement” (like “Push to Talk;” get it?) because it really is that easy. Once you’ve deployed the mobile SDKs according to the documentation, you can now go to Admin > Report Suites, choose the right report suite, and then go to Edit Settings > Mobile Management > Mobile Application Reporting. There, you will find a button called “Enable Mobile App Lifecycle Tracking.” Just press that button, and all of the data I mentioned above will become available to you in out-of-the-box mobile app reports and dashboards. Many users will now be able to do rich mobile app analytics and segmentation without using custom variables or a single line of additional code.

My colleagues will likely be blogging more about this soon, so I’ll link to their content when it becomes available.

Login Improvements; Also, Ben Writes Some Code

It is true: I have code that went out with this release. Very exciting. I think we can say that it is a milestone in my life. With the careful oversight of one of our most senior engineers who reviewed my code for me, I fixed a few annoying issues relative to the login process.

  • Many of you (led by Kevin Rogers, who originally submitted the feature request in the Idea Exchange) have reported that it is a drain on your time to have reset your colleagues’ non-admin user accounts which have become locked due to too many failed attempts. We have added a link to the “Reset Your Password” page in the message that users receive when they are notified that their accounts have been locked. Hopefully this will reduce calls/e-mails and free you up to do more analysis!
  • For new users, or those who have not visited the login page since last clearing cookies, the default product version is now SiteCatalyst 15. You can still select SiteCatalyst 14 from the version drop-down on the login page, but this should hopefully save time/confusion generally.

Meet s_fid: A Better Fallback Visitor ID Methodology

In the past, whenever a user did not accept the s_vi cookie, SiteCatalyst used a combination of users’ IP address and their user-agent string to differentiate one visitor from another. With the release of H.25.3 code and newer (, the JavaScript code now sets a first-party cookie called s_fid containing a visitor identifier generated within the client code. This cookie is used to identify visitors if the s_vi cookie cannot be set. (If neither cookie can be set, the previous fallback method is still available.)

This allows us to be more accurate in our fallback visitor identification method. For example, if Bret Gundersen and I are both browsing the same site from the new Adobe campus in Lehi, Utah, we will appear to have the same IP address. We might even have the same user-agent string depending on our browser and other factors. This new method will ensure that we are measured as distinct visitors/customers.

Furthermore, given that third-party cookies are likely to be blocked more frequently, this helps ensure that visitor measurement continues to function accurately.

We recommend that you upgrade to code base H.25.4 to take advantage of this new fallback visitor identification methodology. If you’re interested, you can read more about this in our online documentation.

Naming Processing Rules

Processing Rules are a powerful capability in the Admin Console which allows you to make minor implementation changes on the fly without touching any code. For example, you can capture campaign tracking codes, combine two variable values, or label keywords as branded/non-branded. This is done by writing some “guided logic” in a series of conditional (if/then) statements.

In the past, you might have have five rules that all set a certain variable—let’s say, the Tracking Code variable—based on different criteria. For example, sometimes you want to set the Tracking Code to the value of a query parameter; other times you want to set it to the value of a different variable. When you collapse all of those rules, they would all say “Set Tracking Code conditionally.” You would need to expand the rules to understand what they all do differently.

With this release, you can provide a friendly name for each processing rule. The ability to assign each processing rule its own name makes it easier to set up and manage them. Now you can know exactly what each rule does without investigating the logic or reading the notes inside of the rule. Thanks to Jason Paulsen for submitting this idea in the Idea Exchange!

Not the End

FYI, we have now implemented nearly 200 of your feature requests from the Idea Exchange!

There is even more to be excited about in this release, so please check out our Release Notes. As always, please let me know what you think by leaving a comment or hitting me up on Twitter at @benjamingaines. We’ll be back next month with more great additions to Adobe Analytics. That’s right, more Adobe Analytics AND the start of the baseball season.

Have I mentioned that April might be my favorite month of the year?

0 comments