Different purchases with different order ID using same order ID in reports

[OscarMM]

Hi community, 

We have an issue tracking purchases.

We have a site where users can login and do purchases. If I as an user do 2 (or more) different purchases at different moment, system will generate and send to Analytics 2 different order id. But, what we can see in Analytics is both purchases are counted but they share the same Order ID.

My suspicious is it happens because both purchases are in the same visit and eVar# value is persistent during the visit. Does it make sense?

[Jennifer_Dungan]

It might have to do with your setting up your Order ID eVar as a Conversion Syntax Variable? Since you are sending the Order ID eVar on your Purchase, you don't really need Adobe to "hold the value" until your binding purchase event...

Why not just use either a normal eVar on the Purchase event (since the Order ID applies to the entire purchase... not just a specific product) and set it to Hit Expiry?

Conversion Syntax is generally used if you need to carry a value forward, from an earlier event (like search terms) to your "add to cart" or "purchase" product notation... but in this case, I think this is probably causing unnecessary complications in your tracking. 

While you can use Conversion Syntax on the same call as the binding event, I think that having it set to Visit expiry with multiple purchases is resulting in something like:

1. First Purchase is made
   • Order ID is set and bound to your first purchase event
2. Order ID from that purchase is retained (due to Visit expiry on the eVar)
3. Second Order is made
   • You have an existing Order ID value and a new value that you are trying to set
   • And your binding "purchase event"
   • I suspect that the binding event may be deferring to the first value in Order ID before setting the new value

This is speculation... as I don't have an Order ID set as a conversion variable syntax or have it set to Visit level expiry.

I am setting up a payment flow right now actually, but my Order ID, being sent on the Purchase call, will just be a Hit expiry standard eVar.

[OscarMM]

Hi @Jennifer_Dungan , as always thank your for your helpful responses.

You suggested "Why not just use either a normal eVar on the Purchase event (since the Order ID applies to the entire purchase... not just a specific product) and set it to Hit Expiry?". You mean switching "Expire After" to hit?

I already did it and run a couple of test to validate. I'll let you know how it result.

[Jennifer_Dungan]

You're welcome

Yes.. you could even drop the "Conversion Variable Syntax" (as in not make this a Merchandising eVar)

Since the Order ID applies to the entire order, and it's being set on the purchase event, it doesn't really need to be specifically stitched to the Products tracking.

We have other eVars that fire at the same time as s.products (not specifically tied to products, but definitely on the same call.... I can correlate those values (eVar > Product, or Product > eVar) and see them in the context of my Products... they are just normal eVars... not merchandising....

Unless there is a specific reason you need the Order to be a merchandising eVar (there are many ways to tag and process data, and you know your system better than I do)

[OscarMM]

@Jennifer_Dungan, keeping previous configuration and changing only "Expire After: to Hit" worked.

But, based on your suggestion, I can go and change "Enable Merchandising: to Disabled". Now my question is. Should I keep "Expire After: Hit" or "Expire After: Visit"?

I'm asking, because this Report Suite has other variables setup as "Expire After: Visit", but still keeping separate values for each hit (honestly, it doesn't make sense to me, but it works).

[Jennifer_Dungan · Accepted solution]

I personally would keep "Hit", but that all depends on whether you have a pressing need to keep tracking the Order ID on all subsequent hits after the purchase event

Basically, eVars default to "Visit"... but they don't have to stay that way...

Let's look at some basic examples:

Example 1: Campaign Code

Let's say you want to track a campaign code when the user enters a page, then you want to maintain that value for the rest of the visit (this way you can attribute this campaign to purchases, or newsletters signups, etc that happen after the user got her from said campaign)

Setting Visit makes sense....

Initial Page - Value is Set (you will also get an Instance of eVarX on this page view)

All other Pages - the value is maintained as part of the same visit, but there is no "instance" recorded...

- The value will stay set until the end of the visit, or until it is overwritten

Example 2: Page Name OR URL OR Something page specific

Let's say you are using your eVar to track something that might need more than 100 characters that you get in Props (Prop limit is 100, eVars are 255)... But if this value is page specific (and likely being set on every page), there is no need to have this set to a Visit Level expiry

Initial Page - Value X is set (instance of eVar is also tracked)

Next Page - Value Y is set (instance of eVar is also tracked)

Page After That - Value is set (instance of eVar is also tracked)

and so on...

Now, you might still want to expand the expiry, cause you want this value to also be set on your clicks/actions... but IF you land on a page that doesn't set the value, then the pre-existing value will continue to track.... personally, I prefer to just make sure the eVar is set on every Page View and Action to ensure that the wrong data isn't tracked on subsequent pages that might not be set correctly.

Note: You can always apply a custom attribution to your Hit Level eVars in Workspace... so IF you need to see something brought forward, you still have that option)

If you look at your eVars by "Page View", "Occurrences" and by "Instance of eVarX" you will see how the values are different - they will match if the eVar is set on every hit, but if not.. you will see quite a different picture.

Basically it comes down to understanding what data you are tracking, how you want to use it (and subsequently how do you potentially want that data to be persisted), and setting an appropriate scope to the dimension.

For something like Order ID... it seems very specific to your actual purchase... so Hit level is where I would put it... IF I needed to see something like ALL Orders for the Visitor in the Visit, or 1 Week, or 1 Month, etc... I would use custom attribution to apply a longer look back window with something like a Participation or Linear Model... or I would look at the First Touch Order in that time and another model for Last Touch Order...