Web SDK Click Tracking - referencing 'this' object?

[jlinhardt_blueAcorn]

Hey all,

I'm back with another question that I'm hoping you might be able to help me with.  I'm trying to figure out away to reference the javascript 'this' object while writing code within the Web SDK Extension's "On before link click send callback" custom code screen.

If I add a console log for the 'this' object while in a click rule (based on a CSS selector), I get a valid response

custom code used in my click rule:

console.log("nav click rule: this.href");
console.log( this.href );

Response I get in my console for this click rule:

nav click rule: this.href
https://www.blueacornici.com/Commerce/

So that works, when I'm working in the rule.

But if I try the same thing when I'm working in the "On before link click send callback" custom code screen, I get an error message.

The custom code i used:

console.log( "checking for link this.href" );
console.log(JSON.stringify( this.href, null, 4 ));

my results

checking for link this.href
undefined

So it appears the 'this' object is not available when working in the "On before link click send callback" custom code screen, but again it is available when working within a rule triggered by a css selector click.

Does anyone have any ideas on how to reference the details of what the user clicked on while working in this section of the Web SDK?  please provide specific code example so I can try to backwards engineer a solution.  Thanks!

follow up on 02-27-2024

per the documentation, there is supposed to be an object called 'clickedElement' when using this click callback back solution.  https://experienceleague.adobe.com/docs/experience-platform/edge/fundamentals/configuring-the-sdk.ht...

but when I try to console log for that element, I get another error message saying it doesn't exist.

Not sure what I'm missing here?!

[jlinhardt_blueAcorn · Accepted solution]

Okay, I think I figured it out. 

There is a 'content.clickedElement' object available in the On before link click send callback custom code screen within the Web SDK.  I swear it wasn't there last week when I first checked, but who knows. 

So if you need to access what the user clicked within this custom code interface you can add something like this:

web SDK "content.clickedElement"
result: <a href=​"/​Experience/​">​…​</a>​

web SDK "content.clickedElement.text"
result: Experience

web SDK "content.clickedElement.href"
result: https://www.blueacornici.com/Experience/

web SDK "content.clickedElement.parentElement"
result: <li tabindex=​"0" class=​"nav-drop nav-closed" aria-expanded=​"true" data-navitem=​"bg-experience">​…​</li>​

web SDK "content.clickedElement.region"
result: nav

To grab "region" (since that's not a typically link attribute), I actually created a function that traverses the DOM tree looking for the closest 'id' value.  That function looks like this:

// Find the closest ancestor element with an 'id' attribute
var region = findClosestAncestorWithId(content.clickedElement);
console.log( "web SDK content.clickedElement.region: " );
console.log( region );

// Function to find the closest ancestor element with an 'id' attribute
function findClosestAncestorWithId(element) {
// Traverse up the DOM tree until reaching the document root or an element with an 'id' attribute
while (element && element !== document) {
if (element.id) {
return element.id; // Return the 'id' attribute of the closest ancestor element
}
element = element.parentNode;
}
return "Body"; // Return body if no ancestor element with an 'id' attribute is found
}

This isn't exactly what the 'clickDataCollection' does out of the box, but the at least now i'm not limited to only the 5 variables that the 'clickDataCollection' xdm object already provides and that was my goal.  

Final thoughts:

For most Web SDK implementations, i would expect to use the recommended EDDL or the ACDL approach which means most of the variable mappings will occur within rules.  But for implementations that have to leverage the Adobe Data Collection 'native' browser listeners (i.e., page load and css selectors rule event triggers), it's nice to have options when it comes to accessing the element the user clicked on.

[NimashaJain]

Thanks @jlinhardt_blueAcorn for posting the complete solution