Who/What should be responsible for pushing GA events?

[oliversweb]

For discussion: In reference to pushing GA events, should we only emit Vue events (to signal an actions that the Analytical Team might want to record) from Fozzie components in folders 'atoms' & 'molecules' and never push actual GA events?

[oliversweb]

The current decision is to make it a standard that we emit vue events in 'atoms' & 'molecules' and capture these in parent components and then push GA events from there.

[kevinrodrigues]

Was just having a think about this whilst working on a ticket (f-status-banner). I think in some instances it would make sense to emit from the component and let the consuming application / vertical deal with what they would like to happen, if anything, for example things like buttons or smaller more shareable components (by shareable I mean more open source type sharing). But for larger components that are more tied to our own system & generic across teams like the f-status-banner (shared across verticals basically) I think it makes sense to push events directly from this component rather than emitting, the reason being is because each team would essentially need the same repeated code (GA push methods setup) in their codebase if they end up using this component, therefore making it a little harder to plug and play. Thoughts?

[SachaZvetelman]

I agree with this.

[matthewhardern]

I think what @ashleynolan says about internal applications vs external customer facing ones could counter this point. My thoughts are that mono repo should have NO GA events on the components and if / when we move pages they can be consumed there. Good use of a GA directive and maybe some good mixins for the events could reduce the repeated code also.

[ashleynolan]

Just one thing to consider with components like f-status-banner (shared across verticals/pages) is that if they're used in different places, they may still have different params for the GA events depending on where it is (as they may have slightly different functionality depending on where they're used).

I personally think we should avoid putting direct GA pushes into components like this, in favour of some kind of abstraction (emitting events, using data-attributes or directives as @matthewhardern mentions). Once you've tied a component to GA like that, it limits the use of that component in other places, so we should be really sure that we don't want to do that before going down that route.

[oliversweb]

If we have components '... that are more tied to our own system & generic across teams like the f-status-banner' then should these be in the open-source fozzie mono repo? what other company would want our bespoke component pushing our bespoke GA events? whereas if we think our components is useful as an open-source shareable component then by emitting vue events we keep it very agnostic.

[ashleynolan]

I think this mostly refers to what will become pages in the component repo (registration and checkout for instance).

I think we may have some components that are more specific to our customer application than other potential applications as Kevin mentions (for example, f-searchbox is probably fairly specific to the website – I can't imagine it would port to one of our internal applications for instance). But it should still be part of the mon-repo so that we can upgrade it in line with other components and give it the benefit of shared testing and workflows that are setup.

[zlatinivanov-je]

Q. What are the actual requirements, problem that we are trying to solve here? Some examples or context may help inform the decision?

[oliversweb]

We are trying to come up with a standard; a rule; guideline (call it what you want) ... when should we emit Vue events (to signal an actions that the Analytical Team might want to record) and when should we push actual GA events (via GTM)?

[ashleynolan]

I pretty much agree with @kevinrodrigues – I don't think there's ever a hard and fast rule, but when I've talked about it in the past, my rough rules has been; If the component can be used in different places across the web flow, then we're likely to need to emit events and let the consumer handle emitting the analytics events.

To give some examples:

Atoms

…like f-button can be used in tonnes of different places and so including analytics code as part of the component would be unrealistic to handle all these situations. So having the consumers handle the analytics makes sense for atoms like this.

One thing to add that worked well when we used f-trak was that it enabled us to hook analytics events onto small components through data attributes (so if this component gets clicked, send this event data). This was super useful for avoiding lots of GA push code mixed up in the application JS. I think this could be potentially useful to recreated in whatever solution we have in the future.

Molecules

Likely to be the same as above, as the idea of these components is that they're still shareable across the application. So embedding analytics code inside them doesn't make a lot of sense, unless there is a way we can avoid a lot of repeated if statements for each different type of GA push.

Organisms

A bit less clear cut, as like Kev says above, it depends on how they're being used. I think we'll likely separate out page components like f-checkout etc in the future, which I think makes sense to handle their own events).

Things like f-status-banner I think we'd need to look at and decide per component. I think the main issue comes if the component could ever likely need to be used in something like Partner Centre or Ops, as then we'd need to be able to push with different params dependent on where it's used. As long as we don't end up with a lot of `if (partner centre) { … } else if (web) { … }' and similarly if we need to emit different things based on the page it's on too.

Pages

I'm including this as a separate category as I think it's inevitable that we'll split these out, either into a separate folder or their own mono-repo. I think for pages, it makes sense that they handle their own events.

[matthewhardern]

I agree having a directive that we can add to atoms like f-button that listens for click events stops a lot of the GA JS bloat

[ashleynolan]

Just for reference – the f-trak docs that show how this was done are here.

[gareththackeray]

Devil's advocate here: the GTM already provides an abstraction away from GA. You push things to a dataLayer array and the GTM takes over. Do you need an abstraction on top of that abstraction?

[ashleynolan]

I guess the difference (to me) is that GTM is an abstraction we don't have any control over. If they decide to change the way GTM works or how to communicate with it, it would result in a lot of effort for us to then update to this new workflow.

[gareththackeray]

Well, this could happen, though I'd venture that any abstraction you come up with will need to be reasonably well coupled to the current expectations of the measurement team to avoid them having to dump masses of custom conversion code into GTM. I would definitely run these ideas past Rob and co earlier rather than later.