To code or not to code

In the early days of digital analytics, then called Web Analytics, when mobile phones did not support Javascript and modern clickstream tools such as Google Analytics, you could split the field into two groups of practitioners: analysts and implementation experts. The second group emerged when companies learned that IT could not do tagging well despite their Javascript proficiency—implementation required developing specialised web development skills. Analysts typically studied humanities at university, while implementation experts studied computer science. You could summarise the split I mentioned earlier thus: who can code and who can't.

About a decade ago, I noticed a new trend in digital analytics: why bother with a SaaS clickstream tool when all vendors provide APIs to their servers? The interface can be clunky, slow, and feel like a straightjacket. With R or Python code, you could pull the same data and data from other sources, blending them to generate richer actionable insight than the user interface ever could. There's only one small problem: such analyses require coding skills. The typical analyst can't code, and the typical implementation expert can't analyse.

With the rise of inexpensive online courses like Coursera, Udemy, and many more, many analysts have upskilled by learning SQL, Python, and R. Google made huge strides into cloud computing, created the Google Cloud Platform (GCP) as an alternative to Amazon Web Services (AWS) and Microsoft Azure. Google has offered Google Analytics analysts a smooth introduction to GCP with BigQuery (BQ). Google then acquired Looker, and many Google analysts are coding in SQL. Here's a quick timeline:

• 2005: Google acquired Urchin Software and rebranded it as Google Analytics (GA)
• 2008: Google enters the cloud computing market with the Google App Engine
• 2011: Google launches BigQuery on Dremel, a fast querying tool for large datasets launched in 2010
• 2011: Google launches Google Cloud Platform (GCP)
• 2011: Google launches Google Analytics Premium (GA Pro)
• 2012: GCP users now have access to BigQuery
• 2012: GA Pro becomes Google Analytics 360. It supports a new feature called BigQuery Export, which lets analysts analyse raw data without needing the GA interface
• 2012: Looker was founded as a separate company. It is a business intelligence and data viz tool for cloud-based data
• 2016: Google launches Google Data Studio, a free data viz tool as part of GA 360
• 2017: Looker grows fast, finds immense popularity with BigQuery users
• 2019-2020: Google acquires Looker
• 2019: Looker lets analysts visualise data sitting in BigQuery and other cloud databases, also supports machine learning
• 2022 Google Data Studio becomes Looker Studio

The timeline above shows a gradual transformation of an analyst using the GA interface for all their needs, probably along with Excel, to a more sophisticated stack requiring coding skills. Taking full advantage of that new stack requires learning various programming languages: Python (TensorFlow, pandas, Flask, Jupyter notebooks), Node (server-side Javascript), SQL, Java (or Go), Bash/Shell scripting, LookML, Kubernetes, Terraform. Admittedly, a minority of analysts with a humanities degree will learn all this, but the metaphor of a frog in boiling water comes to mind.

What I find particularly surprising is that I know many people in my network who are embracing the journey towards becoming a technical analyst while leaving implementation entirely in someone else's hands: the implementation expert. That is not exactly what many hiring managers had in mind when looking for a technical web analyst. They wanted someone capable of doing both analysis and implementation. Why did we not see another scenario where the implementation specialists took on analysis since they already know how to code and have a stronger affinity for the technical side?

Digital analytics is notorious for its lack of career progression, as confirmed yet again by this year's Harnham's salary surveys as a top three most common reason for leaving a role in our field (1st in the US with 23%, 2nd with 24% in the UK, 3rd in France with 23% and 3rd in the Netherlands with 13%). What is true for analysts is even more true for implementation experts: once you specialise as an implementation expert, your career progression is over. Hiring companies will no longer consider you for any role other than implementation and will see your enduring commitment to implementation as having found your calling. However, the bills won't pay themselves.

Is the rise of the analyst who can code to blame? Can't implementation experts pick any of the formidable stack that analysts must contend with? Kubernetes/Docker, Terraform, Node, ETL/ELT and Bash/Shell relate more to data engineering than data analysis. Machine Learning probably sits right on the fence between data analysis and data engineering, revealing a spectrum rather than two distinct camps.

No code? Really?

The rise of no-code solutions is hard to miss—more and more tools in our field claim to require little to no coding skills. Adobe, for example, is pushing for a new paradigm called Customer Journey Analytics (CJA), and one of its main selling points is letting stakeholders query the data using natural search with a large language model (LLM), translating the query into SQL.

Stakeholders managed to sell the idea that data analysts lack business acumen. The result was the emergence of dedicated teams of data analysts doing the Sisyphean work of closing tickets in their BAU (business as usual) queue. Stakeholders tend to behave like kids in a candy shop where all the other kids seem invisible to them and expect to get an answer immediately. Natural language could deliver just that, but will they use it?

It is not the first time digital analytics tool vendors have tried to empower the decision-maker, and they have failed every time. The intended user for their clickstream tools was never a web or digital analyst; it was the stakeholders. However, the stakeholders refused to learn a new tool, so our jobs were born. When Tag Management Systems (TMS) appeared, guess who the intended user was. The stakeholders, but since there already was one or a few digital analysts, either in-house or agency-side, it befell them instead.

I predict that history will repeat itself: the stakeholders won't touch a natural language tool to query the data themselves with a bargepole; it will be data analysts, albeit more junior and cheaper than what we have today. Implementation is more art than science and should remain relatively unchanged, for better or worse. Whether they pick more data engineering and DataOps tasks remains to be seen as IT might prove more experienced.

Data may be most valuable when stakeholders access it as early as possible. Real-time data may seem ideal until life knocks on your door: how good is data when you are stuck in a meeting without access to your real-time data tool, at home in your bed, or during the weekend, a holiday or sick leave? Real-time doesn't work. You will have to rely on underlings. Do you have the budget for a full-time dedicated data analyst? The answer is probably no, so that means a centralised data team, which you have, raising a ticket that will go through triage, competing with other tickets with unbeatable priority over yours.

#MeasureCamp #DigitalAnalytics #Coding #NoCode #DataOps #WAWCPH #CBUSDAW