Data not flowing through from site to Adobe Analytics

[dk14]

We have a number of variables that are tracked on our site and they all flow through to Adobe Analytics. However, I have just noticed that one of the values is not coming through. 

We are using Data Collection and have set the fields as Data Elements to populate. 

When looking in the Adobe Experience Debugger, I can see the value being populated, as well as seeing it in the network response. 

However, just one of the several fields does not show up when running reports. 

I have looked at data for the whole month and nothing is showing.

Any ideas on why some data points would come through and another wouldn't?

[V_Pavan]

Hey @dk14 could you kindly elaborate the use case/scenario which type of values are you trying to track and which variables(eVar/prop) are you using to track it and how have you framed the rule.

[yuhuisg]

@dk14 Adding some screenshots of what you're observing would be helpful too.

[dk14]

Unfortunately our inhouse Adobe knowledge expert left recently so hopefully this is some of the infomration that will be helpful.

In this case, it is an eVar that is being populated (eVar28). 

Here are some screens shots of the Adobe Experience platform results 

I am getting a valid response on the adobe call on the page and I can all see under there the data being populated.

The Data Element

And the Rule

We have many values that are being populated, just not this one and another new one that we were setting up and testing. 

We also have a 2nd site that uses the old adobe processing rules to populate. These both populate the same report suite, and we dont have any issues with that data.

[Jennifer_Dungan]

So the issue is that eVars 11, 19, 25, 35, 44, 67. etc aren't being sent on the third call?

First, you need to check if that is a Page View or an Action... look a little farther down, do you see these rows, and are they populated?

It's possible that the person who designed your site implementation choose specifically not to send the eVars on actions.. or perhaps those eVars are set up with an attribution mode so that there is no need to set them on an action, they will maintain the value from the page without being set...

Are you are logged into your Debugger (since the names of your eVars is shown I would think you are, but it can time out), try turning on "Show post processing hits", to see if those values are being maintained by the eVar retention:

[dk14]

From the screen shot. All the evars (except 28) are being collected correctly and I can see them in AA. This is where my main confusion is. Because things are set up correctly to collect data, but its that one field.

Here is the Page Load rule

isPageView is set to 1

and the Link Name & Link Type are blank.

We do also have the click event that fires, which evar28 is blank for as well, but I haven't check to see if we are populating that field for a event. 

For the Post Processed, the columns just remained blank. My example had data from about 45 minutes ago. 

[Jennifer_Dungan]

Try turning on "Show post processsing rules"...

If you are seeing data in Adobe for those calls, it means the eVars are maintaining the previously set values and carrying them forward..

See my message below about how eVars work.

But for clarity, let's use an example:

Page 1 > Page 2 > Page 3 > Page 4

• Page 1 loaded
  • eVarX is set (eVarX has a Visit expiry)
  • In your debugger you will see eVarX in the call
    • In Adobe you will have eVarX value and Instance of eVarX metric
• Page 2 loaded
  • eVarX is not set on this page
  • In your debugger, you will not see eVarX in the call
    • In Adobe, because eVarX is set to a Visit expiry, the last value set for eVarX will apply to this page view
    • You will have eVarX value, but you will not have the Instance of eVarX metric (as the eVar is not set, only carried forward)
• Page 3 loaded
  • eVarX is set with the same or different value
  • In your debugger you will see eVarX in the call
    • In Adobe you will have eVarX value and Instance of eVarX metric
• Page 4 loaded
  • eVarX is not set on this page
  • In your debugger, you will not see eVarX in the call
    • Again, the last value of eVarX will be carried forward to this page view
    • You will have eVarX value, but you will not have the Instance of eVarX metric (as the eVar is not set, only carried forward)

If you look at the post-processed values, any eVar maintained in this manner will show the value that Adobe is assigning to the page view based on the eVar expiry.

[dk14]

Just for clarification, it is not the third call that was the issue. That was probably the link click tracking. 

It is that evar28 is not being populated at all, even though it is showing in the debugger across all the page loads.

[Jennifer_Dungan]

Ok, so you do have a value, but you are not seeing it in Adobe... 

Do you see eVar28 in general as an option to pull into your reports?

Again, please check the post-processed values... it's possible that there is a processing rule after the data is sent that is clearing out the value... but without knowing if this is an issue of "you can't find eVar28 to add to your reports", or "we have eVar28, but there's no value, its going missing" we will have a hard time pinpointing the issue....

[Jennifer_Dungan]

Is the dimension enabled? You can send data to a prop or eVar (and see it in the cloud debugger), but if that dimension isn't enabled in the Report Suite it won't show up... and technically won't be collecting data until its enabled (though strangely, anything previously enabled that is disabled will continue to collect data)...

Another possibility is that the dimension is enabled, but that dimension hasn't been added to the permissions for the users in the Admin Console for the suite.... even if you are an admin, you will not see any items that have not been added for view permissions.... 

[dk14]

We currently have our primary site using the old Adobe processing rules .
This populates the eVar correctly which I would assume that means the eVar is set up correctly. 

Unless there is something that needs to happen to allow the variable to collect data from the Adobe experience data collection rules.

[Jennifer_Dungan]

No... from the sounds of your original post, it sounded like you were adding some new dimensions and you weren't seeing them in the reports.. but based on your screenshot, you aren't seeing them in the Cloud Debugger.. but this may not be an issue if your implementation relies on eVar expiries to maintain values... or if these are actions and they original implementation was designed to not send those values on actions.

I am going to borrow this from a friend on how to describe the difference between props and eVars...

eVars are like chewing gum on the side walk... once you step it in, it stays on your shoe until you dislodge it....

Props are like a banana peel, you step on it with an immediate action, then you move on leaving it behind. 

[Rajeshwari]

Hello @dk14 ,

from the conversations it seems that there is processing rules enabled to your eVar28 in report suite where you are sending the values and because of this you are seeing value in debugger but not AA report. So request to check the enabling status of  processing rules for eVar28.

Hope this will help.

[dk14]

Can you please let me know where I need to look for this, because when I look it in the conversion variables I see that it is enabled

[Jennifer_Dungan]

Processing Rules are found in:

Admin > Report Suites
(Choose Suite)

Edit Settings > General > Processing Rules

However, there is no way for us to know which rule could be impacting your eVar, you will have to check all of them.

IF you don't have any rules set up, it could be manipulated with a VISTA rule, but those are set up by Adobe (you cannot access them yourself).. so you will need to contact support.

[dk14]

Do these processing rules get applied to Adobe Experience Platform collection as well. 
We were told that these rules are only applied to the older DTM processing

[Jennifer_Dungan]

Who told you that? Processing Rules are applied after the data is received from the data collection (it doesn't matter if that is DTM, AEP, or WebSDK).

In fact, Processing Rules is the only way I know of that Mobile App data (using the AEP SDK) processes context variables into prop, eVars and events... 

[dk14]

Ok, Thanks Jennifer. 

Maybe I have a lot more reading up on this. I had assumed that because AEP was assigned a value to the eVar with in the AEP rules, that was what was setting the value to report on. 
Maybe there is a step in the process that I am missing. 

But if there is another step under the Report Suite processing rules, I need to find where that is because I can't see where it would be happening. 

Here is the AEP rules
I am highlighting 2 examples Evar11 works, evar28 does not

And here are the processing rules which were set up originally for our first site (that hasn't moved to AEP yet, but both sites are going to the same report suite)

Or is that the issue, that this rule could be overwritting the data when it shouldn't be.

[Jennifer_Dungan · Accepted solution]

Even when you set the eVar or Prop or whatever, you can override those values in Processing Rules...

Not an "override" per se, but Processing Rules are sometimes used to set generic values to eVars (rather than sending it from Launch)... like setting an eVar to the User Agent value, or replicating values without taking up length on the Data Collection bundle.

Rule 28 looks like your culprit...

So Looking at the first Rule 10, likely none of those conditions are met, so the rule doesn't trigger.

But Rule 28, one of those conditions must be "passing", and I am sure that page.name is not being set any longer, which means it's an empty value... and that empty value is overriding the value you are sending from Launch...

You should really review ALL the Processing Rules... if they aren't needed you should remove them all so that other parts of your tracking isn't impacted. Just because Rule 10 isn't triggering now.. doesn't mean that there is some scenario where it might trigger... Keeping your Processing Rules clean and only keeping rules that are needed there is going to be much better for your implementation.. and IF you need to use Processing Rules in the future, the person who adds new rules will only have to deal with active content, and not historical leftovers which are now essentially garbage....

[dk14]

Oh my goodness. Thank you, I will do some testing tomorrow, but that looks like that is the reason. 

We were told by the team that originally set up AEP that the old processing rules will not apply to it. And in most cases they don't because the data on the old processing rules is not set, so won't do anything.

BUT, when looking into that rule (it was actually another rule, the rule I screenshotted was for our App), there was a condition of 

So it will be the global Page URL variable, which means it was then updateing our eVar28 with blank data. 

[Jennifer_Dungan]

Ahh.. ok... I think I am starting to get a sense of what happened...

We were told by the team that originally set up AEP that the old processing rules will not apply to it.

---

So you weren't told that Processing Rules didn't apply at all, and the person that told you this assumed that the rules wouldn't apply because they figured none of the conditions would apply.. 

Unfortunately, some rules have conditions that are passing, and because the context variables being used inside the rule don't exist, they are being treated like an empty string... 

In theory, that person was mostly right, those rules shouldn't apply, and most of them probably aren't... but there are some much more generic rules that are triggering.

In particular that new rule you posted, looking at "Page URL" which is a standard value that applies to every page in your site. 

When dealing with apps, I ALWAYS add a condition to my apps which is "a.appid is set" and I don't use "ANY" but "ALL" Rules must apply.

This ensures that my app rules will never impact the website data....

You might want to try the same... since you can't delete your app rules, but you also need to make sure that you aren't breaking your website.