Michael K

Hi,

Thanks for reporting this, I was able to reproduce this problem so I’ve recorded it as a bug here: https://github.com/woocommerce/google-listings-and-ads/issues/1411

It looks like the caching of the values has been broken for a while though. So I’m curious how it used to work before on your site. Did you have any additional code snippets to override these attributes?

For future reference, for anyone else coming across this thread. The error message

Your URL, , is currently claimed by another Merchant Center account

is being incorrectly reported for the wrong scenario.
We are working to resolve this.

One such scenario is a case where the authentication scopes have not been granted. The best way to resolve that is to follow these steps:

1. Revoke the previous access permissions to your Google account so you can reconnect. Open the Security tab for your Google account: https://myaccount.google.com/security
Click on the link “Manage third party access” and then remove access for the WooCommerce app.
2. Go to Dashboard > Marketing > Google Listings & Ads and reconnect your Google account, making sure to grant all requested scopes by checking the boxes.

Image link: https://cloudup.com/cGfof0nAikr

3. Reconnect your Merchant Account

• This reply was modified 3 years, 7 months ago by Michael K.

Hi there,

Thanks for the report of the discrepancy.

There could be many reasons why the sales aren’t being tracked through Google Analytics, some of which are described here: https://docs.woocommerce.com/document/google-analytics-integration/#testing-analytics

Also the payment gateway being used for the purchase can make a difference. The Google Analytics extension only tracks the sale by users visiting the WooCommerce thank you page once the order has been completed and paid for. Depending on the payment gateway the order might be marked as paid at a later stage, which means it won’t be tracked as a sale. Or not every user might be visiting the order thank you page, as in some flows the last step is to redirect back to the starting website, although this isn’t always mandatory.

If your payment gateway isn’t compatible with this flow then one option would be to upgrade to the Google Analytics Pro extension: https://woocommerce.com/products/woocommerce-google-analytics-pro/
This extension uses a different method of tracking when a sale has been completed.

• This reply was modified 3 years, 7 months ago by Michael K.

Hi @kit1103,

Thanks for the report. It seems your site is using WordPress 5.4.6, whereas the function which is required by the Jetpack connection package was only added in WordPress 5.5

We are going to be doing some revisions on minimum required versions, but at the moment the easiest solution would be to upgrade WordPress to a version later then 5.5.

Cheers

Hi Steph,

Thanks for the clarification. In this case I would still suggest to have a look at the Google Analytics Pro extension since it handles tracking of this scenario completely differently: https://woocommerce.com/products/woocommerce-google-analytics-pro/

It allows tracking based upon specific events which happen on your site: https://docs.woocommerce.com/document/woocommerce-google-analytics-pro/#section-5
As well as allowing you to setup a custom checkout funnel to track how your users are making purchases on your site: https://docs.woocommerce.com/document/woocommerce-google-analytics-pro/#section-6

Hi Vishal,

The hook passes an order object so you don’t need to use wc_get_order to retrieve an order object. Here is a code example which works without issues on my site:

add_action( 'woocommerce_after_order_object_save', 'custom_export_pending_order_data' );
function custom_export_pending_order_data( $order ) {
	$logger = wc_get_logger();
	ob_start();
	var_dump( $order->get_id(), $order->get_status() );
	$logger->debug( ob_get_clean(), array( 'source' => 'log-order-data' ) );

	if ( 'pending' === $order->get_status() ) {
		// Do something here.
	}
}

The first few lines of the function are just for logging to confirm we are getting the data we are expecting. You can view these log files in WooCommerce > Status > Logs.
The if statement shows how you can compare the order status.

Hi there,

Both those hooks work on my test site, with just a plain copy of WooCommerce. So if it isn’t working for you, then I’d suggest to have a closer look at either trying a conflict test: https://docs.woocommerce.com/document/how-to-test-for-conflicts/

Or alternatively to add some logging to your function, so you can determine whether the order and order status are actually what you are expecting it to be.

Hi,

Do you recall what was updated in the last week, to see if you can revert just that change to narrow down what might be causing the issue?

Alternatively do you have a staging/test site where you can demonstrate how the code is being added to the page? From the error it still does look like the code is loaded in the wrong order but it would be easier to look at a live example.

A staging site could also be used for doing a complete conflict test, like the one that’s described here: https://docs.woocommerce.com/document/how-to-test-for-conflicts/

Hi there,

You should be able to use either the hook “woocommerce_new_order” or the hook “woocommerce_after_order_object_save”

With the hook “woocommerce_after_order_object_save” it passes an instance of the object. So in that case it will be a “WC_Order $order” object and not the order ID. This would make the extra call to “wc_get_order” unnecessary. But it’s not an explanation why it fails.

You mentioned it works when manually creating an order but not at checkout. Did you confirm that you started a completely new checkout session? Otherwise if the order has already been created WooCommerce will try and use a previously existing order at checkout.
I’d also suggest testing with a different payment gateway since it is possible to override the way the initial order is created at checkout.

You can also add some logging to the hook you are using so you can confirm you are checking the right data and see what the actual order status is at the time your hook is being called. The following suggestions might be helpful there: https://nickgreen.info/logging-errors-in-woocommerce/

Hi there,

If you have a look in your status report which you can find in WooCommerce > Status there is a section which shows database tables.

Can you have a look there to see if all the database tables needed for the plugin to work have been created? Here is the list you should see:

wp_wc_order_stats
wp_wc_order_product_lookup
wp_wc_order_tax_lookup
wp_wc_order_coupon_lookup
wp_wc_admin_notes
wp_wc_admin_note_actions
wp_wc_customer_lookup
wp_wc_category_lookup

In particular the table wp_wc_order_stats is needed for collect the order data.

Note: The prefix might be slightly different on your site, in that case you would just be matching the rest of the table name.

Hi Steph,

In order to track the purchase data, it requires a payment gateway that redirects to the thank you/order received page after payment. Orders paid with gateways which do not do this will not be tracked.

If you are in the situation where you’re payment gateway doesn’t always redirect the customer to the thank you page then it’s best to use a different plugin which handles tracking differently. The following plugin can be used for this: https://woocommerce.com/products/woocommerce-google-analytics-pro/

Hi there,

Would you be able to confirm if you are seeing any tracking data show up in your Google Analytics such as when a product is added to the cart or when the checkout page is viewed. I had a look at your WooCommerce pages, and I do see the data being sent over to Google at the various stages. Although I haven’t completed a full checkout.

Any administrator user is excluded from tracking. So can you make sure you are testing while being logged out (or optionally a customer account). Generally the tracking for the purchase will be done as soon as the user visits the checkout thank you page.

I’d suggest to test with the Chrome Extension Tag Assistant to make sure tracking is being sent at each stage of the checkout, you can find this here: https://get.google.com/tagassistant/

Hi there,

Thanks for sending that through. In the System Status Report it mentions you are using a caching plugin. That plugin has the option to minify or combine JavaScript. Are you using that in the plugin?

The way the Analytics plugin works, it initially includes the tracking script which will define the variable ga in the header. Then it will have some additional JavaScript which is added to the footer, which will use the previously defined variable ga.

Based on the error it looks like the part in the header is either not loaded correctly, or loaded at a different time / later. This is something which can be caused by minification or combining JavaScript. Can you check if disabling this works. If it does them you might want to find a way to exclude the scripts from the plugin to make sure they aren’t changed in any way.

Hi,

Thanks for passing on the behaviour you are seeing with version 1. I’ve passed on those details as well, although we currently aren’t expecting to be implementing any more changes to the version 1.

With regards to the difference you are seeing. Version 2 also does the validation of the WooCommerce fields once all the card fields have been validated. Although one of the card fields is the postcode, which isn’t updated till all the required billing address fields are populated. The developers are also working on some different changes there.

Hi @kubawlasny,

We haven’t heard back from you in a while, so I’m going to mark this as resolved – if you have any further questions, you can start a new thread.