No Custom Code – is an Extension the answer?

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.

Context

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:

1. Launch admins must only use interface Data Elements
2. 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.

Reality

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.

If your friendly marketer works with someone who knows Javascript, then I would go for the Extension.

But Urs is right: it is much easier, technically speaking, to manage elements in the Launch UI, then it is to maintain an Extension, especially for non-Javascript speakers.

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!