Create the ultimate Google Analytics Dashboard for Drupal – Part 3

This is the third and final part of this blog series. In the first part we installed and customized the Google Analytics Reports module and in the second part we created a Social Media Dashboard that displays the data in table format using Views.

The dashboard that we created in the previous part displays useful information, but the real fun starts when we create charts to visualize the data and make them easily understandable to everyone.

 

Following a similar procedure as in the previous post, you first have to create different Views panes for every specific metric and then use Page Manager to display all of them together in the dashboard.

 

Unfortunately, the Google Analytics Views module does not still support the “Chart” format, so you have to use the Views Dataviz module. After the installation, there is a new “Dataviz” format in Views, which you can use to create the charts.

 

 

The Dataviz settings are really simple, allowing you to customize the chart display:

 

 

Grouping field: If your report contains multiple dimensions, you have the ability to group your chart by one or more fields and display it in a more meaningful way.

 

Type: From this menu, you can select the type of the chart. Depending on your selection, there may be a secondary menu with more options. For example, for the line chart you can select if you want line smoothing or not and for the pie chart you can define if the text on the pie slices will be a percentage, the actual value, the label of this figure, or just nothing. Usually, it makes sense to experiment with different chart types, trying to find the optimal way to present the data. 

 

Width, Height: You can also define the exact width and height of every chart, or just leave it blank to use the default values.

 

Colors: In this field, you can select the specific colors for your chart, separated by a comma. Accepted values are hex colors (like #6495ED) and color names (like LightCoral).

 

Enable interactivity:  This checkbox defines if the charts will be interactive or not. 

 

So, by keeping the same field definition that we used in the previous postand changing the format from Table to Dataviz, you can easily transform your dashboard. For the specific reports that we built, I preferred to use the Pie Chart type for the three top ones, the column chart for the two next ones and the line chart for the last one. Of course, you can experiment with different types and decide what makes more sense for your case.

 

The final result can be seen in the following image:

 

 

Using Views to display Google Analytics data is the easiest way to do it, but sometimes it’s not that flexible. If you have specific requirements for a report, which cannot be created with Views, you can always write your custom code, using the Google Chart API module.  There are some code examples on the module's documentation page. We will examine more complex use cases with custom code, in one of our future blog posts. 

Create the ultimate Google Analytics Dashboard for Drupal – Part 2

In the first part of this series, we discussed how to install and configure the Google Analytics Reports module for Drupal and display some basic metrics. In this second part, we are going to examine how to create your own custom dashboards, using the Google Analytics Core Reporting API. The latest update of the API on September 18th, added a lot of new Metrics and Dimensions related to social and mobile and now gives us the ability to create more useful marketing reports.

So, for our example, we are going to create a Social Media Dashboard, to track social activities and see if and how they drive engaged users and qualified traffic. Here’s how the final Dashboard will look like:

To create these reports, you have to to use the 7.x-3.x-dev version of theGA Reports module, as it offers integration with Views 3. You also need toapply this patch that adds all the new "datapoints" as Views Fields.

After the module installation, you will be able to create a new view, with the option to use Google Analytics data:

In order to build the Dashboard, first you have to create different Views Content Panes and then, using Page manager to build a custom Dashboard page with Panels. To create the Views, you can use all the available GA dimensions and metrics as fields, filters and sort criteria.
The first pane, named Social Visits, displays the most important Social Networks that drive traffic to the site, sorted by the number of visits.. In order to build it, you have to use the following settings:

There are three fields: The dimension ga:socialNetwork will represent the different Social Networks as rows in the table and the metrics ga:visits and ga:visitBounceRate will represent the two columns that display visits and bounce rate.

The second pane, Social Mobile Visits, displays identical data, but only for visitors that used a mobile device. The view is similar, but this time you have to use an extra filter for the mobile users.

The next pane, Social Mobile Visits by Device, displays the specific mobile devices that the visitors from Social Networks used. Google Analytics provides again the right metrics to track this kind of data:

In our fourth report, Landing Pages for Social, tracks the major Landing Pages for Social Networks Visits, helping to understand and optimize the visitor’s flow.

The fifth report, Social Actions, tracks the social actions that visitors perform in the site. If you’re using social buttons, you have to follow the directions from Google Analytics documentation, in order to track Facebook likes or tweets in the website.

In the final report, Goal Completion by Source, we display the total number of conversions for the main social sources.

The final step is to create a Page from Page Manager (admin/structure/pages/add) and add the View Panes to the Panels Layout:

Using the same method and with a little help from the Google Analytics API Documentation and Query Explorer, you can create any dashboard for different departments or specific needs (ex. Newsletter Dashboard, SEO Dashboard etc) and you can give access only to specific users or roles.

In the next part of this series, we are going to examine how we can use the Google Charts API to produce charts and present the Google Analytics data in a more interesting and useful manner.

Create the ultimate Google Analytics Dashboard for Drupal – Part 1

As the ability to calculate digital marketing return on investment (ROI) is critical and even the C-suite cares about conversion rates, web analytics are becoming more important. All the members of an organization start to demand more information about the web site’s statistics. As it is not enough any more to just create reports about visits and pageviews, the access to different data for different persons became necessary.

Of course, we could start creating custom dashboards inside Google analytics, but then we would have to create credentials for different persons and also train them on how to use Google Analytics (GA) and how to locate important to them information.

 

Using the Google Analytics Reports module, we can begin by easily creating a dashboard with the basic metrics inside our Drupal web site. Then, by using the Google Analytics Data Export API, we can create custom reports, to inform for example the management for KPI’s of different channels, like SEO, social media or newsletter campaigns. There reports will be easily accessible by just signing in with their Drupal accounts, without the need to use an external system. 

 

The first step is to install the Google Analytics Reports module. Prerequisites are the Google Charts API module and the OAth module. Do not forget to set the module’s permissions about who has access to the reports.

 

After installing the modules, you have to authorize your site to use data from Google Analytics, from admin/config/system/google-analytics-reports. If your domain is registered with Google Apps for Business, you can enter it in the related field. The easiest way is to authenticate with your Google Analytics account, by clicking on “Start setup and authorize account”.  

 

 

In the next step, you allow access to your Google Analytics account from the website, to obtain access to the data. If you have multiple GA profiles, you choose the appropriate one. In this step you can also choose a Query cache period, as the GA quota is 50,000 requests per project per day. 

 

 

After this step, the basic dashboard is ready at: admin/reports/google-analytics. The layout and the provided information are too basic, but at least we now have a framework to start creating our ideal dashboards.

 

 

There are also two blocks named “Google Analytics page traffic” and “Google Analytics site visits” that can be enabled for specific roles.

 

 

In the next part we are going to examine how we can use the Google Analytics Data Export API, to create more useful reports and how we can customize their layout.

When do we refactor code?

If you are a developer it is almost certain that you had to refactor code at some point. Refactoring is no joy, especially if it is not your code and badly written.

In the bigger picture refactoring is ever-present. Just take a look at the Drupal ecosystem. You could refactor content types, display suite fields or views.

 

In this blog post I will give you an insight in how we deal with code refactoring at Amazee Labs.

 

The three code states

I like to think that the code we write can have three states:

• stable code: code that is subject to almost no changes, and at the same time permits to easily add new functionality.
• code to be refactored: this is the code that we are working on, or it is marked with @todo and a comment regarding why and what should be refactored.
• bad code: code that should be refactored, but nobody is aware of it - at least not yet... You will only notice when the client reports a bug or a feature request that cannot be implemented without changes in that portion of code.

Managing @todos

One of the though lessons learned is that when you set a @todo, unless you reserve exclusive time for code refactoring, you will not refactor that code until it is subject of a bug. Since, our first rule regarding code refactoring is actually to try to avoid it, or to make it really early in the development stage, and not let too many @todos go into production. But in the real world, this rarely happens, there always will be @todo in the code.

 

The next thing is how you report a @todo. A bad example is:

 

// @todo: This code has to be refactored.

 

This does not give a clue what the code does now or why the code should be changed. You should always point out the reason why the code needs to be refactored.

 

 

Refactoring

Then, when the time comes to actually refactor the code, the question is: How do you refactor? It depends on the code that has to be refactored, but most of the time it involves moving code into a separate function, changing the structure of a classes tree or moving the implementation from a function oriented to an object oriented approach.

Finally, you have to check if your refactored code really works. Because you refactored the code, this does not mean that you fixed the bugs. You could even have introduced new ones. So to ensure this didn't happen, the best thing is  to have automated tests that you run on your code, which is not always a trivial task to do.

 

The five conclusions

1. If possible, try to avoid having many @todos in your code, especially in the one that goes to production.
2. Always write good documentation for what you have to refactor. It would be good to specify why the code has to be refactored, the priority and optionally why you've chosen not to refactor yet. 
3. Refactor the code as soon as possible. Ideally is in the development stage.
4. Always test the new code. If you refactor it, it does not mean that that code is correct.
5. Avoid writing code you know that you will have refactore it in the future.

If you are looking for a more general blog post on code refactoring you should take a look at SourceMaking's "Introduction to Refactoring".