Advertiser Domain Deduping is now available in SpringServe if you have turned on the Advertiser Domain Deduping beta feature. This feature allows you the option to choose whether or not to allow demand sources with duplicate advertiser domains in the pod response when running your pod inventory.
Once this feature has been enabled for your account by your Account Manager, for any pod-enabled supply tag, in the Pod Settings tab, under the Advanced Section, you can choose to enable this setting. Note that this setting applies only when a Dynamic or a Custom Pod is selected and when duplicate creatives is set to blocked in the UI. This is shown in the screenshot below.
To enable blocking duplicate creatives, select Blocked in the Duplicate Creatives pillbox. This setting is set to allowed by default. To enable blocking duplicate advertiser domains, select Blocked in the Duplicate Advertiser Domains pillbox. This setting is set to allowed by default.
Given that advertiser domain and creative de-duplication can have the undesired side-effect of restricting multiple demand classes from serving in a pod, publishers run a very real risk of pod fill being negatively impacted by pod deduplication. To address this potential concern, there is a setting on all pod-enabled supply tags called Ignore Advertiser Domains as shown in the screenshot below:
It is set to disabled by default. When this setting is set to enabled, the AdServer will use the following settings for ad quality for this supply tag:
It will Ignore competitive exclusion targeting on underlying demand,
It will allow duplicate creatives,
It will ignore all advertiser domain targeting on the supply tag.
It will allow duplicate advertiser domains
To determine whether an advertiser domain is unique, SpringServe compares the advertiser domain that’s either returned in the VAST response of a demand tag or input in the SpringServe UI. When this Setting is set to Blocked, SpringServe will throw out responses from demand tags that return the same advertiser domain as another demand tag in the pod response. For the demand tags that get excluded from the pod due to their creatives being duplicate, the ad server will fire a VAST Error Code on the demand tag specifying that this was excluded from the pod due to the advertiser domain being a duplicate.
There are a few things to note about how this is treated in the AdServer:
Advertiser Domain Deduplication checks are case-sensitive.
We compare only the top-level domains during this check. So, as an example, the domains https://espn.com and https://espn.com/soccer/world-cup/schedules.html will be treated the same and this will fail the advertiser domain deduplication check in the AdServer.
Demand tags with no advertiser domain will be excluded from this deduplication check and always included in the pod.
In the SpringServe UI, clients have the ability to set advertiser domains on the Demand Partner and the campaign.
If this is set, we check for dupes on the DP and campaign advertiser domain on all the demand tags in the lower slots of the pod whether they belong to that campaign/demand partner or not.
Say, for example, that you have a 5 slot dynamic Pod CTV supply tag and duplicate advertiser domains are set to blocked and it has 7 demand tags in its waterfall. For each of the following demand sources, it’s evaluation in the AdServer is listed below:
Demand tag 1 - returns an advertiser domain of http://espn.com - eligible for slot 1
Demand tag 2 - returns an advertiser domain of http://cnn.com - the AdServer checks to see if this advertiser domain is a duplicate of advertiser domain from demand tag 1. Since its not a duplicate of above advertiser domain, this demand tag is deemed eligible for slot 2 as it passes the duplicate advertiser domain check.
Demand tag 3 - returns an advertiser domain of http://espn.com - here we check to see if this advertiser domain is a duplicate of demand tags 1 and 2. Since it is a duplicate of advertiser domain in slot 1, this is not eligible for slot 3 as it fails the duplicate advertiser domain check from slot 1, we discard this demand tag from the pod and fire an advertiser domain exclusion Vast Error Code here.
Demand tag 4 - returns an advertiser domain of http://msn.com - here we check to see if this advertiser domain is a duplicate of all demand tags currently present in the pod in the slots above this one, namely demand tags 1 and 2 and 3. Since the advertiser domain is not a duplicate of advertiser domain in slots 1 and 2, this is eligible for slot 3 as it passes the duplicate advertiser domain check from both the demand tags above.
Demand tag 5 - returns an advertiser domain of http://cnn.com - here we check to see if this advertiser domain is a duplicate of all demand tags currently present in the pod above it so, in this case demand tags 1, 2 and 4. Since it is a duplicate of advertiser domain in slot 2, this is not eligible for slot 4 as it fails the duplicate advertiser domain check. Thus, we discard this demand tag from the pod and fire the advertiser domain exclusion Vast Error Code VEC here.
Demand Tag 6 - returns advertiser domain of http://nbc.com - eligible for slot 4
Demand Tag 7 - returns advertiser domain of http://xyz.com - eligible for slot 5
Demand Tag 8 - returns advertiser domain of http://cnn.com - even though it fails the duplicate check, we don't fire the duplicate advertiser domain vec, we fire Vast Error Code 1627 because the pod is full at this point before we do the duplicate check.
You can run a report to get visibility on duplicate Advertiser Domains by having VAST Error Code as a dimension or a filter. This view is highlighted in the screenshot below.
This reporting view above is a useful way for users to troubleshoot occurrences of duplicate creatives and find error metrics specific to the duplicate creatives vast error, namely:
1672: Ad excluded from pod due to duplicate advertiser domain
You can find additional information on Vast Error Codes at this link.