[MUSIC PLAYING]
KRISTA SEIDEN: Hey, everyone.
I'm Krista Seiden, and I'm here today
with Breen Baker who's a product manager on Google Analytics.
Thanks so much for being here, Breen.
BREEN BAKER: Thanks for having me, Krista.
KRISTA SEIDEN: Of course.
So today, Breen is going to walk us through best practices
for setting up your Google Analytics 4 property.
Now, when you set up a Google Analytics 4 property,
you actually want to think of this in a different way
than you might have set up your Universal Analytics property.
And so because of that, it's very important
to think about a number of things.
And Breen is going to walk us through what those are.
So with that, I'm going to hand it over to Breen.
BREEN BAKER: Thanks, Krista.
So we wanted to start by making clear
that best practices really do vary based on your desired
control over your organization, if you
have legal and/or regulatory requirements,
or any other governance need.
But we can go over our common recommendations
and what we see.
First, the key point is apps very do much matter.
The limitation on having a link between a Firebase app
and a single GA4 property dictates a lot of decisions
if you do have an app.
So a common recommendation is that we
have one account per company.
This is because the account is really the overarching access
control structure for all users that have access to any
of the properties underneath.
So we recommend one so that it has reduced overhead.
Second, we recommend one property per brand or business
unit.
So this would be truly a separate team, different brand,
or a business line within a broader company.
And we do mean truly separate because subproperties would
be-- properties in general, but also subproperties
are created for specific teams to get access
to specific sets of data.
So if there is overlap, then we would actually
recommend combining that.
Roll-ups should be used to further unify the data.
So if you do have the need for both a subset of people
to see a subset of data and to have a combined
view of the data, we would recommend
one property per brand and then a roll-up above that.
And then lastly, we don't recommend
creating a subproperty necessarily
for every organizational need.
We recommend subproperties for governance
needs where a team really is not allowed
to see the data from the broader property
or of another subproperty's subset.
If you don't have those needs, we actually
recommend that you use report collections, which
are a way to organize data within a property for a team
without the need to actually silo that team from everything
else.
So here, we find one of our common examples of a company
with multiple apps in different regions
and the desire to roll those up.
So in this case, we'll create a roll-up property
to unify that data above all three of those apps.
Now, the beautiful part of this is that a roll-up property
is just like any other property and processes and unifies
user identifiers if there is dual usage
across multiple apps.
So if you do have a multi-app company
and you wish to bring the data together
into a roll-up to see how users interact across those apps,
you're going to get a duplicated user
view in that roll-up, which is a really nice feature.
Important considerations-- we'll start with apps.
Apps are very important.
And again, that's because of the one to one
limitation where a single Firebase app can only be linked
to a single GA4 property.
Because of that, if you have a brand with multiple apps,
you're going to need multiple ordinary properties.
And if you want to see that data above all of those apps,
you'll need a roll-up.
And of course, if these apps are global
and you have regional teams, you're
going to want subproperties below the ordinary properties.
Governance requirements.
These are also very key.
Obviously, you have to follow through
with legal and regulatory requirements.
And if you have any need to share data
with a team that is not allowed to see the other data,
then without a feature like subproperties,
you would not be able to achieve that goal.
So governance requirements are the second major consideration
you'll want to think about when you're creating a property.
Organizational structure.
Obviously, again, if you have different teams focused
on different business lines, business units,
and they are competing, then you're
going to want to separate that.
That's a governance need.
However, if you have teams that are not competing
and just need to be focused, you're
going to want to use report collections.
And then lastly, certainly not least, additional costs.
Subproperties and roll-ups both come
with the same 0.5 per event additional cost
for every event processed in that sub or roll-up property.
So with that additional cost, you're not
going to want to create a sub and a roll-up property
for every different reporting need you have.
For that, you'd want report collections.
You're going to want to use subs and roll-up properties when
you're breaking out data for teams that need to be isolated
or rolling up data into a parent company.
Common patterns we tend to see are regional divisions.
So a brand broken up by regions is a very common pattern
we see where the brand has a single collecting
ordinary property and many subproperties based
on the regions and/or countries they support.
Another common pattern is a roll-up
that covers multiple brands.
This is especially common with our app clients
where they have multiple ordinary properties
to service their multiple apps.
Third, we see the agency or subteam model.
So this is where you have a team that's
focused on a subset of data and really should not
be looking at the broader set of data
either for regulatory or competitive reasons.
You will definitely want to use a subproperty for a use case
like that where you can isolate a subset of data collected
by the broader ordinary property and not
give access to the rest.
And then last, we do see specifically,
like for teams that have a very fine focus,
will want to think through governance or organization
and choose whichever it is.
If we have governance needs, maybe it's
a team that's looking across multiple brands,
and it's just not appropriate to have any other team view
that kind of access, then we might
need to use subproperties and possibly
roll-ups in conjunction to create an isolated
set of data that combines data across brands for them.
If I don't have those governance needs,
though, then it works very easily just
to create a set of report collections
and point that team at that set of reports.
KRISTA SEIDEN: Thanks so much, Breen,
for walking us through those best practices for setting up
your account structure in Google Analytics 4.
A lot of really important things to think through
as you go ahead and set this up, and a lot of great tips to help
make your structures successful.
So with that, I hope you can implement
some of these really good best practices
and successfully set up your Google Analytics 4 properties.