Container
Last updated
Last updated
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.
