Third party impression tracking is almost mandatory now in digital advertising while almost wholly ignored in podcasting. When implemented in podcasting, we can often see significant impression discrepancies between ad server and tag vendor, without a clear understanding of why. This post outlines this issue and presents a solution for solving this problem for good.

What type of impression tracking tags are supported

If you choose to move forward with third party tracking in podcasting, there’s a real low bar for what the tag vendor needs to provide you with:

A URL tracking tag for impressions

This is simply one pingback URL, not javascript, iframe, VAST, and definitely no clickthrough tags (because there are no clicks in podcasting).

Impression tag, not download

Make sure your vendor provides you with an impression tracking tag to be fired through your ad server in association with the ad and not a download tracker, associated with a specific episode. Download tags have a different but valuable function, they’re just not focused on your specific ad, but rather downloading the entire episode.

The ability to ingest IP

Using a tracking pixel without receiving an IP address provides zero value. Everything is fired server side and not on the podcast listeners device. That means you’re already limited on what information you received and the case for the value of using a tracking tag greatly diminishes. If the tag vendor ingests the forwarded IP from the listener that means they can take that value and match it against their device graph, or an invalid traffic filter, and definitely against geographical lookup. Without receiving IP, you are paying a vendor to simply echo the number of times it was fired without any bit of intelligent thought applied. DCM tags are a prime example of this.

What you’re not going to get in podcasting

Short list above for what does work, right? It’s a double edged sword unfortunately. While the world scrambles to adapt to a future without cookies and IDFA’s, Podcasters are still being asked for more data. Here are some of the data points no vendor is going to be able to provide you directly.

Mobile Ad ID’s (MAIDs)

No podcast request receives the MAID from the end users device. That doesn’t mean that you can’t get an MAID from a vendor, it’s just that it did not come directly from the listener or the podcast playing app (which, by the way, 100% has it and just doesn’t share it.).

Tag vendors often use device graphs like TapAd, Tru Optik, Claritas, and others to take the IP and user agent to identify all the MAIDs in a household. This data is far more valuable when you acknowledge you’re not tracking specific listeners, but rather their household.

There are some caveats with this methodology:

• Cellular — IP can’t resolve to anything valuable, as some providers with throw millions of users through the same IP.
• Office — Anyone connected to that same network that matches the same IP and user agent.
• Home— Anyone in your household, connected to the same wifi, with the same user agent. If you bought your family all iPhone 11’s last year for Christmas and everyone uses Apple Podcasts, you look identical.
• Add in a healthy fear of CCPA/GDPR regulation and you may reconsider if you really want to pay for these values from a third party. If you do need data like this, consider laying out the entire process of why you need it. Data isn’t a land grab. Tag vendors often have integrations with other platforms for things such as retargeting, without you having to directly receive MAIDs yourself.

Listen Metrics

Your podcast ad server knows the following:

• A request was made for information about the episode by the listener.
• The listeners IP address and user agents.
• A request was made to download/stream the episode by the listener.
• The download/stream request downloaded X bytes out of the total episode.

Everything focuses on downloads. Even an impression in podcasting is really “was enough of the episode downloaded to have passed where the ad is in the file?”.

For your podcast ad server to get listener metrics, the podcast players would need to respond back with that information. Apple, Spotify, etc all have that information, there’s just no standard for them to send it back. NPR has a really great framework that unfortunately isn’t getting the adoption it needs, called Remote Audio Data (RAD), that would solve for this. Spotify and Apple are just not going to integrate with that as Spotify doesn’t benefit from sharing it and Apple isn’t selling ads, so there goes 90% or more of the ability to see listeners. But we as an industry should be asking those remaining 10% to integrate.

Fully informed about the pitfalls facing you, let’s dig into when you should use tracking tags.

Consolidating Reporting

If your goal is to utilize a tracking partner like DCM across all your media for the reporting, then you’ve got only two choices.

Google’s DCM states clearly in their troubleshooting docs that discrepancies up to 20% are considered acceptable . Wild, right? It gets worse when you realize that Google only shares their numbers after filtering (net), so good luck even confirming if the ad server is firing the pixel enough times let alone why it’s removing impressions.

Overall, DCM removes most tools for troubleshooting, but they also have a higher privacy tolerance in podcasting, asking for the last octet of the IP address not to be shared with them when firing their pixel for certified partners. With DCM, my experience tells me that it’s straightforward to get less than a 3% discrepancy on DCM. Still, when discrepancy spikes, and I assure you it eventually will, you’ll have to accept that sometimes you won’t have enough information to resolve it.

If DCM is just your passthrough for a consolidated reporting portal, I highly recommend you ask your podcast ad server if they can provide you reporting in the exact format you need to ingest into your reporting platform. Provide them with a clear template and I think you’ll be pleasantly surprised at the headache you’re able to avoid and the margin you’re able to save while also hitting your goals.

Deeper Learning

Podsights, Chartable, Barometric, and Podtrac are focused on providing way more than just a verification that your ad server says they served the impression. In fact, Podsights and Chartable both confirmed that they don’t actually filter on gross fires of their pixel for that exact reason: they’re not here to bicker about discrepancy with your ad server, they’re trying to provide deeper insight.

These partners are focused on analytics and attribution along with being built from the ground up for podcasting. In my experience, I’ve never been asked to bill off their numbers which aligns with few of them filter out any of the fires received by the podcast ad server.

But if they’re not filtering and everything is fired server side, how is their discrepancy?

Your podcast ad server will take time to vet an impression before reporting it in their first party numbers. For a podcast to be played on the listeners device, there are multiple requests involved and not all of them count as impressions or even a download. The IABv2 specifications focus on counting an impression once it confirms that for a given episode, in a single day, the IP/user-agent pair has downloaded enough of the podcast file to pass where the ad is located. It can take some ad servers upwards of one hour from the time of receiving the initial request to validate it internally and then fire the third party tracking pixel. That delay alone can result in impressions for the ad server being counted on day one, while the vendor shows them on day two.

How To Solve Discrepancy

Discrepancy matters because every impression lost down the funnel is one less piece of insight you can glean off of it, regardless of how you choose to use it. In digital, getting to zero discrepancy is just not going to happen, but we have all of the tools right at our disposal to make it happen in podcasting.

If your ad server passes the following two values to all third party tags, and the tag vendors properly ingests those values, we could see the discrepancy drop to 0.

Unique Identifier

Super simple, super effective. It’s adding a macro to every pingback that looks like uid={uid} to the tag URL. UID or Unique ID should focus on the ad servers unique identification of what makes that specific download unique in their methodology and not necessarily anything to do with a unique user.

If I count 100 impressions as the ad server and you count 75 as the vendor, how do we resolve that? Easiest way to do it is to match them up and see what we can learn about those 25. Without a value uniquely differentiating each of the 100 fires from each other, there’s no way to know which 25 didn’t fire to start digging in. Unique Identifier doesn’t have to be a new value, it just needs to solve this problem when expanded further: Can I compare 1 million impressions together and identify the 100k that are not firing?

This macro solves for the times when a tag fails its call or the ad server fails to make the call. Nothing is perfect, but this helps streamline resolution of the issues.

Timestamp of Impression

Another straight forward fix. Honor the timestamp passed by the ad server, to the tag vendor, as the exact time of the impression. Many vendors already offer a timestamp or ord parameter in their tag so the work here would be on the ad server to confirm the data is sent correctly.

As everything is handled server-side for your third party tag, your ad servers timestamp of when the impression occurred will state the exact time the impression happened even if it took it an hour or two to determine it was valid. If we’re already accepting the ad server is firing the tag when they count the impression, and that they’re forward the third party the listeners IP and user agent, why wouldn’t we accept the timestamp as accurate and match that exactly between ad server and third party vendor?

Wrapping It Up

We collectively own all the tools to resolve this, restoring numerous hours back to our engineering teams and account managers, by accepting that this is not digital and everything is fired server side. The more we lean into the differences in podcast ad tech like this, the stronger the space becomes.