Many brands with large customer bases are facing a similar question when it comes to storing data—is it time to bring all data processing in-house? Whether this is prompted by a data security audit, a data breach, or a desire to be more agile with data analysis, it's an important question that thankfully doesn't have a complicated answer. In this article, I’ll explore whether you should outsource or insource customer data processing for your brand. Quick side note—for Littledata’s direct-to-consumer (DTC) brands, customer data is usually first-party data captured as part of the ecommerce checkout process, including post-purchase interactions with the customers and web browsing information such as IP addresses. Why you need first-party data to be secure First-party customer data is data the customer shares with you directly through the server connecting them to your website. By its very nature, first-party data is created by a contract—and more importantly, a bond of trust—between your brand and the end customer. Accidentally leaking that data is brand-damaging: 46% of organizations surveyed by Forbes suffered reputational damage after a data breach. In addition, GDPR and similar regulations impose large fines (up to 4% of global revenue) for data breaches—specifically, lax processes leading to a data breach. You might also be concerned about commercial espionage—how valuable could your customer purchase history be in the hands of a competitor or a fraudster? Or maybe your company has been burned by third-party data processors in the past whose security standards did not meet your own. Taking these concerns together, you may be thinking the only way to be truly data secure is to process and store first-party customer data on your own infrastructure. But there are downsides to this. Do you want to own your own data infrastructure? By data infrastructure, I don’t mean owning bare-metal servers that sit in the broom cupboard behind your office. I’ll assume you are comfortable with the concept of hosting data in a public or private cloud environment. However, even maintaining that cloud computing infrastructure brings costs and risks. Your company will be responsible for software patches, updates to use the latest API versions, monitoring for suspicious activity, and handling outages. Data engineering is complex, and great data engineers are in short supply. So, I suggest you are better off licensing a secure data pipeline than building it all yourself. Does your company control the data end-to-end? Frankly, processing company data in-house may be missing the point if you do not control the data processing end-to-end. Many of Littledata’s customers have made a deliberate choice by working with Shopify or BigCommerce to leave purchase and transaction processing to a cloud provider—signing data processing agreements (see DPAs for Shopify and BigCommerce) to store customer data on US cloud servers. Many brands also make a choice to share customer data with Google (pseudo-anonymized) or with Facebook (not anonymized) to improve their customer acquisition and Return on Advertising Spend (ROAS). In effect, these brands are outsourcing the data processing that happens between the ecommerce cloud and the marketing cloud to Littledata. Trying to do this processing in-house makes little sense when the start and end of the data processing chain are third parties. Does EU customer data need to stay in the EU to be secure? You may have read about regional courts in France and Austria ruling against sending EU customer data to Google Analytics—or indeed sending data to any US server. I think these rulings are extreme and will eventually be struck down. There is no practical or legal reason why data processing on servers within the EU is somehow more GDPR compliant than hosting on the cloud in the US. That said, data nationalism as a trend is here to stay, so there may be a future need to keep EU data siloed. All cloud computing networks have EU servers, and tools like Segment make it possible to split EU customer data processing onto EU servers. The limitation is that right now, none of our other partners (especially Shopify, Google, and Facebook) have the same ability to process in the EU. This makes regionalizing only one part of the data processing chain pointless. Is outsourced data GDPR compliant? Yes, you can subcontract data processing to a third party. But to be GDPR compliant, your data processors need to enable the right to rectification, the right to erasure, and the right to restrict processing. All the main partners that Littledata works with (Shopify, Google Analytics, Facebook Ads, etc.) have API endpoints by which your customer can request their data to be updated or erased, and this request can be passed on to the downstream processors. If the customer requests to restrict processing (e.g. opting out of advertising retargeting using a cookie consent banner) your company needs to also pass along that choice to the downstream processors. Littledata’s tracking script makes that easy to do via integration with Shopify’s consent management, and plugins for OneTrust and TrustArc. Can you control outsourced data processing? Yes. Doing so is just a matter of working with a processing partner that a) is transparent on how they process the data, b) follows good practices in data security, and c) provides Service Level Agreements (SLAs) for the processing. At Littledata, we are clear about how we process customer data (and exactly what data points are stored where), have a public data security policy, and provide tight processing SLAs for Plus customers. [tip]Learn more about how Littledata protects your data while giving you 100% accurate analytics by booking a demo with one of our experts.[/tip] Conclusion I believe you can outsource data processing and still be truly data secure. In fact, I believe trying to bring data fully in-house is costly and pointless for most cloud ecommerce brands. Pick trusted partners to ensure your customer data processing is both super reliable and super secure, and get on with scaling your business!

When it comes to data privacy law compliance, are your marketing or legal team’s priorities more important? For companies operating globally — or even those whose websites merely reach visitors in different locations — this question has consumed significant time and valuable resources, with one or both parties generally feeling aggrieved. What if rather than this relationship being competitive, it could be collaborative and lead to better outcomes for your customers and company? This optimization isn’t hypothetical; it exists today for those in the know. In this post, we’ll show you how you can utilize Littledata’s integration with industry-leading data privacy compliance platform Clym to make this a reality for your website. First, though, we’ll need to survey the current landscape of privacy laws and how they affect what you can have on your website. How do data privacy laws affect your website? Modern data privacy laws originated in 2018 when Europe implemented the General Data Protection Regulation (“GDPR”). Other jurisdictions have followed in the past few years as consumers increasingly grow concerned about their individual privacy. At their core, data privacy laws affect companies that collect and/or process the personally identifiable information (“PII”) of individuals, such as one’s name, email address, phone number or other information that can be readily attributable to a person. These laws dictate and restrict the way that PII is collected, processed and stored. Their restrictions often depend on a consumer’s consent to these actions, and are generally implemented to cover the geographic location of the consumer, rather than the location of the company to which they apply. One commonly overlooked piece of PII is the IP address of a website visitor that gets collected by cookies and tracking scripts. However, regulators are increasingly reviewing websites to assess data privacy law violations, and private advocacy groups have picked up the enforcement slack by lodging complaints against companies in multiple jurisdictions. Complaints regarding noncompliant websites range from companies implementing a cookie wall, relying on “legitimate interest” for consent or violating the principle and requirements of granular consent. Are all privacy laws the same? No, and that’s a problem for marketing professionals focusing on data-driven growth. Privacy laws are different around the world: in the US alone, a fragmented landscape of regulations is emerging on a state-by-state level, with California, Virginia and Colorado being first to adopt comprehensive laws for their residents. Most states aren’t far behind, and already-implemented laws are changing with a high level of frequency. US State Privacy Legislation Map, Source: iapp.org Data privacy isn’t limited to the US and EU. Countries such as Brazil and China have implemented their own laws, each with their own nuances and penalties for noncompliance. As consumer awareness regarding privacy continues to expand, expect these laws to proliferate, with enforcement following closely behind. If you’re targeting consumers in any location where a data privacy law exists, you need to ensure compliance with that jurisdiction’s regulation. My website has a cookie banner, so I’m good to go, right? The unfortunate reality is that many cookie banners are noncompliant for purposes of modern data privacy law, putting you at risk for penalties. Others only offer a static, inflexible UI that either creates friction for visitors or restricts the flow of data to your marketing team. The consent standards for each jurisdiction play a major role in how marketers can collect data from consumers. GDPR is an explicit consent or “opt-in” regulation, meaning that a consumer must provide specific and affirmative consent before you can collect their PII. CCPA, on the other hand, is an implicit or “opt-out” regulation, meaning that you can collect data from consumers assuming their consent, but must provide a way for them to retract that consent. These are mutually exclusive frameworks that require marketers to adopt a flexible approach. Further, to achieve compliance your website should have up-to-date policies (e.g., privacy, terms of use, etc.) and a mechanism to respond to data subject access requests (“DSARs”). Companies who fail to implement a scalable DSAR solution can become overwhelmed with consumer requests that are time-consuming and expensive. What’s the solution? Marketers rarely take a one-size-fits-all approach, and the same mindset should apply to data privacy compliance. There is no global standard, and adopting a static framework will put your company at risk of legal noncompliance, restrict the amount of legally-obtainable data flowing to your marketing team, or both. That’s why Littledata has an integration with Clym, a global leader in global website data privacy compliance management. To make things even easier, this integration can be deployed whether you’re only concerned with one site or if you leverage cross-domain tracking. Clym believes in striking a balance between legal compliance and business needs, which is why they provide Littledata companies with a cost-effective, scalable and flexible platform to comply with LGPD, GDPR, CCPA and other laws as they come online. Clym’s platform provides consumers with an effective and easy-to-navigate way to opt-out of data collection while not infringing upon the website UI that businesses rely on to drive revenues. Check out Littledata’s integration with Clym today to help manage your data privacy regulation compliance from a global perspective without sacrificing the valuable data your marketing team relies on for its digital strategy. This is a guest post from Michael Williams, Partner at Clym, a leading provider of data privacy law consent management software. After starting his career with Ernst & Young, Michael has provided executive leadership to multiple organizations with a focus on long-term strategy, day-to-day financial management and legal concerns (especially privacy!) Michael is a California-licensed attorney with his J.D. from the University of Connecticut and an M.B.A. from Bryant University.

A new set of privacy rules have transformed companies' online relationships with European clients. General Data Protection Regulation (GDPR) is here to stay, and whether you currently trade in Europe or plan to in the future, you need to make sure your website cookie usage complies with it. Fail, and your company could face some very big fines. How big, you ask? The penalties for getting GDPR compliance wrong are huge: the greater of €20M or 4% of your company's annual revenue. In one case, Vodafone Spain received €8M in fines in 2020 for violations relating to improper marketing data usage. The good news is that Littledata has you covered; GDPR compliance is as easy as installing our app. We'll show you exactly how Littledata helps you comply with GDPR and protects you from a major financial headache. But first, let's dive into the details of GDPR for ecommerce sites: how it works, what good and bad compliance look like, and how to check that your store is GDPR compliant. How does GDPR govern cookie usage? The European Union ePrivacy Directive (2009), together with GDPR (2018), make it compulsory to ask European internet users for informed consent before using cookies to store their personal data. In other words, a user needs to opt-in by clicking on a cookie banner or popup before a website can track their activity with analytics tools. This also gives the user the right to opt-out of their previous consent for cookie usage, and stop any tracking (known as revocable consent). How does GDPR cookie consent affect Google Analytics tracking? Each time a user triggers the Google Analytics script to load on your website, it adds a cookie (the _ga cookie) with an identifier to track the user across multiple pages and sessions. Next, it sends that cookie identifier to Google's servers, along with each page view and event. To be compliant with GDPR, you can't allow Google Analytics to add that cookie before the user has opted in. The problem here is that many online stores track users on Google Analytics before they consent to cookie usage. If they didn't, they could lose valuable marketing attribution by not tracking the user after they opt in. Littledata now has an easy way to get this right. How cookie banner consent should work Right now, the most common way to get informed consent from a user is to show them a cookie banner or popup explaining that your store uses cookies, then allow them to accept or reject being tracked. See this webinar for more discussion on the legality of different wording and displays you can use. Shopify's app store lists many such cookie banner apps, but just having the Accept Cookies button is not enough. Remember, you need to make sure that you do not track users before they opt in. To use the example given by Shopify's own banner app, when a visitor first lands on Kay Nine Supply's website they're shown a banner, and any tracking or setting of cookies has to wait. After the first page of the visit loads, the user has a choice: OK or No thanks. Users who click OK can be immediately tracked (even though it happens after the page load), and users that click No thanks must not be tracked. How Shopify's Customer Privacy API helps with cookie consent Shopify recognized stores had a problem trying to integrate with these myriad cookie consent apps. So, they created a Customer Privacy API where apps can share whether and when the user consented to be tracked. If you want to integrate Littledata's tracking with your cookie consent app, you need to make sure it's using this Customer Privacy API. That way when the user clicks to consent or not, their choice is shared first with Shopify, then with Littledata's tracking script. You will also need to change your store settings so that your store waits for the user to grant consent before tracking. Here's how to set that up: In your Shopify admin, click Online Store.Click Preferences > Customer privacy.Click Limit tracking for customers in Europe. How to configure Littledata to use the Customer Privacy API If you're already a Littledata customer, you can change to respectUserTrackingConsent in the LittledataLayer settings. We don't enable this by default due to the changes below. Our tracking script waits for the user to grant consent, then whenever that happens — on the first page or later — we send the tracking calls to either Google Analytics or Segment. The downside of GDPR cookie compliance for marketing attribution Complying with GDPR does come at a cost to marketing attribution. For example, if your landing page contains UTM parameters in the link to track a campaign, and the user does not consent to tracking, then you will lose the source of the user's visit. If the user continues to checkout and purchase, Littledata's server-side tracking will record the sale without any link to the marketing campaign which brought them. In Google Analytics, these non-consenting users will appear in the "Direct" marketing channel (although in a future feature we are planning to clarify that they Opted Out). In reality, most users do consent for sites to track them, so this feature will limit but not remove all marketing attribution in Google Analytics or other tools. What more can your store do to comply with GDPR? Many of the cookie banners I've seen lack an option for the user to revoke consent or adjust their preference after the first page. I don't believe this has been tested in court, but some stores may want to go further and use a tool such as OneTrust PreferenceChoice to give users finer control over which cookies they want to allow and when. Littledata also integrates with OneTrust, making use of Shopify's Customer Privacy API. So, when the user consents to 'Cookies for performance' (category 2), we will start tracking on Google Analytics and stop when the user revokes consent. This requires the addition of another script. Here's an example of OneTrust setup with Age UK. When the user clicks "Accept all Cookies" Littledata's tracking starts. Then, if the user opts out of "Cookies for performance," the tracking stops. How does cookie consent relate to CCPA compliance? The California Consumer Protection Act (CCPA) does not require you to get cookie consent prior to tracking. CCPA does require stores to disclose what data they collect through cookies and what they do with the data (i.e. in your cookie policy) so users can opt-out of their data being sold. Since there is no way you can sell personal data from Google Analytics, CCPA doesn't apply here. How can you check if your store is GDPR compliant? You'll need to be familiar with Chrome's developer tools to run these checks. Firstly, open your store landing page in an incognito window to make sure no cookies were previously stored. Next, leave the cookie banner or popup open and check that there is no _ga cookie... ...and that there is no network request to Google Analytics by searching for collect URL that Google uses: Then click to "accept cookies," but stay on the same page. You should now see: 1. The _ga cookie is present 2. A network request is sent to Google Analytics Didn't pass all these checks? Then you'll need Littledata's help to avoid those GDPR fines.

In two high-profile data breaches this year – at Ticketmaster and British Airways – over half a million credit cards were stolen via a compromised script inserted on the payment pages. Update 8/7/19: British Airways was fined a record £183m over this data breach, under new GDPR regulation. They are contesting the fine. Google Tag Manager is a powerful tool which enables you to insert any script you want onto pages of your website, but that power can used against you by hackers if you're not careful – and below we’ll look at how to stop GTM being a security risk on your payment pages. Firstly, how did the hackers get the card details from these sites? And how is it relevant to GTM on your site? Security firm RiskIQ has traced the breach to a compromised Javascript file which skimmed the card details from the payment form. So when a user entered their credit card number and security code on BritishAirways.com (or their mobile app) those details were posted to a third party server, unknown to British Airways or the customer. This is a high-scale equivalent of placing a skimming devices on an ATM, which reads one card at a time. In Ticketmaster’s hack the script was one loaded from a chatbot vendor on their site, Inbenta. Inbenta claims not even to have been aware the script was used on payment pages. The changes to the script were subtle: not breaking any functionality, and in BA’s case using a domain ‘baway.com’ which looked somewhat authentic. To protect your site against a similar attack you obviously need to lock down accounts used by your developers to change scripts in the page source code, but you also need to secure GTM – which can be used to deploy such scripts. We have a few rules at Littledata to help reduce risks in using tag management on payment pages: 1. Use pixels over custom JavaScript tags on payment pages You probably need a few standard tags, such as Google Analytics, on payment pages but try to avoid any custom scripts which could possibly skim card details. Many non-standard tags use JavaScript only to create the URL of a tracking pixel – and it is much safer (and faster) to call the tracking pixel directly. Contact the vendor to find out how. (Littledata's Shopify app even removes the need to have any script on the payment pages, by hooking into the order as it's registered on Shopify's servers) 2. Avoid loading external JavaScript files in GTM Many vendors want you to load a file from their server (e.g. myvendor.com/tracking.js) from GTM, so they can update the tracking code whenever they want. This is flexible for them, but risky for you. If the vendor gets hacked (e.g. with Inbenta above) then you get compromised. It’s less risky to embed that script directly in GTM, and control version changes from there (although a fraction slower to load the page). Of particular risk is embedding a tag manager within a tag manager – where you are giving the third party rights to publish any other scripts within the one tag. Don’t do that! [subscribe] 3. Lock down Edit and Publish rights on GTM Your organisation probably has a high turnover of contract web developers and agencies, so have you checked that only the current staff or agencies have permission to edit and publish? It's OK to have external editors use 'workspaces' for version control in GTM, but ideally someone with direct accountability to your company should check and Publish. 4. Blacklist custom JavaScript tag on the payment pages You can set a blacklist from the on-page data layer to prevent certain types of tags being deployed on the payment pages. If you have a GTM container with many users, this may be more practical that step 3. 5. Remove tags from old vendors There are many thousands of marketing tools out there, and your company has probably tried a few. Do you remove all the tags from vendors when you stop working with them? These are most at risk of being hacked. At Littledata we run a quarterly process for marketing stakeholders opt-in tags they still need for tracking or optimisation. 6. Ensure all custom JavaScript tags are reviewed by a developer before publishing It can be hard to review minimised JavaScript libraries, but worth it for payment pages if you can’t follow rules 1 and 2. If you’re still worried, you can audit the actual network requests sent from payment pages. For example, in Chrome developer tools, in the 'Network' tab, you can inspect what requests sent out by the browser and to what servers. It’s easy for malicious code to hide in the patchwork of JavaScript that powers most modern web experiences, but what is harder to hide is the network requests made from the browser to external servers (i.e. to post the stolen card information out). This request to Google Analytics is fine, but if the domain of a request is dubious, look it up or ask around the team. Good luck, and keep safe with GTM!

From 25th May 2018 Google allowed you to automatically wipe user-level data from the reporting from before a cut-off date, to better comply with GDPR. We made the change for Littledata's account to wipe user-level data after 26 months, and this is what we found when reporting before February 2016. Reports you can still view before the user data removal  Audience metrics Pageviews ✓ Sessions  ✓ Users  X Bounce rate  ✓  Audience dimensions Demographics  X OS / Browser  X Location  X User Type  X  Behaviour Pageviews ✓ Custom events X

When the GDPR regulation comes into effect later this month, it will impact all websites trading with EU citizens. That means any ecommerce site with customers in Europe! Is your Shopify store ready to comply? We recently updated our Shopify app (since release 7.8) to help Shopify stores which use Google Analytics comply with GDPR. In addition to automatic fixes to help your store comply, we include recommendations for how to update your site content (such as Terms and Conditions), and how to deal with the new 'two year rule'. If you're running a Shopify store, the time to act is now. Automatic fixes with our Shopify app The first two steps are done automatically when you install our GDPR-ready Shopify app. If you're already using Littledata's Shopify app, these two fixes can be applied when you upgrade to our latest tracking script (version 3.2). Here's what they address. 1. Anonymise customer IP addresses The IP address of your website visitor is considered personal information under GDPR, and to remove any risk that this is sent to Google’s servers in the USA, our script scrambles the last few digits of the IP address. Google already promises not to store the IP address, so this step is an extra level of safety. This slightly reduces the accuracy of tracking which city your visitor came from -- but we believe that this is a small price to pay for ensuring anonymity. 2. Filter personal emails and ZIP/postcodes from pageviews Many sites accidentally send personal data in the page URLs or titles tracked by Google Analytics. For example, apps with their own checkout often send the user email as a URL parameter like ‘/url?email=myname@gmail.com’. Our script now filters that personal data out at source, so the page path you’ll see in Google Analytics is ‘/url?email=REMOVED’. Additional manual steps There are two additional manual steps to ensure that Google Analytics for your Shopify store is GDPR-compliant. 3. Update your terms and conditions You need to update your website T&Cs to ensure users are aware of the Google Analytics Advertising Features that our Shopify app activates and Google uses to identify user demographics, such as gender and interests. We are not lawyers, but we suggest using something similar to these sentences to describe what data is collected, how you (and we) use the data, and how how users can opt out: Our site uses Google Analytics Advertising Features to deduce your gender, age group and interests based on other types of websites you have visited. We use this in aggregate to understand which demographics engage with areas of our website. You can opt out with Google's browser add-on. 4. Remove user-specific information after 2 years You should also change the data retention period for your Google Analytics web property, so that Google removes all user-specific information from their database after 2 years. To make this change, logging to your GA account and go to the Settings cog, and then Property > Tracking info > Data Retention. Use the 'data retention' drop-down menu to select to keep user data for 26 months, and mark 'reset on new activity' to ON. This means that after 26 months, if the user has not come back to your website, any user cookie will be deleted. We think this sensible to comply with the Right to Erasure without making any practical limits to your analysis. [subscribe] Right to Erasure feature coming soon! We're also working on a feature to help websites comply with the Right to Erasure or Right to be Forgotten. Here's a summary of that aspect of the regulation, from the summary of key changes at EUGDPR.org. Right to be Forgotten Also known as Data Erasure, the right to be forgotten entitles the data subject to have the data controller erase his/her personal data, cease further dissemination of the data, and potentially have third parties halt processing of the data. The conditions for erasure, as outlined in article 17, include the data no longer being relevant to original purposes for processing, or a data subject's withdrawing consent. It should also be noted that this right requires controllers to compare the subjects' rights to "the public interest in the availability of the data" when considering such requests. Littledata's Right to Erasure feature will ensure that when you delete a customer from your Shopify admin interface, any references to that customer are deleted from Google Analytics. This won’t affect aggregate reporting, such as number of web sessions or transactions. When do GDPR regulations take effect? The official enforcement date for General Data Protection Regulation (GDPR) is 25 May 2018. At that time any organisations in non-compliance may face heavy fines. In short, we recommend implementing the fixes above ASAP for your Shopify store. All you need is Google Analytics account and our Shopify app. And do check our blog regularly for updates. This is the best place to hear about new Littledata features relating to GDPR, as well as news and analysis about how the regulations affect different types of online businesses, including ecommerce websites, subscription businesses, and membership-based sites such as large charities and nonprofits. Looking for additional support? Contact us about GDPR consulting for analytics setup.

Ecommerce companies typically store lots of personally identifiable information (PII), so how can you make compliance easier without compromising analysis? With the deadline for GDPR compliance looming, I wanted to expand on my previous article on GDPR and Google Analytics to focus on ecommerce. Firstly, who does this apply to? GDPR is European Union legislation that applies to any company trading in Europe: so if you sell online and deliver to European Union member countries, the regulations apply to you. It's essential that you understand how your online business is collecting and storing PII. Splitting PII from anonymous data points Your goal should be to maintain two separate data stores: one that contains customer details, from where you can look up what a specific customer bought, and one that contains anonymous data points, from where you can see performance and trends. The data store for the customer details will typically be your ecommerce back-end and/or CRM (see below). This will include name, email, address, purchase history, etc. It will link those with a customer number and orders numbers. If a customer wants the right of access all the relevant details should be in this store. We use Google Analytics as the anonymous data store (although you may have a different ecommerce analytics platform). There you can store data which only refers to the customer record. These are called pseudo-anonymous data points under GDPR: they are only identifiable to a customer if you can link the customer number or order number back to your ecommerce back-end. Pseudo-anonymous data points you can safely send to Google Analytics include: Order number / transaction ID Order value / transaction amount Tax & shipping Product names and quantities Customer number Hashed email address (possibly a more flexible to link back to the customer record) If a customer exercises their right to removal, removing them from the ecommerce back-end will be sufficient. You do not also have to remove them from your Google Analytics, since the order number and customer number now have nothing to refer to. You do still need due process to ensure access to Google Analytics is limited, as in extreme circumstances a combination of dimensions such as products, country / city and browser, could identify the customer. [subscribe] Isn’t it simpler to just have one store? Every extra data store you maintain increases the risk of data breaches and complexity of compliance – so why not just analyse a single customer data store? I can think of three reasons not to do so: Marketing agencies (and other third parties) need access to the ecommerce conversion data, but not the underlying customer data Removing a customer’s order history on request would impact your historic revenue and purchase volumes – not desirable Your CRM / ecommerce platform is not built for large scale analysis: it may lack the tools, speed and integrations needed to get meaningful insights Beware of accidental transfers There are a few danger areas where you may inadvertently be sending PII data to Google Analytics: Customer emails captured in a signup event A customised product name – e.g. ‘engraving for Edward Upton’ Address or name captured in a custom dimension Our PII audit check is a quick, free way to make sure that’s not happening. Multiple stores of customer details GDPR compliance becomes difficult when your customer record is fragmented across multiple data stores. For example, you may have product and order information in your ecommerce database, with further customer contact details in a CRM. The simplest advice is to set up automatic two-way integrations between the data stores, so updating the CRM updates the ecommerce platform and visa-versa. Removing customer records from one system should remove them from the other. If that’s not possible, then you need clear processes to update both systems when customer details change, so you can comply with the right to rectification. Conclusion GDPR compliance need not require changing analytics tools or databases, just a clear process for separating out personally identifiable information – and training for the staff involved in handing that data. I hope this brief overview has been helpful. For further advice on how your ecommerce systems comply, please contact us for a free consultation. Littledata has experience with every major analytics platform and a wide range of custom setups. However, as a number of global companies are concurrently prepping for compliance, we highly recommend that you get in touch sooner rather than later!

From May 2018 the new General Data Protection Regulations (GDPR) will come into force in the European Union, causing all marketers and data engineers to re-consider how they store, transmit and manage data – including Google Analytics. If your company uses Google Analytics, and you have customers in Europe, then this guide will help you check compliance. The rights enshrined by GDPR relate to any data your company holds which is personally identifiable: that is, can be tied back to a customer who contacts you. The simplest form of compliance, and what Google requires in the GA Terms of Use, is that you do not store any personally identifiable information. Imagine a customer calls your company and using the right of access asks what web analytics you hold on them. If it is impossible for anyone at your company (or from your agencies) to identify that customer in GA, then the other right of rectification and right of erasure cannot apply. Since it is not possible to selectively delete data in GA (without deleting the entire web property history) this is also the only practical way to comply. The tasks needed to meet depends on your meaning of ‘impossible to identify’! Basic Compliance Any customer data sent ‘in the clear’ to GA is a clear break of their terms, and can result in Google deleting all your analytics for that period. This would include: User names sent in page URLs Phone numbers captured during form completion events Email addresses used as customer identifiers in custom dimensions If you’re not sure, our analytics audit tool includes a check for all these types of personally identifiable information. You need to filter out the names and emails on the affected pages, in the browser; applying a filter within GA itself is not sufficient. But I prefer a belt-and-braces approach to compliance, so you should also look at who has access to the Google Analytics account, and ensure that all those with access are aware of the need not to capture personal data and GDPR more generally. You should check your company actually owns the Google Analytics account (not an agency), and if not transfer it back. At the web property level, you should check only a limited number of admins have permission to add and remove users, and that all the users only have permission to the websites they are directly involved in. Or you could talk to us about integrations with your internal systems to automatically add and remove users to GA based on roles in the company. [subscribe] Full Compliance Other areas which could possibly be personally identifiable and you may need to discuss are: IP addresses Postcodes/ZIP codes Long URLs with lots of user-specific attributes The customer’s IP address is not stored by Google in a database, or accessible to any client company, but it could potentially be accessed by a Google employee. If you’re concerned there is a plug-in to anonymise the last part of the IP address, which still allows Google to detect the user’s rough location. ZIP codes are unlikely to be linked to a user, but in the UK some postcodes could be linked to an individual household – and to a person, in combination with the web pages they visited. As with IPs, the best solution is to only send the first few digits (the ‘outcode’) to GA, which still allows segmenting by location. Long URLs are problematic in reporting (since GA does not allow more than 50,000 different URL variants in a report) but also because, as with postcodes, a combination of lots of marginally personal information could lead to a person. For example, if the URL was mysite.com/form?gender=female&birthdate=31-12-1980&companyName=Facebook&homeCity=Winchester This could allow anyone viewing those page paths in GA to identify the person. The solution is to replace long URLs with a shortened version like mysite.com/form And for bonus points... All European websites are required to get visitors to opt in to a cookie policy, which covers the use of the GA tracker cookie. But does your site log whether that cookie policy was accepted, by using a custom event? Doing so would protect you from a web-savvy user in the future who wanted to know what information has been stored against the client ID used in his Google cookie. I feel this client ID is outside the scope of GDPR, but guaranteeing that the user on GA can be linked to opt-in consent of the cookie will help protect against any future data litigation. The final area of contention is hashing emails. This is the process used to convert a plain email like ‘me@gmail.com’ into a unique string like ‘uDpWb89gxRkWmZLgD’. The theory is that hashing is a one-way process, so I can’t regenerate the original personal email from the hash, rendering it not personal. The problem is that some common hashing algorithms can be cracked, so actually the original email can be deduced from a seemingly-random string. The result is that under GDPR, such email hashes are considered 'pseudonymized' - the resulting data can be more widely shared for analysis, but still needs to be handled with care. For extra security, you could add a ‘salt’ to the hashing, but this might negate the whole reason why you want to store a user email in the first place – to link together different actions or campaigns from the same user, without actually naming the user. There are ways around that strike a compromise. Contact Littledata for a free initial consultation or a GDPR compliance audit.