The question we’re going to be looking at today is inspired by our course, Server-side Tagging In Google Tag Manager.
Is it possible to have a single server container serve multiple different main domains that send requests to it? Or do I need a separate cloud project and container per source domain?
When you set up server-side tagging, you usually have one Server container configured to respond to requests from one website.
However, your organization might be in charge of many websites, which might be unrelated to each other.
This introduces the question tackled by this article (and video): can I use a single Server container to serve multiple websites? Similarly, can I use a single cloud project to support traffic from multiple websites, too?
There are many ways to organize your stack, and you can cater to pretty much any combination of Server containers, cloud projects, and websites.
In this article, we’ll take a look at some of the more common ways to set things up.
Video walkthrough
If you prefer this walkthrough in video format, you can check out the video below.
Don’t forget to subscribe to the Simmer YouTube channel for more content like this.
Different setups
As there can be any number of server-side tagging containers, (cloud) services, and websites all interconnected, the range of setups you could explore is just as diverse.
The prototypical setup, however, is where you have a single Server container, and you want it to process data from more than one website, preferably using a single cloud service, too. So it looks something like this:
Another option is that you have a single Server container, and you want it to process data from more than one website, but you want more than one cloud service to handle the traffic, perhaps to direct traffic through servers that are geographically closer to the user (to keep network egress costs and latency down).
And there’s no obligation to stay in just one cloud provider, either. You could have a couple of websites running through a multi-region setup on Google Cloud Run, and then one website sending data through Amazon AWS, all configured to use the same Server container.
Setting up your infrastructure around these options (or a mixture thereof) is not difficult, because the different parts are isolated from each other.
The Server container in Google Tag Manager can be configured to work with any number of cloud services (or any Docker-supported stack).
Using Load Balancers, you can distribute data from a single website or multiple websites within the server stack based on things like the geolocation of the visitor or whether the traffic is considered “internal” or not.
And you can even map multiple domains to a single cloud service, allowing you to leverage the existing server capabilities for more than one domain without the hassles of load balancing.
While we won’t go in-depth into these scenarios, I’ve added links for further reading where relevant.
Map multiple custom domains to a single (Google) cloud project
If you’re working in the Google Cloud Platform, either with Google App Engine or some other service that allows you to map custom domains (e.g. Google Cloud Run), you have a very simple option when working with multiple websites.
You can map as many subdomains as you like to the cloud project.
For example, if you want to collect data from brand.website, store.app, and blog.content, you can reserve subdomains for each by simply mapping them using the regular process for adding custom domains to the project.
This is a very simple way to approach the problem of catering to multiple websites, with the purpose of keeping the requests in first-party context.
The main issue with this approach is that your service needs to accommodate for possible scaling imbalances between the websites.
For example, if you have a very popular website and a more niche one sending requests to the same cloud service, traffic spikes in one could compromise the traffic flow for both, if you haven’t accounted for them in the scaling configuration of the service.
Map multiple cloud services to a single Server container
If you don’t want to have a single cloud service shoulder all the traffic, you can move the inflection point elsewhere.
When you are in the Google Tag Manager user interface for the Server container, you can click the container ID in the top navigation bar to open a dialog that shows the container’s Container Configuration string.
This Container Configuration string is what you’ll need if you want to link a cloud service to the Server container.
Remember, you can have any number of server stacks pointing at the same Server container. They don’t have to run on a cloud platform – they can be on-premise servers, too, as long as they support Docker.
The Container Configuration string is a required parameter in the Docker setup.
Similarly, if you’re using the shell script for App Engine (or the shell script for Cloud Run) to deploy the cloud service, the Container Configuration is something you need to input at an early stage in the deployment process.
I want to reiterate one important point: Docker is platform-agnostic.
You don’t need to stay within the Google Cloud Platform. You can use AWS (see this guide), Azure (see this guide), or whatever server stack you want, as long as it has Docker support and it can make HTTP connections across the internet.
Summary
If you take a look at the series of diagrams in the beginning of this article, hopefully it’s now clear how you should proceed.
To summarize, here are your (general) options:
- You can use a single App Engine (or Cloud Run) service for mapping multiple different subdomains to your single Server container. Follow the general guide for mapping custom domains in the Google Cloud Platform.
- You can configure multiple different server stacks to work with a single Server container. You will need to utilize the Container Configuration string (available in the Server container user interface within Google Tag Manager) when deploying the Docker image.
Once you have these internalized, you can then create hybrids that comprise multi-domain App Engine (or Cloud Run) services, multi-region setups with load balancers, multi-cloud configurations, multi-container deployments, and so forth.
The important thing is that you have a lot of flexibility. You are not handicapped with just one Google Tag Manager container per website, one cloud service per Server container, or one subdomain per cloud service. You can freely choose where the complexity should be, and most commonly this is something you would sort out with your organization’s cloud engineers and DevOps teams.
I hope this article has helped you understand the freedom you have when configuring your cloud services, your Google Tag Manager containers, and your DNS records in building these complex mappings across your deployments.
Let me know in the comments if you have any questions!
