Expand my Community achievements bar.

We are excited to introduce our latest innovation to enhance the Adobe Campaign user experience — the Adobe Campaign v8 Web User Interface!
SOLVED

Difference in click figures between Consolidated Tracking and Recipient Tracking Logs

Avatar

Level 3

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?

1 Accepted Solution

Avatar

Correct answer by
Level 10

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.

1419308_pastedImage_0.png

Regards,

Amit

View solution in original post

9 Replies

Avatar

Level 3

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.

Avatar

Level 10

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

Avatar

Level 3

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

Avatar

Correct answer by
Level 10

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.

1419308_pastedImage_0.png

Regards,

Amit

Avatar

Level 3

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.

Avatar

Level 10

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

Happy to help!

Regards,

Amit

Avatar

Level 3

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?

Avatar

Employee Advisor

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

Avatar

Level 2

Hi Vipul,

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

Label

NameValueDescription
Errorserrors2Errors
Message countersmessageCounters8Message counters
Reset trackingresetTracking4Reset tracking
Trackingtracking1Tracking
Up to datenone0Up to date

 

Regards,

Nitesh.