Optimize your website by managing the client side resources

In a lot of projects I worked on, JS & CSS inclusions were a mess. Too much files, no coherence, bad cache usability, etc. In this article, I’ll try to bring you some concepts and solutions to solve these problems and optimize the loading time of your pages.

These concepts and solutions are valid for both JS and CSS. So I’ll use the words client-side resources for files and client-side scripts for piece of code. And that always will be about JS and CSS. I won’t talk about compression, or minification of resources. We know that they should be compressed, regardless what CMS or tools we are using. I will talk about unification options, and choices that impact on performance.

Assume we develop a site with ten different pages. Some client-side scripts are common, (used by more than one page). In contrast, there’s also some heavy scripts that are specific to a page. Finally, some pages don’t need scripts at all.

Now the questions are:

  • How many client-side resources (how many files) we’ll have ;
  • Whichresource contains which scripts ;
  • And from where they will be loaded.

The unique file approach

We unify all the client-side scripts in one single resource, a “complete-website.js” or “styles.css”. This reduces the number of requests. And this resource is putted in the caches after a visit of one page of our site. Every visits on other pages will benefit of the cache usage.

But even a simple call to one page will load a heavy file with maybe only 5% used. The cache may be empty when we visit a page, and we’ll load awesome UI stuffs such as carousel, swiping and parallax, for nothing. Do we really want to?

Now if we do a modification on a small script used by one page, we have to reunify our big resource and invalidate caches that store it. Modification on a small script happens, meaning frequent cache invalidations.

Many feature-related files approach

So what if each page has it’s own resource? We’ll have files with small code, and we load only the code we need. A client-side resource contains the code for the features a page provides.

But there are many chances that we want to reuse our code in other pages. And I’d rather work on IE than duplicate a code. So let’s say “a client-side resource contains the code of a feature” ! We’ll have files with small code, and we’ll load only the code we need. It’s more modular and easy to maintain.

If we have to modify one of these resources, we just do it, and invalidate caches for one specific URI. Meaning good cache usage.

But if we visit for example a homepage with many client-side features, we will have to load many files. Only the code we need, yes, but with many requests.

So what’s the best approach?

Round-trip time (RTT) is known as more problematic than latency due to bandwidth limitation or too heavy files. So the problem are big amount of files and bad cache usage.

As Andrew B. King says in his book first tip is to limit number of requests.

And as Ilya Grigorik demonstrate in this post, we first have to:

  • Reduce RTT latency by using caches (and especially geolocalized cache such as Akamai).
  • Reduce number of RTT simply by reducing number of requests.

So for a good cache usage in a project that is modified frequently, we’ll choose the “Many feature-related files” approach. And for a less number of requests, we’ll choose “the unique file approach”.

Find the golden mean

If the site is not huge, and the client side scripts not frequently updated. Stop digging your head. Choose the unique file approach. It will be cached. And we’ll have only one request to load all the scripts.

But on a big site, we need some modularity. At least, we need to segment our client-side scripts in three categories :

  • A common client-side resource used by all pages. Let’s name it “internal-lib” ;
  • A few resources for very specific codes, used by only a few pages: “specific-lib” ;
  • And the external libraries or framework we use (but never modify): “external-libs”.

As we never modify the “external-libs”, the cache usage is good. And if we are using cdn and have a bit of chance, the “external-libs” may be cached even before the client visit our site. The internal-lib” is unified, used everywhere, and cached if we don’t modify it too frequently. And finally the “specific-libs” are loaded, just on need. As far as I know, this is a very good compromise.


In a classic architecture, such as Twig & Symfony2. We include all our resources in a “layout” page level, exactly to manage coherence (our golden mean) in one single place. And of course, to do these inclusions in the head of the DOM for CSS and at the end of it for our JS.

The problem is that, at this level, we may not know what specific code we have to include. For the “specific-libs”, we’ll have to determine which templates will be used before we access these templates.

That’s a bit tricky. I would say that all the very specific pages that needs specifics scripts, should use a specific “layout” page, and redo the inclusions at all. In twig, we simply use the blocks and extensions.

In your default twig:

In your specific page:


After all

How to ensure that resources are included in the right order (respecting the dependency chain)? Should it only be about “layout” page coding, and developer‘s good will?

If we don’t pay attention while the project grows and evolve, our “internal-lib” will grow up, becoming a mess, our “specific-libs” will become a transversal norm, and our “external-libs” will be loaded in bad orders. I even seen “external-libs” included multiple time with different versions for a same page!

These kind of problems may need a large refactoring and be very difficult to resolve after a year of development. So when you add a page that needs some client-side scripts, ask yourself:

  • Is that feature already given by “internal-lib” ?
  • If not, should I add it ?
  • Do I really need a new “external-lib” ?
  • Can I replace an old “external-lib” by a new one that meet old and new goals ?

Then, always call the “external-libs” first, then the “internal-lib” and finally the “specific-libs”. If you have problem with dependencies using this order, it probably means that some code in your “specific-libs” should be moved in you “internal-lib”.


Applying these practices will not ensure a high website optimization and performance, but it will contribute for sure.

  • It will allow to control browser cache, in an efficient way, by setting the cache instructions on each client-side resource.
  • It will reduce the weight of your page and number of RTT. Two very important impacts on page performance.

I just heard about new HTTP2 protocol that tend to resolve the performances problems itself. At least regarding RTT. As far as I know, if you design your website for HTTP2, you should reduce amount of data with a high granularity of resources.

In the next article, we’ll adapt these concepts and solutions to a content-centric application and more specifically to Adobe Experience Manager (AEM).

Self managed companies in Switzerland?

“Self-managed companies” or “teal organizations” are a hot topic in many circles. Especially the books “Reinventing Organisations” and “Holacracy” are among the bestsellers in that area.

We at Liip try to be somehow self-managed since quite some time, it comes quite naturally with being agile. Teams (between 5 and 20 people) can decide a lot by themselves already. But of course, there’s still a management on top, which decides about company wide things and also not so company wide things. We now started an active discussion within the company (for example with a session at the last LiipConf) about how it could work, without such a central, top-down management. We haven’t figured out the details yet, but we’re very eager to try.

But we’re also very interested to get to know people who are already doing that or also want to try it. So, please get in contact with me, if you’d like to meet.

To get an idea, what I personally mean with “self-managed company”, here are some questions. If you can answer them with yes, you’re pretty self-managed (in my opinion)

  • Does your company not have a top-down management?
  • Do you have no hierarchy and fixed roles, especially not through job titles?
  • Can people in your company decide on their own without approval from someone “higher up”? Also for investments?
  • Are there no fixed budgets defined from above/centrally?
  • Do people decide about hiring and firing?
  • Do people even decide about their salary?
  • Are you more than “just the founders”? (not sooo important, but maybe for a future growth of your company)
  • Do you have a process to solve conflicts, so that not the one with the bigger voice always wins?
  • Can anyone take responsibility where they want? Define their own roles?
  • Don’t you always try to find a consensus while not trying to please everyone?
  • Do you trust everyone in your company that they take the right decision at that current time?

One important thing in all this is, that “decide on their own” doesn’t mean, they can just do whatever they want or what feels right. There are many different ways to approach this, but the most important part in all of them is, that you have to get advice from the others before deciding something.

I’m really looking forward to the discussions

Tags: , ,

“Time for Coffee!” open sourced!

The public transport app “Time for Coffee!”, made by some Liipers, was finally published at Github under the MIT License. Furthermore the Apple Watch app for it was also released last week, just in time for the watch release in Switzerland this Friday.

Read more about it at the Time for Coffee! blog post.

Tags: , ,

Auch die Letzten sollen endlich online gehen!

Alle Welt schreit Omni-channeling – dabei sind noch gar nicht alle Unternehmen richtig im E-Commerce angekommen.

(english version below)

Aber fangen wir mal von vorne an. Nach mehreren Jahren im Retail- und E-Commerce-Bereich hat es mich jetzt auf die andere Seite verschlagen und damit zu Liip. Wenn man bedenkt, dass ich die letzten Jahre im Onlinehandel Zuhause war – für jeden Aussenstehenden scheinbar eine logische Konsequenz in eine Webagentur zu wechseln. Auch mir erschien dieser Schritt durchaus logisch und als sich dann herausstellte, dass ich sogar E-Commerce-Projekte leiten darf, war mein Glück perfekt.

Meine Welt wurde komplett auf den Kopf gestellt, als ich angefangen habe, mir mein näheres retail- und e-commerce-lastiges Umfeld mal genauer anzuschauen. Dabei fiel mir auf, dass keines der Retail-Unternehmen, in denen ich früher gearbeitet habe, im Jahre 2015 einen Webshop besitzt. Klar ist ein Onlineshop für viele kleine wie auch grosse Detailhändler eine Herausforderung, der sich nicht jeder Retailer stellen möchte. In meinen Augen ist zumindest eine Website heute für jeden noch so kleinen Retailer ein absolutes Muss! Ein Onlineshop ist zwar nicht zwingend – das Fehlen eines Onlineshops aber auf jeden Fall eine verpasste Chance!

 Der Schritt vom erfolgreichen Retailer zum erfolgreichen E-Commerce-Unternehmen, am Besten sogar mit sehr gut ausgebautem Omnichanneling, ist ein beschwerlicher Weg. Das weiss auch die Geschäftsleitung, denn nicht wenige Unternehmen haben beim Versuch erfolgreiche Onlinehändler zu sein, eine schwindelerregend hohe Summe verbrannt und erholen sich nur langsam von dem Schock. Darüber hinaus stehen bei einem Entscheid für E-Commerce viele neue Prozesse, viele neue Mitarbeiter und viele neue Baustellen an, um die es sich zu kümmern gilt.

Dieser Schritt  ist mit der Eröffnung einer neuen Filiale zu vergleichen und benötigt viel Vorarbeit, viel Planung, viel Zeit,ein zuverlässiges Team und  verantwortungsbewusste Partner. Und wenn der (Online-) Shop erst eröffnet ist, muss man diesen weiter pflegen. Was im Kaufhaus der Filialleiter, Merchandiser oder Verkaufsmitarbeiter übernimmt, macht im Online-Shop der E-Commerce-Manager, der Web-Designer oder Online-Marketing-Manager. Und das was im Unternehmen der zuverlässige Lagerleiter ist, ist im Zeitalter von Ecommerce der Operationsmanager und der Entwickler. Anders gesagt: online und offline sind nicht so verschieden wie manch einer meint.

Ein anderes Beispiel: Welcher Retailer würde jemals einen fixfertig eingerichteten Shop kaufen? Übertragen auf den Online-Shop bedeutet dies, dass Liip nicht einfach den fertigen Online-Shop präsentiert. Verglichen mit einem Offline-Store arbeiten bei Liip Schaufensterdekorateur, Inneneinrichter, Logistiker und Personalplaner in einem Team nahtlos zusammen. Von Businesstrategie über Konzeption und Umsetzung bis zum langfristigen Betrieb aus einer Hand. So wird sichergestellt, dass während der “Bauzeit” des Shops nötige Anpassungen und bauliche Änderungen vorgenommen werden können.

Im Retail war ich es immer gewohnt, die Produkte so gut wie möglich in Szene zu setzen. Visual-Merchandiser verbringen Tage und Wochen damit, verblüffende Schaufenster zu gestalten. Aber warum starten so viele E-Commerce Projekte mit dem Design? Ich hätte niemals ein Schaufenster gestaltet, bevor der Shop geplant, gebaut oder gar eingerichtet worden ist.

Wenn die Grundlage das Fundament oder im Webbereich das Backend ist, der Innenausbau einem gut aufgesetzten CMS entspricht und ein zuverlässiges und motiviertes  Team in den Startlöchern steht, muss der Online Shop “nur” noch die gleichen Hürden überwinden, wie eine Offline Location.

E-Commerce: A rocky road we help you to smooth out

The whole world is talking about omni-channel even though, most companies don’t have an e-commerce solution yet.

But lets start from the beginning. After several years managing several retail businesses, I’ve changed sides, went behind the scenes and started a career as IT project manager for Liip.

My whole world stood upside down as I reviewed the business models of my former employers. None of them have a B2C e-commerce solution, even today! Sure, running an online shop is a challenge not every retailer wants to face, but in my opinion, an e-commerce solution is an absolute must!

But leaving the well-known tracks in retail towards a omni-channel strategy is a rocky road. There are more than a few examples of companies that burnt a staggering amount of money, just to get an e-commerce solution that won’t just quite fit to their business. For those companies, this is a blow they barely recover from, since e-commerce doesn’t just affect the web presence, it affects the whole company and it’s processes.

As a retailer, running an e-commerce business can be compared with the opening of a flagship store in the real world: A lot of planning, time and money has to be assigned to an enterprise of this scale. Considering the challenges, gearing up a successful e-commerce business is not that different from it’s real world counterpart. As long as you don’t have the right location, a proper workforce, a fitting interior and solid supply chain there is no use talking about what products you will display in your shopping window. This principle can also be applied to any e-commerce business. Why talk about the design first before you even got your processes in place? This is why we at Liip are determined to give you the whole picture of what it takes to get your e-business running. We do not just provide you with a design, we also shine a light on your processes and get you set up with all the points you have to tick before you can venture into a successful future with e-commerce.

Tags: , ,

Impressions from the Moodle Conference

The annual Moodle conference for the UK and Ireland took place at the Dublin City University,  March 11th to 14th, 2015. Due to the flu that got me down as I got back, this post comes with a slight delay.

The main topics of this years UK & Ireland Moodle conference in Dublin were Learning Analytics and the Moodle Association. Further notable topics were (the more technical) inclusion of Bootstrap 3 in Moodle, the working groups for the simplification of forms and for designing a student dashboard.

As Moodle HQ are in the process of taking ownership of a couple of key Moodle conferences (Dublin was not one of them, but there was strong collaboration), the new format of “working groups” was tested on a larger scale. The idea of a working group is for Moodle users to work on a a specific topic in order to come up with specifications for Moodle HQ to implement as improvements to the Moodle core. The topics here were “form simplification” and “student dashboard”. These working groups have a certain weight, as a delegate from HQ will take part, with the task to make sure the outcomes can (and will) actually be implemented. An interesting observation here was, that at the hackday at the end of the conference, as the working group findings were presented and discussed, the tasks were heavily challenged by developers who naturally prioritise and approach things differently. I could sense a bit of frustration there when a response from HQ representatives would be “this is what the working group was for and basically you’re too late now with your input”. I think it is early days for the working group approach and it will take some time to get used to it.

The most heated discussions were on the initiation of the Moodle Association, as presented by Martin Dougiamas. Martin has been looking for new ways to fund Moodle development for some time now and this is what he decided to do. The Moodle Association is a non profit organisation (and therefore excempt from taxation). It will be completely separate from Moodle HQ after the initial work necessary to launch it. The idea is, for members of the association to come up with specifications and funding for Moodle core development and then to contract HQ to do the work. Martin would like to see instituions to be members in order to comission large junks of development work. There will be a correlation between how much money an entity puts into the association and how many votes it will have. All projects will be up for the association members to vote on. The projects with the highest votes will have the association’s funds allocated to it and will be developed by Moodle HQ. There will be some sort of cap on how many votes individual association members can have.

The idea of this associations opens a lot of questions of course, especially on what it means for Moodle partners who are currently the sole source of funding for Moodle (10% of revenue from Moodle related work by partners goes to Moodle HQ).

The keynote on learning analytics by Bart Rientes from the Open University gave a very interesting insight into what Open University do with their attempt at predictive analytics. The idea there is to show learners which areas of the curriculum they should focus on for the best outcome, based on data analysis. This topic raised two main questions: How do students get to see and use this data and what are the questions we want the (analytics-) system to answer. In a hands-on example with Gavin Henrick I experienced how difficult it is to come up with this question. Without this question being sensibly formulated though, learning-analytics somewhat remains a buzz-word.

The best example of a customised Moodle was presented by Thomas Bell with the United for Wildlife MOOC platform they launched as beta on that day (…). The platform comes with a rather beautiful user interface. Check it out! learn.unitedforwildlife.org

David Mudrak gave a good overview of how the plugins universe works, with a plea for more support on reviewing third party plugins. This reminded me of our initiative to collaborate and publish security reviews of plugins we do for our clients. Somehow it seems hard to motivate developers or companies to collaborate on this.

Davo Smith eloquently convinced us how easy it is to use Behat testing and Dan Poltawski demonstrated how Moodle HQ do continuous integration.

The hackday brought some excellent discussion and follow-up work on the integration of Bootstrap 3 and the state of renderers and templates in Moodle. This was once again the most inspiring part of the Moot, there’s some very talented people that are passionately involved in making Moodle the best VLE out there. This is no easy task, considering the massive amount of code and all those legacy bits still lingering. One of the reasons Moodle needs more funding is to make it the best possible option on the VLE market. The competition is there and work needs to be done. The difficulty here is the generic nature of Moodle: changes need to work for all the users, not just one specific site.

Thanks to Gavin Henrick and the team for making this great MoodleMoot possible. And thanks to Liip for giving this little bit extra to allow me to travel to Ireland by train, bus and boat.

leaving Ireland on the ferry

Tags: , ,

Magento Config Search

Working with Magento configuration it is always a chore. To make a change, you have to find a necessary section, then open it, then open its subsection, then sub-subsection and probably some more… and only after a dozen of cliсks you can finally change necessary Magento configuration item.
Once, while testing new functionality, after routine search of some rarely used settings, I finally got tired and decided to improve this process a little bit.
My attention was drawn to the search field at the top of the admin panel. Existing ‘admin search’ already knew how to perform search among customers, products and orders, so why not to add configuration section to this list as well? As always, I expected that I would have to rewrite basic functionality to achieve the desired result, but I found out a nice way to extend this functionality.

Configurations for the search is stored in the file below:


So, the injection was very easy. I had to add my search model only into the adminhtml/global_search node.

My ConfigSearch model is looking for the matches in the config fields labels, also it takes into account translations. The search result shows you the full config field label and its full path. When matches are found, you’ll see something like this:


When you click on one of the displayed results, you’ll be redirected to the page with this configuration section opened. The field will also be highlighted, so you can find and edit it even more quickly. Task is done!


I hope that this extension will help you a little bit with the navigation in the Magento Admin panel.
source code

Tags: , ,

The Platform.sh Roadshow comes to Zurich

How can you ensure that your deployments will be successful? What should you look for when assessing cloud hosting providers? And where can you find the ideal toolset for cloud-based PHP hosting, especially for Drupal and Symfony applications?

All these questions and more were answered when Liip AG played host to the Platform.sh team recently, giving us the chance to present our revolutionary Git-based cloud hosting solution to customers, partners and like-minded agencies during an evening event on the eve of May Day.

Miro Dietiker kicked the evening off with a presentation on Drupal 8, underlining that the new CMS’s advanced technology stack will challenge practices and require an optimal hosting solution and toolset. Miro went on to explain how Platform.sh is integral to the MD Systems approach to Drupal 8.

The second speaker, Tom Schneider, took up the Drupal 8 topic, describing how his team at the Südostschweiz newspaper worked with MD Systems to build a ready-to-use Drupal 8 news portal distribution known as NP8. Remarkably, this system is already live, stable and highly performant on Platform.sh, despite Drupal 8’s beta status. You can read more about this in our press release.

By this time the audience had heard enough hype: it was time to see a demo. Robert Douglass, Platform.sh’s VP of Customer Success provided just that, showing how Platform.sh can speed onboarding, optimise development workflows, lower risk in deployment, and offer remarkable flexibility in terms of technology compared with other PaaS offerings.

Last, but definitely not least, came Liip’s very own Lukas Smith, who provided some great insight into how Platform.sh provides an ideal environment for Symfony hosting, and how easily newbies can get to grips with the solution. He provided the example of a fellow Liiper who had a few hours left over before a vacation, and managed to get up and running with Platform.sh and integrate a complete ecommerce solution before it was time to go home.

The assembled guests had plenty to discuss once the talks were over, and fuelled by the delicious canapés and the excellent wine, discussions across a range of topics continued until dinner time.

Find out more about Platform.sh at: https://platform.sh

The User Experience of APIs

After having read how some people can hold and transmit the terrible misconception that designing APIs has nothing to do with designing great experiences, I felt one could provide a few insights into the benefits of shaping an API around its consumers – the developers and the machines – as much as around the data.

APIs are for humans what websites are for machines

Like a website, a point-of-sale, …, a web API is just another service touchpoint. And as any web-based touchpoint nowadays, its audience is part humans, part machines.

Interestingly, the audience and content structures of an API are diametrically opposed to those of a website.

A website is explored by machines – called bots – who precede and orient a (hopefully) larger number of human visits. A website main content targets its main human audience, while its metadata targets its secondary audience: machines.

For an API, it’s just the opposite.

An API is explored by humans – developers, mostly – who precede and orient a larger number of machine visits. An API main content targets its main machine audience, while its metadata targets its secondary audience: humans.

Design APIs with the developer experience in mind

So how can user experience design help with APIs? Think of it as a kind of “Developers Optimization” (like SEO helps machines on your website): by lowering the barrier for the developers to understand and code with your API, you raise chances of adoption, success and reuse.

Suppose that you work for some bank and are designing some kind of money API. The information and action points that this API will convey belong to the banking business domain, maybe evenmore specifically to the field of mortgages, maybe even to a specific understanding of that specific field within that specific domain, an understanding that only exists within your bank.

Yet this future money API is certainly not aimed at you, nor at your business colleagues. What if one of that API’s purposes is to support monetary transactions on gaming platforms? Then game developers might reasonably be your primary human audience, right? and game developers don’t know much about the way your bank thinks and deals with money, right?

As for any service touchpoint, don’t design an API around your business, but around the needs and understandings of those who will consume it.

A few design methods that can really help you designing great API experiences

  1. interview target developers : what do they expect from the API and what do they understand about the business behind it,
  2. build personas out of the insights from these interviews,
  3. benchmark other APIs and their documentation to see what conventions are at play there,
  4. prototype and user test the API before the single line of API logic. Provide the developers with a static mockup of the API response and do a walkthrough with them.

Further readings

The user experience of an API is a relatively new concern, yet – and as usual with new things – several people and organisations are developing it:

Tags: , , ,

React Native hackday

Yesterday we had a hackday on React Native. The goal was to find out how it feels to develop native iOS apps with Javascript and how much we have to learn to get started. GermainPedro and Adrian (myself) participated. Our combined knowledge of Javascript frameworks listed projects like Angular JS, Backbone, Exosjs, Ember, ReactJS and jQuery. Germain did a bit of Swift but basically we are web developers without iOS experience.

We started with setting up the sample app from the tutorial and played a bit with changing content and reloading the app. Live reloading worked for all three of us only for a few changes before it stopped reloading, we have to investigate further what the cause of that is. After setting up Apple Developer accounts we deployed the sample app on our phones which worked well. We liked how easy it was to get started thanks to the react-native-cli tool.

Since I already hacked on an example project with React Native before, I gave a short introduction of React, JSX and StyleSheets. We all got the UIExplorer example running which is great to see what React Native can do and to use as a reference when creating own applications. The examples felt great and well… native.

A hackday wouldn’t be called a hackday without hacking so we thought of something we could work on. We wanted to try to get a sliding menu and maybe hack a bit on the Guess the Liiper sample app. When sharing the Guess the Liiper code we had some issues with setting up the .gitignore file correctly for an XCode project and updating the react-library to the latest version. Pedro and Germain investigated the sliding menu and how to add images while I fixed the Guess the Liiper app to be actually usable. We found the react-native-slide-menu, integrated it into the sample app and used a background image for the content. When requiring the image we had some issues but that seems to be known. We ended up with a working app, see the source code. We went through the source code of Guess the Liiper and thought of how to create a circular progress bar like this. React-native-svg might be useful to create this.

React Native sliding menu sample app


Working with React Native is… reactive! It felt like developing for the web and we didn’t have to spend much time getting into it. With the tutorial, UIExplorer app and the sample app it was easy to get started. The Chrome Debugger and tooling like the great Chrome React extension was for us the usual way to debug javascript apps. When thinking about what to implement we found that many components already exist – mostly in a beta stage but the community is very active.

We had to get used to Xcode, digging into the native tools is necessary of course but finding things in Xcode wasn’t the most intuitive experience for us. With our existing knowledge we think we can get quite far to develop apps, especially for quickly prototyping. Probably it needs more iOS and Swift knowledge for specific functionality like applying filters to images, microphone and camera access etc.

When working on styling we noticed that it would be great to have live editing like in Chrome Developer Tools which we are used to. Since we don’t have any iOS development experience we can’t compare this to the normal way iOS apps are developed. But being able to immediately see style changes made in the Dev Tools would be awesome.

We think that the development experience with React Native is great for web developers. The project is very young and it is too early to tell how disruptive it will be. Many components are being developed and there is definitely traction in the community. We are especially looking forward to the Android version.

Tags: , , , ,

Google Analytics Metrics and Dimensions Cheatsheet

Google Analytics dimensions & metrics cheatsheet

There are times using Google Analytics when you don’t remember the name of a dimension, or wether it’s even a dimension or a metric … There also are times when you even wonder how much details does Google Analytics capture about a aspects of the user interaction on your website or app.

For such times, here’s a PDF cheatsheet of Google Analytics dimensions and metrics, as visual summary of the official documentation.

Tags: , ,