adobe.com
Analytics parameter (eg. daa-ll) are getting localized #555
-
|
Hello, |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
This is expected... which is a pro and con. We are beholden to not having hidden non-localizable data. This is why we have added additional parameters like the name of the block, the type of button, and the order of the button. In the DOM Tagging + Dexter world, there wasn't a lot of context around what a particular pattern was... you had 10 flex containers and that could be a marquee, aside, whatever. This meant we used DOM Tagging to add context. The problem with DOM Tagging is that it required author intervention, which was not always predictable... thus making the data unreliable. The good news with Milo + Franklin is that you will always know the block, type of button, and order for a particular engagement. This is stable regardless of authoring... which means it's much more predictable / reliable from a reporting perspective. The downside is that if you are trying to measure engagement for "Buy now" across locales, you will have to be more creative because that text will be localized. If we were to ever pivot to wanting locale specific analytics, it would obviously be a pro. We've heard good feedback about this (from EC analytics), and not so good feedback (CC analytics) about this. The alternative is to use something like placeholders for non-localized strings, but there comes a performance penalty as a result. There also comes an authoring level of complexity... there's hundreds if not thousands of variations to what we put in our buttons that would require an entry in placeholders. There's also the Express route... which I don't advise. We think we chose the lesser of evils with our current approach, but we're happy to hear other ideas that do not have noticeable downsides. |
Beta Was this translation helpful? Give feedback.
This is expected... which is a pro and con.
We are beholden to not having hidden non-localizable data. This is why we have added additional parameters like the name of the block, the type of button, and the order of the button.
In the DOM Tagging + Dexter world, there wasn't a lot of context around what a particular pattern was... you had 10 flex containers and that could be a marquee, aside, whatever. This meant we used DOM Tagging to add context. The problem with DOM Tagging is that it required author intervention, which was not always predictable... thus making the data unreliable.
The good news with Milo + Franklin is that you will always know the block, type of button, and order for …