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.
I am so used to doing things in Javascript, quick&dirty-style, outside the normal constraints. Like a lot of people on the business side, I perceive release cycles and the usual rigor of development as a massive obstacle… it is hard for me to imagine a world where we decide to give up the flexibility tag manegement and Javascript-trickery bring.
The thing is, though, I think Cornell is right.
The data available on the server can be so much richer that it would be foolish to rule out server-side segmentation, and while in the past, modifying a page with Javascript was ok, it will be harder and harder in the future. Think SPAs, dynamic content, progressive web apps, and whatever else that fad will be.
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.
Working together
If we work mainly or exclusively server-side, we have to make sure we (Analytics/Marketing) don’t have to give up too much of our flexibility. That is the number one requirement on our end. It is what led us to the Javascript-based approach and tag management in the first place, and if “server-side marketing” doesn’t come close to that flexibility, adoption rates will likely be bad.
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!
I have seen how ops and dev teams react when we say we inject Javascript into sites. I understand that keeping a site working is hard, and that we don’t help, rather the opposite. But what we do ultimately helps the business, which is why the busniess pays for it. The reality is that if moving to server-side comes with more hoops attached, then it won’t happen, or we will just bolt client-side on top.
This is not your chance to finally reign us in!
Just want to make that really clear.
I guess we don’t play around with Javascript because we want to, or because we love Javascript so much. We do it because currently, it is the easiest way for us to gather the data we need or run the testing or targeting that we think will make a difference.
If server-side will make it easier for us, or better, than we will embrace it. Noone will shed a tear for finicky Javascript, race conditions, lost tracking, 10% discrepancy in the data, and all the other downsides of client-side marketing technology.
I, for one, welcome our new server-side overlords.
Web Analytics for Developers 
Interesting thoughts Jan. I read a blog a couple of months ago about analytics tracking calls being dealt with by redux middleware in a similar way to logs.
LikeLike
Very interesting. As a web dev for analytics beginner, it has definitely made me aware now server-side analytics. I only know, read or hear about client-side stuff so it’s time for me to keep learning!
Thanks for writing the post.
Rafa
LikeLike
The key to this is as you say, making it user friendly for the “average” person and having the flexibility needed. Of this I’m very skeptical of in-house teams being able to do, so most likely this will require vendors to create a server-side product that will be designed by professional UX designers. And those tools/programs will need to have certain amount of standard way of going about how it works, so there is a level of consistency for users across companies. Basically having tag-management type vendors moving their products onto the server side of things.
LikeLiked by 1 person
I remember several years ago the IT group of the company I worked for built their own content management tools, about 5-6 of them for different types of content data. I love IT folks, but UX designers they are NOT. So the thought of IT people building these server-side tools on their own brings back some ugly, painful memories.
LikeLike
Interesting thought on server-side analytics… but still some difficulties if you want some fine-grain analytics. There are a few points I’s like to pinpoint which is still pretty difficult to handle server-side:
– in view checking: we do a quite a lot of impressions or views on banners, content blocks, etc, checking the client view, only firing an event if the banner or block is visible to the visitor.
– we cross a lot of in-page wizard style multi-step controls, rendered fully in the dom a page load, and stepping through client-side; only requiring a back-end call at the end of the wizard. With server-side tracking you would need to call the back-end server at each step…
One further remark on analytics: if you look to web-app frameworks like Vue or React, keeping the “page load” based analytics idea, with a data layer bound to your page, will be hard to sustain… We rather think of “event based analytics”, where showing some component or interacting with a component on a web page triggers an event to analytics… This fits better in these kinds of app-sites, and is still usable with the legacy page-based websites…
LikeLike
Good thoughts!
Your second case is actually not problematic if you do server-side. Even today, it is likely that instead of using a TMS, you’ll have your developers build explicit calls. So the only difference would be that those calls would go to the server, which in turn would handle tracking.
The downside: more coding. The upside: access to a wealth of information server-side that would or could enrich the tracking at any point.
There is a full spectrum from static sites to SPAs. The former are lovely, and TMSs have helped _a lot_. The latter are still handled almost like we did sites pre-TMS. Each technology comes with its limitations on what we can or have to do.
From what I hear, the future will be experiences assembled from a multitude of small-ish services floating about. I think we will at some point be confronted with a reality that will prevent pure JS, client-side Analytics.
It’ll be interesting, I guess.
LikeLike
Hey Jan
Nice read
I’d love to see a version of the blog where you discuss the facts that must be in place in the client to support a well-oiled machine supporting both marketing and application portfolio management. In most of the apps and sites built today (certainly all of the ones driving the current tag management and analytics solutions), there is no consideration of analyst concerns in the design nor actual implementation of the customer facing app/site. If the business folks that are measuring value are not represented at the table, the tech and operational organizations will only focus on publishing and barely anything else. Teams that are only concerned with places to type and publish content, rather than actually managing their content and apps, will never think about, nor build abstractions necessary to support a clear data and event model in the client. Consequently building systemic tools to support the problem will always be relegated to solutions like injecting random scripts.
Do you see any movement in the UI frameworks communities to support business abstractions that expose a clear, manageable, data and event model?
LikeLike