'page' parameter for non pageView events - js tracker

I’m hoping to confirm the intended approach for the ‘page’ parameter when it comes to Structured Events.

I notice in the Web Specific Parameters section of the js tracker documentation it states

These parameters are relevant across all web events, regardless of the event type.

‘page’ is one of many parameters listed on this page.

However I notice that the page property is not sent to the collector with any Structured Events. Looking at the source I can see that unlike trackPageView and trackPagePing, trackStructEvent does not add the page property.

Is it the case that it is not intended to pass these with all web events regardless of the event type, only pv and pp event types ?

Hi @njenkins, you are right - that’s an error in the documentation. The page title is only attached in the page view and the page ping (which is essentially a “child” event of the page view, at least in how it is created).

The confusion comes from the signature of trackPageView:


  // First argument lets you override the page title
  "A custom title",


This API associated the (customizable) page title to just the page view (and by extension the page ping) events.

A more coherent approach would be:

  1. Set the page title on all web events, just like we do with page URI, referer URI et al
  2. Deprecate the custom page title argument from trackPageView
  3. Add a setPageTitle method for equivalence with the current setCustomUrl and setReferrerUrl

Feedback welcome!


Hi @alex,

In an effort to make it easier to analyze our raw data collected from different platforms in various databases and tools, we are currently migrating away from e=pv and will solely be using ('trackStructEvent', '([a-zA-Z]+)Event = <GA category>', '<GA action>', '<GA label>', '', '<GA value>', [<pageContext>, <userContext>, <platformContext>, <productContext>, etc.]) for any type of event, e.g. pageViewEvent (web), clickEvent (web), settingsView (mobile) or ecommerceEvent (web and mobile).

For now, we will just add the page data to our pageContext and maybe that’s an even better solution. But in general I support your setPageTitle idea as not everybody might want to deal with custom contexts (I :heart: them ;-).


Hi @ian - yes, your approach makes sense. Eventually we will move to a first-class page context in Snowplow too…