Hello,
We are having a lot of transactions on the site, so for this reason we are re-cycling our booking confirmation numbers/ order id numbers on the confirmation screen which is set into our purchaseID . Since we are re-using our booking confirmation number, in order to make our purchaseID unique we are adding timestamp to our purchaseID variable using pipe delimeter. So formula looks like:
purchaseID = order_id + '|' + timestamp (current date).
My concern here is, let's say I make a booking today and my purchase id looks like -
purchaseID = 5747118 | 6-7-2019
Now I access my confirmation screen again tomorrow and after 2 days, 3 days and so on and I see adobe calls firing. Because I accessed my confirmation page on different dates my timestamp changed and thus my purchaseID is not unique anymore. Even though I am seeing my same booking confirmation page my purchaseID is not unique now. Does this mean, every time i view my confirmation screen on a different day my booking/revenue would be counted multiple times ? If yes, what's the best way to tackle this issue ? Analytics - QuestionsAdobe Analytics
Solved! Go to Solution.
Purchase IDs are serialized, meaning each unique purchase is only ever counted once. If ever passed again, the purchase is seen as a duplicate and excluded from reporting (meaning only the first is ever counted). I'm unsure why one would re-access the confirmation page, unless it were to check on the reservation or booking. If that's the example you're describing, I'm not entirely sure why any purchaseID would be passed again without a purchase actually occurring. That said, if the same, now non-unique, purchaseID were passed when re-accessing these confirmation pages, I would expect the hit to be excluded from reporting, meaning it wouldn't inflate purchases.
I think my concern would be the exclusion of legitimate orders occurring the same day with the current format. All in all I would probably recommend a more granular timestamp (perhaps down to the second) and not passing the purchaseID unless an actual purchase occurs.
Purchase IDs are serialized, meaning each unique purchase is only ever counted once. If ever passed again, the purchase is seen as a duplicate and excluded from reporting (meaning only the first is ever counted). I'm unsure why one would re-access the confirmation page, unless it were to check on the reservation or booking. If that's the example you're describing, I'm not entirely sure why any purchaseID would be passed again without a purchase actually occurring. That said, if the same, now non-unique, purchaseID were passed when re-accessing these confirmation pages, I would expect the hit to be excluded from reporting, meaning it wouldn't inflate purchases.
I think my concern would be the exclusion of legitimate orders occurring the same day with the current format. All in all I would probably recommend a more granular timestamp (perhaps down to the second) and not passing the purchaseID unless an actual purchase occurs.
Thanks a lot Blaine for your insights. When you mention 'my concern would be the exclusion of legitimate orders occurring the same day with the current format' can you elaborate a bit more on that on what might you think that's the issue here. Also an important finding, I just verified that after I make a booking and land on confirmation page, there is no way i can view the confirmation page again. Once Im logged out I can only view the reservation details and if I try to copy paste the confirmation url it throws me out. Because of this, I am more confused now as to how these same order ids with different timestamps were viewed by the same user. Here is a adobe report showing the above issue, same order id with different timestamps accessed by the same user. Please have a look and if you could kindly give your thoughts.
Views
Replies
Total Likes
Views
Likes
Replies