Skip to content

Halo CMM Core Specification

Tejash Natali edited this page Jan 13, 2024 · 4 revisions

Introduction

This Halo CMM Framework Core Specification (referred to herein as the “Halo Core Specification”) describes the Roles and related obligations that are required as a minimum to properly deploy an instance of the Halo Cross Media Measurement System.

To deliver a Measurement Service in the Territory, the Halo Core Specification and the [Territory] Local Specification (referred to herein as the “Local Specification”) combined describe the full scope of the Roles and related obligations required of all companies that have a fully executed [Territory] Participation Agreement (referred to herein as the “Agreement”).

The Introduction to the Halo Cross-Media Measurement Framework provides a high-level overview of the WFA CMM initiative, including its documentation, background, North Star requirements, underlying methodologies, and future roadmap, as well as guidance on how to approach audits, governance, legal and commercial considerations when setting up a Measurement Service in a Territory. This document assumes familiarity with the terminology used in the Halo Introduction and especially in the Design Overview section (please see also the Halo Glossary).


Legend

Each task or obligation of each Role has a specific code:

  • Code syntax: [Phase - Role - number - (limited to a Phase)]

  • Examples

    • [S-PP-02-T] - Setup Phase task for the Panel Provider no.02 needed for the Training Phase

    • [S-VMP-03-M] - Setup Phase task for the VID Model Provider no.03 needed for the Measurement Phase

    • [S-EDP-07] - Setup Phase task for an EDP no.07 needed for both the Training and the Measurement Phase

    • [T-ESP-01] - Training Phase task for the Enumeration Survey Provider no.01

    • [M-MFO-12] - Measurement Phase task for the Measurement Frontend Operator no.12


This document includes coloured boxes interspersed among the text:

Blue boxes contain additional comments and explanations. These boxes are not considered to be part of the Core Specification of the Halo CMM but provide context or other information that might be useful for local markets to consider. --





  1. Halo CMM – Input Standards and Core Metrics

Placeholder

  • MRC and IAB standards as recommended (non-binding) definitions

  • https://www.iab.com/iab_guideline_type/measurement/?post_type=iab_guideline



Introduction This Halo CMM Framework Core Specification (referred to herein as the “Halo Core Specification”) describes the Roles and related obligations that are required as a minimum to properly deploy an instance of the Halo Cross Media Measurement System. To deliver a Measurement Service in the Territory, the Halo Core Specification and the [Territory] [Local Specification](https://docs.google.com/document/d/1EQg1gciOY4LDlfeAszDdAL15X_daYTK_B6IjCDkE95U/edit?usp=sharing) (referred to herein as the “Local Specification”) combined describe the full scope of the Roles and related obligations required of all companies that have a fully executed [Territory] Participation Agreement (referred to herein as the “Agreement”). The [Introduction to the Halo Cross-Media Measurement Framework](https://docs.google.com/document/d/1jsq6lFlUioPB38JyNXEehCwWSNv58dVLz7QZUH4vSq8/edit?usp=sharing) provides a high-level overview of the WFA CMM initiative, including its documentation, background, North Star requirements, underlying methodologies, and future roadmap, as well as guidance on how to approach audits, governance, legal and commercial considerations when setting up a Measurement Service in a Territory. This document assumes familiarity with the terminology used in the Halo Introduction and especially in the Design Overview section (please see also the [Halo Glossary](https://docs.google.com/spreadsheets/d/1a6BC2c7uQlrntZwXHhMfsHE3WY4QnwdwZ6z5faxtSD8/edit?usp=sharing)).

Legend Each task or obligation of each Role has a specific code: Code syntax: [Phase - Role - number - (limited to a Phase)] Examples [S-PP-02-T] - Setup Phase task for the Panel Provider no.02 needed for the Training Phase [S-VMP-03-M] - Setup Phase task for the VID Model Provider no.03 needed for the Measurement Phase [S-EDP-07] - Setup Phase task for an EDP no.07 needed for both the Training and the Measurement Phase [T-ESP-01] - Training Phase task for the Enumeration Survey Provider no.01 [M-MFO-12] - Measurement Phase task for the Measurement Frontend Operator no.12

This document includes coloured boxes interspersed among the text: Blue boxes contain additional comments and explanations. These boxes are not considered to be part of the Core Specification of the Halo CMM but provide context or other information that might be useful for local markets to consider.

Orange boxes contain links to GitHub pages with the Halo code and deployment guides for the respective components.

Table of Contents

Introduction 1

  1. Halo Framework – Overall Outline 4
  2. Tasks and Obligations by Role 7 2.1. Enumeration Survey Provider 7 2.2. Panel Provider(s) 8 2.3. VID Model Provider 11 2.4. EDP (Event Data Provider) 13 2.5. Measurement Orchestrator Operator 16 2.6. MPC Worker Operator 18 2.7. MPC Aggregator Operator (when necessary) 20 2.8. Measurement Frontend Operator 21 2.9. Measurement Consumer 23 2.10. Local Governing Body 23 2.11. Local Measurement Service Operator 24
  3. Halo CMM – Input Standards and Core Metrics 26 APPENDIX A: The Halo CMM Framework Core Specification version history 27

Halo Framework – Overall Outline The Halo Framework is a solution for ad campaign and content audience measurement that is designed as a secure and decentralised system of components and roles. The Halo Framework protects data and information of all stakeholders involved in the framework and, at the same time, protects privacy of internet users exposed to the measured advertising campaigns or consuming the measured digital content. A general overview of the Halo Framework is shown below:

Halo Framework

The Halo Framework defines the following general roles: Enumeration Survey Provider (ESP) The party that provides the enumeration survey of the population under measurement. The enumeration survey is a [Territory] representative survey to establish size, composition and behaviour, such as media usage, of the Population in the Territory. The outcome are the Universe Estimates used by the VID Model Provider, Measurement Frontend and Non-Census EDPs. Panel Provider (PP) A party that recruits and maintains panel(s) informing the Halo CMM. Panel Provider(s) delivers respondent level data that is used by the VID Model Provider to create and train VID Models for Census EDPs. The Panel Provider obtains census Events associated with panellists from Census EDPs via the Panellist Data Exchange. Panel data also informs cross-media, cross-device platform and cross-EDP audience overlaps. Panel data may be also used for measurement. VID Model Provider (VMP) A party that creates and trains VID Models for Census EDPs and creates and updates the Virtual Population. The VID Models are trained on Panel Data matched to Event Data of EDPs provided by the Panel Provider(s) to the VID Model Provider Event Data Provider (EDP) A party that has access to Event Data for one or more Properties under Measurement, and provides inputs based on such Event Data, such as Panellist logs, Event Groups, and Requisition fulfillments, through a direct integration with the CMMS. An EDP may be a Census EDP, Non-Census EDP and/or an EDP Aggregator. Census EDP - a party that performs the Role of an EDP using Census Event Data for one or more Properties under Measurement that it owns. “Census" means all Events for a particular Event Group in the Territory and/or collected by logs or tags of the Property Under Measurement. Non-Census EDP - a party that performs the Role of an EDP using Non-Census Event Data that it owns for one or more Properties under Measurement. “Non-Census” means a subset of all events for a particular Event Group in the Territory, such as those collected in a panel, even if representative, or from set-top boxes or smart TVs, even if at a large scale. For clarity, if a PUM or some of its Event Groups were available exclusively on the included set top boxes or smart TVs and no sampling has been applied, then the data for those Event Groups would be Census. EDP Aggregator - a party that performs the Role of a Census EDP using Event Data for one or more Properties under Measurement that it does not own and/or performs the Role of a Non-Census EDP for Non-Census Event Data that it does not own.

Measurement Orchestrator Operator (MO) The party that operates the Measurement Orchestrator. Measurement Orchestrator is the component of the Halo CMMS that mediates the relationships between the rest of the system components and Roles and coordinates interactions between them. MPC Worker Operator (MPCW) The party that operates a MPC Worker. A MPC Worker is the MPC Node that performs a part of the Secure Multi-Party Computation using the applicable component of the CMMS in accordance with the operational security requirements. MPC Aggregator Operator (MPCA) The party that operates the MPC Aggregator. The MPC Aggregator is the MPC Node that combines results of the MPC from the MPC Workers to calculate a Measurement using the applicable component of the CMMS in accordance with the operational security requirements. Note: The MPC Aggregator will not be needed in a future version of the MPC which is expected to be released in Q1/2024. The upgraded MPC will operate within MPC Workers without the MPC Aggregator. Measurement Frontend Operator (MFO) The party that operates a Measurement Frontend. A Measurement Frontend is a set of APIs and/or UIs that provide an interface for the Measurement Consumer into the Measurement Orchestrator to define Report Requests and obtain a Report. There can be multiple Frontend Operators in a Territory. Measurement Consumer (MC) The party that makes a Report Request through the Measurement Frontend and receives the results in a Report.

Local Measurement Service governance roles: Local Governing Body (GB) The party that has representatives either directly or through its committees of the buy sides and sell sides in the Territory and that oversees or endorses the Local Measurement Service run in the Territory by the Local Measurement Service Operator. The Local Governing Body or its appointed Local Measurement Service Operator, is responsible for defining and maintaining the Local Specification. The Local Governing Body and the Local Measurement Service Operator may be the same party. Local Measurement Service Operator (MSO) The party, under the auspices of the Local Governing Body, that is responsible for the implementation and management of the Local Measurement Service in a Territory, either by itself or through one or more subcontractors.

Tasks and Obligations by Role

Enumeration Survey Provider The party that provides the enumeration survey of the population under measurement. The enumeration survey is the source of Universe Estimates that inform creation and updates of the Virtual Population. The Universe Estimates are audience size estimates created for all segments of the Virtual Population such as demographic breaks, geographic breaks, device platform overlaps or media type overlaps. The Universe estimates are inputs for several stakeholders in the Halo CMM: VID Model Provider - needed for the creation of the Virtual Population which is incorporated in each VID model. Measurement Frontend Operator - needed for calculations of % reach to be included in Reports. The respective universe estimates of the specific target audience defined by the MC in a Measurement Request are used as the denominator in the Reports to calculate the relative (%) values. EDP Aggregator and/or some Aggregatees - in the instance when Non-Census data sets are integrated by an EDP Aggregator with Halo CMM then the Non-Census data (e.g. TV data, Print survey data) needs to be projected to the same Population under Measurement as applied by the VID Model Provider so the fusion with the Virtual Population does not struggle with inconsistencies in universe estimates. Description of the obligations of the Enumeration Survey Provider can be subject to change - depends on the Halo Population Service design that is currently being discussed by Halo.
Setup Phase [S-ESP-25-T] (subject to change depending on the Halo Population Service design) Agree with the VID Model Provider on delivery means, format and delivery cadence of Universe Estimates [S-ESP-26-T] (subject to change depending on the Halo Population Service design) Agree with the Measurement Frontend Operator(s) on delivery means, format and delivery cadence of Universe Estimates Training Phase [T-ESP-13] (subject to change depending on the Halo Population Service design) Deliver Universe Estimates to the VID Model Provider in an agreed format, cadence and delivery means Measurement Phase [M-ESP-03] (subject to change depending on the Halo Population Service design) Deliver Universe Estimates to the Measurement Frontend Operator(s) in an agreed format, cadence and delivery means [M-ESP-04] (subject to change depending on the Halo Population Service design) If applicable, deliver Universe Estimates to the Non-Census EDP(s) in an agreed format, cadence and delivery means

Panel Provider(s) A Panel Provider is responsible for recruitment and maintenance of panel(s) that meets requirements defined by the Governing Body in the Local Specification and delivers Panel data that is consented by panellists for all purposes of the CMMS.

General requirements for digital panel(s) Smartphone, Tablet, Desktop/Laptop computers Opt-in panel with comprehensive notice and consent processes which meet privacy regulation obligations and covers consent for all processing purposes listed in the Core Specs and Local Specs (use cases decided by the local governance body for the local deployment of the Halo CMM) Collection of detailed URL level information (full URL string) for standard browsers and embedded browsers for both secure and non-secure traffic Might be needed for panellist match key collection for Panellists Data Exchange (depends on the match keys agreed with each EDP) Needed for filtration of publisher back-end calls (e.g. widgets of third parties installed by publishers to their pages and apps) from panel data informing cross-device and cross-media overlaps If panel only reporting for content is included in the [local deployment of the Halo CMM - Needed for a granular classification of content for non-collaborating publishers Collection of data about panellist interactions with mobile apps On the top of the browser data, app behaviour (including embedded browser) need to be collected to provide a complete basis for VID model creation Collection of publishers’ First Party Identifiers (first party cookies, IDFVs) and device IDs Expands options for match keys that can be used for Panellists Data Exchange Can make panel match process smoother if the EDP Aggregator has access to panel data (e.g. is the same company) Demographic information required for CMM reporting to be collected for all panellists Informs demographic correction of the EDP-provided demos in the EDP-specific VID model (if demographic information is available on the EDP side) Informs VID models about demographic composition of the audience for EDPs where demographic information is not available on the EDP side Panel respondent-level data availability to the VID Model Provider VID Model Provider needs to see individual panellist IDs (can be hashed) together with associated first-party identifiers for each EDP obtained via the Panellist Data Exchange.

A Panel Provider creates data sets for VID models training by combining panel data with EDP event data via th ePanellists Data Exchange.

Panellist Data Exchange The goal of the Panellist Data Exchange is to associate Census EDP Event Data with panellist data via a double-blind panel match protocol between participating Census EDPs and a Panel Provider. The panel data match requires Panellist Data Exchange Client to be operated by each participating Census EDP and by the Panel Data Provider(s) that communicates with the shared external storage (where encrypted panel match keys and Census EDP Event Data are stored) to perform the data exchange operations. The Panellist Data Exchange is set up and supervised by the Measurement Orchestrator. The double-blind panel match protocol assures that: The EDP cannot find out who the panel members are in the EDP Event Data measurements The Panel Provider(s) and the VID Model Provider are only allowed to receive from the EDP the census measurements that belong to panel members (are not allowed to view any other census measurements).

Panel data enriched with Census EDP Training Inputs is used by the VID Model Provider to train VID Models for each EDP (or each ID space of the EDPs) and can be also used to inform audience estimates for Properties under Measurement for which Census Event Data is not available.

Tasks and obligations of a Panel Data Provider: Setup Phase [S-PP-15-T] Deploy its Panellist Data Exchange Client and share its Panellists Data Exchange Client certificate with the Measurement Orchestrator [S-PP-16-T] If the Panel Provider hosts the Shared External Storage of the Panellist Data Exchange - share the Storage configuration (storage type, access URL, bucket name) with EDPs and provide access rights to the Shared External Storage to the EDPs [S-PP-23-T] Agree with the VID Model Provider on delivery means, format and delivery cadence of panel data enriched with Census EDP Training Inputs. [S-PP-24] Update software components that interact with the Halo APIs to support evolving Halo API specifications according to timelines set out by the Local Governing Body in the Local Specification.

Training Phase [T-PP-06] Agree with each EDP on an EDP-specific Panel Match Key Types. [T-PP-08] Provide encrypted Match Keys to the Panellist Data Exchange [T-PP-11] Retrieve matched EDP Events from the Panellist Data Exchange (ad exposures,media usage behaviour, Demographics) incl. assigned VIDs (where applicable) and update the Panel Exchange Coordinator (Exchange Service) state accordingly [T-PP-12] Send Panellist Data along with any matched EDP Events (ad exposures,media usage behaviour, Demographics) incl. assigned VIDs (where applicable) to the VID Model Provider Measurement Phase [M-PP-20] If panel-only measurements are used in the local deployment of the CMM - Provide panel data at the agreed upon cadence to a Non-Census EDP.

Halo code and deployment guides - Links Panellist Exchange Client Libraries: https://github.com/world-federation-of-advertisers/panel-exchange-client

VID Model Provider The VID Model Provider creates and updates the Virtual Population (a pool of VIDs, that is equal in size and composition to the Universe Estimate for the Territory) and the VID Models for each EDP. Inputs for the VID model provider are Universe Estimates and panel data enriched with Census EDP Training Inputs obtained via the Panellists Data Exchange process. There can be multiple panels informing the cross-media measurement in the Territory. The VID Model Provider can use a single panel (if it covers all measured device platforms & media and the training sample size is sufficient) or multiple panels to extend the size of training data or to cover all device platforms measured by the CMM in the Territory. Also, depending on the modelling approach, some panels do not need to be matched to Census EDP Training Inputs but can be used by the VID Model Provider to inform cross-device and cross-media audience overlaps.

Tasks and obligations of the VID Model Provider: Setup Phase [S-VMP-27 -T] Deploy software components that conform to the Halo API specifications for providing data to the system. This may involve use of the Halo VID Model Training Toolkit. [S-VMP-28-T] Share the VID Model Provider certificate with the Measurement Orchestrator [S-VMP-29-T] (subject to change depending on the Halo Population Service design) Agree with the Enumeration Provider on delivery means, format and delivery cadence of Universe Estimates [S-VPM-30-T] Agree with the Panel Provider(s) on delivery means, format and delivery cadence of panel data enriched with Census EDP Training Inputs. [S-VMP-31] Update software components that interact with the Halo APIs to support evolving Halo API specifications according to timelines set out by the Local Governing Body in the Local Specification. Training Phase [T-VMP-14] Create and update the Virtual Population [T-VMP-09] If campaign metadata is needed as an input to the VID model creation, the VID Model Provider specifies the required metadata and requests EDPs to provide ad IDs in the Census EDP Training Inputs and agrees with EDPs on delivery means and formats of metadata for the ad IDs each EDP includes in the Census EDP Training Inputs. [T-VMP-15] Create and train VID Models [T-VMP-16] Label every model with VID Model metadata as defined in the Local Specification (versioning, release notes, required deployment date) [T-VMP-17] Provide encrypted VID Models to the Measurement Orchestrator (VID Model Repository) The VID Model Repository is a component of the Measurement Orchestrator where the EDPs are retrieving the EDP-specific VID Models from. The VID Model Repository includes information for each VID model that is provided by the VID Model Provider (VID Model metadata). The VID Model metadata includes required install date for a new VID model which is defined by the VID Model update policy in the Local Specification.

[T-VMP-20] Validate the correctness of the respective VID Model application by each EDP via comparing: the VIDs assigned by the EDP to Event Data matched to the panellists and the expected outcome of the VID model [T-VMP-21] Update the VID Models in periods as defined in the Local Specification Measurement Phase: [M-VMP-21] Tag a VID model line as having an outage in a case if the underlying model is found to be faulty as defined by the VID Model policy in the Local Specification

Halo code and deployment guides - Links VID Model Training Toolkit: https://github.com/world-federation-of-advertisers/virtual-people-training

EDP (Event Data Provider) A party that has access to Event Data for one or more Properties under Measurement (the media whose Events can be measured and reported), and provides inputs based on such Event Data, such as Panellist logs, Event Groups, and Requisition fulfillments, through a direct integration with the CMMS. An EDP may be a Census EDP, Non-Census EDP and/or an EDP Aggregator.

Tasks and obligations of an EDP are: Setup Phase [S-EDP-17-T] - applicable to Census EDP and EDP Aggregator performing a role of a Census EDP: Deploy Panellist Exchange Client Libraries and share its Panellists Data Exchange Client certificate with the Measurement Orchestrator [S-EDP-18-T] - applicable to Census EDP and EDP Aggregator performing a role of a Census EDP: If the EDP hosts the Shared External Storage of Panellist Data Exchange - share Storage configuration (storage type, access URL, bucket name) with the Panel Provider and provide access rights to the Shared External Storage to the Panel Provider [S-EDP-19] Provide its (valid) EDP certificate with the Measurement Orchestrator, Panel Provider (s), an MPC Worker (the MPC Worker that the EDP trusts, i.e. which the EDP sends the Sketches to; the Worker may be operated by the EDP) [S-EDP-20-M] Deploy software components that conform to the Halo API specifications for providing data to the system. This may involve use of the Halo EDP libraries (VID Labelling Library, Privacy Budget Management Library, Sketching Library). [S-EDP-21] Update software components that interact with the Halo APIs to support evolving Halo API specifications according to timelines set out by the Local Governing Body in the Local Specification. [S-EDP-22] Collect the MC IDs from Measurement Consumers who want the measurement to be enabled and enable the MCs Campaign measurement data can be sensitive information and thus only authenticated ‘owners’ of campaigns can have access to the campaign measurement reports. EDPs need to be sure that the measurements are provided to properly identified Measurement Consumers and thus EDPs need to enable every MC separately. The process is currently manual but enhancements can be considered for future as the CMM usage will scale up.

Training Phase’ [T-EDP-07] - applicable to Census EDP and EDP Aggregator performing a role of a Census EDP: Agree with the Panel Provider on Panel Match Keys (EDP-specific) [T-EDP-10] - applicable to Census EDP and EDP Aggregator performing a role of a Census EDP: Operate software components to provide EDP Training Inputs to the Panellist Data Exchange in conformance with the Local Specification. [T-EDP-18] - applicable to Census EDP and EDP Aggregator performing a role of a Census EDP: Operate software components for retrieving VID Models from the Measurement Orchestrator’s VID Model Repository and follow the information provided by the VID Model metadata. [T-EDP-19] - applicable to Census EDP and EDP Aggregator performing a role of a Census EDP: (for VID labelling validation purposes) Provide EDP Training Inputs including VIDs assigned to the to Census EDP Training Inputs to the Panellist Data Exchange Measurement Phase [M-EDP-05] Applicable to Census EDP and EDP Aggregator performing a role of a Census EDP: Collect Census EDP Measurement Inputs in conformance with the Local Specification. Applicable to Non-Census EDP and EDP Aggregator performing a role of a Non-Census EDP: Collect Non-Census data in conformance with the Local Specification. [M-EDP-09] Applicable to Census EDP and EDP Aggregator performing a role of a Census EDP: Assign VIDs to Census EDP Measurement Inputs in-house by applying the correct EDP-specific VID model Applicable to Non-Census EDP and EDP Aggregator performing a role of a Non-Census EDP: Assign VIDs to Non-Census data in-house as specified in the Local Specification. [M-EDP-10] Provide its Event Groups to the Measurement Orchestrator (Event Groups Service) [M-EDP-11] Retrieve and fulfil Requisitions in accordance with the CMMS APIs while monitoring Privacy Budget use by the respective Measurement Consumer (when applicable; if the Privacy Budget is exceeded, reject the Requisition and notify the Measurement Orchestrator).

Privacy Budget Every time a Measurement is created it incurs a privacy cost. The privacy cost is charged by each EDP integrated with the CMMS in a privacy ledger they maintain. Each EDP, in accordance to their own privacy policy, decides how the costs are accrued for in their ledger and what the maximum charge is on each ledger item. When the privacy quota is exceeded for one of the items in the ledger, for example, by querying too many stats for the same campaign, the EDP can refuse to respond to the Requisition and notify the Measurement Orchestrator that the privacy budget has been exceeded. Some EDPs may decide to not apply any privacy budget.

Direct Measurements and Sketches Additive metrics (e.g. impressions, duration) are provided by an EDP to the MO in a form of encrypted Direct Measurements. The same applies to the Requisitions based on single-EDP Measurement R/F Requests. An EDP can add noise to the Direct Measurements to make them differentially private. Sketches are created by an EDP in response to R/F Requisitions based on multiple-EDP Measurement Requests and encrypted Sketches are provided by the EDP to the trusted MPC Worker.

Halo code and deployment guides - Links Panellist Exchange Client Libraries: https://github.com/world-federation-of-advertisers/panel-exchange-client VID Labelling Library: https://github.com/world-federation-of-advertisers/virtual-people-core-serving/tree/main Privacy Budget Management Library: https://github.com/world-federation-of-advertisers/cross-media-measurement/tree/ma[…]rg/wfanet/measurement/eventdataprovider/privacybudgetmanagement Sketching Library: https://github.com/world-federation-of-advertisers/any-sketch-java

Measurement Orchestrator Operator A party that operates the Measurement Orchestrator which is the central component of the Halo CMMS. In the Training Phase, the Measurement Orchestrator facilitates the Panellist Data Exchange process between the EDPs and Panel Provider(s). In the Measurement Phase, the Measurement Orchestrator coordinates the flow of Measurement Requests from Measurement Consumers to deliver Reports to MCs using the MPC Consortium (computation service). The Measurement Orchestrator also facilitates transmission of Event Groups from EDPs to the Measurement Frontend(s) for Measurement Consumers to search and identify those Event Groups they want to report on (Event Groups are building blocks for campaign or content definition for reporting).

The Measurement Orchestrator Operator is an independent regional role which needs to be agreed on between the stakeholders (local association of advertisers, local industry body/JIC, leading publishers & broadcasters and digital platforms).

The Measurement Orchestrator is required to be separated from any EDP or Measurement Consumers to protect data and information of individual players contributing to and using the Halo CMMS. This means that a single party cannot play the Measurement Orchestrator role if it acts as an EDP and/or if it acts as a Measurement Consumer. The party that operates the Measurement Orchestrator may not operate an MPC Worker nor the MPC Aggregator.

The stakeholders driving the cross-media measurement in the Territory have to define how this role will be fulfilled for the Territory, e.g. a local independent and trusted company can be commissioned. Alternatively, a company that already provides this service to other regions or countries can be considered (e.g., in collaboration with the ISBA in the UK in or the ANA in the US).

A local/Territory setup may allow the requirements listed above to be adjusted - for example: If a JIC market is aiming for a single currency solution then a single Measurement Frontend provider can be appointed by the JIC for the Territory. In such a case, s single company may: operate the Measurement Orchestrator operate the MPC Aggregator operate an MPC Worker act as an EDP Aggregator ‘Outsourcing’ of the Halo CMMS infrastructure or its part from a different Territory. In this instance, the core Halo infrastructure is not built in the Territory but a regional/global infrastructure is used by the currency solution in the Territory A single MPC consortium can be used by multiple Measurement Orchestrators A single Measurement Orchestrator can work with multiple MPC Consortiums

Tasks and obligations of the Measurement Orchestrator Operator: Setup Phase [S-MO-07] Deploy the Measurement Orchestrator component (Kubernetes MO) using the up-to-date Halo code (see the link below) using an Approved Service Provider as specified in Local Specification doc, section 1.4. [S-MO-08] Provide the Measurement Orchestrator root certificate and Measurement Orchestrator public IP address to EDPs, Panel Provider(s), the VID Model Provider, MPC Nodes, Measurement Frontend [S-MO-09-T] Generate Panel Provider ID(s) and share the ID(s) with Panel Provider(s) and EDPs [S-MO-10] Generate IDs for EDPs and share the IDs with corresponding EDPs [S-MO-11-M] Generate Worker IDs and share the IDs with corresponding MPC Workers [S-MO-12-M] Generate a MPC Aggregator ID and share the IDs with the MPC Aggregator [S-MO-13-M] Generate Measurement Consumer IDs and share the IDs with corresponding Measurement Consumers [S-MO-14] Deploy updated Halo components and/or libraries as specified in the local code update policy in the Local Specification, and work with the Local Governing Body to rollout new features. Training Phase [T-MO-03] Facilitate the Panellist Data Exchange: Respond to API calls for Panellist Data Exchange [T-MO-04] (a component to be developed) Store population data (Universe Estimates) [T-MO-05] Operate the VID Model Repository by storing VID Models sent by the VID Model Provider and distribute the VID Models to EDPs Measurement Phase [M-MO-06] Facilitate Measurement Requests - split each Request obtained from the Measurement Frontend into a set of Requisitions, for each EDP involved in the measurement. [M-MO-07] Facilitate MPC - notify the MPC Consortium to prepare to compute the Measurement, monitor MPC status information during the lifetime of the Measurement computation. [M-MO-08] (subject to change depending on the Halo Population Service design) Retrieve and fulfil population data Requisitions in accordance with the CMMS APIs [M-MO-15] Store Measurements obtained from the MPC Consortium as the result of MPC Consortium calculations or obtained from the EDPs as Direct Measurements.

Halo code and deployment guides - Links Kubernetes MO Deployment: https://github.com/world-federation-of-advertisers/cross-media-measurement Measurement/Reporting CLIs: https://github.com/world-federation-of-advertisers/cross-media-measurement/tree/main/src/main/kotlin/org/wfanet/measurement/api/v2alpha/tools

MPC Worker Operator A party that operates a MPC Worker which is a component of the MPC Consortium. The MPC Consortium is a decentralised service that distributes the Multi-Party Computations over multiple MPC Nodes to merge encrypted Sketches provided by EDPs and calculate audience estimates in response to Measurement Requests of Measurement Consumers. The MPC Worker is an MPC Node that performs a part of the Secure Multi-Party Computation using the applicable component of the CMMS in accordance with the operational security requirements.

The MPC Consortium performs the secure multi-party computation protocol, i.e. combines encrypted Sketches from multiple EDPs using the MPC Worker process to compute the requested deduplicated reach and frequency. The encrypted Sketches are combined without being decrypted. The MPC Consortium must consist of at least two independent nodes (Workers) but, on the other hand, the total count of nodes should be limited (because of computation efficiency reasons). Similarly to the Measurement Orchestrator setup, it needs to be agreed between the stakeholders (local governing body/JIC, local association of advertisers, leading publishers & broadcasters and digital platforms) who will run the individual MPC Workers for the Territory (or if a regional infrastructure/global Nodes are used). Each EDP needs to select one of the MPC Workers as its trusted node in the MPC Consortium - some EDPs can run their own MPC Worker, some can choose an MPC Worker of a third party as their trusted node. The output produced by the MPC is differentially private, which means that the presence of any particular user’s data can not be inferred from the output. Differential privacy is achieved by adding noise to the output by the MPC protocol.

Tasks and obligations of an MPC Worker Operator: Setup Phase [S-MPCW-32-M] Deploy the Kubernetes MPC Node code (see the link below) using an Approved Service Provider as specified in Local Specification doc, section 2.4., configure it to act as an MPC Worker and connect with other MPC nodes [S-MPCW-33-M] Share its Worker certificate and Worker public IP address with the EDP(s) who selected the Worker as their trusted MPC node and with the Measurement Orchestrator [S-MPCW-34] Deploy updated Halo components and/or libraries as specified in the local code update policy in the Local Specification, and work with the Local Governing Body to rollout new features. Training Phase: no tasks Measurement Phase [M-MPCW-12] Participate in MPC operations according to the protocol specification.

Halo code and deployment guides - Links Kubernetes MPC Node Deployment (configurable to act as an MPC Worker): https://github.com/world-federation-of-advertisers/cross-media-measurement/tree/6617ca8617894e8d207dd7de03f7b92a3a489e78

MPC Aggregator Operator (when necessary) The party that operates an MPC Aggregator which is the MPC Node that combines results of the multi-party computation from the MPC Workers to calculate Measurements that are sent to the Measurement Orchestrator using the applicable component of the CMMS in accordance with the operational security requirements. The MPC Aggregator also acts as an MPC Worker within the MPC Consortium. It is planned to upgrade the MPC code to operate without the MPC Aggregator in the foreseeable future (expected Q1/2024).

The Halo CMMS trust protocols do not allow a single party to operate the MPC Aggregator and the Measurement Orchestrator at the same time so this needs to be considered when the local governance body (JIC) plans to host or to appoint a company to host the MPC Aggregator and the Measurement Orchestrator for the Territory.

The MPC Aggregator may not be operated by an EDP nor by a Measurement Consumer for a different Measurement Consumer. If there are only two nodes in the MPC Consortium in the Territory (a Worker and the Aggregator) then the other MPC node (MPC Worker) may not be operated by the same party as the MPC Aggregator.

Tasks and obligations of the MPC Aggregator Operator: Setup Phase [S-MPCA-35-M] Deploy the Kubernetes MPC Node code (see the link below) using an Approved Service Provider as specified in Local Specification doc, section 2.4., configure it to act as the MPC Aggregator and connect with other MPC nodes [S-MPCA-36-M] Share its Worker certificate and Worker public IP address with the EDP(s) who selected the Worker as their trusted MPC node and with the Measurement Orchestrator [S-MPCA-37-M] Share the MPC Aggregator certificate with the Measurement Orchestrator [S-MPCA-38] Deploy updated Halo components and/or libraries as specified in the local code update policy in the Local Specification, and work with the Local Governing Body to rollout new features. Training Phase: no tasks Measurement Phase [M-MPCA-13] Participate in MPC operations according to the protocol specification [M-MPCA-14] Provide encrypted results of MPC (Measurements) to the Measurement Orchestrator Halo code and deployment guides - Links Kubernetes MPC Node Deployment (configurable to act as the MPC Aggregator): https://github.com/world-federation-of-advertisers/cross-media-measurement/tree/6617ca8617894e8d207dd7de03f7b92a3a489e78

Measurement Frontend Operator A party that operates the Measurement Frontend which is a set of APIs and/or UIs that provide an interface for the Measurement Consumer into the Measurement Orchestrator to define Report Requests and obtain a Report.

There can be several Measurement Frontend operators in a Territory that can offer different features but the core reporting of outcomes from the Halo CMM must deliver the measurement results to end-user (the Measurement Consumers) as provided by the measurement service of the Measurement Orchestrator.

Tasks and obligations of the Measurement Frontend Operator: Setup Phase [S-MFO-39-M] Deploy software components that conform to the Halo API specifications for providing data to the system. This may involve use of the Reporting CLI and/or Reporting Server [S-MFO-40-M] (subject to review) Facilitate registration of Measurement Consumers in the Halo CMM [S-MFO-41-M] Share Measurement Consumer IDs generated by the Measurement Orchestrator with respective Measurement Consumers [S-MFO-42-T] (subject to change depending on the Halo Population Service design) Agree with the Enumeration Survey Provider on delivery means, format and delivery cadence of Universe Estimates [S-MFO-43] Update software components that interact with the Halo APIs to support evolving Halo API specifications according to timelines set out by the Local Governing Body in the Local Specification. Training Phase: no tasks Measurement Phase [M-MFO-16] Authenticate Measurement Consumers [M-MFO-17] Operate the reporting APIs provided by Halo. [M-MFO-18] Manage the interaction between the MCs and the MO

Halo code and deployment guides - Links Reporting Server: https://github.com/world-federation-of-advertisers/cross-media-measurement/blob/main/docs/gke/reporting-server-deployment.md

Measurement Consumer The party that makes a Report Request through the Measurement Frontend and receives the results in a Report. Tasks and obligations of the Measurement Consumer: Setup Phase [S-MC-44-M] Obtain Measurement Consumer ID from the Measurement Orchestrator [S-MC-45-M] Register at individual EDPs (for campaigns measurement) Training Phase: no tasks Measurement Phase: [M-MC-19] Interact with the Measurement Frontend to define, request and view reports including mapping of Event Groups across EDPs.

Local Governing Body The party that has representatives either directly or through its committees of the buy sides and sell sides in the Territory and that oversees or endorses the Local Measurement Service run in the Territory by the Local Measurement Service Operator. The Local Governing Body or its appointed Local Measurement Service Operator, is responsible for defining and maintaining the Local Specification. The Local Governing Body and the Local Measurement Service Operator may be the same party.

Tasks and obligations of the Local Governing Body depend on many aspects: the Local Governing Body structure, governance model and decision-making process stakeholders involved in the local CMM scope and setup of the local CMM commercial model

Local Measurement Service Operator The party, under the auspices of the Local Governing Body, that is responsible for the implementation and management of the Local Measurement Service in a Territory, either by itself or through one or more subcontractors.

Tasks and obligations of the Local Measurement Service Operator depend on the local governance model and the local commercial model. The scope of MSO obligations and tasks is defined by the Local Governing Body.

Proposed tasks and obligations of the Measurement Service Operator: Setup Phase [S-MSO-01] Maintain the template Participation Agreement. [S-MSO-02] Maintain the Local Specification document while applying versioning policy agreed by the Local Governing Body [S-MSO-03] Make an assessment, before accepting a prospect participant as a Participant for a particular Role, whether the prospect participant meets the requirements for such Role. [S-MSO-04] Decide whether to reject or admit Participation Agreement, and notify prospect participants of such decision. [S-MSO-05] Maintain a public record of Participants and their Roles in the Local Measurement Service. [S-MSO-06] Provide implementation guidance and first-line support to Participants. Training Phase [T-MSO-01] Be the arbiter in case of conflicts between Participants in connection with the Participation Agreement. [T-MSO-02] Determine whether a participant complies with the terms of the Participation Agreement and whether the admission of Participants for a particular Role is revoked if a Participant does not comply with the terms of the Participation Agreement or otherwise fails to meet the requirements for a particular Role. Measurement Phase: the same as Training Phase [M-MSO-01] Be the arbiter in case of conflicts between Participants in connection with the Participation Agreement. [M-MSO-02] Determines whether a participant complies with the terms of the Participation Agreement and whether the admission of Participants for a particular

Halo CMM – Input Standards and Core Metrics Placeholder MRC and IAB standards as recommended (non-binding) definitions https://www.iab.com/iab_guideline_type/measurement/?post_type=iab_guideline