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.