Publisher-Listener API: The Superiority of Signals

Advancements in the marketing and technology landscape over past years have helped the availability of accurate data, allowing businesses to interact with their customers like never before. However, with the increase in consumer technology, digitally connecting people and businesses together across time & space, the ability to accurately track the digital user experience across multiple devices and touch points has become increasingly more challenging.
 
One of the largest challenges is blending the technical with the strategic components of a multi-channel analytics program. PCs, smartphones, servers and other pieces of technology speak in code and have their own way of behaving, often foreign to the typical marketer. We introduced our proprietary framework, the Publisher-Listener API, a couple of months ago, as a way to help businesses manage their data collection. As the primary designer of the Publisher-Listener API, I will go through a couple of the most common behaviors relevant to your marketing framework and tag management implementation: polling and interrupts.
 
 
What’s the difference
In computer science, there are two terms that represent different methods for determining the correct time for a piece of code to run:  “interrupts” and “polling”. Interrupts are signals that inform another piece of code, typically the operating system, that an event occurred and it needs to make a decision. When the signal comes through, the OS will stop what it is doing and perform the action requested. 
 
Polling, on the other hand, refers to a piece of code that continually monitors, whether it is a variable’s value or a single bit of a controller, to see when that piece of code can act. Your PC, for example, will keep checking for incoming data over and over until it finds data to process. This performance is extremely simple but inefficient.
 
If your eyes haven’t already glazed over, you might be asking yourself, “You mentioned signals being superior, what’s the deal with that?” Allow me to illustrate with a real-world example.
 
 
Why you hate polling, even if you don’t know it yet.
You’re in a car driving to a far-off vacation spot.  The journey is several hours, but you’re an adult. You enjoy casual conversation, listening to music, a book on tape (or I suppose they’re called “audiobooks” now, since anyone younger than 16 would probably wonder why you would write a book on a rolled up strip of adhesive), or just admiring the scenery. The point of the journey is not to arrive, after all.
 
Except for your children.
 
Your children are sitting in the back seat, and they are B-O-R-E-D. They’ve listened to the same song a thousand times, they’re hungry, the world outside of their window is boring, they’ve found a license plate for all 50 states, and there are no more bottles of beer on the wall. They think years of their life have gone by already, so you must be near your destination.
 
“Are we there yet?”
It begins.  Asking the question does not speed up the journey. Answering the question doesn’t either, but you do it anyway.
“No.”
“Are we there yet?”
“No…”
“Are we there yet?”
“NO.”
This is polling: the act of asking the same question over and over and over and over again until you receive a nice, comforting “yes.” Wouldn’t it be easier if the children simply waited for you to tell them when you have arrived?  I think so, and that’s precisely what a signal does:  it lets you know that it’s time.
 
 
You’re right, I hate polling… why does this matter again?
Let’s look back at what it takes to track information from a web application. Odds are you have some sort of JavaScript running on the page that executes to collect information and send it off to be analyzed and subsequently reported. That JavaScript runs at a particular time and depending on your implementation, it might run synchronously on the page, it might be loaded asynchronously, or it might be loaded at a specific time via tag management.
 
Often, you don’t know precisely when that JavaScript is going to execute on the page relative to the rest of the page load process. Sure, the tag management system, or your favorite JavaScript framework, might provide hooks into some events that say when the DOM is ready, or when the DOM is loaded, but what if you have a dynamic application? What if a button generates new DOM that contains information you want to track in a virtual page view? Your JavaScript has to ask a horrifying question:
 
“Is it there yet?”
“Is it there yet?”
“Is it there yet?”
 
Enter: the Publisher-Listener API
In essence, what the Publisher-Listener API provides is a mechanism to drive signal-based tracking on your dynamic site, or your mobile application, or your standard website. The API lays the foundation for your developers to make a single additional function call in the core functionality of your site that simply says:
 
“Hey!  Something happened!  Here is some information about it!  Ok, bye!”
Based on the information sent in a simple JavaScript object, you can do whatever it is you want with that information. Perhaps a drawer expanded, revealing additional product impressions or a modal just loaded with new dynamic interactions to track. With the appropriate signals in place, you can control everything about what your tracking does from any tag management solution. You can very easily turn tracking on and off for different components, or even turn off tracking just for certain tools, leaving it in place for others. Instead of worrying about all of the nuances of making sure your logic to locate elements in the DOM to parse or bind event listening is correct, all you worry about is what your analytics code does with the information it is given, and you can be confident that it was given that information at just the right time.
 
So instead of the children asking “Are we there yet?you simply tell them when you arrived and they respond accordingly. 
 
 
I have questions, so many questions…
Odds are you have questions. I’ve asked myself many over the course of refining the API’s core functionality, and clients have asked even more. You can read more about the Publisher-Listener API framework HERE and with any luck I’ll put more blog posts out about the advantages of this integrated framework. But if you have any questions, feel free to leave them in the comments or send them to us directly at info@stratigent.com!
 
 
 
 
 
By Adam McArdell
About the Author:

Adam McArdell is a Senior Technical Consultant at Stratigent.

Contact Us Now