Serialization Length is overdue for an update - we need to support more than 20 characters

[#1]

Description

20 characters generally is no longer enough to serialize events against... System GUIDs are now generally 36 characters, but can be longer... transaction ids from Google Play Store are 24 characters (now, right now, the solution is to strip the gns or gpa designation at the beginning, and all the . and - characters which just gets us to 20; but how long will this solution last?).

20 characters may have been enough at one time, but times have changed and serialization needs to change with it.

Why is this feature important to you

Being able to properly serialize against User GUIDs or full transaction ids, rather than risking those values starting with the same 20 characters and being ignored is important to anyone dealing with transactions or any sort of need to de-duplicate based on user ids (account registrations for instance)

How would you like the feature to work

Serialization needs to allow more than 20 characters... while 36 would cover a lot of needs, there could be other scenarios where this isn't enough... increasing to 255 should cover most concerns and then some.

Current Behaviour

Serialization is currently limited to 20 characters, anything passed above that is truncated and only the first 20 characters are used for serialization.. this poses a risk of multiple values matching in the first 20 characters (but diverging in the last half) being ignore by the system.

[#2]

Hello @Jennifer_Dungan ,

I just want to make sure I understand this correctly.  Are you talking about ECID or any ID being captured into an eVar?  Because capturing ECID into an eVar automatically gives you 255 characters right?  

That is what we do, we capture the ECID into an eVar, and use that as the ID to join on after we do a data feed into Snowflake.  

Then, we also have a cookie capture the ECID into a hidden field for for Marketo forms allowing us to join on that later.  

Not sure what is restricting the character count to 20?  Sorry if I misunderstood this.  

[#3]

@Damonwhall I'm talking about Event Serialization, not eVars.

Events can be set with three different models:

1. Always Record the Event
2. Record the Event once per Session
3. Use Event Id (i.e. Event Serialization)
   • This is where you can pass an Unique ID that will only track the event once ever for that ID... this is restricted to 20 characters

Event Serialization ensures that if an event with the same id is sent twice, only the first time will ever be tracked - all others will be ignored. This is commonly used for things like an Account Registration... so that if they refresh the "account completion page" or hit it again through their browser navigation I won't count the registration more than once.

The Purchase ID on purchases is a special reserved Event Serialization for transaction ID... In fact it's pretty much mandatory (Adobe will create a temporary fake purchase ID if one isn't provided)

But even if it wasn't, I don't want to risk double counting a purchase, and since we do in fact have transaction ids on our purchases we should be using them. 

Event Serialization:

https://experienceleague.adobe.com/docs/analytics/implementation/vars/page-vars/events/event-seriali...

Valid values are alpha-numeric characters up to 20 bytes in length. If you enter a value that is longer than 20 bytes, then the system truncates it to the first 20 bytes.

---

Purchase ID:

https://experienceleague.adobe.com/docs/analytics/implementation/vars/page-vars/purchaseid.html?lang...

This variable can store a maximum of 20 bytes; values longer than 20 bytes are truncated. If this truncated value matches subsequent truncated values, those subsequent hits are de-duplicated.

---

20 Character is insufficient by modern needs.

[#4]

@Damonwhall Also, I would not use an ECID for Event Serialization, as this value for the user will change across devices... I would only ever use our internal system GUIDs that are unique to that user's login account and never change.

[#5]

@Jennifer_Dungan got it! this was helpful.  I have worked in primarily B2B organizations when using AA, so using Event Serialization in a cart would be a newer experience for me.  Your original request makes sense to me now.  

[#6]

@Damonwhall no worries, there are a lot of similar sounding features in Adobe, it can be easy to mistake which one is being discussed.

You are right though, eVars have 255 characters, and I do use that to its full potential; but even though our data is exported to our Data Lake, I cannot rely on our data team to weed out the duplicates, since we still pull a lot of reports from Adobe directly... its better to make sure both sets of data have accounted for de-duplication.

[#7]

I agree.  Makes sense.  

Side note, because eVars have 255 characters, I have used that to solve our limitations on the 3 Listvar limit.  There are times where an eVar will work with the 255 characters by concatenating a string of data vs using a list var.  

[#8]

Yes, but again, lists are a completely different beast than serialization...  but since you brought up lists, another thing to use there (since lists don't have a limit, only 255 per list item, but you can have many items passed), is to send multiple things into the same list and use prefixes to create classifications on... 

So let's say you are collecting a list of authors, a list of keywords, and a list of multimedia assets on the article.... you can pass as:

"a:author name1|a:author name2|k:keyword 1|k:keyword 2|k:keyword 3|k:keyword 4|k:keyword 5|m:video 1|m:image 1|m:image 2|m:image 3|m:audio file 1"

Then use

• "a:" to classify into an "Authors" classification
• "k:" to classify in a "Keywords" classification
• and "m:" to classify into a "Multimedia" classification

Serialization is not about tracking that value (though you should in it's own dimension), passing a serial number is a way to enforce unique event tracking in Adobe based on that ID.

[#9]

Very good explanation, Jen.  I would say most often, event Serialization will be first encountered by most individuals in the eComm/purchase scenario, which is where I am most familiar with it; and, I 100% agree with you.  It is more than about time for Adobe to address the issue related to character length for Serialization.  20 characters is entirely too short, even for the year 2000.