Competitive exclusions targeting, global frequency cap improvements, and updates to the UX and reporting.
Targeting on Demand Tags
For demand tags behind a pod supply tag, you can now use advertiser domain lists to apply competitive exclusion targeting.
When SpringServe selects a demand tag with competitive exclusions for a slot in a pod, we will block any demand returning an excluded advertiser domain from subsequent slots. Note that competitive exclusion targeting only applies to demand that returns an advertiser domain in the VAST response.
If a competitive exclusion targeting blocks a demand tag from selection, SpringServe will fire a VAST error code of 1639.
A snowflake icon indicates competitive exclusions targeting on index tables. Hovering over this icon reveals the targeted advertiser domain list(s).
Override on Supply
If multiple demand tags implement competitive exclusions targeting, a potential side effect can be a large reduction in the amount of eligible demand for remaining slots, thereby reducing pod fill. SpringServe therefore gives you the option to override competitive exclusions targeting on any underlying demand. To do so, select Enabled in the Ignore Advertiser Domain Targeting field on the Pod Settings tab of a pod supply tag.
Note that when you enable this setting, SpringServe will do the following:
- ignore competitive exclusion targeting on underlying demand
- all duplicate creatives
- ignore advertiser domain targeting on the supply tag.
Global Frequency Caps
When targeting using a global frequency cap pixel, you can now set a different period on the targeting object from the period on the pixel. For example, if you have created a pixel with an expiration period of 12 hours, you can create a frequency cap on a demand tag of 1 per user per 45 minutes.
The period on the targeting object must be smaller than the period set on the pixel. Note that ineligible periods will be disabled in the UI. In the image above, you can see that the Day option is disabled because the maximum period for this pixel is 12 hours.
Server Side Header Bidding
Cookie synching allows us to now support server side header bidding in desktop environments. Please talk to you account manager for additional information.
Quickstats and Graphs
For supply objects with pod fill, we now display pod opp time on the sunburst graph. This graph shows the available time in the pod, the time returned by demand in the pod, and the time of filled impressions in the pod.
You can also view this sunburst graph on the supply dashboard for aggregate statistics across your account.
SpringServe displays budget bars in the quickstats panel. These progress bars have improved readability now that the background color is darker.
Performance graphs appear throughout the platform and they display usable requests, impressions, fill rate, and pod time fill where applicable. For supply objects, the primary y-axis label now displays the impression values rather than request values.
Index Table Usability Improvements
Objects with flight dates that have passed will not be called due to not passing targeting, therefore we display these dates in italics to indicate inactivity. Flight dates now exclude the hour, as all flight dates run to midnight UTC.
You can view the deletion icon in index tables when toggling to the full view. This change makes it less likely to accidentally start deleting an object when intending to run a report.
When hovering over the VAST endpoint url column the entire url now appears, reducing the need to click in to the settings tab to assess potential missing parameters.
On supply tag index table, you can now filter by pod setting, making it easier to separate your dynamic and custom pods, as well as your non-pod inventory.
VAST Responses Metric
When running demand reports, you can now select VAST responses from the Response Metrics section.
This metric reflects the number of VAST responses returned by a demand tag.
Log Level Data
Where allowed by GDPR and CCPA restrictions, SpringServe now reports unhashed IP addresses and device IDs in log level data. Hashed IP addresses and device IDs are always reported when available, independent of the GDPR or CCPA parameters.