Opt-in tracking

[d4mation]

This may be more appropriate as its own, separate, module as it doesn’t have any direct ties to Licensing/Support, but it would be something nice to standardize throughout our plugins.

[d4mation]

Brainstorming

This would require some kind of logging plugin on RBP.com to accept the tracking info. This should all go into its own Table for cleanliness and performance reasons.

It would be neat if we were to graph out the data in different ways using a library like www.chartjs.org

Assuming the tracking is anonymous, I figure on opt-in a Site should be assigned a Tracking ID. This same Tracking ID will be used across different instances of RBP Support so that the data will be assigned to a Site rather than to a Plugin.

Opt-in will be handled Per-Plugin so that each Plugin can send its own data (Did the Customer use a certain feature? etc.), but no matter how many Opt-ins have been done, the same Tracking ID will be used. This keeps the data grouped like mentioned before.

Some "Global" data points will be tracked no matter what Plugin is being tracked, such as WP Version, PHP Version, etc. so that we can see that kind of data across all our Customers regardless of what Plugin is Opted-into.

When querying the data for graphing, COUNT would be used per-Column because when we're viewing the data, we don't care about who sent the data but rather how many of each result exists. Results could be cached for a Day or some other amount.

When Graphing the data, perhaps it should be done as a Multiple Select so that different Data Points can be graphed on command using the available data. In this way, different Reports could be generated Per Plugin using all of its Plugin-specific Data Points and the Global Data Points.

---

Thoughts, @joelworsham @brashrebel?

[joelworsham]

I love it all. I agree on all points and would consolidate some points to the following:

• Single tracking ID per-site, regardless of the number of plugins. This is super easy as well because, in the end, only one instance of RBP support is loaded per site.
• Global data sent no matter what.
• When sending data, use a filter so that each plugin can enter any amount of extra data specific to each plugin.

For the data sent, we will need to spend some time coming up with the schema so ALL data is normalized and easily expandable. For instance:

apply_filters( "rbp_support_tracking_data_{$plugin_ID}", array(
  // Each "data point" will be an array. This is non-associative, so there are infinite points available
  array(
    'id' => 'my_tracking_point_id',
    // The data array can be looser schema, because the API receiving on RBP.com can be setup to 
    interpret data based in ID, but it should be at least similar so it is easily graphable.
    'data' => array(),
  ),
));

This is just a brainstorming idea. The data sent can be much more complex.

[d4mation]

Yeah, the schema design is going to be incredibly important and something that we are going to want to hammer down before this gets even close to being in the hands of customers, because at that point it will be harder to change.

As long as it is enumerable by Data Point (How many Sites are running PHP 7.0?) and entries can be updated by Tracking ID (They just updated WordPress, so that Data Point for them should be updated in our statistics) I think we'll be good. But we'll want to ensure overall that we can the data organized.

Maybe all Data Points for plugins should use the RBP Support Prefix at the start (automatically)? That could make creating a graph of just CD Pro Data Points easier from a UI standpoint I think.

[d4mation]

Another thing to consider with this would be GDPR.

While I'd consider most anything we'd be collecting here to not include identifiable information, better safe than sorry. If they opt-out at a later time, it should send a signal to RBP.com to delete that data.

[brashrebel]

That's a really important point. We may have to take extra steps to eliminate anything identifying. That would be tough if we want to be able to update entries at a later date but I'm sure we can figure something out.

[d4mation]

Yeah, given that it is an ID that identifies them (Some random number/string) that alone should not be identifying. But according to GDPR even an IP Address is identifying even though here in the States it isn't legally.

A way for the user to say "purge my data please" is enough to be compliant from what I understand of it.