The server-side monitoring interface lets you visualize “incoming hits” to Commanders Act servers (calls issued from your servers to Commanders Act’s) and “outgoing hits” (calls issued by Commanders Act’s servers to your partner solutions’).
Please note the following elements before using the server-side hit monitoring interface :
If you have already subscribed to our server-side tracking service and wish to make use of the monitoring interface, you need to regenerate and deploy the server-side containers you wish to monitor hits for. Information collection will start as soon as the containers are deployed.
Data is stored one day only (24 hours) and updated in real time.
Please do the following to access the reports:
1) – Click the TagCommander icon
2) – Click “Reports”
3) – Select “Server-side Monitoring”
4) – Select the container whose tags you wish to monitor hits for (in case you have more than one container).
5) – Select the type of hits you wish to monitor from the dropdown menu:
*Incoming hits: input hits or hits sent from the client’s server to Commanders Act’s.
*Outgoing hits: output hits or hits sent from Commanders Act’s servers to the client’s.
Default settings will display outgoing hits for all your partners (“all tags”), but you can display a specific partner’s tags by selecting their name from the list.
6) – Click this tab to see hits hourly or every 15 minutes.
7) – The table under the graph contains four default columns for incoming hits and three for outgoing hits. They correspond to server-side hits’ default parameters:
ID: Id of the server-side hit (it is generated automatically by Commanders Act’s servers).
Timestamp: Time and date of the server-side hit (it is generated automatically by Commanders Act’s servers).
User agent: server’s user agent (it is generated automatically by TagCommander’s servers).
Method: It is the method used to send hits to Commanders Act’s servers, meaning “POST”, “GET”, and/or “GET and POST” methods, (the latter is displayed for incoming hits only).
8) – The remaining columns correspond to custom parameters sent in the incoming or outgoing server-side hits. It is data sent by your servers to Commanders Act or by the latter to your partners’ servers.
Example – An incoming hit has the following structure: http://serverside$siteID$.commandersact.com/$containerID$/?order_id=value&order_amount=value
The default columns (ID, Timestamp, User Agent, IP) will be displayed, as well as two additional columns: one labeled “order_id” (corresponding to the order information included in the hit) and another one labeled “order_amount” (order amounts sent through the hits).
9) – Click this icon to display a dropdown menu that will allow you hide or display columns from the table.
10) – You can search for information contained in the hits with this search engine.
11) – Click this icon to export data contained in the table as a .CSV file. You will receive the report by email.
Manage consents in Serverside context
If you setup a serverside tag from your web container, one way to manage consents is to fire or not your serverside tag depending of your CMP signal. Commanders Act offers with TrustCommander an integrated way to manage the firing of your tags depending of consent categories by a simple mapping beetween your tags and your categories.
Nevertheless, for a more precise management, even in hybrid setup we recommand to manage consent in serverside constraints.
We recommand to manage your serverside's tags through constraints, using a variable containing the list of optin categories.
Create an external variable consent_categories and feed it with the user's consent from your CMP. We recommand that consent_categories is feeded by a list of categorie's ids.
(You can also create one variable per category of course if needed)
2. Create a constraint in your serverside container that rely on consent_categories
3. Attach the constraint to your tags
With TrustCommander, you can get your consent categories easily inside your client container using our Javascript APIcact('consent.get') and put the result inside a variable that will be send through your serverside tag.
See documentation here : https://community.commandersact.com/trustcommander/onsite-api/consent.get
Server-side external variables consist of all the information sent by your IT staff to Commanders Act through server-side hits (input hits).
Reminder of server-side incoming hits’ structure:
http://serverside$siteID$.commandersact.com/$containerID$/?variable1=value1&variable2=value2…
$siteID$ and $containerID$: Commanders Act site and container identifier
variable1, variable2: server-side data layer’s variables (ex: ProductID, UserID, Order Amount…)
You can use these external variables to populate server-side tags or to create firing rules to execute them.
Server-side external variables have to be declared in the “Options” tab from the “Commanders Act” interface at the beginning of the project (or later on if the data layer changes). To add a new variable, click the “ADD VARIABLE” (1) button in the “Server-Side” section from the “External Variables” menu.
The variable creation window contains different fields:
(1) “Name”: variable’s name (mandatory field).
(2) “Parameter label”: parameter name within the incoming server-side hit (ex: order_id in this hit http://serverside123.tagcommander.com/1/?order_id=1234).
(3) “Data storage”: do not check this box in a classic server-side implementation. This option is used in hybrid server-side configurations. (Please refer to the corresponding article).
(4) “Category”: variable’s category. It allows you to classify variables according to their use (ex: variables pertaining to users, product pages, confirmation pages, etc.). Variables’ categories are added by clicking the “Manage categories” button next to the “ADD VARIABLE” button.
(5) “Description”: Variable description; it needs to be provided to simplify understanding of the variable’s name. (ex: “Page template” could be the description associated to the “env_template” variable).
(6) “Detailed description”: Detailed description of the variable; it needs to be provided to simplify understanding of the variable’s name (ex: “possible values: homepage/category/product/funnel_confirmation could be the detailed description associated to the “env_template” variable).
When the variable is added, it appears in the variable’s list.
When a flag is displayed next to it, it means that it is currently being used in a tag or a rule. Click the flag to learn more (1).
There are two types of internal variables:
Predefined internal variables, which are variables that are calculated automatically by Commanders Act servers
Custom variables, which allow you to reformat server-side variables’ values with a correspondence table (equivalent to internal variables mapped within Web containers)
1)-Predefined variables
To add a new predefined server-side internal variable, click “Server-Side” > “Internal variables” > “Add predefined variables” (1).
Select “server-side” (2) from the dropdown menu in the popin window and choose the variable(s), among those listed, you wish to add to your account. (Please note: the tick mark atop the column allows you to check/uncheck al variables) (3):
There are six default internal variables in your server-side container:
TC_UNIQ_ID: Commanders Act user ID
IP: Visitor IP
TC_REFERER: User referrer
RANDOM: Random number between one and one billion
TC_TIMESTAMP: Time and date of the server-side hit
USERAGENT: Server’s User Agent (IP, browser, etc. combination)
You can use these internal variables to populate server-side tags or to create firing rules to execute them.
2)-Custom Variables – Correspondence Table
To add a new mapped internal variable, click “Server-Side” > “Internal variables” > “Add variable” (1).
Enter your new variable’s name (2)
Select the server-side variable you will use as reference to create your correspondence/matching table (3)
In the “INPUT” column of the correspondence table, enter your reference server-side variable’s values (4)
In the “OUTPUT” column, enter the values you wish to populate your new variable with (5)
You can also add default values in case none of those present in the “INPUT” column are found (6)
Click “SAVE” (7):
To add a new container, go to the “Dashboard” interface (1) and click “ADD CONTAINER” (2):
In the configuration window, select “Serverside” (1) and click the “Add” button (2):
Your server-side container is ready to be configured.
The “SELECT” step (1) is the first phase of the tag configuration process: it allows you to select tags to add to your container from a tag library. To add one or more tags, click “ADD SERVER-SIDE TAG(S)” (2):
A window containing the list of tag templates ordered by publisher name will appear. There are different filters to look for the tag(s) you need (sorted by alphabetical order or by solution name), as well as a search engine. Select the tag(s) you need (1) and click the “ADD SERVER-SIDE TAGS” button (2).
NB: if you do not find the tag you wish to add among those listed, you have two choices:
Sending an email to Commanders Act support department or to your Consultant to request a partner solution be listed in our library (this takes about three weeks to do).
Adding a “Free input (custom)” tag where you can copy and paste the code your partner solution provides you with:
Tags you just added now have to be populated with information required by your partner solutions.
The “EDIT” (1) step is where you “map” tags with variables needed by them and which are present in the Data Layer:
You can see in the left-hand side of the interface (1) the list of tags you just added. A “warning” icon displayed in front of tags’ names indicates that they have not yet been configured and validated.
You can begin by naming your tag (2) and defining a delay (3) defined in seconds. This allows calling it asynchronously on Commanders Act’s servers. We recommend a delay of 1 second or higher.
When this is done, you can start configuring your tag.
There are two areas available to do this:
A “URL (GET)” section (mandatory): it is the server-side URL’s visible part when calling a partner solution.
“HEADER (POST)” (optional): it contains information sent in the server-side’s query header (2).
You can send POST information in two formats: key=value combinations within an associative array (“Standard” tab (3)) or JSON (4).
Configuring the “URL (GET)” part:
URL (GET) corresponds to the visible part of the server-side URL.
Important:
Do not forget to systematically add a URL in the “GET” part even if you wish to send parameters in “POST”.
The expected format of the “GET” block is a URL. You should never add JavaScript code in this block (JavaScript tags are only compatible with Web containers).
Parameters that are sent to partner solutions in “GET” format must be included in the query string (after the question mark in the URL “?”) in a key=#value# format as shown in the following example: http://logc8.xiti.com/hit.xiti?s=#s#&s2=#s2#&idtransact=#transactid#
The #value# nomenclature represents your URL’s dynamic variables (i.e. parameters expected by the solutions that need to be populated). They are visible both in the URL’s code, in bold and blue characters (1), and underneath the tag’s code (2). You have to map these dynamic variables with those present in your server-side Data Layer, available from the dropdown menus, or with static values (example: an account ID) (3):
Configuring the “URL (POST)” part:
HEADER (POST) corresponds to the server-side Header’s query.
The Header’s code must not exceed 65,000 characters.
Two different formats can be used in the POST section:
An associative array with key=#value# combinations available from the “Standard” tab (1)
A JSON structure (“JSON” tab) (2). Important :
Your JSON code must begin and end with curly brackets {}.
Use commas as separators but omit that which should be placed right before de closing bracket (}).
“String” values (strings) you will send your partners have to be written as follow: “key”:“#value#“. (Most common).
It is also possible to send your partners “integers” or “Booleans. In this case, they should be sent in this format: “key”:#value#. It will only work if “input hits’” values’ types are “integer” or “Boolean”.
Warning signs to the left of the code block will remind you that the standard “string” format is not “key”=#value# as in Web containers, but rather “key”=“#value#“.
Please note: it is possible that certain solutions ask you to send information in a key={JSON} format. Go to the “STANDARD” section to configure this format. Rules applicable to JSON are exactly the same as those mentioned above (even if syntax color codes do not work the same).
Here again, the #value# nomenclature represents your URL’s dynamic variables. They are visible both in the URL’s code, in bold and blue characters (1), and underneath de tag’s code (2).
You have to map these dynamic variables with those present in your server-side Data Layer, available from the dropdown menus, or with static values (example: an account ID) (3):
The “RULES” section is where you create firing rules for your server-side tags.
The two tabs in the left-hand side menu let you manage tag activation:
The “Summary” tab displays a summary of all the rules created for each tag (1)
The “Constraints” tab allows you to create rules for your tags (2)
To create a server-side rule, click the “Constraints” tab, then the “Add tag constraint” button (1):
A new window opens : this is where you add the rules. This interface can be considered as a toolbox allowing you to create rules based on two elements: data layer variables (“Variables”) or mobile OS (“Mobile”)(1).
Select the corresponding rule (2) and then:
Enter the it’s name in the corresponding field (“Name”)(3)
Check the tags you wish to apply the rule to (4)
Configure the rule (5)
Rules based on variables
The “ Variables” menu lets you create rules based on variables from your data layer (external or internal):
“If variable equals (GET and POST)”: Tags execute if the variable equals the specified value.
“If variable is not equal (GET)”: Tags execute if the variable (present in the query string of the incoming server-side hit, i.e. in “GET” format) is different from the specified value. This is the rule that will need to be used in most cases, rather than “If variable is not equal (POST)”.
“If variable is not equal (POST)”: Tags execute if the variable (present in the header of the incoming server-side hit, i.e. in “POST” format) is different from the specified value.
“If variable equals (based on saved Data)”: Tags execute if the “data storage”-type variable equals the specified value.
“If variable is not equal (based on saved Data)”: Tags execute if the “data storage”-type variable is different from the specified value.
“OR condition (one variable)”: Tags execute if the variable equals at least one of the specified values (the variable must be present in the query string of the incoming server-side hit, i.e. in “GET” format).
“NAND condition (one variable)”: Tags execute if the variable is different from the specified values (variable in “GET” format).
“OR condition (up to six possible variables)”: Tags execute if at least one of the variables equals the specified value (variable in “GET” format).
“AND condition (up to six possible variables)”: Tags execute if all variables equal the specified values (variable in “GET” format).
“If variable contains”: Tags execute if the variable contains the specified value (variable in “GET” format).
“If variable doesn’t contain”: Tags execute if the variable does not contain the specified value (variable in “GET” format).
“If variable exists”: Tags execute if the variable exists (variable in “GET” format).
“If variable doesn’t exist”: Tags execute if the variable does not exist (variable in “GET” format).
“Greater than condition”: Tags execute if the variable is greater than the specified value (variable in “GET”).
“Less than condition”: Tags execute if the variable is lesser than the specified value (variable au format GET).
Rules based on mobile OS
The “Mobile” menu lets you create mobile OS-based rules:
“Android”: Tags execute if the mobile OS is “Android”.
“iOS”: Tags execute if the mobile OS is “iOS”.
“Not Android”: Tags execute if the mobile OS is not “Android”.
“Not iOS”: Tags execute if the mobile OS is not “iOS”.
If you wish to modify (1) or delete a variable (2), click the corresponding icons in the rules summary page:
To generate a new container version and save all your work, please move forward to the “GENERATE” step (1).
Enter a comment (entering a comment is mandatory in order to keep good logs about the different container versions) (2) and click the blue “Generate” button (3).
Before generating your container, you can define the execution order of all your tags by clicking the handle (lines) and dragging and dropping each tag in the desired order (“RANK” column) (1). You can also activate or deactivate a tag by checking or unchecking the boxes (“ACTIVATION” column) (2).
Go to the “TEST” step to test your server-side container and verify outgoing hits’ structure.
Select the container version you wish to run tests on from the dropdown menu (1). Parameters sent with both GET (2) and POST (3) methods will be tested. Click the “Test” button (4) and make sure, by looking at the generated code, that outgoing hits are correctly structured (5):
Note: if you have already deployed your container, you still can test the live version (1) or an older/newer version in this section (2).
is the server-side incoming hit’s structure, which you need to provide your technical staff with for calls to Commanders Act servers from your servers occur.
In this section you can also consult the deployed versions’ history (1) and retrieve the server-side URL’s structure once your container is deployed (2): it is the server-side incoming hit’s structure, which you need to provide your technical staff with for calls to Commanders Act servers from your servers occur.
The first step consists in collecting the necessary information through the web container.
To do this, you will need to add the “Commanders Act – Data Saver 1.0” tag to your container, it will collect the information you need and store it for 24 hours on Commanders Act servers.
1)-In the Select step, select the “Commanders Act – Data Saver 1.0” tag and add it to your container:
2)-Configure your tag in the “Edit” step:
#STORAGE_KEY# corresponds to the reconciliation key to match data collected through the web container and that collected on the server-side (ex: user ID, basket ID…)
#DATA_KEYN# corresponds to the names of the variables that will collect and store information on the Website (ex: “order_id”, “cookie_vendor”…)
#DATA_VALUEN# corresponds to the variables’ value, e. information that was collected (ex: tc_vars[“order_id”]; a cookie’s value retrieved with and internal variable, etc…). In the following example, we wish to obtain the Order ID and the value of a cookie that was dropped by a partner solution. The reconciliation key that will allow to link Web data to that of the server side is the User ID. This is how you need to configure your tag:
#STORAGE_KEY# = tc_vars[“user_id”] (data layer variable)
#DATA_KEYN# = “order_id” or “cookie_vendor1” (needs to be typed because it is the variable’s name)
#DATA_VALUEN# = tc_vars[“order_id”] or the partner solution’s cookie’s name, collected with the tC.internalvars.get_cookie_vendor1
Note: The name of the partner solution’s cookie can be retrieved prior to this configuration (Options > Internal Variables):
Information collected by the tag will be stored on Commanders Act’s servers for 24h hours with this structure:
Reconciliation Key (user_id)
order_id
cookie_vendor1
123456
1234FR
A
567489
34565FR
A
346658
56456FR
B
…
…
…
3) – Add, if need be, firing rules in the Rules step, then generate and deploy your web container.
The second step consists in declaring variables retrieved with the “Commanders Act – Data Saver 1.0” tag in the “Server-side external variables” section. You will thus be able to map them with your server-side tags and send your partners values collected with your Web container.
1)- Go to the “Options” > “Server-side” > “External Variables” and click “Add variable” to add your data storage variables.
“Name” and “Parameter label” correspond to the name of the variable present in the #DATA_KEYN# field in the “Commanders Act – Data Saver 1.0 ” tag.
Remember to check the “data storage” box to specify that the variable retrieved from the Web database:
You will find the variable among those in the external variables list:
2)- Lastly, make sure that the variable serving as reconciliation key is indeed present amid your server-side variables. The “Reconciliation key” box must be checked:
The third step consists in mapping variables from the data storage within the server-side tag in the edit step, just as you would map a server-side variable. These variables’ names will be preceded by the “External Variables (data storage)” specification :
The fourth step (optional) consists in creating rules in terms of data saver variables. To do this, go to the Rules section. Two rule types can be defined based on data saver variables:
“If variable equals (based on saved Data)”: A tag executes if the “data storage” variable equals the specified valyue.
“If variable is not equal (based on saved Data)”: A tag executes if the “data storage” variable is different from the specified value.
When you are finished configuring the aforementioned elements, you can generate, test and deploying your server-side container.
