-
Notifications
You must be signed in to change notification settings - Fork 798
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add extra properties to woocommerceanalytics events #15028
Conversation
Thank you for the great PR description! When this PR is ready for review, please apply the Scheduled Jetpack release: April 7, 2020. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works as expected, code looks fine!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we have data we want to send out for every event (such as blog ID, user ID, and now the site URL or the Woo version in this PR, I wonder if this may be a good time to extract all this into its own method to avoid duplicating code. what do you think?
modules/woocommerce-analytics/classes/wp-woocommerce-analytics-universal.php
Outdated
Show resolved
Hide resolved
Thanks for the nudge @jeherve – I was thinking the same thing. I've now added a PHP function for logging a standard event (to reduce boilerplate), and a utility for getting the common props, as a js argument string (fragment). The arg-string version is needed for the events that are triggered client-side. Ready for another review :) I'm going to do some more testing on this on an ephemeral site before merge, to ensure I haven't broken any existing events/props (e.g. user id, product type etc) in the refactor. cc @deltaWhiskey – might be worth a review or testing from you to ensure the existing events & props are intact. |
6eb1319
to
f89d7bb
Compare
This PR / branch has been rebased. |
Not sure if this needs GDPR review but added the tag just in case. |
FYI @psealock 👋 |
$blogid = Jetpack::get_option( 'id' ); | ||
|
||
// check for previous add-to-cart cart events | ||
return "'blog_id': '" . esc_js( $blogid ) . "', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we were to use sprintf
here, would it be more readable? Or by building an array first, like you did for extra properties in record_event
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point! What I've done is to split the definition of the common props and rendering (as js object props fragment) into separate methods (40e0171).
It's still using the string-concatenation style, with embedded esc_js
call, for consistency with the existing code (cc @deltaWhiskey). But now we can deal with common/server-side props with PHP arrays and then call render_properties_as_js
to render them in a standard way.
modules/woocommerce-analytics/classes/wp-woocommerce-analytics-universal.php
Show resolved
Hide resolved
modules/woocommerce-analytics/classes/wp-woocommerce-analytics-universal.php
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like it should work. It's worth making sure the endpoint is getting what's expected. If you'd like to work together on that, let me know.
I added some organizational / coding style suggestions.
modules/woocommerce-analytics/classes/wp-woocommerce-analytics-universal.php
Outdated
Show resolved
Hide resolved
modules/woocommerce-analytics/classes/wp-woocommerce-analytics-universal.php
Show resolved
Hide resolved
"_wca.push( { | ||
'_en': '" . esc_js( $event_name ) . "', | ||
'pi': '" . esc_js( $product_id ) . "', | ||
'pn': '" . esc_js( $product_details['name'] ) . "', | ||
'pc': '" . esc_js( $product_details['category'] ) . "', | ||
'pp': '" . esc_js( $product_details['price'] ) . "', | ||
'pt': '" . esc_js( $product_details['type'] ) . "'," . | ||
$extra_properties . $this->get_common_properties() . ' | ||
} );' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are two other places in this PR that generate very similar _wca.push(...)
strings (the woocommerceanalytics_remove_from_cart
events.) If we moved the generation of this wca.push(...)
string to another function, then we could call that other function from all three places.
That would add some new product detail properties to the remove_from_cart events, but that seems OK to me.
The new function could be called event_push()
or something. There's probably a better name for it, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're doing a lot of string concatenation and repeated calls to esc_json()
. That preserves the previous coding style, but I think it would be more readable and maintainable to pass arrays around, with the values unescaped.
When the string finally has to be generated (in event_push()
, if we go with that approach, or else here,) that would be the moment to escape everything with an array_walk()
call, and then encode with json_encode()
. That would mean we need to review where single vs. double quotes are being used, wherever we output this.
If we were working with arrays before output, then get_common_properties()
could be passing this a raw array, without doing part of the escaping there, and part in the various other places it gets called.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree it would be nice to have a single path for all these events. The issue is that those two other events are generated on the front end, and pull data from the DOM, so they call the JS api directly - we can't enqueue a pre-rendered _wca.push()
call.
In future, we could render a event_push()
style wrapper func on the front end which supplies all the default props. I didn't want to go that far with the refactor :)
@haszari Can you make a list of events affected? I can go through them and compare to master to make sure no changes have been made to the properties already in production. |
Yes please – I'd appreciate another test pass to make sure the events are still working correctly. I've tested and compared with master, but there are lots of props to eyeball. Thanks @psealock ! All 5 events are affected (I believe these are all the WCA events?):
|
- url - store/site home url - woo_version - version of woo plugin installed on the site
- prep work for having a single record event where we can add all common properties - also provides a PHP interface for logging events with custom params + tidy comments
f89d7bb
to
220eddb
Compare
Thanks for the reviews & feedback – this PR is all the better for your feedback! Please give this a final review & test when you're ready. @jeherve @psealock @deltaWhiskey |
I see Travis is failing, I can't tell if this is due to issues caused by my code. There are two jobs failing:
Please ping me / comment if there are steps I should take to resolve these! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good and tests well for me. 👍 I'll let someone more familiar with the events take a look at it as well, but on my end I think this should be good to merge.
As for Travis, it should be okay now.
@psealock Can you give these events a final test/review before merge? Thanks :) |
return array( | ||
'blog_id' => Jetpack::get_option( 'id' ), | ||
'ui' => $this->get_user_id(), | ||
'url' => home_url(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm curious what the url is for. We already have browser document location in _dl
property. Are you looking for a unique way to identify sites? If so, would blog_id
suffice?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
home_url()
is to give a way to map to data collected by WC Tracker, which does not have blog_id
. There have been experiments in the past with using document location, but that comes with some challenges.
'blog_id' => Jetpack::get_option( 'id' ), | ||
'ui' => $this->get_user_id(), | ||
'url' => home_url(), | ||
'woo_version' => WC()->version, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about keeping this inline with other property names: wv
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prefer clarity over terseness here. See also @deltaWhiskey comment in support of clearer props names: #15028 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All the events check out, code looks good. Nice job @haszari
I just have the two questions above, otherwise looks good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for answering my questions. Code looks good and events are working well.
@jeherve – I've merged this – I hope that's ok! Let me know if I need to do anything more to wrangle this change (e.g. changelog, other review tags). |
@haszari You're all set, nothing else to do! Thank you! |
* Initial changelog entry * Changelog: add #14904 * Changelog: add #14910 * Changelog: add #14913 * Changelog: add #14916 * Changelog: add #14922 * Changelog: add #14924 * Changelog: add #14925 * Changelog: add #14928 * Changelog: add #14840 * Changelog: add #14841 * Changelog: add #14842 * Changelog: add #14826 * Changelog: add #14835 * Changelog: add #14859 * Changelog: add #14884 * Changelog: add #14888 * Changelog: add #14817 * Changelog: add #14814 * Changelog: add #14819 * Changelog;: add #14797 * Changelog: add #14798 * Changelog: add #14802 * Changelog: add #13676 * Changelog: add #13744 * Changelog: add #13777 * Changelog: add #14446 * Changelog: add #14739 * Changelog: add #14770 * Changelog: add #14784 * Changelog: add #14897 * Changelog: add #14898 * Changelog: add #14968 * Changelog: add #14985 * Changelog: add #15044 * Changelog: add #15052 * Update to remove Podcast since it remains in Beta * Changelog: add #14803 * Changelog: add #15028 * Changelog: add #15065 * Changelog:add #14886 * Changelog: add #15118 * Changelog: add #14990 * Changelog: add #14528 * Changelog: add #15120 * Changelog: add #15126 * Changelog: add #15049 * Chanegelog: add #14852 * Changelog: add #15090 * Changelog: add #15138 * Changelog: add #15124 * Changelog:add #15055 * Changelog: add #15017 * Changelog: add #15109 * Changelog: add #15145 * Changelog:add #15096 * Changelog:add #15153 * Changelog: add #15133 * Changelog: add #14960 * Changelog: add #15127 * Changelog: add #15056 * Copy current changelog to changelog archive. * Clarify changelog description
This PR adds some extra properties to
woocommerceanalytics
events. For example, these properties allow us to filter events on WooCommerce version.Changes proposed in this Pull Request:
url
property to allwoocommerceanalytics
events.woo_version
property to allwoocommerceanalytics
events.pb0Spc-ou-p2
Is this a new feature or does it add/remove features to an existing part of Jetpack?
This adds features to the existing
woocommerce-analytics
module.Testing instructions:
Cash on delivery
payment method for easy test checkout - you can enable this inWooCommerce > Settings > Payment
.return true;
at the start ofJetpack_WooCommerce_Analytics::shouldTrackStore()
.pixel.wp.com
.woocommerceanalytics_product_view
event. This should have new properties (parameters)url
andwoo_version
, and the values should match the home url and Woo version (respectively).Proposed changelog entry for your changes:
(Not sure if this needs a changelog entry.)