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.
10 thoughts on “The Era of Server-side Everything”
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.
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.
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.
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…
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.
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?