Policy

The Policy API enables Scope3 partners to integrate policy data from the Scope3 platform. As a simple example, an advertiser or agency will set up a policy like "don't run on high-carbon inventory or domains that DeepSee considers MFA". Ad tech platforms use the Policy API on a daily basis to integrate the resulting inventory list into the advertiser's campaigns or PMPs, ensuring that they are always in compliance with the policy.

API Status

The Policy API is in closed beta. Please contact your Scope3 customer success partner to be added to the beta program.

Use Case: DSP Implementation of Climate Shield & Custom Segments

Climate Shield is a standard Scope3 policy definition that blocks made-for-advertising and high emissions inventory. Scope3 will create a Climate Shield Policy for the DSP that can be accessed using the Policy Data API. In many cases - for instance when for technical or business reasons a DSP needs a separate Policy object by country or by channel - Scope3 will create multiple Policy objects with the appropriate slices of Climate Shield data (for instance, "Climate Shield US web").

With the introduction of the Scope3 Collaborative Sustainability Platform (CSP), clients have the ability to define Policy objects on scope3.com. These lists can be mapped into campaigns in the DSP interface. As an example, imagine an agency wishes to create a custom policy for an advertiser that excludes high-carbon and made-for-advertising inventory with a specific threshold. This policy could be distributed to the agency's DSP of choice for targeting within the advertiser's seat.

Use Case: SSP Implementation of GMP Standards and Custom Segments

SSPs that wish to sell Green Media Products (GMPs) must exclude high-carbon and made-for-advertising inventory from these PMPs. Scope3 can set up a GMP Policy that will list all properties and placements that should be excluded and push this into a bucket for regular upload into the SSP platform for use in GMP deals. To make the data more compact, the SSP may set up its inclusion list as a property list and use this to include only these properties in the GMP Policy.

This integration has many advantages over prior methods (using the campaign measurement API directly or through a Google Sheet) including more rapid response to changes in the emissions model and the ability to incorporate placement-level data. We strongly recommend that SSPs work with publishers and upstream supply partners to implement GPIDs properly to improve coverage.

Interpreting Policy Data

Each Policy has three lists that should be processed in order:

1. A list of included properties. If this list is empty, it means all properties are included. If this list is not empty, a property must be in this list to be valid for this policy.
2. A list of excluded properties. If a property is in this list, it is invalid for the policy.
3. A list of excluded placements. If a placement is in this list, it is invalid for the policy.

Property Matching

A property rule consists of an inventory description and a country, both of which must match for the property record to match a rule. A property may contain multiple inventory IDs, each of which will be split into its own inventory description.

Some rules to ensure proper matching:

• Matches should be evaluated against both subdomain and the root domain. For instance, check mail.yahoo.com and yahoo.com, which may have separate records. It is possible that, for instance, yahoo.com would be included but mail.yahoo.com would be excluded.
• A record may exist for a specific country (eg GB) or for the "worldwide" catch-all country which is specified as WW.

Placement Matching

Placements will always be specified per-property, meaning that both the inventory description and the GPID must match. Placements are not unique across properties.

The Scope3 emissions model uses Global Placement IDs (GPID) for all placement names. Scope3 currently uses a default GPID for a seller (for instance, default:teads for all Teads tags directly on a page) and is working with these partners to send GPIDs through the programmatic supply chain.

Distribution Methods

There are three distribution methods for Policy objects.

• Using the API to request one or more Policy objects and their associated data
• Setting up a cloud bucket where Scope3 will push Policy objects on a regular basis
• Direct integration into a partner platform via the partner's API (only done in special cases)

Listing Available Policies

To see the Policy objects that have been configured for your account, use the Policy List API. There are optional parameters to limit the response to active policies or to fuzzy match a particular policy ID.

This will return an array of policies as described in the API documentation. A few key points to note:

• Scope3 defines an id for each policy and allows partners to also attach their own ID which we call policyId. All policy APIs will accept either ID so that partners do not have to manage a mapping table.
• Some platforms provide the ability to push policies to specific seats. The partners array is a mapping of the policy to client seat and segment IDs.
• The updateFrequency is how often Scope3 will push data to a partner bucket. Only relevant for the "bucket push" distribution method.
• The fileName field specifies the file name Scope3 will push to if the distribution method is "bucket push" and supports macros:
  • id - Scope3 internal ID
  • name - policy name
  • policyId - client ID of the policy
  • updateFrequency - DAILY or MONTHLY
  • createdAt - timestamp
  • date - UTC date
• The propertyLists and placementLists arrays are informational and shows the property lists used to create the policy. Primarily useful for debugging.

Retrieving Policy Data

Policy data is returned in a large unstructured array of rules that needs to be assembled into useful form. This array will be in CSV format which pushed into a bucket and in JSON format when retrieved using the Policy Data API.

See the "Interpreting Policy Data" section for logic on how this data should be interpreted.