Difference in click figures between Consolidated Tracking and Recipient Tracking Logs

[alistairk161838]

I have extracted the figures for a single campaign from both of the above tables and was surprised to see that the Consolidated Tracking table is reporting click figures quite a lot higher than those found in the Recipient Tracking Log.

Is there any reason why this is the case?

[alistairk161838]

Amit_Kumar​

Any thoughts? To clarify I have extracted a campaign with a single delivery and have used the delivery id from both the consolidated tracking table and recipient tracking logs to make sure that I'm not double counting instances where a URL may have been used across multiple campaigns/deliveries.

[Jean-Serge_Biro]

Hi Alistair,

Please may you tell if it is a recent delivery, within the purge delay scope?

Please check the xtk.options values:

NmsCleanup_TrackingLogPurgeDelay

NmsCleanup_TrackingStatPurgeDelay

(or use the menu Tools>Advanced>Deployment wizard and go to the purge delay page).

Then, it is within the right purge delay scope, and you see some values differences, please check technical processes.

Regards
J-Serge

[alistairk161838]

Hi JSB,

Thanks for the reply. The campaign in question was sent out within the last two weeks and the purge values all seem to be standard. What would be the next steps in checking the technical process - considering the environment I'm currently accessing is Adobe hosted.

I'm slightly confused as to what could be throwing off the figures as surely the consolidated table is an aggregation of the tracking table/s.

Regards

Alistair

[Amit_Kumar · Accepted solution]

Hi Alistair,

I am sure you are counting unique clicks from you tracking logs, please double check if you are counting unique or all?

Consoldated logs count all clciks not just uniue clcoks. i.e.,Sum of all @totalClicks with a URL type equal to "Email click"(sum(Iif([url/@type]=1, @totalClicks, 0))).

Most of the time we see that count in tracking logs is higher than the consolidated tracking logs this may have happened because of numerous reasons, such as automatic workflow to update this schema is behind the tracking logs by 5 minutes or it was failed or was not successful because of a system restart, etc.

To fix this, select the concerned delivery in the Adobe Campaign Explorer, right-click and choose Action>Recompute delivery and tracking indicators. Select the highlighted option, Click Next, then click Finish.

Regards,

Amit

[alistairk161838]

Thanks Amit. Running that process didn't change my tracking log table but it did appear to fix my consolidated table which is now reporting the lower clicks I was expecting/hoping to see.

[Amit_Kumar]

Thanks Alistair, It was supposed to fix the indicators only so it worked as expected.

Happy to help!

Regards,

Amit

[alistairk161838]

Thanks Amit - as ever your knowledge is gratefully received

On a slightly related note, do you happen to know the process which is being run by this process and if it is possible to call from code rather than the several layers of GUI needed to navigate ATM?

[Vipul_Raghav]

Hi Alistair,

You can do this task with the help of a workflow.

Create a JS Code activity inside workflow with following code to recompute statistics on deliveries with creation date between a certain period and are in a FINISHED state.

//selecting Delivery IDs from nmsDelivery Schema
var query = xtk.queryDef.create(
<queryDef schema="nms:delivery" operation="select">    
  <select>        
    <node expr="@internalName"/>        
    <node expr="@id"/>      
  </select>      
  <where>        
    <condition boolOperator="AND" expr="@created &gt;= #2018-01-01 00:00:00.000Z#"/>         
    <condition boolOperator="AND" expr="@created &lt;= #2018-02-28 23:59:00.000Z#"/>         
    <condition boolOperator="AND" expr="@state = 95"/>      
   </where>     
</queryDef> ); 
var res = query.ExecuteQuery();   //Executing the Query
var count = 0; 
for each(delivery in res.delivery){      //Reading the query result
nms.delivery.RecomputeStats(delivery.@id, 4);    //Recomputing the Delivery and Tracking stats of the Delivery ID passed as parameter
logInfo("RecomputeStats on delivery " + delivery.@id);  //Printing the Delivery ID
count++;
}
logInfo("Recomputed " + count + " deliveries");

Hope this helps.

Please feel free to modify the selection criteria based on internal name rather than creation date. Also, remove the state filter to pick up in progress deliveries as well.

Regards,
Vipul

[nitesha38268385]

Hi Vipul,

Can you please help is passing dirty flag parameter in recomputeStats function. Below is the Enumeration found for the Dirty Flag.

Label	Name	Value	Description
Errors	errors	2	Errors
Message counters	messageCounters	8	Message counters
Reset tracking	resetTracking	4	Reset tracking
Tracking	tracking	1	Tracking
Up to date	none	0	Up to date

Regards,

Nitesh.