Server Side Deduplication with JENTIS

With all the basics covered, let's jump headfirst into the implementation. Here is a short summary of what is required and what the parts of the tag management are.

We will create those elements:

• Trigger: To capture only the first conversion and not the rest, the triggers need a parameter to check this back with.

• Backend Variable: This will be the trigger's parameter. The actual result value must be either true or false, signaling whether this is a new or redundant conversion.

• Frontend Unique Identifier: An ID, such as a transaction_id, that identifies the conversion.

• Tags: Update the tags to use the new trigger and maybe create new tags that connect to the deduplication logic.

Here are the details and step by step integration of those. We will start with the variables and later update the trigger and tags.

Frontend Unique Identifier

The core of this process is the unique identifier. An external application is needed to link a conversion to a particular transaction. This application should know which transaction the conversion is related to and submit that information to the data layer. This is a standard practice for e-commerce tracking, such as Universal Analytics enhanced e-commerce. In case of JENTIS native data model, the data can be pushed to the JENTIS Data Layer by following this process:

_jts.push({
  "track"  :  "order",
  "orderid":  "abcdef1234567890",
  ...
});

By accessing the standard variable "order_id" on the frontend, we can retrieve its value on the server side using backend variables.

Backend Variable

The main chunk of code comes with this backend variable. So we will look at it line by line and see what it does.

async function() {
  var storage_name  = "existing_order_ids";
  var max_storage   = 5;
  let existing_ids  = await this.storage.read(storage_name) || "";
  let new_order_id  = this.getFrontendVariable("dl_order_number");

  if(existing_ids && new_order_id != null && new_order_id != "" && existing_ids.indexOf(new_order_id) >= 0){
    return true;
  } else if(new_order_id && new_order_id != null && new_order_id != "") {
    existing_ids += new_order_id+";";

    if(existing_ids.split(";").length > max_storage){
      existing_ids = existing_ids.split(";");
      existing_ids.shift();
      existing_ids = existing_ids.join(";");
    }

    this.storage.write(storage_name, existing_ids, Date.now()[phone]);

    return false;
  }
  return null;
}

To achieve our goal, we need to keep a record of known conversions or transaction IDs. This record will be saved on the server's local storage. The storage_name is a unique static key to identify the location and is not used in another variable or function. We will also set a maximum list length to avoid overcrowding the storage.

The code will use the API this.storage.read(storage_name) to access previously saved IDs. To match a new ID to the existing list, we will need to read a new value with this.getFrontendVariable(…). In this step, we will use the reference from the previous step, which creates the frontend variable that holds the conversion identifier.

Next, we use if-else statements to handle the situation. If the new ID is found in the existing IDs list, the variable will return "false," and the new ID will be concatenated to the existing list. The storage will be updated using the this.storage.write operation.

That's all we need to do. We can save this function as a new backend variable.

Trigger Update

Now, we need to apply the logic in a trigger. We will add a condition to the “Order” conversion trigger for that.

By the way: this is the default JENTIS Data Layer for purchase tracking that also uses the default JENTIS State (click on those items to learn more on those basic concepts).

In our example, we have a custom trigger defined that activates on the JENTIS Data Layer, though this approach with the variable can be used on any trigger and state. In the conditions, the Order ID Existing variable value is checked to be "false," which indicates that this Order ID already exists (so we can safely activate it according to tags).

Tag Update

The last step is to activate a tag on our new trigger. Two scenarios are plausible here: track the conversion only the first time, and optionally add a tag to track redundant calls as an event (that is not a conversion).

So if you need safety or are just curious to have all the data (meaning also to track events when redundant conversions would have been tracked but were filtered by our setup here) an accompanying tag makes sense. Ensure you are not missing out on anything and that the actual deduplication process is activated correctly. Thus, you’d need a second trigger that has the same conditions, but the check on “Order ID Existing” is looking for “false”.

Conclusion

Make sure to preview this new process in the JTM preview. If everything looks good to go – you are ready for the release!

The concept of events in JENTIS is that each event is a "state". In the context of such state, each variable is evaluated and has a specific value, all triggers are evaluated, too. That all happens in sync with client- and server-side elements of your JENTIS Tag Manager, regardless of where your variable is computed (server or client), it will be available to all JENTIS elements. Read more on this concept: JENTIS States Framework

\