In January 2020, when Google Tag Supervisor’s server-side tagging was first launched to most of the people at SuperWeek, I wrote a flurry of tweets, sharing my imaginative and prescient of a server-side tagging future.
In one of many tweets, I mentioned how you could possibly do these:
- Hit validation and fixing earlier than the hit is shipped to the endpoint
- PII and privateness controls for the requests earlier than dispatch
Quick ahead to in the present day, over three years later, and we’re lastly handled to a characteristic that grants us scalable controls to correctly interrupt information flows inside server-side GTM.
I’m speaking about TRANSFORMATIONS.
It’s a brand new characteristic and useful resource sort in server-side tagging, which you’ll be able to entry by means of the brand new entry within the container useful resource navigator.
Transformations sit firmly between the consumer and tags, permitting you to embody and exclude parameters from the occasion information object earlier than tags can entry it.
You may as well use it to increase current parameters. That is helpful if you wish to enrich the occasion information object with an appropriately designed Firestore pipeline, or one thing related.
Learn on for extra details about how transformations work and the way to use them.
X
The Simmer E-newsletter
Subscribe to the Simmer e-newsletter to get the most recent information and content material from Simo Ahava into your e mail inbox!
Transformations in a nutshell
To know transformations, you first have to recall how purchasers and tags work together in a server-side tagging container.
A consumer is a server-side tagging useful resource whose function is to digest an incoming HTTP request and ideally flip it into an occasion information object.
This occasion information object is then consumed by tags to be able to carry out their duties, resembling dispatching requests to third-party distributors. The occasion information object semantics should not standardized or enforced, however it’s endorsed that purchasers comply with the schema outlined by Google.
For instance, a consumer might take a URL parameter like &cid=12345.12345
and switch it into an occasion information object key named client_id
with the worth 12345.12345
. Tags might then be coded or configured to take this client_id
key from the occasion information object and populate their very own outgoing requests with the worth.
One of the simplest ways to examine what sort of occasion information objects are generated by purchasers is to make use of Preview mode. When you choose an occasion within the left-hand navigation, the Occasion Knowledge tab will present what the consumer produced.
Why don’t you see occasions underneath all of the requests? That’s as a result of there both wasn’t a consumer to declare the request in query, or the consumer didn’t produce an occasion object utilizing a particular template API.
The principle downside with occasion information is that the consumer’s operations are fastened. The occasion information object it produces is identical for all tags which are configured to utilize it. In order for you a tag to disregard sure fields within the occasion information object, or if you would like a set of tags to mutate a few of the values into one other format, the tag template itself must help this, and never all tag templates do.
Moreover, Google’s personal purchasers, which the vast majority of customers will default to as the primary controllers of the incoming information streams, are black packing containers and there’s not a lot you are able to do to regulate how they work.
For lengthy, we’ve been ready for a characteristic that may enable us to edit the occasion information object itself earlier than tags get to eat it.
That is the place transformations enter the stage.
With transformations, now you can create a rule that removes or modifies the values within the occasion information object earlier than tags can entry it.
As a substitute of getting to make tag-specific exceptions, now you can modify the occasion information object itself. After doing so, any tag that’s set to eat this transformation might be privy solely to the modified occasion information object fairly than the unique one.
Importantly, transformations don’t completely edit the occasion information object. They create a reworked clone of the item to be digested by no matter tags and no matter situations you specify within the transformation (extra about these beneath). Tags that aren’t affected by a change could have entry to the unique, unmodified occasion information object.
Create a brand new transformation
To create a brand new transformation, click on the Transformations entry within the left-hand navigation of your server-side tagging container. You’ll see an inventory of your current transformations. When you click on the button labeled NEW, you may create a brand new transformation.
Once you create a change, you’ll first want to decide on its sort.
Transformation varieties
Transformations are available three varieties:
- Enable parameters, which helps you to allowlist the parameters that ought to find yourself within the occasion information object. That is very highly effective, as parameters that aren’t allowed might be excluded from the occasion information.
- Exclude parameters, which helps you to denylist the parameters that ought to not find yourself within the occasion information object. Parameters that aren’t excluded might be included within the occasion information.
- Increase occasion, which helps you to add or modify occasion information parameters. That is the place you’d do information enrichment, delicate information purges, and related.
Enable parameters
Once you select Enable parameters because the transformation sort, you’ll have to populate a desk of rows, with every row akin to a parameter title within the occasion information object.
When this transformation is evaluated, the keys within the occasion information object are in contrast in opposition to the parameters listed on this transformation. If there’s a match, that secret’s saved within the occasion information object.
If there’s no match, then the hot button is dropped from the occasion information object for this transformation.
Within the instance above, the one allowed parameters are client_id
, event_name
, ga_session_id
, and custom_timestamp
. Different parameters should not included on this transformation.
This can be a very highly effective transformation sort, because it allows you to proactively exclude all parameters that you’re not conscious of or that you simply haven’t solely allowlisted for the tags that eat this transformation.
It’s additionally a dangerous transformation sort due to this. Particularly when working with third-party distributors, you won’t know precisely which parameters the seller wants as a result of poor documentation or lazy template design. The Enable parameters transformation is most potent if you’re working with a service for which you understand precisely which parameters are required and that are optionally available.
Exclude parameters
Like Enable parameters above, parameter exclusion requires you to populate a desk of rows, with every row akin to a parameter within the occasion information object.
Nevertheless, this time when evaluating keys within the occasion information object in opposition to this listing, any key that matches between the 2 is dropped from the occasion information object. Keys which are not matched are saved.
On this case, client_hints
and ip_override
have been excluded from the ultimate occasion information object on this transformation. That’s why they’ve empty values above whereas all the opposite parameter values are preserved.
Whereas the allowlist is extra proactive and pre-emptive as a measure, the Exclude parameters transformation allows you to take away parameters that you simply know to be problematic.
Increase occasion
Occasion augmentation is what you’d use for information enrichment and for cleansing up the contents of the occasion information object. As a substitute of eradicating or preserving parameters, the increase occasion transformation sort allows you to add new keys to the occasion information object and/or modify current values.
Once you add parameter names and values into this transformation, any parameters that share the identical title within the occasion information object get overwritten by the transformation’s worth for the given parameter. If there isn’t any pre-existing parameter with that title, a brand new one is added to the occasion information object.
Within the instance above, apart from
forex
, all of the ecommerce parameters are retrieved from Firestore.
The cool factor is that the values you set help the complete vary of server-side Google Tag Supervisor’s variable capabilities, together with issues like asynchronous API calls and Firestore lookups.
Whereas occasion augmentation may be very helpful for eradicating delicate info from the page_location
area, for instance, its greatest potential lies in enriching the knowledge within the occasion information object so {that a} multitude of tags could make use of the modification.
Transformation precedence
It’s doable for a number of transformations to use to a given occasion information key. For instance, you may need a change in place that augments an occasion information key and likewise one other transformation in place that excludes this key underneath sure situations.
On this case it is perhaps smart to set the exclusion at the next precedence, in order that the important thing isn’t unnecessarily augmented in circumstances the place it’s already been excluded.
You could find the precedence setting underneath the Superior Settings of any transformation.
When you don’t specify a precedence, then transformations are evaluated on this default precedence order:
Enable parameters > Increase occasion > Exclude parameters
Matching situations
Matching situations let you allow the given transformation solely when sure variable situations are matched.
For instance, given the Ecommerce augmentation instance from above, it is sensible to solely allow this transformation when the event_name
worth is buy
, as that’s the one occasion that would come with the transaction ID required for fetching the info from Firestore (learn extra about this use case beneath).
If GA4 is your most important incoming information stream, you could possibly even add a Shopper Identify situation to the transformation to guarantee that different forms of incoming streams don’t set off the Firestore lookups.
If any of those matching situations does not match, then the transformation just isn’t evaluated and occasion information just isn’t modified.
Along with limiting transformations to work solely underneath sure situations, you may also apply them solely to particular tags that you simply allowlist within the Affected tags settings.
Within the instance above, my Enable parameters transformation allowlists solely a really restricted vary of occasion information parameters for my customized analytics collector system.
Different tags could make use of your entire occasion information object, however this explicit Customized Analytics Collector tag is just aware of the restricted set allowlisted on this transformation.
Debug transformations
In Preview mode, the primary technique to see transformations at work is to pick out an occasion in Preview mode, after which open a tag that needs to be affected by a change.
Right here, underneath Modified occasion information you’ll see what was obtainable to the tag when it fired. When you examine Present Unique, you’ll see a diff of what the unique occasion information object seemed like.
The transformations that have an effect on this tag are additionally listed. By clicking them open, you may see what the transformation is meant to do, and you may also see one other diff of “earlier than” and “after” states of the occasion information object after the transformation does its job.
If there are a number of transformations affecting the present tag, then the “earlier than” state is perhaps impacted by prior (increased precedence) transformations modifying it.
Within the picture above, this transformation solely reveals a couple of keys within the occasion information object, as a result of there was the next precedence Enable parameters transformation earlier than this one, stripping out all of the keys that weren’t explicitly allowlisted.
Use circumstances
Listed below are some use circumstances for transformations.
#1 Flag customized occasions as conversions for GA4
#2 Enrich ecommerce information
#3 Hash delicate URLs
#4 Populate identifiers from Firestore storage
#5 Clear undesirable parameters from GA4’s occasion information object
#6 Pressure GA4 hits to indicate up in DebugView
#7 Increase occasion with first-party person information
Naturally, all of those use circumstances have been doable earlier than with server-side Google Tag Supervisor in a technique or one other. Nevertheless, not all tags let you modify the knowledge consumed from the occasion information object.
Moreover, the issue with modifying particular person tags is that you simply would possibly slip and miss a tag, which then turns into a legal responsibility in your monitoring schema. By nipping the issue within the bud utilizing a change, the occasion information object itself is modified making it inconceivable for a tag to entry one thing that doesn’t exist anymore.
Use case #1: Flag customized occasions as conversions for GA4
One of many “quirks” of Google Analytics 4 is that it determines conversions in two locations: within the Google Analytics 4 Admin interface and within the client-side implementation, the place conversion occasions are flagged with a selected URL parameter (_c=1
) that tells GA4 the incoming occasion is, certainly, a conversion.
This second context may end up in a little bit of a headache if you happen to’re utilizing a server-side container to duplicate occasions throughout totally different Measurement IDs.
For instance, let’s say you’ve gotten a Google Analytics 4 occasion stream amassing to Measurement ID G-1234567
. On this stream, the occasion click_to_call
has not been flagged as a conversion, so the occasion requests do not need the _c=1
parameter.
Nevertheless, in server-side GTM you ahead this occasion to G-2345678
the place click_to_call
has been flagged as a conversion. However as a result of the unique request didn’t have the _c=1
parameter, this conversion just isn’t registered appropriately.
Increase occasion transformation to the rescue!
Above, I’m setting the parameter x-ga-system_properties.c
to the worth 1
. By evaluating the Occasion Knowledge object with the incoming request parameters, I do know that this corresponds with the URL parameter _c=1
.
Moreover, I exploit a Lookup Desk that returns true
for all of the occasions that ought to have this parameter added to them:
Lastly, I’ve outlined the transformation to solely apply to the G-2345678
GA4 tag within the Server container.
Now the outgoing request to G-2345678
for any occasion flagged as a conversion with the Lookup Desk will all the time embody the _c=1
parameter.
Use case #2: Enrich ecommerce information
One in all my favourite information enrichment use circumstances is for ecommerce information.
Simply think about a state of affairs the place all you have to do client-side is acquire a buy
occasion with a transaction_id
. Then, in server-side GTM, you should use the transaction_id
to drag in the remainder of the ecommerce information out of your gross sales engine (utilizing HTTP API calls) or from Firestore, if it’s one thing you’ve already arrange.
Now you can transfer this logic to an Increase occasion transformation so that every one your conversion tags could make use of this enriched information routinely.
You might even change the
worth
collected from the client-side hit with the precise revenue, and ship that to your distributors. You’d by no means wish to expose your revenue margins within the consumer, however in a server-side atmosphere it’s very doable certainly.
The good thing about utilizing this Increase occasion transformation is that the augmentation applies to the occasion information object, which signifies that tags that make use of it (for instance the GA4 tag) gained’t require any modifications within the tags themselves. They’ll simply see the reworked occasion information object and work with the augmented values out of the field.
Use case #3: Hash delicate URLs
Typically the URL itself can include info that you simply don’t wish to ahead to a third-party vendor. Nevertheless, the seller would possibly nonetheless want URL information for cohort constructing or one thing related.
With a correctly setup Increase occasion transformation, now you can hash the page_location
worth every time the URL has the potential of containing delicate info.
For instance, on this case we wish to use the sha256 Hasher variable template to hash the page_location
worth, however solely when the page_category
occasion information key has the worth logged-in
and solely for Fb tags.
By doing this in a change, we are able to be certain that Fb by no means will get the precise web page URL for delicate pages.
Use case #4: Populate identifiers from Firestore storage
You probably have the authorized foundation to take action, one factor you may need been utilizing server-side tagging for is to gather and collate a person’s identification graph.
This may be so simple as a desk saved in Firestore, the place all of the identifiers related to a person are saved in a neat doc entry.
For instance, you could possibly retailer the person’s login ID as the first key, after which underneath that you could possibly add all their recognized consumer/system identifiers, session IDs, and no matter different identifiers the totally different advertising and marketing platforms like to gather.
With an Increase occasion transformation, you may see what parameters are included within the occasion information object after which populate the remainder after performing the lookup in Firestore. You’ll be capable to “fill within the gaps” of your monitoring schema by overwriting new or ephemeral identifiers with one thing extra sticky.
However – please. Be sure to have a authorized foundation for processing all that private information first!
Use case #5: Clear undesirable parameters from GA4’s occasion information object
The GA4 request appears to gather a lot of data that the GA4 consumer transpiles into the occasion information object. Not all of this info is documented!
It is perhaps helpful to take a look at a handful of GA4 occasions in server-side tagging Preview Mode to see simply what occasion information is generated. You may then create an Exclude parameters transformation to clear all of the parameters that you simply’re not comfy with from the occasion information object.
Equally, you would possibly wish to take away Fb-specific parameters from GA4 tags and vice versa, if you happen to’re utilizing a GA4 consumer to supply an occasion information object for each GA4 and Fb. And this is applicable to different advertising and marketing distributors to whom you might be amassing information by piggybacking on the GA4 stream.
Use the “Some tags” setting right here, as you should use it to specify the subset of tags that ought to eat any given transformation.
Use case #6: Pressure GA4 hits to indicate up in DebugView
Augmenting occasion information may help you debug your Google Analytics 4 hits, too.
For an occasion to floor in GA4’s DebugView, it must be despatched with the particular URL parameter _dbg=1
to GA4’s assortment servers.
The GA4 Shopper parses this parameter into an occasion information key accessible by means of x-ga-system_properties.dbg
. With an Increase Occasion transformation, it’s now straightforward so as to add it to any occasions that you simply wish to discover by means of DebugView.
On this transformation, I’m setting x-ga-system_properties.dbg
to 1
however solely when the server-side tagging container is in Preview mode. I’m additionally limiting this to GA4 tags, as a result of no different tags have to make use of this GA-specific characteristic.
Use case #7: Increase occasion with first-party person information
Whereas I feel you have to be very cautious with utilizing enhanced conversions as a result of apparent privateness points with handing first-party information to Google on a silver platter, it doesn’t cease me from exploring the technical fundamentals of the way it works in server-side tagging.
As a substitute of sourcing the first-party information client-side, you may increase it into your server-side hits by utilizing a change that fetches it from an acceptable information supply.
To populate the first-party information variables, you have to use the prefix user_data
. Below that, you may set:
user_data.e mail
: the person’s e mail handle.user_data.phone_number
: the person’s cellphone quantity.user_data.handle.0.first_name
: the person’s first title.
And you’ll hold including to the handle
object along with the primary title with stuff like metropolis
, nation
, last_name
, area
, and postal_code
.
You don’t should hash them your self, as they are going to be hashed by the Google tags earlier than the outgoing request is compiled.
With a change like this, it’s completely very important you solely allow it for distributors that you simply belief utilizing the Affected tags setting. In any other case you is perhaps taking a look at a extreme information breach chance.
Abstract
I’m very proud of this characteristic launch. I feel server-side Google Tag Supervisor is near having a really passable characteristic set to cater to an unbelievable variety of advertising and marketing use circumstances.
The good thing about transformations for information governance needs to be apparent:
- Google strongly recommends and incentivizes distributors to make the most of the occasion information object when sourcing values for his or her tag templates.
- With transformations, you’ve gotten full management over what the occasion information object finally ends up trying like, no matter what the consumer initially produces.
- This management can be utilized for including, eradicating, and updating values within the occasion information object.
Naturally, tags don’t have to make use of the occasion information object. As transformations clearly pose a threat to malicious tags that wish to acquire as a lot as they’ll with out customers having a correct say, these tags might now proceed to scrape the knowledge from the request URL itself or from cookies or different HTTP headers.
Hopefully there might be further UI indicators in server-side Google Tag Supervisor that assist us clearly see what information every tag template is utilizing.
One of many issues with transformations is that you have to know each what the occasion information object can seem like at totally different instances and which parameters every tag makes use of.
A strong method of determining what a tag template is definitely attempting to do is to watch its permissions. Good template design includes including as few permissions as doable, so if a template clearly lists which occasion information keys it needs to entry, you may construct your transformations extra effectively.
Clearly templates can be constructed with wildcard permissions entry, by which case this sleuth work gained’t be as efficient. I hope that Google figures out a technique to incentivize restricted permission units over broader wildcard alternatives.
A number of options that I’d nonetheless prefer to see in transformations embody:
- Means to pick out a tag sort over particular person tags when selecting Affected tags.
- Means to populate the desk of parameters with a single variable, in order that you could possibly iterate over all of the keys within the occasion information object, for instance, and return an array (for Enable / Exclude) or object (for Increase) of parameter names (and values) to which you need the transformation to use.
What do you consider transformations? Do you’ve gotten further use circumstances in thoughts for them?