For the last 5 years and a bit, I have been working in the Adobe office in Basel. I came here more or less by chance, and it turned out to be a nice and interesting place.
The Basel office came to Adobe via the acquisition of Day Software. It is the place where AEM was built, and culturally, it is an engineering office.
For me, coming from a sales-y office / home office into an engineering office, plus from a very Target and Analytics oriented crowd into a purely AEM crowd was a dual culture shock.
Not to mention life outside the office. Swiss German is to German as Italian is to French. I still can’t understand Swiss unless I put all my concentration into it.
But you know what’s great about culture shocks?
You learn. A lot.
I was the only non-AEM in Basel for a couple of months, and that was a very interesting ride.
I like helping people, but I had to admit at some point, that sometimes, helping means just planting seeds. My mind set was so far away from that of most people here, that we first needed to build a common foundation.
These days, the seeds have turned into trust. People come and ask me all sorts of Analytics- or marketing related questions. I especially like it when my engineering colleagues come and want to see data.
That’s exactly where we want to be! Data can help!
A couple of questions have come up again and again, and when that happens, there must be an article in there, somewhere.
So, after the longest introduction ever, here it goes.
Developers often think of Analytics as a tool that will give them a sequence of things that happened, a bit like a trace or a log. Sometimes they think about sending data into Analytics in terms of key-value-pairs, and the notion of a page view tends to stump them.
That is when I usually try and talk about what they expect from Analytics versus what I think they should do with it.
Analytics is not a Logger
I don’t have to tell you that developers spend a lot of time debugging. Debugging is hard, even though code is usually predictable. If you run the same code twice, and you interact in the same way, it does the same thing.
At the end of a debug session, you would almost always have found out why code did what it did.
The notion that things happen in some order is absolutely normal for developers, as is the notion that there must be a reason.
When you work with Analytics, the notion that things happen in some order is absurd, funny, or a dream that we all gave up after a week or so of looking at data. And let’s not even talk about reasons.
Every single developer I have spoken with has at this point been disappointed.
“If I cannot see what people do, what can I see?”
We then usually go into a discussion about actual goals and needs.
To give you an example: the editor in AEM is a pretty funky thing. There is a lot of stuff happening in the browser when an author in AEM edits a page. One colleague wanted to know exactly how people used the editor.
In the end, he was really interested in making it faster, and so we settled on tracking times between key actions, e.g. from opening the page to it being editable (editor has initialised and can be used).
The big gap there was between “give me all the data, and I will find what I need” and “tell me what you want to know, and I’ll give you data to answer your question”
Analytics does the latter.
Pageviews, or “can’t you just keep it open?”
I was frustrated for years about how AEM does a lot of things asynchronously.
If you do A/B testing, targeting, or analytics, you like your data to be available as early as possible. A data layer would ideally be delivered along with the HTML, in the <head> of the page. Can’t be that hard, right?!
AEM really doesn’t do that, and by design. You can put parts of your data layer into templates, of course, but a lot will simply only be available later.
Example: a product page may load more or less empty, and it may reload product data, price, availibility, and other stuff asynchronously.
For me, that means I must make a choice: send data early, incomplete, or send complete data, late.
The issue with the latter is that people may have moved away from the page if I wait too long, so that is really not in my best interest.
But the former is not good, either. I want that data! I want to be able to look at my reports and tell which products visitors have seen!
When I told my AEM colleagues how frustrating async was for me, they would usually shrug, “oh well”, and walk away, bemused by that crazy guy and his first-world problem.
My developer colleagues would always make the same suggestion: “can’t you just send some data, keep the channel open, and send the rest when it is available?”
The answer, unfortunately, is that you can’t. (At least not right now. Some of the recent announcements point towards a future where I may be able to do just that)
Often, it doesn’t even matter. I could just send data in multiple calls, but that would also cost more, since Analytics is billed by server-call.
So no, I can’t keep the call open, and yes, I still would love to have data as early as possible for the time being.
You don’t choose the key
The third thing my dev colleagues do is think about data being sent to Analytics as key-value-pairs. “componentID = abc123”
Analytics has up to 250 custom dimensions (“eVars”) for you to use, and it is up to the administrator of your deployment to decide what data goes into which dimension, but the bottom line is that there are 250 of them. A little bit of planning is in order.
Even at Adobe, the people managing Analytics settings and the people who need data are not always able to communicate efficiently, and so the first thing I do is try to explain to my developer colleagues how Analytics works.
I found it helpful to only talk about events and eVars.
Using events, you can count things. Things that happen, things that visitors or site users do, doesn’t matter. When a visitor opens the page editor, and if we want to know about that, then lets count it. Let’s assign an event.
Using eVars, you can drill down, be more specific. Want to know which page the editor has been used on? Put the name or the URL of the page into an eVar.
Dimensions usually end up as text on the left hand side of a report. Events will end up as numbers in that same report, one event representing a column.
Events are for stuff that is important. And eVars are to tell you more about what happened.
And that’s it.
Note: I think that in the future, we will have more flexibility. I base this on the announcements like this: Adobe Brings Photoshop-Inspired Functionality to Customer Journey Analysis I have no say in where this all goes, but this looks like Workspace would go straight to Platform, doesn’t it?
Notes
Over time, I have seen a lot of confusion and missed opportunities, but there has also been a lot of progress. The first Analytics Cloud Service, as an example, was an interesting answer to a question noone had or would ever ask. We have come a long way since then!
Regarding the notion that things happen in some order: if you do Analytics, you know that visitors tend to behave erratically. However simple you think the flow of some action on your site is, there will always be people who do not follow that flow.
“But why would anybody put article A into the cart and then immediately log out?” we ask, until we stop asking, because, well, they just do. We accept the quirkiness of people as a fact of life, and we move on.
I wonder whether people in web analytics have a more relaxed outlook on life, are more tolerant? We see daily that all roads lead to Rome. Does that shape us? Or do you have to be open to this to be able to be a good analyst?
Sometimes, the effect is even positive!
In 2013 I was on site when a British retailer had a relaunch. It was felt that I should be there, in case the Analytics deployment was horribly wrong.
An hour or so after relaunch, someone realised that whenever a visitor added a product to the cart, there was a popup that covered all UI elements. The popup was placed so you couldn’t reach the “x”, and ESC wouldn’t close it, either.
See a product, click “Add to Cart”, stuck.
PANIC!
One guy started calculating how much money they’d lose, because of this. If people couldn’t move on from this screen, nobody could buy anything! Total disaster!
Then we checked in Analytics, and there were orders. We asked a backend person, who also saw orders.
The site was fixed quickly, and everyone went back to normal.
Later, we figured out that people had in a lot of cases simply closed the browser, headed back to the site, found their cart with the article in it, then finished their purchase.
Ingenuity and sheer stubbornness, highly underrated.
I think people are so used to the Internet being a bit wonky that they have developed all sorts of tactics, like closing the browser and simply trying again.
Web Analytics for Developers 
2 thoughts on “Analytics for Developers”