Skip to main content

By default with the browser SDK, we can get it to track a “Pageview” event which has properties like page_url, page_domain and page_path.

I can then query that to our heart’s content but it’s a bit of a pain each time to specify the domain to differentiate between our marketing site and web app (for example).

Also, in the event stream seeing “Pageview” just repeated isn’t helpful since it forces us to click on each one to see the page domain and path to even understand the order of their navigation:

 

Even worse, in Amplitude’s “Pathfinder”, a generic Pageview event then looks like this which is not very unhelpful:

 

I’ve seen this older (2014) blog post making a case for not needing a pageview type event, but I think this is naive because an event of viewing a page is just as important in how we attach analysis of user flows as it is to look at an event causing someone to get to that page. It also forgets that some visitors may do a pageview coming from a link from a 3rd party source.  Lastly, the way you often look at user flows and paths is you first want to know their general journey (Page A → … → Page Z) then you dial in on what they may have specifically clicked on or engaged it.

Given this, is the default “Pageview” even the right thing to depend on? We could:

  1. Use the track() call to call a custom event each time for every page on our marketing site and web app and turn off the default “Pageview” event
  2. Do #1 but leave “Pageview” turned on.  
  3. Turn off the default “Pageview” event and instead replace it with 2 generic events Marketing Pageview and Webapp Pageview

Advantage of #1 is that we reduce noise of seeing Pageview events as well as the custom event we send.  However, this is good because I”m sure there will be less important pages we may not want to bother with a custom call (e.g. privacy policy pages, terms of user pages).

Advantage of #2 is the event stream is cleaner without doubling up, but then we risk losing events for pages we didn’t do a custom track call for.

Advantage of #3 is that it still keeps it generic and minimizes total # of events, but at least at a glance you know which part the user is doing a pageview in. Also reduces # of steps later in analysis to avoid needing to specify the domain each time, you then just worry about path

 

What is the best practice for this? Surely all of you with a marketing site and/or web app have encountered this.

 

Thanks for reaching out here @trevin-bc. Our data taxonomy playbook has guidance on how to leverage page views operate here. It’s recommended that you should leverage client-side tracking to capture more context. Read more on the blog and keep us posted as you make progress!  

I implemented this on our site a while back using Amplitude’s template tag in GTM coupled with a simple Javascript, the logic should hold if you’re coding direct on your site rather than through a tag manager. For reference, we’re a UK holiday provider so we have a “marketing site” as you mention.

The tag passes a page view with relevant event parameters (domain, path, user agent, etc) and an additional “event type” property specifying “page view” for the value. The Javascript simply outputs and event name based on the page data (for example, if path = <your homepage> then event name = ‘view homepage’)...it’s passed into the field which populates the event name. It works really well and make the user pathing really good (I’ve added in red the values we pass in the custom “event type” property)…
 

Having the custom “event type” property also means you can very easily filter out interactions….which is something I imagine your marketers would be keen to do when just wanting to get hold of “traffic” 😀

I implemented this on our site a while back using Amplitude’s template tag in GTM coupled with a simple Javascript, the logic should hold if you’re coding direct on your site rather than through a tag manager. For reference, we’re a UK holiday provider so we have a “marketing site” as you mention.

The tag passes a page view with relevant event parameters (domain, path, user agent, etc) and an additional “event type” property specifying “page view” for the value. The Javascript simply outputs and event name based on the page data (for example, if path = <your homepage> then event name = ‘view homepage’)...it’s passed into the field which populates the event name. It works really well and make the user pathing really good (I’ve added in red the values we pass in the custom “event type” property)…
 

Having the custom “event type” property also means you can very easily filter out interactions….which is something I imagine your marketers would be keen to do when just wanting to get hold of “traffic” 😀


Thanks for this. I had no idea you could specify an “event type” property.  I can’t event find documentation about this… can you point me to where this is discussed in help docs?

The long and short of it is that you can pass whatever “event properties” you like (within the limits of whichever Amplitude tier you’re on), these variables can be for any purpose you see fit in order to add contextual data to the event you’re firing.

Event props & User props: https://help.amplitude.com/hc/en-us/articles/115002380567-User-properties-and-event-properties#h_045bc2f6-4427-46bc-a379-55f0eabb2c91

Limits: https://help.amplitude.com/hc/en-us/articles/115002923888

The long and short of it is that you can pass whatever “event properties” you like (within the limits of whichever Amplitude tier you’re on), these variables can be for any purpose you see fit in order to add contextual data to the event you’re firing.

Event props & User props: https://help.amplitude.com/hc/en-us/articles/115002380567-User-properties-and-event-properties#h_045bc2f6-4427-46bc-a379-55f0eabb2c91

Limits: https://help.amplitude.com/hc/en-us/articles/115002923888


I understood that about event props in general but the special thing here, I thought, was the event type was showing up in the red text in that event stream. 

Oh no, that was me manually adding it to the screengrab purely for showing the example 😁

Oh no, that was me manually adding it to the screengrab purely for showing the example 😁

LOL.. ok that makes more sense now. Thanks for humoring me :)

 

I do think your approach for event type is a good one though. thanks for the tip.\

That said, do you know if you can apply filters based on event names? I’m thinking through ways of saving time and avoiding mistakes where events may be implemented missing the “event type” prop

Thank you for your help here @dangrainger. Much appreciated! 😃

@dangrainger have you found not having  Amplitude] Page Counter attached to your pageview events to be a limitation. As far as I can tell on https://www.haven.com/ you dont send this?

As soon as we change event name of a pageview do we lose ability to keep up the Page Count as its based on default Page Viewed event?

Everything else, refererr/location etc. can be added manually.

Thanks!

Hey @Matt Grogan DMPG. The simple answer here is that we fully migrated off GA and on to Amplitude for our websites/ apps long before DET (Default Event Tracking) was created and launched. As such we just got on with our own custom implementation; the out-of-the-box Page Counter property didn’t exist so it’s never really been missed.

On the few occasions things like this have come up from our Amplitude users, we’ve generally been able to use the Historical Count/ Event Historical Count properties which perform their counting at the user level for whatever time range you’ve got selected. Would it be nice to have session-level equivalents that don’t rely on having to use DET? Yes, but for us a nicety not really a necessity so far.

@dangrainger  cheers thanks for the perspective.

Reply


Terms & ConditionsCookie settings