thirty bees and GDPR

//thirty bees and GDPR
Listen to this article

Here in the next couple of weeks, we are getting ready to start making thirty bees compliant with the European Union’s Global Data Protection Regulations. This is likely going to be a big undertaking to comply with the EU regulations before the deadline comes into effect. The regulations around e-commerce shops are very wide sweeping and very vague at best. So we are left trying to decode the regulations to keep thirty bees users in compliance with them.

If you have been eagerly waiting for thirty bees 1.0.4, you might have to wait a little bit longer. We are trying to figure out if we can squeeze everything we need to comply with the regulations into a module, or if we are going to have to modify the core to bring the software in compliance. One of the main issues centers around cookies. From our understanding of the law, a shop cannot cookie a user before a user agrees to be cookied. We are working to see if there is a reliable way that we can disable the ability to cookie users without requiring core changes.

Some of the changes required, like letting users delete data and export data are fairly simple to deal with. Those will likely be added to the EU compliance module to help bring shops up to compliance quickly and easily. This along with a few other tweaks to ensure that the module works consistently, correctly, and is within the current framework of the law.

The end goal

The end goal we want to provide is a comprehensive EU compliance module. So that all shops in the EU can install the module, configure it, and be legal. We just have not figured out if we are going to need to alter core functionality to provide this result yet. Also, we are in talks with several experts in the field of compliance to help wrap our heads around the quirks in the law and how they best need to be handled on a massive global scale.

If you have followed our Google Analytics module, you know that it has already been made compliant by anonymizing the IP addresses sent to Google. With less than 100 days until shops need to be compliant, we feel the time to start working on a solution is now, to best protect our merchants.

Join the discussion below, let us talk about what new features need to be added or changed in thirty bees to make your shop compliant with the GDPR.


About the Author:

Lesley Paone
Lesley is one of the co-founders of thirty bees. He also is the owner of a PrestaShop support, development, and SEO agency called dh42. He has been active in the ecommerce community for almost a decade providing help and support services.
  • Ahmed Abderraham

    Well, I’ve been developing web projects (plenty of e-commerce) in the eurozone for 12 years now. Since all the “cookies warning” madness started, I read the old “cookie law” and decided in any part it said it was required to show a message to your users and make them accept it. I’ve never implemented a “cookes warning” message in any of the projects I’ve developed unless specifically requested by the client. I always gave my opinion to them: that it wasn’t required. It was only required to have a “privacy policy” or “cookies policy” page explaining what you are collecting and why.

    After all this time, I’ve never heard of anyone getting fined in the entirety of the EU for not showing a cookies acceptance message. Not only that, if you for example visit the Union’s official webpage,, you will see that they use Piwik (Matomo now?), which sets 2 cookies in your browser, and there’s no cookies acceptance message anywhere. Also, for example, the page, supposedly made by the best experts in digital laws in europe, is using Google Analytics and setting 4 cookies in your browser, and there’s no cookies acceptance message to be seen. I could go on all day with similar examples.

    So all in all, and after having read the new GDPR law, I still think there’s no need to show the damned cookies acceptance message, and you are fine with a well-written privacy and/or cookies policy.

    Just my 2 cents, trying to avoid people getting crazy about stupid and unnecessary laws instead of actually building and moving forward great products.

  • Dovydas | Innercode

    I would agree with Ahmed Abderraham we add notification on client request only and most of them do not ask for this. But with GDPR might be a little bit different situation. What is the fine for missing cookie notification? To be honest I don’t know, but for the new law it is huge, up to 4% of your revenue and up to 20 M EUR.

    Not sure what is the reason, maybe the amount of fine, but we got a lot of requests by our clients regarding GDPR. No one asked us to make changes to their stores after cookie notification got required.

    If it would be implemented it would be easier for us to modify stores because module won’t be enough in this situation. If you want “clean” solution you need to modify template files.

    I had a short meeting with a lawyer who specializes in data privacy. Probably there is no way to develop universal solution, but at least basic functionality which fits most of the shops can be added. The main point which should be applied even now: one agreement for single purpose / use of data. If customer agreed to your privacy policy, it does not mean that you can send newsletter to him/her. You need additional confirmation for this. Same goes if you use e.g. HotJar (live recordings of the visitors) you need additional checkbox for this. Basically with hotjar you can even identify your customer (by order ID in the success page).

    Some points that might be useful:
    1. Cookie notification. Not sure how, but just displaying notification is not enough. You shouldn’t store cookies unless user agrees to. Also you cannot save customer’s choice not to use cookies into a cookie. This means, that notification must be displayed all the time, unless user agrees to it, or find other ways of implementation how to hide it (store to DB, instead of a cookie).

    2. You need to collect as little data as you need to. e.g. we have terminals (boxes near supermarkets) where you can deliver your products. In this case you don’t need to collect customer’s address, because you are not delivering to his home. There might be other cases, e.g. when selling virtual products you need less customer’s data. But you also should not forget what data is required for invoice.

    3. Define how long you are going to save the data. Data that is needed in invoice can be stored according to invoice regulations, but other data should be anonymized or deleted after some time. The time is defined by merchant, so probably it might be quite long, but the amount of time must be reasonable.

    4. This one I think should be implemented even now for Terms and conditions. Versioning of agreements (TOC, Privacy Policy). Since you can modify these agreements at any time, it must be versioned (auto save pdfs on modification) and it would be the best to send agreement pdfs with order confirmation email and make them available in my account next to order data. Since privacy policy can be modified, user must agree to privacy policy each time he purchases products, unless you want to check which was the last version he agreed to.

    I still don’t know much how properly it must be implemented, had only one time short “free” consultation, which is not enough to get into more details. But as he told me, most of the cases are too individual even for shops, it seems easy at the beginning when you think that there are just products that are being sold.

    One more thing. Same example with cookie notification when it is displayed unless you agree. If you make your shop 100% GDPR compatible, UX will drop. another example: what happens when you don’t agree with cookie and add product to cart? You must show some kind of notification anyway, either don’t allow to add product, or show that you agree with privacy policy automatically. I don’t know which one is the right way, but still, it is not so nice.

    Maybe no one will check your store and everything will be OK without it, but usually this requirement comes from the client, and taking into account the fine amount, I wouldn’t risk to talk client over not to implement it. Also it would be one more additional feature, the more features it has the more attractive it will be for merchants.

  • Tobias Mitty

    Just wanted to check, can you give us any updates about your current progress? (:

  • Dejan Toplak

    The default TB/PS cookie is not a problem as long its time is set to 0 so it expires at and of the session. That should be default setting.
    However it would be a nice choice if there was remember me on login, that would require consent and would add new extra cookie for the ones that would like to be remembered for longer time than just current session (benefit of registered customer)
    Registration of custumer is already covered with privacy policy as it adds a checkbox where you can write
    what you will do with the data entered and link to the privacy policy and consent date is the registration date.
    Same think is needed on newsletter subscription and on contact form.
    Cookie banner and consent for cookies are not needed if only default cookie is used and it ends at
    the end of the session. But if default cookie lifetime is longer, than the cookie should be blocked before customer accepts it.
    Plus the added functions for customer to request the view or removal of his data.

    So. Prestashop is planning to add free GDPR comliance module for the 1.7 and payed module for the 1.5 and 1.6.
    But I would not want to migrate to 1.7 in my lifetime as I totaly don’t like what it has become.
    Their plan is that most of the users migrate to 1.7 due to free gdpr compliance.

    So best for thirtybees would be if they are prepared before official prestashop modules are prepared, as migration from ps 1.6 to TB is not that hard and admin experience remains same as on ps, where on otherhand the ps1.7 admin is total nightmare to the ones who were using older ps versions for longer time (like me for last 8 years).

    Have a nice day.