[MUSIC PLAYING]
PJ MCLACHLAN: Your users
know that the word install
means that it's software
that's meant for their device,
and you want to meet
your users' expectations.
So that's what you see there on
the right, an app that launches
from the home screen and is
essentially indistinguishable
from a native experience.
Let's start at the beginning
of the story though.
Bookmarks are the
original way for users
to get back to anywhere on the
web they wanted to get back to.
They're kind of a
universal install button,
and they've been available
on every major browser
since the dawn of the web.
So a good question would be,
why don't we just use that?
And in a word, the
answer is mobile.
Of course, you can
bookmark on mobile,
but it never really
fully made the jump.
And we do see significantly
less bookmark usage on mobile
than we see on desktop.
One reason for that
is that the UI just
isn't quite as convenient.
And that's not just
saving the bookmarks,
it's also organizing and
finding them as well.
The second challenge that we
see for bookmarks on mobile
is that apps, as we
just saw right now,
integrate into the mobile
OS in ways that are
important for functionality.
So for example, a
lot of apps do need
to tie in to, say, Android's
native sharing sheet, which
is what you see on the
right side of the slide,
where a URL is shared from
the Myntra PWA to Twitter.
And to enable a share target,
we needed OS level entity.
We need something like
an APK on Android,
and not just a bookmark
A lot of you will be
familiar with this term Add
to Home Screen.
And again, you see that on
the right in the Starbucks
screenshot in this example.
Unfortunately,
Add to Home Screen
can actually mean
two different things.
It could mean that
it's a bookmark that's
being placed on the home
screen, or it could also
mean that it's
actually an integrated
experience on the device.
And that's why we'll be
using the word install
for the rest of this talk
to talk about the integrated
experience.
And in the future, you're going
to see this in the browser UI
on mobile and desktop.
The reason for that is
install is a UX affordance
that's familiar to
mobile users who
are used to adding content
from their OS's stores,
such as Play, and then
finding that content again
on the device through whatever
the native launch surfaces are.
So on mobile, usually
from the home screen.
Install aligns to a user's
mental model for how install--
basically, how experiences
ought to operate on the device.
An installed web app looks and
feels like every other app.
And the fact that your user
discovered and installed
your app from the
browser or from Play
shouldn't actually
matter when they go back
to use your app again.
Most importantly, the word
install signals to users
that the experience was meant
to be great on their device.
Here's a summary of
how web install is
different from bookmarks.
Web install offers
users access to web apps
from familiar
discovery and launch
surfaces for their device.
So install web apps
can be standalone.
That means they can be
separate from the browser.
It also means that they can be
integrated into the native task
switcher.
And they can-- this is gonna be
a more familiar way for users
to interact with
apps, or it might
be more suitable to certain
types of tasks than tabs.
Web install integrates
the web apps
with the device services
that expect an installed app.
The important thing to remember
when you're asking a user
to install a PWA is that
with an installed app,
you're telling the user that
it is an experience that
is meant for the device
that the user is using,
and that means that
you need to live up
to those expectations
of what you design,
or you're going to
have unhappy users.
There's a good thing that we
have a pattern for building
experiences that do just that.
Progressive Web Apps are
a pattern for great apps
that use web technology.
And they have all the
features and functionality
users expect from a modern
app on mobile or desktop.
I'm sure most of
you in this room
are quite familiar with
PWAs at this point,
so I'll just cover some of
the very high level background
information about PWAs
for those of you who
maybe are new to the concept.
PWAs include things like
personalized content,
offline mode, push
notifications,
and instant loading.
And PWAs and installed web
apps do go hand in hand.
You need to have a PWA in
order to offer install.
There are, of course,
other projects
that are trying to
crack this problem,
and you can take a look at React
Native, at Electron or Cordova.
And all of these are
basically offering you
a way to build native
apps using web technology,
but those experiences do depend
on functionality that won't
also work in the web browser.
PWA's goal is to build
directly on the web.
So that means you can
maintain one code base
and that's going to work for
visitors both in the browser
as well as for your
installed users.
SAM THOROGOOD: So hi.
I'm lucky enough to get
to work on "Santa Tracker"
every year, which is
a fun holiday themed
experience for all ages.
And so we'll be using this
as an example as we go along.
Santa runs on
basically everything
with a browser, even this
magical screen changing device.
And so we find that
folks who install it
to their home screens on
any one of these platforms
where it's supported are some
of our most engaged users,
coming back the most often.
And on Android alone,
a few years ago,
we found that about
10% of all our loads
were coming from
that installed icon.
So that's a quite nice number.
This is fundamentally because,
when an app is installed,
your users will feel like
it is designed for them.
Users will have better
engagement, more loyalty,
and have a positive
experience with you
with your installed application.
But of course, who
are these users?
Who is going to benefit
from this extra power?
We're the first ones to admit
that it won't be everybody.
The power of the web has always
been that it is ephemeral.
Users can move seamlessly
between experiences,
and so you shouldn't expect
all of your users to install.
And to that end, there is
a bit of an install funnel.
This is the same as native
apps or e-commerce conversions.
Most strategies for
optimization apply here as well.
You don't want to push the
user to convert too soon
or they'll leave
your site running.
You should only promote install
to users who are frequent users
or who will actually
benefit from your services.
You know, focus on
features that users
might care about, like smaller
download size or faster access.
You'll also want to track
the right events in analytics
to make sure you know
what to optimize.
PJ will cover this
a bit later on.
So promote web
install on screens
where the use case makes sense,
including desktop, tablet,
and mobile.
Take this example of Spotify's
CTA from a landing page.
We'll also be covering more
of these as we go along.
So we've covered some of the
what and some of the why.
And I'll continue now by talking
about the how of install.
Your basic requirements for
supporting the installable web
are to have both our Web App
Manifest and a Service Worker.
These are actually, in 2019,
pretty well documented.
These are the same
requirements, as we
mentioned, to be called a PWA.
I'll mostly be
covering the Manifest.
For the Service Worker, just
briefly, the requirement
is that you do
actually load offline.
If your user clicks on your
app icon while they're offline,
and they see nothing
or an offline dino,
users will have a bad
time and so will not
allow it to be
installed in this case.
I think you'll find some great
amazing content on Codelabs
for Google and Service
Workers online.
The Manifest is a
simple JSON file,
which basically informs
your user how the site acts
when it's installed.
You need one per app, and you
need to include a link to it
from every page of your
site so the user can
tap install anywhere.
And I'm kind of
trivializing it, but pretty
much all modern browsers
have some level of support
for this file, and
including it's quite simple.
You simply include a
link in pretty much all
your pages, as I
mentioned, because you
don't know where your user
will hit install from.
One of its core
parts is controlling
what your launcher icon
will actually look like
and the start page that
opens when you press it.
He's what an Android
experience will be.
"Santa Tracker" has a little
green icon with a short name,
and you'll see something
quite similar when
an app is installed on desktop.
The Manifest also controls
how your app is loaded.
For games, you might
choose full screen.
See the example on the right.
But for anything
app like, you want
standalone, which won't take
over the target device's UI.
Websites running in
any mode can still
use browsers' APIs to
later request full screen.
There's a few
other options here,
including browser which
retains the URL bar.
But honestly, we don't think
this is that interesting,
and so we think
these two options are
what most people will end up
choosing when they configure
their installed PWA.
The Manifest itself
is pretty boring.
Here it is for completeness.
I won't go through every field.
Like I said, there's
actually tons of information
out there on the web.
But I want to cover
some important patterns.
You need to include a
few icons, including one
which is at least 512 by 512.
And remember that this
isn't your site's fav icon,
so you still need to
include one of those.
In building "Santa Tracker,"
one thing we really discovered
was that there's no implicit
internationalization support.
You need to serve a different
Manifest for every language.
And icons, the standard also
now describes maskable icons.
The very short version
is, if you provide an icon
and indicate that it's
maskable, this is a signal
to the platform that it can
cut your icon down to safely
display crazy icon
types like circles,
[? square-circles, ?]
or teardrops,
making your users feel like the
app was really made for them.
And with this, we
actually recommend
not using transparency
in your PWA icons at all,
because the OS is handling
this part for you.
Of course, this is
still a bit brand new,
so we recommend also
loading up your app
in some major
environments to check
what the icon will look like.
There's a few more things
coming in the Manifest which
are also worth mentioning.
App shortcuts have just
been added to the spec.
This lets an install icon
provide secondary intents,
perhaps with one press.
I've kind of cheated here and
show you an Android example
of this case.
And Web Share Target,
which we'll cover more,
allows an installed web app
to be a target for sharing.
We're also just seeing a bunch
of tooling around manifests.
And we think that honestly,
going forward, nearly
every tool chain will just
provide you a web app manifest.
And so while we're
glad you're listening,
this stuff is also
becoming just boring enough
that it's likely handled for
you, which is great for us
as web developers.
So as I mentioned
earlier, Manifests
are supported by pretty much
all modern browsers, which
leads me on to,
well, the nuances,
a web developer's best friend.
Let's start with Android.
This was the first place
that install was available,
and once installed, apps
are first class citizens
provided by real native APKs.
Importantly, Chrome
on Android is actually
able to prompt your
users to install
if your site includes a
Service Worker and a Manifest.
"Santa Tracker" here is
actually pretty ambitious.
If you take a look
at this animation,
even during the
loading screen, it
pops up a little mini info bar.
It's not ideal, but we'll
revisit this in a bit.
Regardless, if you
then tap that info bar,
you'll get a full screen
prompt to install.
There's a few things
to dissect here.
While this does say Add to
Home Screen, as we mentioned,
we're moving away
from that verbiage
as we support really
so many platforms now.
And as I mentioned, this
generates a real APK
that works with any
launcher, and is really
a first class system for
users like any other installed
application.
Another option for
install on Android
is something called Trusted
Web Activities or TWA.
While this has a few
[? details ?] to get through,
fundamentally, you're writing
an Android application which
features a core activity
provided by Chrome,
or actually, fairly
soon, Firefox as well.
And you're uploading
it to the Play Store,
so it's discoverable
and promotable
like any other native app.
The best way to learn more
here is to go and follow
Google's Codelabs on this.
Do a search for TWA
Codelabs to find out more.
We've also got an
interesting option
for folks who are using
Managed Play with G Suite.
This means if your organization
signs into corporate Gmail
on their devices,
you can simply push
real APKs that load your
website by Managed Play.
There's quite a few steps.
This video is quite long.
But if you watch
closely here, I've
built "Santa Tracker for Work,"
which pushes "Santa Tracker"
to all the elves
and in Santa's org.
So while we think this
is real interesting,
it's also worth noting that your
corporate users will actually
never see the URL that's
being added to their device.
You're able to push any
website as a real app, not just
your own.
Finally, and probably
most interestingly,
let's talk about the how in iOS.
iOS has had install for web
apps since the beginning,
but the last few
releases have really
made install in iOS
quite practical.
Here's an example of loading
"Santa Tracker" from the iPad.
We do have to have custom icons.
This is done by the iOS metadata
icon tags, which I won't really
cover here.
And while they're
a bit of a pain,
tooling can help
you generate these.
Apple has also
previously suggested
providing splash screens.
Honestly, we don't think this
is that important anymore.
IOS 13 has brought you
nice animations and fades
that make sure that your website
isn't just jarringly dumped
on the screen.
We didn't use one
in this example.
And last but not least, I also
want to talk about desktop.
Only Chrome provides install
on desktop right now,
but it works well across
all platforms, macOS, Linux,
Chrome OS, and Windows.
Your sites will get
the little plus button,
and users will get a native app
that lives in their launcher.
The plus button will
even wiggle a little bit
if you do the right thing,
calling attention to the fact
that install is available.
PJ MCLACHLAN: Thanks, Sam.
I'd like to cover some
of the frequently missed
details that will help you
acquire more installed users.
So first, a lot of
companies have native apps
and worry about accidentally
promoting the PWA to a user who
already has their app.
And you may want to
promote your PWA,
but you want to
explicitly target
a group of people that are
not your native app users.
Now, keep in mind that
there's all kinds of reasons
that a user may not have
or want your native app
but might still
want the web app.
Storage, for example,
is the number one reason
that users remove apps
from their device.
But most web apps are
tiny, and the stores
that most web apps use
can be dynamically purged
from the browser through
either a manual cache clear
or in response to
storage pressure.
So you may want to let
users know that the web app
option exists, but you don't
want to create any channel
conflict with your native apps.
So to avoid promoting your PWA
install feature to native app
users, you want to use the
getInstalledRelatedApps,
just there to help.
This API is going to let you see
in JavaScript if the user has
your native app installed.
getInstalledRelatedApps
is not in stable yet,
but it is in an
origin trial, which
is an early access program.
You can still use it
on your site today.
An origin trial might sound
scary, but all it means
is that you need
to register online,
and the API will be enabled
for all Chrome visitors
to your site.
SAM THOROGOOD: If only
there was some search engine
that will help you with that.
PJ MCLACHLAN: If only.
Most PWA installs
today are happening
from the mini infobar.
The mini infobar was only
intended as a temporary shim.
It's not the best
user experience.
And since it's generated
by the browser,
it really has no way of knowing
whether this particular moment
is the right moment
to present to the user
the option to install.
It just shows up
as soon as the site
passes installability criteria
and the user engagement
measure.
You're going to want to replace
the mini infobar with something
better.
And we're going to get to what
is better than the mini infobar
soon, but first you
need to hide it and make
sure the mini infobar doesn't
appear if you don't want it.
And all you need to do that
is to call preventDefault
on the
beforeinstallprompt event.
Make sure that
you've added the UI
that you need to trigger
the install prompt
before you do this though,
or you will literally
have no installed users after
you prevent default on this.
So let's look at the
code for a second.
The relevant line is right
here, event.preventDefault.
And that's the critical thing
for hiding the mini infobar.
Most sites, it should be
a very trivial change.
So let's assume that you've got
a UI element in the page called
Install Button and
that you're going
to want to display
this Install Button as
soon as the browser signals
that your app can be installed.
You don't want to
show this beforehand,
because this button won't work
the way that the user would
expect it to work.
This element should be
hidden and then enabled,
and that's exactly what
we do in this next line.
And finally, you're
going to want
to capture a reference
to the install event
so that you can use it
to prompt the user later
when the user actually clicks
on that Install button.
And now we can look at
exactly how you do that.
So here's how you use
that save reference.
So let's imagine that you want
to wait until the user has
finished some important journey
that's part of your experience
before you prompt them.
You could use this stored handle
for whenever you're ready.
The user clicks on
the Install button
in your UI to trigger the
browser's UI for the install
prompt.
Don't forget to
instrument analytics
so that you can understand your
user's behavior with respect
to install prompts.
There's really three
important moments
that you want to capture
here for your analytics.
So the first is when that
prompt is actually available,
when did the site fulfill
the installability criteria?
And that happens with the
beforeinstallprompt event.
And that's what you listen
for, and you can set up
an analytics event there.
The second is the analytics for
when the prompt is triggered.
If you're taking the
recommended approach here
and you're tying that to a
piece of UI inside of your web
content, then this is going
to be probably a click
handler on some element
inside of your page.
And finally, when
the user has actually
completed the app
install, you're
going to want to listen for
the app installed event.
And this is what's going to
tell you that the app install
was completed
successfully and the user
hit OK from the browser UI.
So you may be asking
yourself, what about iOS?
And the great news here is
that iOS Safari has had support
for the essential PWA
Ingredient Service Worker
for quite a while now.
And it's easier than
ever to install PWAs
from iOS Safari with
Add to Home Screen
like moving to an option
on the first level menu.
So here's an install
promotional pattern for iOS
that we're going to use
for "Santa Tracker."
Notice how this--
we're basically
triggering a pop-up
helper to help
the user through the install
experience from the Install
button.
And this is the
same Install button
that we're going to
use on Android as well.
So the delta between
the two experiences
is really quite small.
SAM THOROGOOD: So
with that, I want
to talk briefly about a
few different UX patterns
for your installed PWAs.
So "Santa Tracker" is
pretty unique, right?
It already has a pretty
simple look and feel,
and your site probably doesn't.
It looks like a
regular web page.
So the uncanny
valley for something
which looks almost correct,
which is ultimately
just a bit off, like this
almost right dino game
with some very odd UI elements.
If your experience doesn't
match your user's expectation,
they might be put off.
So we at Google love the web,
and there's now an expectation
that perhaps an installed
app acts and feels
like it's always been that way.
And this advice isn't
really unique to PWAs.
I want to talk
about the feeling we
get when we use web apps
like Gmail, Spotify, or even
Google Docs.
When I use these apps, I almost
forget that I'm on the web.
How can you help your users have
that same level of immersion?
There's a few tips I'd
like to talk through
to make your site
feel more native
and lose the uncanny feeling.
Focus rings are where
I'm going to start.
These let the user know
where the cursor is.
Pretty basic access
accessibility
feature, which you should keep.
But the default ring is a
definite tell of the web.
So mix it up, and this applies
to form elements as well
as links.
Text selection is also
probably something
you want to disable,
especially on UI components,
because it's not an
expected behavior
of installed applications.
Personally, I'm not ever
a fan of making this UI
part of a page selectable,
but it's especially pronounced
when installed.
And set a theme color.
This refers to the
window color of your app,
as you see in this desktop
version of "Santa Tracker,"
where it's a dark blue.
By the default, it's
from the platform,
so you don't really know
what you're going to get.
An over scroll, which you
can see happening here,
is actually somewhat
related, because it
can mean that three contrasting
colors end up showing.
And in most cases, you just
want to disable over scroll
to prevent this from happening.
It's a very web pattern.
As an alternative,
at least make sure
that your HTML tag is set to
a reasonable background color
that's not the default white.
Also very briefly
mention safe area inset,
which if you're a fan
of notches on phones,
let you avoid that
notch and put some color
or interesting content
behind that area.
You'll also want to think
about some UX changes.
I'm going to go through
these fairly quickly.
First, don't allow navigation
outside your own site.
If you do, users will get
a really ugly URL bar.
Make sure you always
open external content
in a new window.
Next, think about better
behavior for extended actions
like select all, undo,
and redo, especially
if your experience is app like.
But by default, undo and redo
only apply to text elements.
What if you're allowing
the user to reorder a list?
And finally, you might want
to do something different
with the right click menu,
especially when installed
on desktop.
The default menu includes
items like Save as or Cast,
which barely make sense
on some web pages.
And while it's bad practice
to disable this right click
menu on the web, when
you're installed,
that's really a license to
improve the user experience
by hiding these options.
PJ MCLACHLAN: So I've
mentioned a couple
of times the different ways that
you can promote your web app,
and here's where we
get into the examples
of how exactly to do it.
So keep in mind, as
we go through these,
that these patterns
aren't intended
for every kind of site.
They're examples
of good patterns
that you can use, but try
to understand your use cases
and use patterns that
are appropriate for you.
And please always
remember the rule of thumb
whenever you're prompting
users about anything
installed or otherwise,
don't be annoying.
[LAUGHTER]
Let's give this a try.
All right.
First, the header
can be a good place
to promote install
of your app, but you
do need to be careful here.
This one comes with a lot
of cautions and hand waves.
These are really
precious pixels,
and you want to use information
architecture and A/B testing
to determine whether it
actually makes sense for you
to have an install option
and a header of your site.
For some apps, this will
be a clear and obvious win,
and for other apps, it would
be completely inappropriate.
That will really depend
on your use case.
You may want to use an
icon instead of text,
if you want to make this action
button a little bit smaller.
And you might also want
to consider selectively
promoting only to users
that have engaged with you.
So for example,
could be only shown
to signed in users who clearly
have an interest in what
the product or service
that you're offering.
This is an example of adding an
install prompt to the hamburger
menu.
The great thing about
using the menu here
for promoting your
web app install
is that there's
already a strong signal
that the user is interested
in what you're offering
by clicking on the menu.
And I hope that this
is obvious, but you
don't want to block access to
any important functionality
in your app with
the promotion here
or anywhere else
for that matter.
You want to make
sure that it doesn't
overlay anything or
clutter up the menu design
or in any way take precedence
over the other actions
that the user might want to
take by clicking on that menu.
Here's an example of promoting
install via a landing page.
And landing pages are explicitly
about marketing your product
or service, and so this is
really your one opportunity
to go crazy, be as
big as you want.
But just keep in mind that
all the usual best practices
for creating a good landing
page are going to apply here.
In particular, the
most essential thing
about your landing
page is that the user
understands what the value
proposition that you're
offering them is.
If your install pattern is
getting in the way of that,
then chances are you're going
to lose both the potential user,
and you're certainly
not going to encourage
them to actually install.
Here's an example of
an in feed pattern
for promoting PWA install.
And feed cards are very common
these days in many types
of apps, including in social
and news, e-commerce--
basically anywhere where there's
a lot of vertical scrolling
and chunked information.
Don't show this
promotion too often.
And if a user
dismisses the card,
please remember and respect
the user's choices here.
Every app's use case is
a little bit different,
but there's almost
always some key moment
of engagement in
the journey when
you know that the user is truly
interested and understands
what it is that you're offering.
And that's a great moment to
ask if they want to reconnect
with you in the near future.
The usual rules apply here.
You want to always focus
on the benefit to the user
and use the context
of the key moment.
In this example, the user's
just finished a game.
It's a great
opportunity to say, hey,
do you want to play
again really easily?
You can find this again
from your home screen.
So let's recap on
the principles here.
Don't be annoying.
Your users came to your
site to get something done.
If you interrupt
that flow or make it
in any way difficult for
them to get the task done
that they came to
your site for, chances
are they're just
going to leave and go
get it done somewhere else.
Information architecture
is your friend
for figuring out
what belongs where,
and that includes for
promoting install.
Second, remember that if
the user doesn't benefit,
you shouldn't be promoting it.
And finally, do use
the context where
is the user in their journey
to help the user understand
what they're actually going to
get out of installing your app.
If you want to
learn more, you can
search through the fundamental
site with a query Promoting
Install.
Now, investing in a
great PWA and making
that PWA installable
does have big benefits
for user engagement.
To talk about these
benefits in practice,
Mukund, a Product Manager
for OYO Consumer Experience,
is going to join us
on stage and talk
about the impact
installability has
had for them and their team.
As a little bit
of background, OYO
is the world's second
largest hotel chain,
and it has a presence in
more than 80 countries.
It has more than 23,000 hotels.
And with the rapid growth,
they have basically
pursued mobile web as
a key demand channel.
So today, Mukund's going
to take you through all
that's happened with their
mobile web experience
and how they've grown
in the last year.
Please welcome Mukund.
[APPLAUSE]
MUKUND LADDHA: Thank you, Peter.
Hi.
I'm Mukund.
I am Product Manager for
OYO Consumer Experience.
And I'm super excited
and delighted to share
the journey of OYO mobile
web, as well as how focus
on this channel led to
rich results for us.
So if we talk about the growth
that we saw in OYO mobile web,
we can talk about three
major interventions
that were brought about.
First was PWA.
This was followed by the
capability as well as
adoption of browser installs.
Finally, the integration of TWA,
that is Trusted Web Activities,
really led to rich
results for us.
With each of these
key interventions
we were able to see good,
sizable lift in conversion,
as well as key
capability increase.
Also, our product was made more
accessible to the end users.
Let me take you through each of
these interventions one by one.
PWA was the first major
intervention for us.
It provided users with
key UX capabilities,
like offline
support, reliability
on different networks, which
was especially important for us,
given the markets we were
present in, and also better
latency.
Overall, we saw a conversion
lift of around 2.2X,
while our user base
also rose by 4X.
We saw a latency
rise of almost 75%.
Our product was optimized
leaps and bounds.
And this was one of the
first major breakthroughs
which really made us
believe in OYO mobile web.
With an already optimized
product in our hands,
we were looking to make it more
and more accessible to the end
users.
This is where the capability
of browser installs
came into the picture.
From browser installs,
users were already
converting by around
2X as compared to PWA.
Having these metrics
[? insight, ?] we
were actually looking to
increase its adoption.
This is where we started
doing a lot of A/B experiments
around how to have nudges
across user journeys.
We started making nudges on
home pages and [INAUDIBLE] pages
in which we saw adoption
increase of around 1.5X,
whereas we did not see any
drop in PWA conversion.
Finally, this May,
we released OYO Lite,
which was built on
Trusted Web Activity.
It was a major breakthrough in
the world of OYO mobile web.
Users were starting
to get access
to OYO PWA on Play Store,
which was really cool.
The numbers since
have been incredible.
We have a similar rating on OYO
Lite as compared to native app.
This showcases the importance
of core capabilities
like low size, easy
over the air updates,
deep linking support,
full screen, and a lot
of other capabilities.
Overall, we were seeing a
conversion lift of 3X as
compared to PWA,
and our conversion
was similar to the native app.
To summarize, each of
these interventions
has brought about a good
growth in our channel.
From [? M site ?] to PWA, our
conversion has risen by around
6.6X, which is incredible.
Mobile web has been the highest
growing demand channel for OYO
over the past few months.
And we have undoubtedly
benefited from all the three
interventions and got a
great [INAUDIBLE] out of it.
Thank you.
[APPLAUSE]
PJ MCLACHLAN: Thanks
so much everyone.
Just to invite you to
come on by the sandbox.
We'll be there most
of the day tomorrow.
And our Twitter handles
are right up here.
So do please reach
out to us if you
have any questions,
any feedback,
or feel like a good
public shaming.
[MUSIC PLAYING]
