• 12 Sep 2023
  • 6 Minutes to read
  • Contributors
  • Dark


  • Dark

Article Summary

A Tool in context of the JENTIS Data Capturing platform is an abstract object that holds a configuration for a data recipient. That can be an external third party data application (web analytics, data science), marketing and ad technology or even an internal data storage. This configuration includes the properties of an individual network or application required for its basic setup. This way you have a single entry point to adjust a setting for multiple tags in your JENTIS Tag Manager configuration.

If you are interested in a list of all supported tools in JENTIS, please head this way: JTM Tools List

Tool Instance Configuration

A tool instance defines properties of a service that you want to enable with the JENTIS Data Capturing platform. Services in this regard are partner networks and data bases such as Facebook, Google Ads or Google Analytics. Further a tool can also be a configuration to a custom endpoint that your JTM server needs to interact with. A manifestation of a defined configuration is referred to as a "tool instance configuration". In your JENTIS DCP you can have multiple configuration instances of the same tool, ie. "Google Analytics Europe" and "Google Analytics US" for different configurations per region.

Tool Creation Process

In your JTM account you will find Tools in the top of the main navigation. Here a tools instances are managed. Any tool or service (Facebook, Google Ads, Google Analytics, etc.) can be configured multiple times (instances). In case that you need to implement multiple different data recipients (Pixel or Property IDs, etc.) with a single provider.

Tool configuration instances have properties that you can access in all the tags that are associated with them. This properties are used for global configuration values, such as a property or account ID. In context of Google Analytics this is the Measurement ID (GA4) or the Property ID (UA-ID for Universal Analytics). Further you can define more custom parameters that are required as a global constant for your configuration.

A tool configuration instance consists of the following settings:

  • Name: Give your tool instance a human readable and meaningful name. We'd recommend to specify here a brief tool handle ("GA") and its purpose ("Web Analytics") and optionally the data target, if there are multiple instances ("UA-12345-0").
  • Containers: This very important setting defines on what containers this tool configuration (with all associated Tags, Triggers and other elements) will be activated on a given JENTIS Tag Manager Container (ie. a given domain or website).
  • Constant Settings: These are the global fields, that are shared across all tags of this tool instance. Those fields and values can hold different values for each environment (live, stage) and container (each to be defined in its column). This way you can create basic lookup tables for each individual container configuration. To set individual values in a field please click the "three boxes"-icon in the field input (at the most right of the input field).

Tools Advanced Settings

On the advanced settings tab of a tool instance configuration you can adjust the mapping to a vendor (see details on consent and vendor administration here: Consent Management) or add custom global variables to this tool.

Vendor Settings

Every tool must be assigned to a vendor in JENTIS. By default for each tool an equivalent vendor exists by default (with the exact same name, so tool name and vendor name match). However you can create custom vendors with different settings and map your tool to your custom vendor.

Further a vendor, based on its configuration, can be connected to a CMP (consent management platform) to receive consent information and operate based on the consent provided. For more information on this topic please refer to: JENTIS CMP Connectors

Backend Data Storage

Every tool configuration instance in your JENTIS account will operate in its own scope. The implication is that data can not be shared between different tools in JENTIS, which is enhancing privacy and data security. Every time a value is persisted on the JENTIS server for a tool it is only for this single tool that executed, ie. a "Client ID" value for the tool to internally identify a website visitor. Another tool instance (even if both tools are from the same class, ie. "Google Ads - EU" and "Google Ads - US") will not access the other tools data.

With the feature to set custom Backend Data Storage options in a tool you can now share data for the same tool classes. Here is how to configure this setting. Let's examine it in the example of Google Ads.

Activate Backend Data Storage - Background and Example

Lets cover some background first. Google Ads requires a parameter value that must be stored from page entrance up to the event of conversion (which might be on a later page or session of a visitor). It's the "gclid" URL query parameter value that must be stored and best is to use a server-side storage. As it is the most secure and reliable option.

JENTIS by default will persist this information when a Google Ads tool instance is installed in your account with all tags automatically created (you must select this option when the tool is configured initially). Now whenever a user enters the website and this tool is executed (based on the triggers and consent information) it will persist the "gclid" value on the server. For more information on which Google Ads tags to configure please refer to the tools documentation: Google Ads 

In a manual configuration you must make sure to activate the "Google Ads Campaign Detection" tag to persist any "gclid" parameter value received on page entrance.

Now as soon as the conversion signal is received (again, based on the triggers and consent information) it will access the accordingly stored information to submit the value of the "gclid" parameter to Google Ads. This access refers to the backend storage that holds the information. Generally this is on a per-tool-instance basis, as mentioned before, each tool must persist its own data.

Here comes the option into play to share data between tool instances. You can adjust the setting "Default Storage" to select another tool of the same class. If you do so, both tools will share the same storage.

There will be a hint if data is shared in the menu item.

In the example of Google Ads, if multiple instances of this tool are installed in your account, and you select this option, the "gclid" value will be available to all tool instances. So a conversion tracked in any of the tools will access the "gclid" value from any other tool. Possibly enhancing your data quality as less restrictions on sharing data now apply.

Generally this option is a good idea where multiple containers are used or when multiple instances of the same tool are configured. Please also make sure to check our guide on Cross Domain Tracking, which is often related. As data sharing might possibly also be technically restricted based on different website domains.

Further for custom implementations and code you must be aware that this setting (Backend Data Storage) on a tool affects the associated functions "storage.write" and "", for more details see: Backend Function Interfaces - Read and Write

Optional Constants

Some tools come with optional global settings: "Optional Constants". Just as with the main "Constants" on the tool you can configure here different values that you can then access in this tools tags. Further you can configure your own tool constant values to refer to in the tags. Again those values can be a default or set to individual values on container and environment level.

Tools Automatic Tag Creation

When a tool is created a toggle to "Automatically create Tags" is opted in. You can keep this enabled to generate all tags that are designed to work out of the box with the JENTIS Data Layer default.

It is recommended to keep this toggle if you intend to push data to the JENTIS Data Layer. If you primarily want to pull data based on your custom website and data layer design you can switch this toggle of, to not create tags that will not be triggered in that case anyway.

Was this article helpful?

What's Next