 Okay. So thank you for coming. I can't even improve on that introduction. So thank you very much, Abba. As you said, we're going to talk about GDPR and Google Analytics because we've both been getting absolutely deluged with questions about this, both on the legal and the technical side. So we thought let's just put our heads together and do this talk and cover all the ground from two very different perspectives. So Google Analytics. Well, Marissa's based in Washington, as Abba said. She is a former web developer. She has some very shameful, beveled borders in her past. I saw them. And she is now a full-time Google Analytics specialist. Most of us have used Google Analytics, but we've only done maybe two percent of it, just logged in and set up an account. She does all the crazy event stuff. The deep dives, the event settings. That's what she does. So she's really glad she's here because I've never done that. It's only her second word cap. She's the curator of an absolutely appalling collection of 1990s pop music. If it was bad, it was a one-hit wonder. She's probably got the original. And she is not only... And her whole album. Oh, he used to. Okay. And this is Heather. Heather is based in Glasgow, which I only learned how to properly pronounce yesterday. She is also a former web designer. And she is now a full-time digital law expert. Again, if you Google GDPR, you're going to see Heather's name. This is her gazillionth word camp, or I guess 18th. And she has an exquisite collection of French pop music, of which I see no appeal. And she is also not a lawyer. So what we're going to cover is, as I said, from both the legal and the technical perspective, we're going to talk about what you need to know, which is the changing European privacy framework. What means what. How the right to be informed impacts analytics and ascent. And Marissa is going to talk about what you need to do to actually configure Google Analytics for what we feel is a happy little ground for optimal user privacy. We're going to talk about risks beyond everyday analytics, specifically in aggregation. A couple of analytics issues we wanted you to be aware of and to privacy notices. So I'm going to start talking about the legal side. But what you can do to not fall asleep while I'm doing that is if you have your laptop and Google Analytics account, get in, open it up and log in, because she's going to tell you exactly what to do, and you might as well do it while she's in front of you. So what do you need to know about the way that Europe is changing, the European privacy framework is changing? Well, we all know GDPR was yesterday. Yay! It replaced the general data, the data protection directive of 1995, which was incorporated in the UK in the Data Protection Act 1998. So when people said Data Protection Act, that's what we mean. That has now been superseded by the Data Protection Bill, which received royal assent, I believe, on Wednesday. So they left it till two days before the deadline. Obviously, they weren't smited by the way I do slides. So GDPR maintains the original principles of what we've always had since 1995. Just expands and modernizes them for the ways we collect and process and use data today. GDPR deals with what we might call data at rest, your collection, your usage, your retention, what you do with it inside your business. What a lot of people don't realize is that GDPR is only half of the European privacy framework. The other half is something known as the ePrivacy Directive. This was supposed to go live yesterday in a sort of double helix to GDPR, but it is still bogged down in European committees, and I believe they've basically been told, for God's sake, you need to finish this up already because it's getting ridiculous. The latest draft only came out last week, and it's 84 pages long, and I mean, I'm struggling to read it. It is getting to the point where it is literally unintelligible. So ePrivacy deals with data at what we might call transit, which is cookies, telemetry, advertising, beacons, marketing, and yes, analytics. EPD is what you know is the cookie law, which was a bit of a misnomer because that was only part of it. So they're saying perhaps late autumn, early winter, which in practicality means winter, early spring. So we're going to have a slightly awkward year where we have a new data protection framework pertaining to data arrest and an old data protection framework pertaining to data and transit, and the thing to know about that is that neither of these specifically mentioned the words analytics. It's more about the concepts. So you're going to have to keep up with what's happening with ePD and monitor as best you can. So what I will say is that this talk is really about what you need to bear off for the next year. It's going to be updated in a year or so. I need to run over a couple of definitions with you. I don't need you to memorize this, but you do have to know what we're talking about. So European data protection law pertains to personal data. This is any information relating to an identified or an identifiable natural person. This can be one piece of information or multiple data points combined in a record. Now, as I said, GDPR modernized these things. So new definitions of personal data under GDPR include genetic data, biometric data, location data, and online identifiers. So your analytics data becomes personal data. The term personal data is very different from an American term. It's called PII, personally identifiable information. PII is a specific set of data identifiers. It's a really odd list like name, address, birthplace. It's weird things like I think your license plate number. As well as a couple of things which could be PII in context such as age, gender, salary data. But you need to be aware it's a limited data set. But when we're getting into our Google Analytics configuration, it talks about PII. So I want you to be aware to what Google Analytics is talking about is actually what European data protection law is talking about, which is why you really need to double check these things. Other thing you need to be aware of is what's called sensitive personal data, which is information about racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, health data, sex life or sexual orientation, or past or stand criminal convictions. And remember this is all, it's all about context. So if you have analytics data about individuals browsing about sexual health issues, it's all sensitive personal data aggregated together. Under European data privacy law there's two sets of people. One is the data controller. So that's the person or the entity that means you really, or your business who decides what data is processed, how you use it and who you share what process just means used. So the analytics data you're looking at, you're being a data controller about that. But the data processor is any person other than the employee of the data controller who processes the data on behalf of the data controller. That seems confusing, hold that thought, it will make sense in a minute. Under GDPR, the rights we've always had over our data have been strengthened and reinforced. The ones that pertain to analytics are the right to be informed, the right to restrict processing, the right to object, and certain rights related to profiling. We're talking about very innocuous uses of analytics, but the hard stories you see, I mean Cambridge Analytica is just the nexus of all hard stories about data, about web browsing and purchasing habits being aggregated with offline data. So that's called profiling. But on an everyday basis for you for analytics, this means telling your site visitors what you're doing with analytics in your privacy notices as well as what you're doing if you're aggregating it with anything else or selling it or using shadow programs. Disclose the cookies you use if your analytics use cookies, give them information on how to opt out of being tracked through analytics, and remove any analytics request records, you've created or aggregated a part of the request, and this slide has changed since we started this. So bring it all together. J2MLukes and GDPR, who's who? You're the data controller. So you are responsible for protecting your users' data, including your analytics records, and any information you've aggregated with them. When you're logging in, when you're looking at them, when you're studying them, you still have to safeguard all those people's data in full compliance with the law and their rights over it. But Google Analytics is the data processor. So they're the data processor for cookie identifiers, IP addresses, device identifiers, and client identifiers. Now if you use it here in Europe, you'll have probably seen a pop-up with them. It would be a pop-up and an email. Just sign your new data processing agreement. They have to do this to cover their legal backside. So they can say, this is what you've agreed to. So you now have to give them your contact information if there's a privacy concern, and your data protection officer if applicable. Remember, not everyone needs a data protection officer. But if you do, they want to know who that is now. So if you haven't found that... So this is what Google Analytics admin screen looks like. I always talk about the three columns. So that first thing is in the account settings in that first column. If you haven't already accepted the agreement, that's where you could find it. Isn't that first column? Create account settings. And that will cover all of your properties that you may manage in Google Analytics, not the account level. And you'd have to... It's long. You would review the amendment. And then you would just manage your DPA details if that were necessary. And that's it. So obviously the real hot-button issue about GDPR has been the notion of consent. And this gets into a really big debate about do you need consent to track analytics? Because in the act of asking for consent, you're losing the count. So we kind of got into an argument about what it means. Do you have to ask for active consent or not? Let's get rid of us at lunch yesterday. I didn't talk about that. We've agreed to disagree here. So you take it from a sort of contractual view about you're already complying with Google Analytics in terms of service, which forbids the collection of PII. Remember, PII is not personal data. Can you actually explain how the terms of service don't allow PII? So in terms of service, just don't let you collect anything in any combination that is personally identifiable information. And I think one of the examples I have is a lot of times you'll see post forms that have you have a big URL and then it says an email equals Marissa Goldsmith at marissagoldsmith.com. That then gets sent into Google Analytics and now I actually know the email address of the person who looked at that page. So that is personally identifiable information. You have the ability to make custom dimensions where if I'm filling out a form and I say I have hazel eyes and I track that piece of information, suddenly you now know I have hazel eyes and then you can combine that with I also happen to live in West Springfield, Virginia in the United States and suddenly you start making all that information together and that is all considered personally identifiable information. So if you're using Google Analytics technically, you've agreed not to do that. So on the presumption that you're not doing that, you are, we're also going to assume you're compliant with the existing cookie law which in the UK includes some derogations which the Information Commissioner's office put in. And you're also going to do everything Marissa's going to explain to you shortly in your settings. We're also going to assume you've disclosed everything you're doing with analytics in your privacy notice. On that basis she could say that active consent is not required. But then you might take the ideological view that I do that yes, maybe you're only using Google Analytics to see who's looking at your website, what pages they're looking at, you're not doing anything with that data. I mean how many of us have had meetings with clients where we said okay, what did your analytics say and they said not looking at it. Okay, fair enough, but Google's still collecting that data. And then it's the unknown question of what is Google doing with that data? Because there's a reason it's free. You're the product. They're collecting data on you. We don't know what they're doing and we've watched a lot of very entertaining congressional and parliamentary hearings about what actually happens with this data that you've been giving them. On that basis you might want to say that yes, it is required to get people's active consent. And we're both right. And I think we're both right. But what's the best thing to do here? We feel there's a middle ground. One thing is that privacy by design fundamentals, which I've spoken about before, that's part of GDPR. And they say that you should collect as little data as required, retain it for as little time as required and delete it when it's no longer needed. So you can take steps as part of a healthy privacy framework, not necessarily because law tells you, but there's things that you can do to not collect data in the first place so that Google doesn't collect that data in the first place. Privacy by design also has a rule against zero-sum scenarios. I saw a privacy person tweeting that she wrote a really good blog post and she wishes she knows who was reading it because she doesn't have analytics. And it felt like you're ignoring the privacy by design principle against zero-sum scenarios. There is a little ground. You can collect the bare minimum useful analytics you need to know what the heck your blog is doing on your site and still respect user privacy and site functionality. We're also aware that you're here today not because you want to join a crusade or tell to the window, you just need to know practically what to do. So that's what we're going to help you do. We're going to run through how to configure Google Analytics to we hope is that happening on the ground. We're going to tell you what to cover in the privacy notices you need to have on your site anyway. And we're going to look ahead to what I could scratch out of that latest 84-page draft without my eyes falling down about what might change in future for analytics and consent. So here's what you need to do, the technical bit. So if you're logged into your Google Analytics account, this is where she's going to take over. And if you're not and you catch me later, I'm more than happy to help anyone with anything they need to answer any questions. So I'm going to have some examples here that I put up. I use Google Tag Manager with all my Google Analytics. So the examples that I have will use Google Tag Manager and that is just a tag manager. User interface that makes putting Google Analytics stuff on your website a little bit easier. You can also do these things straight in the code and in the code snippets. We're going to start first with IP addresses. IP addresses certainly fall under the personal data of GDPR. And so Google Analytics actually does have a parameter that's called Anonymize IP. And I'm advising everyone right now to set it to true. You set Anonymize IP to true. The consequence of doing this is, someone actually did a real study on this. I didn't study this. I'm reading someone else's study. Some of the geolocation data that is in Google Analytics may lose its accuracy. IP address is just one of the many things that Google Analytics uses to tell where you're coming from. And one thing that I always used to do with my clients was exclude your own office's IP address from your Google Analytics account because you don't want your internal, you know, your browsing showing up in your Google Analytics. You're not going to be able to do that anymore because the IP address is no longer being registered. In that case, there are some really great Chrome plugins and Safari plugins. It's called Block My Analytics. You put it in, you press a button, and then the analytics doesn't get tracked from your machine, from your computer. So if you are using Google Tag Manager, there's the more setting, if you scroll down in your Google Analytics page view tag, there's more settings, fields to set, you just say anonymize IP, true, and let that go. So that's in Google Tag Manager. If you go and you go to the Google documentation and look for anonymize IP, if you're doing stuff straight in the code, it should be there as well. Many of the WordPress plugins that you might use for Google Analytics on your site will also have a checkbox to allow you to anonymize the IP and they'll do it for you. This is an example I was talking about before. In the page path, let's say I enter my email address into a newsletter sign-up form. This is sometimes the thank you page, something that would say, like, there's my email address right there in plain text. If you've ever looked at a page path report in Google Analytics, that'll show up. And it's bad for analytics in about a million ways, but it's also really bad to be compliant in GDPR. So this generally happens when you use a get instead of a post in your form submissions. And you are already violating Google Analytics terms of service if you do that. It's with email, I've seen a client who had this whole form filled out to see if people qualified for a subsidy and it included their email address, their actual address, and their income range. That is really, really, really, really bad to have in a URL Google Analytics use it or not. So don't do that. So this is an example of what can happen if you're putting email addresses in the URLs to pull up page information and data. Here's an example of someone who put in someone else's email address and it brought in someone else's preferences. You can put in anyone's email address, you know. So be really careful with using that kind of information in a URL. So whatever you can do, just try to avoid having that information in a URL. Check your forms and plugins seeing, making sure that they're using post. For some reason, if you must programmatically remove this information, it has to be removed before it hits Google Analytics. When you get this, there's a good post by Sima Wabaha who writes a little script on how to redact that information in the URL before it hits Google Analytics. If you do really like Google Analytics and especially like Google Tag Manager, his blog is about the best thing in the world to read. And in Google Analytics configuration, there is the ability to exclude and filter parameters. In this case, that's not good enough because the data is still hitting Google Analytics and then you're processing it afterwards. You want to get that stuff out before it even hits Google Analytics. You don't even want to send it to them at all. We're going to review a bunch of configurations that will cause Google Analytics to collect more data than you want. Unless you either get consent or know as much about GDPR as Heather does and think you're not doing anything wrong, just turn them off. We're going to go through a bunch of things that you should turn off. Advertising features. Google has explicitly stated this. You cannot turn on advertising features unless you get consent. The advertising features includes the demographics and interest reports in Google Analytics. When those first showed up like two or three years ago, everyone wanted those turned on. Everyone was so excited. I'll tell you, A, I think the data is not really useful. It's very large buckets. I read one study that said it's pretty inaccurate. Also, it's not really that great to begin with. And since it requires consent and I've yet to use it for any active client, I just turn it off. But by default, a lot of people are very encouraged to see that and they just turn it right on. So leave that off. Tracking info, data collection. There's remarketing and advertising report features. If you're going to use remarketing, you have to get active consent. If you're not using remarketing, don't turn it on. Just don't turn it on at all. And get consent if you are doing remarketing. So here's where these are. Remarketing off. Advertising reporting features off. Off is always the best. This is something that's new. I want to talk about it a little bit. If you have Google Analytics, you've probably got an email. If you've logged into your Google Analytics, you saw this huge, ugly yellow banner that said that Google has added a new configuration for data retention. In the States, everyone freaked out about this. I was getting emails from clients saying, they're going to erase my data. What should I do? They're going to erase my data. But for GDPR, you do not retain data for longer than necessary. You can adjust the retention schedule. By default, Google is setting it to 26 months. You can set it to never. If you are in my camp that you are only tracking pseudonymous data, that is just about your website and you're not tracking any personal data, there's a do not expire option. But I actually think 26 months is good. Number one, for a while, the Google terms of service only guaranteed good data for that long. If you wanted to do more than two years of tracking, you really couldn't trust what came before. Number two, I will buy a pint for anyone who has ever had to look at more than three years of data. At one time, all of it together. Wait, I'm not done yet. Three years of data. But it doesn't affect the standard aggregate reporting. So if you're looking at standard aggregate reporting, you're still okay. I did that backwards. I'm going to buy a pint after the standard aggregate reporting. What it really affects is if you do a lot of event tracking, if you do a lot of custom dimensions, you might lose those. And you lose the ability to do the really advanced stuff in the advanced segments or secondary dimensions. Or if you use the Google Analytics plugin for Google Sheets, some of those things might get lost. If you really need to do that, you should take a look at what you're collecting, make sure it's not, again, personal data. And then you can change your retention settings. So this is my rant from yesterday. The sky is not falling. Google is not erasing everything. You didn't even really have a right to it anyway. So this is what that looks like there. And then there's another thing here that we said on new activity. So if someone came back, their 26 months would start over. Here's some more configuration pieces. Tracking info, user ID. Does anyone use the user ID feature for Google Analytics at all? And turn it right off. What this does is if you have a site that relies on logins, let's say I have an app on the phone, a website, and then I know someone uses it at work and at home and in three different places, it allows you to stitch the user together. Whereas if I used your website here and then I went home on a different computer and used it on a different computer, I'm considered two users. But if you have a login system where you have a user ID that can connect users together, it can stitch those users together. You need active consent if you want to be doing something like that. Since no one is doing it, just turn it right off. There it is. Off. This came out several years ago. I thought it was going to be the greatest thing since sliced bread. But very few organizations really have a need for it or really have used it. Next is product linking. If you go into that second column, you can link your AdWords, your AdSense. There's like a million products I haven't even really thought about or heard of. If you don't actively use those products, don't link them up. If you had used AdWords once two years ago and don't really look at it anymore, you can unlink it. In that second column, we also talk about you might sometimes see post backs. Never used it, don't use them. Audience definitions. Audience definitions go hand in hand with remarketing. So again, if you're doing remarketing, you need to get consent. If you're not doing remarketing, don't create these definitions. Custom definitions we'll talk about in a minute. Has anyone used the data import in Google Analytics before? This is, again, where you need to be careful. You can import some cost data into Google Analytics. Just don't import data that would be personal information. All right, so these are custom dimensions and events. These are a little bit more common to use. Does anyone use events in Google Analytics? Downloads to PDFs, outbound links, that's pretty common usage. You can do a lot more advanced things with that and with custom dimensions and events, this is where Google really wants you to be careful because we're the ones with the power. We're the ones defining what goes into an event, what goes into a custom dimension. So when you're doing this kind of tracking, I like to use custom dimensions to describe content. One of the things I do in WordPress specifically is I make a custom dimension for author. I'll make a custom dimension for content category so I can make reports that are instead of, like, the 300 pages that I have and the page views. Google Analytics topic, these are the page views. GDPR topic, these are the page views. And so that's one of the ways that I like to use custom dimensions and I actually think it's the best way. And when you're using custom dimensions that way, no personal information. You're just recording what's happening with the content. Some people sometimes will use custom dimensions if, let's say, a user logs in. I have a website. A user logs into my website. I can create a user-scoped custom dimension so if that person comes back to my website, even if they don't log in, I know that they've logged in once before. And that's where you need to be careful when you start making your custom dimensions that you anonymize everything as much as possible. I've seen events where people track the zip codes and the postal codes that people put into a form. Eye colors, the example that I use, but income. You should really try to avoid putting any of those things in Google Analytics. Not even for GDPR, but for Google Analytics in terms of service and for just being a good citizen. And you need to make sure that there is no combination of this data. So let's say I only put an eye color. It's not that big a deal. There's only a few of them and I have thousands of visitors. I'll never be able to point anyone out. But then somewhere else I'm tracking zip code. Then I can see in one session that there is someone there with hazel eyes who lives in the postal code 22152. I live in a small postal code area. You might actually be able to find me and identify me. And all of these things, if you've set your retention policy properly, they will expire anyway. It goes in with each other. So these are events that I have made in the past that I think are pretty good. I like to track navigation for UX purposes. I like to track exactly how people click on navigation so I can see if there are improvements I can make to navigation. That's okay. Now this is again, depending on whose side you fall on, my side or Heather's side, dealing with the cookie IDs. If you really think that using a cookie with an ID is non-compliant and you want to get rid of it, what you can do is make the cookie expire after the session closes. In that case, you're not really tracking an individual that individual has no cookie ID associated with them because it's gone. There's a website here from Humix that has a good article on how to do this with Google Tag Manager, how to track various levels of consent that have been given. It's got a bit of JavaScript in it. They use Google Tag Manager, but the script will work outside of it. It shouldn't be a problem. If you do this, the consequence is you pretty much have no return visitor metrics, which to me is pretty important. That's why I'm falling on my side and not Heather's side. That's the thing I care a lot about. Here's an example of a tag that has various levels of consent. Like I said, I use Google Tag Manager. You do need to consider, again, that it is a Google tool. You're putting a Google Tag on your site and you need to think about what Google does with it. Google Tag Manager can also be used for other things. It's not just a way to implement Google Analytics. It's a way to implement all your marketing tags. I would take this opportunity, if you do use Google Tag Manager, to go through and see the things that you think you might need consent for. If you have a Facebook pixel sitting in Google Tag Manager, you might need consent for that. I would start doing a clean-out of deleting the ones you don't know you need. You don't think you need it versions. If it turns out you need it back, you can get it back. But clean up your Google Tag Manager if you have a lot of things in there. It'll feel good to have a nice, small, manageable list of tags. Then you should also start thinking about putting together a governance process for getting those tags in there. The other thing is this deletion API. Google had been talking about it for a long time. But I was over the ocean when they actually released it to get here. So I don't know much more about it except for that it exists. It allows you to delete data based on the Google Analytics client ID. It looks promising. As a Google Analytics engineer, I've been dying to be able to delete data out of Google Analytics for a really long time, GDPR or not. You know, you have dev environments. You have things that don't belong. You accidentally double count things. I love the idea of being able to delete data out of it. And it took a European law to make that happen. But I don't know how it's going to work. Okay. So now that you've done all that in your settings, we need to get back to privacy principles for GDPR. And part of that is the right to be informed, bringing it all into the open. So in privacy notice on your website, you need to document, as we said at the beginning, what analytics you're using, what you're collecting, why you collected, who has access to it. That's your governance process. That's really an internal thing. How you audited it, again, when was the last time you actually looked through this stuff, what you're collecting, why are we collecting it? Whether it's used for profiling, for advertising, anything like that. What, if any, cookies are used and how a user can opt out, whether that's through Google Analytics settings, a browser extension, browser settings, we'll get more of that. To make that privacy notice, you can either use the privacy notice tool in your WordPress dashboard, which shipped with version 4.9.6 last week. There's a nice little tutorial that I wrote. You don't have to use that. You can use any privacy notice page as long as it's not a template. Remember, in GDPR, we're getting away from... There's a well-known WordPress plugin that had a privacy policy and they deliberately put a typo in it to see how many other people were copying and pasting it and putting it as is. That's done. You can't just download and copy and place boilerplate in that. You have to write your own privacy notice. So whether you use the tool or something you already have, just don't think you can cut and paste it from anyone else. I did do a talk about how to do it in London and I was hoping it would be on WordPress TV by now, but it's not. But please watch it when it is up. Google Analytics are not the only fruit, so we thought it would be worthwhile talking about other analytics packages, as well as things that can capture data. For example, Twitter. If you add this line of code to your page header, it will not track any of the actions on any embedded tweets that you put in. Facebook, we could probably do a whole talk about... How about you do that in the pub? Okay. We'll do that in the pub. Yeah. Facebook privacy talk in the pub. Supermetrics. So Supermetrics is a tool that is an aggregating tool. It works with the Google Sheets plug-in. My advice is not to go get it. That's not what I'm asking you to do. But take a look at the tool and take a look at all the things that it could aggregate. If you use any of those things, you're using an advertising... It's essentially an advertising tool, so you need to be careful about that. I have in the past used Supermetrics to do things like create combined dashboards of tweets with Google Analytics with a few other things. But it's a good repository of all the marketing tools in the whole wide world that you might possibly be able to use. And there's some aggregators, like a tool called Brandwatch. And they're sort of an interesting case because what Brandwatch does is say I'm a brand and I just want to see what's happening on Facebook and on Twitter and on a few other... on Instagram. It brings and aggregates all that data together. It's data that's out there and it's in the public, but it's also other people's personal information sitting in one aggregator. And so you do need to be a little bit careful about how you use tools like that. Again, governance, access, making sure... One of the things that I'll always say is making sure that if you have let someone go, if someone has quit or if you have fired them, that you change your passwords, get rid of their account. I brought up the Brandwatch example because I had a client who had gotten rid of someone six months ago and their email address was still the account on Brandwatch. And I don't know if anyone changed the address or anything like that. So there's other analytics packages you can use. Paylic has changed its name to Matomo. It was an analytics package designed with privacy in mind. But you had some interesting thoughts on it. It's not interesting. My interesting thought is that I would... I would be super happy if... I'm gonna... I always call it Paylic, but if Matomo became like the analytics package of choice, but it just... it isn't. If you need to hire someone to do your analytics for you, the chances of them knowing the tool are gonna be very slim. They do have an installed version, which is very nice, but then you are now responsible for the privacy of everything, including your servers. So there are some issues with that as well. I've personally been using an Irish service called StatCounter since before there was Google Analytics. You can choose to not set cookies and obscure the IP address. So I just want to know what quotes are popular, and that's really good for me. Same with Jetpack stats. It collects very little information and just basically shows you what pages are popular. And the cookie set is admin only. So if all you're wanting to do is know who's reading what, not even who, just what's being read, just stick with Jetpack. We wanted to touch on the dangers of aggregating analytics data with other forms of tracking. So winners... We are anonymous analytics, not anonymous. Say that five times fast after we get this. When you can take lots of data points and stitch them together. So we already know you can't do this officially, but you can do it with other tools. I saw a video of a talk where somebody was talking about putting Google Analytics hot jar in Facebook pixels, and I was watching it like, no, don't do that! Because that is capturing all sorts of pieces of data about an individual site visitor which can be stitched together to the James Bond levels of monitoring and tracking. So as you said with your example, if you go into your e-commerce tool and see that what's the Goldsmith from what Springfield ordered something at 833, you can then go into Google Analytics to track the patterns, and you know that that's who she is. And then you can match it up with the hot jar you were taking of what she was... We got this poor woman under surveillance. So set really strict organizational rules about cross-referencing data sources or don't track it to begin with. I would, as with everything, I would recommend burning your Facebook pixels in a fire, but I know that that's not an option for a lot of you. So I mean, one of the things... I have always tried to be a people pleaser, and I'm also, you know, I work with clients, and so someone comes to me and says, we got a pixel, we got to put it up. They give me the code I go and I put it up. But the more and more I kept doing this, the more and more I kept realizing that I was putting things up that were, maybe we'll use this data in a few years, this is just in case data, or this is something that will get so much information about our users, and then you want to take a step back. Because the more stuff you collect just in case, the more tempted someone's going to be to stitch that together, so if you really don't need it and if it's not really useful, don't do it, because down the road someone might ask you to do something evil with it. Don't put it on your site just because someone tells you to. What you want to do is you want to develop a real governance process around these things. A lot of people equate governance processes with bottlenecks, but it doesn't have to be that way. But there does have to be a gatekeeper of sorts who says, you know what, you don't need this pixel, this is just in case data, and we're never going to use it. But the extra just in case data usually messes things up anyway. Data reading a year from now much harder because you don't know what was there and why. You know, you can create these master field maps, conduct a privacy impact, and talk to all your vendors about what they're doing to be compliant. I've heard some really, really lousy vendor explanations about how they're going to be GDPR compliant, and I'm not really sure what to do with them, and we don't use them. So I promise to you I would give you a little sneak peek of what might happen with the UIFC Directive revamp, being mindful of the fact that trying to predict what's going to happen based on a draft is a fool's errand. They're talking about how they acknowledge that analytics cookies can be useful for analytics processes, but it's not the case, however, regarding cookies and similar identifiers used to determine the nature of you who is using the site. They really are keen to see analytics as basic bare-bone statistical counting. Anything beyond that behavior, basically anything you talk about, they're not so keen on that. They want to change the mechanism of express consent to browser settings, so we're going to be able to get rid of all those cookie pop-ups, drop-downs, banners, windows. Pretty much can do that already in the UK anyway. But what they want you to be able to do is make those options really, really granular, and they don't want to dissuade end-users from selecting higher privacy settings, including compilation of long-term records of individuals browsing histories and the use of such records to send targeted advertising. I have a feeling, based on what I've read, they're going to move for an analytics setting in browsers, and given how universal Google Analytics is, that might just be the 80-20 principle. That would kill off a lot of privacy concerns. So give me a year to figure out what they're doing with it, and I will let you know. We have provided some links, which we'll send the slides over. What we want you to know, the ICL has some fantastic resources on consent and privacy. If you're from the Republic, use dataprotection.ie. I will be talking about WordPress's GDPR compliance project in late in the talk tomorrow, and I have a separate side blog where I monitor all these thorny technical political issues through Brexit, versus given a couple of resources against GDP risks on... I put it in there. I caveat the Optimize Smart. He uses a lot of... What's the expression of the legitimate business use? I don't agree with all his interpretations of legitimate interest, but the tech is good. The tech is good in that blog post, and it's a really comprehensive list, so it's worth looking at. There's a Humix blog post on ways to use Google Tag Manager to record varying levels of consent and then fire tags, or don't fire tags, depending on those. The full Google Privacy Compliance site, Brian Clifton blog post on Google Analytics and GDPR consent. He's also a little bit more of a sky-is-falling kind of guy, but again, it's a good read. I added that this morning. I just remembered that legitimate interest cannot be applied better actively to data you've already collected. So don't even try that one. Also, Google Analytics is not historical data. Unless you... There was one blog post that said that it was used for historical... We're using it for historical purposes and we're using it for scientific research. I have one exception where I had a client who had me install event tracking to monitor how... They ran a special needs camp to monitor how parents would track the progress of their children's birth by logging into a website and looking at things. He wrote a PhD paper on that. That is scientific research so that I'm okay with. Everything else, no. And I think that's it. Thank you very much.