add woo analytics event props for block/shortcode use in cart/checkout

[haszari]

This PR adds additional props to woocommerceanalytics events so we can filter based on how stores implement their cart & checkout pages.

New cart & checkout blocks are coming soon in the WooCommerce Blocks plugin. We're planning to evaluate these blocks by measuring conversion rates from the existing woocommerceanalytics events, in particular add_to_cart, product_checkout and product_purchase. To compare traditional and block-based UX, we need to add these new props to the events.

The new props are as follows. Values are 0 or 1, consistent with other boolean tracks props.

• cart_page_contains_cart_block
• cart_page_contains_cart_shortcode
• checkout_page_contains_checkout_block
• checkout_page_contains_checkout_shortcode

Changes proposed in this Pull Request:

• Utility functions for determining if a woo site is using shortcodes or blocks on the cart & checkout pages.
• Include this info as props on all woocommerceanalytics events.
• Cache this info in a transient (1-day life, jetpack-woocommerce-analytics-cart-checkout-info-cache).

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:

• This requires WooCommerce to be installed and set up on the site, with some products. Recommend setting up Cash on delivery payment method for easy checkout.
• The events are disabled for development sites. Use an incognito window, or hack this by adding return true; at the start of Jetpack_WooCommerce_Analytics::shouldTrackStore().

• Open network tab in browser dev tools, search for pixel.wp.com.
• View a product on the front end of your site. You should see a request for woocommerceanalytics_product_view event. This should have new properties (parameters) as above. Check that the values are correct. You'll probably have 1 for shortcodes and 0 for blocks.

If you install the current master branch of WooCommerce Blocks, you can add the cart & checkout blocks to the cart & checkout pages and retest - the values should show the correct info. If don't have blocks plugin and want to hack some more, you can fake this by adding an html comment that looks like the start of one of the blocks.

You can also test edge cases such as:

• Add the shortcodes and blocks to the pages, i.e. use both at the same time.
• Delete all content from the pages, or switch in some alternative cart or checkout solution (e.g. One Page Checkout).
• Add cart/checkout shortcodes/blocks to other pages (not cart/checkout page).
• Break your woo setup or skip onboarding so there is no designated cart/checkout page.

Note that this is cached in a transient for a day, so if you change your setup, you'll need to wait a day to retest, or delete the transient:

yarn docker:wp transient delete "jetpack-woocommerce-analytics-cart-checkout-info-cache"

Note: right now, the events are not all consistently firing for block-based cart & checkout (e.g. woocommerce/woocommerce-blocks#2031). For example, product_checkout only works with shortcode checkout. This is a separate issue and will be fixed in a separate PR. Please be aware of this when testing with blocks :)

Proposed changelog entry for your changes:

• Added props to WooCommerce Analytics events indicating if store is using blocks or shortcodes on cart & checkout pages.

[jetpackbot]

Thank you for the great PR description!

When this PR is ready for review, please apply the [Status] Needs Review label. If you are an a11n, please have someone from your team review the code if possible. The Jetpack team will also review this PR and merge it to be included in the next Jetpack release.

Scheduled Jetpack release: April 7, 2020.
Scheduled code freeze: March 31, 2020

Generated by 🚫 dangerJS against 7a6b95b

[jeherve]

This tests well for me. I only have minor remarks.

[deltaWhiskey]

I agree with the other reviewers' comments. Otherwise, looks good to me.

I only reviewed code, and did not test.

I'm concerned how this approach will work a year from now. If many features, such as these blocks, will result in properties being added to every woocommerceanalytics_ event, then the event data could become quite heavy. Especially with the verbose names of the new properties. I do like the self-explanatory names, though.

This is a non-issue if these are the only such properties that will be added in the foreseeable future. But, if more are coming, perhaps the properties should only be added to relevant events. Or a once-per-visit event could be sent with the details for this url.

[haszari]

I'm concerned how this approach will work a year from now. If many features, such as these blocks, will result in properties being added to every woocommerceanalytics_ event, then the event data could become quite heavy. Especially with the verbose names of the new properties. I do like the self-explanatory names, though.
This is a non-issue if these are the only such properties that will be added in the foreseeable future. But, if more are coming, perhaps the properties should only be added to relevant events. Or a once-per-visit event could be sent with the details for this url.

Good point @deltaWhiskey - I would definitely prefer to log these more "static" props using such an event. Let's keep this in mind as we iterate - I believe there's no standard mechanism for sending a once-per-visit event right now, so we'd need to develop that.

[haszari]

Feedback addressed & rebased the branch - please re-review when ready :)

@jeherve Should I address codeclimate issue (below) before merge? I could move post_contains_text() and get_cart_checkout_info() into a utility class perhaps.

File wp-woocommerce-analytics-universal.php has 292 lines of code (exceeds 250 allowed). Consider refactoring.

[jeherve]

Should I address codeclimate issue (below) before merge?

No need, I don't think it's really worth it.

Our CodeClimate configuration is still a work in progress; we need to update its configuration a bit more so it can provide more useful suggestions. Right now it can sometimes be helpful or provide an interesting point of view on how some things could be refactored, but really most of the time it's not super helpful imo. :)

[jeherve]

You'll want to update the transient name here as well, or make it a variable maybe to avoid further issues.

[haszari]

D'oh! Fixed here: 6bfc817

[haszari]

Ready for review again @jeherve :)

handled

[jeherve]

This looks good in my tests. 🚢