As the title -
I am looking to capture the adobe tag name that fires on a page as a prop variable. How can I go on about this?
Solved! Go to Solution.
Views
Replies
Total Likes
Launch has a data element for the rule name. However, the key is as reminded by others, there can be multiple rules fired before a hit sent to Adobe Analytics and you need to think about how to handle multiple names in the prop. Or if you are certain that in your implementation each rule fires a hit, then you are safe to go simple.
Depending on your implementation, you could have multiple rules triggered...
Some people use multiple rules to set the different dimensions, then have one final rule that sends the beacon....
However, if you aren't using that, and know that send beacons are always paired with set variables within your rules... while I don't know of any automatic way to pull this data... you could easily add to your "set variables" portion of your rules, a prop that is hard coded to a value (that indicates the rule name)...
This will require that your team is aware that if they copy rule and make modifications, they will need to manually edit the value of the prop. If the rule name is changed, they should also update this hard coded value.
I did also find this, but I have never tested it: https://experienceleague.adobe.com/docs/experience-platform/tags/client-side/satellite-object.html?l...
Under "Debugging Functions", I see some code to read the event.rule
You could try writing some custom JS in your rules custom code area to try and using these debugging options to populate a prop with the value (rather than logging it to the console).
If you are familiar with Javascript Coding, with some trial and error you can probably get something working... or ask your developers to help.... if those options don't work.. the manual process is the safest option, but like all manual processes, it's highly reliant on people following that process and it's subject to human error.
Just to add, rules can also go very long, props have a maximum of 100 bytes (100 characters). So you will need to figure out how you would go around that. Yes, you can technically use eVars, but you will run into 255 char limit as well.
So if you had your rules:
LB50 - Page View Beacon, you could only fit about 4 other rules (including commas if you are going to use a list prop)
May not be a practical solution.
I guess the question comes back what will you do with the Rule Names. Once you know what rule fires what will you do with it? Audit and remove rules? etc. There might be other solutions instead of setting it as a prop/evar
I am thinking about capturing the rule-names for Q/A purposes. This is to prevent rules that should be running for Product A from not firing on Product B and so on.
My expectation is to capture a rule name on hit-level instances so one rule name per hit in the prop. We can update our rule names to fit the 100 Ch limit which isn't an issue.
So if I visit a page and then interact, the rule that sends the beacon should be captured.
Views
Replies
Total Likes
If this is just for QA purposes, do you need to capture this in a dimension? There is a satellite debug that will show you ALL the rules that are fired during any trigger... so if there are multiple rules, all the rules, and the order they are fired will appear in your browser's console when debugging is enabled..
This will mean you don't need to do any work to make those values track... Unless you are actually using those values in Workspace (after waiting an hour for the data to appear) to actually built testing reports to correlate the data captured to the rule(s)....
I am not trying to dissuade you if you think this will be of benefit, just throwing out the debug option as an alternate option to try (which you can use right now without any code modification or dimension setup).
You can simply enable debug mode by running this JS in your console:
_satellite.setDebug(true)
And to turn it off:
_satellite.setDebug(false)
Thank you for the reply. I utilize the _satellite.setDebug(true) during my Q/A but the purpose of having it in a prop is to debug for cross-domain tracking and auditing data integrity as opposed to Q/A for implementations.
No worries, like I said, this is an option you can use now, but if tracking the rule in a dimension has benefit to you and your team, then absolutely go for it!
I have not had to write code to do such a thing, and I am still trying to catch up on being away for Summit... but if I have a chance, I will see what I can do from a code perspective....
Views
Replies
Total Likes
Launch has a data element for the rule name. However, the key is as reminded by others, there can be multiple rules fired before a hit sent to Adobe Analytics and you need to think about how to handle multiple names in the prop. Or if you are certain that in your implementation each rule fires a hit, then you are safe to go simple.
Well that is handy!
Views
Replies
Total Likes
Thank your reply - this is what I was looking for.
We wanted to find the method of capturing the adobe rule name first prior to revamping our rule names.
We intend to shorten the names and apply a processing rule to parse the information in adobe analytics.
Views
Replies
Total Likes
Views
Likes
Replies