Settings and activity
2 results found
-
4 votes
Alex Merrick
supported this idea
·
-
5 votes
An error occurred while saving the comment An error occurred while saving the comment Alex Merrick
commented
@dejan, the beauty of the legacy editor click tracking is that it's used by our Content editors who are just technical enough to look through DOM and attempt different selectorsand preview them in the preview feed but are not technical enough to fully understand CSS and HTML.
I agree with you that it's not bullet-proof functionality but it's a critical need our team where half our experiment implementers are not developers and need to be able to have an interactive interface to attempt to do their own click tracking with some very basic html css knowledge.
Happy to chat on this. Just sent you connect to you on Linkedin
Alex Merrick
shared this idea
·
@dejan I think I understand your point now. You’re saying this was legacy functionality that automatically added items under Implementation / Events, and we weren’t aware of that behavior. In most cases, the click metrics we create are one-off and tied to a specific experiment, so our assumption was that they would apply only within that experiment rather than being added for broader reuse.
With that clarification, this isn’t a critical issue for us, but it does feel like an area worth revisiting. It’s not very practical for us to create one-off events or saved pages under Implementation for every experiment when we don’t expect to reuse them. At enterprise scale, that quickly becomes difficult to manage across systems and processes.
To add some context to how we work today: when we create experiments, activation is always done via URL, not Saved Pages, specifically because these are typically one-off experiments. The challenge with following the documentation you linked is that, in order to create a universal click event, we would also need to create corresponding saved pages under Implementation just to support a single experiment, which isn’t realistic for our use case.
I’m not sure if this falls directly within your scope, but I wanted to flag it in case support for more one-off or ephemeral implementations is being considered.
Happy to log that as a seperate feedback/idea