For every retail loser there's a retail winner

Today PwC's retail survey found the British high street is being reshaped as shoppers shift online - especially in fashion, where a net 100 high street stores closed. This misses the positive side of the story: all those shoppers are buying from independent UK brands online instead, which is one of the fastest growing area of the UK economy. We looked at 30 mid-sized online fashion retailers (with average sales of £1m per month) who get a majority of their traffic from the UK. This collection had grown their sales by an aggregate 21% from October 2017 to October 2018 (year on year). Fashion shoppers love to browse unique designs on Instagram and Pinterest, compare prices and get easy home deliveries. Independent ecommerce brands are bringing original designs to the British wardrobe, and we should celebrate their success.   Behind the research Littledata gathers benchmark data from Google Analytics on over 12,000 websites, including many types of ecommerce businesses. Our customers get insights into their performance and recommendations on how to improve online conversion. [subscribe]

2018-11-09

Categorising websites by industry sector: how we solved a technical challenge

When Littledata first started working with benchmark data we found the biggest barrier to accuracy was self-reporting on industry sectors. Here’s how we built a better feature to categorise customer websites. Google Analytics has offered benchmarks for many years, but with limited usefulness since the industry sector field for the website is often inaccurate. The problem is that GA is typically set up by a developer or agency without knowledge or care about the company’s line of business - or understanding of what that industry sector is used for. To fix this problem Littledata needed a way to categorise websites which didn’t rely on our users selecting from a drop-down list. Google Analytics has offered benchmarks for many years, but with limited usefulness since the industry sector field for the website is often inaccurate. [subscribe] The first iteration: IBM Watson NLP and a basic taxonomy Our first iteration of this feature used a pre-trained model as part of IBM Watson’s set of natural language APIs. It was simple: we sent the URL, and back came a category according to the Internet Advertising Bureau taxonomy. After running this across thousands of websites we quickly realised the limitations: It failed with non-English websites It failed when website homepage was heavy with images rather than text It failed when the website was rendered via Javascript Since our customer base is growing most strongly outside the UK, with graphical product lists on their homepage, and using the latest Javascript frameworks (such as React), the failure rate was above 50% and rising. So we prioritised a second iteration. The second iteration: Extraction, translation and public APIs The success criteria was that the second iteration could categorise 8 sites which the first iteration failed with, and should go on to be 80% accurate. We also wanted to use mainly public APIs, to avoid maintaining code libraries, so we broke the detection process into 3 steps: Extracting meaningful text from the website Translating that text into English Categorising the English text to an IAB category and subcategory The Watson API seemed to perform well when given sufficient formatted text, at minimal cost per use, so we kept this for step 3. For step 2, the obvious choice was Google Translate API. The magic of this API is that it can detect the language of origin (with a minimum of ~4 words) and then provide the English translation. That left us focussing the development time on step 1 - extracting meaningful text. Initially we looked for a public API, and found the Aylien article extraction API. However, after testing it out on our sample sites, it suffered from the same flaws as the IBM Watson processing: unable to handle highly graphical sites, or those with Javascript rendering. To give us more control of the text extraction, we then opted to use a PhantomJS browser on our server. Phantom provides a standard function to extract the HTML and text from the rendered page, but at the expense of being somewhat memory intensive. Putting the first few thousand characters of the website text into translation and then categorisation produced better results, but still suffered from false positives - for example if the text contained legal-ease about data privacy it got categorised as technical or legal. We then looked at categorising the page title and meta description, which any SEO-savvy site would stuff with industry language. The problem here is that the text can be short, and mainly filled with brand names. After struggling for a day we hit upon the magic formula: categorising both the page title and the page body text, and looking for consistent categorisation across the two. By using two text sources from the same page we more than doubled the accuracy, and it worked for all but one of our ‘difficult’ websites. This hold-out site - joone.fr - has almost no mention of its main product (diapers, or nappies), which makes it uniquely hard to categorise. So to put it all the new steps together, here’s how it works for our long-term enterprise client MADE.com's French-language site. Step 1: Render the page in PhantomJS and extract the page title and description Step 2: Extract the page body text, remove any cookie policy and format Step 3: Translate both text strings in Google Translate Step 4: Compare the categorisations of the title vs page body text Step 5: If the two sources match, store the category I’m pleased that a few weeks after launching the new website classifier we have found it to be 95% accurate. Benchmarking is a core part of our feature set, informing everything that we do here at Littledata. From Shopify store benchmarks to general web performance data, the improved accuracy and deeper industry sector data is helping our customers get actionable insights to improve their ecommerce performance. If you’re interested in using our categorisation API, please contact us for a pilot. And note that Littledata is also recruiting developers, so if you like solving these kind of challenges, think about coming to join us!

2018-10-16

Are you benchmarking your ecommerce site in the right sector?

Littledata launched benchmarks for websites two years ago. They quickly became a key feature of our app, and as customers became more engaged, so did ideas for how to improve our benchmarking and the algorithms that learn from those benchmarks. In response to customer feedback and deeper research into industry sectors, we've made some really exciting improvements over the last few months to make the comparisons even more useful -- and even more dynamic. The changes are five-fold. Detailed sectors and sub-sectors. Almost every customer we talked to said the benchmark comparison was most useful if it was for very similar sites. Previously we only had 50 high-level sectors to compare with; now we have hundreds of low-level sectors. You can visualise the full range. Smarter auto-categorisation of your website. Our machine learning process now has a 95% chance of finding the best sector for your website, meaning you can compare against the most useful benchmark without filling in a single form! Ability to manually change industry sector. And of course, if you're in that 5% that needs human input, then you (or your Enterprise account manager) can pick a better sector in the general app settings page. You might also want to change sectors just to see how you compare. No problem. Benchmarks for technology stacks. Want to see if you are making the most of a technology such as Shopify or Yieldify? Now you can compare with other sites using the same technology, making our ecommerce benchmarking even more powerful for agencies and web developers. Benchmarks for starter websites. Previously we only generated benchmarks for sites with at least 500 monthly visits. We dropped that to 200 monthly visits, so starter websites can see a comparison - and see more detail as they grow. We've launched a live visualisation of how our AI-based website categorizer is mapping a range of industry sectors. It offers a full overview of website categories and segments. And you can drill down to see more details. For example, we've seen a big rise in wine, coffee and health shake retailers this year, many of whom are using our ReCharge integration to get insight into their subscription business models. As our algorithms learn about ecommerce businesses selling beverages of many varieties and automatically categorises sites accordingly, you can now look closely at a particular segment to see how your site compares. Littledata is an Agile company. We're constantly iterating, and continuously improving the benchmarks to make them more actionable, so please give us feedback if you'd like to see more. Happy benchmarking! [subscribe]

2018-09-25

What's the real ROI on your Facebook Ads?

For the past decade Facebook’s revenue growth has been relentless, driven by a switch from TV advertising and online banners to a platform seen as more targetable and measurable. When it comes to Facebook Ads, marketers are drawn to messaging about a strong return on investment. But are you measuring that return correctly? Facebook has spent heavily on its own analytics over the last three years, with the aim of making you -- the marketer -- fully immersed in the Facebook platform…and perhaps also to gloss over one important fact about Facebook’s reporting on its own Ads: most companies spend money with Facebook 'acquiring' users who would have bought from them anyway. Could that be you? Here are a few ways to think about tracking Facebook Ads beyond simple clicks and impressions as reported by FB themselves. The scenario Imagine a shopper named Fiona, a customer for your online fashion retail store. Fiona has browsed through the newsfeed on her Facebook mobile app, and clicks on your ad. Let’s also imagine that your site -- like most -- spends only a portion of their budget with Facebook, and is using a mix of email, paid search, affiliates and social to promote the brand. The likelihood that Fiona has interacted with more than one campaign before she buys is high. Now Fiona buys a $100 shirt from your store, and in Facebook (assuming you have ecommerce tracking with Pixel set up) the sale is linked to the original ad spend. Facebook's view of ROI The return on investment in the above scenario, as calculated by Facebook, is deceptively simple: Right, brilliant! So clear and simple. Actually, not that brilliant. You see Fiona had previously clicked on a Google Shopping ad (which is itself powered by two platforms, Google AdWords and the Google Merchant Center) -- how she found your brand -- and after Facebook, she was influenced by a friend who mentioned the product on Twitter, then finally converted by an abandoned cart email. So in reality Fiona’s full list of interactions with your ecommerce site looks like this: Google Shopping ad > browsed products Facebook Ad > viewed product Twitter post > viewed same product Link in abandoned cart email > purchase So from a multi-channel perspective, how should we attribute the benefit from the Facebook Ad? How do we track the full customer journey and attribute it to sales in your store? With enough data you might look at the probability that a similar customer would have purchased without seeing that Facebook Ad in the mix. In fact, that’s what the data-driven model in Google Marketing Platform 360 does. But without that level of data crunching we can still agree that Facebook shouldn’t be credited with 100% of the sale. It wasn’t the way the customer found your brand, or the campaign which finally convinced them to buy. Under the most generous attribution model we would attribute a quarter of the sale. So now the calculation looks like this: It cost us $2 of ad spend to bring $1 of revenue -- we should kill the campaign. But there's a catch Hang on, says Facebook. You forgot about Mark. Mark also bought the same shirt at your store, and he viewed the same ad on his phone before going on to buy it on his work computer. You marked the source of that purchase as Direct -- but it was due to the same Facebook campaign. Well yes, Facebook does have an advantage there in using its wide net of signed-in customers to link ad engagement across multiple devices for the same user. But take a step back. Mark, like Fiona, might have interacted with other marketing channels on his phone. If we can’t track cross-device for these other channels (and with Google Marketing Platform we cannot), then we should not give Facebook an unfair advantage in the attribution. So, back to multi-channel attribution from a single device. This is the best you have to work with right now, so how do you get a simple view of the Return on Advertising Spend, the real ROI on your ads? Our solution At Littledata we believe that Google Analytics is the best multi-channel attribution tool out there. All it misses is an integration with Facebook Ads to pull the ad spend by campaign, and some help to set up the campaign tagging (UTM parameters) to see which campaign in Facebook brought the user to your site. And we believe in smart automation. Shhhh...in the past few weeks we've quietly released a Facebook Ads connection, which audits your Facebook campaign tagging and pulls ad cost daily into Google Analytics. It's a seamless way to pull Facebook Ads data into your overall ecommerce tracking, something that would otherwise be a headache for marketers and developers. The integration checks Facebook Ads for accurate tagging and automatically pulls ad cost data into GA. The new integration will normally only be available in higher-tier plans, but we're currently offering it as an open beta for ALL USERS, including Basic plans! For early access, just activate the Faceb|ook Ads connection from your Littledata dashboard. It's that easy! (Not a subscriber yet? Sign up for a free trial on any plan today.) We believe in a world of equal marketing attribution. Facebook may be big, but they’re not the only platform in town, and any traffic they're sending your way should be analysed in context. Connecting your Facebook Ads account takes just a few minutes, and once the data has collected you’ll be able to activate reports to show the same kind of ROI calculation we did above. Will you join us on the journey to better data?

2018-09-20

The World Cup guide to marketing attribution

It’s World Cup fever here at Littledata. Although two of the nationalities in our global team didn’t get through the qualifiers (US & Romania) we still have England and Russia to support in the next round. And I think the World Cup is a perfect time to explain how marketing attribution works through the medium of football. In football (or what our NYC office calls 'soccer'), scoring a goal is a team effort. Strikers put the ball in the net, but you need an incisive midfield pass to cut through the opposition, and a good move starts from the back row. ‘Route one’ goals scored from a direct punt up the pitch are rare; usually teams hit the goal from a string of passes to open up the opportunity. So imagine each touch of the ball is a marketing campaign on your site, and the goal is a visitor purchasing. You have to string a series of marketing ‘touches’ together to get the visitor in the back of the net. For most ecommerce sites it is 3 to 6 touches, but it may be more for high value items. Now imagine that each player is a different channel. The move may start with a good distribution from the Display Ads defender, then a little cut back from nimble Instagram in the middle. Facebook Ads does the running up the wing, but passes it back to Instagram for another pass out to the other wing for Email. Email takes a couple of touches and then crosses the ball inside for AdWords to score a goal – which spins if off the opposing defender (Direct). GOAL!!! In this neat marketing-football move all the players contribute, but who gets credit for the goal? Well that depends on the attribution model you are using. Marketing attribution as a series of football passes Last interaction This is a simplest model, but less informative for the marketing team. In this model the opposing defender Direct gets all the credit – even though he knew nothing about the end goal! Last non-direct click This is the attribution model used by Google Analytics (and other tools) by default. In this model, we attribute all of the goal to the last campaign which wasn’t a Direct (or session with unknown source). In the move above this is AdWords, who was the last marketing player to touch the ball. But AdWords is a greedy little striker, so do we want him to take all the credit for this team goal? First interaction You may be most interested in the campaign that first brought visitors to your website. In this model, Display ads would take all the credit as the first touch. Display often performs best when measured as first interaction (or first click), but then as a ‘defender’ it is unlikely to put the ball in the net on its own – you need striker campaigns as well. Time decay This model shares the goal between the different marketing players. It may seem weird that a player can have a fraction of a goal, but it makes it easy to sum up performance across lots of goals. The player who was closest to the goal gets the highest share, and then it decays as we go back in time from the goal. So AdWords would get 0.4, Email 0.5 (for the 2 touches before) and Instagram gets 0.1. [subscribe] Data-driven attribution This is a model available to Google Analytics 360 customers only. What the Data-driven model does is run through thousands of different goals scored and look at the contribution of each player to the move. So if the team was equally likely to score a goal without Facebook Ads run down the wing it will give Facebook less credit for the goal. By contrast, if very few goals get scored without that pass from Instagram in the midfield then Instagram gets more credit for the goal. This should be the fairest way to attribute campaigns, but the limitation is it only considers the last 4 touches before the goal. You may have marketing moves which are longer than 4 touches. Position based Finally you can define your own attribution weighting in Position Based model, based on which position the campaign was in before the goal. For example, you may want to give some weight to the first interaction and some to the last, but little to the campaigns in between. Still confused? Maybe you need a Littledata analytics expert to help build a suitable model for you. Or the advice of our automated coach known as the analytics audit. After all, every strategy could use a good audit to make sure it's complete and up-to-date. So go enjoy the football, and every time someone talks of that ‘great assist’ from the winger, think of how you can better track all the uncredited marketing campaigns helping convert customers on your site.

2018-07-02

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

Six challenges in developing a Shopify integration

At the start of 2017 Littledata released its first Shopify app. A year on, here are my observations on the technical challenges we’ve overcome. This week we're at Shopify Unite in Toronto, and it's no surprise that their app ecosystem continues to grow. We chose Shopify as our first platform partner due to their open APIs, quality documentation and enthusiasm from other developers. Much of that has been as expected, but to help all of you looking to build your own Shopify app I’ll share some of our learnings on the hidden challenges. Littledata's Shopify app makes it a one-click process for stores to set up for Enhanced Ecommerce tracking in Google Analytics, and then get actionable insights based on the Google Analytics data. It has to hook into Shopify orders and products, as well and modify the store's theme and process ongoing transactions. 1. Handling re-installs gracefully The great advantage of Shopify’s app store over, say, Magento marketplace, is that any store admin can install and pay for an app with a couple of clicks. The disadvantage is that stores can be as quick to uninstall as install. Store admins may start, realise they don’t have permissions, time or energy to continue and roll back to try again later in the day. Since our app inserts a snippet into the store’s theme layout (see point two below), uninstalling removes the web-hooks we set up but does not remove the inserted snippet. When a store re-installs our app has to work out what state they were in when they uninstalled (audit, test mode or live), whether the script snippet is still there and what settings have been changed in the meantime. It took us a few months to get a handle on all the possible user flows, and we’ve found automated end-to-end tests to really speed up running through the different scenarios. In our Meteor framework we use Chimp [link] to run tests through Selenium on localhost and on our staging server. We've also found it essential to track our own stats of 'installs + activations' (including the date of first install and time to finally uninstall) rather than relying on the Shopify Partner stats of uninstalls and installs, which can hide the detail in between. 2. Working with script tags The other side-effect of making apps easy to install is that you can assume the early-adopter stores who will try your app already have lots of other installs. Shopify recommends using the Script Tag API to handle scripts linked to the app, so that when a store uninstalls your app it also removes any client-side scripts from the store. Unfortunately, in early tests we found the load latency to be unacceptably high: on some stores, only 50% of the page load events were getting fired before the user moved off the page. So plan B was add a snippet to the store theme, and then load this snippet at the top of the <body> element on all the layout templates. This has worked much more predictably, except when theme editors remove the snippet reference without enquiring what the Littledata app does (see our fifth challenge). [subscribe] 3. Charge activation vs authorisation Now a very simple gotcha. In our first month we had around 60 installs at a flat price of $20/month, but apparently no revenue. After investigation we found we had not activated the recurring charges after the store admin had authorised them. Doh! We're still not sure why an app would want to have authorised charges which are not activated -- seems like over-engineering on Shopify's side -- but luckily it was easy to correct without asking for more user permissions. 4. Tracking adds-to-cart The first version of our app tried to run the script when customers got to the ‘/cart’ page of a store. The problem here is that many stores have AJAX or ‘mini’ carts where customers can checkout without every visiting the cart page. We looked to trigger the script before the user got to the cart the page, but this appeared to run too many risks of interfering with the customer actually adding the item. Our final solution has been to poll the Shopify store for the current cart, and see if products have been added (or removed) since we last polled (and stored the previous cart contents in memory). This is somewhat inefficient, as it requires continuous network activity to grab the cart JSON from Shopify, but we’ve reduced the network requests to one every 4 seconds – judging that customers are very unlikely to add a product and checkout in less than 4 seconds. This cart polling has proved more reliable across different store templates. 5. Integrating with other Shopify apps I mentioned that early-adopter stores tend to have lots of other apps: and those apps have loyal customers who push to make Littledata's app to work their chosen app (not just vanilla Shopify). The challenge is that most of these app development companies run a very Agile process, constantly changing how their app works (hopefully to improve the experience for store owners). An integration that worked a few months ago may no longer work. We've found the best solution to be open developer-to-developer communications, via a Slack guest channel. Having the developers implementing the features on each side talk to each other really cuts down the delays caused by a well-meaning project manager slightly misinterpreting the requirement. 6. Handling ongoing updates As tested improved client-side tracking scripts, we needed to update the script in the store theme (see point 2 above). This creates a small risk for the store, as there is no UAT or test environment for most stores to check before going live with the new script. The store theme may also get edited, creating new layout templates where the Littledata snippet is not loaded. In the first version of our app we tried to update and re-insert the latest Littledata snippet automatically on a weekly cycle. However, once we reached hundreds of active installs this became unmanageable and also opaque for the store admins. In the latest version we now allow store admins to UPGRADE to the latest script, and then we check all the correct Google Analytics events are being fired afterwards. Giving the end user control of updates seems a better way of maintaining trust in our brand and also removing risk: if the update goes wrong, it’s quicker for us to alert the store owner on how to fix. Conclusion I’m still sure we made the right choice with Shopify as a platform, as their APIs, partner support and commercial traction are all number one in the ecommerce world. But I hope that by sharing some of the hidden challenges in developing Shopify integrations, we can all build better apps for the community. Have you built something for the Shopify app store? Are there development problems you’ve encountered which I haven’t shared here? PS. Are you a developer interested in joining an innovative analytics company? We're hiring in multiple locations!

2018-05-07

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

2018-05-02

Get the Littledata analytics app

Complete picture of your ecommerce business. Free Google Analytics connection, audit and benchmarks.

Sign up