content_ids including SKUs creates dublicates on FB when SKU changes

Hi Jesper,

This sounds like an interesting topic. Could you please share a step-by-step guide on how to replicate this behavior and share screenshots of the fields you are referring to?

I did not experience this behavior and did not read one from a user.

Please confirm the Facebook for WooCommerce plugin version too.

I recommend https://snipboard.io/ for easily sharing screenshots – please follow the instructions on the page, then paste the URL(s) in your reply.

Hi,

I am using the latest version 2.3.5, but this is not a new issue for me, it has been there for a long time now. It is only a problem if you ever change SKU’s, which in my case I do from time to time, as I use the SKU as the location in the warehouse, which can change.

Steps to reproduce:
– Change the SKU of the product in Woocommerce, update the product
– This creates a new product in the FB catalogue, the ”old product” is also still in the catalogue

So this is messing up the catalogue, since over time, if SKU’s are changed, dublicates are created. And I also guess this have an impact on advertising and retargeting, because people then will see old prices, outdated products, and products not in stock etc.

As I see it, it basically comes down to the function starting on line 92 in ”includes/fbutils.php”:

”public static function get_fb_retailer_id( $woo_product ) {
$woo_id = $woo_product->get_id();
// Call $woo_product->get_id() instead of ->id to account for Variable
// products, which have their own variant_ids.
return $woo_product->get_sku() ? $woo_product->get_sku() . ‘_’ .
$woo_id : self::FB_RETAILER_ID_PREFIX . $woo_id;
}”

This code includes the SKU in the content_id if a SKU exists, and only if there is no SKU, the content_id will be like ”wc_post_id_123” (123 is product id). I would prefer it to be like ”wc_post_id_123” all the time, so that it never changes, even if SKU is changed.
I would rather not edit directly in the plugin files, so a quick solution could be to include a filter in this function. Then the code could be modified through the filter if thats of interest, which it is in my case. People who never changes the SKU probably does not experience a problem.

So a solution could be to adjust the function to this:

”public static function get_fb_retailer_id( $woo_product ) {
$woo_id = $woo_product->get_id();
// Call $woo_product->get_id() instead of ->id to account for Variable
// products, which have their own variant_ids.
return apply_filters( ‘facebook_woocommerce_fb_retailer_id’, $woo_product->get_sku() ? $woo_product->get_sku() . ‘_’ . $woo_id : self::FB_RETAILER_ID_PREFIX . $woo_id, $woo_product);
}”

Please let me know whether it could possible to fix this issue ??

Thanks for the details! ??

We’re running this by our developers to see if this behavior is expected, or if it’s an issue we’ll consider solving.

Please standby for now while we work on getting you an answer. Thanks!

Hi Adam, thank you for this ?? Looking forward to hearing from you ??

Hi there,

Thanks for your patience while our developers looked into this.

The behavior you’re seeing is expected: it comes down to the fact that SKUs don’t usually change – they are set for the life of a product (a key expectation of an SKU).

Since in this case the SKU field is being used as a variable identifier of warehouse location (it changes), it’s causing the duplication issue you’ve been seeing.

We’ll continue evaluating this approach over the long term, but for now, I recommend using a different field for tracking your items in the warehouse and keeping SKUs constant.

I hope this information is helpful for you – please let me know if you have any further questions!

Hi Kwesi,

Thank you for your reply.

I think there are issues in this, especially since in Woocommerce, you cannot set the same SKU (Stock Keeping Unit) for different products. But if you have a larger store, then for different brands the SKU could be the same in theory. In my store there are several of these examples. For instance 2 different brands could have the SKU “KIT012” for a product. This is also one reason why the SKU field makes sense to use as a warehouse place indicator instead, since products cannot be at exactly the same spot in the warehouse, so therefore this functionality (that the SKU has to be unique in Woocommerce) makes sense here.

In reality the SKU provided by the supplier does also change some times, and other times you will discover later that the first SKU you inserted is wrong or misspelled, or you forgot to insert a SKU when you first created the product etc. So just like changing the product name does not create a dublicate product, I do not think there is a reason for why changing the SKU should.

Besides this, the FB content_id should in the end just be a unique ID, so I do not see the reason why it is necessary for it to include the SKU anyway, as long as the post ID of the products can just be used (which it also is already when SKU is absent).

I agree that many probably use the SKU field as you say (which though could still give issues as explained above). And even if they use it as I do, many do not change the warehouse location frequently enough that it has any huge impact anyway, and if it has happened many are probably not aware. This is why I suggest that the Facebook for Woocommerce plugin just provides a bit of flexibility on this issue, since in the end it does not matter whether the SKU is in the content_id anyway. This could be solved by implementing the suggested filter. Then the user of the plugin can decide whether or not the SKU field should have any impact on the created content_id.

Please let me know whether I am missing anything in regards to why it should be important to include the SKU in the content_id, when it is not absent.

Hi @jesperh95,

It would be great to have you add your ideas to the [Ideas Board](https://ideas.woocommerce.com/forums/133476-woocommerce), which is where developers go to look for future plugin features and improvements.

Meanwhile, we are still checking this out with the developers.

I’ve been encountering an issue with Facebook showing ads with outdated pricing or stock, and customers complaining as a result. After a lot of head scratching it seems to be exactly the same issue that @jesperh95 is describing. We’re gradually migrating to a new SKU system and are changing SKUs to the new format as we bring in new stock. When we update old SKUs it’s leaving ‘ghost’ items in the Facebook catalogue, which have the old SKU but are unconnected to any live product (so just stay live and stuck on whatever price, stock level etc. they were on when the SKU changed). They are still live, they’re still eligible for ads and they still link to the product listing, even though the price etc. might be different to what’s shown in the ad, or even if the product when out of stock long ago.

Unlike GTINs, MPNs etc. there’s no standardised way that SKUs should be used and retailers use them in numerous ways; in whatever way best suits their business. So whilst generally they usually stick with the product for its lifetime, many retailers don’t use them in that way, and even if they do (like us) if you’re managing an ecommerce site with thousands of products, like @jesperh95 says it’s unavoidable that SKUs will change sometimes for all sorts of other reasons – updated versions of products, warehouse management changes, third party software, supplier changing their SKUs, human error etc. Even if you believe that SKUs should only be used in one way and should never change, it still doesn’t really make sense to use an easily editable and non-required field as part of a unique identifier? As @jesperh95 says there doesn’t seem to be a good reason to use it when it works perfectly fine if you don’t have a SKU at all?

Even if it’s expected behaviour that the SKU is appended to the post ID, surely it’s not expected behaviour that the product with the old content_ID is left hanging around in the Facebook catalogue, orphaned from any Woocommerce product? If it couldn’t be overwritten by the ‘new’ product, it could at least be deactivated in the catalogue? It’s not a “duplication issue” as such – because the item that is left in the catalogue is not in sync with the live/correct item.

The problem is compounded by the fact that when trying to manually correct the issue in Facebook Commerce Manager, there’s no way as far as I can see to filter and edit catalogue items in bulk, so you have to go through and find and deactivate each ‘ghost’ variation one by one. This would be a nightmare for us with the number of affected products, so the alternative is to delete and re-add the feed but a) this will presumably mess up the learning that the ad algorithm has built up with the catalogue and b) it’s not going to stop the issue just happening again next time we have to change a SKU for some reason.

I appreciate that a second voice won’t suddenly convince you that this is a bug, but I would imagine that there are lots more affected users who haven’t yet realised there are live items sitting in their Facebook catalogues that don’t accurately reflect the products that they link to, and it will no doubt be impacting their ad performance.

If you got this far thanks for sticking with me! ??

I just discovered this issue too. Found MANY duplicate products in fb catalog after changing skus.

What i don’t understand is why it combines the product id as a suffix. I am now having to use a tracking plugin that sends only the SKU as content_id and its not matching the fb catalogue which expect +”_productid”

sku should = content_id without anything added to it

thanks

/J