More on Segments in Google Analytics
Permanent, Dynamic, and Sequence Segments, oh my!
Welcome back to our beginners guide on using segments in Google Analytics! If you remember last week’s article, it was all about how you can and should be using segments in Google Analytics.
Today, we’re going to go a little more into what’s necessary to finish that article — specifically how you can get that segmentId for your permanent segments, and then spend most of the remaining article talk about creating dynamic segments.
Onwards!
Accessing Permanent Segments in Google Analytics API
While you are not able to create permanent segments in Google Analytics API, you are able to access segments that you have already created and use those segments in your data requests to Google Analytics.
To tell Google specifically which segment that you want to segment your data with, you will need to access the id of that specific segment.
Unfortunately, this segment id is not accessible via the Google Analytics user interface, and we have to access it via the Google Analytics Management API.
Luckily, you can use the Google Analytic API playground on the right side of the Google Analytics API documentation to bypass this issue and get your segments and their ids in no time, simply use the link below and authorize yourself for the api playground — no additional parameter needed.
However, the response you get will be one long string in json format. You will need to use one of the json formatters online to convert that json into legitimate format that you can read — one of the formatters that I use frequently is displayed below:
Through this method you will get ALL of the segments your use have access to in different views, so you need to do some filtering around if you have too many accounts.
After identifying the segment id of the segment you want, create a segment object with “segmentId” parameter populated with your segment id, and you are all set in creating this segment.
Creating Dynamic Segments
Now let’s talk about creating dynamic segment in Google Analytics. The processing of creating a dynamic segment is very similar to creating a filter clause as explained in chapter 5 of this guide, so I would recommend reviewing that article first before proceeding.
A dynamic segment object is structured the following way:
{
“name”: string,
“userSegment”: {
object(SegmentDefinition)
},
“sessionSegment”: {
object(SegmentDefinition)
},
}
The name field is pretty self-explanatory, it is the name you want to give the segment that you are creating.
Now, for user segment and session segment, you need to make a decision of what type of segment you want your segment to be.
Remember our discussion about the differences between user and session segments — it is recommended to have your segment being only user or session segments, unless you have advanced needs that will justify the existence of a more detailed filtering mechanism.
Let’s look in detail of the segment definition object:
{
“segmentFilters”: [
{
object(SegmentFilter)
}
],
}
Now if you remember the “rabbit hole” structure of dimension and metric filters that we went through in the previous structure, here we go again.
A segment (session or user) definition has multiple segment filters, with each segment filters being either a simple segment, or a sequence segment (but not both).
Simple Segment:
The object of simple segment can be seen as below:
{
“orFiltersForSegment”: [
{
object(OrFiltersForSegment)
}
],
}
Within each simple segment, there are multiple “orFiltersForSegment”,which contains multiple segment filter clauses that are combined with OR logic (only one condition need to be satisfied).
An illustration of the orFiltersForSegment object can be found below:
{
“segmentFilterClauses”: [
{
object(SegmentFilterClause)
}
],
}
Notice here that while filters clauses within the “OrFiltersForSegments” object are organized with an OR logic, in the “simpleSegment” object, “OrFiltersForSegments” objects are organized in an AND logic among themselves, meaning that all of the “OrFilters” need to be satisfied in order for a session/user to be included in the segment.
Going deeper, each of the filter clauses in the orFilters, have to be either a dimension filter, or a metric filter, both defined as a “dimensionOrMetricFilterForSegment” (it can only be one of each).
{
“not”: boolean,// Union field dimensionOrMetricFilter can be only one of the following:
“dimensionFilter”: {
object(SegmentDimensionFilter)
},
“metricFilter”: {
object(SegmentMetricFilter)
},
// End of list of possible types for union field dimensionOrMetricFilter.
}
The “not” field is a reverse selector that, if set true, select everything that does NOT satisfy the filter conditions.
Then, just like what we see in dimension/metric filters last time, we need to define the filter either as a dimension filter, or a metric filter, but not both by filling out the corresponding field.
The dimension filter is essentially a variation of the standard dimension filter, and is illustrated below:
{
“dimensionName”: string,
“operator”: enum(Operator),
“caseSensitive”: boolean,
“expressions”: [
string
],
“minComparisonValue”: string,
“maxComparisonValue”: string,
}
Same for metric filter, which is illustrated here:
{
“scope”: enum(Scope),
“metricName”: string,
“operator”: enum(Operator),
“comparisonValue”: string,
“maxComparisonValue”: string,
}
It seems to me that the dimension and metric filters used for segments are a lot more mature than the standard filter clauses, with more functions than a regular filter clause.
For dimension filters, the biggest difference is the addition of a “between” operator, which enable user to select a value that is between a min and max value (defined via minComparsionValue and maxComaprisonValue)
This difference also apply for the metric filter. At the same time, the metric filter also enables user to select the “scope” of the filter, which can be one of “User”, “Hit”, and “Session”.
The scope defines to what level you want your data to be aggregated and compared. This scope is usually aligned with your segment type, that is, use sessions if you are creating a session segment, and user if you are creating a user segment. However, if you want to further filter down the data using session filter for a user segment and hit filter for a session segment is not strictly prohibited, you just need to be aware that you are not getting all of your session data for a user, or all of the hit data for a session.
That is all we are going to touch on dimension and metric filters for segment, to both save repeated effort and control the length of the guide.
To understand specifics of each of the filter that is not covered here, please reference our previous discussion linked below, or documentation of the Google Analytics API, whichever you find easier to follow:
Plain English Guide:
Slightly More Detailed:
That’s all of our discussion for a simple segment.
Sequence Segment:
In most cases you will want to use simple segment for your segment definition. However, in some cases you mind find the AND/OR logic in simple segment unable to satisfy your need.
For example, if I want to create a segment for users who have first visited my website via Facebook, and then visited via Google, and then ultimately converted in a later visit, you have to use a sequence segment to illustrate the sequential nature of this classification method.
Then, you need to define a sequence segment illustrated below:
{
“segmentSequenceSteps”: [
{
object(SegmentSequenceStep)
}
],
“firstStepShouldMatchFirstHit”: boolean,
}
A sequence segment needs two pieces of information — all the filter steps that you are defining (via segmentSequenceSteps parameter), and whether you want the step to start immediately on the first hit.
Let’s expand on the second point.
Going back to our previous example. If you set “firstStepShouldMatchFirstHit” to be false, a user that first visited via Linkedin, then via Facebook, then Google will be included in your segment.
However, if you set this field to be true, only user that have their first visit via Facebook and then later on Google can be included in the segment that you are creating, making it a lot more precise, but also the overall user/session count a lot less.
I am not going to linger on this point, however, since if you are using sequential segment you will know your need better than I do, so just do what best fits your analytics desire.
Now let’s look into the object structure for each of the SegmentSequenceSteps:
{
“orFiltersForSegment”: [
{
object(OrFiltersForSegment)
}
],
“matchType”: enum(MatchType),
}
OrFiltersForSegment is the exact same as we see in the previous section, so we are not going to repeat ourselves there.
The interesting addition here is a field called “matchType”, with two options: PRECEDES and IMMEDIATELY PRECEDES.
Here we are seeing the same logic here as the “first step should match first hit field”.
If you choose immediately precedes, the algorithm will make sure the step filter that you are use is immediately followed by the next step. In term of our previous example, if you choose false on “firstSegmentShouldMatchFirstHit” but IMMEDIATELY PRECEDES on the two segment filters that identify traffic from Google and Facebook, then those two session must happen before or after each other regardless where they are out of all sessions by the user, depending on the order you configured.
However, if you choose PRECEDES, this strict sequential matching does not happen, and you will have a much larger selection of users/sessions as an end result.
Wrapping it up
Phew, wrapping up another long, two-parter guide!
Hope this guide gives you everything that you need to know about segmentation, and how to do it with Google Analytics Reporting API.
If you want to know how to apply everything said here into a real-life analytical request, please checkout our previous chapter below, which is a step-by-step guide on how you can setup your own coding environment and submit your first Google Analytics API request.
Next week, we are going to talk about cohort analysis in Google Analytics, and how you can use the cohort feature in the analytics API to submit a request that analyze a specific custom cohort of yours.
This article was produced by Humanlytics. Looking for more content just like this? Check us out on Twitter and Medium, and join our Analytics for Humans Facebook community to discuss more ideas and topics like this!
