Many of Littledata's subscription customers come to us with a similar problem: how to calculate return on advertising spend, considering the varying customer lifetime value (CLV) of subscription signups. Calculating marketing ROI for subscription ecommerce is a big problem with a number of potential solutions, but even the initial problem is often misunderstood. In this post I break down what the problem is, and walk through two proven solutions for getting consistent, reliable CLV reporting in Google Analytics. What is customer lifetime value? I work with all kinds of subscription ecommerce businesses: beauty boxes, nutritional supplements, training courses and even sunglasses-by-the-month. All of them want to optimise customer acquisition costs. The common factor is they are all willing to pay way MORE than the value of the customers' first subscription payment... because they expect the customer to subscribe for many months. But for how many months exactly? That's the big question. Paying for a marketing campaign which bring trial customers who cancel after one payment - or worse, before the first payment - is very different from paying to attract sticky subscribers. A marketing director of a subscription business should be willing to pay WAY more to attract customers than stay 12 months than customers who only stay one month. 12 times more, to be precise. So how do we measure the different contribution of marketing campaigns to lifetime customer value? In Google Analytics you may be using ecommerce tracking to measure the first order value, but this misses the crucial detail of how long those shoppers will remain subscribers. With lifetime customer value segments we can make more efficient use of media, tailor adverts to different segments, find new customers with lookalike audiences and target loyalty campaigns. There are two ways for a marketing manager to see this data in Google Analytics: one is a more difficult, manual solution; the other is an easier, automated solution that ties recurring payments back to the original campaigns. A manual solution: segment orders and assign a lifetime value to each channel It's possible to see the required data in GA by manually segmenting orders and assigning a lifetime value to each channel. For this solution you'll need to join together: (a) the source of a sample of first orders from more than a year ago, by customer number or transaction ID and (b) the CLV of these customers The accuracy of the data set for A is limited by how your Google Analytics is set up: if your ecommerce marketing attribution is not accurate (e.g. using Shopify's out-the-box GA scripts) then any analysis is flawed. You can get B from your subscription billing solution, exporting a list of customer payments (and anonymising the name or email before you share the file internally). To link B to A, you'll need either to have the customer number or transaction ID of the first payment (if this is stored in Google Analytics). [subscribe] Then you can join the two data sets in Excel (using VLOOKUP or similar function), and average out the lifetime value by channel. Even though it's only a sample, if you have more than 100 customers in each major channel it should give you enough data to extrapolate from. Now you've got that CLV by channel, and assuming that is steady over time, you could import that back into Google Analytics by sending a custom event when a new customer subscribes with the 'event value' set as the lifetime value. The caveat is that CLV by channel will likely change over time, so you'll need to repeat the analysis every month. If you're looking to get away from manual solutions and excessive spreadsheets, read on... A better solution: tie recurring payments back to the original campaign(s) What if you could import the recurring payments into Google Analytics directly, as they are paid, so the CLV is constantly updated and can be segmented by campaign, country, device or any other standard GA dimension? This is what our Google Analytics connection for ReCharge does. Available for any store using Shopify as their ecommerce platform and ReCharge for recurring billing, the smart connection (integration) ties every recurring payment back to the campaigns in GA.  Here's how the connector works The only drawback is that you'll need to wait a few months for enough customer purchase history (which feeds into CLV) to be gathered. We think it's worth the wait, as you then have accurate data going forward without needing to do any manual imports or exports. Then, if you also import your campaign costs automatically, you can do the Return on Investment (ROI) calculations directly in Google Analytics, using GA's new ROI Analysis report (under Conversions > Attribution), or in your favourite reporting tool. Do you have a unique way of tracking your marketing to maximise CLV? Are there other metrics you think are more important for subscription retailers? Littledata's connections are growing. We'll be launching integrations for other payment solutions later this year, so let us know if there's a particular one you'd like to see next.

Littledata has launched the first Shopify Flow connector for Google Analytics, enabling Shopify Plus stores to analyse customer journey using a custom event in Google Analytics. In addition to Littledata's native connections with Shopify, Shopify Plus, Facebook Ads, ReCharge, etc., we have now launched a beta version of a Flow connector for Google Analytics. What is Shopify Flow? Flow is an app included with Shopify Plus, which enables stores to define automation pathways for marketing and merchandising. Think of it as an ‘If This Then That’ generator just for Shopify. For example, after an order is marked as fulfilled in Shopify’s admin you might want to trigger an email to ask for a review of the product. This would involve setting a ‘trigger’ for when an order is fulfilled and an ‘action’ to send an email to this customer. How do you use Littledata Flow actions? You install Littledata's Shopify app along with Shopify Flow Every time an order is created in your store we send it to Google Analytics, along with information about which customer ID made the order (nothing personally identifiable) You add Littledata's actions to your Flow Every time the order or customer event is triggered, even for offline events, the event is linked back to Google Analytics In Google Analytics you can then: Segment the customer base to see if these actions influence purchasing behaviour Visualise when these events occurred Analyse the customers making these actions: which geography, which browser, which marketing channel (in GA 360) Export the audience to retarget in Google Ads (in GA 360) Export the audience to run a website personalisation for using Google Optimize How do you set the actions up in Flow? Google Analytics customer event – can be used with any customer triggers, such as Customer Created Google Analytics order event – can be used with any order triggers such as Order Fulfilled, Order Paid, How else could I use the events? You can now link any of your favourite Shopify Apps with Flow connectors into Google Analytics. Some examples would be: Analyse if adding a product review leads to higher lifetime value   Retarget in Google Ads after a customer's order is fulfilled - Download .flow file   Set up a landing-page personalisation for loyal customers (using Loyalty Lion connector) - Download .flow file How much does this cost? The Flow connectors are included as part of Littledata’s standard subscription plans. You’ll need Littledata’s app to be installed and connected to link the events back to a customer – and to get reliable data for pre-order customer behaviour. [subscribe] Can Littledata set up a flow for a specific app? Our Enterprise Plans offer account management to help you configure the Littledata Shopify connection, including the Shopify Flow connectors. Get in touch if you have a specific app you'll like to make this work with.  

If your business relies on customers or subscribers returning to your site, possibly from different devices (laptop, smartphone, etc.) then it’s critical you start tracking unique customers rather than just unique visitors in Google Analytics. By default, Google Analytics tracks your customers by browser cookies. So ‘Bob’ is only counted as the same visitor if he comes to your site from the same browser, but not if he comes from a different computer or device. Worse, if Bob clears his cookies or accesses your site via another mobile app (which won't share cookies with the default browser) then he'll also be counted as a new user. You can fix this by sending a unique customer identifier every time your customer signs in. Then if you send further custom data about the user (what plan he / she is on, or what profile fields they have completed) you can segment any of the visits or goals by these customer attributes. There are 2 possible ways to track registered users: Using Google Analytics’ user ID tracker By storing the clientId from the Google cookie when a new user registers, and writing this back into the tracker every time the same user registers In both cases, we also recommend sending the user ID as a custom dimension. This allows you segment the reports by logged in / not logged in visitors. Let's look at the pros and cons. Session stitching Tracking customers involves stitching together visits from different devices into one view of the customer. Option 1, the standard User ID feature, does session stitching out the box. You can optionally turn ‘session unification’ on which means all the pageviews before they logged in are linked to that user. With option 2 you can stitch the sessions, but you can't unify sessions before the user logs in - because they will be assigned a different clientId. So a slight advantage to option 1 here. Reporting simplicity The big difference here is that with option 1 all of the user-linked data is sent to a separate 'registered users' view, whereas in options 2 it is all on the same view as before. Suppose I want a report of the average number of transactions a month for registered vs non-registered visitors. With both options, I can only do this if I also send the user ID as a custom dimension - so I can segment based on that custom dimension. Additionally, with option 1 I can see cross-device reports - which is a big win for option 1. Reporting consistency Once you start changing the way users are tracked with option 2 you will reduce the overall number of sessions counted. If you have management reports based on unique visitors, this may change. But it will be a one-time shift - and afterwards, your reports should be stable, but with a lower visit count. So option 1 is better for consistency Conclusion Option 1 - using the official user tracking - offers a better route to upgrade your reports. For more technical details on how this tracking is going to work, read Shay Sharon’s excellent customer tracking post. Also, you can watch more about customer tracking versus session tracking in this video. Have any questions? Comment below or get in touch with our team of experts!   Get Social! Follow us on LinkedIn, Twitter, and Facebook and keep up-to-date with our Google Analytics insights.

Universal Analytics promises some juicy benefits over the previous standard analytics. But having upgraded 6 different high traffic sites there are some pitfalls to be aware of. Firstly, why would you want to upgrade your tracking script? More reliable tracking of page visitors - i.e. fewer visits untracked More customisation to exclude certain referrers or search terms Better tools for tracking across multiple domains and tracking users across different devices Track usage across your apps for the same web property Ability to send up to 20 custom dimensions instead of the previous limit of only 5 custom variables If you want to avoid any interruption of service when you upgrade, why not book a quick consultation with us to check if Universal Analytics will work in your case. But before you start you should take note of the following. 1. Different tracking = overall visits change If your boss is used to seeing dependable weekly / monthly numbers, they may query why the number of visits has changed. Universal Analytics is likely to track c. 2% more visits than previously (partly due to different referral tracking - see below), but it could be higher depending on your mix of traffic. PRO TIP: Set up a new web property (a different tracking code) for Universal Analytics and run the old and new trackers alongside each other for a month. Then you can see how the reports differ before sharing with managers. Once this testing period is over you'll need to upgrade the original tracking code to Universal Analytics to you keep all your historic data. 2. Different tracking of referrals Previously, if Bob clicked on a link in Twitter to your site, reads, goes back to Twitter, and within 30 minutes clicks on a different link to your site - that would be counted as one visit and the 2nd referral source would be ignored. In Universal Analytics, when Bob clicks on the 2nd link he is tracked as a second visit, and 2nd referral source is stored. This may be more accurate for marketing tracking, but if Bob then buys a product from you, going via a secure payment gateway hosted on another domain (e.g. paypal.com) then the return from the payment gateway will be counted as a new visit. All your payment goals or ecommerce tracking will be attributed to a referral from 'paypal.com'. This will ruin your attribution of a sale to the correct marketing channel or campaign! PRO TIP: You need to add all of the payment gateways (or other third party sites a user may visit during the payment process) to the 'Referral Exclusion List'. You can find this under the Admin > Property > Tracking codes menu: 3. Tracking across domains If you use the same tracking code across different domains (e.g. mysite.co.uk and mysite.com or mysite.de) then you will need to change the standard tracking script slightly. By default the tracking script you copy from Google Analytics contains a line like: ga('create', 'UA-XXXXXXX-1', 'mysite.com');. This will only track pages that strictly end with 'mysite.com'. PRO TIP: It's much safer to change the tracker to set that cookie domain automatically. The equivalent for the site above would be ga('create', 'UA-XXXXXXX-1', 'auto');. The 3rd argument of the function is replaced with 'auto'. 4. Incompatibility with custom variables Only relevant if you send custom data already Custom variables are only supported historically in Universal analytics. That means you will need to change any scripts that send custom data to the new custom dimension format to keep data flowing. Read the developer documentation for more. PRO TIP: You'll need to set the custom dimension names in the admin panel before the custom data can be sent from the pages. You can also only check that the custom dimensions are being sent correctly by creating a new custom report for each dimension. 5. User tracking limitations We wouldn't recommend implementing the new user ID feature just now, as it has some major limitations compared with storing the GA client ID. You need to create a separate view to see the logged-in-user data, which makes reporting pageviews a whole lot more complex. Visits a user made to your site BEFORE signing up are not tracked with that user - which means you can't track the marketing sources by user PRO TIP: See our user tracking alternative. Got more tips on to setting up Universal Analytics? Please share them with us in the comments, or get in touch if you want more advice on how to upgrade!   Get Social! Follow us on LinkedIn, Twitter, and Facebook and keep up-to-date with our Google Analytics insights.

There’s a difference between the ‘screen size’ measured as standard in Google Analytics and the ‘browser size’ or ‘browser viewport’. Especially on mobile devices, there are pitfalls comparing the two. Browser viewport is the actual visible area of the HTML, after the width of scroll bars and height of button, address, plugin and status bars has been allowed for. Desktop computer screens have got much bigger over the last decade, but browser viewports (the visible area within the browser window) are not. The CSS tricks site found only 1% of users have their browser viewing in the full screen. While only 9% of visitors to his site had a monitor less than 1200px wide in 2011, around 21% of users have a browser viewport of less than that width. Simply put, on a huge monitor you don’t browse the web using your full screen. Therefore, 'screen resolution' may be much larger than 'viewport size'. The best solution is to post browser viewport size to GA as a custom dimension. P.S. Google Analytics does have a feature within In Page Analytics (under Behaviour section) to overlay Browser Size, but it doesn’t work for any of the sites I look at.