Simon

Hey @xiaobijou!

Thanks for reporting this issue, I’d be happy to take a closer look at this for you. It sounds like this may be an issue with the Facebook scripts that display and load the messenger chat, though I’d be happy to take a closer look in case there’s anything we can suggest to work around the problem.

I’m not currently seeing the issue on my local test, so it would be great to see it in action on your site! It looks like you may have disabled messenger entirely for the time being, as I don’t see the pop up at all at the minute, is that right?

If so, I completely understand, especially if it blocks your iPad users using Safari from browsing anywhere else on the site! In which case, would it be possible to get access to a staging or demo site where we could take a closer look?

Cheers!

Simon.

Hey @casedigital,

Thanks for following up with the logs! These errors usually indicate a mismatch between the stored metadata in WooCommerce, and the actual ID of the product in Facebook. This can sometimes happen if the products in Facebook are deleted, or adjusted in a way that creates a new product ID. Facebook does not feed this back to the WooCommerce store, as the sync process is one way.

Usually, it’s quick to remedy this by deleting the Facebook metadata from the product by navigating to Products > All Products, selecting the product this is causing the error, and clicking the reset link in the Facebook side panel box: https://cloud.skyver.ge/WnuJbjNk

Would it be possible to give this a go for the products that are causing the issue and let me know if that does the trick?

Cheers!

Simon.

Hey @austenite,

Thanks for getting back to me! That’s some useful information for sure. We heard from Facebook late last week that they are planning a fix for the “Oops!” error, or at least, what they’ve found to be the most common reason for that error. Apparently this screen is a general catch-all for the issues happening during the store link flow, which is one reason it’s been hard for them to nail this down.

I’m waiting for confirmation on when the fix might be rolled out (or if it has already been rolled out!) today and will circle back around as I hear more. While I don’t think this will solve the multiple system user’s problem that you’re seeing – it might allow the connection to succeed and for the store to carry on syncing. The system users would then be resolved at a later date with the fix they mentioned previously.

I’ll keep an eye on the messages from their team today and will let you know as soon as I hear more. Thanks so much for your patience so far!

Cheers,

Simon.

Hey @ralphward,

I spoke with our developers just now who gave a little more insight of the error as they understand it. They mentioned this is likely to occur when the Facebook setup process tries to assign the ad account to the system user. They think this could happen if the selected Ad Account cannot be managed by the selected Business that the System User belongs to.

If you’d be willing to try, if we try to perform this action manually inside Business Manager, it may give us a different error to work with or pass along to Facebook.

Please could you:
– log into Business Manager
– Make sure to select the same Business that was used in the setup process
– Click Users > System Users
– Select the Partner Created System User and click Add Assets
– Click the Ad Account available for the business, and make sure to toggle the “Manage Ad Account” permission from the right-hand side: https://cloud.skyver.ge/04uq14N6
– Finally, click Save Changes.

Could you let me know if that works as expected or if it also throws an error?

Cheers!

Simon.

Hey ,

Thank you for writing in and sharing all the details you have so far, that’s a great help! We’re currently aware of some issues with the latest API we use to connect your store to Facebook, and our developers and the support team are working with Facebook to gather as much information as possible to help them diagnose what might be happening.

Information like this is a great help, so thanks again! I’ll pass this on to our contacts and circle back around here once I have a further update.

In the meantime, are you seeing the same issue again today if you re-attempt the connection? If so, it would be great if you could contact us directly so that we might gather Facebook-specific information to help them diagnose the platform issue.

To do so, please could you raise a support request via our support form and mention this topic link so that I can look out for you?

Cheers!

Simon.

Hey @rez009,

Thanks for the kind words, I’m so glad you enjoyed the new setup process! We think the closer connection to Business Manager will make things a lot easier in the long run, so we were super glad to be able to get this out. As well as bring back our sync features we had added previously too!

I only wish we could have found these connection errors before release. We did testing on our own test accounts without issue, and Facebook performed some user testing as well, and nothing cropped up, which is really maddening. There seems to be some nuance with the way individual accounts are set up that causes an error with the final connection logic. We don’t have direct access to the error logs on Facebook side and don’t have access to the merchant account configuration either (Without asking for many many screenshots), and so it’s been quite problematic to help investigate.

We’ve been working with Facebook ever since the new release though and gathering as much info as we can. They mentioned they rolled out the fix on Friday but as you say, it could have been a gradual rollout that only just reached you, or could be a further fix we weren’t informed about. They are still investigating the latest batch of issues that we’ve had reported, so hopefully, we’ll have some concrete info soon.

I also tried the process you mentioned too, in case there were some mixup during that part of the setup, without luck. Though it’s great you’ve shared this here in case other merchants have similar luck.

Thanks again for keeping me in the loop, and I’m glad that at least one more merchant has been able to connect okay now too ?? On to the rest!

Is there anything else I can help out with today?

Cheers,

Simon.

Hey all!

We received word from Facebook that they deployed a fix for this issue on Friday, though as of yet, it’s not clear if this was a staggered rollout or a complete release.

Our team is already tracking this issue and working with Facebook to resolve it as soon as possible. In the meantime, we’d really appreciate it if you can use our contact form to reach out to us about our plugin in case we need more information.

You can click here if you’d like to proceed.

Cheers,

Simon.

Hi @viktormorales,

Thanks for the question. There are two options for adjusting the price sent to Facebook with the plugin. The first, being the simplest, is to edit the Facebook price field which is available on the edit product page > Facebook tab: https://cloud.skyver.ge/qGuNw6A1

The second is to use one of the plugins available filters, namely: facebook_for_woocommerce_integration_prepare_product, which is given the $product_data and $id. This will then allow you to adjust the $product_data[‘price’] field.

As Jennifer mentioned, I’m afraid we don’t cover directly implementing custom code, though I hope this gives you something to work with!

Is there anything else I can help out with today?

Cheers,

Simon.

Hey @gevcen,

Thanks for letting us know! The error you first saw looks to be due to a permission error, so it’s quite possible it took a little time for Facebook to refresh the access token or the product data as you’ve mentioned.

It sounds like you’re all set now though, which is great to hear! Is there anything else I can help out with today?

Cheers!

Simon.

Hi @anguschang007,

Thanks for letting me know. If the ACF workaround is doing the trick, then that’s great news!

If there’s anything else I can help with, please don’t hesitate to reach out again.

Cheers,

Simon.

Hi @anguschang007,

If you were using the feed file from our plugin, based on the contents of the latest field file downloaded earlier, then the item_group_id should not mismatch the pixel event.

There seems to be two issues in this topic that seem to be crossing over each other, and I’m not sure which we’re looking to solve. So it would be great if you could clarify for me.

– The item_group_id does not match the pixel ViewContent event content_id. This is because the data in the Catalog Manager does not match the data sent by our plugin when syncing products. Instead, we can see it does match the feed file generated by Woo Product Feed Pro. This suggests that you are not using our feed file for syncing the products, or if you are, the Woo Product Feed Pro file is updating/replacing the data.

– The affiliate products are not being synced via our plugin. This is an outstanding issue that we would need to look into further to see why they aren’t being added to the file.

My understanding here is that because you are already using the Woo Product Feed Pro for syncing your products, and because you mentioned needing the google_product_category data (as well as the affiliate products we’d have to investigate), the better solution seems to be to switch pixel tracking over to Woo Product Feed Pro too.

If you were to use pixel tracking with their plugin, you would have matching products and ViewContent content_id’s. You’d also still be able to sync the affiliate products, and you mentioned that it provides the google_product_category too.

If you would like to continue using our plugin for syncing and pixel tracking, then I’d suggest deactivating the Woo Product Feed Pro from generating their own XML feed file for syncing. This should allow our plugin to sync the item_group_id’s correctly, and that will match the contetn_ids in the pixel event too. We can then investigate the affiliate products issue, though we currently don’t support google_product_category data.

Could you please confirm for me which issue above is the one you’re looking to solve at the moment?

Cheers,

Simon.

Hi @anguschang007,

Thanks for sharing that. It’s interesting they link to a blog post that details the exact issue you’re experiencing here! The fix they recommend is to allow them to implement the pixel for you, so that the content_id’s match the feed ID’s.

This would be one further option that could work immediately! As you are not using the feed file generated by our plugin already, if you wanted to switch over pixel tracking to use their implementation, you would not need our plugin at all and would have affiliate products synced too.

If you’d prefer to use our plugin for both pixel tracking and product syncing, then I’d be happy to look into the Affiliate product sync issue further for you.

Could you let me know if you’d like to use our plugin, or if you will be testing switching the pixel implementation over to Woo Product Feed Pro?

Cheers,

Simon.

Hi @anguschang007,

From the feed file you’ve uploaded it shows that our plugin has generated the item_group_id as ISP001_2657 which is what we’d expect and require for the pixel events to match. Yet your screenshot from the Catalog Manager shows that the item group ID has been set to ISP001 instead.

This seems like the data has been adjusted outside of our plugins sync, or you are not using our generated CSV file. The most likely cause here is that Product Feed Pro is generating the feed file (their XML) and this is being used to sync products to your Facebook Catalog. We can see from the XML file you uploaded earlier that the item_group_id is set to ISP001 which matches the catalog display at the moment.

This means that there is a conflict between the item_group_id used by Woo Product Feed Pro, and the content_id tracked by the pixel included with our plugin. Either the content_id needs to be adjusted to match product feed pro group_id, or the group_id within product feed pro needs to be adjusted to match the pixel event.

The only way to adjust the content_id’s being tracked with our plugin would be through custom code that would require the help of a developer.

> “However, I don’t think Product Feed Pro will have a solution for this issue. They are only trying to get the attribute from the current WordPress properties. They don’t generate any data!”
They are generating data that gets inserted into the XML file. I suggest reaching out to their team to see if it’s possible to adjust the item_group_id to be of the format <sku>_<parent_product_id>. This might be something they’ve had asked before, or maybe possible through the plugin settings. I’m afraid I don’t know the plugin or the code enough to be able to say.

Once you hear back from them, could you let me know what they suggest?

Cheers,

Simon.

Hi @anguschang007,

I don’t have an exact release date to share at this time, as our product team are still assessing what the implementation looks like and scoping it out for development. Work has not yet started on this from the development side of things.

I would suggest keeping an eye on the plugin changelog to see when this gets introduced.

If you will be continuing to use Woo Product Feed Pro in the meantime, will you be reaching out to their team to see if it’s possible to change the item_group_id or will you be looking into the code customization for the pixel tracking?

Cheers,

Simon.

Hi @anguschang007,

Thanks for confirming. In which case, we would want to make sure that it has not been added to the feed file, or if the feed file has not synced correctly to Facebook. For that, I would need a copy of the feed file as requested previously.

At the moment I am unsure which method you are using for syncing products given the Woo Product Feed Pro plugin seems to be in use. It now sounds like you would want to use our plugin instead, yet these issues are preventing you from doing so, is that right?

If affiliate items were syncing correctly, would you be able to use our product sync to resolve the issue raised here, or would you still be using Woo Product Pro?

Cheers,

Simon.