Level 5

Solved

Evars Downstream - Instances and Persistence

Forum|Forum|1 year ago
November 25, 2024
4 replies
2681 views

Hi,

I'm trying to figure out whether downstream eVars are always persistent since I think downstream daily web traffic is on a hit level. If they persist, is there no possible way to distinguish between an instance and a "Behind the scenes" persistent value of the eVar? The reason I ask is I am trying to tie out instances for an eVar in Adobe workspace with our Downstream Data. I'm anxious if I just count POST_EVAR# that it will just give me all persistence + instances when I need to figure out just instances.

Analytics

Best answer by MandyGeorge

If you're referring to the data feeds, then the way to differentiate between instances and persistence of evars is to compare the evar# and post_evar#.

In workspace, when an evar fires, if you use the "instances" metric, it will give you the number of times that the it actually fired. But if you use any other metric (like page views, occurrences, etc.) it will also count the times that the value persisted (instances + persistence for total occurrences).

In the data feeds, when an evar fires, it populates the evar#. If you want to see the persisted value of the evar you would use post_evar#. So, if you have a row where post_evar# is populated and evar# is blank, that means that it's a persisted value and not an actual firing.

If you want to replicate like the instances metric from workspace, you would count the number of times the evar# fired (not the post_evar#).

The persistence is based on the same rules that you set up for your workspace, so the allocation and expiry. If your evar is set to a visit level expiry in workspace, it will have the same expiry in the data feeds.

skatofiabahAuthor

Level 5

Hi,

How can you use SQL or certain columns to figure out whether an eVar is an Instance or Persistence or a combination? Is there an easy way about this? Or do you have to partition by visit when each unique instance of an eVar exists?

Jennifer_Dungan

Community Advisor and Adobe Champion

I do not believe you can really figure this out vis SQL alone...

Even checking if the post and non-post version of the values are set won't be an indication of this... Post Processing or VISTA rules could be setting the value of the eVar regardless of the attribution. It is possible that you might be able to compare the Instance of the eVar metric to when values are set (since values set with processing rules should still trigger the instance)... but if the eVar is always set (regardless of it's retention period) then you still may not know....

FYI, I am going to merge this with your other question, since these are interconnected.

skatofiabahAuthor

Level 5

Hi,

Do Custom Links Persist? Both in Workspace and Downstream? Or are they instance only? It seems like occurrences and instances of Custom Link in Workspace line up so maybe they don't persist?

Jennifer_Dungan

Community Advisor and Adobe Champion

Custom Links are basically a special reserved prop, so they have Hit Level attribution only. There is no Click Attribution.

If you need click data to be retained, you can create a custom eVar that is set on some or all of your clicks... but not set on page views... but keep in mind that if you are looking for attribution to something like an Order, you might want to be selective about which clicks use such an attribution.

MandyGeorge

Accepted solution

Community Advisor and Adobe Champion

If you're referring to the data feeds, then the way to differentiate between instances and persistence of evars is to compare the evar# and post_evar#.

In workspace, when an evar fires, if you use the "instances" metric, it will give you the number of times that the it actually fired. But if you use any other metric (like page views, occurrences, etc.) it will also count the times that the value persisted (instances + persistence for total occurrences).

In the data feeds, when an evar fires, it populates the evar#. If you want to see the persisted value of the evar you would use post_evar#. So, if you have a row where post_evar# is populated and evar# is blank, that means that it's a persisted value and not an actual firing.

If you want to replicate like the instances metric from workspace, you would count the number of times the evar# fired (not the post_evar#).

The persistence is based on the same rules that you set up for your workspace, so the allocation and expiry. If your evar is set to a visit level expiry in workspace, it will have the same expiry in the data feeds.

Jennifer_Dungan

Community Advisor and Adobe Champion

Actually, IF the eVar is populated by Processing Rules (i.e. Mobile Apps using context variables and processing rules), it won't show in the eVar column, but will still trigger the eVarX Instance... if you need to get the instances, you should use the metric, not either of the dimension columns....

skatofiabahAuthor

Level 5

Hi @jennifer_dungan @mandygeorge,

So if I'm piecing this all together, basically a non_post evar would be only instances? Whereas Post_evar can be either/or? And we can also look at Event_List to figure out exactly which of the evar are instances or not? If it's blank and the Post_Evar exists, we know it is persisted (non-instance)? Is this all more or less correct? Am I missing any key details?

Thanks!

Jennifer_Dungan

Community Advisor and Adobe Champion

In the Raw Data, the even if you use the Post_eVar value, there is an instance metric for each eVar that can be used to get the instance of the eVar being set:

Example:

Page 1
- eVar1 set to "A"
- Instance of eVar1 is triggered
- Raw Data
  - eVar1 = "A"
  - post_eVar1 = "A"
  - events_list, somewhere in the list of events, you will see "100" which is the instance metric for eVar1
Page 2
- eVar set to "A" (again)
- Instance of eVar1 is triggered
- (Same Raw Data as above)
Action 1
- eVar1 not set, but maintains value "A"
- Instance of eVar1 is not triggered
- Raw Data
  - eVar1 = ""
  - post_eVar1 = "A"
  - events_list will not include event 100

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded