.NET Tracker - Set domain_sessionid

The .NET Tracker contains methods SetNetworkUserId and SetDomainUserId, but I can’t see any way to set domain_sessionid.

Is there any way to set this value?

Hi @Michael_Bailey
The .NET Tracker sets this when using the ClientSession object. It’s primarily used when using the .NET Tracker in a client side implementation (such as a desktop application, Xamarin mobile app, or similar).

The docs for it are here.

At this time there is no manual way to set this, if you want to track your own session information, I’d suggest creating your own session schema and attaching it as a context to your events.

Hi Paul,
we run into the same problem. Setup:

  • website - primary data collection and sessionization client-side via browser tracker
  • .NET SDK for some server-side events
  • domain_userId, network_userId and domain_sessionId is getting passed from client to server to map them in server-side events

Since the domain_sessionid is an essential dimension in the web data model, it is crucial to have it in order to model the serve-side events properly. Working with the ClientSession object from the .NET SDK doesn’t make sense in that case.

In my opinion, conceivable solutions would be:

  1. As you mention, a custom context to append the domain_sessionid to server-side event. Would it be possible to map the domain_sessionid into the “native/atomic” domain_sessionid field via JavaScript enrichment?
  2. Feature request for a SetDomainSessionId method on the subject (best solution IMO;)

Thanks in advance for your help.
PS: as you know - we are a BDP customer but I think it makes sense to follow up on the topic here, instead of a support ticket.

Hi @davidher_mann,

With the current state of affairs, as long as you’re tracking the domain_sessionid in your server-side events, you can integrate them with your web model as follows:

Inner join the sessions_this_run table to your atomic table on session_id = your session ID field. Limit the query on MIN(collector_tstamp) - {a few hours} from sessions_this_run The few hours is just a buffer in case some events arrived late. (You can also use a where clause but that’s likely slower).

That will return the set of server-side events in your data that are relevant to this run. Aggregate them, and handle them in your model as desired from there - same way you would for any custom module in the model.

You could also go lower tech and just select all server-side events from MIN(collector_tstamp) - {a few hours}, I think that’d achieve the same thing.

The argument against populating the domain_sessionid field from server-side is that this field represents a cookie value set from the web, and is exclusively populated by the JS tracker - so there’s some conceptual misalignment if it can also be populated manually.

As for passing the data to the server-side, I think this would always have to be part of the solution, not sure the .NET tracker could easily grab the value automatically from the front end.

I don’t have any skin in the game (am on a different team), but I am curious - if we were to change the data models so that you could handle server-side data within the incremental web model logic, would that solve your problem?

(Edit: I suspect you might already be aware of the data model pattern, but for others searching, this might be useful :slight_smile: )

1 Like

Hi Colm,
thanks a lot for your quick answer and the modeling hints! Two thoughts:

  1. Even though it is possible to build a workaround via data modeling and a custom context, it feels like an unnecessary complexity in the raw tables if the domains_sessionid is null for some events.
  2. I see your the conceptual misalignment point regarding the domain_sessionId, but from my perspective the differences to the SetDomainUserId and SetNetworkUserId methods is small, e.g. domain_userId is set by the tracker as well, network_userid is set “exclusively” by the endpoint.

I might be wrong, but I assume that the .NET SDK is not designed to work in a client-side / server-side combined setup?

If I understand this correctly, you can now set a new Subject per event.

Tracker.Instance.Track(IEvent newEvent, Subject eventSubject = null);

I added this in v1.1 (in July 2021, so after the last time I posted on this thread). The Subject object lets you set all the properties you need: Subject | Snowplow Documentation
You just need to find a nice way to build the subject for an incoming request on your server that can then be used in all tracking for that backend request.

Hi everyone,
I think there is a misunderstanding about what our problem really is (I work with David).
We are trying to tie the events together using the domain session ID BUT we have no way of setting the domain session id on events that are sent from our backend i.e. from the .NET tracker. The subject, that is passed to the Track method, does not allow us to set the domain session id.

We are not struggling with passing the session ID to the backend nor are we trying to set it manually for frontend events.

1 Like

The ClientSession object of the .NET tracker seems to generate a domain session id automatically. But we want it to match with the session ID in the frontend. The ClientSession object can also only be passed to the singleton tracker at startup and not with every event which would be necessary for our .NET server application.

The Subject class has a SetDomainUserId(string); function. This Subject can be passed to every Track call. Doesn’t this allow you do do what you need?

Subject s = new Subject();
s.SetDomainUserId("domain-id");
Tracker.Instance.Track(new PageView()
    .SetPageUrl("www.example.com")
    .SetPageTitle("example")
    .SetReferrer("www.referrer.com")
    .Build(),
    s);

Oh dear! I need to learn to read better :person_facepalming:

Sorry. You are correct, the domain session id isn’t on the subject, but as an apology… let me fix that for you :wink:

2 Likes

Great! Thank you for the quick fix!

1 Like

I guess you’ve already noticed but the release is officially out now! Just a small one to get this out quickly for you - Snowplow .NET Tracker v1.2.0 released

2 Likes

Hi,
thanks a lot for the quick release Paul! My colleagues deployed our implementation couple after your release. SetDomainSessionId method works like a charm.

1 Like