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?
Solved! Go to 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
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.
Views
Replies
Total Likes
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
Views
Replies
Total Likes
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
Views
Replies
Total Likes
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
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.
Views
Replies
Total Likes
Thanks Alistair, It was supposed to fix the indicators only so it worked as expected.
Happy to help!
Regards,
Amit
Views
Replies
Total Likes
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?
Views
Replies
Total Likes
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 >= #2018-01-01 00:00:00.000Z#"/>
<condition boolOperator="AND" expr="@created <= #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
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.
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies