Overview
Data providers interact with the system to:- Receive and fulfill requisitions from measurement consumers
- Upload encrypted sketches containing aggregated event data
- Manage event groups representing campaigns and content
- Track requisition lifecycle and fulfillment status
Key Concepts
Requisitions
A Requisition is a request for aggregated event data from a data provider, created when a measurement consumer initiates a measurement. Requisition Properties:- Specifies which event groups to include
- Includes encrypted measurement specification
- Contains duchy public keys for encryption
- Has a nonce for one-time fulfillment
Sketches
A Sketch is a probabilistic data structure containing aggregated event information:- Liquid Legions Sketch - For reach and frequency measurements
- Encrypted Payload - Data encrypted for duchy processing
- No Raw Data - Individual user data never exposed
Event Groups
Data providers create EventGroups to organize events:- Campaign impressions
- Video views
- App interactions
- Custom event types
Requisition Fulfillment Flow
Polling for Requisitions
System API (v1alpha)
Data providers monitor for new requisitions using the system API:Requisition States
Current state of the requisitionValues:
UNFULFILLED- Awaiting data provider fulfillmentFULFILLED- Sketch uploaded (terminal)REFUSED- Data provider declined (terminal)WITHDRAWN- Measurement consumer cancelled (terminal)
Generating Sketches
Sketch Generation Process
- Query event data - Retrieve events matching requisition spec
- Filter events - Apply event filters from measurement spec
- Create sketch - Build probabilistic data structure
- Encrypt sketch - Encrypt with duchy public keys
- Upload sketch - Submit to Kingdom
Example: Liquid Legions Sketch
Encrypting Sketches
Multi-Party Encryption
Sketches must be encrypted for duchy processing:- Retrieve duchy public keys - From requisition specification
- Layer encryption - Each duchy adds encryption layer
- Hybrid encryption - Combine symmetric and asymmetric encryption
Fulfilling Requisitions
FulfillRequisition RPC
Resource name of the requisition to fulfillFormat:
computations/{computation}/requisitions/{requisition}One-time nonce value from the encrypted requisition specPrevents replay attacks and double fulfillment.
Additional context about the fulfillmentFields:
build_label- Software version that generated the sketchwarnings- Human-readable warnings about data quality (no sensitive data)
Optional etag for optimistic concurrency controlIf specified and doesn’t match current etag, returns ABORTED status.
Example: Fulfill Requisition
Managing Event Groups
Creating Event Groups
Data providers register event groups through the CMMS public API:Event Group Metadata
External identifier for this event group in data provider’s system
Protocol buffer message types that events conform toExample:
wfa.measurement.api.v2alpha.event_templates.VideoTypes of media in this event groupValues:
VIDEO, BANNER_AD, NATIVE_AD, AUDIOTime range when events are available for measurementMeasurement consumers use this to filter event groups.
Metadata for advertising campaignsFields:
campaign_metadata.brand_name- Advertiser brandcampaign_metadata.campaign_name- Campaign identifier
Refusing Requisitions
Data providers can refuse requisitions they cannot fulfill:Data Quality Best Practices
Validate event data before sketch generation
Validate event data before sketch generation
Ensure VIDs are properly formatted, timestamps are valid, and required fields are present before generating sketches.
Apply consistent event filtering
Apply consistent event filtering
Use the same filtering logic across all requisitions to ensure measurement consistency.
Monitor sketch generation metrics
Monitor sketch generation metrics
Track sketch size, number of registers, and generation time to detect anomalies.
Use fulfillment context warnings
Use fulfillment context warnings
Document data quality issues in the
warnings field to help measurement consumers interpret results.Implement retry logic
Implement retry logic
If sketch upload fails, implement exponential backoff retry logic to handle transient network issues.
Secure nonce handling
Secure nonce handling
Treat nonces as secrets and never log or expose them in plaintext. Verify nonce uniqueness before fulfillment.
Error Handling
Common Error Scenarios
Invalid requisition name format or malformed nonceResolution: Verify resource name follows pattern and nonce is 64-bit fixed integer
Requisition does not exist or has been withdrawnResolution: Refresh requisition list and skip withdrawn requisitions
Requisition already fulfilled or in wrong stateResolution: Check requisition state before attempting fulfillment
ETag mismatch indicating concurrent modificationResolution: Retry with updated requisition and fresh etag
Data provider lacks permission to fulfill this requisitionResolution: Verify authentication credentials and requisition ownership
Security Considerations
Encrypt sketches properly
Encrypt sketches properly
Always encrypt sketches with duchy public keys using approved cryptographic libraries. Never upload unencrypted event data.
Validate duchy certificates
Validate duchy certificates
Verify duchy public key certificates are signed by trusted certificate authorities before encryption.
Protect nonce values
Protect nonce values
Nonces are cryptographic secrets that prevent replay attacks. Store and transmit them securely.
Use mTLS for authentication
Use mTLS for authentication
Data provider services should authenticate using mutual TLS with X.509 certificates.
Audit fulfillment operations
Audit fulfillment operations
Log all requisition fulfillments with timestamps and operator IDs for security auditing.
Related APIs
System: Requisition Fulfillment
Low-level requisition fulfillment system API
Measurement Consumer API
How measurement consumers create measurements