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!
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
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!
Unfortunately, you cannot really track every moment, without "tracking every moment", and that involves server calls.
My suggestion was to track all the "set values" on the page when the user proceeds to the next step.
As in:
You can see my notes above about the individual page / action tracking above, from Product Page > Add to Cart > Checkout > Purchase
Maybe it was unclear, have you used the Products List variable before? Or is this something you are new to? I can do a more detailed explanation of Products (I assumed being e-commerce you would already be familiar, so I kept the details very high level)
Views
Replies
Total Likes
This is fine. But how do I know that user interacted with value X (in element 1). This is needed to optimize the page element. Is there any other way to know/track each and every element of the page without triggering the server calls?
I dont mind a refresher on product list variable and on merchandising evars. Thank you so much for your detailed steps.
Also, if my link click is leading to a next page right now we are triggering a link call (other) and also a page load call. I dont think we need the link call. We can only trigger the page load call and in that call pass a variable that shows which link was clicked on. Is this the best practice? Any documentation to support this?
Sure thing...
So first, as much as I like to reduce my server call footprint to page views (and relying on Activity Map as much as possible), when it comes to core flows (like subscription / purchasing / etc) like in your case, I think you will still need to have both an action and the following page view to capture what you need.
Just so we are on the same page, I am thinking of "Element 1" in terms of "payment dropdown", or "form input for name".. i.e. something that would have a single end value associated to it... if you have a multi-select, you would need to pass all the selected values. I am not thinking of "X" in terms of something the user interacts with more of what was the value for that element.... Maybe if I could see the pages you are trying to track it would help me to frame my example data in something more than generic naming.....
Depending on the complexity of your items / pages... having a dimension for each element might be enough (i.e. you know that someone interacted with "Element 1" if you have a value in your dimension when they go to the next step). However, if someone does interact with Element 1, then removes it, it won't be tracked... I don't know if that particular flow is common for you, or something you really need to track...
If it is, I suppose you could create some custom tracking... set up an object on the window level (empty to start), every time someone interacts with an element you can add that element to a "list" formatted value...
i.e. "element1", then "element1,element2", then "element1,element2,element7", etc....
You could even create logic around de-duplicating the values... so if a user interacts with "element1" 3 times, its only part of the list once...
Now, if you pass this entire value into a hit based eVar, so long as it's 255 characters or under, nothing will be truncated. You can also pass it to a list variable, but note that duplicates will be removed by Adobe....
So in this way, you can basically create a custom solution to track all the interacted with elements (regardless of the value).
If you like the concept of the list, you could even use a "pair values" as a list:
"element 1:X,element 2:Y,element 7:,element 8:Z"
// OR"element 1:X,element 2:Y,element 7:na,element 8:Z"
or even add another value to each item for the step:
"step 1:element 1:X,step 1:element 2:Y,step 1:element 7:,step 1:element 8:Z"
// OR
"step 1:element 1:X,step 1:element 2:Y,step 1:element 7:na,step 1:element 8:Z"
You can use this extra information as part of classification rules...
Note that in these example, I left "element 7" empty (or passed "na"), you will have to see what works best for you, but the "na" is a bit easier for Classification Regex rules.... but more complicated from a "manage the window object" perspective... if you aren't a strong coder, you may want to get some developer support for this, as this is a custom solution... and before even going down that road, I suggest you run some tests in Dev/QA just passing some hard-code values and making sure you can interpret the values.
This will certainly achieve less server calls, but it does require a lot of custom code to set up...
As for the product notation, let's deal with a simple example... let's use the example of:
On the product page, you could have multiple colour / prices per colour, etc... so I would track on the Page View, only the content that makes sense:
s.products = ";12345;;;event1=1;eVar1=adobe analytics t-shirt|eVar2=clothing";
s.events = "event1";
category (not used); product id (sku); quantity (not relevant here); price (not relevant here); event1 (numeric event for "product page view"); eVar1 (name) and eVar2 (type)
Note 1: You don't have to have event1 in the products notation here for simple implementations... but IF you also have something like "other people also bought" on the Product Profile page, you may want to track the "current product" with event1 (product profile view) and the "recommended products" with event2 (recommended). Having it explicitly in the product notation ensures the correct product gets the count.
Note 2: price and quantity only map during a purchase, even if you want to track the price (assuming all the same) and quantity, these will be stripped since those are used to calculate revenue (actual sales).. if you need them here, set up custom merchandising eVars to track at other steps, like here)
Now, when the user adds the black t-shirt to their cart:
s.products = ";12345;;;;eVar1=adobe analytics t-shirt|eVar2=clothing|eVar3=black";
s.events = "scAdd";
Note, you can just add the scAdd to s.events, you don't need to tie into the s.products notation. Only the product being added to cart should be on this server call.
In your Cart view, like Product Page, you can list all the products in your cart, and use the scView event (if you have recommended content on that page, then you may need to have events in the product notation).
Similar, your Start Checkout would track the items with scCheckout.
When the purchase is complete, you can now have quantity and price in the notation:
s.products = ";12345;1;9.99;;eVar1=adobe analytics t-shirt|eVar2=clothing|eVar3=black";
s.eVar10 = "credit card";
s.events = "purchase";
Note: I am keeping the step info, such as payment with CC separate from the products, as it is global to the entire purchase, not specific to the t-shirt.
Now, in your reporting, you can pull in Products (or even your custom eVar holding the Name), and your custom event1 (and event2 if you have that tracking), all your Cart events, and your Orders (purchase) event. You can even add Revenue, which will be quantity multiplied by price...
Under each product, you can breakdown by your merchandising eVars to see the other information you collected (like colour, you will see "black", "grey", "red', etc.
You can also break down by the generic values on the purchase event like eVar10 (Payment Type) - this will only apply to the Purchase and Revenue columns.
Views
Replies
Total Likes
We have multi select values in each element . I like pair:values in list vars. Where do I pass the list vars - in the page view call (so every time user interacts with an element a page view call is triggered)?
User clicks on element 1 value 1> Trigger page load call > Pass in an evar X= element 1:value 1
User clicks on element 1 value 2> Trigger page load call > Pass in the same evar X = element 1:value 1, element 1:value 2
User clicks on element 2 value 1>Trigger page load call > Pass in the same evar X = element 1:value 1, element 1:value 2, element 2:value 1
User clicks on element 2 value 2>Trigger page load call > Pass in the same evar X = element 1:value 1, element 1:value 2, element 2:value 1, element 2:value 2
User clicks on element 3 value 1>Trigger page load call > Pass in the same evar X = element 1:value 1, element 1:value 2, element 2:value 1, element 2:value 2, element 3:value 1
Are you suggesting in this way? Isn't this incurring server call?
I will come back to the product page tagging little later.
Not able to share the actual site/url due to security concerns. Thank you!
Views
Replies
Total Likes
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:
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.
Thanks @bjoern__koth
Like you, I would only track the "final state" of what was selected... I don't care about the "dithering" a person does to get there... I am not sure how anyone would even use that information... or really care.
We can of course make a complex effort to try and track that information, but is it worth the effort? That is a question each business has to ask....
I often get requests to "track everything"... then I sit down with that person, explain the costs associated to the tracking calls, ask them how they want to see and use such information (to even see if we have a plan of a clear way to present the information, instead of just ending up with "data vomit"), I offer a plan to them that reduces the server calls and gets them a clear set of data, then ask them if they "really need everything" to justify it and get it approved by senior management.
So far, they always go with the reduced simplified plan....(bear in mind, the "simple plan" has a lot of information in our set up, and they have always been happy with the results)
I totally agree with both Jennifer and Bjoern that we should keep it simple and not try to tag everything. However, they do want to see that interaction going to downstream datawarehouse to be able to do more analysis and optimize inventory. Will push for having a trade-off.
Related question : Is there any best practice to track the delivery page with shipping information, delivery date etc? Would love to get some best practices there as well (examples).
Thank you!
In terms of delivery you are completely free to decide what's relevant to you. What surely makes sense is to not capture the delivery date but the number of days until delivery.
That way you could set up a classification to bucket these.
maybe on top the parcel service if known and whatever else makes sense to understand your business better
I am thinking of using two evars - 1/ delivery (values : pick up,ship) and 2/ payment method (values : card, other methods) and trigger success events when someone starts the delivery address, successfully completes and also another two events for payment initiation and payment success. Finally, 3/ order page. One event for successful order and another evar for all the order details. Is this the correct approach?
That sounds logical.. I know you can't share the website due to security, but it sounds like you have some good thoughts on the how to proceed.
It may take additional time, but sometimes playing with the flows and what is collected in a Dev/QA environment (even though its limited data), then trying to build a report can really help identify potential issues / scenarios you didn't anticipate, and it can spark new ideas of what to track...
In the long run, this approach can save you time and effort, because by the time it launches you already have a good sense of what you will get back.
Hi @Bjoerg Can you let me know how we can set up classifications if we know the number of days until delivery? Could you elaborate on this please?
Views
Replies
Total Likes
The delivery page is certainly a fine line scenario, between collecting relevant data, but not collecting PII...
Without knowing what is available, I would think tracking the order number the estimated delivery date (this will be stored as text, but I would track it in a standard "castable" date format for the datewarehouse to make use of), the number of days to delivery (as per @bjoern__koth), maybe a generic "location" of where the delivery is going (like not the address, but maybe the city level? to understand the distribution of where the deliveries are going)....
However, I am sure you will have other relevant fields that you might find useful... maybe number or items, and overall package weight? Maybe even your items would be classified by size... I am not sure.
HI @Jennifer_Dungan In the checkout page, could you let me know in your example above how the products variable should be tagged? I have scCheckout event to know how many times checkout was started. What other things do we need in the Checkout page?
Hi @Jennifer_Dungan Kindly let me know the answer to my question above!
Sorry about that, I must have missed the notification.
Everyone does things a little differently, and bare in mind that I don't know what sort of products you have on your site... so take this as a general guideline as opposed to a specific instruction.
In General, I would probably look at breaking down my flows like this:
Products Pages:
Have a "Product Page View" event, and collect information such as the ID / SKU, name, depending on if the view changes or is specific to each option, maybe track details about those options (colour, size, configurations, maybe even an eVar to track the "current price" even though this will store as text, etc). Focus on things that will be helpful to you and your reports... if you will never pull a report on if a t-shirt added to a cart was red or black or blue, do you need to track it? I don't know what you or your stakeholders need... that has to be decided by you.
Product Recommendations:
If the site shows a list of recommended or "other people also looked at / bought", then I would track these (again with basic details) and a "recommendation view" event
Add to Cart:
Again, any relevant info about the product when it is added to the cart and using the scAdd event. (You may also want to trigger a "cart created/opened" [scOpen] when the first product is added to the cart, but only if you think it will be helpful... you can always add it later, I would worry about getting core flows in first)
Cart Views:
Tracking the Cart Views (scView) for all the products in the cart
Start Checkout:
Again, track the info about all the products that you deem as important to track and make reports on. Using the scCheckout event
Purchase Complete:
Again, the relevant info, plus now adding the price and quantity (which will be multiplied to create your Revenue report), and using the Purchase event
Views
Replies
Total Likes
thanks @Jennifer_Dungan . Could you please elaborate the events , products variables (with an example) starting with Checkout to all the way to Order page? How can we track orders on the order page and tie to marketing channels?
Views
Like
Replies
Views
Likes
Replies
Views
Likes
Replies