Five sides to the story, can you guess who's not telling the truth?
This is based on a true story - Let me know if you've experienced something like this or have something to add. I'm always keen to learn something new.
The story
From every end, publisher to ad server, the frequency is either being controlled or measured. Our user however has seen an advert several times within about an hour. When measured, everything appears to be within our target frequency; 1.6x over the past 9 days however something has gone awry. So what's happening with the user who's seen it five times in less than an hour?
Let's go through those who have played a part in this mystery and give you the lay of the land. Programmatically, there are several parties involved with getting an ad to a user.
The usual suspects
Here's an extremely simplified diagram detailing the end to end experience from User to Adserver. The little arrows are reflective of who passes the details between one another. These are in order. The dotted line is reflective of the ad being passed from the ad server to the user.
When a user is consuming some sort of content and is about to see an ad, they will either have a unique ID associated with their device or one will be assigned to them. This can be done from the publisher, the SSP, the DSP, or the ad server. Most of the time, the publisher is responsible for this component as they're the closest to the user.
This unique ID is what unique impression ID's get associated with, to know how much value an impression has had in the path to conversion. It's the critical component to attribution - otherwise you wouldn't be able to tell the difference between user A or user B. Another critical component that requires this unique ID to be one per user and unique is frequency control. That is, the number of times before you see an ad.
There can be several factors that can be involved with frequency control breaking down - you know, when you're trying to watch something and all you get is the same ad over and over again? Here are a few of those reasons.
Things that can break frequency control
- Frequency is being controlled by cookies and a user clears their cookies or blocks cookies entirely.
- The advertiser hasn't added a frequency cap.
- Unique ID's aren't being assigned correctly.
Quick to blame and absolve themselves of responsibility are the parties responsible for controlling the frequency - once you look beneath the hood you understand that it's the party that generates the ID who is letting the process down. But who exactly is that?
My hypothesis
After speaking with each party involved and getting nowhere, I have used my technical imagination to come up with this potential cause. A unique ID is being generated at the beginning of the session and has a concatenated impression ID which is intended to provide the placement ID back. This lets you know which placement you're getting; pre-roll or mid-roll. This placement ID isn't being separated from the User ID string and each is being counted as a unique user.
Here are some numbers to make a bit more sense of these. I've just made them up, unique ID’s & impression ID's are different to a randomly generated hex ID.
780d65e27424b9a739d2, 780d65e27424b9a77bbc5, 780d65e27424b9a716b
The party issuing the ID has associated this ID to the user: 780d65e27424b9a7. All the other parts with the underline represent the impression ID. When this gets generated and passed back, without removing the last four digits, every other provider using this as a unique ID sees each as unique and thus are unable to control frequency.
Where we are now
Basically every party has been passing the blame back to the other, all the way to the user. This can not be the case as the ad call is coming from within an app, and provided with the device ID so it's free from cookie controlled frequency. After we resolved this the first time, added frequency control at all levels not just the DSP (which is quite an unusual thing to have to do), we saw the same thing happen within a matter of hours. We picked this issue up with one publisher in particular. Is this an example of ad fraud or just a technical limitation?
My mind is made up as to the next steps we'll be taking to resolve this and booking this in the future but I still want to get to the bottom of what is happening from the technical end.
What are your thoughts? Which party is responsible for this happening and when will ownership be taken rather than pushed around?
Marketing, Media & Ad Tech Leader
7 年Not always true re publishers, they rarely apply an fCap in programmatic. It's the DSP that usually applies the frequency cap, as long as they can accurately associate a unique ID then they will not bid on the same unique ID if the frequency cap set has been hit. The only time you would really rely on publisher or SSP is if the DSP didn't apply an fCap. And the reason it might be 'broken' is it's not always possible - clearing of cookies, incognito browsers, in-app, connected TV all vary. Simply put: technical limitation!
Digital Investor | Acquiring & Scaling Online Businesses
7 年Looking forward to seeing what you uncover! We have had the same thing happening on certain clients and personally watching CUTV is a painful experience when advertisers/ media cannot get frequency capping correct!
Consulting Director at KlewdUp
7 年Nice post Victor Condogeorges interested to see what your investigations finds