After my series of posts on measuring user activities, tracking conversions, and re-marketing data from the server side, I’ve received numerous questions regarding DNS-based issues and alternative solutions like Cloudflare. Taking this opportunity, I’ll be adding a few updates to the relevant article series.
In my previous post titled Google Tag Manager - Server-side Tagging, I discussed the setup of the relevant server-side container and the basic tag installation, noting that custom domain usage was a minor point. However, I’ve received many requests to include detailed notes in the article regarding the numerous issues encountered during DNS management.
DNS management is itself a topic that deserves separate attention. The root causes of the issues may be one or more factors. In such cases, it’s important to first contact peers with expertise in server management or the domain hosting provider. The steps I’ll discuss and use as an example below will closely parallel Google’s documentation on domain management1.
Google Tag Manager Server-side and Custom Domain Usage
In my previous post titled Google Tag Manager - Server-side Tagging, I mentioned that upon completion of the GTM server-side container setup, a domain ending in *.appspot.com is automatically created. The domain and its subdomains under it are considered first-party, while any domains outside of this domain and its subdomains are considered third-party.
For example, the top-level domain for www.ceaksan.com and ss.ceaksan.com will be ceaksan.com. www and ss are subdomains associated with this domain and are evaluated as first-party in tracking processes, and thus will accept requests/cookies related to them. However, the domain used for the website or application is not mandatory during GTM server-side setup. Depending on different purposes, domains other than first-party domains can also be included in the tracking process. The following steps apply similarly for each added domain.
Domain Selection and Association with Container
It is important that the selected domain has not been used previously and does not have a DNS record. Therefore, instead of using a previously problematic subdomain, a new subdomain should be selected. Generally, the most preferred approach is ss.[domain]. We will proceed accordingly by selecting the ss subdomain.
If you’d like to pre-check your chosen subdomain, you can use Dig to perform a preliminary check. Enter the domain name you intend to use in the Name field and click on the A and AAAA options to view the records (record) associated with that domain.
Server-Side Container URL
You can proceed by entering the domain name you wish to use in the [kbi]Server Container URL[/kbi] field in the Tag Manager container settings.
If you’re defining multiple domain names, it’s important that all of them are added to this field. This is because, in the case of multiple domain usage, a separate Preview step must be performed for each domain name defined during the validation process2.
If you don’t have a need for multiple domain names, simply adding the domain is sufficient. When only a single domain is defined, the preview process is automatically executed through that domain when you click the Preview button.
We’ve completed the domain configuration step on the GTM side. Now we can proceed to the Google Cloud and, if needed, the Webmaster Central (also known as Google Search Central) steps3.
[bdi]Google Cloud > [Project created for GTM] > Settings > Custom Domain[bdi] (if navigating through the left-side menu, you can also reach these steps via App Engine). Following these steps is sufficient.
You can proceed by selecting the Add a new custom domain option. After selecting the domain listed, you can proceed to the domain mapping step. By default, the www and non-www subdomains associated with the domain will be listed. In this case, you can remove the relevant options and simply add the domain(s) you’ve designated for server-side use. For example, if you’re setting up for continuous operation, when you register ss.dnomia.com, the required DNS records for that domain will be sent to you4.
At this stage, you should consider which domain registrar you’re using. For example, if the domain you acquired through Google Domains is associated with a different server via its NS records, you’ll need to manage the A and AAAA records (four records each) on that server. This process is similar in Cloudflare usage5. Since I’m hosting my domain on Google Domains and have pointed my NS records to Hawkhost, I will manage the A (IPv4) and AAAA (IPv6) records through Hawkhost.
After entering the relevant records, you can conclude this step and wait for Google to complete the SSL certificate generation. Of course, it’s important to remember that the DNS record process may take anywhere from a few minutes to several hours. Additionally, if the SSL certificate generation process takes an unusually long time, there may be an underlying issue with the certificates. In such cases, you must verify whether a certificate covering the specified domain exists. For instance, a certificate created by the hosting provider that covers all subdomains could negatively impact Google’s certificate issuance process. In such situations, the relevant certificate can be transferred directly to Google Cloud, or a different subdomain can be included in the process.
IMPORTANT RULES:
- Maintain the original formatting (markdown, HTML tags, links, etc.)
- Keep technical terms and proper nouns as appropriate
- Preserve code blocks and technical syntax exactly
- Maintain the same tone and style
- Only output the translated text, no explanations or comments
In the case of transferring an external certificate, the hosting provider’s SSL interface must be used to transfer the Public Key and Private Key contents following the steps under App Engine Settings > SSL Certificates. After this procedure, the relevant domain names can be associated with the installed certificate. The following example shows the use of two different certificates.
After completing the above steps, domain names can be verified via the GTM preview mode.
It is expected that preview pages will load without issues, provided there are no problems related to DNS or SSL certificates. If an issue occurs, the above steps should be carefully reviewed again from the beginning.
After the tags have been added to the server-side container, if changes are not pushed to production, the client-side will return a 404 error code for any requests it receives. Therefore, it is essential to remember that server-side tag modifications must be re-verified after they have been pushed to production.