Referral Tracking Analytics

[y_buccellato]

Hi everybody,

I would like to know if, similarly as in Google Analytics, I can create a USQL in Dynatrace in order to catch session started on my webpage reffered from another website (youtube, linkedin, tiktok ecc...)

Do you have any experience on the subject?

Thank you for your time

[AntonioSousa]

@y_buccellato,

The Referer header is something that Dynatrace doesn't save at the useraction level, so it would normally be said that you won't be able to do it with USQL. And it would be a good Product Idea. It should be at the session level, to say from where the user entered.

A workaround that I imagine would work is to capture the Referer header as a Request Attribute, and then pass it on as an action property. This would then be available inside useractions, and you should be able to get it with USQL.

[y_buccellato]

Hi, we are applying (trying) the "document.referrer" java script variable to UserSession and UserAction

I'm asking myself if it makes sense to configure it as a Session Properties

[AntonioSousa]

@y_buccellato,

Interesting, as I was thinking of a more difficult way, grabbing it first as a Request Attribute, and then passing it to the RUM level.

Never tried getting it from a Javascript variable... Does your solution work, or don't you get anything from your try?

It doesn't seem that it will work as a Session property, I would say that you have to do it at the user action level. But still trying to figure out how you will get the first user action in a session, and then aggregate it at a higher level.

Interesting challenge (still thinking...)!

[y_buccellato]

Ei @AntonioSousa

yeah, the idea of the variable came after reading a little bit on the internet how page are referred. Wikipedia (it) helped me this time 🙂 and one of my collegue showed me another good thread on the internet .

If you go to a web page and hit the F12 key ("developer tool") you can actually access the console and look for that js variable by writing "document.referrer":

The result will be the referral page.

That Dt config that I showed you does exactly this (I think) and what you have suggested me before I think would do the same trick aswell but pasting more attribute on the backend of those http request.

Now that I have taken my time to think about it, it does make sense that this would be a useraction properties and not a session one (unless you wanted to apply it only at the start of a session when the first useraction would qualify as an entry action but this reasoning seems too much specific and mazy).

Still the referrer is not always there when a page is called; as much as I understood depends a lot on the policy applied for the website itself (Referrer Policy: strict-origin-when-cross-origin).

I tried that by calling my webpage from a link from Linkedin and the referrer is not to be found.

[AntonioSousa]

@y_buccellato,

The Referer header has long been a source of controversy, starting with it's misspelling in the original RFC 🤣🤣🤣 (link to the first one that noticed it)

You can get the referral in several ways, but it all relates to it being sent by the client browser as an HTTP header.

One interesting first use of Referer was by search engines, where you could even get the keywords that users had searched for. That was gone a long time ago...

Referer has been implicated with some bad things on the net, including absolutely incorrect usage for authentication/security methods. It's also a great privacy risk, so I don't recommend using it for anything. Of course, like a lot of things on the net, playing with it might get some things very wrong...

And, then there is Referrer-Policy (this time correctly spelled). As a site owner, you can control how much Referer information the client browsers gets to send.

Finally, as Referer headers are set by the browser, a lot of additional rules apply. They also have to follow RFCs that tell in some cases what should not be sent (eg. in the days of HTTP, you would not receive a Referer if going from HTTPS to HTTP), and I'm almost certain that most privacy add-ons will also remove that information from requests.

In short, using Referers is tricky business...

Finally, since a Referer is based on an HTTP header, it does make sense to make use of it at the useraction level. It could be a session property though, as to find out where the user was coming from in the first place, and it would be the Referer from the first action, if it happens to exist...