since we managed to resolve issues with more important events, our web analysts now noticed another problem - this time with the view_item event.
On our website, we are using a lot of variable products. Unfortunately, the data sent with the view_item event are incorrect and there are multiple situations were the problem appears:
When using a parametrized URL such as: https://www.jagaia.cz/produkt/breathein/?attribute_pa_obsah=33ml, you can see that the item ID send in the event is correct - it is in the format of productId-variantId where both IDs are correct, but the rest of the item’s data are incorrect. I checked the source code in mergado-marketing-pack/src/Service/External/Google/GoogleAnalytics/GA4/Ga4ServiceIntegration.php and it is quite clear that the variant only influences the item id and nothing else - for example the prices or categories are obtained for the “parent” product, not the correct variant. I believe this is incorrect behaviour. I am also unsure why is there the need for this productId-variantId format. To me it would seem more reasonable to just have the variantId here same as you do with add_to_cart or purchase events.
When not using the parametrized URL, the source code just doesn’t take variants into account at all. I understand that one could think that in that scenario you don’t have information about the displayed variant (or that there is no variant displayed) but that’s true only sometimes. Woocommerce supports default variations which we use on our website, so if there is not a parameter in the URL, the wbsite will display the default one. I believe this would be true not just for our website and I believe the tracking should respect this WooCommerce settings.
I believe the fix for both of these problems should be quite easy - just fetch the product by the variation id before obtaining any information for the event. Btw just be careful not to override the global $product variable as it could break many things.
Thank you for reaching out to our support team. Parameterized URLs will be implemented in the next version of the Mergado PACK plugin. Regarding the IDs, we will need to discuss this issue further with our developers.
After weighing all the pros and cons, we will add an option to configure which ID should be sent - either productId or variantId, if it exists. This will be implemented in the next major version release of the Mergado PACK plugin
ETA is approximately 30 days. In other words, we aim to release the new version of the pack by the end of October.
The time requirement is primarily driven by the significant number of new features, fixes, and updates. Additionally, ensuring compatibility with the latest versions of WordPress and WooCommerce is a key factor.
I’m reaching out to you after a while, hopefully with good news. We have just released a new major version of the Mergado Pack plugin with improvements addressing this issue.
Check out all the details in the article below!
If you encounter any issues or unexpected functionality, please don’t hesitate to let us know.
thanks for the update. I just installed it and carried out some simple tests and I can confirm that the parametrized URLs and (non)composite IDs work great. In our case, the view_item and select_content events now work great.
There is although one little drawback. Without a parametrized URL, the view_item event still sends the ID of the product (which actually never gets added to cart since it’s a variable product) instead of the ID of the default variant of the product which is actually displayed to the user.
Let’s take the example of our BREATHE IN product (https://jagaia.cz/produkt/breathein/). The iD of product is 13089. The variants have teh following IDs:
When you use the parametrized URLs, view_item is tracked correctly. But when you use the one without the parameter (https://jagaia.cz/produkt/breathein/), the ID 13089 is sent even though the (WooCoommerce configured) default variant (15ml, ID 13092) is displayed to the user.
Is this anything we could resolve?
Thanks in advance.
Honza
Apologies for the delayed response and thank you for your fast feedback!
I have already forwarded your information to the plugin developer. In the new version, we are implementing the adjustment (see the changelog) along with some minor bug fixes.
I have sent you the updated version of the plugin in advance so that you can conveniently test the proper functionality in your environment.
Once everything is ready and thoroughly tested, we will release the new version of the plugin for public download.
Changelog:
If you navigate to a product detail page and the URL is not parameterized, it checks whether a default product is available, and if it exists, it uses it.
In other words, we aim to release the new version of the pack by the end of October.