The Perfect Candidate for training as a Digital Analytics Developer

Introduction

This article lists some topics and subjects that a Digital Analytics Developer (D.A.D) will need to be familiar with. There does not exist an agreed curriculum for someone who is working as a D.A.D or wants to break into the field, so the way I’ve approached this list is as an answer to the following question:

Given someone with no substantial experience of Digital Analytics, for which topics should that person acquire some basic knowledge in order to be considered The Perfect Candidate for training as a Digital Analytics Developer?

Background

Put simply, the topics I’ve listed here are based on what I do day-to-day (obviously excluding specific tools such as Adobe Analytics).

Common Topics

JavaScript

This is a big one. JavaScript is the programming language of the web, and it’s used extensively in Digital Analytics development.

If you don’t have any coding experience, that’s the bad news.

The good news, on the other hand, is that:

1. You do not need an in-depth knowledge of JavaScript in order to be an effective D.A.D
   • The level of technical proficiency offered in the free tier of a course such as Codecademy’s Introduction to JavaScript is sufficient
2. Being a Digital Analytics Developer is not a closed-book exam!
   • There isn’t a week that goes by where I don’t have to search Stackoverflow to find out how to do something or even just Google for a refresher on some bit of syntax

I will write a more in-depth article on the exact JavaScript features that I use day-in/day-out, but don’t feel like you need to become a software developer or plough through a JavaScript textbook before you can get started.

The Internet

Another fairly large topic.

There is a great deal of general knowledge about how the actual networking part of the internet that you will need as a D.A.D.

Learning exactly what happens when you enter a URL into the address bar of the browser until the point that your destination page is downloaded will probably cover everything you need to know.

Things like HTTP status codes, redirects, query string parameters, and more will be the topics of a future article.

Cookies

Cookies are probably a technology that you’ve heard about. What you may not know is how integral to Digital Analytics data collection they have been.

One of the reasons they’re such a hot topic these days (mid-2019) – and one of the reasons their use is subject to increasing restrictions – is their potential for storing unique identifiers, which form a fundamental building block of Digital Analytics data: without a method of uniquely and persistently identifying a single browser, it’s impossible to know that the person looking at your site today is the same person who was looking at it a week ago.

With the use of Tag Management solutions (such as Adobe Launch) being the norm, it is increasingly rare that you will interact directly with cookies (which should come as something of a relief, trust me!); however, it is necessary as a Digital Analytics Developer to understand the underlying principles of them as a technology and to keep abreast of the browser vendors’ hardening attitude towards supporting them.

To be explored in another article, but some initial points to note:

1. The maximum size of an individual cookie is just over 4,000 bytes (so, around 4,000 characters of text)
2. Correctly configured, a given cookie can be read on multiple sub-domains of a single site (e.g., www.meriweb.co.uk and blog.meriweb.co.uk and meriweb.co.uk), but never across domains (i.e. you cannot read a cookie that was written on meriweb.co.uk when your current page is on google.co.uk)
3. By default, a cookie will expire when the browser is closed, but can be configured to expire more than 270,000 years after the time it was written!

WebStorage

Browser storage (“WebStorage”) in the form of localStorage and sessionStorage is similar to cookies in that Tag Management solutions tend to take care of the details, and it is rare (outside advanced use cases) to need to directly manipulate these technologies.

But, in a similar vein to cookies, knowledge of how they work, the capabilities they offer, and the limitations they bring is useful to acquire.

The details will be covered in another article (probably alongside cookies), but it’s worth mentioning a few points to give a flavour:

1. The minimum size of WebStorage is typically measured in megabytes (where individual cookie size limits are measured in kilobytes – see above)
   • For example, my current browser (Firefox Quantum) allocates a total of 10MB per origin to be shared between localStorage and sessionStorage
2. WebStorage cannot be read across sub-domains (i.e. what is set on www.meriweb.co.uk cannot be read on blog.meriweb.co.uk)
3. sessionStorage is only accessible on the browser tab where it was written and is anyway deleted when the browser is closed
4. localStorage is persistent through the browser being closed and does not have any expiry date

Web Developer Tools

Did you know that your browser (most typically on laptops and PCs) includes a set of tools that developers use for various tasks such as testing (and even writing) code, evaluating the speed at which pages load, looking into values stored in cookies, and inspecting the traffic passing between the browser and various internet services?

These “Web Developer Tools” (easily accessible by pressing the F12 function key or looking for the relevant entry in the browser’s menus) are invaluable for the hands-on Digital Analytics Developer.

I’ll explore some tips and tricks in a future post, but for an immediate demo, open Web Developer Tools on this very page, select the Console tab, type “dataLayer” (all one word, no quotes, capital “L” in the middle), and hit RETURN (or ENTER); you should see some details of the Google Tag Manager implementation that is running as part of this website:

A whole new world awaits you behind the curtain of your daily web browser!

Third-party Tools

I tend to think of “third-party tools” as being tools or services other than your company’s chosen Digital Analytics tool and the Tag Management solution through which it is deployed. This is a personal stance, and my reasoning is that the data captured in your Digital Analytics solution (e.g., Adobe Analytics, Google Analytics) is often core to your business (and is rarely swapped for another Digital Analytics solution). By contrast, it’s not uncommon for a company to employ more than one survey vendor or to change their online chat provider, and every company I’ve worked with has had dozens of advertising networks hooking into their websites.

With that definition out of the way, I want to list a few categories of third-party tools about which a D.A.D will have some knowledge; two primary reasons in today’s world underpin this fact:

1. The Tag Management solution (TMS) is the obvious vehicle for deploying such tools onto the website, which means they pass through the hands of the D.A.D on their way to implementation, and some of the reasons for this are:
   • It is usually quicker to implement via the TMS than by requesting deployment by the website developers (for any number of reasons)
   • Deploying via the TMS allows much quicker response to amending (or pulling) the code
   • The TMS will offer conditional logic options (“load this tool on the Homepage, but not on the Thank You page”) that may not be readily available to the website developers
2. Third-party tools are often integrated with Digital Analytics tools – potentially sharing data (a simple example being the Page Name)

Some example categories of “third-party tools”:

• Advertising networks (e.g.., Google Adwords)
• Social Media integrations
• Webchat, or Online Chat
• Survey or Feedback tools
• Session Replay tools (these record exactly what the website visitor sees for playback at a later date; exceedingly useful for seeing where visitors struggled to navigate or interact with the site)

Testing Methodology

The D.A.D is often involved testing and Quality Assurance activities – in essence, making sure that the data you have specified for collection is being made available when and in the correct form that was agreed.

It can even fall to the D.A.D to author the test scripts (the steps to be followed in carrying out these validation tasks) that will be used.

Again, while expertise in this area is not demanded, a familiarity with some of the principles and terminology that are used will go a long way.

Advanced Topics

Whereas the previous section listed topics that a Digital Analytics Developer will almost certainly have or gain familiarity with, the following are some that, in my opinion, are likely to crop up (particularly in job adverts and interviews) without being considered fundamental.

SQL

Being involved in the company’s data efforts, it’s possible that you will one day need to use or understand SQL, or Structured Query Language, which is basically the de facto “standard” for reading data from databases (among other database-related tasks).

Microsoft Excel

Love it or hate it, this spreadsheet software crops up often enough in practically any job that it can be hard to avoid.

Regular Expressions (Regex)

Not something that I would list as a must-have; however, it is a powerful and useful tool to understand.

There is a ton of free resources – including tutorials and checkers – available online.

Summary

In a previous post, where I provided something of a basic job definition for the term “Digital Analytics Developer”, I used the term “Jack of all trades”. The lengthy list of “supporting” technologies in this article adds some weight to that.

The Digital Analytics Developer interacts widely within the business and with its external suppliers and must be at least conversant with a substantial range of topics.