Sugar Highs with SpringServe

In our latest release we discuss expanded reporting for domain by geo, and additional sizes. We also discuss new KPI targeting metrics, macro additions, and UX improvements.

Core Improvements

Domain by Geo Reporting

By popular request, we have released Domain by Geo reporting. Geographical regions are broken out into the following:

  • United States (US)
  • Canada (CA)
  • Great Britain (GB)
  • Europe without Great Britain (CEU)
  • Asia (CAS)
  • Africa (CAF)
  • Central and South America (CSCA)
  • Oceania (COC)
  • Antarctica (CAN)

A CSV with the country-region mapping can be found on our wiki.

Hourly domain/geo data is available for the last two days. If you foresee the need for this data beyond this period, we recommend scheduling daily reports for yesterday and archiving them. Please see our wiki for more information about scheduling reports. We welcome your feedback during this initial release of this expanded reporting.

Expanded Size Support

We have broken player sizes into two additional classifications: extra small and extra large. In SpringServe, size is based on width and defined as the following:

  • X-Small: <250 pixels
  • Small: 250-349 pixels
  • Medium: 350-500 pixels
  • Large: 501-799 pixels
  • X-Large: ≥800 pixels

Reporting by declared and detected size will show X-Small and X-Large. This data is available from October 13, 2017. Prior to this date extra small and extra large sizes are included in small and large size reporting, respectively.

This further granularity will allow you to see when your partners are sending you possibly undesirable inventory. You are also able to target including or excluding these sizes.

Note that tags created prior to October 15th target extra small if small players were targeted and extra large if large players were targeted.

Reporting Improvements

Moat Data in Report Center

In the metric section of the create reports page you will now see selected Moat metrics. Consolidating metrics into one report will reduce your workload, allowing you to spend less time navigating between reports and more time optimizing. These metrics include the following:

  • Moat Imps
  • Moat Human Imps
  • Moat Bot Imps
  • Moat Human %
  • Moat Bot %
  • Viewability %
  • AVoC %
  • GroupM Viewability %

Note that Moat data is not aggregated on the declared size or country level. These fields will be unknown for rows where Moat data is reported. This data is available on the main reporting page for periods beginning October 2, 2017. You can get data for periods prior to this date by running reports in the Traffic Quality report center.

Full Moat reports are available in the Traffic Quality report center. On this page, you can still access the following metrics:

  • Detected dimensions
  • Mismatched Domain %
  • Visible on Complete %
  • Hover %
  • Fully on Screen %
  • Human and Viewable %

API Updates

Label by domain reporting is now supported in the reporting API. As in the UI, this data is available for the last two days.

Sorting on asynchronous reports is now available; include these two parameters when making your request:

  • async:true
  • sort:[“<metric_name> <desc or asc>”]

The response will show the number of pages in the report and the first page of sorted data.

Objects now have a created_at timestamp.

Feature Additions

KPI Targeting Metrics

Different demand sources may require different optimization strategies. Some may require high viewability, others may want high fill or completion rates. Moat Viewability has been available for targeting in the platform, but now you can select from four additional KPIs for campaign targeting:

  • Moat Viewability Rate
  • Moat GroupM Viewability Rate
  • Moat AVOC Rate
  • Demand Tag Fill Rate
  • Completion Rate

When KPI targeting is enabled on a campaign, enter your goal in the text box below your selected KPI.

KPI targeting is available on the campaign level. Associate your demand tags to campaigns with KPI targeting in order to use this feature. If the supply does not historically meet the KPI goal requirement, the request will not be passed to any demand tag that has KPI targeting enabled. You can use reporting to determine which supply should be aligned to KPI-targeted demand.

Demand Partner Revenue Budgeting

Budgeting has long been available for your SpringServe demand partners, campaigns, and tags. We have added the ability to target based on Revenue on the partner level. Pacing options are available for any type of budget. Enter your budget in dollars in the text box.

You may have a number of tags for a partner that all have different rates. Using Revenue budgeting on the partner lightens your workload in converting impressions to revenue.

Macro Additions

Real-Time Visibility

SpringServe can now detect the visibility of a player in real time for JS VPAID supply tags on a supply opportunity. A new macro, {{IS_VISIBLE}}, can be used to pass whether the player is visible to demand tags. {{IS_VISIBLE}} passes the same values as the {{MOAT_VIEW_BINARY}} macro:

  • 1 when the player is visible
  • 0 when the player is not visible
  • -1 when visibility is unknown

Visibility is defined very similarly to the MRC standard for viewability (active browser tab, 50% of the player pixels in view, etc.), just without the ad timing requirement (since this is sent to demand tags before an impression).

This macro can be used in AOL TbV tags.

Passthrough Macros

With the influx of mobile and CTV inventory, you may have demand partners asking for additional macros to be passed to them. If your demand tag’s endpoint URL contains an unsupported macro, you can use passthrough macros! Passthrough macros simply look for the matching query string parameter in the ad request and fill in the value with what follows the equals sign.

For example, if you have a demand tag that requires appVersion, the endpoint URL may contain appVersion=[APPLICATION_VERSION]. SpringServe does not have a designated app version macro, but you can follow these steps to use a passthrough macro:

  1. append &appVersion=[APPLICATION_VERSION] to your supply tag that you export to your supply partner. You will need to do this for any supply that is selling to this demand tag.
  2. replace [APPLICATION_VERSION] in the demand tag endpoint url with {{QP_appVersion}}

SpringServe will see QP_ in the endpoint url and look for appVersion= in the request. In this case, appVersion is the query string parameter and whatever follows the equals sign will be passed through the macro. Note that your supply partner must replace [APPLICATION_VERSION] with their own supported macro in order for the value to be passed through.

UI Improvements

On a managed supply tag, you now have the ability to add or remove all macros within a section with one click. When you click Add or remove All in a macro section, the export tag will automatically update. Updating the export tag will ensure that you are ready to get all relevant information from your supply partner. Once you send the exported tag to your supply partner and they have implemented it in their system, they may need to update the macros.


SpringServe in ads.txt

SpringServe fully supports the IAB’s ads.txt initiative and its goal of increasing industry-wide transparency between buyers and sellers. With increasing adoption of the ads.txt initiative by a number of buying and selling platforms, we encourage all SpringServe clients to implement ads.txt on their domains and any domains with whom they work.

We have included instructions about how to add SpringServe to an ads.txt file below:

Owned and Operated Domains, {{ACCOUNT_ID}}, DIRECT, a24eb641fc82e93d

Resellers, {{ACCOUNT_ID}}, RESELLER, a24eb641fc82e93d

Replace {{ACCOUNT_ID}} with your SpringServe Account ID; this ID can be found in the lower right hand corner of the browser when you are logged into your SpringServe account. In the example below, CrushTown USA has Account ID 17.

Bug Fixes

  • We have released a fix to updating targeting profiles in the API
  • The optimization defaults in Basic Settings now update properly
  • Domain mismatches are no longer recorded when the only mismatch is declared domain including prefix “www.”
  • Fix to buying demand tag bug
  • Ensure demand pixel encoding is UTF-8

Leave a Reply

Your email address will not be published. Required fields are marked *