Provide read-only access to some properties generated inside tracker object

[chuwy]

Recentrly we encountered few cases where users wanted to get some properties that are encapsulated inside tracker object. Particularly, users wanted to get cookieDomain and pageViewId to use in app logic. It's possible to get cookieDomain with lengthy script, but seems not possible at all for pageViewId.

I think we should provide some read-only access to at least these properties (and may be consider another properties) as getter-functions.

[alexanderdean]

Nice idea, scheduling...

[ryanrozich]

Our need for this has to do with click tracking. Currently we have our own click redirect and also have been using the javascript link tracking built into the javascript tracker. We have our script deployed across a wide variety of client sites.

We wanted to see whether the javascript tracker was counting as many clicks as our redirect so as a sanity check we took click count samples over multiple days from both our redirect and also from the snowplow reported clicks. On some sites they were close, and on other sites either our redirect had a much larger count of clicks than snowplow and on others it was the reverse. The discrepancy was consistent for the same site across multiple days, so timezones/timestamp differences between our redirect and snowplow could not explain the difference. It appears in some cases a redirect does a better job and in other cases the client-side javascript does a better job. Not sure why, my best guess is that it might have to do with other tracking scripts that the client might be running on their site.

Since we want to get the most complete count of clicks, our solution is to (a) continue tracking clicks from the javascript tracker and (b) use the clojure collector as a redirect and (c) rely on our data modeling scripts to deduplicate the clicks that appear in both.

We planned on using the web_page.id (pageViewId) and the link target URL as the key for deduplication (we only need to track unique clicks, don't need to be able to count multiple clicks on the same URL for the same page view).

The problem we ran into was that, while the link_click event from the javascript tracker will append the web_page context automatically, we will need to manually add it to the click URL so that the redirect can pick it up as a context. Since we can't get this ID as a getter-function, we are stuck. Hopefully that provides more context.

Do you have plans in the short-term to deliver this getter-function for the web_page context id? If not, it sounds like something that we could implement ourselves and submit a pull-request. It would be helpful though if you could point us to the right part of the code to make this change.

[alexanderdean]

Moving forwards to 2.8.0

[BenFradet]

The shortlist of things to expose seems to be:

• pageViewId
• cookieDomain

Are there any others I'm missing / someone wants to add?

[alexanderdean]

Ping @yalisassoon @bogaert

[bogaert]

Nothing comes to mind.

[digdeep]

A bit late to the party but session variables like domain_sessionidx will also be very useful if exposed. For non trackPageView events like snowplow_name_here('trackSelfDescribingEvent', <<SELF-DESCRIBING EVENT JSON>>);, it means most standard reporting for interaction events doesn't need a join to events just to run queries like select clicked_someting, domain_sessionidx, count(distinct(domain_userid)).

Also, users can have an option to archive unstruct type in events table as they inherit everything from events which is taxing when all you really want is some cookie info tied to the context table.

The latter is a whole separate conversation but having domain_sessionidx exposed would make managing data, just in the short term much cheaper for larger set ups that have lots of data in events and want to archive the redundant data. (think list views in enhanced ecommerce)

FWIW, this was awesome in 2.2.0:

snowplow(function () {

	// Get the fingerprint which the tracker
	// generates based on browser features
	var userFingerprint = this.cf.getUserFingerprint();

	// Get the ID stored in the first party cookie
	var domainUserId = this.cf.getDomainUserId();

	// Get all information stored in the first party cookie
	var domainUserInfo = this.cf.getDomainUserInfo();

	// Get the ID which you set for the user
	var businessUserId = this.cf.getUserId();

	doSomethingWith(userFingerprint, domainUserId);
});

[alexanderdean]

So add access to the domainSessionIndex?

[digdeep]

Yes.

[alexanderdean]

Okay let's go for it, it can't hurt...

[BenFradet]

Renamed to reflect that the discussion regarding other internal properties that need exposing should happen here.

[hilarykitz]

Hey, did this ever get anywhere?

[BenFradet]

yes cookieName and pageViewId have been exposed in 2.8.x (cf #574 and #575)

[falschparker82]

Just real quick: we'd love to have programmatic access to the session ID as well. Use case: We're tracking server sided events, (i.e. Login within our Login API, clickout through our click tracker) and want to attribute those server sided events to the correct app session. For this, we need to extract the session and propagate it to the backing services.

Currently, would be possible to access the session ID through the cookie, but that would be super hacky (especially since the tracker manages its own storage that might also be localStorage or something else).

Do you see problems with this?

[alexanderdean]

I don't see any problems - @chuwy @BenFradet ?

[BenFradet]

me neither, moved the discussion to #610

[paulboocock]

From the comments it looks like this should have been closed a while ago, all of the discussed features have existed since around 2.8.0.