[MUSIC PLAYING]
ERIN WALSH; Hi, my name is Erin Walsh,
and I'm a Developer Relations Engineer on the Privacy Sandbox
team here at Google.
Today, I'll be talking through what's
next on the Privacy Sandbox on Android.
In this talk, we'll start with a brief refresher
of what the Privacy Sandbox entails,
and when to expect new releases and features.
Then we'll walk through a couple of adtech use cases
and how to implement them with the Privacy Sandbox APIs.
Finally, we'll review some resources to help
get started with integration.
The Privacy Sandbox aims to improve user privacy
without putting access to free content and services
at risk for the mobile ecosystem.
To do this, we have Topics, FLEDGE, Attribution Reporting,
and the SDK runtime.
The Topics API gathers on-device information
to infer topics of interest to a particular user, which
advertising SDKs can use to serve relevant ads.
The FLEDGE API orchestrates ad selection workflows and shows
ads based on custom audiences defined by app developers.
The Attribution Reporting API supports the measurement
of clicks, views, and conversions,
and sends the reports to advertisers that detail
the performance of an ad.
The SDK runtime allows third-party ads-related SDKs
to run in a dedicated runtime environment that
provides safeguards around user data collection and sharing.
These APIs allow you to monetize your app
with relevant and high-performing ads,
while still protecting the privacy of your users.
App developers can typically work with their advertising SDK
partners to integrate the Privacy Sandbox.
Since our initial announcement in February,
we've been busy releasing developer previews, which
allow you to integrate and test all of the APIs
that I just mentioned.
Right now, you can check out what's
new in Developer Preview 6.
We plan to enable testing of the Privacy Sandbox
on public mobile devices in early 2023.
We'll also release our first stable API release
in a future SDK extension for you to integrate.
After that, we will continue releasing developer previews
in parallel to stable API releases
to expose the latest features.
To test against developer previews and stable releases,
developers will need to complete an enrollment process that
enables access to the Privacy Sandbox.
When the first stable API is released,
the Privacy Sandbox will initially
be made available on a small percentage of eligible Android
13 devices.
So when is the best time to start
testing the Privacy Sandbox?
The answer is right now.
The sooner developers can start incorporating the Privacy
Sandbox, the more action we can take on any feedback
that you might have during your integration.
We need your help to make the best product that we can.
So now that we've had a recap of what the Privacy Sandbox is
and where we're at in development,
let's take a look at some practical examples
using the Privacy Sandbox APIs.
These examples demonstrate a few of the many ways
you can put the Privacy Sandbox into practice.
Adtech developers want to know what users are interested in,
so they can serve ads that are interesting and relevant
to the people seeing them.
To do this, they can use the Topics API
to receive a list of interests that are
relevant to the user of an app.
The Topics API infers these core screen interests
on device with added noise to protect user privacy.
It is encouraged to start integration with the Topics API
and work with advertising partners
to include topics and ad requests so that they
can be used for ad selection.
To do this, first, instantiate the Topics manager.
Then instantiate the Topics request builder,
which can be used as is, or populated
with options for the request.
Then the topics manager can be used to call getTopics
and will return a callback.
The Topic objects will include a Topic ID, which corresponds
to a taxonomy entry.
In this case, our user is interested in cats, concerts,
and winter sports.
You can view the full taxonomy on our Privacy Sandbox GitHub
page.
Advertiser apps want to select the best possible ad
to be shown in other apps on the same device.
To do this, they can use the FLEDGE API
to add a device to a custom audience based on the actions
that a user takes.
The custom audience carries information
for candidate ads and logic to determine which ad to display.
Let's say the user accesses this children's menu in a restaurant
app.
This action would be a good trigger
to join the device to a custom audience for families
of children.
In addition, the restaurant app lets the ad network
that manages its ads know about this custom audience.
This can be accomplished with the FLEDGE API
by creating a custom audience.
This will include information such as the name of the ad
network that manages your ads, where the ad network hosts
your ad content, and the name of the custom audience
itself, in this case, families of children.
Once the custom audience has been defined,
it can be used to create a custom audience request.
Then the custom audience manager can be instantiated and used
to make the call to joinCustomAudience
with the requests that was just created.
Now, this device is part of the families of children audience.
Now that we have a custom audience on this device,
a publisher app on the same device
will want to consider the ads that
are associated with that custom audience
when choosing an ad to display.
To do this, the publisher app's ad
netwok STA can use the FLEDGE API to call select ads.
Let's say the publisher app is a travel guide app.
This travel guide app wants to display ads
while the user researches attractions, landmarks,
and restaurants.
The travel guide's ad network SDK
will start by building an ad selection config to set up
the auction parameters.
The builder can be used to set variables for ad selection.
The ad networks SDK can use these variables
to pass signals that are relevant to the advertising
slot that the auction wants to fill,
for example, what kind of food the user likes.
After creating the builder, instantiate the ad section
manager, then use the config that was just created
in the call to selectAds.
This will start an auction process
that decides which add will be selected
to be displayed in the publisher,
in this case, the traffic guide app.
The ads considered for this process
will come from the custom audiences
present on the device, in this case, the families of children
custom audience from the restaurant advertiser app.
The auction will run, and a winning ad
will be selected, which could be the ad from the families
of children custom audience.
Because the custom audience is not shared directly
between the advertiser and publisher apps,
FLEDGE can perform ad selection while protecting user privacy.
To implement an end-to-end ad selection process,
it is important that the advertiser app and publisher
app work together.
This implementation of the FLEDGE APIs
has been simplified for time.
We did not get into the details of what
happens when an auction is run.
I highly encourage you to check out our documentation
for more details.
After an advertisement is displayed in an app,
ad tech developers will want to assess
how well the ad is performing.
This can be done with the Attribution Reporting
API, which accomplishes ad measurement
goals without the need for cross app identifiers, which
limits information ad tech companies receive about users.
The Attribution Reporting API receives information
about how the user is interacting
with an advertisement from an Android app, SDK,
or Chrome mobile browser.
Once this information is gathered on device,
the Attribution Reporting API sends reports
to a designated service.
This service is set up by whomever
is receiving the reports, for example, a mobile measurement
partner.
Let's say a user views or clicks an advertisement in your app.
You can record these interactions
with the measurement manager's registerSource function.
RegisterSource calls an endpoint from the adtech service
that is enrolled with the Privacy Sandbox.
And this endpoint can include optional identifiers
to include more information about the interaction,
such as the identifier of an ad campaign.
After the user has seen or clicked the advertisement,
let's say they were inspired to purchase
the product being advertised.
You'll want to record this action as a conversion.
You can do this by invoking measurement manager's
registerTrigger function.
Similar to registerSource, you'll
pass registerTrigger an enrolled endpoint
from the adtech service, and can include optional identifiers.
Now that you've registered a user's interaction with the ad,
you will want to receive and interpret that data.
The data that gets sent to the adtech service
in the form of event level and of aggregate reports.
Let's take a closer look at the information in each report.
The event-level report contains information
about specific conversions that happened on the device.
Because these reports refer to specific conversions,
the information in these reports is limited to protect privacy.
You'll find information such as the attribution destination,
which refers the app in which your event happened;
the source of an ID, which refers the ad that
led to this report; the trigger data, which
is low-fidelity data for conversions;
the source type, which refers to whether the interaction is
a click or view, in this case, navigation refers to a view;
and the randomized trigger rate, which is a parameter for adding
noise to event reports.
The aggregate report details how well your advertisement
is doing overall.
There are many ways to measure the success of an ad
based on different business needs.
So the aggregate report is customizable
depending on what you want to measure.
For example, if you want to measure how many purchases
of a product were made in a certain geographic region
due to an ad campaign, you can design an aggregation key
to measure the amount of purchases
based on those categories.
The payload will return an aggregate key referring
to the ad campaign, geographic region, and product,
and the aggregateable value, which in this case
refers to the amount of purchases
made in those categories.
In practice, the payload information
will be encrypted in the report and bundled along
with some other information about the report,
such as the reporting origin, which lists the URL where
the report was sent.
You can learn more about designing and receiving
aggregateable reports on our documentation.
Now that you've seen some examples of the ways
that you could choose to implement advertiser use
cases with the Privacy Sandbox, we
encourage you to go try out the APIs.
You can find sample apps on our GitHub page, development
guides, and videos to help you get started.
Please reach out if you have any feedback for us along the way.
The earlier we receive feedback on the Privacy Sandbox,
the better we can adjust it to make the best product possible.
Thank you so much for watching.
[MUSIC PLAYING]