Evars Downstream - Instances and Persistence

[skatofiabah]

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.

[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. 

[Jennifer_Dungan]

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.... 

[skatofiabah]

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!

[MandyGeorge]

Yes, that's right. To summarize:

regular evar = instances where it was set on the site

post_evar = instances and persistence

event list = fires the event every time the value is fired on the site or set with a processing rule (counts instances)

[skatofiabah]

Hi @MandyGeorge, 

What is the different between regular evar and event list? It sounds the same to me. Is event list just instances after processing rules whereas regular evar is before processing rules?

[Jennifer_Dungan]

events_list is a comma separated list of all the metrics that were triggered for a hit.

With your Raw Data feed, you should get an events.tsv file that shows you the mapping:

1 Purchase
2 Product View
10 Cart Open
11 Checkout
12 Cart Add
13 Cart Remove
14 Cart View
20 Campaign View
100 Instance of eVar1
101 Instance of eVar2
102 Instance of eVar3
...
198 Instance of eVar99
199 Instance of eVar100
10000 Instance of eVar101
10001 Instance of eVar102
10002 Instance of eVar103
...
10148 Instance of eVar249
10149 Instance of eVar250
200 Custom Event 1
201 Custom Event 2
202 Custom Event 3
...
298 Custom Event 99
299 Custom Event 100
20100 Custom Event 101
20101 Custom Event 102
20102 Custom Event 103
...

---

Every metric has a "visible name" (i.e. purchase, or Instance of eVar1, or Custom Event 27, etc), and then they all have a unique number associated to them... those unique numbers are what you will see in events_list

So, let's say on a hit you have s.events = "purchase,event5"; and you also have s.eVar1 = "X"

your events_list will be "1,100,204"

• 1 for "purchase"
• 100 for "instance of eVar1"
• 204 for "event5"

[Jennifer_Dungan]

Technically, the non-post version would be instances... but not necessarily all instances... instances that are set with processing rules will show only in the post_eVar value.

Basically, the post values are instances and persistence... but a scenario with a post value and not a regular value may not be a persistence but it may also be an instance....

Example:

• Page 1
  • eVar1 set to "X"
  • Raw Data
    • eVar1 = "X"
    • post_eVar1 = "X"
    • events_list contains "100"
• Page 2
  • eVar1 set to "Y"
  • Processing Rule sets eVar1 to "Z"
  • Raw Data
    • eVar1 = "Y"
    • post_eVar1 = "Z"
    • events_list contains "100"
• Page 3
  • eVar1 not set
  • Raw Data
    • eVar1 = ""
    • post_eVar1 = "Z"
    • events_list does not contain "100"
• Page 4
  • eVar1 not set
  • Processing Rule sets eVar1 to "W"
  • Raw Data
    • eVar1 = ""
    • post_eVar1 = "W"
    • events_list contains "100"

The instance will appear in the non-post column when it is sent directly to Adobe, but if it is set using processing or Vista rules, it will only appear in post_ variation...

Because of this, you cannot know if an eVar was an instance or not by looking at the dimension data alone... only the events_list can tell you that, since the non-post and post columns will look at the same; page 3 and 4 have no eVar1 set, and both have post_eVar1 set, but only page4 has the instance event 100 in events_list.

[skatofiabah]

Hi @Jennifer_Dungan,

So if I'm understanding this correctly, I should only be looking at event_list instance of evar to get a true instances only after processing rules. I cannot use Post_Evar because that is both instances + persistence. I cannot use evar because those are instances only, but not pre-processing rules, or are they both instances + persistence but just pre-processing rules?

Long story short, just use the event list for the instance to get post-processing rules?

[Jennifer_Dungan]

If you need to match the "Instance" that you get in Adobe, then yes, the only way is to use the actual "instance event" for the dimension...

In your raw data, think of the "evar1" value as what is sent to the Adobe server, and the post_evar1 as the final result of the value (after processing rules, and Vista rules, and attribution, etc).

I think this is partially done this way, so that IF there is an issue with any of the processing being done, you have the original value to look at for debugging. 

In the case of mobile apps (that rely on context variables and processing rules), the "original value" is null... the value that is set is only done as part of the processing.

Of course, if you have moved to the XDM Streams on your mobile apps, data might be set directly (using the analytics schema and setting props and eVars directly)... or maybe it's still being mapped from the new schemas to the AA designations... which again would be a form of processed mapping...

The safest approach however, if you are trying to match workspace, would be to use the actual "instance" event...

For reference this:

Is the same as:

Whether you apply the "Instance" model to the dimension, or look for the instance metric to exist... the logic in workspace is all based off of that specific instance metric.

Depending on if you are using processing rules, counting the values in your eVar values might get you close.. but if something changes and processing rules start getting used, this could cause a lot divergence in your values... so it's best to try and use the events right away to avoid potential future issues... 

[skatofiabah]

Hi @Jennifer_Dungan,

At the end when you mention use the events, you mean use the # that corresponds to the instance of eVar# in the Event_List Dimension downstream, right?

[Jennifer_Dungan]

Yes, once you identify the event # for the "Instance" event, that corresponds to your eVar, you can use that in your SQL to find the instance.

Keeping in mind, that the instance will trigger if the same value is set to the eVar in a row:

• Page 1 - eVar1 = "X"
• Page 2 - eVar1 = "X"
• Page 3 - eVar1 = "X"
• Page 4 - eVar1 = "Y"
• Page 5 - eVar1 = "X"
• Page 6 - eVar1 not set, but retains value "X"
• etc

In Workspace, this would be:

		Page View	Instance	Non-Repeating Instance
eVar1		6	5	3
	X	5	4	2
	Y	1	1	1

If you need unique instances (i.e. Non-Repeating Instances), you would need to do a lot more logic pairing the Instance against the value in the post_eVar column to only count the first time the instance event is fired in sequential order... 

[skatofiabah]

Hi @Jennifer_Dungan,

The last point you bring up is super interesting. Unique Instances is something we are really after. There is no default field for that in Data Feed? We need to look at when the Evar Event_List fires and then scrap off everything that is not duplicate after the original?

[Jennifer_Dungan]

In theory... if you are looking for the unique instance, you might not need to use the event... You could just pull up the sequence of the post_eVar values, and take the first value (ignoring the repeats) until the next value is populated, and so forth... you can use the Hit Depth to make sure you are getting the correct sequence order.

So if looking at:

• Page 1 - eVar1 = "X"
• Page 2 - eVar1 = "X"
• Page 3 - eVar1 = "X"
• Page 4 - eVar1 = "Y"
• Page 5 - eVar1 = "X"
• Page 6 - eVar1 not set, but retains value "X"

You would see the first value "X" on page 1, then ignore pages 2 and 3, then get the first value of "Y" on page 4, then again the value of "X" on page 5, ignoring page 6....

[skatofiabah]

Hi @Jennifer_Dungan,

There is no hit depth downstream: https://experienceleague.adobe.com/en/docs/analytics/export/analytics-data-feed/data-feed-contents/d...

[Jennifer_Dungan]

There is, it's called visit_page_num

Gotta love all the different naming conventions, lol. Especially since this sounds specially like "page" number, but it is in fact for Hits....

[skatofiabah]

Hi @Jennifer_Dungan,

Thank you so much! You are the best!

[Jennifer_Dungan]

You are very welcome!

[Jennifer_Dungan]

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

[skatofiabah]

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]

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.