Expand my Community achievements bar.

Webinar: Adobe Customer Journey Analytics Product Innovations: A Quarterly Overview. Come learn for the Adobe Analytics Product team who will be covering AJO reporting, Graph-based Stitching, guided analysis for CJA, and more!
SOLVED

PurchaseID Duplication Issue

Avatar

Level 2

Hello,

I am noticing that the eVar that i use to send the transaction ID is getting duplicated along with metrics such as bookings and revenue. And I am setting this same transaction ID in my purchaseID variable on confirmation screen along with purchase event. From what I have read is setting purchaseID on confirmation provides serialization and orders are not counted multiple times even when the page is refreshed. But I created a report in my workspace to view my eVar reports that captures the transaction ID and I see multiple bookings and revenue associated with that transactionID. Does this mean my revenue is getting counted multiple times and purchaseID serialization does not work ? Also, I have been informed that all the below 3 transactions are being performed by different users on the site having different email. I also breakdown the 3 bookings below by date and the first one strangely was reported on May18,2017 second one on  Dec7, 2017 and the third one on  May14, 2019. Does this mean the logic of adding timestamp is wrong as well ?

This is how it sets the order id along with timestamp in TMS -

var todayDate = new Date();

            utc = todayDate.getTime() + (todayDate.getTimezoneOffset() * 60000);

            nd = new Date(utc + (3600000 * -7));

            if (typeof b.order_id != "undefined" && b.order_id.length > 0) {

                b.order_id = b.order_id + "|" + nd.toISOString().slice(0, 10);

I am not able to analyze what is the issue here ? Is the backend sending same order id for different people on the same day and it somehow counts revenue multiple times even though purchaseID is used to set the duplicated orderID's ? Please help and info would be appreciated

Adobe AnalyticsAmy_WongWoojinmghalpinJochem van Dietentheblair

1762945_pastedImage_4.png

1763163_pastedImage_0.png

1 Accepted Solution

Avatar

Correct answer by
Employee

Purchase expiry sounds like a better option if the goal is to tie eVar values to order IDs with as close to a one to one relationship as possible.  I suppose it would also depend on where the eVar is being populated.  If the value is populated only on the single hit wherein purchaseID is passed, something like pageview expiration may be an option as well.  Ultimately the decision rides on business needs, but I agree that visit expiration would cast too wide a net for your needs here.

Every variable has a "post" or "post-processing" column at a DataFeed level.  These columns are used to reflect any post processing that has occurred from the original value collected at an implementation level through the use of exclusions (IP/Bots), processing rules, VISTA rules, etc.  For instance, if I pass the value "dog" into eVar1 which has "visit" expiration, the value would immediately be copied over to the post column for the duration of the visit.  This is how conversion events that occur much later in a visit are tied back to campaign links, etc, passed at the first of the visit.

View solution in original post

6 Replies

Avatar

Employee

Serialization of purchase ID occurs on a hit level.  If a duplicate purchase ID is detected, I would expect conversion variables and events to be excluded from reporting for that particular hit.  My guess in this instance would be that the conversion variable is being set and persisted in the variables "post" column at the time a separate purchaseID is passed. 

To determine if this is the case, I would suggest pulling a raw datafeed and filtering against post_eVar127 to determine if this value is persisted against other purchaseID values.  You might consider reaching out to clientcare@adobe.com for assistance if needed.  The team should be able to assist in collecting additional information pertinent to your specific situation and isolate what is causing this behavior.

Avatar

Level 2

Thanks a lot Blaine, I actually looked into the persistence issue and noticed that the eVar above and various other such eVars has an expiry at 'visit' level. I suppose their expiration should be set at 'purchase' success event right ? Also, would setting these eVars to 'visit' level expiry may be the issue here ?

Also, along the same lines I have documented another issue, would love to hear your thoughts on that as well.

Question URL - PurchaseID set with Timestamp Issue

Avatar

Level 2

Also Blaine, can you provide more context when you mention 'post' column ? I am not aware of that terminology. Thanks !

Avatar

Correct answer by
Employee

Purchase expiry sounds like a better option if the goal is to tie eVar values to order IDs with as close to a one to one relationship as possible.  I suppose it would also depend on where the eVar is being populated.  If the value is populated only on the single hit wherein purchaseID is passed, something like pageview expiration may be an option as well.  Ultimately the decision rides on business needs, but I agree that visit expiration would cast too wide a net for your needs here.

Every variable has a "post" or "post-processing" column at a DataFeed level.  These columns are used to reflect any post processing that has occurred from the original value collected at an implementation level through the use of exclusions (IP/Bots), processing rules, VISTA rules, etc.  For instance, if I pass the value "dog" into eVar1 which has "visit" expiration, the value would immediately be copied over to the post column for the duration of the visit.  This is how conversion events that occur much later in a visit are tied back to campaign links, etc, passed at the first of the visit.

Avatar

Level 2

Thanks much again Blaine. Inorder to get the raw data feed and post eVar127 data would I need to contact client care or can it be done internally via adobe reporting ?  Also you mean that this same value of eVar127 might be persisted across these 3 bookings right ? But the worrying part here is that these 3 bookings were made in different years, so for eVar127 to persist so long for these 3 different bookings seems very difficult.

Avatar

Level 3

This may be due to hash collisions:

Hash collisions https://docs.adobe.com/content/help/en/analytics/implementation/analytics-basics/traffic-props-evars...

I've seen this with a couple companies I've worked for - hard to get around with variables that have many unique values of long strings.