A Full Guide to Event-based Marketing (Including How to Do It)

A Full Guide to Event-based Marketing (Including How to Do It)

This comprehensive guide to event-based marketing is designed to help digital marketers utilise javascript “events” to trigger marketing, product, analytics, advertising and communication campaigns based on user behaviour.

 

To be clear, this is not a guide about promoting physical events. This is a guide about using javascript based events to automatically trigger marketing.

In the context of digital marketing, “events” record a single instance of a behaviour occurring on your website or app. They are called events because:

  1. they record a change in state, and
  2. Javascript technology uses events to trigger functions.

I’ve worked with event-based marketing since 2013 and in this article, I’m going to teach you everything I know about this field of marketing.

Table of contents

  • Does event-based marketing work?- DONE
  • Technical background to event-based marketing – DONE
  • What is an “event”?- DONE
  • Right person, right message, right time – NEXT
  • Implementing events
  • – How to structure your events (layout/table)
  • – Google Tag Manager or Segment
  • – Using events in Amplitude
  • – Using events in Vero
  • – Using events in Facebook
  • – Using events in Hotjar
  • – Using events in Google Ads
  • – Using events in eCommerce
  • – Using events in SaaS (activation)
  • Tools that support event tracking (and tools that don’t)
  • Getting started

Does event-based marketing work?

Yes, event-based marketing works and it’s probably the single biggest opportunity for growth in almost every business today.

I’ve been using event-based marketing for around six years now. I’ve implemented it successfully in my own business, and have helped many other companies implement it. In every single case, those businesses saw an immediate company-wide increase in every metric that matters. From revenue to email deliverability. I’ve literally seen 400% to 600% increases in conversion metrics overnight. Event-based marketing absolutely works.

The performance of every single marketing channel and activity is enhanced when event-based marketing is added. Even interstitial popups convert well when enhanced with event-based marketing.

Yet, despite all of this… very few people know how to do it.

This makes sense though because it’s virtually impossible to learn. There is literally zero content online about it. Not a single guide or course… a few articles here and there, but that’s about it. So, being the content-savvy marketer I like to think I am, I started writing about it (and teaching it in real life). This was a great decision because it’s helped me refine all of the content I’m about to share with you. The diagrams, the explanations, the metaphors, the strategies and most importantly the application of the concepts are all better because of the real-life testing that has taken place in the classroom. Let’s begin…

Technical background to event-based marketing

It wasn’t until the early 90s that marketers first started tracking people visiting their websites. Unlike the way most marketing professionals approached their job at the time (think Don Draper), this new breed of marketer was fascinated by measuring whether their marketing activities actually worked. These data-driven-pioneers were the first ‘digital marketers’ because of one thing: data.

Access to data was the turning point because it closed the feedback loop of marketing. Immediately every single marketing function became measurable, which in turn creates an opportunity to optimise our marketing. Data also speeds the entire marketing process up; if you’ve ever tried to optimise a website with no traffic you’ll know what I’m talking about.

From this moment on, data gave us the ability to measure our performance as marketers and compared to the incumbent alternative of little to no measurement, it probably felt like it was all happening in real time. Indeed, this was the birth of digital marketing, and the data source we came to rely on was server logs.

Server logs

Initially, the ability to actually measure the traffic to your website and the pages people were interested in relied on the most basic analytics technology we have: server logs. Server logs still work to this day. They show us the documents being requested by people who visit our website. When PHP, XML and HTML were the default web languages this worked well because every change in the state of a page (and the information contained upon it) relied on a call being made to a server. The typical user path on a website would look something like this:

The server log would tell us which documents were being requested on the server, and in which order. Beyond this, marketers couldn’t do much more… but neither could websites, so the data still felt pretty powerful. However, far more meaningful metrics would become available if we moved the tracking scripts to the client side. Enter ‘click-stream analytics’.

Click-stream analytics

Although they were not the first with this technology, the release of Google Analytics in 2005 democratised online analytics by introducing a free analytics package that would enable anyone with a website to begin collecting in-depth analytics about site usage.

The technical innovation was based on the repositioning of the data collection away from a server-side implementation to a client-side implementation. Rather than tracking document requests on the server, we would monitor requests from the front end of the website itself using a piece of javascript. In other words, we tracked the “click” side of a document request, rather than the response side of a document request. Clicks are an important evolution because they also represent a shift towards intention based metrics.

This repositioning of tracking allowed us to obtain an ever increasing number of new data points. Things like bounce rate, time on page, session durations along with new browser information such as screen size suddenly all became possible. The click-stream still recorded the movement of a user between documents, but it leveraged the user’s browser to achieve it (rather than the server).

This was a major breakthrough but it was appropriate given the changing purposes of websites. Rather than websites being brochures online, websites were becoming shops… and applications (such as forums and trading sites like eBay). This change in the way we used the Internet also spawned the development of a new series of technologies designed to facilitate a more lightweight transfer of data between a user (client) and the server. Not only would this speed browsing experiences up, but it would also take an enormous computational burden off the servers themselves (simply by reducing the size of the requests).

The things we cared about, such as a reply to our message or the change of an item’s price on eBay represented a very small portion of the overall HTML document. So instead of needing to reload the entire document, we were increasingly only reloading the portions of the document that had changed (often just a single line or value). AJAX and Javascript languages offered a way for websites to achieve this, by transferring small packets of data within the page itself.

Google Analytics quickly added support for these in-page changes of state using a new report called “events”, but the fact that user data is not allowed inside Google Analytics largely renders this function useless. Events in GA can be used for goal tracking and simple reporting, but not much more. This was not a problem for click-stream analytics at first, until Javascript took over most of the web in the form of Single Page Applications (SPAs). Yep, I’m talking about Angular and React, along with back-end frameworks like node.js.

Suddenly a single document became an entire website.

Event-streaming analytics

As websites quickly evolved into web applications a document based tracking method was no longer adequate. Users could spend 10 minutes on a single page clicking, liking, saving, posting and otherwise interacting with the page despite the document path not changing. Think of Facebook.com’s home page news feed for example, as a user scrolls through their uniquely personalised news feed liking and commenting on posts, they are creating an enormous amount of data, but the document path is not changing. In this scenario, a click-stream based analytics tool like Google Analytics would simply report time on page of say 10 minutes with a 0% bounce rate.

The fact that all of these sites run on Javascript technology means that all of these interactions are already being recorded using javascript events. Amongst other things, these js events are used by the application to change what the user sees (the DOM) and how they interact with content whilst avoiding reloading the entire site itself. These events trigger client side or server side functions and can transfer data… again, all without requiring the page to be reloaded.

For example, imagine a user finding a product on an e-commerce website, adding the item to their cart, and commencing the checkout process. The event-stream would look something like this. Notice how it’s sitting on top of the document (server logs) and click-stream.

You can see from the diagram above that the click-stream is really not that useful at all. So, now we arrive at the present day.

Event-based marketing today

Today, javascript events are running most of the front-end and back-end of websites and applications, but marketers… and product people… and even engineers sometimes just aren’t using them. Or are they?

In 2017 Facebook announced the transition away from the 8 default ‘conversion pixels’ to a new ‘smart pixel’. You’ve probably guessed it, but the old conversion pixel was a server log based analytics method, much like the 1px by 1px image contained within emails to record email opens. The old Facebook pixel would trigger a request to a document on Facebooks server, located at a unique path where it could then be mapped as a conversion. The conversion count was simply the number of times the document had been requested on the server. The ‘smart pixel’, again you’ve probably already guessed it, is a new javascript based event tracking script. Javascript events would fire, sending a record of an event having occurred back to the Facebook conversion server. The number of conversions would be equal to the number of times the event had fired. This matters because marketers are interested in who triggered the event, not just the fact that an event was triggered.

So, that leads us to the present day. Any marketer using Facebook advertising is already using ‘events’ to measure conversion (they just don’t know it) and the worlds number one analytics platform doesn’t support personalised event tracking. Can you see the opportunity?

What is an “event” in the context of event-based marketing?

Definition

An event is a record of a single instance of behaviour taking place on a website or app. It’s pinned to a single identity (known or unknown) and we can store useful information inside it.

Think of an event like a box that you can store useful information inside of. It gets automatically created when a user performs an action or a task (a behaviour) you are interested in observing and measuring. This box can then be stored, and sent anywhere you desire. If you want your email marketing platform to know about the event, send the event there. If you want to serve the user an advert in Facebook based on this behaviour, send the event there. If you want to create a report of the number of times this event was fired, you might send a copy into Amplitude to help generate the report. If you want to send a push notification a week after the user triggers the event, send it to Vero.

Anatomy of an event

There are three parts to every event:

  1. An identity (even if it’s anonymous)
  2. A unique event name
  3. Attributes stored inside the event.

Again, an event is a single instance of behaviour with information stored inside it. People trigger events, which means we can attach an identity to the event. As marketers, this means we know what happened, when it happened and who did it.

Why do we use the phrase ‘event stream’?

As users move around our website or app, clicking and interacting with things, they create a stream of data. This stream describes the user’s actions in chronological order. The stream really matters because it helps us perform what I can only describe as ‘reactive marketing’. We can react to users actions in real time by creating conditional rules. For example: if a user triggers, “add an item to cart” and does not trigger “started checkout” you may wish to commence display advertising containing the products the user just added to their cart. The fact that events happen in a particular order means we can more easily build conditional sequences around our user’s behaviour.

Stateful and stateless data

Lastly, it’s beneficial to know about the differences between stateful and stateless data. This is a very technical concept, but it fundamentally underpins event-based marketing.

Stateful data allow us to create, store and read the memory of the data generated in the lead up to a stateless change in our database (like filling in a form).

Stateless data holds no memory of the past, it merely contains the most recent version of a record (such as the information submitted by the form).

Most marketing platforms were built for stateless data streams. This means that marketers can only react to stateless changes in the database, such as a user creating an account, adding an item to their cart or making a purchase. However, to build a truly customised event-based marketing program, we must be able to trigger marketing automation on the smallest changes, and these can be easily measured using stateful data points.

Right person, right message, right time

Leave a comment