Issue with page tracking events

  • 29 December 2021
  • 3 replies

We are over our event type limit, but we shouldn’t be as far as I can tell.

Looking into "why" has led us to the Page call that we're passing to Segment. When we do that, a single Page event appears in amplitude as two different events. One for "Loaded a Page"  with a URL as a property (which I am using EVERYWHERE), and another for "Viewed_____ Page". That blank is being filled in with the URL of the page, which sometimes contains a unique slug, which means 1000s of event types that we dont need. I never use the "Viewed ___ Page" call in Amp.

So how do we fix this?  Why are there two events being created in Amp? Can we kill the "Viewed ____ Page" calls (historically and going forward)?


Best answer by Denis Holmes 30 December 2021, 10:23

View original

3 replies

Userlevel 6
Badge +8

 Hi @pindelicato ,


Thanks for writing in! Denis here again, happy to help and provide some insight!


So I understand that the issue is Amplitude gets two events ingested, one for Loaded a Page and one for Viewed URL_Slug Page which created a hundred of event types. In this scenario, the best fix would be to block and delete these event types so you can get below the limit again. Alternatively, you could create a new project and start using that instead. You could export the data from the old project and import it using the HTTP Batch API to the new project.


It would seem the events are being sent to Amplitude from the code. I understand you have segment, correct? Are these events ingested from Segment? Or is it from the Amplitude SDK? Regardless, it would seem this is an implementation issue so you would need to look at these events and see what gets triggered to log two different ones of these events. 


With regards to stopping this, the only way to do this is to look at the implementation and look into the part triggering both events in order to stop it from generating a whole new event each time there is a different URL. It would seem some code somewhere or some implementation logic is sending the slug as a separate event, as we know, and this is not ideal. I would instead look into the part of Viewed ___ Page and instead make this an event property such as , for example. rather than a whole separate event.


Can we kill the "Viewed ____ Page" calls (historically and going forward)?

You can block them but it is specific to each, so once a new URL comes along, it will be ingested. I would look at the implementation and see the root cause of the double sending of events. I would spend time with your developers to see where the kink in the code is. If you cannot find a genuine reason, please PM Me your Org ID and Project ID along with a chart. Thank you! 


Kind Regards,


Hi All,

Curious what the solution was for this issue? I am having the same issues with our webapp, and we use Segment for our implementation. Thank you! 

Userlevel 6
Badge +8

Hi @emilyf ,


I believe pindelicato would have had to go to their Govern, remove the pesky events that polluted it and then look into the Segmentation events they are sending and examine the implementation between both systems. Specifically, getting payloads to see if the data is being ingested in this way.

It would probably be the case that Segment is sending these events. I would look in to the implementation and see why they are generating a whole different event each time. My guess would be there is code something that is sending in new events such as Event_SOME_PROP which is causing issues rather than Event with Some_Prop in the properties. I hope this helps @emilyf !