This is just a guess, Ruchitam, but if the value in the code is lower
case, and in the debugger is lower case, but it is upper case in the
report, maybe there is a processing rule or VISTA rule on the report
Hi, Balakrishna.This could be a number of things. First verify that the
date range for the report you are looking at includes this visit (I
usually forget that part). Second lets verify that the variables are
being sent to the correct report suite (if it's staging or production).
If that all checks out, you should know that it takes a while to process
eVars, so if you do a test page view, then go straight to the report,
you won't see it yet. I would wait an hour. br,Lorrie
I'm not positive of the limitations on this, but it has been my
experience that you can't add data to the past, it will be set on date
you run the call. I asked in-house and we have a couple of ideas. First,
you can create an adjustment event an upload it against the same
transaction id. Then you create a calculated metric to subtract that
event from the price, and then use that metric for price from now on.
The adjustment event would be set as positive and your calculated metric
will subtract i...
We should move this discussion out of DTM and into Analytics if we
continue beyond this comment. Your prop will expire on page view so if
you want the list to match on instances it needs to expire on page view
I agree. Or maybe simple database size? It’s volume of data stored
andmanipulated not server calls. We can send every event separately and
notincrease the record sizes.On Sat, Jul 14, 2018 at 11:14 PM
My understanding is that the list vars (list1, list2, list3) follow the
same basic expiration rules as eVars. So if a list var is set to expire
on the visit, then any value assigned to that var during the visit will
persist until the visit expires. If it is set to a specific time period,
like month, day, 5 days, etc, the value assigned to that list variable
will persist for that specific time period, beyond the visit.