Tag: Analytics

If you need help with your tagging plan oroptimizing your Analytics accounts, contact us, we’ll be delighted to discuss and implement the solutions you need;

Also, if you want to advance on your own and become an Analytics ninja, don’t forget to work on your Conversion Funnels; Check out our artilce “How to set up Conversion Funnels in Google Analytics“: you’ll be guided step by step; Happy reading!

Of course, we’d like to avoid having to pay for a useless machine. We’ll see that there’s a way to have zero machines and still have an automatic scaling system.

However, there is one prerequisite: we need a way of knowing when it’s time to scale up again.

At Adenlab we use a taskqueue(MRQ) for our recurring jobs. MRQ allows us to route our jobs to specific worker groups, depending on the queue and/or the task itself. Each worker group is linked to an ASG, so we have a clear metric here: for a given ASG, do we have any jobs queued?

With all this, we can use the following ASG structure:

A small (read: inexpensive) machine that will always be up (not self-leveling)

One or more ASGs, without auto-scaling policy

By creating an ASG without an auto-scaling policy, GCE will let us scale to zero machines if we want. On our little machine, we’ll have a script that runs every 5 minutes and checks each MRQ worker group for jobs to process.

If this is the case, the script will create an auto-scaling policy for the worker group concerned, and scale it up to 1 machine. The auto-scaler can then add additional machines as required, depending on the base metric configured (in our case, CPU utilization).

Let’s write an MRQ task for this script. Already the necessary imports :

from mrq.task import Task
from google.oauth2 import service_account
from googleapiclient import discovery
import time
import re

First, we need to configure a few parameters concerning GCP :

class ScaleUp(Task):
    project_name = "name of your GCP project"
    zone = "europe-west1-c" # adapt your zone here
    service_account_path = "service_account_credentials.json"
    # groups that are not concerned by this task
    groups_to_skip = ("group1",)

Add to groups_to_skip the worker groups that should not be auto-scalated: at least add the group of the machine that will unstack this task.

Now let’s write the main method of our task:

def run(self, params):
    credentials = service_account.Credentials               
        .from_service_account_file(
            self.service_account_path
        )
     
    self.service = discovery.build(
        "compute", 
        "v1", 
        credentials=credentials, 
        cache_discovery=False
    )
    # We need to have a way to know what we want our different
    # autoscaling policies to be.
    # We could store them in a DB and fetch them here,
    # so that it is shared with our Ansible playbooks for instance.
    # For simplicity here we'll just hardcode them here:
    self.autoscaler_configs = {
        "group2": {
            "min_replicas": 1,
            "max_replicas": 10,
            "cooldown": 180,
            "cpu_target": 0.80
        },
        "group3": {
            "min_replicas": 1,
            "max_replicas": 8,
            "cooldown": 180,
            "cpu_target": 0.90
        }
    }
    # First we need to fetch existing ASGs
    self.fetch_groups()
    # Next we want to know which groups currently have an autoscaler
    self.fetch_autoscalers()
    # Check each groups and see if we should scale them up
    self.check_groups()

Here’s how to retrieve ASG information:

def fetch_groups(self):
    self.groups = {}
    request = self.service.instanceGroupManagers() 
                          .list(
                            project=self.project,
                            zone=self.zone
                          )
    while request is not None:
       response = request.execute()
       for asg in response['items']:
           group_name = asg["baseInstanceName"]
           self.groups[group_name] = {
                "base_name": group_name,
                "name": asg["name"],
                "size": asg["targetSize"],
                "link": asg["selfLink"]
            }
       request = self.service.instanceGroupManagers() 
                             .list_next(
                               previous_request=request,
                               previous_response=response
                             )

We hydrate self.groups with ASG information. For more info on ASG structure, see here.

Now let’s take a look at the code we’ll use to create an autoscaler for a given worker group:

def create_autoscaler(self, group):
    autoscaler_config = self.autoscaler_configs[group]
    config = {
        "target": self.groups[group]["link"],
        "name": "%s-as" % group,
        "autoscalingPolicy": {
            "minNumReplicas": autoscaler_config["min_replicas"],
            "maxNumReplicas": autoscaler_config["max_replicas"],
            "coolDownPeriodSec": autoscaler_config["cooldown"],
            "cpuUtilization": {
               "utilizationTarget": autoscaler_config["cpu_target"]
            }
        }
    }
    operation = self.service.autoscalers().insert(
        project=self.project,
        zone=self.zone,
        body=config
    )
    wait_for_operation(operation)

You can find the wait_for_operation code in this example.

The last thing we need is a method for scaling up an ASG:

def scale_up(self, group, size=1):
    if self.groups[group]["size"] > 0:
        # Already scaled up
        return
    # Make sure we have an autoscaler
    if not self.autoscalers.get(group):
       self.create_autoscaler(group)
    operation = self.service.instanceGroupManagers().resize(
        project=self.project,
        zone=self.zone,
        instanceGroupManager=self.groups[group]["name"],
        size=size
    )
    wait_for_operation(operation)

The final logic of our task is quite simple:

def check_groups(self):
    # Now we have everything we need for the actual task logic:
    for group in self.groups:
    if group in self.groups_to_skip:
        continue
    if self.should_scale_up(group):
        self.scale_up(group)

should_scale_down is the method that should contain your scaling logic. We don’t provide it here, but remember that in our case it’s a question of checking whether or not we have jobs waiting to be processed.

This task is scheduled to run every 5 minutes. This is convenient for our use case, because even if there are no pending jobs, a team member can perform an action at any time, which will result in the creation of a new job.

We don’t want to have to wait too long for it to be started. Of course, for any user actions that create jobs and are supposed to get a quick response, we need a dedicated machine that’s always up.

In most cases, however, it’s best to avoid asynchronous tasks for user interactions that require feedback.

So now we can scale up a machine when we need it, and GCE will take over if we need more. But we also need a way to scale down to zero when we don’t need it again!

To do this, we have a second task, running every 30 minutes, which will execute the same code as the first, with the difference that it will remove the autoscaler and scale to 0 machines if there are no pending jobs.

We can inherit our new task from the previous one, so that we have all the methods we need to communicate with GCP :

class ScaleDown(ScaleUp):

We also need some new methods to scale down:

def delete_autoscaler(self, group):
    autoscaler = self.autoscalers[group]
    operation = self.service.autoscalers().delete(
        project=self.project,
        zone=self.zone,
        autoscaler=autoscaler["name"]
    )
    wait_for_operation(operation)
    
def scale_down(self, group):
    if self.groups[group]["size"] == 0:
        # Already scaled down
        return
    # Delete the autoscaler so that we can scale to zero machine
    if self.autoscalers.get(group):
      self.delete_autoscaler(group)
    operation = self.service.instanceGroupManagers().resize(
        project=self.project,
        zone=self.zone,
        instanceGroupManager=self.groups[group]["name"],
        size=0
    )
    wait_for_operation(operation)
    
def check_groups(self):
 
    for group in self.groups:
        if group in self.groups_to_skip:
            continue
        if self.should_scale_down(group):
            self.scale_down(group)

When we know there are no more pending jobs, we remove the autoscaler and scale down completely. Again, should_scale_down contains the scale down logic to be implemented.

The positive side of this approach is that we can have several scaling criteria. For example, to avoid scaling up and down several times in a row too close together, we can also check that a certain amount of time has elapsed without a job being created before scaling down.

All traffic sources together account for 100% of attribution points. Depending on the attribution model used, this 100% is allocated differently:
Last interaction: the last source of incoming traffic gets 100% of the credit.

⇒ First interactionThis is the 1st point of contact which obtains 100% of the points.

⇒ Last non-direct clickWhen direct attribution channels are removed from the equation, all points are awarded to the last indirect click.

⇒ Last click on a Google Adss: 100% of points are awarded to the last ad clicked on Google.

⇒ Linear allocationEach channel used by the visitor up to the point of sale shares the 100% equally.

⇒ Depreciation over timeAll traffic sources are taken into account, but the last ones score more points.

⇒ Position-based allocation1st and last contact points are awarded 40% of points each. The others share the remaining 20%.

⇒ Data-driven attribution: This attribution model uses Google Ads algorithms and actual performance data from your campaigns to determine how clicks on your ads contribute to conversions. Unlike other models, it’s dynamic and customized according to your account data.

The tracking system is at the very top of the list of configurations that need to be set up correctly. Without it, you run the risk of missing out on key data on existing conversion stages on your site.

Tools for checking your configuration

There are various tools you can use to check your analytics configuration and make sure everything’s running smoothly.

Tag Assistant: perfect for checking configuration and resolving detailed problems at “page” level.

Tag Assistant is a Chrome extension that can be used to validate and diagnose your Google Analytics data on a page-by-page basis. Once you’ve solved a problem, you can return to Tag Assistant to check that your tags are working properly.

Screaming Frog SEO Spider: ideal for detecting site bugs across all pages. This tool is perfect for finding out whether your tracking code is correctly installed on all your pages.

There are two versions available: a FREE version, for websites up to 500 URLs, and a paid version, for more than 500 URLs.

Your tracking code
At the very least, you should check two things with regard to the tracking code installed

Tracking code version: if you haven’t already done so,
make sure you switch to Universal Analytics. Tag Assistant will display the
version you’re using and whether or not you need to migrate.

**Code location **: where to place your tracking code depends on whether you use Google Tag Manager or not.

It is increasingly recommended to use Google Tag Manager for tracking configuration.

Getting the code implementation right (according to your tagging plan) is a crucial step in getting reliable information from Google Analytics.

This means you need to identify the user over time, even if they use multiple devices or browsers. Fortunately, in most cases, actions such as making a purchase or subscribing to a membership involve some form of authentication. While it’s possible to track retention metrics with Google Analytics alone, in most cases you’ll get much better (and more accurate) results by combining it with other solutions.

Conversion tunnels or sales funnels are essential for understanding the steps your customers take before reaching their final conversion, and the obstacles that prevent them from doing so.

You can think of each stage of your sales funnel as a central touchpoint that you want people to reach on their way to conversion. Once you’ve defined each of these stages, you can identify the friction zones: the places where people get stuck, leave or don’t continue the conversion process. When you have this information, you can optimize your page design and site flow, adjusting the right elements to capture more conversions. And suddenly, you know what’s working on your website and what’s not – so you can start adjusting and improving.

Optimize your Analytics data and tagging plan with Tag Manager

If you use Google Ads, Gmail, Google Docs, Youtube or any other Google product for your business, you must use the same account for Google Analytics. Once you’ve logged in to your Google account, you’ll sign up for Google Analytics.

To create your Google Analytics account, enter the details of your website or application.

Confirm the settings for data sharing between Google Analytics and other Google commercial products and click on Get tracking ID to complete the creation of your free Google Analytics account.

Your Google Analytics tracking ID is a number and code that uniquely identifies your website or application.

Popular app makers, website builders like Wix, content management systems like WordPress and e-commerce platforms like Shopify have specific instructions on how to add Google Analytics tracking code to your website or app.

Visit your website’s administrative dashboard to find out how to start tracking users of your website or app with Google Analytics.