You have just inherited a GA4 property — seven checks for week one

You have inherited the GA4 property of someone who left. There is no handover document, and nobody remembers why the settings are the way they are. The reports open; whether the numbers in them can be trusted is another matter.

Week one is not for fixing settings. It is for finding out what is arriving and what is not. GA4 raises no errors when it is configured wrongly, so until somebody checks, everyone keeps quietly using the wrong numbers. All seven checks below are read-only, inside GA4, and one or two a day finishes them inside the week.

1. What you actually have access to

Why. The other six checks need at least read access to the property, and fixing anything needs edit access. Not checking on day one means getting stuck on day three.

How. Admin → Property access management shows which role your account holds. While you are there, count the properties in the account. A company having created GA4 twice, with nobody sure which one is real, is not unusual — the live one is the property whose session count resembles your actual traffic.

2. What is being collected right now

Why. When you inherit someone else's setup, what you need first is an inventory. The event list alone tells you whether your predecessor designed something or whether it simply accumulated.

How. Reports → Engagement → Events, period set to 28 days, read the whole list. Consistent lowercase snake_case and 20 to 40 events means somebody designed this. Two hundred rows, most of them a handful of occurrences, means it accumulated. Do not delete anything yet — this week you only read.

3. Whether conversions are even defined

Why. With no key events defined, GA4 is a visitor counter. Ad optimisation and the question "did that campaign do anything" both start here.

How. Admin → Events shows which events are marked as key events. What matters is not the count but whether the final conversion is in there. If the purchase, the enquiry or the signup — the thing the business earns from — is missing while scrolls and clicks are marked as conversions, that property's "conversions" number means nothing.

4. Whether those conversions have numbers behind them

Why. Registering and collecting are separate. Flip the toggle on a name in the admin screen without implementing the tag and you get a conversion that exists only as a name. A typo in the name looks identical.

How. Take the names from check 3 and compare them one by one against the event counts in Reports → Engagement → Events. Present in the list with a count of zero settles it. There is also the not-quite-zero case: we treat fewer than one conversion per 10,000 sessions as effectively not collecting, and flag it.

5. Whether one action is being counted twice

Why. Duplicate collection contaminates every downstream analysis until someone finds it. Conversion rates read half, pages per session read double.

How. Two things. First, look for two names meaning the same action (purchase and order_complete). We treat such a pair as a duplicate when their counts are within 30% of each other, because that pattern means one action going out through two paths. Second, divide page_view by sessions. More than 6 per session and it is worth suspecting the tag is installed twice.

6. Whether personal data is riding in your URLs

Why. This is the one item on the list that may need action today. Google's policy is that no data should be passed to Google that it could recognise as personally identifiable information, and it names email addresses and personal mobile numbers as examples. On an inherited property, you do not even know how long it has been happening.

How. One minute. Open the 'Page path and query string' dimension and search for @, then %40, then your local mobile prefix. An encoded email writes its @ as %40, which is why both searches are needed. Anything that comes back stops being a data quality matter and becomes a policy one.

7. Write down the current state before you change it

Why. Most GA4 changes are not retroactive. Custom dimensions, renamed events, data filters — they apply to data collected after you make the change. Which means the only thing that will explain a step in a chart months from now is a record of what you changed and when.

How. One document. Today's date, what you saw in the six checks above, and one line every time you change something afterwards. The fact that your predecessor kept no such document is exactly why you are reading this article — which is what makes this the first item on the list rather than the seventh.

After week one

Get this far and you can answer "can we trust these numbers" with evidence for the first time. The answer is usually "some of them, not all of them", and knowing where that line falls is the real end of the handover.

To go through more of it at once, start with our getting started guide, which sets out what is needed and what gets checked. A Google account with viewer access to the GA4 property is enough, and the 30 checks run in roughly the order above.

In one line

In week one, read; do not fix. Access → event list → conversion definitions → conversion counts → duplicates → personal data, in that order, and within a week you will know which parts of an inherited property can be believed. Then, whatever you change, write down the date.