I had an extremely brief discussion the other day about custom code, Extensions, and data quality, with Urs Boller.
You all know how much those three topics mean to me, and that I have some opinions on all three of them. I also have a lot of respect for Urs, so when he challenged my idea, I knew I hadn’t thought it through.
Jim Gordon published his excellent article The Semantic Implementation in December 2019. At the time, this article had sat in the queue for weeks, semi-abandoned, waiting for some spark to bring me back to it. Jim’s article was that spark, and the crucial line was this one:
Everything about your implementation must make sense to a junior analyst.
So with that new spark, and knowing that Urs and Jim were very much thinking along the same lines, I went back and changed
some parts everything.
You want to track data. Launch provides Data Elements, which can be used in Rules. Those Data Elements get their values from the data layer. All very simple and beautiful, and therefor perfect.
Jim’s junior analyst will likely be able to use Launch, change and create Rules, maybe even make the odd Data Element.
The trouble is that the data layer is usually far from perfect.
There would be no need for the multitude of different Data Layer Types if it was!
So we build Custom Code Data Elements, encapsulating complexity (which is good) in lots of places (which might be bad).
Urs suggested to have a top layer of Data Elements (the Interface, so to speak), backed by one or two layers of helper Data Elements (the implementation), along with two strict rules:
- Launch admins must only use interface Data Elements
- Interface Data Elements can access the implementation Data Elements if the data they need is not available in the data layer
Urs was explaining how he would split the implementation DEs into a pair (one gets raw data, the other modifies it). If you have read Jim’s article, you’ll notice that Jim suggests the exact same thing: build some helper Data Elements, then use those in “the” Data Element. In his example, the Data Element “Page | Name” would behind the scenes get the data from the data layer if possible (on the desktop site), and somewhere else if not (on mobile site).
So when I asked Urs “why don’t you build all Rules as if the data layer was perfect, then add code into your private Extension that fixes the data layer?”
He didn’t like it.
To Extension or not to Extension
The bigger question is: is an Extension better than all sorts of fixes and conventions?
My point of view, prior to our discussion: OMG yes!
I was thinking about an Extension that would encapsulate a lot of technical details, and ideally give those things proper names.
Here are two examples:
“Ready to fire Target” Event Type
The Extension could provide a “Ready to fire Target” Event Type, which people would use in Rules to fire Target Page Load requests.
What exactly would “Ready to fire Target” mean? Well, that depends! And that could be covered in the Extension.
On a product page, it could mean “wait for all relevant product data to be available, then fire”, whereas on a page like the home page, it could pretty much fire immediately.
Someone using Target would not have to think about it, to an extent.
Custom Pagename Data Element Type
Every single customer I have worked with has a Data Element called “Pagename”, which is of “Custom Code” Data Element Type.
That is due to the fact that noone has a perfect data layer, and that we always have to add logic — like “/” and “/en” should both be called “Home”
My point is that Launch should be accessible, and just like in Analytics, I am an advocate of being as explicit as possible so people can understand what it is they are seeing, what they are using.
Urs, on the other hand, comes from the point of view of someone who has to use and maintain analytics with too little personnel.
You’d think that he would agree with me, therefore, since everything that makes stuff easier to use, also opens up the possibility that other people can chime in, help, do things they need themselves. But no.
And yet again, Jim agrees with Urs.
Urs looks at the whole subject from a point of view of influence. How important is analytics in the context of site development? How much money does he get?
His reality is that he doesn’t have enough of either, and so everything he works with is intrinsically chaotic, unreliable, and sometimes just plain wrong. A clean, comprehensive, well-maintained data layer? Dream on.
So data must be manipulated.
You will have to fix data, create workarounds, put business logic into your implementation, and do other unspeakable things.
If any of those things are particularly durable or needed all the time, it might make sense to put them into an Extension. If you add those into your private Extension, you’ll eventually build a sort of toolset tailored to your site, and your requirements. That can be very powerful!
Sometimes it might make sense to release some of those tools as a public Extension, as Urs and my colleague Ben Wedenik have done with the Mapping Table Extension. Other people have contributed “toolset Extensions”, too.
A lot of the time, though, you will need very specific things in very specific places, and so you’ll build them into Data Elements, or maybe even into Rules.
Naming conventions (such as suggested by Jim in Adobe Launch: Naming Conventions) help a lot here, but an Extension does not.
So, is an Extension the answer?
I think the answer depends on who you are, or rather what kind of people you have in your Analytics team.
I guess the answer depends on your team, then, and their abilities.
Have enough developer fire-power: go for an Extension and keep the UI really clean.
Have analytics people but not much JS experience: go with a more light-weight approach, such as the one Urs suggests, in order to do as much as possible in the UI within Launch.
That sounds like a good compromise, until Jim comes around the corner and reminds us that a) “Everything about your implementation must make sense to a junior analyst”, and b) the implementation will be handed down to other people.
With that in mind, I think the answer is obvious: Nope, an Extension is very likely not the answer, at least not as I planned it.
Using Extensions to reduce custom code, on the other hand, is absolutely an answer!
4 thoughts on “No Custom Code – is an Extension the answer?”
One of the other challenges with putting so much into Extensions is the frequency with which those Extensions would need to be updated. The data layer is a good example, as we have regular issues with our data layer which we find, as “problems” come and go with big IT Site Releases. We find ourselves having to make quick patches to data elements and other code while we wait for IT to make proper back-end fixes (could be 2 weeks to 2 years to get the fix). So having a lot of Data Element/Layer control being done by an Extension would mean we are constantly making updates to that Extension, sometimes needing to be within a day. That is not feasible for us to have our couple developers alwyas handle in such a timely manner.
I’m all for Extensions, but we need to find that balance between the “ideal” framework and the day to day reality of the messy sites we need to support.
LikeLiked by 1 person
Thanks for this Jan!
LikeLiked by 1 person
I think that the idea of zero code is still a good one, a “north star” (as people like to call it now). In other words, we should all aim at it. However, when it is not possible to reach it and we need to compromise, then you can add some custom code here and there, as long as it is easy to follow.