https://wiki.prebid.org/api.php?action=feedcontributions&feedformat=atom&user=AdminUser 2026-05-25T22:55:15Z User contributions MediaWiki 1.35.0 https://wiki.prebid.org/index.php?title=Main_Page&diff=283 2021-01-25T19:52:41Z

<p>AdminUser: </p> <hr /> <div>&lt;strong&gt;Welcome to the Prebid Wiki!&lt;/strong&gt;<br /> <br /> This is the industry's premier place for information about programmatic media.<br /> <br /> == Prebid Wikipedia ==<br /> <br /> [[Prebid: About|About Prebid]]<br /> <br /> [[Prebid Members]]<br /> <br /> [[Prebid GitHub]]<br /> <br /> [[Prebid Membership]]<br /> <br /> [[Prebid Blog]]<br /> <br /> [[Prebid Products]]<br /> <br /> [[:Category:Prebid_Project_Management_Committeess|Prebid Project Management Committees]]<br /> <br /> [[:Category:Glossary|Glossary of Programmatic Topics]]<br /> <br /> == Getting started ==<br /> Consult the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents User's Guide] for information on using the wiki software.<br /> <br /> * [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]<br /> * [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]<br /> * [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]<br /> * [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]<br /> * [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]</div>

AdminUser https://wiki.prebid.org/index.php?title=Fledge&diff=280 2021-01-24T15:35:32Z

<p>AdminUser: /* Experiment Design */</p> <hr /> <div>Google's First Locally-Executed Decision over Groups Experiment (FLEDGE) is a proposal to measure the effectiveness of Google's [[Turtledove]] auction mechanism as being a viable replacement for the interoperable identifiers that support the decentralized, open web.&lt;ref&gt;https://github.com/WICG/turtledove/blob/master/FLEDGE.md&lt;/ref&gt; <br /> <br /> FLEDGE has a goal to quantify the economic impact of [[Turtledove]] on publishers. <br /> <br /> == Experiment Design ==<br /> FLEDGE will rely upon the following steps:<br /> <br /> * '''Pre-auction Audience Segmentation'''<br /> ** Marketers will periodically (maximum of once per day in this experiment) send two sets of information to a Google-specified endpoint <br /> *** The mechanics of sending this logic information are described by their forthcoming documentation on [[Worklet|worklets]].<br /> *** The first information set contains logic rules that determines marketer-defined audience segmentation<br /> **** Each Chrome browser will fetch marketer desired segmentation logic <br /> **** Each Chrome browser will processes each marketer's audience segmentation logic and return back with its unique identifier whether or not it qualifies for the audience segment to the Google-controlled server<br /> **** The Google-controlled server will count distinct number of identifiers belong to each audience segment <br /> ***** If the number of identifiers exceeds a Google-defined threshold, then this server will notify these browsers that they may use such audience segments for auction logic <br /> <br /> * '''Pre-auction Auction Desirability Logic''' <br /> ** In addition to audience segmentation logic, marketers will send logic to determines marketer auction desirability <br /> *** Marketer-specific desirability logic can include ad size, publisher domain, prior frequency of exposure to a give set of ads, and audience segmentation <br /> *** Marketers will also send budget information per campaign to a Google-controlled trusted server<br /> ** Each Chrome browser will separately request information from a Google-controlled trusted server to fetch marketer-specific desirability logic<br /> *** The Google-controlled trusted server will apply the marketer desirability logic to generate a bid for each combination of ad size, audience information and context information per campaign independent of current context<br /> <br /> * '''Pre-auction Publisher ad slot implementation'''<br /> ** Publishers will implement a [[Fenced Frames|Fenced Frame]] to query the browser APIs for ads and render the resulting ad <br /> *** After the experiment phase, the Fenced Frame will not communicate any information about the winning ad to the publisher<br /> ** Publishers will load into the Chrome browser logic called &quot;[[Worklet|worklets]]&quot; to select which bid response will win the on-device auction <br /> *** Publisher logic can adjust desirability of each bid response, based on price and other factors <br /> **** Publisher desirability logic can filter which marketer buying platforms can compete in the auction<br /> **** Publisher can also apply an out-of-band creative review process to be used as an input into this desirability logic <br /> <br /> * '''Auction Mechanics'''<br /> ** When triggered by the Fenced Frame, the Chrome browser will send a bid request to a limited number of marketers' buying platforms (e.g., DSPs) containing only the context of the given ad slot<br /> ** DSPs receiving the Chrome browser request for a bid will determine whether they want to return a bid response<br /> *** DSPs calculate in real-time the bid for a context-only ad, while the audience-out-of-context bid is calculated by the desirability logic they posted to the Google designated end point <br /> ** Publishers may also send to the Fenced Frame their most desirable ad from their own direct sales process, if they have one<br /> ** The Chrome browser conducts an on-device auction to determine a local winning ad<br /> *** The Chrome browser will filter the returned bids based on the presence of audience attributes <br /> *** The Chrome browser will apply the publisher desirability logic to first choose the on-device auction winning ad<br /> *** The Chrome browser will compare this ad to the direct-sold publisher, if any, and apply the publisher desirability logic to first choose the on-device auction winning ad<br /> <br /> * '''Post-auction'''<br /> ** During the experiment phase, the Chrome browser will send reporting data to per-specified publisher and buyer end points with event level data as to the outcome of the auction <br /> *** After the experiment phase, the Chrome browser will not send event-level data to the publisher or marketer <br /> ** Marketer buying platforms that lose auctions will get access to aggregate metrics on some yet to be determined, time-delayed basis<br /> <br /> == Impact ==<br /> Given FLEDGE's design, the following are impacts to marketing effectiveness will not be measured: <br /> <br /> * [[Cohort]] vs [[attribute]] level audience inputs to buyer algorithms <br /> * [[Aggregate Reporting API|Aggregate]] vs event-level feedback to buyer algorithms <br /> * Time-delayed vs real-time event-level feedback to buyer algorithms <br /> <br /> == Open Questions ==<br /> * What time delay, if any (e.g., on lost bids), will be used to quantify the impact of Turtledove on marketers' value of inventory? <br /> * What limits on marketer audience segmentation logic will be placed?<br /> * Why is Google mandating the order of operations which has the Chrome browser controlling the final auction, rather than the publisher's monetization platform (e.g., Publisher Ad Server or SSP) which otherwise could compare the locally winning ad and its bid price to other demand for this same ad slot and select the winning ad to render?<br /> * Who will pay for operating the Google-controlled servers that process marketer audience segmentation logic?<br /> * How can marketers and their agents protect their intellectual property from being disclosed to Google?<br /> * What is the maximum number of DSPs that can operate in the ecosystem under a model where the browser must directly contact each for bids?<br /> * What is the acceptable level of impairment to marketing effectiveness, such that marketers will not reduce payments to publishers? <br /> * Given publishers will be monetizing the same ad slot with existing monetization and Chrome-based monetization, how will the metrics associated with each be reported for comparison? <br /> * Why are we not also evaluating the metrics proposed by [[Teetar]], such as measuring experience and perception of users exposed to cohort-based advertising.<br /> <br /> == See Also ==<br /> <br /> [[Teetar]]<br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> <br /> [[Category:Glossary|Fledge]]<br /> [[Category:Privacy Sandbox|Fledge]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Fledge&diff=279 2021-01-24T15:32:49Z

<p>AdminUser: /* Experiment Design */</p> <hr /> <div>Google's First Locally-Executed Decision over Groups Experiment (FLEDGE) is a proposal to measure the effectiveness of Google's [[Turtledove]] auction mechanism as being a viable replacement for the interoperable identifiers that support the decentralized, open web.&lt;ref&gt;https://github.com/WICG/turtledove/blob/master/FLEDGE.md&lt;/ref&gt; <br /> <br /> FLEDGE has a goal to quantify the economic impact of [[Turtledove]] on publishers. <br /> <br /> == Experiment Design ==<br /> FLEDGE will rely upon the following steps:<br /> <br /> * '''Pre-auction Audience Segmentation'''<br /> ** Marketers will periodically (maximum of once per day in this experiment) send two sets of information to a Google-specified endpoint <br /> *** The mechanics of sending this logic information are described by their forthcoming documentation on [[Worklet|worklets]].<br /> *** The first information set contains logic rules that determines marketer-defined audience segmentation<br /> **** Each Chrome browser will fetch marketer desired segmentation logic <br /> **** Each Chrome browser will processes each marketer's audience segmentation logic and return back with its unique identifier whether or not it qualifies for the audience segment to the Google-controlled server<br /> **** The Google-controlled server will count distinct number of identifiers belong to each audience segment <br /> ***** If the number of identifiers exceeds a Google-defined threshold, then this server will notify these browsers that they may use such audience segments for auction logic <br /> <br /> * '''Pre-auction Auction Desirability Logic''' <br /> ** In addition to audience segmentation logic, marketers will send logic to determines marketer auction desirability <br /> *** Marketer-specific desirability logic can include ad size, publisher domain, prior frequency of exposure to a give set of ads, and audience segmentation <br /> *** Marketers will also send budget information per campaign to a Google-controlled trusted server<br /> ** Each Chrome browser will separately request information from a Google-controlled trusted server to fetch marketer-specific desirability logic<br /> *** The Google-controlled trusted server will apply the marketer desirability logic to generate a bid for each combination of ad size, audience information and context information per campaign independent of current context<br /> <br /> * '''Pre-auction Publisher ad slot implementation'''<br /> ** Publishers will implement a [[Fenced Frames|Fenced Frame]] to query the browser APIs for ads and render the resulting ad <br /> *** After the experiment phase, the Fenced Frame will not communicate any information about the winning ad to the publisher<br /> ** Publishers will load into the Chrome browser logic called &quot;[[Worklet|worklets]]&quot; to select which bid response will win the on-device auction <br /> *** Publisher logic can adjust desirability of each bid response, based on price and other factors <br /> **** Publisher desirability logic can filter which marketer buying platforms can compete in the auction<br /> **** Publisher can also apply an out-of-band creative review process to be used as an input into this desirability logic <br /> <br /> * '''Auction Mechanics'''<br /> ** When triggered by the Fenced Frame, the Chrome browser will send a bid request to a limited number of marketers' buying platforms (e.g., DSPs) containing only the context of the given ad slot<br /> ** DSPs receiving the Chrome browser request for a bid will determine whether they want to return a bid response<br /> *** DSPs will return separate bids for context-only and others based on each combination of attributes the browser may or may not contain <br /> ** Publishers may also send to the Fenced Frame their most desirable ad from their own direct sales process, if they have one<br /> ** The Chrome browser conducts an on-device auction to determine a local winning ad<br /> *** The Chrome browser will filter the returned bids based on the presence of audience attributes <br /> *** The Chrome browser will apply the publisher desirability logic to first choose the on-device auction winning ad<br /> *** The Chrome browser will compare this ad to the direct-sold publisher, if any, and apply the publisher desirability logic to first choose the on-device auction winning ad<br /> <br /> * '''Post-auction'''<br /> ** During this experiment, the browser will send reporting data to per-specified publisher and buyer end points with event level data as to the outcome of the auction <br /> *** After this experiment, the browser will not send event-level data to the publisher or marketer <br /> ** Marketer buying platforms that lose auctions will get access to aggregate metrics on some time-delayed basis<br /> <br /> == Impact ==<br /> Given FLEDGE's design, the following are impacts to marketing effectiveness will not be measured: <br /> <br /> * [[Cohort]] vs [[attribute]] level audience inputs to buyer algorithms <br /> * [[Aggregate Reporting API|Aggregate]] vs event-level feedback to buyer algorithms <br /> * Time-delayed vs real-time event-level feedback to buyer algorithms <br /> <br /> == Open Questions ==<br /> * What time delay, if any (e.g., on lost bids), will be used to quantify the impact of Turtledove on marketers' value of inventory? <br /> * What limits on marketer audience segmentation logic will be placed?<br /> * Why is Google mandating the order of operations which has the Chrome browser controlling the final auction, rather than the publisher's monetization platform (e.g., Publisher Ad Server or SSP) which otherwise could compare the locally winning ad and its bid price to other demand for this same ad slot and select the winning ad to render?<br /> * Who will pay for operating the Google-controlled servers that process marketer audience segmentation logic?<br /> * How can marketers and their agents protect their intellectual property from being disclosed to Google?<br /> * What is the maximum number of DSPs that can operate in the ecosystem under a model where the browser must directly contact each for bids?<br /> * What is the acceptable level of impairment to marketing effectiveness, such that marketers will not reduce payments to publishers? <br /> * Given publishers will be monetizing the same ad slot with existing monetization and Chrome-based monetization, how will the metrics associated with each be reported for comparison? <br /> * Why are we not also evaluating the metrics proposed by [[Teetar]], such as measuring experience and perception of users exposed to cohort-based advertising.<br /> <br /> == See Also ==<br /> <br /> [[Teetar]]<br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> <br /> [[Category:Glossary|Fledge]]<br /> [[Category:Privacy Sandbox|Fledge]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Fledge&diff=278 2021-01-24T15:32:27Z

<p>AdminUser: /* Open Questions */</p> <hr /> <div>Google's First Locally-Executed Decision over Groups Experiment (FLEDGE) is a proposal to measure the effectiveness of Google's [[Turtledove]] auction mechanism as being a viable replacement for the interoperable identifiers that support the decentralized, open web.&lt;ref&gt;https://github.com/WICG/turtledove/blob/master/FLEDGE.md&lt;/ref&gt; <br /> <br /> FLEDGE has a goal to quantify the economic impact of [[Turtledove]] on publishers. <br /> <br /> == Experiment Design ==<br /> FLEDGE will rely upon the following steps:<br /> <br /> * '''Pre-auction Audience Segmentation'''<br /> ** Marketers will periodically (maximum of once per day in this experiment) send two sets of information to a Google-specified endpoint <br /> *** The mechanics of sending this logic information are described by their forthcoming documentation on [[Worklet|worklets]].<br /> *** The first information set contains logic rules that determines marketer-defined audience segmentation<br /> **** Each Chrome browser will fetch marketer desired segmentation logic <br /> **** Each Chrome browser will processes each marketer's audience segmentation logic and return back with its unique identifier whether or not it qualifies for the audience segment to the Google-controlled server<br /> **** The Google-controlled server will count distinct number of identifiers belong to each audience segment <br /> ***** If the number of identifiers exceeds a Google-defined threshold, then this server will notify these browsers that they may use such audience segments for auction logic <br /> <br /> * '''Pre-auction Auction Desirability Logic''' <br /> ** In addition to audience segmentation logic, marketers will send logic to determines marketer auction desirability <br /> *** Marketer-specific desirability logic can include ad size, publisher domain, prior frequency of exposure to a give set of ads, and audience segmentation <br /> *** Marketers will also send budget information per campaign to a Google-controlled trusted server<br /> ** Each Chrome browser will separately request information from a Google-controlled trusted server to fetch marketer-specific desirability logic<br /> *** The Google-controlled trusted server will apply the marketer desirability logic to generate a bid for each combination of ad size, audience information and context information per campaign independent of current context<br /> <br /> * '''Pre-auction Publisher ad slot implementation'''<br /> ** Publishers will implement a [[Fenced Frame]] to query the browser APIs for ads and render the resulting ad <br /> *** After the experiment phase, the Fenced Frame will not communicate any information about the winning ad to the publisher<br /> ** Publishers will load into the Chrome browser logic called &quot;[[Worklet|worklets]]&quot; to select which bid response will win the on-device auction <br /> *** Publisher logic can adjust desirability of each bid response, based on price and other factors <br /> **** Publisher desirability logic can filter which marketer buying platforms can compete in the auction<br /> **** Publisher can also apply an out-of-band creative review process to be used as an input into this desirability logic <br /> <br /> * '''Auction Mechanics'''<br /> ** When triggered by the Fenced Frame, the Chrome browser will send a bid request to a limited number of marketers' buying platforms (e.g., DSPs) containing only the context of the given ad slot<br /> ** DSPs receiving the Chrome browser request for a bid will determine whether they want to return a bid response<br /> *** DSPs will return separate bids for context-only and others based on each combination of attributes the browser may or may not contain <br /> ** Publishers may also send to the Fenced Frame their most desirable ad from their own direct sales process, if they have one<br /> ** The Chrome browser conducts an on-device auction to determine a local winning ad<br /> *** The Chrome browser will filter the returned bids based on the presence of audience attributes <br /> *** The Chrome browser will apply the publisher desirability logic to first choose the on-device auction winning ad<br /> *** The Chrome browser will compare this ad to the direct-sold publisher, if any, and apply the publisher desirability logic to first choose the on-device auction winning ad<br /> <br /> * '''Post-auction'''<br /> ** During this experiment, the browser will send reporting data to per-specified publisher and buyer end points with event level data as to the outcome of the auction <br /> *** After this experiment, the browser will not send event-level data to the publisher or marketer <br /> ** Marketer buying platforms that lose auctions will get access to aggregate metrics on some time-delayed basis<br /> <br /> == Impact ==<br /> Given FLEDGE's design, the following are impacts to marketing effectiveness will not be measured: <br /> <br /> * [[Cohort]] vs [[attribute]] level audience inputs to buyer algorithms <br /> * [[Aggregate Reporting API|Aggregate]] vs event-level feedback to buyer algorithms <br /> * Time-delayed vs real-time event-level feedback to buyer algorithms <br /> <br /> == Open Questions ==<br /> * What time delay, if any (e.g., on lost bids), will be used to quantify the impact of Turtledove on marketers' value of inventory? <br /> * What limits on marketer audience segmentation logic will be placed?<br /> * Why is Google mandating the order of operations which has the Chrome browser controlling the final auction, rather than the publisher's monetization platform (e.g., Publisher Ad Server or SSP) which otherwise could compare the locally winning ad and its bid price to other demand for this same ad slot and select the winning ad to render?<br /> * Who will pay for operating the Google-controlled servers that process marketer audience segmentation logic?<br /> * How can marketers and their agents protect their intellectual property from being disclosed to Google?<br /> * What is the maximum number of DSPs that can operate in the ecosystem under a model where the browser must directly contact each for bids?<br /> * What is the acceptable level of impairment to marketing effectiveness, such that marketers will not reduce payments to publishers? <br /> * Given publishers will be monetizing the same ad slot with existing monetization and Chrome-based monetization, how will the metrics associated with each be reported for comparison? <br /> * Why are we not also evaluating the metrics proposed by [[Teetar]], such as measuring experience and perception of users exposed to cohort-based advertising.<br /> <br /> == See Also ==<br /> <br /> [[Teetar]]<br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> <br /> [[Category:Glossary|Fledge]]<br /> [[Category:Privacy Sandbox|Fledge]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Fledge&diff=277 2021-01-24T15:32:05Z

<p>AdminUser: /* Experiment Design */</p> <hr /> <div>Google's First Locally-Executed Decision over Groups Experiment (FLEDGE) is a proposal to measure the effectiveness of Google's [[Turtledove]] auction mechanism as being a viable replacement for the interoperable identifiers that support the decentralized, open web.&lt;ref&gt;https://github.com/WICG/turtledove/blob/master/FLEDGE.md&lt;/ref&gt; <br /> <br /> FLEDGE has a goal to quantify the economic impact of [[Turtledove]] on publishers. <br /> <br /> == Experiment Design ==<br /> FLEDGE will rely upon the following steps:<br /> <br /> * '''Pre-auction Audience Segmentation'''<br /> ** Marketers will periodically (maximum of once per day in this experiment) send two sets of information to a Google-specified endpoint <br /> *** The mechanics of sending this logic information are described by their forthcoming documentation on [[Worklet|worklets]].<br /> *** The first information set contains logic rules that determines marketer-defined audience segmentation<br /> **** Each Chrome browser will fetch marketer desired segmentation logic <br /> **** Each Chrome browser will processes each marketer's audience segmentation logic and return back with its unique identifier whether or not it qualifies for the audience segment to the Google-controlled server<br /> **** The Google-controlled server will count distinct number of identifiers belong to each audience segment <br /> ***** If the number of identifiers exceeds a Google-defined threshold, then this server will notify these browsers that they may use such audience segments for auction logic <br /> <br /> * '''Pre-auction Auction Desirability Logic''' <br /> ** In addition to audience segmentation logic, marketers will send logic to determines marketer auction desirability <br /> *** Marketer-specific desirability logic can include ad size, publisher domain, prior frequency of exposure to a give set of ads, and audience segmentation <br /> *** Marketers will also send budget information per campaign to a Google-controlled trusted server<br /> ** Each Chrome browser will separately request information from a Google-controlled trusted server to fetch marketer-specific desirability logic<br /> *** The Google-controlled trusted server will apply the marketer desirability logic to generate a bid for each combination of ad size, audience information and context information per campaign independent of current context<br /> <br /> * '''Pre-auction Publisher ad slot implementation'''<br /> ** Publishers will implement a [[Fenced Frame]] to query the browser APIs for ads and render the resulting ad <br /> *** After the experiment phase, the Fenced Frame will not communicate any information about the winning ad to the publisher<br /> ** Publishers will load into the Chrome browser logic called &quot;[[Worklet|worklets]]&quot; to select which bid response will win the on-device auction <br /> *** Publisher logic can adjust desirability of each bid response, based on price and other factors <br /> **** Publisher desirability logic can filter which marketer buying platforms can compete in the auction<br /> **** Publisher can also apply an out-of-band creative review process to be used as an input into this desirability logic <br /> <br /> * '''Auction Mechanics'''<br /> ** When triggered by the Fenced Frame, the Chrome browser will send a bid request to a limited number of marketers' buying platforms (e.g., DSPs) containing only the context of the given ad slot<br /> ** DSPs receiving the Chrome browser request for a bid will determine whether they want to return a bid response<br /> *** DSPs will return separate bids for context-only and others based on each combination of attributes the browser may or may not contain <br /> ** Publishers may also send to the Fenced Frame their most desirable ad from their own direct sales process, if they have one<br /> ** The Chrome browser conducts an on-device auction to determine a local winning ad<br /> *** The Chrome browser will filter the returned bids based on the presence of audience attributes <br /> *** The Chrome browser will apply the publisher desirability logic to first choose the on-device auction winning ad<br /> *** The Chrome browser will compare this ad to the direct-sold publisher, if any, and apply the publisher desirability logic to first choose the on-device auction winning ad<br /> <br /> * '''Post-auction'''<br /> ** During this experiment, the browser will send reporting data to per-specified publisher and buyer end points with event level data as to the outcome of the auction <br /> *** After this experiment, the browser will not send event-level data to the publisher or marketer <br /> ** Marketer buying platforms that lose auctions will get access to aggregate metrics on some time-delayed basis<br /> <br /> == Impact ==<br /> Given FLEDGE's design, the following are impacts to marketing effectiveness will not be measured: <br /> <br /> * [[Cohort]] vs [[attribute]] level audience inputs to buyer algorithms <br /> * [[Aggregate Reporting API|Aggregate]] vs event-level feedback to buyer algorithms <br /> * Time-delayed vs real-time event-level feedback to buyer algorithms <br /> <br /> == Open Questions ==<br /> * What time delay, if any (e.g., on lost bids), will be used to quantify the impact of Turtledove on marketers' value of inventory? <br /> * What limits on marketer audience segmentation logic will be placed?<br /> * Who will pay for operating the Google-controlled servers that process marketer audience segmentation logic?<br /> * How can marketers and their agents protect their intellectual property from being disclosed to Google?<br /> * What is the maximum number of DSPs that can operate in the ecosystem under a model where the browser must directly contact each for bids?<br /> * What is the acceptable level of impairment to marketing effectiveness, such that marketers will not reduce payments to publishers? <br /> * Given publishers will be monetizing the same ad slot with existing monetization and Chrome-based monetization, how will the metrics associated with each be reported for comparison? <br /> * Why are we not also evaluating the metrics proposed by [[Teetar]], such as measuring experience and perception of users exposed to cohort-based advertising.<br /> <br /> == See Also ==<br /> <br /> [[Teetar]]<br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> <br /> [[Category:Glossary|Fledge]]<br /> [[Category:Privacy Sandbox|Fledge]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Fledge&diff=276 2021-01-24T15:20:41Z

<p>AdminUser: /* Experiment Design */</p> <hr /> <div>Google's First Locally-Executed Decision over Groups Experiment (FLEDGE) is a proposal to measure the effectiveness of Google's [[Turtledove]] auction mechanism as being a viable replacement for the interoperable identifiers that support the decentralized, open web.&lt;ref&gt;https://github.com/WICG/turtledove/blob/master/FLEDGE.md&lt;/ref&gt; <br /> <br /> FLEDGE has a goal to quantify the economic impact of [[Turtledove]] on publishers. <br /> <br /> == Experiment Design ==<br /> FLEDGE will rely upon the following steps:<br /> <br /> * Pre-auction Audience Segmentation<br /> ** Marketers will periodically (maximum of once per day in this experiment) send two sets of information to a Google-specified endpoint <br /> *** The mechanics of sending this information are described by their forthcoming documentation on [[Worklet|worklets]].<br /> *** The first information set is a set of logic rules that determines marketer-defined audience segmentation<br /> **** The Google-controlled server will send the audience segmentation logic to each Chrome browser<br /> **** Each browser will processes each marketer's audience segmentation logic and return back with its unique identifier whether or not it qualifies for the audience segment to the Google-controlled server<br /> **** The Google-controlled server will count distinct number of identifiers belong to each audience segment <br /> **** If the number of identifiers exceeds a Google-defined threshold, then this server will notify these browsers that they may use such audience segments for auction logic <br /> * Pre-auction Auction Desirability Logic <br /> ** In addition to audience segmentation logic, marketers will send logic to determines marketer auction desirability <br /> *** Marketer-specific desirability logic can include ad size, publisher domain, prior frequency of exposure to a give set of ads, and audience attributes <br /> *** Marketers will also send budget information per campaign to a Google-controlled trusted server<br /> ** The browser will separately request information from a Google-controlled trusted server to fetch marketer-specific desirability logic<br /> *** The Google-controlled trusted server will apply the marketer desirability logic to generate a bid for each combination of ad size, audience information and context information per campaign independent of current context<br /> * Pre-auction Publisher ad slot implementation<br /> ** Publishers will implement a Fenced Frame to query the browser APIs for ads and render the resulting ad <br /> *** The Fenced Frame will not communicate any information about the winning ad to the publisher<br /> ** Publishers will load into the browser logic called &quot;[[Worklet|worklets]]&quot; to select which bid response will win the on-device auction <br /> *** Publisher logic can adjust desirability of each bid response, based on price and other factors <br /> *** Publisher desirability logic can filter which marketer buying platforms can compete in the auction<br /> *** Publisher can apply an out-of-band creative review process to be used as an input into this desirability logic <br /> * Auction Mechanics<br /> ** When triggered by the Fenced Frame, the browser will send a bid request to a limited number of marketers' buying platforms (e.g., DSPs) containing only the context of the given ad slot<br /> ** DSPs receiving the browser request for a bid will determine whether they want to return a bid response<br /> *** DSPs will return separate bids for context-only and others based on each combination of attributes the browser may or may not contain <br /> ** The browser conducts an on-device auction to determine a local winning ad<br /> *** The browser will filter the returned bids based on the presence of audience attributes <br /> *** The browser will apply the publisher desirability logic to return the on-device auction winning ad<br /> ** The publisher's monetization platform (e.g., Publisher Ad Server or SSP) will compare this ad and its bid price to other demand for this same ad slot and select the winning ad to render<br /> * Post-auction<br /> ** During this experiment, the browser will send reporting data to per-specified publisher and buyer end points with event level data as to the outcome of the auction <br /> *** After this experiment, the browser will not send event-level data to the publisher or marketer <br /> ** Marketer buying platforms that lose auctions will get access to aggregate metrics on some time-delayed basis<br /> <br /> == Impact ==<br /> Given FLEDGE's design, the following are impacts to marketing effectiveness will not be measured: <br /> <br /> * [[Cohort]] vs [[attribute]] level audience inputs to buyer algorithms <br /> * [[Aggregate Reporting API|Aggregate]] vs event-level feedback to buyer algorithms <br /> * Time-delayed vs real-time event-level feedback to buyer algorithms <br /> <br /> == Open Questions ==<br /> * What time delay, if any (e.g., on lost bids), will be used to quantify the impact of Turtledove on marketers' value of inventory? <br /> * What limits on marketer audience segmentation logic will be placed?<br /> * Who will pay for operating the Google-controlled servers that process marketer audience segmentation logic?<br /> * How can marketers and their agents protect their intellectual property from being disclosed to Google?<br /> * What is the maximum number of DSPs that can operate in the ecosystem under a model where the browser must directly contact each for bids?<br /> * What is the acceptable level of impairment to marketing effectiveness, such that marketers will not reduce payments to publishers? <br /> * Given publishers will be monetizing the same ad slot with existing monetization and Chrome-based monetization, how will the metrics associated with each be reported for comparison? <br /> * Why are we not also evaluating the metrics proposed by [[Teetar]], such as measuring experience and perception of users exposed to cohort-based advertising.<br /> <br /> == See Also ==<br /> <br /> [[Teetar]]<br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> <br /> [[Category:Glossary|Fledge]]<br /> [[Category:Privacy Sandbox|Fledge]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Worklet&diff=275 2021-01-24T15:19:16Z

<p>AdminUser: Created page with &quot;A worklet is a self-contained logic processing service that executes within Chrome browsers. Each worklet is associated with a single domain, and runs code written by either a...&quot;</p> <hr /> <div>A worklet is a self-contained logic processing service that executes within Chrome browsers. Each worklet is associated with a single domain, and runs code written by either a buyer or a seller.&lt;ref&gt;https://github.com/WICG/turtledove/blob/master/FLEDGE.md&lt;/ref&gt; <br /> <br /> == Loading logic into the browser ==<br /> Buyers and sellers post their desired logic to a well-known URL from which the browser will fetch the logic and potentially implement. <br /> <br /> Google has not yet specified whether the well-known location will be a Google-controlled server or a URL controlled by the buyer or seller. <br /> <br /> Google has not yet specified how buyers or sellers would receive feedback on the following:<br /> <br /> # Whether Google approved their logic for application in a Chrome browser worklet (useful for QA)<br /> <br /> # How many browsers have applied this logic (useful for QA)<br /> <br /> # How many browsers qualify for each output of this logic (useful for planning)<br /> <br /> == Restricted functions ==<br /> To prevent buyers or sellers from combining information outside of Google's control, the code in the worklets cannot access or communicate with the publisher page or the network. <br /> <br /> == See Also ==<br /> * [[Fledge]]<br /> * [[Turtledove]]<br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Worklet]]<br /> [[Category:Privacy Sandbox|Worklet]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Fledge&diff=274 2021-01-24T15:09:52Z

<p>AdminUser: /* Experiment Design */</p> <hr /> <div>Google's First Locally-Executed Decision over Groups Experiment (FLEDGE) is a proposal to measure the effectiveness of Google's [[Turtledove]] auction mechanism as being a viable replacement for the interoperable identifiers that support the decentralized, open web.&lt;ref&gt;https://github.com/WICG/turtledove/blob/master/FLEDGE.md&lt;/ref&gt; <br /> <br /> FLEDGE has a goal to quantify the economic impact of [[Turtledove]] on publishers. <br /> <br /> == Experiment Design ==<br /> FLEDGE will rely upon the following steps:<br /> <br /> * Pre-auction Audience Segmentation<br /> ** Marketers will periodically (maximum of once per day in this experiment) send two sets of information to a Google-controlled server <br /> *** The first information set is a set of logic rules that determines marketer-defined audience segmentation<br /> **** The Google-controlled server will send the audience segmentation logic to each Chrome browser<br /> **** Each browser will processes each marketer's audience segmentation logic and return back with its unique identifier whether or not it qualifies for the audience segment to the Google-controlled server<br /> **** The Google-controlled server will count distinct number of identifiers belong to each audience segment <br /> **** If the number of identifiers exceeds a Google-defined threshold, then this server will notify these browsers that they may use such audience segments for auction logic <br /> * Pre-auction Auction Desirability Logic <br /> ** In addition to audience segmentation logic, marketers will send logic to determines marketer auction desirability <br /> *** Marketer-specific desirability logic can include ad size, publisher domain, prior frequency of exposure to a give set of ads, and audience attributes <br /> *** Marketers will also send budget information per campaign to a Google-controlled trusted server<br /> ** The browser will separately request information from a Google-controlled trusted server to fetch marketer-specific desirability logic<br /> *** The Google-controlled trusted server will apply the marketer desirability logic to generate a bid for each combination of ad size, audience information and context information per campaign independent of current context<br /> * Pre-auction Publisher ad slot implementation<br /> ** Publishers will implement a Fenced Frame to query the browser APIs for ads and render the resulting ad <br /> *** The Fenced Frame will not communicate any information about the winning ad to the publisher<br /> ** Publishers will load into the browser logic called &quot;[[Worklet|worklets]]&quot; to select which bid response will win the on-device auction <br /> *** Publisher logic can adjust desirability of each bid response, based on price and other factors <br /> *** Publisher desirability logic can filter which marketer buying platforms can compete in the auction<br /> *** Publisher can apply an out-of-band creative review process to be used as an input into this desirability logic <br /> * Auction Mechanics<br /> ** When triggered by the Fenced Frame, the browser will send a bid request to a limited number of marketers' buying platforms (e.g., DSPs) containing only the context of the given ad slot<br /> ** DSPs receiving the browser request for a bid will determine whether they want to return a bid response<br /> *** DSPs will return separate bids for context-only and others based on each combination of attributes the browser may or may not contain <br /> ** The browser conducts an on-device auction to determine a local winning ad<br /> *** The browser will filter the returned bids based on the presence of audience attributes <br /> *** The browser will apply the publisher desirability logic to return the on-device auction winning ad<br /> ** The publisher's monetization platform (e.g., Publisher Ad Server or SSP) will compare this ad and its bid price to other demand for this same ad slot and select the winning ad to render<br /> * Post-auction<br /> ** During this experiment, the browser will send reporting data to per-specified publisher and buyer end points with event level data as to the outcome of the auction <br /> *** After this experiment, the browser will not send event-level data to the publisher or marketer <br /> ** Marketer buying platforms that lose auctions will get access to aggregate metrics on some time-delayed basis<br /> <br /> == Impact ==<br /> Given FLEDGE's design, the following are impacts to marketing effectiveness will not be measured: <br /> <br /> * [[Cohort]] vs [[attribute]] level audience inputs to buyer algorithms <br /> * [[Aggregate Reporting API|Aggregate]] vs event-level feedback to buyer algorithms <br /> * Time-delayed vs real-time event-level feedback to buyer algorithms <br /> <br /> == Open Questions ==<br /> * What time delay, if any (e.g., on lost bids), will be used to quantify the impact of Turtledove on marketers' value of inventory? <br /> * What limits on marketer audience segmentation logic will be placed?<br /> * Who will pay for operating the Google-controlled servers that process marketer audience segmentation logic?<br /> * How can marketers and their agents protect their intellectual property from being disclosed to Google?<br /> * What is the maximum number of DSPs that can operate in the ecosystem under a model where the browser must directly contact each for bids?<br /> * What is the acceptable level of impairment to marketing effectiveness, such that marketers will not reduce payments to publishers? <br /> * Given publishers will be monetizing the same ad slot with existing monetization and Chrome-based monetization, how will the metrics associated with each be reported for comparison? <br /> * Why are we not also evaluating the metrics proposed by [[Teetar]], such as measuring experience and perception of users exposed to cohort-based advertising.<br /> <br /> == See Also ==<br /> <br /> [[Teetar]]<br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> <br /> [[Category:Glossary|Fledge]]<br /> [[Category:Privacy Sandbox|Fledge]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Spurfowl&diff=273 2021-01-23T23:57:23Z

<p>AdminUser: </p> <hr /> <div>Nextroll's Sandboxed Private User Reporting Functions Operating Within Limits (Spurfowl) is designed to support reporting needs of marketers on various activity trails.&lt;ref&gt;https://github.com/AdRoll/privacy/blob/main/SPURFOWL.md&lt;/ref&gt; <br /> <br /> Spurfowl is designed to support reporting on both [[Multi-touch attribution]] and A/B Testing, provided browsers can be assigned to particular marketer-defined audience segments.<br /> <br /> Spurfowl sends locally computed metrics to a trusted server on a time-delayed basis.<br /> <br /> == Impact ==<br /> Spurfowl provides time-delayed information which impairs the accuracy of information ingested by marketer algorithms as well as their effectiveness.<br /> <br /> By disclosing audience information, publishers and buyers are leaking their intellectual property associated with that web client (e.g., high value customer) to anyone with access to the web client.<br /> <br /> == Open Questions ==<br /> * How will distinct count metrics be computed? <br /> * How much history associated with activity trails be stored in the browser? <br /> * How many different organizations can ask the browser to calculate counts or conduct logic without impairing local client processing? <br /> * How frequently can different organizations can ask the browser to calculate counts or conduct logic without impairing local client processing? <br /> * How do organizations aggregate the information that was individually computed on each browser?<br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Spurfowl]]<br /> [[Category:Privacy Sandbox|Spurfowl]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Spurfowl&diff=272 2021-01-23T23:54:33Z

<p>AdminUser: </p> <hr /> <div>Nextroll's Sandboxed Private User Reporting Functions Operating Within Limits (Spurfowl) is designed to support reporting needs of marketers on various activity trails.&lt;ref&gt;https://github.com/AdRoll/privacy/blob/main/SPURFOWL.md&lt;/ref&gt; <br /> <br /> Spurfowl is designed to support reporting on both [[Multi-touch attribution]] and A/B Testing, provided browsers can be assigned to particular marketer-defined audience segments.<br /> <br /> Spurfow sends locally computed metrics to a trusted server on a time-delayed basis.<br /> <br /> == Impact ==<br /> Spurfowl provides time-delayed information which impairs the accuracy of information ingested by marketer algorithms as well as their effectiveness.<br /> <br /> By disclosing audience information, publishers and buyers are leaking their intellectual property associated with that web client (e.g., high value customer) to anyone with access to the web client.<br /> <br /> == Open Questions ==<br /> * How will distinct count metrics be computed? <br /> * How much history associated with activity trails be stored in the browser? <br /> * How many different organizations can ask the browser to calculate counts or conduct logic without impairing local client processing? <br /> * How frequently can different organizations can ask the browser to calculate counts or conduct logic without impairing local client processing? <br /> * How do organizations aggregate the information that was individually computed on each browser?<br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Spurfowl]]<br /> [[Category:Privacy Sandbox|Spurfowl]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Spurfowl&diff=271 2021-01-23T23:54:09Z

<p>AdminUser: /* Open Questions */</p> <hr /> <div>Nextroll's Sandboxed Private User Reporting Functions Operating Within Limits (Spurfowl) is designed to support reporting needs of marketers on various activity trails.&lt;ref&gt;https://github.com/AdRoll/privacy/blob/main/SPURFOWL.md&lt;/ref&gt; <br /> <br /> Spurfowl is designed to support reporting on both [[Multi-touch Attribution]] and A/B Testing, provided browsers can be assigned to particular marketer-defined audience segments.<br /> <br /> Spurfow sends locally computed metrics to a trusted server on a time-delayed basis.<br /> <br /> == Impact ==<br /> Spurfowl provides time-delayed information which impairs the accuracy of information ingested by marketer algorithms as well as their effectiveness.<br /> <br /> By disclosing audience information, publishers and buyers are leaking their intellectual property associated with that web client (e.g., high value customer) to anyone with access to the web client.<br /> <br /> == Open Questions ==<br /> * How will distinct count metrics be computed? <br /> * How much history associated with activity trails be stored in the browser? <br /> * How many different organizations can ask the browser to calculate counts or conduct logic without impairing local client processing? <br /> * How frequently can different organizations can ask the browser to calculate counts or conduct logic without impairing local client processing? <br /> * How do organizations aggregate the information that was individually computed on each browser?<br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Spurfowl]]<br /> [[Category:Privacy Sandbox|Spurfowl]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Spurfowl&diff=270 2021-01-23T23:54:00Z

<p>AdminUser: /* Impact */</p> <hr /> <div>Nextroll's Sandboxed Private User Reporting Functions Operating Within Limits (Spurfowl) is designed to support reporting needs of marketers on various activity trails.&lt;ref&gt;https://github.com/AdRoll/privacy/blob/main/SPURFOWL.md&lt;/ref&gt; <br /> <br /> Spurfowl is designed to support reporting on both [[Multi-touch Attribution]] and A/B Testing, provided browsers can be assigned to particular marketer-defined audience segments.<br /> <br /> Spurfow sends locally computed metrics to a trusted server on a time-delayed basis.<br /> <br /> == Impact ==<br /> Spurfowl provides time-delayed information which impairs the accuracy of information ingested by marketer algorithms as well as their effectiveness.<br /> <br /> By disclosing audience information, publishers and buyers are leaking their intellectual property associated with that web client (e.g., high value customer) to anyone with access to the web client.<br /> <br /> == Open Questions ==<br /> * How will distinct count metrics be computed? <br /> * How much history associated with activity trails be stored in the browser? <br /> * How many different organizations can ask the browser to calculate counts or conduct logic without impairing local client processing? <br /> * How frequently can different organizations can ask the browser to calculate counts or conduct logic without impairing local client processing? <br /> * How do organizations aggregate the information that was individually computed on each browser?<br /> * How do organizations protect their intellectual property from leaking to competitors?<br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Spurfowl]]<br /> [[Category:Privacy Sandbox|Spurfowl]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Multi-touch_attribution&diff=269 2021-01-23T23:53:05Z

<p>AdminUser: /* See Also */</p> <hr /> <div>Multi-touch attribution calculates the incremental value of different prior exposures in driving a marketer's desired outcome. <br /> <br /> == See Also ==<br /> * [[Attribution]]<br /> <br /> [[Category:Glossary|Multi-touch Attribution]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Multi-touch_attribution&diff=268 2021-01-23T23:52:55Z

<p>AdminUser: Created page with &quot;Multi-touch attribution calculates the incremental value of different prior exposures in driving a marketer's desired outcome. == See Also == * Attribution Category:Gloss...&quot;</p> <hr /> <div>Multi-touch attribution calculates the incremental value of different prior exposures in driving a marketer's desired outcome. <br /> <br /> == See Also ==<br /> * Attribution<br /> <br /> [[Category:Glossary|Multi-touch Attribution]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Attribution&diff=267 2021-01-23T23:49:53Z

<p>AdminUser: </p> <hr /> <div>The process of identifying which events (e.g., impressions and/or clicks) should be associated with influencing a subsequent conversion. Several different attribution models exist that can determine how much credit will be given to previous events. Last click/view attribution models (also known as last seen) give all of the credit to the most recent event prior to the conversion. First click/view attribution gives all of the credit to the first impression delivered to the user. Fractional Attribution gives some amount of credit to each of the prior events associated that a user's subsequent conversion. <br /> <br /> == See Also ==<br /> * [[Multi-touch attribution]]<br /> <br /> [[Category:Glossary|Attribution]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Spurfowl&diff=266 2021-01-23T23:49:12Z

<p>AdminUser: /* Open Questions */</p> <hr /> <div>Nextroll's Sandboxed Private User Reporting Functions Operating Within Limits (Spurfowl) is designed to support reporting needs of marketers on various activity trails.&lt;ref&gt;https://github.com/AdRoll/privacy/blob/main/SPURFOWL.md&lt;/ref&gt; <br /> <br /> Spurfowl is designed to support reporting on both [[Multi-touch Attribution]] and A/B Testing, provided browsers can be assigned to particular marketer-defined audience segments.<br /> <br /> Spurfow sends locally computed metrics to a trusted server on a time-delayed basis.<br /> <br /> == Impact ==<br /> Spurfowl provides time-delayed information which impairs the accuracy of information ingested by marketer algorithms as well as their effectiveness. <br /> <br /> == Open Questions ==<br /> * How will distinct count metrics be computed? <br /> * How much history associated with activity trails be stored in the browser? <br /> * How many different organizations can ask the browser to calculate counts or conduct logic without impairing local client processing? <br /> * How frequently can different organizations can ask the browser to calculate counts or conduct logic without impairing local client processing? <br /> * How do organizations aggregate the information that was individually computed on each browser?<br /> * How do organizations protect their intellectual property from leaking to competitors?<br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Spurfowl]]<br /> [[Category:Privacy Sandbox|Spurfowl]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Spurfowl&diff=265 2021-01-23T23:48:43Z

<p>AdminUser: Created page with &quot;Nextroll's Sandboxed Private User Reporting Functions Operating Within Limits (Spurfowl) is designed to support reporting needs of marketers on various activity trails.&lt;ref&gt;ht...&quot;</p> <hr /> <div>Nextroll's Sandboxed Private User Reporting Functions Operating Within Limits (Spurfowl) is designed to support reporting needs of marketers on various activity trails.&lt;ref&gt;https://github.com/AdRoll/privacy/blob/main/SPURFOWL.md&lt;/ref&gt; <br /> <br /> Spurfowl is designed to support reporting on both [[Multi-touch Attribution]] and A/B Testing, provided browsers can be assigned to particular marketer-defined audience segments.<br /> <br /> Spurfow sends locally computed metrics to a trusted server on a time-delayed basis.<br /> <br /> == Impact ==<br /> Spurfowl provides time-delayed information which impairs the accuracy of information ingested by marketer algorithms as well as their effectiveness. <br /> <br /> == Open Questions ==<br /> * How will distinct count metrics be computed? <br /> * How much history associated with activity trails be stored in the browser? <br /> * How many different organizations can ask the browser to calculate counts or conduct logic without impairing local client processing? <br /> * How frequently can different organizations can ask the browser to calculate counts or conduct logic without impairing local client processing? <br /> * How do organizations aggregate the information that was individually computed on each browser? <br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Spurfowl]]<br /> [[Category:Privacy Sandbox|Spurfowl]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Category:Privacy_Sandbox&diff=264 2021-01-23T23:38:37Z

<p>AdminUser: /* Reporting Projects */</p> <hr /> <div>Privacy Sandbox is a set of proprietary Chrome browser APIs that provide information to buyers and sellers of digital media.&lt;ref&gt;https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers&lt;/ref&gt; Many of these APIs rely on server-side components. <br /> <br /> This page lists Google Privacy Sandbox projects as well as proposed modifications to these projects to better meet the needs of publishers and marketers. When an organization other than Google is proposing a project in the list below there name appears in parentheses. <br /> <br /> == Media Planning Projects == <br /> Given a goal of the Privacy Sandbox is to prevent marketers from understanding which audiences are interacting across different publishers, this will not be directly addressed by this project. <br /> <br /> == Experience Management Projects ==<br /> Marketers engagement requirements are to show their content to their desired audience in the right context, while limiting the frequency capping across these different publishers. The &quot;right&quot; context is determined by the relative cost for a subsequent value generated from the exposure, such as brand awareness, click or conversion. Part of determining a desired audience is also filtering [[Non-human_Traffic|Non-human traffic]].<br /> <br /> Publisher engagement requirements are to show their content to their desired audience, while controlling for publisher business rules, such as controlling which types of advertising content can appear or appear together on the same page to a particular audience. Privacy Sandbox's time-delayed feedback may not meet publisher requirements for A/B testing nor quality assurance of their advertising.<br /> <br /> A goal of the Privacy Sandbox is to limit the precision of audience segments in context, as well as to limit the real-time feedback marketers receive to update their measurement and budget allocations. Thus the Privacy Sandbox engagement proposals either force marketers to choose to control audience OR context, but not combine the two, or alternately force marketers to engage imprecise cohorts defined by Google. <br /> <br /> * '''Audience Creation''' <br /> ** [[FLoC]]<br /> ** [[Turtledove]]<br /> ** [[Scaup]]<br /> ** [[Trust Tokens]]<br /> ** [[Privacy Budget]]<br /> ** [[Client Hints]]<br /> ** [[First Party Sets]]<br /> <br /> * '''Auction Management''' <br /> ** [[Turtledove]]<br /> ** [[Augury]]<br /> ** [[Dovekey]]<br /> ** [[Sparrow]] (Criteo)<br /> ** [[Parrrot]] (Magnite)<br /> ** [[Fenced Frames]]<br /> ** [[Tern]] (Adroll)<br /> <br /> == Reporting Projects ==<br /> Marketers reporting requirements are to understand which content generating relatively better outcomes when shown to particular audiences in particular contexts. The attribution of outcomes, which often occur on marketer properties, is part of the process that enables marketers to value the publisher inventory they buy. <br /> <br /> A goal of Privacy Sandbox is to prevent the link of positive outcomes on marketer properties back to particular publisher contexts. <br /> <br /> * '''Reporting Management''' <br /> ** [[Aggregate Reporting API]]<br /> ** [[Conversion Measurement API]]<br /> ** [[Private Click Attribution]] (Apple)<br /> ** [[Murre]] (Adroll)<br /> ** [[Pelican]] (Neustar)<br /> ** [[Spurfowl]] (Nextroll)<br /> <br /> == Measuring Effectiveness and Ecosystem Impact ==<br /> Many marketers are concerned that the effectiveness of their media would be impaired by having reduced access to accurate, complete and real-time feedback across the various publishers they advertise on. Many ad-funded publishers are concerned that their revenues would decline as a result of this reduced effectiveness. <br /> <br /> Below are a few studies and approaches to quantify the impact on the ecosystem, expected by the roll out of Privacy Sandbox:<br /> <br /> * Google's Effects of Disabling Third-party Cookies on Publisher Revenue&lt;ref&gt;https://services.google.com/fh/files/misc/disabling_third-party_cookies_publisher_revenue.pdf&lt;/ref&gt;<br /> * [[Fledge]]<br /> * [[Teetar]] (Criteo)<br /> <br /> == References ==<br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Privacy Sandbox]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Category:Privacy_Sandbox&diff=263 2021-01-23T23:37:18Z

<p>AdminUser: /* Reporting Projects */</p> <hr /> <div>Privacy Sandbox is a set of proprietary Chrome browser APIs that provide information to buyers and sellers of digital media.&lt;ref&gt;https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers&lt;/ref&gt; Many of these APIs rely on server-side components. <br /> <br /> This page lists Google Privacy Sandbox projects as well as proposed modifications to these projects to better meet the needs of publishers and marketers. When an organization other than Google is proposing a project in the list below there name appears in parentheses. <br /> <br /> == Media Planning Projects == <br /> Given a goal of the Privacy Sandbox is to prevent marketers from understanding which audiences are interacting across different publishers, this will not be directly addressed by this project. <br /> <br /> == Experience Management Projects ==<br /> Marketers engagement requirements are to show their content to their desired audience in the right context, while limiting the frequency capping across these different publishers. The &quot;right&quot; context is determined by the relative cost for a subsequent value generated from the exposure, such as brand awareness, click or conversion. Part of determining a desired audience is also filtering [[Non-human_Traffic|Non-human traffic]].<br /> <br /> Publisher engagement requirements are to show their content to their desired audience, while controlling for publisher business rules, such as controlling which types of advertising content can appear or appear together on the same page to a particular audience. Privacy Sandbox's time-delayed feedback may not meet publisher requirements for A/B testing nor quality assurance of their advertising.<br /> <br /> A goal of the Privacy Sandbox is to limit the precision of audience segments in context, as well as to limit the real-time feedback marketers receive to update their measurement and budget allocations. Thus the Privacy Sandbox engagement proposals either force marketers to choose to control audience OR context, but not combine the two, or alternately force marketers to engage imprecise cohorts defined by Google. <br /> <br /> * '''Audience Creation''' <br /> ** [[FLoC]]<br /> ** [[Turtledove]]<br /> ** [[Scaup]]<br /> ** [[Trust Tokens]]<br /> ** [[Privacy Budget]]<br /> ** [[Client Hints]]<br /> ** [[First Party Sets]]<br /> <br /> * '''Auction Management''' <br /> ** [[Turtledove]]<br /> ** [[Augury]]<br /> ** [[Dovekey]]<br /> ** [[Sparrow]] (Criteo)<br /> ** [[Parrrot]] (Magnite)<br /> ** [[Fenced Frames]]<br /> ** [[Tern]] (Adroll)<br /> <br /> == Reporting Projects ==<br /> Marketers reporting requirements are to understand which content generating relatively better outcomes when shown to particular audiences in particular contexts. The attribution of outcomes, which often occur on marketer properties, is part of the process that enables marketers to value the publisher inventory they buy. <br /> <br /> A goal of Privacy Sandbox is to prevent the link of positive outcomes on marketer properties back to particular publisher contexts. <br /> <br /> * '''Reporting Management''' <br /> ** [[Aggregate Reporting API]]<br /> ** [[Conversion Measurement API]]<br /> ** [[Private Click Attribution]] (Apple)<br /> ** [[Murre]] (Adroll)<br /> ** [[Pelican]] (Neustar)<br /> <br /> == Measuring Effectiveness and Ecosystem Impact ==<br /> Many marketers are concerned that the effectiveness of their media would be impaired by having reduced access to accurate, complete and real-time feedback across the various publishers they advertise on. Many ad-funded publishers are concerned that their revenues would decline as a result of this reduced effectiveness. <br /> <br /> Below are a few studies and approaches to quantify the impact on the ecosystem, expected by the roll out of Privacy Sandbox:<br /> <br /> * Google's Effects of Disabling Third-party Cookies on Publisher Revenue&lt;ref&gt;https://services.google.com/fh/files/misc/disabling_third-party_cookies_publisher_revenue.pdf&lt;/ref&gt;<br /> * [[Fledge]]<br /> * [[Teetar]] (Criteo)<br /> <br /> == References ==<br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Privacy Sandbox]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Pelican&diff=262 2021-01-23T23:36:52Z

<p>AdminUser: </p> <hr /> <div>Neustar's Private Learning and Inteference for Causal Attribution (Pelican) provides key market requirements for causal attribution of sequences of exposure across decentralized publishers.&lt;ref&gt;https://github.com/neustar/pelican&lt;/ref&gt; <br /> <br /> The focus of Pelican is to ensure marketers can continue to provide multi-touch credit for publishers, given other proposals would only support last-click attribution. See [[Private Click Attribution]].<br /> <br /> Causal measurement makes it possible to say how effective advertising is at changing user behavior.&lt;ref&gt;Singh, K., Vaver, J., Little, R., Fan, R. 2018. &quot;Attribution Model Evaluation.&quot; https://research.google/pubs/pub46901/.&lt;/ref&gt; Operationalizing causal measurement in practice requires not only measuring marketing's impact on a consumer's decision to purchase, but also quantifying the consumer's inherent propensity to convert. &lt;ref&gt;Kelly, J., Vaver, J., Koehler, J. 2018. &quot;A Causal Framework for Digital Attribution.&quot; https://research.google/pubs/pub46905/.&lt;/ref&gt; <br /> <br /> == Impact ==<br /> By improving marketers' ability to attribute credit to more publishers, they will allocate more spend with those publishers. <br /> <br /> Pelican lists impacts to marketers if attribution is impaired:<br /> <br /> * Impairing accuracy in attribution will likely lead to lower spend in digital channels overall. <br /> * Impairing accuracy in attribution will disproportionally impact smaller publishers who do not have the ability to leverage large amounts of first party data about their users.<br /> * Impairing accuracy in attribution will shift spend to digital channels that are not impacted by interference with cross-publisher identifiers (such as Search)<br /> * Impairing accuracy in attribution will cause marketers to allocate their spend less efficiently, which will increase waste and hence likely result in higher customer acquisition costs, and may in turn be passed on to consumers in the form of higher prices.<br /> <br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Pelican]]<br /> [[Category:Privacy Sandbox|Pelican]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Pelican&diff=261 2021-01-23T23:36:27Z

<p>AdminUser: </p> <hr /> <div>Neustar's Private Learning and Inteference for Causal Attribution (Pelican) provides key market requirements for causal attribution of sequences of exposure across decentralized publishers.&lt;ref&gt;https://github.com/neustar/pelican&lt;/ref&gt; <br /> <br /> The focus of Pelican is to ensure marketers can continue to provide multi-touch credit for publishers, given other proposals would only support last-click attribution. See [[Private Click Attribution]].<br /> <br /> Causal measurement makes it possible to say how effective advertising is at changing user behavior.&lt;ref&gt;Singh, K., Vaver, J., Little, R., Fan, R. 2018. &quot;Attribution Model Evaluation.&quot; https://research.google/pubs/pub46901/.&lt;/ref&gt; Operationalizing causal measurement in practice requires not only measuring marketing's impact on a consumer's decision to purchase, but also quantifying the consumer's inherent propensity to convert. &lt;ref&gt;Kelly, J., Vaver, J., Koehler, J. 2018. &quot;A Causal Framework for Digital Attribution.&quot; https://research.google/pubs/pub46905/.&lt;/ref&gt; <br /> <br /> == Impact ==<br /> By improving marketers' ability to attribute credit to more publishers, they will allocate more spend with those publishers. <br /> <br /> Pelican lists impacts to marketers if attribution is impaired:<br /> <br /> * Impairing accuracy in attribution will likely lead to lower spend in digital channels overall. <br /> * Impairing accuracy in attribution will disproportionally impact smaller publishers who do not have the ability to leverage large amounts of first party data about their users.<br /> * Impairing accuracy in attribution will shift spend to digital channels that are not impacted by interference with cross-publisher identifiers (such as Search)<br /> * Impairing accuracy in attribution will cause marketers to allocate their spend less efficiently, which will increase waste and hence likely result in higher customer acquisition costs, and may in turn be passed on to consumers in the form of higher prices.<br /> <br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Turtledove]]<br /> [[Category:Privacy Sandbox|Turtledove]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Pelican&diff=260 2021-01-23T23:31:30Z

<p>AdminUser: Created page with &quot;Neustar's Private Learning and Inteference for Causal Attribution (Pelican) provides key market requirements for causal attribution of sequences of exposure across decentraliz...&quot;</p> <hr /> <div>Neustar's Private Learning and Inteference for Causal Attribution (Pelican) provides key market requirements for causal attribution of sequences of exposure across decentralized publishers.&lt;ref&gt;https://github.com/neustar/pelican&lt;/ref&gt; <br /> <br /> The focus of Pelican is to ensure marketers can continue to provide multi-touch credit for publishers, given other proposals would only support last-click attribution. See [[Private Click Attribution]].<br /> <br /> Causal measurement makes it possible to say how effective advertising is at changing user behavior.&lt;ref&gt;Singh, K., Vaver, J., Little, R., Fan, R. 2018. &quot;Attribution Model Evaluation.&quot; https://research.google/pubs/pub46901/.&lt;/ref&gt; Operationalizing causal measurement in practice requires not only measuring marketing's impact on a consumer's decision to purchase, but also quantifying the consumer's inherent propensity to convert. &lt;ref&gt;Kelly, J., Vaver, J., Koehler, J. 2018. &quot;A Causal Framework for Digital Attribution.&quot; https://research.google/pubs/pub46905/.&lt;/ref&gt; <br /> <br /> == Impact ==<br /> By improving marketers' ability to attribute credit to more publishers, they will allocate more spend with those publishers. <br /> <br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Turtledove]]<br /> [[Category:Privacy Sandbox|Turtledove]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Fledge&diff=259 2021-01-23T22:23:51Z

<p>AdminUser: /* Open Questions */</p> <hr /> <div>Google's First Locally-Executed Decision over Groups Experiment (FLEDGE) is a proposal to measure the effectiveness of Google's [[Turtledove]] auction mechanism as being a viable replacement for the interoperable identifiers that support the decentralized, open web.&lt;ref&gt;https://github.com/WICG/turtledove/blob/master/FLEDGE.md&lt;/ref&gt; <br /> <br /> FLEDGE has a goal to quantify the economic impact of [[Turtledove]] on publishers. <br /> <br /> == Experiment Design ==<br /> FLEDGE will rely upon the following steps:<br /> <br /> * Pre-auction Audience Segmentation<br /> ** Marketers will periodically (maximum of once per day in this experiment) send two sets of information to a Google-controlled server <br /> *** The first information set determines marketer-defined audience segmentation<br /> **** The Google-controlled server will send the audience segmentation logic to each Chrome browser<br /> **** Each browser will processes each marketer's audience segmentation logic and return back with its unique identifier whether or not it qualifies for the audience segment to the Google-controlled server<br /> **** The Google-controlled server will count distinct number of identifiers belong to each audience segment <br /> **** If the number of identifiers exceeds a Google-defined threshold, then this server will notify these browsers that they may use such audience segments for auction logic <br /> * Pre-auction Auction Desirability Logic <br /> ** In addition to audience segmentation logic, marketers will send logic to determines marketer auction desirability <br /> *** Marketer-specific desirability logic can include ad size, publisher domain, prior frequency of exposure to a give set of ads, and audience attributes <br /> *** Marketers will also send budget information per campaign to a Google-controlled trusted server<br /> ** The browser will separately request information from a Google-controlled trusted server to fetch marketer-specific desirability logic<br /> *** The Google-controlled trusted server will apply the marketer desirability logic to generate a bid for each combination of ad size, audience information and context information per campaign independent of current context<br /> * Pre-auction Publisher ad slot implementation<br /> ** Publishers will implement a Fenced Frame to query the browser APIs for ads and render the resulting ad <br /> *** The Fenced Frame will not communicate any information about the winning ad to the publisher<br /> ** Publishers will load into the browser logic called &quot;[[Worklet|worklets]]&quot; to select which bid response will win the on-device auction <br /> *** Publisher logic can adjust desirability of each bid response, based on price and other factors <br /> *** Publisher desirability logic can filter which marketer buying platforms can compete in the auction<br /> *** Publisher can apply an out-of-band creative review process to be used as an input into this desirability logic <br /> * Auction Mechanics<br /> ** When triggered by the Fenced Frame, the browser will send a bid request to a limited number of marketers' buying platforms (e.g., DSPs) containing only the context of the given ad slot<br /> ** DSPs receiving the browser request for a bid will determine whether they want to return a bid response<br /> *** DSPs will return separate bids for context-only and others based on each combination of attributes the browser may or may not contain <br /> ** The browser conducts an on-device auction to determine a local winning ad<br /> *** The browser will filter the returned bids based on the presence of audience attributes <br /> *** The browser will apply the publisher desirability logic to return the on-device auction winning ad<br /> ** The publisher's monetization platform (e.g., Publisher Ad Server or SSP) will compare this ad and its bid price to other demand for this same ad slot and select the winning ad to render<br /> * Post-auction<br /> ** During this experiment, the browser will send reporting data to per-specified publisher and buyer end points with event level data as to the outcome of the auction <br /> *** After this experiment, the browser will not send event-level data to the publisher or marketer <br /> ** Marketer buying platforms that lose auctions will get access to aggregate metrics on some time-delayed basis<br /> <br /> == Impact ==<br /> Given FLEDGE's design, the following are impacts to marketing effectiveness will not be measured: <br /> <br /> * [[Cohort]] vs [[attribute]] level audience inputs to buyer algorithms <br /> * [[Aggregate Reporting API|Aggregate]] vs event-level feedback to buyer algorithms <br /> * Time-delayed vs real-time event-level feedback to buyer algorithms <br /> <br /> == Open Questions ==<br /> * What time delay, if any (e.g., on lost bids), will be used to quantify the impact of Turtledove on marketers' value of inventory? <br /> * What limits on marketer audience segmentation logic will be placed?<br /> * Who will pay for operating the Google-controlled servers that process marketer audience segmentation logic?<br /> * How can marketers and their agents protect their intellectual property from being disclosed to Google?<br /> * What is the maximum number of DSPs that can operate in the ecosystem under a model where the browser must directly contact each for bids?<br /> * What is the acceptable level of impairment to marketing effectiveness, such that marketers will not reduce payments to publishers? <br /> * Given publishers will be monetizing the same ad slot with existing monetization and Chrome-based monetization, how will the metrics associated with each be reported for comparison? <br /> * Why are we not also evaluating the metrics proposed by [[Teetar]], such as measuring experience and perception of users exposed to cohort-based advertising.<br /> <br /> == See Also ==<br /> <br /> [[Teetar]]<br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> <br /> [[Category:Glossary|Fledge]]<br /> [[Category:Privacy Sandbox|Fledge]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Fledge&diff=258 2021-01-23T22:23:19Z

<p>AdminUser: </p> <hr /> <div>Google's First Locally-Executed Decision over Groups Experiment (FLEDGE) is a proposal to measure the effectiveness of Google's [[Turtledove]] auction mechanism as being a viable replacement for the interoperable identifiers that support the decentralized, open web.&lt;ref&gt;https://github.com/WICG/turtledove/blob/master/FLEDGE.md&lt;/ref&gt; <br /> <br /> FLEDGE has a goal to quantify the economic impact of [[Turtledove]] on publishers. <br /> <br /> == Experiment Design ==<br /> FLEDGE will rely upon the following steps:<br /> <br /> * Pre-auction Audience Segmentation<br /> ** Marketers will periodically (maximum of once per day in this experiment) send two sets of information to a Google-controlled server <br /> *** The first information set determines marketer-defined audience segmentation<br /> **** The Google-controlled server will send the audience segmentation logic to each Chrome browser<br /> **** Each browser will processes each marketer's audience segmentation logic and return back with its unique identifier whether or not it qualifies for the audience segment to the Google-controlled server<br /> **** The Google-controlled server will count distinct number of identifiers belong to each audience segment <br /> **** If the number of identifiers exceeds a Google-defined threshold, then this server will notify these browsers that they may use such audience segments for auction logic <br /> * Pre-auction Auction Desirability Logic <br /> ** In addition to audience segmentation logic, marketers will send logic to determines marketer auction desirability <br /> *** Marketer-specific desirability logic can include ad size, publisher domain, prior frequency of exposure to a give set of ads, and audience attributes <br /> *** Marketers will also send budget information per campaign to a Google-controlled trusted server<br /> ** The browser will separately request information from a Google-controlled trusted server to fetch marketer-specific desirability logic<br /> *** The Google-controlled trusted server will apply the marketer desirability logic to generate a bid for each combination of ad size, audience information and context information per campaign independent of current context<br /> * Pre-auction Publisher ad slot implementation<br /> ** Publishers will implement a Fenced Frame to query the browser APIs for ads and render the resulting ad <br /> *** The Fenced Frame will not communicate any information about the winning ad to the publisher<br /> ** Publishers will load into the browser logic called &quot;[[Worklet|worklets]]&quot; to select which bid response will win the on-device auction <br /> *** Publisher logic can adjust desirability of each bid response, based on price and other factors <br /> *** Publisher desirability logic can filter which marketer buying platforms can compete in the auction<br /> *** Publisher can apply an out-of-band creative review process to be used as an input into this desirability logic <br /> * Auction Mechanics<br /> ** When triggered by the Fenced Frame, the browser will send a bid request to a limited number of marketers' buying platforms (e.g., DSPs) containing only the context of the given ad slot<br /> ** DSPs receiving the browser request for a bid will determine whether they want to return a bid response<br /> *** DSPs will return separate bids for context-only and others based on each combination of attributes the browser may or may not contain <br /> ** The browser conducts an on-device auction to determine a local winning ad<br /> *** The browser will filter the returned bids based on the presence of audience attributes <br /> *** The browser will apply the publisher desirability logic to return the on-device auction winning ad<br /> ** The publisher's monetization platform (e.g., Publisher Ad Server or SSP) will compare this ad and its bid price to other demand for this same ad slot and select the winning ad to render<br /> * Post-auction<br /> ** During this experiment, the browser will send reporting data to per-specified publisher and buyer end points with event level data as to the outcome of the auction <br /> *** After this experiment, the browser will not send event-level data to the publisher or marketer <br /> ** Marketer buying platforms that lose auctions will get access to aggregate metrics on some time-delayed basis<br /> <br /> == Impact ==<br /> Given FLEDGE's design, the following are impacts to marketing effectiveness will not be measured: <br /> <br /> * [[Cohort]] vs [[attribute]] level audience inputs to buyer algorithms <br /> * [[Aggregate Reporting API|Aggregate]] vs event-level feedback to buyer algorithms <br /> * Time-delayed vs real-time event-level feedback to buyer algorithms <br /> <br /> == Open Questions ==<br /> * What time delay, if any (e.g., on lost bids), will be used to quantify the impact of Turtledove on marketers' value of inventory? <br /> * What limits on marketer audience segmentation logic will be placed?<br /> * Who will pay for operating the Google-controlled servers that process marketer audience segmentation logic?<br /> * How can marketers and their agents protect their intellectual property from being disclosed to Google?<br /> * What is the maximum number of DSPs that can operate in the ecosystem under a model where the browser must directly contact each for bids?<br /> * What is the acceptable level of impairment to marketing effectiveness, such that marketers will not reduce payments to publishers? <br /> * Given publishers will be monetizing the same ad slot with existing monetization and Chrome-based monetization, how will the metrics associated with each be reported for comparison? <br /> * Why are we not also evaluating the metrics proposed by [[TEETAR]], such as measuring experience and perception of users exposed to cohort-based advertising.<br /> <br /> == See Also ==<br /> <br /> [[Teetar]]<br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> <br /> [[Category:Glossary|Fledge]]<br /> [[Category:Privacy Sandbox|Fledge]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Category:Privacy_Sandbox&diff=257 2021-01-23T17:53:26Z

<p>AdminUser: /* Measuring Effectiveness and Ecosystem Impact */</p> <hr /> <div>Privacy Sandbox is a set of proprietary Chrome browser APIs that provide information to buyers and sellers of digital media.&lt;ref&gt;https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers&lt;/ref&gt; Many of these APIs rely on server-side components. <br /> <br /> This page lists Google Privacy Sandbox projects as well as proposed modifications to these projects to better meet the needs of publishers and marketers. When an organization other than Google is proposing a project in the list below there name appears in parentheses. <br /> <br /> == Media Planning Projects == <br /> Given a goal of the Privacy Sandbox is to prevent marketers from understanding which audiences are interacting across different publishers, this will not be directly addressed by this project. <br /> <br /> == Experience Management Projects ==<br /> Marketers engagement requirements are to show their content to their desired audience in the right context, while limiting the frequency capping across these different publishers. The &quot;right&quot; context is determined by the relative cost for a subsequent value generated from the exposure, such as brand awareness, click or conversion. Part of determining a desired audience is also filtering [[Non-human_Traffic|Non-human traffic]].<br /> <br /> Publisher engagement requirements are to show their content to their desired audience, while controlling for publisher business rules, such as controlling which types of advertising content can appear or appear together on the same page to a particular audience. Privacy Sandbox's time-delayed feedback may not meet publisher requirements for A/B testing nor quality assurance of their advertising.<br /> <br /> A goal of the Privacy Sandbox is to limit the precision of audience segments in context, as well as to limit the real-time feedback marketers receive to update their measurement and budget allocations. Thus the Privacy Sandbox engagement proposals either force marketers to choose to control audience OR context, but not combine the two, or alternately force marketers to engage imprecise cohorts defined by Google. <br /> <br /> * '''Audience Creation''' <br /> ** [[FLoC]]<br /> ** [[Turtledove]]<br /> ** [[Scaup]]<br /> ** [[Trust Tokens]]<br /> ** [[Privacy Budget]]<br /> ** [[Client Hints]]<br /> ** [[First Party Sets]]<br /> <br /> * '''Auction Management''' <br /> ** [[Turtledove]]<br /> ** [[Augury]]<br /> ** [[Dovekey]]<br /> ** [[Sparrow]] (Criteo)<br /> ** [[Parrrot]] (Magnite)<br /> ** [[Fenced Frames]]<br /> ** [[Tern]] (Adroll)<br /> <br /> == Reporting Projects ==<br /> Marketers reporting requirements are to understand which content generating relatively better outcomes when shown to particular audiences in particular contexts. The attribution of outcomes, which often occur on marketer properties, is part of the process that enables marketers to value the publisher inventory they buy. <br /> <br /> A goal of Privacy Sandbox is to prevent the link of positive outcomes on marketer properties back to particular publisher contexts. <br /> <br /> * '''Reporting Management''' <br /> ** [[Aggregate Reporting API]]<br /> ** [[Conversion Measurement API]]<br /> ** [[Private Click Attribution]] (Apple)<br /> ** [[Murre]]<br /> ** [[Pelican]] (Neustar)<br /> <br /> == Measuring Effectiveness and Ecosystem Impact ==<br /> Many marketers are concerned that the effectiveness of their media would be impaired by having reduced access to accurate, complete and real-time feedback across the various publishers they advertise on. Many ad-funded publishers are concerned that their revenues would decline as a result of this reduced effectiveness. <br /> <br /> Below are a few studies and approaches to quantify the impact on the ecosystem, expected by the roll out of Privacy Sandbox:<br /> <br /> * Google's Effects of Disabling Third-party Cookies on Publisher Revenue&lt;ref&gt;https://services.google.com/fh/files/misc/disabling_third-party_cookies_publisher_revenue.pdf&lt;/ref&gt;<br /> * [[Fledge]]<br /> * [[Teetar]] (Criteo)<br /> <br /> == References ==<br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Privacy Sandbox]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Teetar&diff=256 2021-01-23T17:52:30Z

<p>AdminUser: Created page with &quot;Criteo's Testing Environment Enabling Truthful and Actionable Results (TEETAR) is a proposal to measure the effectiveness of Google's Turtledove auction mechanism as being...&quot;</p> <hr /> <div>Criteo's Testing Environment Enabling Truthful and Actionable Results (TEETAR) is a proposal to measure the effectiveness of Google's [[Turtledove]] auction mechanism as being a viable replacement for the interoperable identifiers that support the decentralized, open web.&lt;ref&gt;https://github.com/criteo/privacy/tree/main/TEETAR&lt;/ref&gt; <br /> <br /> TEETAR has three goals: <br /> <br /> * Evaluate the economic impact of using [[Cohort|cohorts]]. <br /> * Evaluate the experience and perception of users exposed to cohort-based advertising.<br /> * Identify how proposals parameters (e.g., cohort sizes) influence the above two.<br /> <br /> TEETER proposes using CPM to measure the the economic impact on ecosystem welfare, defined as the value exchanged through advertising, as it directly correlates to both publishers' revenue and advertiser spend.<br /> <br /> TEETER proposes using a Net Promoter Score metric for measuring the users' perception of cohort-based advertising.<br /> <br /> <br /> == Open Questions ==<br /> * How much data must be collected to quantify the impact of cohort-based advertising? <br /> <br /> <br /> == See Also ==<br /> [[Fledge]]<br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> <br /> [[Category:Glossary|Teetar]]<br /> [[Category:Privacy Sandbox|Teetar]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Fledge&diff=255 2021-01-23T17:50:57Z

<p>AdminUser: Created page with &quot;Google's First Locally-Executed Decision over Groups Experiment (FLEDGE) is a proposal to measure the effectiveness of Google's Turtledove auction mechanism as being a via...&quot;</p> <hr /> <div>Google's First Locally-Executed Decision over Groups Experiment (FLEDGE) is a proposal to measure the effectiveness of Google's [[Turtledove]] auction mechanism as being a viable replacement for the interoperable identifiers that support the decentralized, open web.&lt;ref&gt;https://github.com/WICG/turtledove/blob/master/FLEDGE.md&lt;/ref&gt; <br /> <br /> FLEDGE has a goal to quantify the economic impact of [[Turtledove]] on publishers. <br /> <br /> == Experiment Design ==<br /> FLEDGE will rely upon the following steps:<br /> <br /> * Pre-auction<br /> ** Marketers will periodically (maximum of once per day in this experiment) send their attributes to a Google-controlled server that counts distinct identifiers containing this attribute <br /> *** If the number of identifiers exceeds a Google-defined threshold, then it will send this information to be stored in each qualifying browser <br /> *** Marketers will send budget information per campaign to a Google-controlled trusted server<br /> ** Publishers will implement a Fenced Frame to query the browser APIs for ads and render the resulting ad <br /> *** The Fenced Frame will not communicate any information about the winning ad to the publisher<br /> ** Publishers will load into the browser logic called &quot;[[Worklet|worklets]]&quot; to select which bid response will win the on-device auction <br /> *** Publisher logic can adjust desirability of each bid response, based on price and other factors <br /> *** Publisher desirability logic can filter which marketer buying platforms can compete in the auction<br /> *** Publisher can apply an out-of-band creative review process to be used as an input into this desirability logic <br /> * Auction<br /> ** When triggered by the Fenced Frame, the browser will send a bid request to a limited number of marketers' buying platforms (e.g., DSPs) containing only the context of the ad slot<br /> ** DSPs receiving the browser request for a bid will determine whether they want to return a bid response<br /> *** DSPs will return separate bids for context-only and others based on each combination of attributes the browser may or may not contain <br /> ** The browser will separately request information from a Google-controlled trusted server to fetch marketer-specific desirability logic<br /> *** Marketer-specific desirability logic can include ad size, publisher domain, prior frequency of exposure to a give set of ads, and audience attributes <br /> *** The browser will send a set of information to the Google-controlled trusted server to be used as an input into the per marketer desirability logic (e.g., publisher domain, prior exposure frequency per ad, attributes) <br /> *** The Google-controlled trusted server will apply the marketer desirability logic to generate a bid for each combination of ad size, audience information and context information per campaign <br /> ** The browser conducts an on-device auction to determine a local winning ad<br /> *** The browser will filter the returned bids based on the presence of audience attributes <br /> *** The browser will apply the publisher desirability logic to return the on-device auction winning ad<br /> ** The publisher's monetization platform (e.g., Publisher Ad Server or SSP) will compare this ad and its bid price to other demand for this same ad slot and select the winning ad to render<br /> * Post-auction<br /> ** During this experiment, the browser will send reporting data to per-specified publisher and buyer end points with event level data as to the outcome of the auction <br /> ** Marketer buying platforms that lose auctions will get access to aggregate metrics on some time-delayed basis<br /> <br /> == Impact ==<br /> Given FLEDGE's design, the following are impacts to marketing effectiveness will not be measured: <br /> <br /> * [[Cohort]] vs [[attribute]] level audience inputs to buyer algorithms <br /> * [[Aggregate Reporting API|Aggregate]] vs event-level feedback to buyer algorithms <br /> * Time-delayed vs real-time event-level feedback to buyer algorithms <br /> <br /> == Open Questions ==<br /> * What time delay, if any (e.g., on lost bids), will be used to quantify the impact of Turtledove on marketers' value of inventory? <br /> * What is the maximum number of DSPs that can operate in the ecosystem under a model where the browser must directly contact each for bids?<br /> * What is the acceptable level of impairment to marketing effectiveness, such that marketers will not reduce payments to publishers? <br /> * Given publishers will be monetizing the same ad slot with existing monetization and Chrome-based monetization, how will the metrics associated with each be reported for comparison? <br /> * Why are we not also evaluating the metrics proposed by [[TEETAR]], such as measuring experience and perception of users exposed to cohort-based advertising.<br /> <br /> == See Also ==<br /> <br /> [[Teetar]]<br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> <br /> [[Category:Glossary|Fledge]]<br /> [[Category:Privacy Sandbox|Fledge]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Category:Privacy_Sandbox&diff=254 2021-01-23T17:50:20Z

<p>AdminUser: /* Measuring Effectiveness and Ecosystem Impact */</p> <hr /> <div>Privacy Sandbox is a set of proprietary Chrome browser APIs that provide information to buyers and sellers of digital media.&lt;ref&gt;https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers&lt;/ref&gt; Many of these APIs rely on server-side components. <br /> <br /> This page lists Google Privacy Sandbox projects as well as proposed modifications to these projects to better meet the needs of publishers and marketers. When an organization other than Google is proposing a project in the list below there name appears in parentheses. <br /> <br /> == Media Planning Projects == <br /> Given a goal of the Privacy Sandbox is to prevent marketers from understanding which audiences are interacting across different publishers, this will not be directly addressed by this project. <br /> <br /> == Experience Management Projects ==<br /> Marketers engagement requirements are to show their content to their desired audience in the right context, while limiting the frequency capping across these different publishers. The &quot;right&quot; context is determined by the relative cost for a subsequent value generated from the exposure, such as brand awareness, click or conversion. Part of determining a desired audience is also filtering [[Non-human_Traffic|Non-human traffic]].<br /> <br /> Publisher engagement requirements are to show their content to their desired audience, while controlling for publisher business rules, such as controlling which types of advertising content can appear or appear together on the same page to a particular audience. Privacy Sandbox's time-delayed feedback may not meet publisher requirements for A/B testing nor quality assurance of their advertising.<br /> <br /> A goal of the Privacy Sandbox is to limit the precision of audience segments in context, as well as to limit the real-time feedback marketers receive to update their measurement and budget allocations. Thus the Privacy Sandbox engagement proposals either force marketers to choose to control audience OR context, but not combine the two, or alternately force marketers to engage imprecise cohorts defined by Google. <br /> <br /> * '''Audience Creation''' <br /> ** [[FLoC]]<br /> ** [[Turtledove]]<br /> ** [[Scaup]]<br /> ** [[Trust Tokens]]<br /> ** [[Privacy Budget]]<br /> ** [[Client Hints]]<br /> ** [[First Party Sets]]<br /> <br /> * '''Auction Management''' <br /> ** [[Turtledove]]<br /> ** [[Augury]]<br /> ** [[Dovekey]]<br /> ** [[Sparrow]] (Criteo)<br /> ** [[Parrrot]] (Magnite)<br /> ** [[Fenced Frames]]<br /> ** [[Tern]] (Adroll)<br /> <br /> == Reporting Projects ==<br /> Marketers reporting requirements are to understand which content generating relatively better outcomes when shown to particular audiences in particular contexts. The attribution of outcomes, which often occur on marketer properties, is part of the process that enables marketers to value the publisher inventory they buy. <br /> <br /> A goal of Privacy Sandbox is to prevent the link of positive outcomes on marketer properties back to particular publisher contexts. <br /> <br /> * '''Reporting Management''' <br /> ** [[Aggregate Reporting API]]<br /> ** [[Conversion Measurement API]]<br /> ** [[Private Click Attribution]] (Apple)<br /> ** [[Murre]]<br /> ** [[Pelican]] (Neustar)<br /> <br /> == Measuring Effectiveness and Ecosystem Impact ==<br /> Many marketers are concerned that the effectiveness of their media would be impaired by having reduced access to accurate, complete and real-time feedback across the various publishers they advertise on. Many ad-funded publishers are concerned that their revenues would decline as a result of this reduced effectiveness. <br /> <br /> Below are a few studies and approaches to quantify the impact on the ecosystem, expected by the roll out of Privacy Sandbox:<br /> <br /> * Google's Effects of Disabling Third-party Cookies on Publisher Revenue&lt;ref&gt;https://services.google.com/fh/files/misc/disabling_third-party_cookies_publisher_revenue.pdf&lt;/ref&gt;<br /> * [[Fledge]]<br /> * [[TEETAR]] (Criteo)<br /> <br /> == References ==<br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Privacy Sandbox]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Category:Privacy_Sandbox&diff=253 2021-01-23T17:49:33Z

<p>AdminUser: </p> <hr /> <div>Privacy Sandbox is a set of proprietary Chrome browser APIs that provide information to buyers and sellers of digital media.&lt;ref&gt;https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers&lt;/ref&gt; Many of these APIs rely on server-side components. <br /> <br /> This page lists Google Privacy Sandbox projects as well as proposed modifications to these projects to better meet the needs of publishers and marketers. When an organization other than Google is proposing a project in the list below there name appears in parentheses. <br /> <br /> == Media Planning Projects == <br /> Given a goal of the Privacy Sandbox is to prevent marketers from understanding which audiences are interacting across different publishers, this will not be directly addressed by this project. <br /> <br /> == Experience Management Projects ==<br /> Marketers engagement requirements are to show their content to their desired audience in the right context, while limiting the frequency capping across these different publishers. The &quot;right&quot; context is determined by the relative cost for a subsequent value generated from the exposure, such as brand awareness, click or conversion. Part of determining a desired audience is also filtering [[Non-human_Traffic|Non-human traffic]].<br /> <br /> Publisher engagement requirements are to show their content to their desired audience, while controlling for publisher business rules, such as controlling which types of advertising content can appear or appear together on the same page to a particular audience. Privacy Sandbox's time-delayed feedback may not meet publisher requirements for A/B testing nor quality assurance of their advertising.<br /> <br /> A goal of the Privacy Sandbox is to limit the precision of audience segments in context, as well as to limit the real-time feedback marketers receive to update their measurement and budget allocations. Thus the Privacy Sandbox engagement proposals either force marketers to choose to control audience OR context, but not combine the two, or alternately force marketers to engage imprecise cohorts defined by Google. <br /> <br /> * '''Audience Creation''' <br /> ** [[FLoC]]<br /> ** [[Turtledove]]<br /> ** [[Scaup]]<br /> ** [[Trust Tokens]]<br /> ** [[Privacy Budget]]<br /> ** [[Client Hints]]<br /> ** [[First Party Sets]]<br /> <br /> * '''Auction Management''' <br /> ** [[Turtledove]]<br /> ** [[Augury]]<br /> ** [[Dovekey]]<br /> ** [[Sparrow]] (Criteo)<br /> ** [[Parrrot]] (Magnite)<br /> ** [[Fenced Frames]]<br /> ** [[Tern]] (Adroll)<br /> <br /> == Reporting Projects ==<br /> Marketers reporting requirements are to understand which content generating relatively better outcomes when shown to particular audiences in particular contexts. The attribution of outcomes, which often occur on marketer properties, is part of the process that enables marketers to value the publisher inventory they buy. <br /> <br /> A goal of Privacy Sandbox is to prevent the link of positive outcomes on marketer properties back to particular publisher contexts. <br /> <br /> * '''Reporting Management''' <br /> ** [[Aggregate Reporting API]]<br /> ** [[Conversion Measurement API]]<br /> ** [[Private Click Attribution]] (Apple)<br /> ** [[Murre]]<br /> ** [[Pelican]] (Neustar)<br /> <br /> == Measuring Effectiveness and Ecosystem Impact ==<br /> Many marketers are concerned that the effectiveness of their media would be impaired by having reduced access to accurate, complete and real-time feedback across the various publishers they advertise on. Many ad-funded publishers are concerned that their revenues would decline as a result of this reduced effectiveness. <br /> <br /> Below are a few studies and approaches to quantify the impact on the ecosystem, expected by the roll out of Privacy Sandbox:<br /> <br /> * Google's Effects of Disabling Third-party Cookies on Publisher Revenue&lt;ref&gt;https://services.google.com/fh/files/misc/disabling_third-party_cookies_publisher_revenue.pdf&lt;/ref&gt;<br /> * [[FLEDGE]]<br /> * [[TEETAR]] (Criteo)<br /> <br /> == References ==<br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Privacy Sandbox]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Private_Click_Attribution&diff=252 2021-01-23T17:48:25Z

<p>AdminUser: </p> <hr /> <div>Apple's Private Click Attribution is designed to provide less accurate, incomplete and time-delayed data to marketers about the events associated with their advertising. Apple acknowledges that for &quot;ad click attribution to happen, some bits of data about what happened across two websites need to be sent.&quot;&lt;ref&gt;https://webkit.org/blog/8943/privacy-preserving-ad-click-attribution-for-the-web/&lt;/ref&gt;<br /> <br /> == Process ==<br /> Apple proposes that the browser send time-delayed information associated with the attribution to both buyers and sellers.<br /> <br /> “Ad Click Attribution in a Nutshell<br /> <br /> Here’s a simple example of ad click attribution:<br /> <br /> An online store runs an ad on a... website. If a user clicks the ad and eventually buys something, both the online store and the... website where the ad was placed want to know; they want the purchase to be attributed to the ad click so that the store knows where to focus their advertising budget. Such attribution is used for measurement of which ads are effective….&quot;&lt;ref&gt;https://webkit.org/blog/8943/privacy-preserving-ad-click-attribution-for-the-web/&lt;/ref&gt;<br /> <br /> The steps in calculating this attribution include:<br /> <br /> * The browser stores the click on every ad a visitor engages with<br /> * The browser stores every conversion event<br /> * The browser matches conversions to prior clicks<br /> * The browser sends a time-delayed aggregate report to both buyers and sellers <br /> <br /> == Impact ==<br /> By removing accurate, complete and real-time feedback to marketers, their ability to adjust the pricing and budget associated with advertising will be impaired. As the value marketers receive from advertising declines, so to will publisher revenues.<br /> <br /> Apple's proposal suggests marketers need only to measure a limited set of 64 campaigns, which is not practical to most marketers who run hundreds of campaigns or relying on sponsored search relying on thousands of keywords.<br /> <br /> Apple's proposed Private Click Attribution relies on marketers sending the value of their conversion data to the publisher. However, Apple proposes that the data sent be a range rather than a specific value, which thus impairs the accuracy of the attribution algorithm. Moreover, W3C members have criticized this proposal on not improving privacy as well as forcing buyers to disclose proprietary data to sellers: <br /> <br /> * “ad click destination may not want to share any details with ad click source besides the fact that conversion happened.”&lt;ref&gt;https://github.com/privacycg/private-click-measurement/issues/16&lt;/ref&gt;<br /> <br /> * “It also doesn't seem more transparent than sending a request to a third party. The data being sent is already in aggregate and contains very little identifiable information so it's not clear what threat is being avoided.” &lt;ref&gt;https://github.com/privacycg/private-click-measurement/issues/53&lt;/ref&gt;<br /> <br /> == Open Questions ==<br /> * How will marketers value view-through attribution or multi-touch attribution? <br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Private Click Attribution]]<br /> [[Category:Privacy Sandbox|Private Click Attribution]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Private_Click_Attribution&diff=251 2021-01-23T17:42:54Z

<p>AdminUser: </p> <hr /> <div>Apple's Private Click Attribution is designed to provide less accurate, incomplete and time-delayed data to marketers about the events associated with their advertising. Apple acknowledges that for &quot;ad click attribution to happen, some bits of data about what happened across two websites need to be sent.&quot;&lt;ref&gt;https://webkit.org/blog/8943/privacy-preserving-ad-click-attribution-for-the-web/&lt;/ref&gt;<br /> <br /> == Impact ==<br /> By removing accurate, complete and real-time feedback to marketers, their ability to adjust the pricing and budget associated with advertising will be impaired. As the value marketers receive from advertising declines, so to will publisher revenues.<br /> <br /> Apple's proposal suggests marketers need only to measure a limited set of 64 campaigns, which is not practical to most marketers who run hundreds of campaigns or relying on sponsored search relying on thousands of keywords.<br /> <br /> Apple's proposed Private Click Attribution relies on marketers sending the value of their conversion data to the publisher. However, Apple proposes that the data sent be a range rather than a specific value, which thus impairs the accuracy of the attribution algorithm. Moreover, W3C members have criticized this proposal on not improving privacy as well as forcing buyers to disclose proprietary data to sellers: <br /> <br /> * “ad click destination may not want to share any details with ad click source besides the fact that conversion happened.”&lt;ref&gt;https://github.com/privacycg/private-click-measurement/issues/16&lt;/ref&gt;<br /> <br /> * “It also doesn't seem more transparent than sending a request to a third party. The data being sent is already in aggregate and contains very little identifiable information so it's not clear what threat is being avoided.” &lt;ref&gt;https://github.com/privacycg/private-click-measurement/issues/53&lt;/ref&gt;<br /> <br /> == Open Questions ==<br /> * How will marketers value view-through attribution or multi-touch attribution? <br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Private Click Attribution]]<br /> [[Category:Privacy Sandbox|Private Click Attribution]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Private_Click_Attribution&diff=250 2021-01-23T17:42:37Z

<p>AdminUser: </p> <hr /> <div>Apple's Private Click Attribution is designed to provide less accurate, incomplete and time-delayed data to marketers about the events associated with their advertising. Apple acknowledges that for &quot;ad click attribution to happen, some bits of data about what happened across two websites need to be sent.&quot;&lt;ref&gt;https://webkit.org/blog/8943/privacy-preserving-ad-click-attribution-for-the-web/&lt;/ref&gt;<br /> <br /> <br /> == Impact ==<br /> By removing accurate, complete and real-time feedback to marketers, their ability to adjust the pricing and budget associated with advertising will be impaired. As the value marketers receive from advertising declines, so to will publisher revenues.<br /> <br /> Apple's proposal suggests marketers need only to measure a limited set of 64 campaigns, which is not practical to most marketers who run hundreds of campaigns or relying on sponsored search relying on thousands of keywords.<br /> <br /> Apple's proposed Private Click Attribution relies on marketers sending the value of their conversion data to the publisher. However, Apple proposes that the data sent be a range rather than a specific value, which thus impairs the accuracy of the attribution algorithm. Moreover, W3C members have criticized this proposal on not improving privacy as well as forcing buyers to disclose proprietary data to sellers: <br /> <br /> * “ad click destination may not want to share any details with ad click source besides the fact that conversion happened.”&lt;ref&gt;https://github.com/privacycg/private-click-measurement/issues/16&lt;/ref&gt;<br /> <br /> * “It also doesn't seem more transparent than sending a request to a third party. The data being sent is already in aggregate and contains very little identifiable information so it's not clear what threat is being avoided.” &lt;ref&gt;https://github.com/privacycg/private-click-measurement/issues/53&lt;/ref&gt;<br /> <br /> == Open Questions ==<br /> * How will marketers value view-through attribution or multi-touch attribution? <br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Private Click Attribution]]<br /> [[Category:Privacy Sandbox|Private Click Attribution]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Private_Click_Attribution&diff=249 2021-01-23T17:38:04Z

<p>AdminUser: </p> <hr /> <div>Apple's Private Click Attribution is designed to provide less accurate, incomplete and time-delayed data to marketers about the events associated with their advertising. Apple acknowledges that for &quot;ad click attribution to happen, some bits of data about what happened across two websites need to be sent.&quot;&lt;ref&gt;https://webkit.org/blog/8943/privacy-preserving-ad-click-attribution-for-the-web/&lt;/ref&gt;<br /> <br /> Apple's proposed Private Click Attribution relies on marketers sending the value of their conversion data to the publisher. However, Apple proposes that the data sent be a range rather than a specific value, which thus impairs the accuracy of the attribution algorithm. <br /> <br /> == Impact ==<br /> By removing accurate, complete and real-time feedback to marketers, their ability to adjust the pricing and budget associated with advertising will be impaired. As the value marketers receive from advertising declines, so to will publisher revenues.<br /> <br /> == Open Questions ==<br /> * How will marketers value view-through attribution or multi-touch attribution? <br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Private Click Attribution]]<br /> [[Category:Privacy Sandbox|Private Click Attribution]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Private_Click_Attribution&diff=248 2021-01-23T17:37:47Z

<p>AdminUser: Created page with &quot;Apple's Private Click Attribution is designed to provide less accurate, incomplete and time-delayed data to marketers about the events associated with their advertising.&lt;ref&gt;h...&quot;</p> <hr /> <div>Apple's Private Click Attribution is designed to provide less accurate, incomplete and time-delayed data to marketers about the events associated with their advertising.&lt;ref&gt;https://webkit.org/blog/8943/privacy-preserving-ad-click-attribution-for-the-web/&lt;/ref&gt;<br /> <br /> Apple acknowledges that for &quot;ad click attribution to happen, some bits of data about what happened across two websites need to be sent.&quot;&lt;ref&gt;https://webkit.org/blog/8943/privacy-preserving-ad-click-attribution-for-the-web/&lt;/ref&gt;<br /> <br /> Apple's proposed Private Click Attribution relies on marketers sending the value of their conversion data to the publisher. However, Apple proposes that the data sent be a range rather than a specific value, which thus impairs the accuracy of the attribution algorithm. <br /> <br /> == Impact ==<br /> By removing accurate, complete and real-time feedback to marketers, their ability to adjust the pricing and budget associated with advertising will be impaired. As the value marketers receive from advertising declines, so to will publisher revenues.<br /> <br /> == Open Questions ==<br /> * How will marketers value view-through attribution or multi-touch attribution? <br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Private Click Attribution]]<br /> [[Category:Privacy Sandbox|Private Click Attribution]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Category:Privacy_Sandbox&diff=247 2021-01-23T17:29:41Z

<p>AdminUser: </p> <hr /> <div>Privacy Sandbox is a set of proprietary Chrome browser APIs that provide information to buyers and sellers of digital media.&lt;ref&gt;https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers&lt;/ref&gt; Many of these APIs rely on server-side components. <br /> <br /> This page lists Google Privacy Sandbox projects as well as proposed modifications to these projects to better meet the needs of publishers and marketers. When an organization other than Google is proposing a project in the list below there name appears in parentheses. <br /> <br /> == Media Planning Projects == <br /> Given a goal of the Privacy Sandbox is to prevent marketers from understanding which audiences are interacting across different publishers, this will not be directly addressed by this project. <br /> <br /> == Experience Management Projects ==<br /> Marketers engagement requirements are to show their content to their desired audience in the right context, while limiting the frequency capping across these different publishers. The &quot;right&quot; context is determined by the relative cost for a subsequent value generated from the exposure, such as brand awareness, click or conversion. Part of determining a desired audience is also filtering [[Non-human_Traffic|Non-human traffic]].<br /> <br /> Publisher engagement requirements are to show their content to their desired audience, while controlling for publisher business rules, such as controlling which types of advertising content can appear or appear together on the same page to a particular audience. Privacy Sandbox's time-delayed feedback may not meet publisher requirements for A/B testing nor quality assurance of their advertising.<br /> <br /> A goal of the Privacy Sandbox is to limit the precision of audience segments in context, as well as to limit the real-time feedback marketers receive to update their measurement and budget allocations. Thus the Privacy Sandbox engagement proposals either force marketers to choose to control audience OR context, but not combine the two, or alternately force marketers to engage imprecise cohorts defined by Google. <br /> <br /> * '''Audience Creation''' <br /> ** [[FLoC]]<br /> ** [[Turtledove]]<br /> ** [[Scaup]]<br /> ** [[Trust Tokens]]<br /> ** [[Privacy Budget]]<br /> ** [[Client Hints]]<br /> ** [[First Party Sets]]<br /> <br /> * '''Auction Management''' <br /> ** [[Turtledove]]<br /> ** [[Augury]]<br /> ** [[Dovekey]]<br /> ** [[Sparrow]] (Criteo)<br /> ** [[Parrrot]] (Magnite)<br /> ** [[Fenced Frames]]<br /> ** [[Tern]] (Adroll)<br /> <br /> == Reporting Projects ==<br /> Marketers reporting requirements are to understand which content generating relatively better outcomes when shown to particular audiences in particular contexts. The attribution of outcomes, which often occur on marketer properties, is part of the process that enables marketers to value the publisher inventory they buy. <br /> <br /> A goal of Privacy Sandbox is to prevent the link of positive outcomes on marketer properties back to particular publisher contexts. <br /> <br /> * '''Auction Management''' <br /> ** [[Aggregate Reporting API]]<br /> ** [[Conversion Measurement API]]<br /> ** [[Private Click Attribution]] (Apple)<br /> ** [[Murre]]<br /> ** [[Pelican]] (Neustar)<br /> <br /> == Measuring Effectiveness and Ecosystem Impact ==<br /> Many marketers are concerned that the effectiveness of their media would be impaired by having reduced access to accurate, complete and real-time feedback across the various publishers they advertise on. Many ad-funded publishers are concerned that their revenues would decline as a result of this reduced effectiveness. <br /> <br /> Below are a few studies and approaches to quantify the impact on the ecosystem, expected by the roll out of Privacy Sandbox:<br /> <br /> * Google's Effects of Disabling Third-party Cookies on Publisher Revenue&lt;ref&gt;https://services.google.com/fh/files/misc/disabling_third-party_cookies_publisher_revenue.pdf&lt;/ref&gt;<br /> * [[FLEDGE]]<br /> * [[TEETAR]] (Criteo)<br /> <br /> == References ==<br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Privacy Sandbox]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Category:Privacy_Sandbox&diff=246 2021-01-23T17:27:33Z

<p>AdminUser: </p> <hr /> <div>Privacy Sandbox is a set of proprietary Chrome browser APIs that provide information to buyers and sellers of digital media.&lt;ref&gt;https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers&lt;/ref&gt; Many of these APIs rely on server-side components. <br /> <br /> This page lists Google Privacy Sandbox projects as well as proposed modifications to these projects to better meet the needs of publishers and marketers. When an organization other than Google is proposing a project in the list below there name appears in parentheses. <br /> <br /> == Media Planning Projects == <br /> Given a goal of the Privacy Sandbox is to prevent marketers from understanding which audiences are interacting across different publishers, this will not be directly addressed by this project. <br /> <br /> == Experience Management Projects ==<br /> Marketers engagement requirements are to show their content to their desired audience in the right context, while limiting the frequency capping across these different publishers. The &quot;right&quot; context is determined by the relative cost for a subsequent value generated from the exposure, such as brand awareness, click or conversion. Part of determining a desired audience is also filtering [[Non-human_Traffic|Non-human traffic]].<br /> <br /> Publisher engagement requirements are to show their content to their desired audience, while controlling for publisher business rules, such as controlling which types of advertising content can appear or appear together on the same page to a particular audience. Privacy Sandbox's time-delayed feedback may not meet publisher requirements for A/B testing nor quality assurance of their advertising.<br /> <br /> A goal of the Privacy Sandbox is to limit the precision of audience segments in context, as well as to limit the real-time feedback marketers receive to update their measurement and budget allocations. Thus the Privacy Sandbox engagement proposals either force marketers to choose to control audience OR context, but not combine the two, or alternately force marketers to engage imprecise cohorts defined by Google. <br /> <br /> * '''Audience Creation''' <br /> ** [[FLoC]]<br /> ** [[Turtledove]]<br /> ** [[Scaup]]<br /> ** [[Trust Tokens]]<br /> ** [[Privacy Budget]]<br /> ** [[Client Hints]]<br /> ** [[First Party Sets]]<br /> <br /> * '''Auction Management''' <br /> ** [[Turtledove]]<br /> ** [[Augury]]<br /> ** [[Dovekey]]<br /> ** [[Sparrow]] (Criteo)<br /> ** [[Parrrot]] (Magnite)<br /> ** [[Fenced Frames]]<br /> ** [[Tern]] (Adroll)<br /> <br /> == Reporting Projects ==<br /> Marketers reporting requirements are to understand which content generating relatively better outcomes when shown to particular audiences in particular contexts. The attribution of outcomes, which often occur on marketer properties, is part of the process that enables marketers to value the publisher inventory they buy. <br /> <br /> A goal of Privacy Sandbox is to prevent the link of positive outcomes on marketer properties back to particular publisher contexts. <br /> <br /> * '''Auction Management''' <br /> ** [[Aggregate Reporting API]]<br /> ** [[Conversion Measurement API]]<br /> ** [[Privacy Click Attribution]] (Apple)<br /> ** [[Murre]]<br /> ** [[Pelican]] (Neustar)<br /> <br /> == Measuring Effectiveness and Ecosystem Impact ==<br /> Many marketers are concerned that the effectiveness of their media would be impaired by having reduced access to accurate, complete and real-time feedback across the various publishers they advertise on. Many ad-funded publishers are concerned that their revenues would decline as a result of this reduced effectiveness. <br /> <br /> Below are a few studies and approaches to quantify the impact on the ecosystem, expected by the roll out of Privacy Sandbox:<br /> <br /> * Google's Effects of Disabling Third-party Cookies on Publisher Revenue&lt;ref&gt;https://services.google.com/fh/files/misc/disabling_third-party_cookies_publisher_revenue.pdf&lt;/ref&gt;<br /> * [[FLEDGE]]<br /> * [[TEETAR]] (Criteo)<br /> <br /> == References ==<br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Privacy Sandbox]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Murre&diff=245 2021-01-23T17:26:57Z

<p>AdminUser: </p> <hr /> <div>Adroll's Mechanism for User Reports with Regulated Epsilon (Murre) is designed to enable machine learning based on binary inputs with noise added. The Murre proposal keeps the activity trail local to the web client, which thus requires client processing for any processing.&lt;ref&gt;https://github.com/AdRoll/privacy/blob/main/MURRE.md&lt;/ref&gt;<br /> <br /> Murre makes the following assumptions: <br /> * Machine learning algorithms in ad tech require granular data to function well.<br /> * Ad tech uses models of high dimension, with sparse vectors.<br /> * Differential privacy is a framework for understanding and protecting user privacy.<br /> * The data required for effective advertising is not particularly sensitive. <br /> * Computation and network usage will be limited on the user agent. <br /> <br /> == Impact ==<br /> By limiting inputs to binary values, continuous values (e.g., price) are not supported unless they are binned into categories, which will impair the modeling process. <br /> <br /> By disclosing audience information, publishers and buyers are leaking their intellectual property associated with that web client (e.g., high value customer) to anyone with access to the web client. <br /> <br /> == Open Questions ==<br /> * What is the time-delay in providing the data necessary for publishers to optimize their revenue? <br /> * What is the time-delay in providing the data necessary for marketers to optimize their media spend?<br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Murre]]<br /> [[Category:Privacy Sandbox|Murre]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Aggregate_Reporting_API&diff=244 2021-01-23T17:26:23Z

<p>AdminUser: </p> <hr /> <div>Google's Aggregated Reporting API and [[Conversion Measurement API]] provide aggregate data from a Google-controlled server.&lt;ref&gt;https://github.com/csharrison/aggregate-reporting-api&lt;/ref&gt; These APIs are designed to provide marketers aggregate reach and conversion reporting, given marketers using Privacy Sandbox will not have event-level visibility into the media they purchase.&lt;ref&gt;https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers&lt;/ref&gt; <br /> <br /> Google's server will provide time-delayed, aggregated metrics only after at least 24 hours have elapsed from the actual events. <br /> <br /> <br /> == Impact ==<br /> By providing publishers time-delayed information, their ability to A/B test and assure quality of changes to their website will be impaired. <br /> <br /> By providing marketers time-delayed information, they more of their budget will continue to be spent on publishers providing relatively lesser value.<br /> <br /> <br /> == Open Questions ==<br /> * Will frequency reporting be available in addition to reach?<br /> <br /> == See Also == <br /> * [[Murre|MURRE]] is designed to address the time-delayed and aggregate impairments of machine learning Google's Aggregate Reporting API otherwise imposes<br /> <br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Aggregate Reporting API]]<br /> [[Category:Privacy Sandbox|Aggregate Reporting API]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Aggregate_Reporting_API&diff=243 2021-01-23T17:25:46Z

<p>AdminUser: </p> <hr /> <div>Google's Aggregated Reporting API and [[Conversion Measurement API]] provide aggregate data from a Google-controlled server.&lt;ref&gt;https://github.com/csharrison/aggregate-reporting-api&lt;/ref&gt; These APIs are designed to provide marketers aggregate reach and conversion reporting, given marketers using Privacy Sandbox will not have event-level visibility into the media they purchase.&lt;ref&gt;https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers&lt;/ref&gt; <br /> <br /> Google's server will provide time-delayed, aggregated metrics only after at least 24 hours have elapsed from the actual events. <br /> <br /> <br /> == Impact ==<br /> By providing publishers time-delayed information, their ability to A/B test and assure quality of changes to their website will be impaired. <br /> <br /> By providing marketers time-delayed information, they more of their budget will continue to be spent on publishers providing relatively lesser value.<br /> <br /> <br /> == Open Questions ==<br /> * Will frequency reporting be available in addition to reach?<br /> <br /> == See Also == <br /> * [[MURRE]] is designed to address the time-delayed and aggregate impairments of machine learning Google's Aggregate Reporting API otherwise imposes<br /> <br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Aggregate Reporting API]]<br /> [[Category:Privacy Sandbox|Aggregate Reporting API]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Cohort&diff=234 2021-01-22T20:25:01Z

<p>AdminUser: </p> <hr /> <div>A Cohort is a set of identifiers that are grouped together based on some shared [[attribute|attributes]]. Often these sets of identifiers are mutually exclusive, meaning each identifier belongs to one and only one cohort. <br /> <br /> Clustering is a common algorithm to group identifiers into cohorts. <br /> <br /> == See Also ==<br /> [[:Category:Personal Data|Audience]]<br /> <br /> [[:Category:Personal Data|Personal Data]]<br /> <br /> <br /> [[Category:Personal Data|Cohort]]<br /> <br /> [[Category:Glossary|Cohort]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Cohort&diff=233 2021-01-22T20:23:33Z

<p>AdminUser: </p> <hr /> <div>A Cohort is a set of identifiers that are grouped together based on some shared [[attribute|attributes]]. Often these sets of identifiers are mutually exclusive, meaning each identifier belongs to one and only one cohort. <br /> <br /> Clustering is a common algorithm to group identifiers into cohorts. <br /> <br /> == See Also ==<br /> [[:Category:Personal Data|Audience]]<br /> <br /> [[:Category:Personal Data|Personal Data]]<br /> <br /> <br /> [[Category:Glossary|Cohort]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Cohort&diff=232 2021-01-22T20:23:19Z

<p>AdminUser: /* See Also */</p> <hr /> <div>A Cohort is a set of identifiers that are grouped together based on some shared [[attribute|attributes]]. Often these sets of identifiers are mutually exclusive, meaning each identifier belongs to one and only one cohort. <br /> <br /> Clustering is a common algorithm to group identifiers into cohorts. <br /> <br /> == See Also ==<br /> [[:Category:Personal Data|Personal Data]]<br /> <br /> [[:Category:Personal Data|Audience]]<br /> <br /> [[Category:Glossary|Cohort]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Audience&diff=231 2021-01-22T20:23:11Z

<p>AdminUser: /* See Also */</p> <hr /> <div>Audience Segment (also know as audience or segment) is a set of IDs that a marketer wants to message, because of one of more attributes. Attributes are analogous to pieces of information stored in an envelope, while the IDs are analogous to the address on the outside of the envelope. Marketers target attributes (e.g., interest=sports) rather than IDs (e.g., first name). Marketers create audience segments via Boolean logic segmentation or triggered-membership rules on the attributes associated with user IDs.<br /> <br /> == See Also ==<br /> [[:Category:Personal Data|Personal Data]]<br /> <br /> [[:Category:Personal Data|Cohort]]<br /> <br /> [[Category:Personal Data|Audience]]<br /> <br /> [[Category:Glossary|Audience]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Cohort&diff=230 2021-01-22T20:22:20Z

<p>AdminUser: </p> <hr /> <div>A Cohort is a set of identifiers that are grouped together based on some shared [[attribute|attributes]]. Often these sets of identifiers are mutually exclusive, meaning each identifier belongs to one and only one cohort. <br /> <br /> Clustering is a common algorithm to group identifiers into cohorts. <br /> <br /> == See Also ==<br /> [[:Category:Personal Data|Personal Data]]<br /> [[:Category:Personal Data|Audience]]<br /> <br /> [[Category:Glossary|Cohort]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Audience&diff=229 2021-01-22T20:21:50Z

<p>AdminUser: </p> <hr /> <div>Audience Segment (also know as audience or segment) is a set of IDs that a marketer wants to message, because of one of more attributes. Attributes are analogous to pieces of information stored in an envelope, while the IDs are analogous to the address on the outside of the envelope. Marketers target attributes (e.g., interest=sports) rather than IDs (e.g., first name). Marketers create audience segments via Boolean logic segmentation or triggered-membership rules on the attributes associated with user IDs.<br /> <br /> == See Also ==<br /> [[:Category:Personal Data|Personal Data]]<br /> [[:Category:Personal Data|Cohort]]<br /> <br /> [[Category:Personal Data|Audience]]<br /> <br /> [[Category:Glossary|Audience]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Cohort&diff=227 2021-01-22T20:16:13Z

<p>AdminUser: </p> <hr /> <div>A Cohort is a set of identifiers that are grouped together based on some shared [[attribute|attributes]]. Often these sets of identifiers are mutually exclusive, meaning each identifier belongs to one and only one cohort. <br /> <br /> Clustering is a common algorithm to group identifiers into cohorts. <br /> <br /> [[Category:Glossary|Cohort]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Cohort&diff=226 2021-01-22T20:13:24Z

<p>AdminUser: Created page with &quot;A Cohort is a set of identifiers that are grouped together based on some shared attributes.&quot;</p> <hr /> <div>A Cohort is a set of identifiers that are grouped together based on some shared [[attribute|attributes]].</div>

AdminUser https://wiki.prebid.org/index.php?title=Category:Privacy_Sandbox&diff=225 2021-01-22T20:06:14Z

<p>AdminUser: </p> <hr /> <div>Privacy Sandbox is a set of proprietary Chrome browser APIs that provide information to buyers and sellers of digital media.&lt;ref&gt;https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers&lt;/ref&gt; Many of these APIs rely on server-side components. <br /> <br /> This page lists Google Privacy Sandbox projects as well as proposed modifications to these projects to better meet the needs of publishers and marketers. When an organization other than Google is proposing a project in the list below there name appears in parentheses. <br /> <br /> <br /> == Media Planning Projects == <br /> Given a goal of the Privacy Sandbox is to prevent marketers from understanding which audiences are interacting across different publishers, this will not be directly addressed by this project. <br /> <br /> <br /> == Experience Management Projects ==<br /> Marketers engagement requirements are to show their content to their desired audience in the right context, while limiting the frequency capping across these different publishers. The &quot;right&quot; context is determined by the relative cost for a subsequent value generated from the exposure, such as brand awareness, click or conversion. Part of determining a desired audience is also filtering [[Non-human_Traffic|Non-human traffic]].<br /> <br /> Publisher engagement requirements are to show their content to their desired audience, while controlling for publisher business rules, such as controlling which types of advertising content can appear or appear together on the same page to a particular audience. Privacy Sandbox's time-delayed feedback may not meet publisher requirements for A/B testing nor quality assurance of their advertising.<br /> <br /> A goal of the Privacy Sandbox is to limit the precision of audience segments in context, as well as to limit the real-time feedback marketers receive to update their measurement and budget allocations. Thus the Privacy Sandbox engagement proposals either force marketers to choose to control audience OR context, but not combine the two, or alternately force marketers to engage imprecise cohorts defined by Google. <br /> <br /> * '''Audience Creation''' <br /> ** [[FLoC]]<br /> ** [[Turtledove]]<br /> ** [[Scaup]]<br /> ** [[Trust Tokens]]<br /> ** [[Privacy Budget]]<br /> ** [[Client Hints]]<br /> ** [[First Party Sets]]<br /> <br /> * '''Auction Management''' <br /> ** [[Turtledove]]<br /> ** [[Augury]]<br /> ** [[Dovekey]]<br /> ** [[Sparrow]] (Criteo)<br /> ** [[Parrrot]] (Magnite)<br /> ** [[Fenced Frames]]<br /> ** [[Tern]] (Adroll)<br /> <br /> == Reporting Projects ==<br /> Marketers reporting requirements are to understand which content generating relatively better outcomes when shown to particular audiences in particular contexts. The attribution of outcomes, which often occur on marketer properties, is part of the process that enables marketers to value the publisher inventory they buy. <br /> <br /> A goal of Privacy Sandbox is to prevent the link of positive outcomes on marketer properties back to particular publisher contexts. <br /> <br /> * '''Auction Management''' <br /> ** [[Aggregate Reporting API]]<br /> ** [[Conversion Measurement API]]<br /> ** [[Privacy Click Attribution]] (Apple)<br /> ** [[Pelican]] (Neustar)<br /> <br /> == Measuring Effectiveness and Ecosystem Impact ==<br /> Many marketers are concerned that the effectiveness of their media would be impaired by having reduced access to accurate, complete and real-time feedback across the various publishers they advertise on. Many ad-funded publishers are concerned that their revenues would decline as a result of this reduced effectiveness. <br /> <br /> Below are a few studies and approaches to quantify the impact on the ecosystem, expected by the roll out of Privacy Sandbox:<br /> <br /> * Google's Effects of Disabling Third-party Cookies on Publisher Revenue&lt;ref&gt;https://services.google.com/fh/files/misc/disabling_third-party_cookies_publisher_revenue.pdf&lt;/ref&gt;<br /> * [[FLEDGE]]<br /> * [[TEETAR]] (Criteo)<br /> <br /> == References ==<br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Privacy Sandbox]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Category:Privacy_Sandbox&diff=224 2021-01-22T20:05:38Z

<p>AdminUser: </p> <hr /> <div>Privacy Sandbox is a set of proprietary Chrome browser APIs that provide information to buyers and sellers of digital media.&lt;ref&gt;https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers&lt;/ref&gt; Many of these APIs rely on server-side components. <br /> <br /> This page lists Google Privacy Sandbox projects as well as proposed modifications to these projects to better meet the needs of publishers and marketers. When an organization other than Google is proposing a project in the list below there name appears in parentheses. <br /> <br /> <br /> == Media Planning Projects == <br /> Given a goal of the Privacy Sandbox is to prevent marketers from understanding which audiences are interacting across different publishers, this will not be directly addressed by this project. <br /> <br /> <br /> == Experience Management Projects ==<br /> Marketers engagement requirements are to show their content to their desired audience in the right context, while limiting the frequency capping across these different publishers. The &quot;right&quot; context is determined by the relative cost for a subsequent value generated from the exposure, such as brand awareness, click or conversion. Part of determining a desired audience is also filtering [[Non-human_Traffic|Non-human traffic]].<br /> <br /> Publisher engagement requirements are to show their content to their desired audience, while controlling for publisher business rules, such as controlling which types of advertising content can appear or appear together on the same page to a particular audience. Privacy Sandbox's time-delayed feedback may not meet publisher requirements for A/B testing nor quality assurance of their advertising.<br /> <br /> A goal of the Privacy Sandbox is to limit the precision of audience segments in context, as well as to limit the real-time feedback marketers receive to update their measurement and budget allocations. Thus the Privacy Sandbox engagement proposals either force marketers to choose to control audience OR context, but not combine the two, or alternately force marketers to engage imprecise cohorts defined by Google. <br /> <br /> * '''Audience Creation''' <br /> ** [[FLoC]]<br /> ** [[Turtledove]]<br /> ** [[Scaup]]<br /> ** [[Trust Tokens]]<br /> ** [[Privacy Budget]]<br /> ** [[Client Hints]]<br /> ** [[First Party Sets]]<br /> <br /> * '''Auction Management''' <br /> ** [[Turtledove]]<br /> ** [[Augury]]<br /> ** [[Dovekey]]<br /> ** [[Sparrow]] (Criteo)<br /> ** [[Parrrot]] (Magnite)<br /> ** [[Fenced Frames]]<br /> ** [[Tern]] (Adroll)<br /> <br /> == Reporting Projects ==<br /> Marketers reporting requirements are to understand which content generating relatively better outcomes when shown to particular audiences in particular contexts. The attribution of outcomes, which often occur on marketer properties, is part of the process that enables marketers to value the publisher inventory they buy. <br /> <br /> A goal of Privacy Sandbox is to prevent the link of positive outcomes on marketer properties back to particular publisher contexts. <br /> <br /> * '''Auction Management''' <br /> ** [[Aggregate Reporting API]]<br /> ** [[Conversion Measurement API]]<br /> ** [[Privacy Click Attribution]] (Apple)<br /> ** [[Pelican]] (Neustar)<br /> <br /> == Measuring Effectiveness and Ecosystem Impact ==<br /> Many marketers are concerned that the effectiveness of their media would be impaired by having reduced access to accurate, complete and real-time feedback across the various publishers they advertise on. Many ad-funded publishers are concerned that their revenues would decline as a result of this reduced effectiveness. <br /> <br /> Below are a few studies and approaches to quantify the impact on the ecosystem, expected by the roll out of Privacy Sandbox:<br /> <br /> * Google's Effects of Disabling Third-party Cookies on Publisher Revenue&lt;ref&gt;https://services.google.com/fh/files/misc/disabling_third-party_cookies_publisher_revenue.pdf&lt;/ref&gt;<br /> * Google's [[FLEDGE]]<br /> * Criteo's [[TEETAR]]<br /> <br /> == References ==<br /> &lt;references /&gt;<br /> <br /> [[Category:Glossary|Privacy Sandbox]]</div>

AdminUser https://wiki.prebid.org/index.php?title=Scaup&diff=220 2021-01-12T16:56:28Z

<p>AdminUser: </p> <hr /> <div>The goal of Google's Scaup is to provide marketers [[Look-alike modeling|look-alike modeling]] capabilities, without providing marketers access to event data.&lt;ref&gt;https://github.com/google/ads-privacy/tree/master/proposals/scaup&lt;/ref&gt;<br /> <br /> Google's Scaup proposal relies on Multi-Party Computation (MPC) whereby the web client sends an encrypted version of its personal information to two trusted servers to build models and the outputs of these models is stored for later application. Each of the MPC servers must store historical data to be used as inputs into the modeling. However, under current design the MPC servers are not provided complete information. <br /> <br /> MPC means that so long as one of these servers is trusted to be accountable, then there is a guarantee that if the other server is not being &quot;honest&quot; with its calculations it can be detected. &quot;Honest&quot; means that the result is mathematically accurate. <br /> <br /> The web client periodically queries the trusted server to receive guidance on whether it belongs to a look-alike model. To receive the correct audience attribute membership the web client must send the information that was used to train the model. Thus the web client sends its history rather an identifier. <br /> <br /> Under this proposal, the marketer is allowed to push the machine learning model to the trusted server. The trusted server informs the browser to store the events and features that would be inputs into the machine learning model.<br /> <br /> Scaup still relies on [[Turtledove]] auctions that keep audience-based buying separate from contextual buying. <br /> <br /> == Impact ==<br /> Prospecting is a critical activity for marketers. Prospecting chooses audiences that are believed to be more likely to become new customers. By centralizing control over this important function, marketers will have less choice on the vendors they can use. <br /> <br /> Another potential impact is given the time delay in this look-alike modeling process assigning a given web client eligibility for a new audience attribute, the user experience will be diminished.<br /> <br /> There are limits on scalability given web clients cannot process or store the information to support the multiple vendors marketers rely upon to generate audiences for each marketer brand. Bandwidth and battery impact on portable devices associated with audience creation are other related issues.<br /> <br /> See Turtledove impacts for auction-related issues.<br /> <br /> <br /> == Open Questions ==<br /> * Given each marketer would like to generate different look-alike models for different products, how much data is required to be sent and stored on the web client? <br /> * What is the process for determining which organizations' servers are trusted?<br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> <br /> [[Category:Glossary|Scaup]]<br /> [[Category:Privacy Sandbox|Scaup]]</div>

AdminUser