Create Tracks Client Wrappers

[timmyc]

Collecting usage data of the new Analytics and Dashboard projects will be key to determine which features our users are interacting with most frequently. During the last woo-dash hangout we discussed the notion of using the Jetpack Tracks Clients to implement tracks within dash/analytics.

Goals

• Determine if it is feasible to utilize the existing Tracks clients that are available in Jetpack. I.E. can we have our own tracks namespace for the project yet still use the JP clients?
• Since not all users of the feature plugin will have Jetpack installed / activated - look into creating a wrapper of the JP classes, or similar logic that can be called within PHP and JS code to record tracks events

[greenafrican]

not all users of the feature plugin will have Jetpack installed/activated

If we're going to support no-Jetpack users then we shouldn't create any dependencies on Jetpack code.

We'll need to decide on how we identify sites (as there may not be a wp.com blog_id) and users. We're using ${blog_id}:${user_id} for logged in users in the WooCommerce Analytics module in Jetpack, which wouldn't work without a blog_id. WC Tracker identifies unconnected sites via their URL.

[timmyc]

I totally understand that only a percentage of Woo users will likely have Jetpack installed so it restricts how many interactions we can track, but in-lieu of rolling our own tracks tooling I figured having a sample of usage would be better than none.

Other consideration here is we can collect usage data via tracks by using Jetpack, and are okay doing so based upon the T.O.S. that Jetpack users agree to, so our feature plugin here can steer a bit clear of that and just use the tooling that is in place already.

From a data-science standpoint, do you think the number of Woo sites with Jetpack connected is statistically large enough to base usage trends from @greenafrican ?

[greenafrican]

do you think the number of Woo sites with Jetpack connected is statistically large enough to base usage trends

Yeah, the trends from Jetpack connected sites are very representative of the population.

the ±300k Woo+Jetpack connected sites may offer a large enough statistical sample of all stores (statistically I think you only need around 20k samples to evaluate a population of ±2M with a 99% confidence level and 1 point confidence interval)? (technically, this only applies to random sampling and there may not be anything 'random' about store owners using or not using Jetpack; however, we do have nearly 10x the sample size, which is significant)

[timmyc]

/cc @allendav if you wanted to chime in with any comments you had from our hangout today.

One other concern I have with adding new tracks/tracker specific logic here is it might be cause some users to not test out the feature plugin potentially.

[greenafrican]

The JP tracks PHP class prepends all event names with jetpack - https://github.com/Automattic/jetpack/blob/master/class.jetpack-tracks.php#L83

The admin JS client doesn't prepend jetpack but isn't accessible to us as it is part of their build -https://github.com/Automattic/jetpack/blob/master/_inc/client/lib/analytics/index.js#L121

[timmyc]

Yeah I was a bit worried about that, but I suppose we could still get useful information even with using the jetpack namespace, alternatively we submit a PR there that makes the prefix configurable.

[greenafrican]

The good news is that w.js and s.js are both available so we can use those :)

[timmyc]

Closing this out since #452 shows the tracks wrapper working end-to-end 🎉