What Is Strict Act-As Enforcement in Dataform GCP, and What Is the Impact

Strict Act-As is an extra security check that used to be optional. It prevents Workflows from running with the default Dataform Service Agent, which forces GCP users to be more deliberate with how they set up who gets to create or make changes to which Dataform Workflows.

Instead, you need to create a Custom Service Account and configure it to run your Workflows. We’ll go through that step by step below.

Default Dataform Service Agent VS Dataform Custom Service Account

Note that we will use the terms Default Dataform Service Agent and Custom Service Account a lot. The Agent is the principal Dataform creates to run its jobs. The Custom Account is the principal we create to make sure that the Agent is authorized to run the workflow.

As a very loose analogy, think of:

• the Workflow as a building project
• the Default Agent as a tradesperson
• the Custom Account as the project manager
• Google as the construction company

Traditionally, Google would let tradespeople (Agents) just walk onto the building site (Workflow) and get to work, but they want to tighten security. As a result, they are introducing a policy that only project managers (Service Accounts) on that building (Workflow) have keys to the site and the authority to request that the tradespeople (Agents) do work.

For all our building projects (Workflows) where the tradespeople (Default Dataform Agent) are still doing stuff directly, we need to hire a project manager (Custom Service Account), and tell the tradespeople to report to them.

Key Dates

2026-01-19

New repositories created on or after this date will no longer have the option of not using Strict Act-As enforcement, which means you won’t be able to make Workflows run by the Dataform Service Agent.

2026-04-29 – 2026-07-31

Existing repositories will gradually have Strict Act-As enforcement turned on. If you haven’t set things up correctly by then, your scheduled Workflow runs will stop.

Create or Modify a Dataform Workflow to Work with Strict Act-As Enforcement

Whether you are making a new Workflow or changing an existing one, the Act-As part of things is pretty much identical. We’ll

1. Make the Custom Service Account
2. Give it required permissions
3. Give the Dataform Service Agent and appropriate users access to the Custom Service Account
4. Create or configure a Workflow to be run by the Custom Service Account
5. Turn on Act-As enforcement and test

Even nicer is that the UI design anticipates that people would want to do steps 1-2-3 above together, so we don’t have to wander from page to page to do them. That assumes you are fine with doing things at the project level – you can get more or less granular, but we are keeping things simple for today.

The Default Dataform Service Agent

The instructions assume that you have already created a Dataform repo, and by extension, a Dataform Service Agent. The latter has the default format:

service-(aBunchOfNumbers)@gcp-dataform.iam.gserviceaccount.com

If you changed the default, make a note of what you used instead, as we’ll need it in a bit.

1. Create a Custom Service Account to Run Dataform Workflows

1. Search for “service”
2. Click on Service Accounts
3. On the Service Accounts screen, click on Create service account

Choose a name, provide a description, and change the autofilled ID if you want. Hit Create and Continue.

2. Set Custom Service Account Permissions

Always defer to your org’s security experts when it comes to setting cloud platform permissions. Some commonly provided permissions in this context are shown.

1. BigQuery Job User – Dataform can’t run BQ queries without this one.
2. BigQuery Data Editor – Allows Dataform to read, modify, and create BQ tables and datasets, and delete tables.
3. BigQuery Data Viewer – Allows Dataform read-only access to tables (if granting permissions at the table or dataset level, it can be a good idea to limit permissions to Data Viewer on source tables you wouldn’t want to accidentally modify).
4. BigQuery Data Owner – Use this instead of Data Editor if you need Dataform to be able to delete entire datasets.

Click Continue.

3. Give Access to the Custom Service Account

The first principal we should give access to is the Dataform Service Agent that you created when you set up the Dataform Repo. Then we’ll give access to ourselves, and anyone else that needs to configure Releases or Workflows

1. Type in part of the Agent ID email in the “Service account users role” and click on the result that pops up. The default, once again, looks like this:

service-(aBunchOfNumbers)@gcp-dataform.iam.gserviceaccount.com

2. Add other users based on their Google Accounts. In most cases they should be granted the “Service account user” role , but if you want them to be able to make changes to who has access to the Service Account, or the Service Account itself, including deleting it, you would put their Google Account email in the “Service account admin” box.
3. Click Done

That will return you to the list of Service Accounts. Click on the new Service Account and we’ll make sure everything worked as needed. Hit the Permissions tab and the Manage Access button to confirm the permissions you want are there.

Provide Dataform Service Agent with the Token Creator Role

We need to give one more permission to the default Service Agent on the Custom Service Account.

1. Go to the “Principals with access” tab
2. Check the “Include Google-provided role grants” box
3. The Service Agent has the Service Account User role, but they will also need the Service Account Token Creator role
4. Click the pencil to edit the Service Agent’s roles

On the fly out, Click  “+Add another role” and search for “Service Account Token Creator.” Click on it, then the Save button.

4. Set Your Dataform Workflow to Use the Custom Service Account

Whether you are just switching over existing workflows or creating new ones, there is only one field in the configuration flyout we need to worry about.

Now, it is probably a good idea to create a test Workspace (with some kind of compilation override), Branch, Release, and Workflow while getting the kinks out. We’re assuming you’ve already made the first three, as there is no change to those steps from Strict Act-as enforcement.

Assuming you are still in the repo you want to switch over,  head to the “Releases & scheduling” tab, and click “+ Create”  to make a new Workflow. 

1. Set it to use the test Release
2. Search for and/or choose the Custom Service Account you made earlier. 
3. You might get a warning that isn’t very useful, like the one shown here, or you might get an error message with helpful information.

When I was testing, I was blocked from using the Custom Service Account, and the error message told me it was because it needed access to a table in another project to run the workflow in question, making it easy for me to address the issue. 

This digression is just to remind you to keep an eye out for anything like that, because the instructions above give the new Service Account permissions only on the currently selected project.

Resolve any errors, assess any warnings, save, and do a manual run. Then wait for a scheduled one to go through as well.

All green? Awesome. There’s one more thing we need to test though.

5. Testing with Strict-Act As Enforcement Before the Deadlines

To make sure your Workflows will run once Google turns on Strict Act-As enforcement, you may want to turn it on manually beforehand and test. 

Note that you can only change this setting at the repository level. If you have multiple Workflows in your repo, any that you haven’t switched to the Custom Service Account will fail to run. I’d switch them all to the new Service Account before changing the repo-level setting. For now, you can switch Act-As enforcement back and forth on existing repos, but I’m not sure how Google will handle that after the 19th.

Once all your Workflows are ready, 

1. Hit the rightmost Settings tab in your repo.
2. You can update the Service Account default to the new Custom one. The Workflow level settings will override this default, but removing the old Service Agent default will reduce the chance of someone using it by accident. Click the pencil to bring up a flyout, select the new account, and save.
3. Click the pencil across from “actAs permission checks”  to change it
4. Select “Enforce actAs permission checks” and click Save.

You can now run your workflows manually or wait for the scheduled ones to run and keep an eye on the results.

Have you run into any problems with Strict actAs permission enforcement, or found any different solutions? Let me know in the comments or use the contact page to get in touch.

Before I let you go, I got guidance on dealing with this Google Cloud Platform change from Ken Williams at my usual source for GCP info, DiveTeam.

The post Complying with Strict ActAs Permission Enforcement in Dataform appeared first on Informed Iteration.

Google updates GA4 data for a few days after it is initially gathered, so a lot of the methods that we might ordinarily use to add only new data to a BigQuery table won’t work. Much of the introductory material available correctly guides us to just overwrite the entire output table when scheduling queries.

This is the easiest way to get accurate data, and back when we’d just connected GA4 to BigQuery, the costs of doing it for even pretty busy websites were negligible. But as time goes on, and more data is gathered, the inefficiency of querying old data that hasn’t changed has increasing costs. Here’s a better way that isn’t too complicated

What You’ll Need

We’re assuming that you have scheduled queries you run against the whole date range of your GA4 BigQuery export, and that these queries overwrite the results table when they run.

If you need help with getting your reporting up and running through BigQuery, consider this course on how to Prep GA4 Data in BigQuery for Reporting. Note that it doesn’t just cover the basics – later sections of the course will take you through more sophisticated stuff than we do in this post, but they build up to it.

The Plan: Delete and Insert the Last 7 Days of Data, Every Day

Note that there are lots of ways to do this, and some are more robust and sophisticated, but we are going to take the easy route wherever possible. Instead of trying to append new rows, update changed rows, and delete removed rows, we’re just going to delete the last seven days of data from our destination table, then query the last seven days from the export into our destination table.

This might seem heavy handed, but if you are coming from overwriting the entire date range, it’s a much lighter approach.

We’re also going to add a bit of a safety valve. Sometimes Google Analytics bugs out and data has to be backfilled, so we will still overwrite the whole table occasionally. It will also clear up some minor inconsistencies that might arise in your data. This clever idea came from June Li at ClickInsight. We’ve got things set up to do this quarterly in the example below, but you’ll see how you can modify that.

Copy Your Current Tables

We’re going to start by creating test versions of the tables you want to update. The easiest way I found to do this was to take the query I currently use to generate the table, wrap it in parentheses, and stick a CREATE command in front of it.

CREATE TABLE
destination_dataset.destination_table_name
PARTITION BY
Date
AS (
SELECT
cast(event_date as DATE format 'YYYYMMDD') as Date,
-- ...
FROM `your_project.analytics_XXXXXXXXX.events_*`
WHERE
_table_suffix between
-- your first day of data as a YYYYMMDD string, eg 20240101
'your_first_day_of_data_as_YYYYMMDD' and
format_date('%Y%m%d',date_sub(current_date(), interval 1 day))
)

Give your tables a clear name, but note that if you keep them in the same dataset as your production tables, you can just rename them when you are done testing and ready to switch over.

Next, instead of configuring partitioning as part of the scheduled query UI , we are going to define our partitioning in the query itself.

Then comes AS ( the original query ). Obviously, the query needs to include the partition column (which you can name however you please, but ours is just called Date).

Beyond that, you can go to town!

Wait, Should I Test This First?

I highly recommend testing the new versions of your queries against the old ones, because, well, you should always check data for accuracy when you change how it’s processed. In my testing I did detect some minor inconsistencies in one of my queries. In a query to generate a pageview table with session level attribution, I noticed a very small number of pageviews got attributed differently.

I’m guessing these were part of sessions that spanned midnight of the cutoff point seven days ago, and the original attribution data from the beginning of the session was lost. In the case of this query and the data it was running against, the difference was negligible, but that might not always be the case. And, we will run the full overwrite of the tables quarterly, which will keep these inconsistencies from accumulating.

What’s the Easiest Way to Test This?

Here’s the testing plan I used:

1. Create copies of scheduled query result tables (done above)
2. Check table row counts to make sure they are identical across test copies and production originals
3. Create scheduled queries to run on the last seven days for a day or two, do a full refresh, then run on the last seven days for another day or two (we go into this in detail later).
4. You can check your results at any point in the process, but waiting through a couple normal seven day pulls, then a full overwrite, and another couple seven day pulls, reproduces both date ranges for the query, in their natural sequence.
5. Check tables for row level discrepancies using the query shared here by Mark Scannell https://medium.com/google-cloud/bigquery-table-comparison-cea802a3c64d

You can also connect the tables to copies of reports you currently run from your full overwrite tables and compare the final output. This is particularly useful if you turned up row level discrepancies whose impact you need to investigate.

Prepare a DELETE and INSERT Query

Much like we just added some stuff to the beginning of the query we used to overwrite tables to make it create a new table with the same data, we will add commands to the beginning of our old queries in this step. Note that, unlike before, we don’t need to wrap our original query in parentheses. I start with images as they are easier to decipher, what with the colours and indents, but the code is available at the end of this section in copy and paste/screen reader friendly text.

Let’s break this into parts:

We start by declaring and setting some useful default values in variables

• dayof: this is an integer that tells us how many days into the current year we are. The testing version gives the day of the week instead.
• start_date: the date we want to start pulling data from, which defaults to seven days ago.
• start_date_string: same as start_date but in a string data type so we can easily pass it as a table suffix later.

Next, we decide if we are going to do a full overwrite or stick to a seven day overwrite

We use the MOD function with the dayof variable and the number of days we want to go between full overwrites. If the day of the year divided by 91 has no remainder (so, every quarter), we do a full overwrite. You can adjust the number you divide by to set the frequency with which you want to do the full overwrite.

The testing version of the MOD function divides by seven, and the test version of the dayof variable set in the previous step gives the day of the week, starting from Sunday. So in test mode, you’d get your full refresh every Saturday. Perfect for setting this up one week and testing the next, but again, you can adjust the numbers to your liking.

If our modulus is 0, we change the values of start_date and start_date_string to represent the first day of data we gathered. Otherwise, we leave them at at 7 day lookback window we set above.

DELETE the Old

Note that the WHERE clause is using the Date column we set as our partition. Again, you can call this column whatever you’d like, but deleting (and inserting) based on the partition column uses far less data than otherwise.

INSERT the New

Finally, we insert the data from the query we’ve always used into the destination table. The big difference is, instead of always going all the way back to our first day of data, we set the beginning _table_suffix to start_date_string. And most of the time, that start_date_string will only be going back a week – think of the query data you’ll save!

Schedule the DELETE and INSERT Query

There are a couple important differences in how we schedule this kind of query where we specify destinations directly in the query. As you might have guessed, you DO NOT tick the Set a destination table for query results box, as we’ve established the destination in the query and the overwrite vs append behavior in the query itself.

Otherwise this is no different from scheduling a normal query.

I hope you found this helpful and that you’re looking forward to saving a bunch of data. If you have any questions or other feedback, please leave a comment or contact me!

Here’s the plain text version:

DECLARE dayof INT64 DEFAULT (EXTRACT(DAYOFYEAR FROM CURRENT_DATE()));
-- for testing use: DECLARE dayof INT64 DEFAULT (EXTRACT(DAYOFWEEK FROM CURRENT_DATE()));
DECLARE start_date DATE DEFAULT DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY);
DECLARE start_date_string STRING DEFAULT FORMAT_DATE('%Y%M%D',DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY));

IF MOD(dayof, 91) = 0
-- for testing use: IF MOD(dayof, 7) = 0
THEN SET (start_date,start_date_string) = 
(CAST('your_first_day_of_data_as_YYYYMMDD' AS DATE FORMAT 'YYYYMMDD'),'your_first_day_of_data_as_YYYYMMDD');
END IF;

DELETE FROM `your_project.destination_dataset.destination_table`
WHERE Date BETWEEN start_date AND DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY);


INSERT INTO `your_project.destination_dataset.destination_table`
SELECT
CAST(event_date as DATE format 'YYYYMMDD') as Date,
-- ... rest of your query
FROM `your_project.analytics_XXXXXXXXX.events_*`
WHERE

_table_suffix between 
start_date_string and 
FORMAT_DATE('%Y%M%D',DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY))

The post Slash Your GA4 BigQuery Bills By Only Overwriting Recent Data appeared first on Informed Iteration.

Not only would it be too much to learn at once, but given how recently many people had moved to GA4, there wouldn’t be tons of data gathered yet, so putting effort into controlling the size of queries wasn’t a priority.

Returning to the present, you might have noticed your bills creeping up, or maybe you are just looking to make sure that doesn’t happen. You might just be setting something up, and aren’t sure of what it will cost once all the users hit your reports, so you figure it’s better to build things to be efficient just in case.

Wherever you are in the process, partitioning is perhaps the easiest way to avoid unnecessary BigQuery costs, especially when connecting to Looker Studio.

What You Need to Get Started

We’re going to assume that you already have source tables you make by querying the Google Analytics 4 BigQuery export data, and saving the results manually or by scheduled queries. Figuring out what tables you need is a bit of an art, and figuring out how to make the queries for them is more of something you’d learn in a course than from a blog post I’m trying to keep brief.

For now, I’ll just say you can get a lot done with a session-scoped table, a pageview table, and a leads/sales table. I might write more about how to build those in the future, but if you want something more concrete, I’d recommend this course on how to prep GA4 data in BigQuery.

Another note is that we’ll be setting up new scheduled queries in the examples, but you could just as easily add the partitions to existing scheduled queries if you preferred.

The event_date Column Is Not a Date

The good news is that the raw GA4 export is already partitioned by way of table suffixes. The bad news is that this doesn’t get inherited automatically by tables queried from that raw export. But, setting up your BQ tables with partitions, and getting Looker Studio to take advantage of that, is easy.

The first thing we need to do is establish what column we’ll be using to do the partitioning on, and event_date seems like a logical choice. There’s one small issue, which is that event_date is considered a string in the schema.

So instead of just selecting event_date, we’ll need to cast it as a date in the SELECT part of our query:

CAST(event_date AS DATE FORMAT 'YYYYMMDD') AS Event_Date

You can easily edit your queries to do this where you currently select the date. We don’t have to call the output Event_Date, but keep track of what you do call it as you’ll need it for the next step.

Tell Big Query to Partition the Resulting Table

Now that we have a suitable candidate, we need to tell BigQuery to use it as our partitioning column. There are lots of ways to do this, but I’m going to lean towards a very common and easy one: configuring it in a scheduled query.

When your query is ready, click SCHEDULE above the main editor window. In the sidebar that appears, name and schedule your query, then scroll down to the Destination for Query Results section. Then:

1. Check the box to Set a destination table for query results
2. Choose a dataset and name your new table
3. Put Event_Date (or whatever you called it) into the Destination table partitioning field

Continue through the form and complete the remaining options. Because of the way the GA4 export works, unless you know what you are doing, it is usually best to select Overwrite table (4. above). The other options can all be left as is if you don’t know what they do. Click save when you are done.

Once your scheduled query has run, you’ll have a partitioned table you can connect to Looker Studio.

One More Crucial Click

The last step is to make sure Looker Studio takes advantage of your table partitioning. Whether you are setting up a new data source or reconfiguring an existing one, the process is identical once you get to the step where you edit the connection, pictured below.

Choose the project, dataset, and table as appropriate. If everything went well in the steps above we’ll get a checkbox (1) to Use Event_Date (or whatever you called the column you are partitioning on) as date range dimension. Make sure you remember to tick this, or the queries Looker Studio runs to feed the reports won’t take advantage of the partitioning. Hit the Connect or Reconnect button at the top right when you are done (2).

Thanks for reading, and let please me know if you have any thoughts or questions!

The post Partition Tables for Lower GA4 BigQuery and Looker Studio Costs appeared first on Informed Iteration.