May 2018 has been a really long and frustrating month in terms of updates to London Bus Pal. I would never have imagined just how much effort I would need to put into my app when I thought that I was free from any GDPR requirements.
I was on holiday and I saw some emails from Google and then also saw an article on The Register (https://www.theregister.co.uk/2018/05/10/google_gdpr_consent_klaxon/) which pretty much made it clear that I would have to do something. Upon return from my holiday, I immediately got on the internet and started reading all kinds of horror stories of people building entire consent databases and having to come up with really intricate ways to obtain and store consent. It felt like it was overkill and like it was completely against what I thought the spririt of GDPR was (less data, not more!). The panic started to set in as it seemed like this was a much bigger beast than I had anticipated and I started studying the regulation itself, rather than just reading blogs based on third-hand information. At least it turned out that I was right and that GDPR was meant to limit and reduce the amount of data we process, not process more data because of it.
After reading the regulation and no consent SDK being available yet from Google, I decided to build my own pages to manage this in the app. I settled on the following requirements:
- Location permission – I already had to obtain these due to Android requirements and my app works fine without it. I decided to still build a screen to tell users about it and that they can revoke permissions if they want.
- Ads – this was the main reason I built this, because it felt like Google was willing to stop us from using AdMob if we did not do something to gain consent. To be honest, I understand where they are coming from as they would be held responsible if they didn’t insist on us doing something. The consent isn’t to consent to ads or not, it was basically to use personal data to personalise ads or not. More on this later!
- Crash reporting – as I didn’t consider capturing crash reports as a legitimate enough reason to keep my app going, I decided that I had to gain consent to store crash reports.
There is very little else that I do with data – I just take a location or bus route or bus stop request, get the relevant data and show it back to the user. I really have no interest in obtaining data I don’t need.
So I built my GDPR consent screens and I ran into a bit of trouble. My crash reporting and analytics tools are bundled together really. If I switch one off, I have to switch both off. I then decided to change the wording for crash reporting to something along the lines of tracking expected and unexpected behaviour (the former being analytics and the latter being crash reporting). I had some issues with the analytics, so I then had to go and find each use and check if I could use it or not before posting something as I didn’t use standard methods everywhere.
Due to the GDPR consent screens being one of the first screens and having to test with different permutations, I decided to just do some manual testing instead of expanding (and fixing) my automated tests.
I changed my AdMob settings to select my own technology providers and I published version 3.2.6 on Wednesday morning, two days before GDPR was due. Things sort of looked normal, my ad revenue seemed unaffected and even though I could see a bit of a drop in users reported through my analytics tool, the users who still opted to keep crash reporting and analytics on, still had a 100% stability rate.
Over the next two days I noticed some 1-star reviews, two of them were removed before I could get to them and it just looked like someone trolling the updated GDPR screens. But there were some legitimate ones too and I started to investigate. I noticed on the Play Store that my app stability had decreased since the GDPR release and I found some specific pieces of code I missed! If someone had chosen to turn off analytics, I still had some instances where I was trying to track events and it would crash the app. I asked the users to contact me to give me more detail to help my investigation.
Rushing to get a fix out, I made sure I found all of the uses, fixed it and I released version 3.2.7 on Saturday morning. I received another 1-star review saying that the app was broken – this review was left for version 3.2.7 and I also received an email from one of my users who confirmed the same. Frustrated, I decided to take the nuclear option and remove all of my GDPR updates (by reverting the code back to version 3.2.5) and then just serving non-personalised ads.
I have now scrapped the idea of requesting consent for crash reporting and analytics since I believe that this is actually crucial information for the app to work based on the nightmare I had. I was trying to stick to the “letter of the law”, rather than the spirit of the regulation. The data I am collecting does not contain enough information to personally identify anyone and I’m happy to have it go under scrutiny.
Today I watched as my revenues plummeted. This is either due to only serving non-personalised ads or the fact that it’s a bank holiday in the UK. It’s probably a combination of both – I can see my click-through ratio has gone down and so has my CPC. So I made another attempt at implementing a quick consent request so that I can at least get personalised ads back on for some of my users.
Effectively, all of the work I have done to implement GDPR in version 3.2.6 and 3.2.7 had to be undone and I started from scratch. This time also, I have taken a softer approach and just made it a pop-up where you can choose Yes, No or Later – similar to my rating pop-up. (I still used all of the saved consents from version 3.2.6 and 3.2.7 if it worked, so at least people won’t be annoyed with more pop-ups!).
I’m going to package version 3.2.9 now and publish it to all the app stores. I am hoping that this is the final version for GDPR and that I can finally get onto other things. If you are a user who was impacted by my GDPR disaster, I can only apologise!!!