-
Considerations for Tracking Asynchronous Data in GA's page_view Event
So here’s the deal. I’m wading through a little bit of a pickle here. I’ve been asked to chuck
page_viewevents (GA4) into the mix, which need to lug around some information that’s coming in all slow-like… you know, asynchronously and all.The sticky part is, when the page first pops up all shiny and new, and that info isn’t there straight off the bat, I can’t just whip up that event. I gotta wait until we’re good to go with the data. Ok, no sweat so far.
Stumbling Block
But here’s where the hairpin bend comes in. One of these pages isn’t just one of those run-of-the-mill, one component kind of deals. Nope, there’s a whole bunch of these bad boys, each one fetching its own little nuggets of data. So the only way I can see to fire up one of these events, is to lean on the redux store, you know, wait until the data’s there, and presto, off goes the page view event.
A little bit like this:
const subscriptionsData = useAppSelector( (state) => state?.[REDUX_API.KEY]?.[REDUX_API.SUBSCRIPTIONS]?.successPayload?.data ); useEffect(() => { sendPageViewEvent({ subscriptionsData }); }, [subscriptionsData]);But if a page is peppered with lots of components, and those components are pulling in data that I also need to throw into that same
page_viewevent, well, then we’re in a jam.I’ve been digging around for a bit, but haven’t struck gold when it comes to solving this curious caper. And I have a nagging idea that maybe it’s because I’m trying to send along data that I simply don’t have in my hands.
The only solution I’ve managed to cook up is a bit on the janky side:
- Maybe conjure up some kind of setting file that double-checks, based on the route, what fields we want to ship off to GA. But this feels a bit like a kludge, we’d always be chasing our tail trying to keep it updated, and folks are likely to drop the ball and forget about it now and again.
All this to ask, is it a bit of a no-no to be shooting off asynchronous data in
page_viewevents? Click events, sure, butpage_view, that’s another kettle of fish. Even if you’ve got just one component doing all the fetching, you can’t really count on always fetching data from the same component in the future. And if you do need to fetch some more, well then you just end up having to fire off another event. And that’s just going to scramble you analytics real good… -
2 Replies
-
Firing off asynchronous data in
page_viewevents is not necessarily a no-no, but it does introduce certain complexities that you’ve already identified. It’s crucial to recognize that the firing of thepage_viewevent and fetching of data don’t always occur simultaneously, which can impact the accuracy and consistency of the event’s data payload. Leveraging the Redux store to trigger the event once data is available may work in some instances, but with multiple components fetching different data sets, inconsistencies may emerge.Your proposed solution of creating a settings file that checks, based on the route, which data fields to include with the GA event can present future maintenance difficulties due to the dynamism and evolving nature of web applications.
An alternative might be to consider using a state management solution to aggregate data from all components before firing the
page_viewevent, or to delay firing the event until all async operations have completed. In the end, it’s essential to ensure your solution doesn’t skew the accuracy of your analytics. -
The problem this person is experiencing is that they are trying to track who visits their web pages (known as “page_view events”) while at the same time collecting certain information from those visitors. The difficulty emerges because the required information isn’t always immediately available and only comes later. This is due to the fact that web pages these days are often composed of many smaller parts (which we call “components”) that grab their own information. A possible solution is to use a tracking system that waits until all the data is ready before triggering a “page_view event”, but this becomes more complex when there are many components fetching data. They’ve suggested a workaround that involves setting up a system to check which data fields should be sent based on the page route, but they worry it would be hard to maintain. They’re also concerned that trying to include asynchronous data in these events might not be good practice and further complicate their analytics.
Log in to reply.