1. How to send data from my web container ?

2. How to migrate from the serverside v1 (server to server) ?

3. How to migrate my mobile app data collection ?

This guide shows you how to quickly set up server-side event forwarding for GA4 in Google Tag Manager (GTM) using Commanders Act. With this setup, your GA4 events can be routed to multiple destinations like Facebook CAPI, Google Enhanced Conversions, and others.

1. Create a GTM Source in Commanders Act.

2. Update the GA4 URL in GTM.

3. Set Up Domain Delegation for first-party data collection (strongly recommended).

Step 1: Create a GTM Source in Commanders Act

1. Log in to Commanders Act.

2. Go to the Sources section and create a new Google Tag Manager source.

3. Copy the Source Token displayed.

Step 2: Update GA4 in Google Tag Manager

1. Open your GTM workspace.

2. Find your GA4 Configuration Tag.

3. In the Tag Configuration window, under Fields to Set, add a new field with the following values:

   • Field Name: server_container_url

   • Value:

     Copy

     https://collect.commander1.com/events?tc_s={siteId}&token={sourceKey}&&ga_url_param=

   Replace:

   • {siteId}: Your Commanders Act site ID.

   • {sourceKey}: The Source Token from Commanders Act.

Note: This URL uses Commanders Act’s default domain (commander1.com) to get you up and running quickly. For better data quality, it’s strongly recommended to use your own custom domain (see Step 3).

1. Save and Publish your changes in GTM.

Step 3: Set Up Domain Delegation for First-Party Data Collection

For enhanced data accuracy and first-party tracking, we recommend setting up a custom domain through domain delegation. This ensures the data is collected and processed as first-party, improving tracking reliability and compliance with privacy regulations.

How to Set Up Domain Delegation:

1. Go to the Domain Management section of Commanders Act (find detailed instructions here) and follow the steps to configure a custom subdomain such as https://collect.yourdomain.com

2. In GTM, update server_container_urlwith your subdomain url such as:

   Copy

   https://collect.yourdomain.com/events?tc_s={siteId}&token={sourceKey}&&ga_url_param=

   Replace collect.yourdomain.com with your own subdomain.

Using a custom domain not only improves tracking precision but also helps ensure better compliance with browser and privacy policies.

Step 4: Event Forwarding to Multiple Destinations

Once GA4 events are sent to Commanders Act, they can be forwarded to various destinations, such as: Facebook CAPI, Google Enhanced Conversion, Bing Ads, TikTok, Awin, ... And many more through the Commanders Act plug&play destinations catalog.

Going Further: Bypassing Ad-Blockers with GTM Script Proxification

For users looking to optimize server-side tracking, Commanders Act provides also an option to proxify the GTM JavaScript file to bypass ad-blockers. This solution ensures that consented data can still flow to your analytics tools or partners without being unfairly blocked by ad-blockers that might indiscriminately block GTM scripts, even when used responsibly.

How It Works:

• Instead of using the default GTM URL (e.g., https://www.googletagmanager.com/gtm.js?id=XXX), the script is served from your own domain (e.g., https://track.yourdomain.com/custompath.js) with a unique path modifier to avoid detection by ad-blockers.

• This process helps ensure that only user-consented data is collected and forwarded, in strict compliance with privacy regulations such as GDPR.

A Privacy-Respectful Approach:

Our server-side infrastructure is designed with privacy, consent, and user control at its core. By proxifying the GTM script, you're simply ensuring that consented data can be processed and sent to trusted tools and partners, in line with the user’s preferences. This aligns with best practices in privacy and GDPR compliance, ensuring that ad-blockers do not unfairly interrupt responsible data flows.

If you're interested in setting this up, please contact your account manager for more information.

Sending an event from a web container is as easy as adding a tag : the OneTag.

1. Add the OneTag from the tag library

From your web container, add a tag from the tag library, searching Commanders Act OneTag

You will find 2 tags to choose from :

1. The OneTag - Builder: it will guide you without having to write code

2. The OneTag - Custom: for those who prefer to manually write complex event data using javascript

2. Setup the tag

If you choose the builder version of the tag, you can go to the next step, you just have to follow the instructions. If you choose the custom one, here is how it works: The cact('trigger') function is what allows you to record any actions your users perform, along with any properties that describe the action. Each action is known as an event.

Here’s the format of a typical trigger call:

cact('trigger', '<event_name>', {<event_data>}, [config], [callback]);

Each event has a name, like page_view, and properties. For example, a page_view event might have properties like page_name or page_type.

Here is an example

cact('trigger','page_view', {
  page_type: 'product_list',
  page_name: 'Best sellers', 
  //...
});

Standard events and custom events

You can implement two types of events:

• Recommended standard events are events that you implement yourself, but that have Commanders Act-predefined names and parameters.

• Custom events are events that you name and implement yourself. Before implementing a custom event, check that there is not a recommended event that already provides what you need. With custom events, best practice is to use recommended properties that you can find in our event references (ex: revenue, currency, ...) beside your custom properties.

User Consent in each events

If you use Commanders Act CMP, the user consent is automatically retrieved and put inside all events in the user property.

If you use another CMP, you will have to add manually a property consent_categories inside a user property, following this example :

cact('trigger','sign_up', {
  method: 'email', 
  user: {
      consent_categories: [1,3,4,6]
  }
});

consent_categories is the user's consents list and is mandatory to manage consents in each destinations (aka server-side consent) See how work server-side consent management.

Advanced options: Overriding default parameters

There are 3 default parameters that you can override if needed:

• collectionDomain: if not set, the default value correspond to your first party domain (if you setup one) or collect.commander1.com

• sourceKey: if not set, the default value is the source key of the currently running web container.

• siteId : if not set, the default value is the site id of the last web container loaded (tC.id_site)

To override a parameter, you can add a config object to your cact('trigger') function (4th parameter) like this:

cact('trigger', 'purchase', {   id:'1234',  currency: 'EUR',  //...},{
    collectionDomain: "my.firstdomain.com",
    siteId: "1234",
    sourceKey: "abcd"
});

You can also set globally these parameters for all triggered events with the cact('config') method. See the Javascript API documentation for more information.

3. Check that everything is working

After configuring your OneTag (at lease one event triggered) and deploying your web container, you can refer to the Event Inspector tab for the Source to verify that it generates the expected event data.

The Source Event Inspector serves as a live tool that aids in validating the arrival of events originating from your website, mobile application, or servers to your Commanders Act Source. This enables you to promptly examine the reception of calls by your source and troubleshoot without the need to await data processing.

4. Setup your first destination

Once you have verified the inflow of data from your fresh source, it's the perfect moment to create your first destination:

• Navigate to your Commanders Act platform, click on Destinations-> Overview, and select 'Add Destination' to list all the available destinations in the catalog.

• Look for the destination of your preference. For example Facebook Conversion API.

• Click on the card representing the destination to obtain more information about it.

• Initiate the configuration by clicking on 'Configure'

• Choose the source that you had previously setup, or select all sources.

• In the settings screen, name your destination, choose an environment and enter required information.

• Then in the filter tab, manage the user consent by selecting the appropriate consent categories for that destination (for example "Advertising" category for Facebook CAPI)

• Save and go checking that everything is going well in the Event Delivery and/or Event Inspector tab, or directly in your tool.

FAQ

How work server-side consent management

When you add a destination (aka serverside tag), you manage the user consent by selecting the appropriate consent categories for that destination (for example "Advertising" category for Facebook CAPI). As a result, since each event entering the platform contains information about the user's consent, the event will only be sent to the destination if there is a match between the categories consented by the user and the consent's category associated to the destination.

There are several ways how to get your data into Commanders Act platform.

Real-time Commanders Act tracking

Third party tools

Commanders Act also offers connectors to third party tools, visit the to explore the full list.

Imports

It is possible to import data to Commanders Act through regular automated file imports (csv), such as:

• and

• Custom storage universe

Data API

Serverside v1 to Serverside v2

Severside v1 (aka SSv1) is the serverside tag management feature of the old platform (v7). It is now deprecated. In this section, we'll see how to migrate from a SSv1 setup to the new platform (aka SSv2)

Tree steps to migrate

1. (aka Platform X)

1. New concepts

On the new platform (aka Platform X), everything is Source/Event/Destination. (your website, app or server) collect your user actions by sending . These events are sent to the platform servers and are then enriched, normalized and translated in each tool () format, so that they can be sent to your chosen destinations. You can learn more in the section.

2.How to send events (standard / custom)

• From a server, use our .

• From a mobile application, you can either use one of our SDK (, , ...) or use our if you don't want to use a SDK.

3. Format events

• Events are the new format of your data. As explain in the , common events have to be sent in the standard format (name and properties) to benefit from plug&play features.

• Standard event format can be found in our

• Go through this based on the ssv1 format :

To track mobile app on the new platform, you can either install our new SDK ( and ) or use our .

Steps to follow for migration from SDK v4 to SDK v5

Create your Mobile Source(s)

In the Sources Catalog, create your new Sources. Sources > Overview > Add Source

At the last step of the Source setup, you will obtain a Source Key, required for the initialization methods of our SDK

Replace SDK Modules

Our SDK files have changed. You must replace the old ones. Get our latest versions :

Modify initialization methods

The way you initialize our SDK is now different, your old methods will not be recognized anymore.

• You don't need container ID anymore, all is on the same site ID. Instead of a container ID you'll need a specific key to define the source.

• You don't need to put any TCServerSide instance in your Consent implementation anymore.

• You might need to use the TCUser class to forward relevant information about your users.

Replace container calls by events

With the old platform, you were used to send a container call, with all the variables. It's not compatible anymore. Instead, you have to send events with properties.

Here’s a code example of how to execute an event:

Upgrade your data layer

The new platform is using standard properties, so we recommend to upgrade your mobile application’s data layer by using our standard properties as much as possible

Create your destinations

Test & validation

A Quality Assurance Test & validation is strongly recommended before launch in production ! Here’s a few references to help you on this point:

• Testing => tips how to test
• Common errors list

FAQ

Should my data layer be identical for my website & my app ?

It’s a good practice ! We strongly recommend to have the same data layer for web & mobile application Main benefit: setup only 1 destination for both sources! Your destination’s setup will be recognized by web and mobile

How can I obtain the IDFA/AAID ?

Our SDK doesn’t collect automatically the IDFA/AAID anymore, but we offer a simple method to track this information:

Can I create custom events ?

Yes it’s possible !

Can I use additional parameters ?

Yes it’s possible ! If you need to send more data then just the required properties, simply use the "additional property" method, as follow:

Can I add Persisting variables ?

Yes it’s possible !

Do I need to change/update my Json file ?

It’s not required ! Your current json is still valid for our new SDK

Do I need to change/update my callbacks for consent statistics ?

It’s not required ! Your current setup is still valid for our new SDK

Here are an example of a serverside v1 hit : Booking Confirmation :

It should be sent to the serverside v2 in this format (adding maximum of recommanded properties) :

Standard parameters :