Tracking workflow logic


The tracking workflow show only 1 command without much explanation: tracking -instance:%= instanceName % -download -update

The purpose of this KB article is to list the steps of the workflow in the backend:

Step 1 - download and insert tracking logs in the database (NmsTrackingLogXXX). During the -download step the workflow will log nothing.

-download will only fetch the tracking log from the different tracking containers and store them in database.

Step 2 - create tracking log statistics (NmsTrackingStats).

-update will consolidate the logs by creating aggregate records in NmsTrackingStats. The entire table is updated based on the deliveries that are marked for update. All tracking reports are fetching data from this table. You can do this step manually for each delivery that is missing Tracking statistics by clicking “recompute delivery statistics”.

Step 3 final one - rebuild the delivery statistics (NmsDeliveryLogStats) for all delivery impacted by an open or click (deliverers are processed one by one…)

The tracking workflow will also update several other tables:


It is important to check the fragmentation rate of indexes in these tables. If index fragmentation is above 30-35% the index needs to be rebuilt. For hosted clients, Adobe performs this maintenance operation once a month. If indexes of the tables are not rebuilt regularly, the tracking workflow execution is slowed down.

To see the exact queries executed by the tracking workflow use the command:

*nlserver tracking -instance:instanceName -download -update -verbose -tracefilter:<b>

This command will create an additional log inside /var/instanceName/log/tracking.log with all queries executed during Tracking workflow execution.

Sometimes customers ask if they can skip the update process? The answer is NO: Tracking Statistics will not be updated, data will be invalid, which can lead to numerous other problems regarding Tracking which we would like to avoid by any means necessary.

Once the tracking workflow execution is finished, the option NmsTracking_Pointer is updated. The option value will show the date of the last log retrieved in all tracking server containers and the message id in decimal format. If we convert this id to hexadecimal, it will be the name of the tracking file stored on the tracking server.


This article explains the workflow logic so it doesn’t require a resolution.

On this page