Upgrade your servers for live traffic

So far, you have set up a tagging server in the App Engine in a test environment. If you are interested in switching to a production environment, follow these steps.

We recommend running a minimum of 3 servers to support your production traffic. Autoscaling from a minimum of 3 to a maximum of 6 instances should be able to manage 50–200 requests per second, although ultimately this depends on how many tags your requests trigger and what those tags do.

Upgrade your server

To configure your tagging server:

  1. Open the Google Cloud Platform Cloud Shell.
  2. Set the Cloud Platform project in the Cloud Shell. Replace project ID with the GCP project ID that you noted earlier:
    gcloud config set project project ID
  3. To reconfigure the tagging server for a production environment, run the setup script below. Perform the following tasks:
    bash -c "$(curl -fsSL https://googletagmanager.com/static/serverjs/setup.sh)"
    1. Change the deployment type to production.
    2. Set up additional servers to serve production traffic. We recommend a minimum of three servers.

Map a custom domain to your service

One of the key features of server-side tagging is that it can be run in a subdomain of the websites that send data to it.

This is referred to as a first-party context between the server-side tagging server and the website.

Diagram showing the difference between a first-party and third-party domain.

You can add multiple custom domains to your server-side application. This is useful if you are using the same server container to receive requests from multiple different websites.

One of the main benefits of the server-side environment being in a first-party context with the website is that browser cookies read and written by your server container are considered first-party cookies. As many browsers today restrict access to cookies in a third-party context, this can greatly improve the quality of your data collection.

1. Map a subdomain to your app

  1. In the Google Cloud Console, navigate to App Engine > Settings > Custom Domains. Make sure you’re in the project that matches your container ID:
    GCP project selector, showing a sample Tag Manager container ID.
  2. Click Add a custom domain.
  3. If your domain is already verified, you may select it from the Select the domain you want to use section. Otherwise, select Verify a new domain from the drop-down menu. If you haven’t verified your domain, do the following:
    1. Enter your subdomain (such as metrics.example.com) and click Verify. A new Webmaster Central window will appear.
    2. To verify your ownership of your subdomain, follow the steps as prompted in Webmaster Central.
    3. After you complete the steps in Webmaster Central, close the window and return to the Add a new custom domain page in Google Cloud Console. You may need to click Refresh domains to see your newly verified domain.
  4. In the Point your domain to [project-ID] section, remove the www. prefixed subdomain and Save mappings.

After you've mapped your service to a custom domain in App Engine, update the DNS records at your domain registrar. As a convenience, App Engine generates and displays the DNS records you need to enter.

2. Update DNS records at your domain registrar

  1. To retrieve the DNS record information for your domain mappings, open the Custom Domains tab in Google Cloud Console. This page lists DNS records for all of the domains you have mapped to your app.
  2. Log in to your account at your domain registrar and open the DNS configuration page.
  3. Locate the host records section of your domain’s configuration page and add each of the DNS records that you retrieved when you mapped your domain to your app. Enter the following information in the record fields:
    • Record type: Enter the record type shown in the DNS record that Google created for you (A and AAAA).
    • Record name: For A and AAAA records, enter the subdomain you registered. For example, enter “metrics” to map metrics.example.com.
    • Data: Enter the record data (rrdata) that is shown in the DNS record Google created for you. For A or AAAA records, the record data is an IP address. If there is a CNAME record shown in addition to the A and AAAA records, do not map the CNAME record.
  4. Save your changes in the DNS configuration page of your domain’s account. In most cases, it takes only a few minutes for these changes to take effect, but in some cases it can take several hours. You can use dig to confirm the DNS records have been successfully updated.
  5. To test your subdomain, navigate to your server-side Tag Manager container under Admin > Container Settings. and paste that URL into the Server container URL. Click Save, navigate back to your workspace, then click Preview. You should see the Debug panel pop up.

Update your client-side tags to send data to the new domain

Once you have mapped a custom domain to your upgraded environment, remember to update your browser tags to communicate with this new subdomain rather than with the default App Engine domain.

In Tag Manager, the option can be found in the Google Analytics 4: Configuration tag, under the setting labeled Send to server container.

Refer to chapter 5 in this learning pathway for more information on how to update your browser tags.

Deploy additional tags

Once you have your Google Analytics 4 browser tags configured to send data to your server-side tagging environment, you can use this data flow to fire other tags, too.

This is a unique feature of server-side tagging. You can build a more efficient and user-friendly tagging setup by sending your requests to your server. From there, requests are distributed to multiple vendors, and you can remove vendor tags from your web container.

For example, with the Google Analytics 4 client now parsing the incoming requests into the event data format, you can create tags for Google Ads and Floodlight which trigger upon these events.

Diagram showing that the GA4 client can also trigger other Google tags, such as Ads and Floodlight in a server container.

In the example above, a single conversion event from the web browser is distributed to three destinations: Google Analytics 4, Google Ads, and Floodlight. In the web container, it is no longer necessary to add Google Ads and Floodlight as separate marketing tags, because the logic is now handled server-side.

In addition to the built-in templates available in the server container, there are many other templates for tags and variables in the Community Template Gallery, created by the Tag Manager user community. To minimize possible security issues, these templates run in sandboxed JavaScript. As an extra layer of security, you can set up policies. A template will only run if it complies with all policies and permissions.

If you want to set up additional tags before you start the next chapter, these resources might be interesting for you:


This chapter showed you two integral parts of server-side tagging:

  • How to upgrade and configure your servers
  • How to tag from within a first-party context.

Now that you have a production-grade infrastructure, we will take a closer look at monitoring your servers.