Add new events to the Analytics module

[pmcpinto]

Description: we want to take advantage of the existing Event Analytics module (p90Yrv-RL-p2) to improve our understanding of the shopper behavior at checkout and help merchants to improve their checkout conv. rate. We need to create a new event and update the woocommerceanalytics_product_purchase event to include more event props.
Ventures made some updates in this tracking last year: pb0Spc-ou-p2

Acceptance criteria:

• we need to add a new event to track the checkout view and all the payment options available:

woocommerceanalytics_product_checkout_view
payment_options: an array with the options available. Eg [paypal, stripe, cod, amazon]
express_checkout: an array with the options available. Eg [apple_pay] or [null] if they don’t display them
guest_checkout: Yes/No. Identify if the store allows users to checkout without an account
create_account: Yes/No Identify if the store allows users to create an account on checkout
device: mobile/desktop

• We can use the woocommerceanalytics_product_purchase event to track more information when the user finishes the purchase. We need to add the following event props:
  payment_option: the option that was used. Eg Stripe or COD
  express_checkout: if the express checkout option was used: Eg: Apple Pay or Null
  guest_checkout: if the guest checkout was used
  create_account: check if the shopper created an account (Y/N)
  device: mobile/desktop

[pmcpinto]

@elizaan36 let me know if you think if there's something missing that we should also include.

[elizaan36]

looks perfect!

[moon0326]

@pmcpinto It looks like we already have woocommerceanalytics_product_checkout event on the checkout page. Could we use it instead of creating woocommerceanalytics_product_checkout_view ?

[pmcpinto]

@pmcpinto It looks like we already have woocommerceanalytics_product_checkout event on the checkout page. Could we use it instead of creating woocommerceanalytics_product_checkout_view ?

Hey @moon0326 is this event fired only when the user views the checkout page? I'm under the impression that we're firing it when the user moves from cart to the checkout page

[moon0326]

Hey @pmcpinto the event gets fired even when the user access/refresh the checkout page directly.

BlYh8a.mp4

[pmcpinto]

Thanks for the clarification. The event description and notes made me think that it was only fired when the shopper was moving from the cart to the checkout:

This event measures how many times product proceeds from cart to checkout.. It fires when User proceeds to checkout.
One of these events is generated for each item in cart.

If woocommerceanalytics_product_checkout is fired on any checkout page view, then it makes sense to reuse it instead of creating a new one.

[moon0326]

Hey @pmcpinto after looking into the issue, I realized that it's going to be very hard to include express_checkout property for woocommerceanalytics_product_checkout_view event. The reason is that Apple or Google pay buttons are rendered in the frontend via Stripe. WooCommerce Analytics doesn't have any information about them in the backend. We can inject JS, but it's going to be very hacky as we need to initialize Stripe in WooCommerce Analytics when WooCommerce Payments already initialized it.

I think it's best to add a new method in WooCommerce Payments and use the method in WooCommerce Analytics.

I can make an issue in WooCommerce Payments and work on it. If we decide to work on WC Pay, we need to release WC Pay then WooCommerce Analytics (Jetpack)

We can add express_checkout to woocommerceanalytics_product_purchase without a problem though.

What do you think?

[pmcpinto]

@moon0326 thanks for the feedback. This looks like the best path forward:

I think it's best to add a new method in WooCommerce Payments and use the method in WooCommerce Analytics.

[moon0326]

@moon0326 thanks for the feedback. This looks like the best path forward:

I think it's best to add a new method in WooCommerce Payments and use the method in WooCommerce Analytics.

Sounds good. I've created Automattic/woocommerce-payments#2608 to get started.

[moon0326]

@pmcpinto A minor nitpick, but could we make express_checkout property type as a string instead of an array for the woocommerceanalytics_product_checkout_view event? The value is one of Apple Pay, Google Pay, and null. It's always a single value.

[pmcpinto]

@pmcpinto A minor nitpick, but could we make express_checkout property type as a string instead of an array for the woocommerceanalytics_product_checkout_view event? The value is one of Apple Pay, Google Pay, and null. It's always a single value.

Sure! That works for me

[moon0326]

@pmcpinto Sorry for the late notice. I just opened a PR for this issue and realized that express_checkout value in woocommerceanalytics_product_checkout_view event is only available when the user has WC Payment version 2.9.0+ installed. We had to make a change in WC Payment to get the value of the express checkout method and the change is only available in version 2.9.0+. Is this okay?

[pmcpinto]

No worries. Thanks for the heads up

[haszari]

Jumping in to review this – a couple of questions for @pmcpinto :

• What are the questions you want to answer by collecting this data?
• Is there a P2 with more info about how this data will be used? Specifically, have the data team advised on this?

I'll review the PR from a technical point of view for now. If I can get a clearer understanding of how this data will be used, that helps me review the PR :)

[moon0326]

Hey @pmcpinto,

I have a question about the express methods. I assumed that the express methods mentioned in this issue are express methods in WC Payment. @haszari raised a good point in the PR.

Should we also consider tracking express methods from other plugins such as Stripe? If so, it's going to take a little bit more effort to research as it is hard to track the usage of payment methods that are rendered on the client side and not under our control.

[haszari]

hard to track the usage of payment methods that are rendered on the client side and not under our control

Just a thought about this – I think it's possible to add WooCommerce Analytics (tracks) events in the front end code too. In fact this is how the PHP events are eventually sent. I'm not sure if this is used in the current events, but it should be possible.

[moon0326]

hard to track the usage of payment methods that are rendered on the client side and not under our control

Just a thought about this – I think it's possible to add WooCommerce Analytics (tracks) events in the front end code too. In fact this is how the PHP events are eventually sent. I'm not sure if this is used in the current events, but it should be possible.

We're actually tracking WC Payment's express method on JS side using WC Pay's action.

The tricky part is that express method availability is only available via Stripe API, but the Stripe object isn't available globally last time I investigated it.

We'll need to grab API key information from the Stripe plugin and initialize the object on our own. This feels a bit hacky to me.

I totally forgot that WooCommerce owns Stripe plugin 🤦

We can add a new action to this method just like we need in WC Pay to support Stripe plugin.

[moon0326]

@pmcpinto I totally agree with @haszari comment that we should also capture express methods used in the Stripe plugin.

My apologies. I should have raised this question when we estimated this issue.

The next Jetpack code freeze happens next Monday and I don't think we have enough time to implement Stripe.

Do you think we should postpone the release of this PR and include Stripe support?

[haszari]

There's some work in WooCommerce Blocks for wrangling different payment methods and whether they support express. This might be another option for detecting which methods and express methods are available on a store (or part of it!).

https://github.com/woocommerce/woocommerce-gutenberg-products-block/blob/trunk/src/Payments/Integrations/Stripe.php#L170

[pmcpinto]

What are the questions you want to answer by collecting this data?

As we (Transact and Start+Manage) started exploring the WooPay opportunity, we discovered that we have a huge gap in quant data about the shopper behavior at checkout. Namely, if they're choosing express checkout methods over other payment options, if they're creating an account at checkout or using the guest checkout, etc.

We're already tracking some shopper behavior, so we thought it would make sense to expand the event tracking we already have in place.

Is there a P2 with more info about how this data will be used? Specifically, have the data team advised on this?

We don't have a post specifically about this. AFAIR we talked with the data team about this (I don't remember if it was on Slack or a data request) and they don't have a way to get this kind of data. Legal gave the 👍 to move forward with this additional event tracking.

[pmcpinto]

@pmcpinto I totally agree with @haszari comment that we should also capture express methods used in the Stripe plugin.
My apologies. I should have raised this question when we estimated this issue.

No problem. Yes, we should also capture express methods used in the Stripe plugin.

Do you think we should postpone the release of this PR and include Stripe support?

Is there any difference in terms of effort if we stagger them? (WCPayments now and Stripe next). The sooner we can start getting data on this and validate if it's working correctly, the better. If we skip this JP release, we'll need to wait one additional month or more until this is shipped.

[moon0326]

Is there any difference in terms of effort if we stagger them? (WCPayments now and Stripe next). The sooner we can start getting data on this and validate if it's working correctly, the better. If we skip this JP release, we'll need to wait one additional month or more until this is shipped.

@pmcpinto Since we already have the base functionality working, it's going to be very similar.

I think we can ship WCPaymeents first and follow up later.

[pmcpinto]

@moon0326 I spoke with Rua today and he suggested that it would be helpful to double-check with Woo Data if they're ok with this approach. So let's wait until the upcoming JP release to ship everything. Do you agree?
If yes, can you share here a summary of the technical implementation? I'd like to share a post explaining this tomorrow or Wednesday and it would be great to include this summary. Thanks!

[pmcpinto]

Hey @moon0326 I don't know if you saw the comment I posted yesterday :)

[pmcpinto]

@moon0326 @haszari I chatted with @thenbrent this morning, and the sooner we start getting this data, the better. So let's move forward with this implementation and fine-tune it later if necessary. Moon, can you confirm that all the new props outlined in the description will be shipped? Thanks!