Skip to main content

Hey Amplitude Community!
 

Since 07/19/23, my company has been experiencing a problem with our Amplitude tracking. We monitor two events: one when a user visits our page (view) and another when they click on something on the page (button_click).

Lately, we have noticed a significant increase in the number of button_click events do not recorded, almost three times more than it should be. Strangely, there have been no changes made to the backend or frontend that could account for this discrepancy.

Upon investigation, we found that the majority of our users are accessing our site through the Facebook in-app browser and the Instagram in-app browser.

Now, we are trying to identify the potential causes for this issue. Any insights or suggestions on what might be affecting the tracking accuracy would be greatly appreciated.

Hi @Ihor Shvydkyi. We’ve recently had some similar fun with in-app browsers...do you by chance have bot blocking turned on in your Amplitude Analytics project?
 


We found that our in-app browser traffic was being sent with a user agent string that was on the block list, so this traffic segment wasn’t reaching our Amplitude project. It might not be your issue but I thought it worth mentioning as something for you to check.

Dan.

Unfortunately, we do not have any blockers or tracking blockers in place that could explain this issue. We have thoroughly checked for such possibilities.

Could you suggest any other potential reasons for this unexpected behavior?

@dangrainger Hi again)
 

We have identified a specific error in the tracking process. When a user clicks on our webpage and then navigates away (e.g., to the store or other sections), the click event does not appear to be displayed or tracked at that moment. However, if the user returns to the original page (from the store or other sections) and refreshes it, the previously triggered click event becomes visible.

The puzzling aspect is why the tracking of the click event doesn't happen immediately upon the initial click. We're actively investigating this delay and seeking possible explanations. If you have any insights into why this behavior is occurring or suggestions for resolving it, we would greatly appreciate your input.

I’ve seen this in our implementation. We deploy Amplitude calls using the GTM template tag, but found some occasions where GTM was not quick enough to process the tag before the user moved to a new application. I got our engineers to put a small time lag in place between the data layer event firing and the user being transitioned to the new application which helped.

@dangrainger , thanks! It didn't solve our problems 100%, but it made things better 

@Ihor Shvydkyi

When a user clicks on our webpage and then navigates away (e.g., to the store or other sections), the click event does not appear to be displayed or tracked at that moment. However, if the user returns to the original page (from the store or other sections) and refreshes it, the previously triggered click event becomes visible.

Seems that i have an explanation for your case:

  • user clicks on the button and navigates away, but amplitude haven’t sent the event yet (probably because of batching or race condition on browser navigation/sending)
  • in the meanwhile amplitude saves events queue to the store (cookie, ls) and events gonna be send again on the next session

You have different options to solve the issue:

  • use beacon transport for events instead of http
  • flush events on page hiding
  • configure batching by flushQueueSize and flushIntervalMillis options to send events immediately
  • add a delay between navigation and event sending (can be achieved by custom js handler on link)

Hope that it helps!

 

Reply


Terms & ConditionsCookie settings