I had a slightly shocking, and certainly eye-opening moment a month ago or so. I was chatting with Cornell, who is not only my colleague, but also probably the best Target consultant I know. He shocked me by casually saying that he thinks the future of A/B testing and targeting is server-side.
As a developer, you will likely not think that statement shocking, but since I identify as someone used to working with Analytics or Marketing folk, it did shock me.
The thing is, though, I think Cornell is right.
If what I hear about where the web is heading is even partly true, we Analytics folk will have to start thinking about server-side, too, against our deep-rooted feelings about why client-side is so much better.
Ok. Putting aside the why, let’s muse a little bit about how that might affect you, the developer, the analytics people, and your friendly marketer.
I think there are two relevant aspects:
1. software / UI for the marketer
2. how we (Analytics people) work with you (developers)
Software / UI
If we switch to server-side analytics, A/B-testing and targeting, we need completely new tools, even though of the three big things we do, only two are affected, really.
1. We need new ways of configuring tracking, choosing data, and managing how that data is ingested, exactly.
2. We will create and manage segments as usual, partly based on that data.
3. And we need new ways of modifying what our visitors will see, based on those segments.
The third one will be the biggest, I think, because it includes both, the infrastructure needed to make changes (independently of release cycles!), and a UI that is compatible with a whole bunch of requirements, such as: can be used by non-technical people, makes sure CI is not violated unless explicitly asked for, makes it easy to find suitable alternatives for whichever piece of content should be changed, and probably a lot more.
I reckon there will be a lot of experimentation on the level of granularity – like will it be easy to modify a single CSS property just as easily as a whole big part of a page or site.
A lot of brains need to go into that.
For the first item, I guess tag management will become less important, while some sort of data flow management in the cloud will increasingly be used. Send data to some aggregator / transformer, which will hand-pick what is needed, then forward that to Analytics. Of course that aggregator / transformer needs a good UI and more flexibility than Processing Rules (its closest living relative). At the same time it needs better (more domain-specific) UI than the good old Yahoo Pipes.
Or we could agree on some standard Data Layer-based approach, essentially a server-side variant of the W3C CEDDL specification. Based on how popular that is right now (not very), I doubt that will happen, but it would be a good idea.
Analytics would be a sort of back-end service which would be triggered on page load, then query all sort of information stores in the back-end. Site meta data? Get that from here. Page name and meta data? Over there. Visitor data? There. The Analytics service would collect all of that, then send it off.
Again, you’d need a decent UI to manage what kind of data should be collected and where from.
While the Processing Rules UI is not too bad for what it does, it would be woefully inadequate as a replacement for tag management.
What that means is that we will either have to accept that some part of development will continually work with analytics and marketing, building whatever is needed for your friendly marketer, or that we will be able to inject code. I think it really boils down to that, both for testing/targeting, and for analytics.
This is important!
This is not your chance to finally reign us in!
Just want to make that really clear.
I, for one, welcome our new server-side overlords.