according to my knowledge it seems like it is not possible to set a page url on a SelfDescribing Event in the .NET Tracker. As a result, all page url related atomic columns would be empty. Is that correct?
I case of a hybrid frontend / backend tracking setup that’s unfortunate. Obviously it can be fix via data modeling / a custom context – but it’s cumbersome. Just because events were sent via backend (.NET) doesn’t mean they don’t happen “on a page”. If I am right, I would be interested why it is not possible to use the arguments from Track(PageView) e.g. SetPageUrl on events.
Example case
Measurement of login validation in an oAUTH sign-up (common identity provider solution):
Client side / JS: page_view, form events
server-side/ .NET: validation results e.g. failed login reason
We are in the process of transitioning from using the atomic fields (such as page_url) to representing information using context entities as they are more flexible. However, this is an ongoing transition, so we don’t have all the parts in place yet.
I think an easy workaround to let you set the page_url atomic property in self-describing events would be to subclass the SelfDescribing class and override the GetPayload() function. There you could add additional properties to the payload object. See here how the PageView event assigns the page URL and title properties.
I can add some more context - I don’t remember why this is the case, but I do remember encountering similar use cases.
If you wanted to avoid overriding the method then there’s a pattern that can be followed - however it doesn’t necessarily make things simpler in the way you desire. I’m just addding it here in case it’s helpful.
The typical pattern I’ve seen for this requirement is to use the web page context to assign page view IDs, retrieve the id using a callback, pass it to the server and attach it to server-side events.
This comes with the advantage of allowing more granular analysis, since you don’t just identify the page, but the instance of the page being viewed. I appreciate the feedback that it’s harder to model if you can’t set the atomic field - if we assume that you use our web model, then it’s a bit easier to handle this way, since you just join on the page views table once.
I still think you make a valid point, it’s definitely quite awkward if querying atomic data - as he mentioned, matus’ team has been ironing out this kind of wrinkle across the tracking estate.
(PS. I don’t work on trackers or modeling, FYI - I just have some experience of similar use cases that I thought might be useful to know about)