You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Understand that restricting conversion metadata to 3 bits is purposeful, however this doesn’t allow the specific conversion value to be specified for the conversion. This effectively prevents any ROAS optimization, either by ad tech or by the advertisers. This would be severely limiting from Microsoft Ads perspective as ROAS optimization (e.g. Target ROAS auto bidding) is one of the most popular optimization tools used by advertisers.
It would be good to understand more clearly what the privacy risks associated here are. Also would like to understand what Google Ads position on this is since it would impact Google Ads advertisers similarly. Just for the sake of completeness, although the aggregate API can allow conversion values in aggregate, it does not work for ROAS optimization scenarios such as auto bidding.
The text was updated successfully, but these errors were encountered:
I can't speak for Google Ads, but things like ROAS optimizations are definitely on my radar, and I agree that doing them with the 3-bit event level API would be difficult. I think the best thing you could try is to apply some discretization of the value (e.g. in log space) and do a post-processing step where conversion metadata is translated back to value on the server side, though I understand it will have a lot of error.
For the privacy risks, we want to make sure conversion reports cannot be used to:
Join user identity between publisher / advertiser sites, even after repeated conversions
Learn too much about any one user's activity on the advertiser site after an ad click
These two principles led to our API design. These challenges come up because a conversion report in our API has the capability to be associated with a user on the publisher page (via the 64 bit ID). If we move away from reports (potentially) identifying individuals and move to aggregate reporting it is much easier to get more accurate data (e.g. with central differential privacy) that can encode more information like conversion value. I think it would be valuable to see how far you could go with training a bidding system that uses a combination of event-level and aggregate data for this purpose.
Understand that restricting conversion metadata to 3 bits is purposeful, however this doesn’t allow the specific conversion value to be specified for the conversion. This effectively prevents any ROAS optimization, either by ad tech or by the advertisers. This would be severely limiting from Microsoft Ads perspective as ROAS optimization (e.g. Target ROAS auto bidding) is one of the most popular optimization tools used by advertisers.
It would be good to understand more clearly what the privacy risks associated here are. Also would like to understand what Google Ads position on this is since it would impact Google Ads advertisers similarly. Just for the sake of completeness, although the aggregate API can allow conversion values in aggregate, it does not work for ROAS optimization scenarios such as auto bidding.
The text was updated successfully, but these errors were encountered: