Quick answer: To migrate to GA4 server-side tracking safely, leave your current browser setup running and build the server-side version beside it. Send the two paths to separate GA4 properties, compare their output, and remove the direct path only after the server-side setup captures every required event and parameter. Google calls this parallel measurement or dual tagging.
Here, dual tagging means running client-side and server-side GA4 measurement in parallel. Older resources often use the same term for the migration pattern that ran Universal Analytics and GA4 together.
How GA4 server-side tracking works
A common GA4 server-side tracking setup still begins in the browser. The Google tag creates an event, then sends the request to your first-party tagging domain. A Google Tag Manager server container receives the request, processes it, and forwards the permitted data to Google Analytics 4.
The request follows this path:
Browser -> first-party tagging URL -> GTM server container -> GA4
Without server-side tagging, the browser sends the request directly to a Google Analytics collection endpoint:
Browser -> Google Analytics
The server container adds a processing layer that you control. You can inspect incoming events, remove or transform parameters, apply consent rules, and decide which destinations receive the data. The browser still controls which events exist, and consent still applies.
Inside the server container, the built-in Google Analytics client claims incoming GA4 requests and turns them into event data. A server-side Google Analytics tag then forwards those events to GA4. Google's current setup guide says one GA4 client is enough for this flow.
What dual tagging means for GA4
Dual tagging gives you a baseline and a candidate implementation:
| Measurement path | Route | Purpose |
|---|---|---|
| Client-side baseline | Browser -> current GA4 property | Preserves the reporting setup people already use |
| Server-side candidate | Browser -> server container -> new GA4 property | Tests the new collection path without changing production reports |
Both paths should represent the same measurement plan. Use the same event names, triggers, parameters, ecommerce schema, and consent rules. Only the destination and transport path should change.
Google recommends a new GA4 property for the server-side dispatch during parallel measurement. Separate properties keep test events out of production reports and make the comparison easier to read. Pausing the copied tags then leaves the original property running as a clean rollback.
Before you start
Prepare these parts before copying tags:
- A deployed GTM server container
- A first-party HTTPS tagging URL, such as
https://metrics.example.com - A new GA4 property and web data stream for the server-side test
- Publish access to the web and server GTM containers
- Access to GA4 DebugView, Realtime, and the reports used for validation
- A list of required events, parameters, key events, and ecommerce fields
Match the new property's reporting time zone, currency, internal traffic rules, unwanted referrals, cross-domain settings, custom dimensions, and data filters to the current property. Property-level differences can look like tagging defects when the tags are working correctly.
How to set up GA4 server-side tracking with dual tagging
1. Keep the current GA4 tags unchanged
Do not point the production Google tag at the server container yet. Keep the current client-side property as the baseline while you build and test the second path.
Record the current GTM container version and export it if your release process requires a separate backup. List every GA4 tag and trigger you expect to reproduce, including page views, recommended events, custom events, ecommerce events, and consent initialization.
2. Create the server-side GA4 property
Create a GA4 property and web data stream for the server-side candidate. Give both a clear name, such as Website - GA4 server-side test, so analysts do not use the test property as the production source by mistake.
Copy the relevant property settings from the client-side baseline. Do not connect production dashboards, audiences, or ad accounts until you have decided that this property will become the reporting source after cutover.
3. Configure the GA4 client and tag in server GTM
Open the server container and check Clients. Server containers include a Google Analytics client. Keep the default GA4 request paths enabled so it can claim requests such as /g/collect.
Create a server-side Google Analytics: GA4 tag. Its default configuration inherits the measurement ID and event parameters parsed by the client. Add a custom trigger that fires when Client Name equals the name of your GA4 client. This prevents unrelated client events from firing the GA4 tag.
Preview the server container before publishing it. An incoming GA4 request should be claimed by the GA4 client, converted into event data, and passed to the GA4 tag once.
4. Copy the Google tag in the web container
Create a second Google tag in the web container and use the measurement ID from the new server-side test property. Under Configuration settings, add:
server_container_url = https://metrics.example.com
Replace the example with your tagging URL. Use a first-party domain in production. If your Content Security Policy restricts requests, allow the tagging URL in the directives required by the Google tag transport methods.
Keep the original Google tag pointed at the current property. The copied tag should send its request to the server container.
5. Copy each GA4 event tag
Duplicate the existing GA4 event tags one by one. Connect each copy to the server-side Google tag while leaving its event name, trigger, and parameters unchanged.
Work in small groups. Start with page_view and a frequent interaction event, then add lead or ecommerce events after the basic path works. A staged setup makes it easier to locate the tag that introduced a mismatch.
Check automatic and manually configured page views carefully. Each property should receive one intended page view per page load or route change, not one from the Google tag and another from an event tag.
6. Verify the complete request path
Open Preview mode for both GTM containers, then load the site in a private browser window.
For the server-side copy, confirm that:
- The copied web tag fires on the expected trigger.
- The browser sends the request to your first-party tagging domain.
- The request appears in the server container's Preview summary.
- The GA4 client claims the request.
- The server-side GA4 tag fires once.
- The event appears in the new property's GA4 DebugView or Realtime report.
Repeat the test with each consent state your site supports. A server container must respect the choice passed from the web container. It cannot turn denied consent into permission.
How to compare client-side and server-side GA4 data
Run both paths over the same dates and compare more than total events. A matching headline count can hide broken parameters, duplicate purchases, or lost attribution.
| Check | What to compare |
|---|---|
| Event coverage | Every required event_name appears in both properties |
| Event frequency | Counts by event, page, device category, and consent state |
| Ecommerce | transaction_id, item arrays, quantity, currency, value, tax, and shipping |
| Event parameters | Names, values, and data types for critical custom parameters |
| Page context | page_location, page_referrer, page title, and hostname |
| Acquisition | Source, medium, campaign, and landing page |
| Identity | User and session behavior expected from your consent and identifier setup |
| Tagging quality | No duplicate page views, events, purchases, or unexpected PII |
Use the same reporting time zone, filters, date range, and attribution settings when you compare properties. If both properties export to BigQuery, event-level queries make parameter and ecommerce checks easier than aggregate reports.
Parity does not require identical top-line totals. The two collection paths can differ because of request delivery, browser behavior, consent, filters, and configuration. Parity means every required event and field works, the variance stays within an accepted range, and your team can explain the remaining differences.
Common dual-tagging mistakes
- Sending both copies to one property: GA4 reports can count both events. Use separate properties during the parallel test.
- Changing the existing tags first: You lose the stable client-side baseline needed for comparison and rollback.
- Copying only the Google tag: Event tags, parameters, trigger rules, and ecommerce payloads also need a server-side candidate path.
- Using different triggers: The comparison is invalid if the two copies do not fire under the same conditions.
- Ignoring property settings: Different filters, time zones, currencies, or referral rules can create report gaps that have nothing to do with transport.
- Checking only Realtime: Realtime confirms delivery. It does not prove that attribution, ecommerce fields, custom dimensions, and daily reporting are correct.
- Treating extra events as automatic improvement: A higher server-side count can come from duplicate tags or consent errors. Trace the difference before accepting it.
When to end parallel measurement
End the test after the server-side path has remained stable through a representative traffic cycle and the people who use GA4 have approved the comparison. Before cutover, confirm that:
- Each required event fires once under its intended conditions.
- Critical parameters and ecommerce values arrive with the correct types.
- Consent choices change tag behavior as designed.
- Acquisition and session differences are understood.
- Monitoring covers server errors, request volume, and tagging costs.
- The team has a saved GTM version that can restore the previous setup.
Then publish a version that sends production GA4 measurement through the server container and removes the temporary duplicate path. If the new property becomes the reporting source, verify its key events, audiences, product links, BigQuery export, access, dashboards, and retention settings before the switch.
Parallel measurement vs. hybrid collection
Parallel measurement duplicates the same plan for a temporary comparison. Hybrid collection deliberately keeps different events or destinations on different paths.
For example, a hybrid setup might route GA4 through the server container while a browser-only vendor tag remains on the page. Another setup might create completed-order events in the backend while the browser measures page and product interactions. Those are architecture choices, not parity tests.
Document which system owns each event. If the browser and backend both send the same conversion, define a deduplication rule before production reporting depends on it.
GA4 server-side tracking vs. server-to-server tracking
Server-side GTM and server-to-server tracking are related but different.
In the setup described above, the browser creates the GA4 event and sends it through your server container. The extra server hop gives you control over processing and routing, but the original signal is still browser-generated.
A true server-to-server event starts in your backend. GA4's Measurement Protocol can send events such as completed orders or offline actions from a server. These events need the identifiers and session context required for useful reporting. Do not send a second copy of a browser conversion without a deliberate duplicate-control plan.
GA4 server-side tracking FAQ
Does GA4 support server-side tracking?
Yes. Google Tag Manager provides a server container with a built-in Google Analytics client and GA4 tag. The web Google tag sends requests to the container through server_container_url, and the server tag forwards the processed events to GA4.
Do I need a separate GA4 property for server-side tracking?
Not for the final architecture. Google recommends a separate property while you run parallel measurement because it keeps the candidate data isolated and prevents the two paths from inflating one report.
How long should dual tagging run?
There is no fixed duration that fits every site. Run it long enough to cover normal traffic, low-frequency conversions, consent states, campaign traffic, and at least one complete business reporting cycle. Cut over after the remaining differences are understood.
Is dual tagging the same as parallel tracking?
This guide uses parallel measurement for the temporary client-side and server-side GA4 comparison. Google Ads also has a feature called parallel tracking for loading a landing page while click tracking runs in the background. They solve different problems.
Can I use the same GA4 property for both paths?
You can route client-side and server-side events into one property in a hybrid design, but do not send two copies of the same event without a deduplication plan. For migration testing, separate properties make discrepancies and duplicates easier to find.
Hardal's server-side hosting provides a managed sGTM runtime and first-party tagging URL. Follow the Hardal sGTM setup guide to connect your server container.