Add cart, checkout, and order confirmation pageview events to the woocommerce-analytics module

[pmcpinto]

Description: the woocommerce-analytics module doesn't include any data on the cart, checkout, and order confirmation pageviews. These data points are critical to understanding how the cart and checkout blocks and shortcodes are performing regarding conversion rate.
For example, we already have one for the product page view: woocommerceanalytics_product_view
This will need to be implemented in the Jetpack repo. More info about prior art here: pb0Spc-ou-p2#comment-701

Acceptance criteria:

• Create a new event that should be fired when the shopper visits the Cart page:
  Event name: woocommerceanalytics_cart_view
  Event properties:

• Existing properties from woocommerceanalytics_product_checkout: pp, pq, pt, r3d, ui, url, woo_version, cart_page_contains_cart_block, cart_page_contains_cart_shortcode, checkout_page_contains_checkout_block, checkout_page_contains_checkout_shortcode, create_account, device, express_checkout, lr, or

• New properties from woocommerceanalytics_product_purchase (see Add new event properties to product checkout and purchase Tracks events #9729): number_products, order_value, additional_blocks

• New properties: shipping_options_count: the number of shipping options available
  template_used: if the page is powered by a template or regular page

• Create a new event that should be fired when the shopper visits the Checkout page:
  Event name: woocommerceanalytics_checkout_view
  Event properties:

• Existing properties from woocommerceanalytics_product_purchase: pp, pq, pt, r3d, ui, url, woo_version, cart_page_contains_cart_block, cart_page_contains_cart_shortcode, checkout_page_contains_checkout_block, checkout_page_contains_checkout_shortcode, create_account, device, express_checkout, lr, or, guest_checkout

• New properties from woocommerceanalytics_product_purchase (see Add new event properties to product checkout and purchase Tracks events #9729): products_count, order_value, additional_blocks

• New properties:
  shipping_options_count: the number of shipping options available
  payments_options_count: the number of payments options available
  express_checkout_count: the number of express options available
  shipping_options_list: array with the shipping options available
  payments_options_list: array with the payments options available
  express_checkout_list: array with the express options available
  template_used: if the page is powered by a template or regular page

• Create a new event that should be fired when the shopper views the Order Confirmation page:
  Event name: woocommerceanalytics_order_confirmation_view
  Event properties:

• Existing properties from woocommerceanalytics_product_purchase: pp, pq, pt, r3d, ui, url, woo_version, cart_page_contains_cart_block, cart_page_contains_cart_shortcode, checkout_page_contains_checkout_block, checkout_page_contains_checkout_shortcode, lr, or, payment_option, device, create_account, guest_checkout

• New properties from woocommerceanalytics_product_purchase (see Add new event properties to product checkout and purchase Tracks events #9729): products_count, order_value, additional_blocks, shipping_option, order_note

• New properties:
  template_used: if the page is powered by a template or regular page

Ideally, we should include this change in the next Jetpack release.

[wavvves]

@pmcpinto since this also regards page-used blocks, and therefore not template-specific, should it be considered a blocker for releasing the template work? The only update brought by the template branch would be related to template_used

[pmcpinto]

@pmcpinto since this also regards page-used blocks, and therefore not template-specific, should it be considered a blocker for releasing the template work? The only update brought by the template branch would be related to template_used

Suppose we don't treat this as a blocker, in which Blocks and Core versions can we get the templates available?

[wavvves]

Suppose we don't treat this as a blocker, in which Blocks and Core versions can we get the templates available?

@pmcpinto We were aiming for Blocks 10.5.0 (June 19) and WC 8.0, but I don't think we can test properly in time (also I'm AFK next week), so I would propose a change to Blocks 10.6.0 (July 3), being released on WC 8.0 also ( code freeze is July 17, so two weeks of live testing on the feature plugin)

[pmcpinto]

That timeline seems fine. In the meantime, we can find someone else to handle the instrumentation improvements during cycle 4. cc @ralucaStan

[ralucaStan]

@pmcpinto just to confirm, you are talking about #9250 as something that could be worked on in Sprint 1?

[pmcpinto]

@ralucaStan yes. Regarding the instrumentation improvements, I think that #9250, #9571, and #9729 should be treated as a priority for sprint 1

[ralucaStan]

Please add your planning poker estimate with Zenhub @mikejolley

[opr]

Hi @pmcpinto I am working on implementing this, I have a question about the properties on the new pageview events.

You're asking for several new properties to be added to these events, including these specific ones:

pp, pq, pt

Just want to check, these refer to specific items in the cart, so it doesn't make sense to include this property on a single pageview event. So, my question is: Do we want to track an individual pageview event for each product in the cart? This doesn't seem right so I wanted to clarify, do we remove these properties or send multiple events?

Relating to r3d, lr, and or, do you know if these are tracked automatically when submitting the event? I don't see references to them in the analytics module.

[pmcpinto]

Do we want to track an individual pageview event for each product in the cart? This doesn't seem right so I wanted to clarify, do we remove these properties or send multiple events?

Yeah, firing individual page views for each product included in the cart doesn't make sense. Can you check how these properties are recorded in the woocommerceanalytics_product_purchase?

Relating to r3d, lr, and or, do you know if these are tracked automatically when submitting the event?

Mmm they aren't global event properties, but maybe they're tracked automatically. I don't see a reference to these props in the original PR: Automattic/jetpack#8296
These 3 props are a nice to have. We can check how to add them later, in case they're no tracked automatically.

[opr]

Hi @pmcpinto I have been doing more work on this today, seems like they are included by something higher up when sending the event, so we get them for free.

Can you check how these properties are recorded in the woocommerceanalytics_product_purchase?

Looks like an individual woocommerceanalytics_product_purchase event is fired for every item in the cart. I just checked out with three items and saw three requests. I am waiting for the Tracks events to catch up then I'll check there.

[pmcpinto]

Hi @pmcpinto I have been doing more work on this today, seems like they are included by something higher up when sending the event, so we get them for free

Thanks for the confirmation.

Looks like an individual woocommerceanalytics_product_purchase event is fired for every item in the cart. I just checked out with three items and saw three requests. I am waiting for the Tracks events to catch up then I'll check there.

Gotcha. Applying the same approach to page views would be weird. An alternative is to use an array for each property. But that could be messy, especially for the pp (product price) prop. Is there any other option that we could consider?

[opr]

Gotcha. Applying the same approach to page views would be weird. An alternative is to use an array for each property. But that could be messy, especially for the pp (product price) prop. Is there any other option that we could consider?

I think an array makes sense, I can't think of another way to pass this data. Whether we can send an array to Tracks is something we'll need to experiment with, and it'll need some significant changes to the existing code accomplish.

Nadir also mentioned that we won't know things like shipping_options_count and payments_options_count until the user has entered their address, so wondering if we should register different events to track these (e.g. woocommerceanalytics_address_updated or similar, where we'd track the new cart state).

[pmcpinto]

I think an array makes sense, I can't think of another way to pass this data. Whether we can send an array to Tracks is something we'll need to experiment with, and it'll need some significant changes to the existing code accomplish.

There are properties in other events that use an array, so I think it's possible. How long do you think it would take to implement this piece?

Nadir also mentioned that we won't know things like shipping_options_count and payments_options_count until the user has entered their address, so wondering if we should register different events to track these (e.g. woocommerceanalytics_address_updated or similar, where we'd track the new cart state).

This happens only in some use cases, right? Here are two screenshots where I'm getting the payment options without adding an address

[opr]

There are properties in other events that use an array, so I think it's possible. How long do you think it would take to implement this piece?

Ok, should be fine then, I'd say a day or a little over to implement.

This happens only in some use cases, right? Here are two screenshots where I'm getting the payment options without adding an address

Yes, true, the payment methods can change in some cases, however shipping options are more likely to change in most cases, we won't know the correct shipping options until the address has been entered.

[pmcpinto]

Yes, true, the payment methods can change in some cases, however shipping options are more likely to change in most cases, we won't know the correct shipping options until the address has been entered.

Ok. So it's safer to create two additional events: one for the payments options another one for shipping

[opr]

After asking in p1693586277232899-slack-C03DKP1JP we are going to store the products as an array but it will need to be parsed when processing the data to be readable.

[opr]

@pmcpinto - for the order confirmation pageview, how critical is it that we include shipping_option in each product? Is this something we can skip for now and try to figure out later?

This is going to be hard to track without inserting additional metadata to the order, which is possible, but would require a complex structure to match products back to their shipping methods.

[pmcpinto]

Sorry, I missed this ping last week.

@pmcpinto - for the order confirmation pageview, how critical is it that we include shipping_option in each product? Is this something we can skip for now and try to figure out later?

That prop can be included in a future iteration. Thanks!

[senadir]

This is now done.