Widgets: Record events for the Simple Payments widget

[Copons]

Fixes Automattic/wp-calypso#25484

Add metrics for the Simple Payments widget.

Changes proposed in this Pull Request:

• Add three new Tracks event:
  • jetpack_wpa_simple_payments_button_create
  • jetpack_wpa_simple_payments_button_update
  • jetpack_wpa_simple_payments_button_delete

The extra event properties are the same as in Calypso: id, price, and currency for create and update; only id for delete.

• Add three new MC stats to the simple_payments group:
  • button_created
  • button_updated
  • button_deleted

Testing instructions:

I'm not sure how to properly test this on WPCOM while it's still a PR to be merged into a feature branch.

[Copons]

@Automattic/jetpack-crew 👋
Pinging you informally to check with you that I'm doing the right thing here.

Also, we should probably also track when we insert or remove the Simple Payments widget, but I'm wondering if we already track that "globally" somehow.

And another doubt: our analytics lib forces us to prepend jetpack_ to the event names.
Am I supposed to do anything different for the WPCOM side?

@gwwar You mentioned a simple_payments_dialog_edit_view or simple_payments_dialog_customize_view.
Do you mean that we should track whenever a user opens the edit form of a SP in the Customizer?
It's bit overkill maybe? I've added a track/bump for when the user actually updates the button (not the widget), and I think it should be enough.

[gwwar]

Do you mean that we should track whenever a user opens the edit form of a SP in the Customizer?

Not sure if it'd be too difficult to track, but I think the initial click on the blue edit pencil (or initial load of the form) in the customizer would be interesting. Though I imagine we're smart enough to de-dupe events for users on a single session.

[Copons]

@gwwar I think that clicking the blue pencils in the preview or opening a widget via the menu, those are (should be?) tracked independently of their widget.
It's unclear to me how to see events recorded in JP, so I've got a bit of trouble figuring out if they actually record such events and if they do what's their name, but I'll look into it ASAP.

In other words, if the pencil doesn't record any events, we (or maybe the JP folks? 😛) should take care of that on a higher level, and not only for this widget.

[matticbot]

This PR looks like it might contain user tracking functions. We need to make sure that it is GDPR Compliant.

Rules triggering this positive scan:

• Called "record_user_event" function.

cc: @pesieminski

[gwwar]

Thanks @Copons I think this looks correct. I did some light smoke testing and checked to see if the jetpack tracks event appeared. I'll of course defer to any Jetpack convention and if we need any other considerations for GDPR.

[Copons]

Rebased and ready to go.

@pesieminski re: GDPR
The bot raised a concern about a function we're not using anymore in this PR.
Though, we've replaced it with another function (jetpack_tracks_record_event) that takes a user object (obtained with wp_get_current_user()) as parameter.
What exactly should we be careful with here?

[Copons]

A bit of an explanation of the changes in a9661dd:

• Replaced if ( IS_WPCOM ) with if ( function_exists( 'bump_stats_extras' ) ) because the latter (and jetpack_bump_stats_extra as well) only exists on WPCOM. So the outcome is the same, but it's a little bit more elegant.

• Since there is no bump_stats_extra in JP proper, I've adopted an established workaround: start tracking with $jetpack->stat() and immediately do a one-off stat bump with $jetpack->do_stats( 'server_side' );.