Skip to content

Guide 204 · Setup · GA4 + Tag Manager

Set up GA4 on a staging site: a separate property, so test visits never reach the live reports

Written November 13, 2026 · 6-minute read

Testers clicking through a staging build are not your live audience, so their visits do not belong in the live property. Create a second property for staging, with its own web stream and its own Measurement ID, and point the staging build at that ID only.

Expected signal

After step 7, a visit to the staging site shows in the staging property's Realtime report, and the production property's Realtime report stays empty of staging pages.

Download the reference: the staging setup reference (JSON) (1008 bytes, MD5 eb40bfefd629861e3c58c5ea23b632bd). The two environments side by side: 2 properties, 2 web streams and 2 Measurement IDs, and no ID appears in both environments.

What you need

  • The Editor role on the Analytics account. You need the Editor role to add a property. If you created the account, you have the Editor role already.
  • Room for one more property. An account can hold up to 2,000 properties, so a staging property costs nothing against the ceiling in any normal setup.
  • The staging site's URL. The web stream is created with the staging address, not the live one.
  • A way to give each build its own Measurement ID. The staging build carries the staging ID and the live build carries the production ID. How the build picks the ID is a site setting; the rule is that the two IDs never swap places.
  • The production property's time zone and currency. The staging property copies both, so a test day lines up with a live day when you compare the two.

The trace

  1. Decide the split before you create anything. A property holds data for one user base, and data that should not be reported on together belongs in separate properties. Testers on a staging build are a different user base from live visitors, and Google's own account-structure examples keep development, staging and production in separate environments. Staging gets its own property.
  2. Create the staging property. In Admin, click Create, then select Property. Enter a name that says staging, such as the site name with staging after it. Select the same reporting time zone and currency as the production property.
  3. Finish the property form. Click Next, select the industry category and business size, click Next again, select how you intend to use Analytics, then click Create.
  4. Add the staging web stream. In Admin, under Data collection and modification, click Data Streams, then Add stream, then Web. Enter the staging site's URL and a stream name that says staging.
  5. Copy the staging Measurement ID. Open the new stream and copy its Measurement ID. It starts with G-. This ID belongs to staging only.
  6. Install the staging ID on the staging build only. Put the staging Measurement ID in the staging build's tag, and leave the production ID out of that build. Then check the reverse on the live build: production ID present, staging ID absent.
  7. Prove the split in Realtime. Visit the staging site, then open the staging property and read the Realtime report: the visit is there. Switch to the production property: the staging visit is not there. Both halves of that check matter.
  8. Repeat the pattern at go-live, not a swap. The live site keeps its own production property and its own web stream for the live URL, created the same way. Going live is not moving the staging ID onto the live site. The staging property stays in place for the next round of changes.

Dead ends

DEAD END — ONE MEASUREMENT ID ON BOTH BUILDS. A single ID sends staging visits and live visits into one property, where the reports hold them together. Test orders, test sign-ups and your own test visits sit inside the live numbers, and no report setting pulls them back out. Two properties is what keeps the two audiences apart.

DEAD END — A STAGING STREAM INSIDE THE PRODUCTION PROPERTY. Google's structure guidance is one web data stream per property: the best practice is a maximum of 3 data streams per property, one web stream and one app stream each for iOS and Android. A second web stream for staging breaks that shape, and every production report then needs the staging traffic filtered out by hand, forever.

DEAD END — FIXING THE TIME ZONE LATER. Changing a property's time zone only affects data going forward, and the shift can leave a flat spot or a spike where the change lands. Google also warns against changing the time zone more than once per day. Set the staging property's time zone to match production at step 2, while the property is empty, instead of repairing it after test data has arrived.

End state

Two properties sit in the account: production, holding live visitors only, and staging, holding the test build only. Each has one web stream and one Measurement ID, and neither ID appears in the other environment. Staging tests run as often as the build changes, and the live reports never see them.

Sources

  • Analytics Help — [GA4] Google Analytics account structure — one property for each logical user base, separate environments for development, staging and production in the worked examples, and the best practice of a maximum of 3 data streams per property with 1 web data stream
  • Analytics Help — Set up Analytics for a website and/or app — the Editor role for adding properties, the 2,000-property account ceiling, the property creation steps with reporting time zone and currency, the Add stream steps for a web stream, and the warning that a time zone change affects data going forward only