Skip to content
This repository has been archived by the owner on Sep 2, 2024. It is now read-only.

API Propsal for Consent and Measurement #350

Closed
wants to merge 5 commits into from

Conversation

nickvenezia
Copy link

@nickvenezia nickvenezia commented Nov 16, 2023

Field Description
API family name "Consent & Measurement"
API family owner Centillion.AI
API summary The “Consent & Measurement” API suite is designed to provide the inputs necessary to power the world's digital ecosystem and protect Children. "Consent" is used to focus on a third-party usage of data. "CONSENT" CAN can be used by companies for fueling insights for audience planning, measuring ad exposure, along post campaign validation and audience contextual and behavioral lift measurement, Usage of data through auditing of AI and LLM usage, children's data usage by third-parties with permissions set by the parents. The "Measurement" APIs are designed to integrate with leading enterprises needing consent for AI, Customer Data Platforms' (CDP), Data Management Platforms (DMP), Demand Side Platforms (DSP), Consent Management Platforms (CMP), ad tech companies both on the Sell Side (SSPs, DOOH, CTV, Publishers etc.) and the Buy Side (DSPs, Agency Trading Desks) and position the Mobile Network Operators (MNOs) as the digital backbone with MNO's holding the "consent" and the customers are ad-tech and AI for data aggregated with consent. 'Measurement' has a focus on helping identify real traffic, and provides clarity for all parties. Leveraging the geospatial capabilities of the "CAMARA device location", natively integrated with a specific advertiser focused goals allow for an advertising experience focused on contextual targeting that provides privacy and adapts to local regulation, the goal is for minimizing ad-fraud, blocking access to those without consent, and these APIs provide a new solution for the cookie day allowing for new innovative inputs that will streamline the $674B ad industry and trillion dollar forecasted AI Economy. The CAMARA provides "Measurement" capabilities that are a natural enhancement to advertisers and provide measurement lift in physical retail media and along with digital out of home device exposure (Rideshares, billboards, Points of interest). Leveraging conversion signals from "CarrierBillingCheckOut" (Purchase/digital transaction/click to call) enables both physical and digital transaction impact measurement, tying mobile device to ad exposure to audience behavior to business objectives. CAMARA's commitment to interoperability and compliance with industry standards is why we will be bringing both the IAB Tech Lab, Tradedesk, Bidswitch, and Prebid to aide with our dedication to providing interoperability based on a standardized ecosystem leveraging a dynamic consent verification framework.
Technical viability The "Consent & Measurement" API family provides validated technical integrations with next generation ad tech and AI infrastructure, mass adoption potential with emerging industry standards, such as the Interactive Advertising Bureau (IAB) Tech Lab's. For MNOs and developers, this offers a path to long term viability, new revenue, and compliance across jurisdictions. By leveraging the scale of a standardized federated deployment, MNOs can reclaim revenue back from the tech industry that has created immense value on the back of the telecom infrastructure. By leveraging the structural advantages of the mobile network operators and provide a viable (if not superior alternative) to walled gardens (META / Google) "self-measurement" approach. CAMARA will uplift brands with greater transparency on ad measurement, the Consent and Measurement API will incentivize the adoption of the developer ecosystem with more ad revenue fueling innovation.
Commercial viability The "Consent & Measurement" API has been proposed to leading conglomerate consumer brands, tech platforms, sell side publishers, buy side ad exchanges, and advertising trade organizations to gauge viability and industry adoption. When considering the commercial viability of the "Consent & Measurement" API, interested industry leaders gave it a unanimous “Yes.” The interested parties include LinkedIn, Univision, Proctor and Gamble, IAB Tech Lab, and TradeDesk.
YAML code available? NO.
Validated in lab/productive environments? NO.
Validated with real customers? YES.   YES, the features of CAMARA API like Device Location can replace existing third-party tools used by brands which have been proven to be inaccurate.
Validated with operators? NO. 
Supporters in API Backlog Working Group Will be added by the Working Group.

@nickvenezia nickvenezia changed the title API proposal for consent and measurement API Propsal for Consent and Measurement Dec 4, 2023
@nickvenezia nickvenezia requested review from bigludo7, HanbaiWang and yuhan1020 and removed request for MarkusKuemmerle January 23, 2024 20:43
@nickvenezia nickvenezia self-assigned this Jan 28, 2024
@nickvenezia
Copy link
Author

nickvenezia commented Feb 3, 2024

Field Description
API family name "Consent & Measurement"
API family owner Centillion.AI
API summary The “Consent & Measurement” API suite is designed to provide the inputs necessary to power the world's digital ecosystem, reduce ad fraud, and add Parental Controls."Consent" is used to focus on a third-party usage of data. "CONSENT" CAN can be used by companies for Advertising : fueling insights for audience planning, measuring ad exposure, post campaign validation, audience contextual, behavioral lift measurement. Consent is relevant for auditing of AI and LLM usage By providing insights from inside the network this will position the Mobile Network Operators (MNOs) as the backbone with MNO's holding the "consent". The customers are advertisers and AI who need access to data aggregated with consent. Measurement Requires Consent.. The "Measurement" APIs are designed to integrate with leading enterprises needing consent for AI, Customer Data Platforms' (CDP), Data Management Platforms (DMP), Demand Side Platforms (DSP), Consent Management Platforms (CMP), Ad tech companies both on the Sell Side (SSPs, DOOH, CTV, Publishers etc.) and the Buy Side (DSPs, Agency Trading Desks). 'Measurement' has a focus on helping identify real traffic, and provides clarity for all parties. Leveraging the geospatial capabilities of the "CAMARA device location", natively integrated with a specific advertiser focused goals could allow for a unique advertising experience focused but needs to keep up with future regulation. Advertising requires a different type of consent versus existing API Working Group. The goal is for minimizing ad-fraud, blocking access to those without consent, helping users that have opt-ed out, and these APIs provide a new solution for the removal of the third party cookie. These new innovative insights provided by MNOs will streamline the $674B ad industry and trillion dollar forecasted AI Data Economy. CAMARA APIs provide "Measurement" capabilities that are a natural enhancement to advertisers and outputs like NEF provide measurement lift in physical retail media and paired SMPTE Relative Timestamps empower digital out of home advertisers with device exposure (Rideshares, billboards, and Points of interest). A different type of consent is needed. What is needed is a consent string that is compliant with Global Advertising Regulations and bridges the gap between Telecom and Ad Tech, that will empower other CAMARA APIs for new revenue generating opportunities and use cases. A conversion signal from "CarrierBillingCheckOut" (Purchase/digital transaction/click to call) enables both physical and digital transaction impact measurement, connecting mobile device <<>> ad exposure <<>> audience behavior <<>> business objectives. CAMARA's commitment to interoperability and compliance with industry standards is why we will be bringing both the IAB Tech Lab (Trade Organization) and Prebid (Trade Organization) to aide with our dedication to providing interoperability based on a standardized ecosystem leveraging a dynamic consent verification framework.
Technical viability The "Consent & Measurement" API family provides validated technical integrations with next generation ad tech and AI infrastructure, mass adoption potential with emerging industry standards, such as the Interactive Advertising Bureau (IAB) Tech Lab's. For MNOs and developers, this offers a path to long term viability, new revenue, and compliance across jurisdictions. By leveraging the scale of a standardized federated deployment, MNOs can reclaim revenue back from the tech industry that has created immense value on the back of the telecom infrastructure. By leveraging the structural advantages of the mobile network operators and provide a viable (if not superior alternative) to walled gardens (META / Google) "self-measurement" approach. CAMARA will uplift brands with greater transparency on ad measurement, the Consent and Measurement API will incentivize the adoption of the developer ecosystem with more ad revenue fueling innovation.
Commercial viability The "Consent & Measurement" API has been proposed to leading conglomerate consumer brands, tech platforms, sell side publishers, buy side ad exchanges, and advertising trade organizations to gauge viability and industry adoption. When considering the commercial viability of the "Consent & Measurement" API, interested industry leaders gave it a unanimous “Yes.” The interested parties include LinkedIn, Univision, Proctor and Gamble, IAB Tech Lab, and TradeDesk.
YAML code available? NO.
Validated in lab/productive environments? NO.
Validated with real customers? YES.
Validated with operators? NO. 
Supporters in API Backlog Working Group Will be added by the Working Group.

@nickvenezia
Copy link
Author

@jordonezlucena did I do this correctly?

@ShutingQing
Copy link
Contributor

Hi Nick, thanks for your proposal. The desciption of the API value is pretty clear. Meanwhile, I'll suggest to clarify more clear on the API input and output, or like which exactly the ability is, how API caller can utilize the API under which exact scenario. That would be helpful.

@nickvenezia
Copy link
Author

image

@nickvenezia
Copy link
Author

@ShutingQing let me know if the image I shared helps at all.

@TEF-RicardoSerr
Copy link
Contributor

TEF-RicardoSerr commented Mar 18, 2024

Hello Nick, @nickvenezia
I suggest you to fill the template with a couple of user stories and also define the scope in the template (eg. This API aims to cover the following use cases...).

Also Nick, I need you to attend the Backlog meetings for the API discussions before the aproval by the TSC

@nickvenezia
Copy link
Author

@TEF-RicardoSerr where can I find the link to the calendar invite for the API Backlog.

Have you looked at what I previously uploaded to the API Backlog folder for the presentations?

@nickvenezia
Copy link
Author

@ShutingQing, What else could we add to this list?

  1. SCEF
  2. SIP protocol
  3. SMPTE Relative Timestamp
  4. UPF
  5. NEF

These would all be relevant to help reduce ad fraud.

@ShutingQing
Copy link
Contributor

Hi @nickvenezia , thanks for your response. :) Humbly give you some advices, hopefully can help your proposal getting appoved.

As @TEF-RicardoSerr suggested, you can elaborate more on the API functions, scopes. Currently, in the table, API summary and techinical viability, we can't know how developers call the api, how the api helps developers under which scenario. This is the main problem.

I suggest you to fill the template with a couple of user stories and also define the scope in the template (eg. This API aims to cover the following use cases...).

Kindly find you some references, https://github.com/camaraproject/WorkingGroups/pulls?q=is%3Apr+is%3Aclosed . My humble suggestions for the proposals is:

  1. What's the API function?
    For example, API functions is like, 1) QoD is helping developers adjusting QoS, from device to the Server(of the APP). Instant QoS Asjustment. End users may enjoy QoS accerlation by calling QoD post/put API. 2) SIM SWAP API is checking the matching changes between mobile phone number (MSISDN) and SIM card (IMSI). --> What about this API?
  2. Scenario.
    Ad fraud scenario, what Ad fraud scenario specifically?
    For example, for SIM SWAP, since it is checking the matching history of MSISDN and IMSI. So by calling the API, API caller like banks, may know whether a customer who applied for a loan, is risky or not. Because, if a sim card is newly applied, then by calling SIM SWAP, banks can know. Then banks know here is a risky behavior. So SIM SWAP can helps on anti fraud scenario.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

New Proposal for Consent and Measurement
3 participants