Traffic

Use Cases for the Traffic API

Each entity in the Scope3 emissions model has data points that indicate how it receives, processes, and distributes traffic. Traffic flows will differ by country, environment, browser, and device type. The more granular these data points, the more accurate the model.

There are four key use cases that the Traffic API is designed to address:

• Publisher traffic volume
• Header/SSP traffic shaping
• DSP traffic throttling

Publisher Traffic Patterns

By default, the Scope3 emissions model uses third-party data sources (SimilarWeb and Data.ai) and proprietary tools to understand ad load behavior on the page, publisher traffic patterns, and avails.

Publishers, of course, have better data about their own traffic. Using the Traffic API, publishers and their ad technology vendors can share this data and improve the accuracy of the Scope3 model.

Header and SSP Traffic Shaping

Scope3 uses various assumptions, based on contributed and observed data, to model how traffic flows through the supply graph. For instance, it assumes that SSPs do some level of traffic shaping to downstream SSPs and DSPs, and that this shaping will differ by the type and size of the downstream partner. This model works well on average but does not "give credit" for the adaptive traffic shaping algorithms that many SSPs use to minimize QPS and maximize win rate. Similarly, many companies are developing traffic shaping capabilities in the header bidder wrapper that optimize revenue per bid request.

Using the Traffic API, ad tech vendors can provide granular data about their traffic shaping algorithms to improve the accuracy of the Scope3 model and to highlight the sustainability benefits of their traffic shaping efforts to their constituents.

DSP Traffic Throttling

All DSPs have traffic throttling technology that manages QPS, protects against duplicated traffic, and prevents wasting CPU resources on low-value traffic. Scope3 uses contributed and observed data to represent DSP throttling in the aggregate.

The Traffic API allows DSPs to share throttling data for direct and indirect supply chain partners, providing a much more accurate view of how the supply chain is producing actual emissions at the DSP (where the majority of computation happens).

Getting Started

There are two ways to upload traffic data to our traffic API:

1. A Cloud Bucket Configuration
2. The File Upload API

File Format

Both the cloud bucket and File Upload API methods accept a CSV file. See here for CSV schema details.

Bucket Setup

You will need a Cloud Bucket Configuration. If you don't have one set up, please ask your friendly neighborhood ScopeThreep!

Once you have the cloud bucket configured, you'll need to gather traffic data. We plan to write specific guides for common data sources (Prebid Analytics, GAM, Google Analytics, etc) - if you're using one of these platforms, please let us know so we can help out as well as document the process.

When you push data to the cloud bucket, Scope3 will pick up the file, parse it, and add it into a staging version of the emissions model to see the impact. We will share some statistics and visualizations of the impact to help validate the data. Once both sides are satisfied that the integration is reliable and accurate, we will flip the switch and all new data will be added to the "latest" model on a nightly basis.

API Setup

Alternatively, you can use the Upload Data File API with the TRAFFIC_ROUTING file type.

Data Format

The core of the traffic data format is "what traffic did I see and what did I do with it":

• Inventory: channel, property (inventory_id, domain, or app, app_store), placement (gpid, max_placement_size)
• Traffic Dimensions: country, country_group, operating_system, device_type, and network
• Traffic Source: schain, traffic_source (both use OpenRTB entity identifiers)
• Traffic Destination: traffic_destination

Traffic Volume

For the publisher traffic use case, the key metrics are volume (impressions or ad_opportunities) and sessions.

Traffic Shaping

For header traffic shaping, the key metric is the ratio of volume seen vs volume sent to partners. This can be expressed by providing both seen and sent (ad_opportunities + ad_opportunities_sent or inbound_requests + outbound_requests) or by providing the ratio directly (filter_rate is the % blocked; passthrough_rate is the % sent). Partners may also provide win_rate to affect the bandwidth calculation for bid responses.

Since SSPs sit in the middle of a vast network of traffic sources and destinations, we recommend that SSPs reduce the dimensionality of the data they send by omitting inventory detail for all but the largest partners. A "null" inventory row that matches other dimensions will be treated as the platform default.

For vendors that provide traffic shaping for other ad tech companies (shaping-as-a-service), pass the ad tech company entity identifier into the atp field.

Traffic Throttling

For traffic throttling, the key metric is the throttling ratio (filter_rate or passthrough_rate) plus inbound_requests and/or ad_opportunities.

See here for the full list of available fields.