Best way to tag every clickable element on the page (retail site) | Community
Skip to main content
Level 2
July 31, 2024
Question

Best way to tag every clickable element on the page (retail site)

  • July 31, 2024
  • 3 replies
  • 3795 views

What is the best practice to tag every clickable element on the page? Especially on the checkout page where there are payment options plus delivery information etc. Right now our site A triggers link call for every interaction by the customer. I dont think this is the best way. Is there any guide (example site for ecommerce) that we could refer to see how product page, cart page, check out page should be tagged? Many thanks!

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

3 replies

Jennifer_Dungan
Community Advisor and Adobe Champion
Community Advisor and Adobe Champion
August 1, 2024

I agree, that doesn't sound efficient... also, what happens as users mis-click, go back and change options, etc before continuing to the next step... that would be a lot of useless "dither" values that didn't account for anything.

 

There is no "one size fits all" solution, but for me, when the user chooses to continue, I would bundle all the selected information onto the single "continue" action... this would give me their actual selections, on a single server call.

 

I would also create a relationship, using s.products, between the product page, add to cart, checkout, success, etc....

 

On the product page, I would track the key info that I need at that level... the product identifier is the "glue" that will hold together all the touchpoints.

 

On the product page, I might have a few merchandising eVars relevant to that product and page, and I might also set up a custom numerical event for "product page". (I say this because I might use "prodView for all views of the product from product page, to recommended content, to other people also bought, etc...)

 

Then, when the user "Adds to Cart", I would use s.products with the same product identifier, the scAdd event, and again relevant merchandising eVars....

 

The Cart view, which may have multiple products, I would track all the products with the appropriate identifiers, the scView, and again relevant merch eVars....

 

The checkout, again, all the products would be tracked with their identifiers and merch eVars, and the scCheckout event

 

And of course on success, I would have the product identifiers and merch eVars, the Orders metric, and also the quantity and price values from the purchase.

 

 

In my reporting, I would use the product identifiers as my breakdown, and have the relevant columns: Product Page, Add to Cart, Cart Views, Checkouts and Orders.... 

 

Those values you spoke of may be standalone values associated to the entire order (payment options, in store/delivery, etc), or specific to each product making them part of your merchandising eVar content per product....

 

I know this is a bit vague, it's hard to provide specifics without seeing your pages / flows.

Level 2
August 1, 2024

We do want separate evars, events so that we can get those variables for downstream reporting so activity map will not work. We also want to track every element to understand the user's engagement. Is there any example e-commerce retail site (based on app measurement implementation) that anyone can point me to see what is the best practice of tagging should be for product page > cart page > check out page? Thank you!

bjoern__koth
Community Advisor and Adobe Champion
Community Advisor and Adobe Champion
August 2, 2024

No, I am definitely not suggesting that you send a server call on each interaction... that is what we are trying to avoid...

 

I am suggesting that you create custom code (that fits your needs), that on each interaction, a value is appended to a variable on the page... when the user clicks to continue to the next step/page/whatever, you send a single server call at that time, passing in the variable that has been creating a list of all your interactions.

 

So when the page loads, you declare a variable (at the window level so that you can continue to interact with the same object, and keep building it up):

window.elementInteractions = [];

 

 

Then when the user interacts with Element 1 and chooses a first value, you run a custom script to update the variable with this information:

window.elementInteractions.push("element 1:value 1");

 

Then the user interacts again with element 1 and chooses a second value:

window.elementInteractions.push("element 1:value 2");

 

Now the user interacts with element 2:

window.elementInteractions.push("element 2:value x");

 

and so on....

 

At this point, your object (array), should have three pieces of info:

["element 1:value 1","element 1:value 2","element 2:value x"]

 

When the use submits, you can take this object (array), and flatten it down to a single string:

var finalInteractionString = window.elementInteractions.join(",");

 

which will turn it into:

"element 1:value 1,element 1:value 2,element 2:value x"

 

Pass this into your list (which will use comma as a separator), so you will end up in Adobe with three separate rows of data:

  • element 1:value 1
  • element 1:value 2
  • element 2:value x

 

One server call, all your collected interactions passed on the same call.

 

However, if the user leaves the page, this info will be lost...

 

You and your business have to weigh the pros and cons of tracking each interaction as it happens (multiple server calls, all separated from one another), or trying to collect the interactions and pass in a single call.

 

You might even be able to listen for the user "trying to abort the page" with something like the beforeunload event (https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeunload_event)

 

But you need to be careful as this will fire on the 'happy path" as well as the quitting path...

 

Again, I recommend getting a developer to help support this, this is a completely customized solution... since Adobe is not designed for this out of the box.....


Fully agree with @jennifer_dungan 

In my opinion "we want to track everything" is not a tracking strategy that I typically see in companies with low Analytics and data maturity. This approach leads to polluted report suites and is typically only serving vanity KPIs without actual meaning (number up is good, number down is bad, and then what?! What business question are you going to answer with this, dear stakeholder?)

 

I personally prefer a clean definition of KPIs and how these are captured through events, props and evars. And you can always extend it as needed in the future if requirements change.

 

In your case, you surely have a good set of requirements in mind. However, I would ditch everything that happens in between the page load and the form submit or actual last action on the page when it navigates away.

 

Just ask your stakeholder one simple question: "What are you going to use all the different data clicks for, when the actual important bits of information are what the user actually chose at the end???"

If they want to understand if people got annoyed whilst using the website, rather consider using a session recording tool like ContentSquare where you can replay individual sessions and see where users struggled with the UX. Looking at the sum of all interactions will not give you any meaningful insights and just adds to the background noise data of your report suite.

 

As you can read, this is a highly emotional topic for me and I have been fighting this nonsense for a long time xD

 

P.S.

Maybe worth mentioning that the shiny new ActivityMap for WebSDK has event grouping which is supposed to bundle internal clicks and send them on the following page as single request.

Similar to what GA4 is doing.

 

Yet again, this is not supported with AppMeasurement. AppMeasurement has event buffering which works in a similar way (stores image requests locally and releaes them on the next page), but is not reducing the actualy number of requests made.

 

Cheers from Switzerland!
BShan
Level 2
August 1, 2024

At a higher level, I'd also be asking whoever you're reporting to which are the metrics that matter to them in terms of business objectives and KPI targets, and tag those up first.

After that, it would be a case of looking at which elements are the most important in terms of understanding how users are using each stage of the checkout funnel, (do they get stuck entering their address, or is the add to cart page have too many options?) and then start to tag those to capture them as indicators of user behaviour.

The metrics that track user behaviour can then help explain the performance of the KPIs/ business critical numbers, and give avenues for optimisation

bjoern__koth
Community Advisor and Adobe Champion
Community Advisor and Adobe Champion
August 1, 2024

Well technically you could use ActivityMap to capture those link clicks automatically. What will be missing is any relation to actual products on the page. This will rather give you indication on where the users clicked on the page but not what happened after.

Cheers from Switzerland!
Jennifer_Dungan
Community Advisor and Adobe Champion
Community Advisor and Adobe Champion
August 1, 2024

It depends... if each link results in a new page being loaded, then yes, Activity Map will work, if they are trying to get form element interactions (which sounds like it based on the description), Activity Map will only potentially get the "submit"... and I'm not even sure about that, since I discovered that buttons are no longer working with Activity Map..... 

Krishna_Musku
Community Advisor
Community Advisor
August 1, 2024

I lean towards the activity map tracking to track almost everything. I didn't know that button tags are no longer working with Activity Map. I checked for the documentation and found this. https://experienceleague.adobe.com/en/docs/analytics/analyze/activity-map/faq  this is last updated on Jun 27, 2024.

Only the attribute type="button" is not working with Activity Map.