How to override trackerVersion

For engineers Tracking SDKs
1

Hello there,

I am trying to override the trackerVersion with some custom name through GTM but it’s not getting reflected in my Redshift table, so can you check my configuration and let me know if I am doing in right way or not.

<script type="text/javascript">
;(function(p,l,o,w,i,n,g){if(!p[i]){p.GlobalSnowplowNamespace=p.GlobalSnowplowNamespace||[];
p.GlobalSnowplowNamespace.push(i);p[i]=function(){(p[i].q=p[i].q||[]).push(arguments)
};p[i].q=p[i].q||[];n=l.createElement(o);g=l.getElementsByTagName(o)[0];n.async=1;
n.src=w;g.parentNode.insertBefore(n,g)}}(window,document,"script","sp.js","snowplow"));
  console.log("Platform: "+'{{platform}}');
window.snowplow('newTracker', 'cf', 'collector.endpoint.com', { 
  appId: 'APP_ID',
  cookieDomain: 'endpoint.com',
  trackerVersion: 'version-1'
});
window.snowplow('trackPageView');
</script>
2

Hey,

we tried that too, but if you look at the code, the tracker name is hard coded during build time. See here:

I suggest a open an issue, and even better: provide a pull request.

Christoph

3

Why would you want to override the tracker version @birju1100 - I’m having trouble seeing the use case.

Obviously if you are forking the tracker, you can attach a custom tracker version, but if you are using vanilla js-2.6.0 or similar, I’m not clear why you would want to change that.

4

Hey @alex,

I agree with you, I am not going to change that because it’s not make any seance, just because I was trying to test what are the attribute we can override. so just ask the question. because we are trying to override the platform but which is not possible as of now, so we thought we can use some other attribute and track the platform instead of that so had tried but that’s also didn’t workout.
so can you suggest me what are the attribute we can override with the custom field, we were thinking to override the tna (trackerNamespace) can you suggest me some of that were we can use for platform instead of that.

5

What about using a context? You could easily write a platform_context and add as many fields as you want. You have to add the context for every event you sent, but it’s way cleaner than forking or hacking something in.

The events table is designed for a basic use-case, but if you have additional values you want to track, contexts are the way to go. We use contexts for many many things and it’s an awesome way to modify the system for your business case

6

Hey @tclass,

If I will use the context what are the changes I have to do in terms of events table. I don’t know how to use, can you help me out to build.

7

That’s the nice thing about it, you don’t have to change the events table you create a new table that you can join on, so for every event in your events table there will be added a line in your context table. With this you can easily join additional information based on the event_id.

Example:

events:
app_id, event_id, user_id,…

platform_context:
platform, root_id, …

This would be the two tables you have, so if you want to find out the platform for a specific event
SELECT platform, event_id FROM events JOIN platform_context ON (event_id = root_id);

so the root_id is the foreign key and references the event_id

There’re some documents on how to implement contexts:

Feel free to ask everything you don’t understand after reading this documents

1 Like
8

Hi @alex ,

we actually build a shallow wrapper around the native JS tracker with some convenience methods. We required the js tracker as a npm module. For that reason, we would like to differentiate the tracker version to make sure we keep track which of our tracker versions is actually sending the events. Does that make sense?