Buildio

Hi, really appreciate the thoughtful review, and thank you for the detailed feedback.

Great news on the multi-language consent popup. That was the biggest gap you flagged, and it’s just been shipped in v2.6.4. The built-in popup now supports 18 languages out of the box (Spanish, French, German, Italian, Portuguese, Dutch, Polish, Japanese, Chinese Simplified/Traditional, Korean, Turkish, Arabic, Russian, Swedish, Czech and more), automatically matched to each visitor’s WordPress locale. On top of that, you can now fully edit every string in the popup per-language from the admin, so you can match your brand voice, legal wording, or any jurisdiction-specific requirements. It should fully unblock the multi-region use case you had in mind.

On the other two points:

• Meta test event code field: noted and on the roadmap. Being able to verify server-side events land in Meta’s Test Events tab is a fair ask and we’ll look to add it.
• Diagnostic data: thanks for flagging. We’ll take another look at what’s sent and work on making it more transparent (and opt-outable).

Thanks again for the careful review, it genuinely helps shape where we focus next. If you give v2.6.4 a try and run into any issues, please get in touch through the support forum and we’ll jump on it.

Great to hear, please get in touch if you notice any other issues. Cheers.

Hi Bastian,

Apologies for the delay in getting back to you.

This is a confirmed bug — on PHP 8.0+ the plugin assumes a User-Agent header is always present, but some visitors (bots, crawlers, certain proxies) don’t send one, which triggers the warning.

This will be patched in the next update! In the meantime the warning is cosmetic, it doesn’t affect tracking for real visitors, as browsers always send a User-Agent.

Thanks for reporting it.

Closing this for now, hopefully this answers your question.

Good eye, that’s just the result of a build process. The distributed version goes through minification and encoding as part of packaging, this is common for some WordPress plugins that run a build step before release. If you decode those hex strings you’ll see they’re just regular function names like unipixel_generate.... Nothing unusual, just the compiled output vs the development source.

Thanks very much @laserstore , glad to hear it’s working for you.

Hi @leodefaveri , apologies for the delay. We are continuing to look into quality improvement for Meta events. You’re exactly right that the score from Meta acts like an incentive for developers to add more information. They – as well as us – are trying to get as much information as possible to “match events” and gather information to help their algorithms. When it comes to Purchase, lots of information is available, including email and phone. Meta asks for hashed/encrypted versions of these (these are not useable or decipherable, and don’t reveal personal information about the user) but they help with it’s algorithms. This is sent by UniPixel for Purchase events. When it comes to AddToCart, Meta wants this same information. But in many cases, it’s simply not available. So in that sense, Meta’s score is not really helpful – too harsh if you like. Having said that, we are looking into at getting more of these information pieces and making them available for AddToCart, InitiateCheckout etc, and potentially having configuration options around this data on whether to collect. I’ll keep you updated. Further to this, we are currently looking into tidying up some pieces of data being sent for general events. In some cases, you may notice a blank currency value being attached to some events currently, which will be updated soon to be removed.

Hi @joy0114 ,  error when calling /?wc-ajax=add_to_cart has been fixed, which was caused by this action needing to handle some cart parameters slightly differently vs other methods of adding to cart. Thank you for pointing this out. Client side events also are sent for this properly now when using ajax cart adding, however, note that this happens on the next page-load (even though server side is sent straight away). Client side events for WooCommerce are now logged to the console to confirm that they occur. In future updates features will include ability to have control over turning on/off logging in browser, but for the moment this should help you confirm that client side events are firing for WooCommerce. This console logging is not available for Custom Events.

There is currently no feature to manage Cookie consent but this is planned in an upcoming release. function unipixel_metric_log is to provide usage stats to help us with debugging and logs an event when the plugin is activated or deactivated. See “Domains” and “Data Sent” in the plugin Details https://wordpress.org/plugins/unipixel/