Raw Data Feed Number of Purchases does not match with the Numbers of Purchases displayed in Adobe Analytics Workspace. | Community
Skip to main content
Level 2
June 22, 2024
Solved

Raw Data Feed Number of Purchases does not match with the Numbers of Purchases displayed in Adobe Analytics Workspace.

  • June 22, 2024
  • 1 reply
  • 1926 views

Hi Experts. 

 

Recently I have introduced the concept of capturing Subscription ID, Transactions ID for the purchase event getting triggered on the e-commerce cart.

 

In Adobe Analytics Workspace I am able to see very less data compared to what I am seeing in my data feeds. There is a drastic difference of 80% approx.

 

Eg: Workspace shows only 22 Purchase event and the Raw data feed has around 125.

 

All these 125 transactions in the data feed are valid Transactions - they are present in our zoura tables 

 

To query the data feed In am using respective evars and purchase event present in event list mapped.

 

What can be the possible causes for this. I want to ensure we see the same things that I see in data feeds in my workspace as the workspace provides more edge on the advance viz part. 

 

@jennifer_dungan, @VaniBhemarasetty

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Jennifer_Dungan

What are you using for your transaction ids? Keep in mind, Adobe's serialization only accepts 20 characters, if you are passing values like:

  • 12345678901234567890123
  • 12345678901234567890124
  • 12345678901234567890125

 

It may be taking the first 20 characters ("12345678901234567890") and treating them as the same, and therefore not including them in your data?

 

Note my idea posted about this limitation:

https://experienceleaguecommunities.adobe.com/t5/adobe-analytics-ideas/serialization-length-is-overdue-for-an-update-we-need-to-support/idi-p/620678

 

1 reply

Jennifer_Dungan
Community Advisor and Adobe Champion
Jennifer_DunganCommunity Advisor and Adobe ChampionAccepted solution
Community Advisor and Adobe Champion
June 23, 2024

What are you using for your transaction ids? Keep in mind, Adobe's serialization only accepts 20 characters, if you are passing values like:

  • 12345678901234567890123
  • 12345678901234567890124
  • 12345678901234567890125

 

It may be taking the first 20 characters ("12345678901234567890") and treating them as the same, and therefore not including them in your data?

 

Note my idea posted about this limitation:

https://experienceleaguecommunities.adobe.com/t5/adobe-analytics-ideas/serialization-length-is-overdue-for-an-update-we-need-to-support/idi-p/620678

 

omkarbhAuthor
Level 2
June 23, 2024

@jennifer_dungan  - you are awesome!

The issue was with the purchaseID! It was truncating data after 20 bytes, which was affecting the event serialization. Since the starting characters of the subscription ID were the same, Adobe was identifying them as duplicate purchases. It is surprising how I missed the part about the purchaseID size limit.

I have stopped passing my custom purchaseID and am letting Adobe create their own serialization.

Question: Is it possible to contact Adobe support and get the data processed that was missed due to the error in serialization?

omkarbhAuthor
Level 2
June 24, 2024

The Serialization limit doesn't seem to be widely advertised.... it can be very easily missed!

 

I think letting Adobe handle the Transaction ID / Purchase ID is a good idea, then you can still track this in your own custom eVar for your own reporting and mapping to your system.

 

What I see is  the values are populated in the eVar column but the postEvar Column is all empty 

That doesn't seem right... your eVar should be outside of the serialization... Are these in your standard Raw Data feeds? Do you have a sufficient delay on your feeds?

 

We have hourly feeds, but we set the maximum delay of 120 minutes to ensure that processing is completed before the feeds are sent...  originally our Data Team didn't do this and they used to miss a lot of data because of it.

 


That doesn't seem right... your eVar should be outside of the serialization... Are these in your standard Raw Data feeds? Do you have a sufficient delay on your feeds?

---------------------------------------------------------------------------------------------------
Yes - there is a delay of 120 mins and we have an hourly feed