Add tracking for completed events

[mikkamp]

Changes proposed in this Pull Request:

Project Thread: pcTzPl-20H-p2

This PR adds tracking from the backend for the following events:

• Merchant Center onboarding completed
• Ads onboarding completed
• Campaign created
• Campaign edited
• Campaign deleted

Sending these events from the backend allows us to track when the event was successful (as opposed to when the button is clicked to submit the data), as well as return relevant properties.

Detailed test instructions:

1. Connect a new site and confirm tracking is allowed in WooCommerce > Settings > Advanced > Woo.com
2. Go through the onboarding, while skipping the campaign creation
3. Go through the ads onboarding by adding a campaign on the dashboard
4. Create a campaign
5. Update a campaign
6. Delete a campaign
7. Go to tracks > history and filter for your username to confirm all tracks are received (make sure to set the date range to include today and might need to wait a while for them to show up)
8. Alternatively I used a snippet like this to add the track properties to a debug log file:

// Log tracks.
add_filter(
	'pre_http_request',
	function ( $pre, $args, $url ) {
		if ( str_starts_with( $url, 'https://pixel.wp.com' ) ) {
			wp_parse_str( wp_parse_url( $url, PHP_URL_QUERY ), $query_vars );
			error_log( json_encode( $query_vars, JSON_PRETTY_PRINT ) );
		}
		return $pre;
	},
	10,
	3
);

Note

This snippet will only work for tracks that are sent through wp_remote_get (for example while doing REST API requests), tracks that are injected into the page footer will not be logged through this snippet.

Changelog entry

• Add - Tracking for completed events.

[codecov]

Codecov Report

Attention: 19 lines in your changes are missing coverage. Please review.

Comparison is base (1b7abc7) 59.5% compared to head (858aef3) 59.7%.
Report is 5 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##             develop   #2207     +/-   ##
===========================================
+ Coverage       59.5%   59.7%   +0.2%     
- Complexity      4129    4136      +7     
===========================================
  Files            453     454      +1     
  Lines          16482   16506     +24     
===========================================
+ Hits            9807    9858     +51     
+ Misses          6675    6648     -27     

Flag	Coverage Δ
php-unit-tests	59.7% <29.6%> (+0.2%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
src/API/Google/AdsCampaign.php	97.3% <100.0%> (+<0.1%)	⬆️
...rc/API/Site/Controllers/Ads/CampaignController.php	100.0% <ø> (ø)
...I/Site/Controllers/Ads/SetupCompleteController.php	90.0% <100.0%> (+1.8%)	⬆️
...trollers/MerchantCenter/SettingsSyncController.php	90.0% <ø> (ø)
src/Exception/WPErrorTrait.php	58.3% <100.0%> (+41.7%)	⬆️
...ernal/DependencyManagement/RESTServiceProvider.php	100.0% <100.0%> (ø)
src/Tracking/EventTracking.php	0.0% <ø> (ø)
...ernal/DependencyManagement/CoreServiceProvider.php	0.0% <0.0%> (ø)
src/Tracking/Events/GenericEvents.php	50.0% <50.0%> (ø)
src/API/Google/Settings.php	6.2% <0.0%> (-0.6%)	⬇️

... and 5 files with indirect coverage changes

[puntope]

Thanks for working on this @mikkamp

I yes see the logs using the filter.

For example: For campaign creation I see all of this:

"gla_version": "2.5.15","
"gla_ads_id": "2675599762","
 "gla_mc_id": "541848347","
"id": "20958455946","
"status": "enabled","
"name": "Campaign 2024-01-22 22:07:08","
"amount": "2","
"country": "ES","
"targeted_locations": "ES","
"_en": "wcadmin_gla_created_campaign","
"_ts": "1705961231444","
"_via_ua": "Mozilla\/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/120.0.0.0 Safari\/537.36","
"_lg": "en,es-ES;q=0.9,es;q=0.8,nl;q=0.7","
"_dr": "https:\/\/woomppellicer.jurassic.tube\/wp-admin\/admin.php?page=wc-admin&path=googlesetup-ads","
"_dl": "http:\/\/woomppellicer.jurassic.tube\/wp-json\/wc\/gla\/ads\/campaigns?_locale=user","
"_ut": "wpcom:user_id","
"_ui": "113366118","
"url": "https:\/\/woomppellicer.jurassic.tube","
"blog_lang": "en_US","
"blog_id": "225662403","
"store_id": "653e00fe-4f75-4c5d-b126-6f3fd6296c41","
"products_count": "27","
"wc_version": "8.5.0.40","

However, I don't see it in the Tracking History

[puntope]

💅 I would change this to get_tracking_settings or get_settings_for_tracking.

[mikkamp]

get_tracking_settings implies it would be settings for the tracking system, which is not the case.

Changing the tense of the verb to "tracked" implies that it is "for tracking", but happy to change it to get_settings_for_tracking if it's more explicit.

[puntope]

What do you think to wrap these functions? So we can avoid to repeat some code

public static function track_event( $event, $props ) {
do_action(
					'woocommerce_gla_track_event',
					$event,
					$props
				);
}

I see you created some Service for that. So potentially there is some reason to use an action instead of calling the function directly.

[mikkamp]

The reason I didn't do this was because of dependencies, as well as consistency with the other tracking classes being setup to hook into an action to trigger the event.

My thought was that we would be adding tracking to many different classes, in order to be able to use a service class it would need to become a dependency of any class that wants to record a tracking event. However tracking is not a requirement for the code to function well within each of those classes, so I didn't want to add additional dependencies to multiple classes just for tracking.

The other option was to use a static class, but since the existing tracking implementations were using actions, I decided to stick with using a similar approach. The actions are also a little easier to unit test (using some helper functions) as opposed to sticking with a static class.

As for wrapping the function, the do_action is just one function call, so I don't see a lot of repetition there, so if a dependency is needed for a utility class I don't see us gaining a lot of benefit from wrapping it.

[mikkamp]

Thanks for the review @puntope. I've gone ahead and renamed the function you suggested. I've also added an explanation why I don't think we should use a service class for tracking. Let me know if that makes sense or if there are any other suggestions there.

However, I don't see it in the Tracking History

It can sometimes take a while till they are processed, I searched for the event and I can find one with the same properties you logged above:

[puntope]

Hi @mikkamp thanks for clarifying my question in regards the service.

I still don't see the track history for any event... Maybe I'm using the wrong username? Or some setup is wrong?

Since you see them, Im approving this in advance