Also see: Working with Third-party Creative Trackers.
Third-party trackers/tags (we'll just call them trackers from here on) are used to confirm the validity of ad traffic delivered by an ad server, and also to augment the ad server's proof-of-performance impression data with richer data generated by the tracking company. In both cases the tracker is a bit of code that is attached and fired from the location that is inserting the ad. The code's execution can be as simple as returning a confirmation that the ad was delivered, or it can include the placement of a cookie for future ad tracking.
Triton's advertising platform supports ad trackers, and we allow them to fire in the location where we insert the ad. For on-demand ad requests that are inserted by the player, ad trackers should work as expected. In podcasts and live streams, however, the ads are inserted in our data centers where significant limitations and challenges with ad trackers are introduced. This article will go through those challenges and how to get around them.
A short history of ad trackers
Ad trackers were originally designed to be used within browsers on web sites. They were used for both display and video ads, where the ads would be requested by the browser via ad tags delivered by companies like Google. Since the ad was being managed by the web browser, the associated ad tracker could leverage all of the browser's capabilities.
Additionally, as the ad was requested by the browser at the user's location, the basic components of the listener's internet connection were accessible directly. Things like user agent, IP address, and the ability to drop cookies were all tied to the user's browser settings. This enabled ad trackers to do sophisticated things; essentially anything a web page could do, an ad tracker could do. The digital ad industry began using ad trackers to filter out things like fraud, confirm the actual delivery of the ad, and also confirm components of the ad buy like location and even behavioral components. Data management platforms (DMPS) were also integrated into trackers to utilize ad delivery for data enrichment.
As mobile ad delivery became more prevalent, the ad tracker was integrated directly into ad code used by mobile apps, providing a similar set of capabilities as found with a web browser.
One common thread in all of the above – display, video, mobile – is that the ad trackers were called directly from the user's application, whether it was a browser or a mobile app.
A short lesson on server-based ad delivery
Audio live streaming is done in real-time with a standardized platform that works in a wide variety of players, such as web players embedded in a browser like Chrome, audio desktop applications like iTunes or VLC, mobile platforms like Apple Carplay or Android Auto, smart speakers like the Amazon Echo or Google Home devices, and even TV set-top boxes like Roku. In nearly all of these instances, the player of the audio does not support the direct request of ads.
This means the entire advertising model for display and video is broken when it comes to audio. For example, you cannot place a tracking image pixel in an Amazon Echo device… it has no screen! Complicating things further, the player has to actually support ad placement, before we even get to ad trackers. Many locations do not allow the placement of ads at all. This includes some of the most widely-used distribution points for audio, such as Apple Podcasts for podcasts and smart speaker devices for live audio.
The solution is to include the ads as part of the audio content. Thus, a player like Apple Podcasts will download the audio for users to play, and that content already includes the advertising stitched into it. This gives digital audio a huge advantage over all other digital-based content, primarily because it does not require the permission of the player to include advertising. So, while you will not be able to include digital display advertising in a podcast on Apple Podcasts, you can include audio advertising.
This is where Triton Digital's advertising platform (Tap) comes in. Tap takes the audio content in our data centers and inserts the advertising into it. When the player then requests the content, our data centers send the content with advertising included. To make things even more powerful, Tap looks at the data sent from the player and can dynamically target advertising with each user listening experience. Thus, for example, while display advertising can't even be used in an Amazon Echo device, Triton Digital empowers targeted and real-time advertising in that same environment.
What does this have to do with trackers?
The basic challenge is that for streaming and download audio ad delivery, the ads are inserted in our data centers rather than the listener's browser or app. As ad tracking companies are almost universally focused on tracking display advertising, they have difficulty understanding the limitations of server-based ad delivery. They will often say things like "the cookie my tracker drops is not working" or "the IP address of the tracker is showing Montreal and not the listener's location in St. Louis."
Let's take a closer look at some of these problems.
Common issues with ad trackers
"We are not able to place our cookie."
The ad tracker is fired in our data centers, and we do not allow cookies to be dropped on our servers, so this is expected. Furthermore, it would make no sense to drop a cookie there. The goal of a cookie is to track an individual user. Having a cookie on a streaming server will do nothing useful. In this instance, the issue is educational: the tracking company needs to understand that cookies are not supported in a server-based advertising environment.
"None of our tracking elements are working."
As noted earlier, trackers are primarily used in web browsers, and are based on the HTML web standards. As a result, they are built with the assumption that the variables in all the tracker company's trackers will be natively supported. However, as the ad trackers in downloads and streaming are not fired from a web browser, but rather from our servers, these variables will not work.
The good news is that Triton Digital understands this challenge and provides macros for the tracking company to use. A macro is a placeholder that the tracking company can put in the ad tracker, and Triton Digital uses its connection data from the player to insert it into the ad tracker. An example is the macro for "user agent." If the tracker company places %%USERAGENT%% in their tracker, Triton Digital passes the user agent information from the player to the ad tracker.
In this way, an ad tracking company can use data from a player like an Amazon Echo device, whereas this is impossible in any other scenario.
You can find out more about our supported macros in the TAP User Guide: Using Macros
"Our tracker flagged all of the advertising as fraud."
This is usually because the tracker company has blocked all server-based advertising. Tracker companies do this as a way of combating bogus display advertising traffic from click farms and servers that send fraudulent traffic. It's easy enough to fix; the ad tracking company simply needs to allow (or unblock) the Triton data centers. For example, Google does not block our data centers, and their ad trackers work as intended.
"Your ad server is telling you that the advertising was in a specific geographic location, but our trackers are showing them all in Montreal (or Los Angeles, or another data center location)."
Internet location is usually assessed by a listener's IP address. This has some limitations, but it is widely supported. For ad trackers, the IP method of assessing location is very common.
While our data centers are not web browsers, they do support basic internet standards. So ad trackers that are fired from our data centers will include an IP address, which is the TCP/IP address included in pretty much all Internet communication. However, this is not the IP address of the listener. As a result, the tracker mistakenly uses the TCP/IP address of the server as the location and not the address of the listener we send via our macros.
The solution is straightforward; the tracking company needs to support an IP macro so they use the location of the listener, not our data center.
"My tracking company says supporting Triton will require dev work on their side and they won't do it (or it will take a long time)."
This is due to macro support and is the response of display and video ad tracking companies with no experience on broad distribution digital audio. For example, they have never tracked ads on an Amazon Echo device so they are not prepared for it. There is unfortunately no solution here other than for the tracking company to do the work or for the client to change tracking companies.
"Does Triton support [insert tracking company name]?"
Triton supports ad tracking code, so the answer is yes. We most likely support the ad tracking company you're inquiring about, as ad tracker code is usually standardized for use across apps and browsers. However, the real question is: Will the tracking company support server-based advertising? Each tracking company has different capabilities. We would recommend you talk to the tracking company and ask them about their support of server-based advertising and macros. If they support them, or are willing to integrate our macros, the odds are good that the trackers will work.