-
Notifications
You must be signed in to change notification settings - Fork 0
[AE-1142] Include ad client dma in the interaction and request-stats pings #9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
16fb96b to
d5a6075
Compare
gleonard-m
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was a data collection review created for this?
No I didn't do a data review for this change, is it needed? My thought was we're already collecting this data in other pings, and in some cases in other fields of the same ping, but I'm happy to kick that off now if necessary |
d8d396d to
c5a22e2
Compare
|
DATA REVIEW REQUEST
In preparation for fully rolling out OHTTP between Desktop FFox and MARS, we need to capture some coarse geo info about the ad client in all our pings, since we will no longer be able to rely on the client's IP address to derive this data. We were already capturing the CountryCode and the RegionCode in interaction and request-stats, this change adds capturing the DMA. (provider-request-stats already captures all three geo info fields).
When we make requests to ad providers, we need to let the ad server know roughly what area the client is coming from so that only relevant ads are returned. So in the case of the request-stats ping, we record for system observability and correctness. In the case of the interaction ping, we record for those same reasons, and for our ad business reporting internally.
With the introduction of OHTTP between FFox Desktop and MARS, we no longer have the X-Forwarded-For ip_address field that we used to have in the standard glean ingestion. We are replacing that with three explicit geo metrics, CountryCode, RegionCode, and DMACode. This change completes the third geo metric. (This answer is based on some preliminary conversations in #glean, summarized in https://mozilla-hub.atlassian.net/browse/AE-1142)
Soon it won't be able to, so this change shores up our preparation for OHTTP across the metrics we collect.
This collection is Glean so is documented in the Glean Dictionary.
This collection will be collected permanently.
All channels, countries, and locales. No filters.
These collections are Glean. The opt-out can be found in the product's preferences.
This data will be part of standard ad reporting for observability, correctness of ad targeting, and as internal business metrics to understand the coarse geo info of where ads are being requested from and returned.
This data will surface in standard dashboards for ad interactions (impression and click data tables), and MozAds team will use this to understand revenue/business insights.
No. |
|
Sensitive Data Review Team has given us the go-ahead to move forward with this change. |
Tickets or other relevant links:
https://mozilla-hub.atlassian.net/browse/AE-1142
What's Here
In preparation for rolling out OHTTP between Desktop FFox and MARS, we need to capture all the ad client's geo fields in all our pings -- specifically the interaction and request-stats ping.
Things I'd Like Feedback On
Lmk if you see any issues with capturing this. Looks like it is already available in the backend.
Testing
This can be tested via the companion PR in MARS that use the updated pings structure, see the Testing section there.
Any concerns with backwards compatibility?
No, these changes are additive.