Product order just now showing up in reporting over 6-months later

[PhillipTr2]

Here's a puzzle. I have a product order containing two products that occurred in late November just now showing up in reporting over 6 months later. An eagle-eyed director caught that two products that changed skus last February showed up in reporting today.

Coincidence that an order with "old" skus suddenly appeared today? The order was placed in November and shipped out in December according to our eComm platform, but Adobe Analytics somehow didn't report on the order when it happened.

I've waited a few hours before reaching out to Adobe support and this forum in hopes that the issue would resolve itself.

Have anyone experienced this? What could be the root cause? Is there a way to audit if this has happened previously or is an ongoing issue?

Thanks in advance!

[Jennifer_Dungan]

That's very strange....

Just curious, do you have offline tracking enabled? Is it possible that this purchase came from a mobile app that somehow got into a strange mode that ended up storing the analytics of a purchase from back in Nov, and only sent the data now?

Or maybe you timestamps enabled (this is part of offline data logic which is supposed to set data collected offline back to the correct date when the event took place)... but instead of acting like "offline tracking"... the data was sent to the system back in Nov, but with a future datetime stamp.. meaning the tracking call was always there in the data, but not seen because it occurred in the future?

Another possibility, do you have any data import processes running that might have sent old purchase information into the current data?

You could try exporting Raw Data, and comparing the date_time (which should be the time the hit was received to the server) ad the cust_hit_time_gmt (which is the "timestamp of the hit" in timestamp enabled report suites). You might have to export current and Nov data to find the correct row of data.... 

Good luck!

[justinhess]

Solid theories - I know that we capture timestamp based on the local system clock of the user and if the visitor has their clock set to 6mo. back, it will show that way in the data unless you supplement with another out-of-the-box day/time metric. We'll be addressing this issue in parralel with our websdk migration later in the year, but just thought I'd call it out.

[Jennifer_Dungan]

Lol, in my experience... never trust the user!

You would be surprised how many people have their system time set incorrectly.... we used to have issues on some of our sites with logins, if the user clock was out of sync it would cause the authentication cookies to be deleted (i.e. their time was outside of the login session period).... the number of people who used to call our customer service about the issue was astounding!

I get that with offline tracking, you don't have an option (since you don't have access to server time)... but it definitely opens the door to some crazy situations.

[PhillipTr2]

A bit of a follow-up from Adobe Support:

"Basically, the logic here is that Adobe acts as a data container and processor, while you are the data controller. You send us the data, being the controller and set the rules for data processing, and Adobe collects and processes the data based on these rules. So, the report shows the Order in the month of June because the data was sent to Adobe in June.

The code version is JS which indicates online hit. Hence, as the data was sent to Adobe on 11th June, the report shows the order id on 11th June."

Based on this, any change in thoughts?

[Jennifer_Dungan]

It sounds like Adobe Support forgot about Timestamp Enabled Suites... In that scenario (as I mentioned above), the included timestamp controls "when the order took place" not the timestamp that the hit was received. 

This is specifically designed like this to support offline data from mobile apps... so that IF a user is offline while using an App, the tracking calls will queue up in the app, and send the entire bundle when that user reconnects to the internet... 

However, that relies on the user's system time to create the appropriate timestamps.. and if their clock is set incorrectly (like 6 months into the future), the tracking will reflect that...

The best way to see if this is the case is to look at the Raw Data...  I would export Data from November (when the Order ID was received by your system) and another one for when Adobe says it happened (since I don't know if the exports are based on when the hit was received or when it "took place" - I don't have timestamp enabled suites, our apps don't support offline data so I can't pull a scenario in my own data to match what you are seeing).

Between those two files, you should be able to find that order and see if what the timestamp data says; and confirm if this is a case of the "time the event supposedly took place" being significantly off of when the hit was received.