Introducing inventory routers, improvements to pod reporting, supply and payment chain, and additional account defaults.
Feature Additions
Routers
SpringServe has developed routers, a new feature which gives you even more control over your inventory. Routers allow you to control the distribution of requests between multiple supply tags. Sitting between supply partner and tag in SpringServe hierarchy, routers are available in tabs displayed on the main supply page and on a supply partner’s page. On these tabs you can access existing routers and see their targeting and quickstats, as well as create a new router.
Setup
Setup for routers is similar to supply tags: set name, environment, pixels, and notes on the Settings tab; expand the Advanced section to reveal Keys. You can set IVT options on the router or the tag level. Selecting Router in Verification Settings will allow you to set pre-bid and post-imp options for any request flowing through the router. If Tag is selected, apply verification settings on the tag level.
Like all other objects in SpringServe, targeting can be set on a router. Any request that goes to the router must pass targeting on the account, partner, and router level before it is eligible to be passed to a supply tag.
In the Supply tab of a router you can associate supply tags with ratios to define the inventory split. For example, if you set tag A at 1 and tag B at 1, you will have a 50/50 split. You can see the weights of 50% in the Weight column of the table.
SpringServe will split requests between the tags in the router after applying supply tag targeting. For example, if A is targeting US and B is targeting CA, a request from US will go to A 100% of the time.
For any supply tag within a router, you can specify a fallback supply tag. If the request to the original supply tag does not fill, SpringServe will send the request to the fallback tag.
Reporting
Analyze real-time data via quickstats summaries and using the reporting UI. Include router as a dimension or a filter to select the following metrics:
-
- Router Total Calls: all usable router requests + platform, account, supply partner, and router targeting blocks + pre-bid blocks (only when pre-bid is set on the router level)
- Router Requests: usable requests that passed targeting on the platform, account, supply partner, and router levels
- Fallback Requests: requests that went to a fallback supply tag within the router
- Router Missed Opps: usable router requests for cases where no supply tag met targeting or all supply tags have ratio of 0
- Missed (Targeting): usable router requests that did not go to a supply tag because of tag targeting
- Router Usable %: ratio of usable router requests to total router requests
- Missed % (Targeting): percentage of usable router requests that were not passed to a supply tag due to supply tag targeting
- Router Opp %: ratio of Opportunities to Router Usable Requests
- Router Req Fill %: ratio of Impressions to Router Usable Requests
Use Cases
Routers in SpringServe are simple to use and report on and can serve multiple purposes:
- Inventory splits: deals with OTT infrastructure providers often call for a certain split between the platform and a channel. Routers allow you to accomplish this split with ease.
- Custom ad experiences: control custom ad experiences based on supply tag targeting, which allows you to set different waterfalls based on the user.
- A/B testing: set equal ratios between identically targeted supply tags to see how different demand stacks compare.
If you would like to beta test routers in SpringServe, please contact your account manager.
Core Improvements
Pods
Unfilled Slot Opt-Out
Normally when calling a pod tag SpringServe will return all ads provided by the demand stack even if there are still empty slots. In certain cases you may want to return empty VAST if there is one or multiple empty ad slots. When Unfilled Slot Opt-Out is Enabled, set the maximum number of unfilled slots that are allowed in the pod. If this value is 0, SpringServe will return empty VAST if the pod is not fully filled.
VAST Error Codes
We continue to increase the robustness of our VAST error code reporting to allow for better troubleshooting:
- 1627: Pod slots full
- 1628: Ad duration greater than pod time unfilled
- 1629: Ad duration greater than slot max
- 1630:Ad duration less than slot min
Targeting Additions
Canadian DMA targeting is now available in More Geo Targeting.
WhiteOps IVT Rate is now available as a KPI target for CTV tags.
Additional schain and pchain support
Supply chain objects can now be passed into the supply tag url through the “schain=” parameter. Additionally, the supply chain object and payment chain string specified in the supply tag url will be passed to any header bidders that accept these parameters. For more information, please consult the wiki.
UI/UX Improvements
New Account Default Settings
On the Default Settings tab of the Basic Settings page, you will now find additional fields:
- Supply Environment & Demand Environment: set the default environment for new managed supply and demand tags. If your business operates primarily in a single environment, you may want to update these settings. This setting will only affect new tags.
- RPM Floor Margin Default: The default value of this field is 20%. This setting will update the RPM Floor Rate on supply tags. On the waterfall tab of a supply tag, demand tags that fall under the RPM floor rate will be highlighted in red.
DC Connection Notifications
New connection approvals will now appear in the notification bubble upon login. If your DC partner has approved your request in the last 2 days, the notification message will appear so you know that you can start creating connected supply or look out for connected demand.
Reporting Improvements
Pods

- Pod Avail Time: number of possible ad seconds to be filled. This value is based on what is set in the UI or passed in a macro
- Pod Opp Time: number of ad seconds that are returned in the pod
- Pod Fill Time: number of ad seconds that had an impression
Comments are closed.