How to stop Google Tag Manager being hacked

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. 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! 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!

2018-11-24

Google Analytics Data Retention policy - which reports does it limit?

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

2018-06-04

How Littledata helps Shopify stores comply with GDPR

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. 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.

2018-05-02

GDPR compliance for ecommerce businesses

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. 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!

2018-02-13

Is Google Analytics compliant with GDPR?

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. 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.

2017-10-19

Get the app

See for yourself why Littledata is the smartest ecommerce analytics app

Free trial