Piwik integration

[y-lohse]

What we want to do

We essentially do 3 things in regards to Piwik:

• init a client
• track page changes
• Manually call other methods in very specific conditions

The last point is what we should discuss. Here are the main uses cases that I see:

• Tracking an event with a category, name and action
• Converting a goal
• Manually triggering a fake page view

These are all simple function calls (trackEvent, trackGoal, etc) with some parameters.

How we are doing it at the moment

Right now, we do some calls to trackPageView manually during the onboarding.

We also have a more automated solution to track events. There is a redux middleware that will inspect actions, and call the piwik API if the action has a field named trackEvent, which describes the parameters to pass to the function.
cozy-photos has a dedicated middleware that adds the trackEvent field where needed.

What's wrong with it?

• Tracking goals and custom page views isn't seemless
• Tracking anything requires to dispatch a redux action, event if the state won't be affected at all

Is there a better way?

This is what I'd like to discuss 🖊 📄

[y-lohse]

My own 2 cents: I actually like this approach. I think we can easily extend the middleware to track more than just events, with a very similar design. While it slightly bothers me to sometimes dispatch actions with no consequence on the store, I feel like this isn't a big deal.
I also quite like the design used in cozy-photos, where a app-custom middleware sits on top of the middleware provided by cozy-ui, as it allows to centralize all the piwik-stuff.

The thing that bothers me the most, and is not listed above because it's subjective, is that this approach is a bit fragile. The piwik calls happen ad-hoc from the redux dispatch, so they are very easy to overlook. It's easy to imagine someone removing a dispatch call because "it does nothing to the store", and breaking a tracker in the process.

Other options?

Manual

Obviously we could require the piwik client where needed, and fire the calls manually. I'm fairly sure this would lead to unhealthy code duplication.

Do-it-all function

We could create a standalone function, with a signature like track(event|goal|page, ...extraArgs), which would take care of the rest. This function would still need to be called manually everytime we want to track something.

If anyone has other implementation ideas, shoot! Now is the time.

[CPatchane]

For Claudy we use directly the tracker with trackeEvent. We used it directly in cozy-settings and it's stored in the state for the cozy-bar.

Also we could add this little js code somewhere and add it to the global name cozy using webpack (like for the bar and for the client). And we will use it like :

cozy.tracker.init({
        app: 'Cozy Settings Services',
        heartbeat: 0
      })
cozy.tracker.trackEvent({ // tracked if shouldEnableTracking()
        'Claudy', // action
        'openActionLink', // name
        `${action.slug}` // value
      })

// same for cozy.tracker.trackPageView

Using that, we also doesn't need to handle shouldEnableTracking seems it will be checked by these methods internally.

Agree about the fact that depending on the redux action dispatching to track something could make think that we must dispatch something if we want to track it. Using the example above, we could call it directly after/before an action dispatching and keep it explicit in the code while keeping it simply.

#my2cents

[y-lohse]

(2) [PHO] Ajouter un pistage du partage d'albums via l'API dédiée