I see the documentation for filtering link-tracking. Track Links Using the Adobe Experience Platform Web SDK | Adobe Experience Platform
We want to keep the download links and exit links for automatic links tracking in the WebSDK and disable custom links. We are not finding the custom links helpful so want to not capture them. We do want to capture Activity Map values on the resultant page.
Does anybody know what the code for that would look like?
AppMeasurement code automatically sets the exit link to the "destination url" and also sets the "page url" of where the exit link was clicked on. WebSDK sets the exit link to the text of the link and does not set the "page url". We are going to have to play with this to make sure to send in the page url.
Solved! Go to Solution.
Views
Replies
Total Likes
Within the Experience Platform Web SDK extension there is an option to turn on automating link click tracking...
When this is selected, the default behaviour is to collect literally every single link click (not just exit links and downloads)
However, there is a way to make it exit link and download specific. You need to add a code snippet at top of the "On before link click send" callback (this is a bit like the equivalent of putting something in doPlugins in the old appMeasurement.js)
The code snippet is:
if (content.xdm.web.webInteraction.type === "other") {
return false;
}
What this does is it detects when it is not exit or download (i.e. it is "other") and returns "false", which disables the web SDK from sending the data.
NOTE: this only disables the automatically generated clicks classified as "other"; fortunately it does not disable any manually generated ones that you may have created using the send event that also pass the value "other" in the same xdm property!
Although it is not very clear, the help article that specifies this is here:
Track Links Using the Adobe Experience Platform Web SDK | Adobe Experience Platform
(Help article states: "Adobe recommends returning false
for the link clicks that should not be tracked. Any other response will make Web SDK send the data to the Edge Network." - you have to work out this translates to the above)
Bonus information - Exit Link Tracking:
Similarly to the old analytics extension, Web SDK will automatically treat any link that goes outside of the current domain as an exit link. The old Analytics Extension used to let you black list additional domains that you didn't want to treat as exit links. This functionality does not exist in the same way in Web SDK. If you want to prevent additional domains being treated as exit links you now need to do this in code, again returning "false" in the "On before link click send" callback.
Maybe I am missing something here... but custom links are all coded and triggered in Launch.. if you don't want those, wouldn't you just disable those rules?
Custom Links aren't automatic the way Download or Exit links are... the only disabling you should have to do is to stop running any s.tl calls....
Views
Replies
Total Likes
You would think that, but anything with an anchor tag is getting sent automatically as a custom link if they are not exit or download links.
We definitely did not code the ones that we are seeing.
The custom links that we have coded are working as expected.
Views
Replies
Total Likes
That actually sounds like a bug in the implementation... there is no way clicks like that should be triggering additional calls unbidden... this will inflate your server calls.
I am not on WebSDK yet, but given how the contracts and pricing structure is based around server calls (s.t and s.tl) what you are describing would almost double your server calls...
I think you need to investigate the cause of those extra tracking hits....
You could probably run an s.abort for custom links, but this would then also affect your real custom link tracking, and that wouldn't be good.
(inside doPlugins)
if (s.linkType === 'o') {
s.abort;
}
But finding the root of the issue would allow you to properly prevent the calls you don't want, while allowing the ones you do.... this code here will still have the code run, but will stop the execution at the last minute (for all custom links, including the ones you specifically coded)
Views
Replies
Total Likes
There is no "s" object and doPlugins callback in the WebSDK, but a different version for the same result.
In the WebSDK extension and under "Data Collection", you can add some custom code for the "on before link click send callback where you determine the custom link type and return false if other to abort this particular custom link click.
return content?.xdm?.web?.webInteraction?.type!='other'
above example is there is no other logic in the callback and simply return, you may have mode code if there is any other logic required within this callback.
However, Activity Map relies on this custom link click to provide information like link "name" and link "region". Disabling this may have impact to the Activity Map data.
Good to know about the s object..
However, there is still no way that WebSDK should be automatically tracking ALL clicks automatically... that behaviour would blow most companies budgets out of the water... and given that is not even a recommended practice any more.. it makes no logic sense for Adobe to automatically force those extra server calls..
The best solution is still to find the root of the issue, rather than try to create code around aborting the calls late in the execution of the script....
Views
Replies
Total Likes
Within the Experience Platform Web SDK extension there is an option to turn on automating link click tracking...
When this is selected, the default behaviour is to collect literally every single link click (not just exit links and downloads)
However, there is a way to make it exit link and download specific. You need to add a code snippet at top of the "On before link click send" callback (this is a bit like the equivalent of putting something in doPlugins in the old appMeasurement.js)
The code snippet is:
if (content.xdm.web.webInteraction.type === "other") {
return false;
}
What this does is it detects when it is not exit or download (i.e. it is "other") and returns "false", which disables the web SDK from sending the data.
NOTE: this only disables the automatically generated clicks classified as "other"; fortunately it does not disable any manually generated ones that you may have created using the send event that also pass the value "other" in the same xdm property!
Although it is not very clear, the help article that specifies this is here:
Track Links Using the Adobe Experience Platform Web SDK | Adobe Experience Platform
(Help article states: "Adobe recommends returning false
for the link clicks that should not be tracked. Any other response will make Web SDK send the data to the Edge Network." - you have to work out this translates to the above)
Bonus information - Exit Link Tracking:
Similarly to the old analytics extension, Web SDK will automatically treat any link that goes outside of the current domain as an exit link. The old Analytics Extension used to let you black list additional domains that you didn't want to treat as exit links. This functionality does not exist in the same way in Web SDK. If you want to prevent additional domains being treated as exit links you now need to do this in code, again returning "false" in the "On before link click send" callback.
Thank You!
Views
Replies
Total Likes
Andrew,
This worked beautifully. Thank you very much!
Your description was perfect and probably should be added to the Track Links documentation.
Hi Andrew,
We tried to do this for Exit Click call's so that we can blacklist some domains so Exit Click Call does not get triggerred for this domains but this code it not pausing the Exit Click calls for them.
If anyone has worked on it, share so documnent or code.
Views
Replies
Total Likes
Have you solved the issue with Web SDK sending the exit link name instead of the destination URL?
Is there a way to get both "exit link name" and "exit link URL" without the custom event implementation?
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies