One of life’s great joys is the oh-so satisfying feeling at the end of a project that went well:

• Thorough discovery focused on aligning requirements to the organizational goals for a project
• Reviewed solution design with sponsor and stakeholder rep who were thrilled
• Trouble-free implementation
• A few minor fixes in testing; validation came back clean
• Users are trained and excited to use the new tools

A few weeks later you connect with the users for a “now that you’ve had a chance to get used to it” Q&A.

Nothing is really wrong, but there are very few questions, and none of them are about the features they or the sponsor were excited about at launch. You ask if they are using them, only to learn that the users’ stakeholders are asking for the same reports and metrics they always have.

I have been trying to crack this nut for years, with some success. Then I took a Change Management course that provided very valuable new perspectives. I’ll describe what didn’t work, and some more effective approaches I will use going forward.

Communicating with Strategic Intent: The limits of organic adoption

When users would report back that they were getting the same old questions despite having fancy new tools, I responded based on what I would do. I’d encourage users to:

• Deliver the requested data, but when a stakeholder has an ask that could be improved upon based on new functionality, also offer related information and analysis now available.
• Offer that if the first suggestion isn’t helpful, they might be able to suggest more pertinent information if the stakeholder wants to share what questions they are trying to answer.
• Over time, users should work to be seen as SME advisors.

I maintain that this is entirely valid advice to people reporting data. But it doesn’t get the organization to use the solution to its fullest as quickly as possible. It is slow and sporadic, relying on countless repetitive (at least from the analyst point of view) conversations, with the right questions and data to provide the opportunity, all against a backdrop of a reasonably open-minded culture.

Change Management is about how to make that kind of change adoption happen at scale. To get stakeholders asking questions that take advantage of new tools quickly, we need to have an intentional strategy to communicate the change with them.

Ignoring Preferred Sender of Key Messages research

A crucial part of a change communication strategy is the concept that people tend to receive information about a change more readily if it comes from the right sources.

There are two preferred types of source, each being better for a certain kind of message:

• Messages about the big picture, like why we need to change and how the change supports our organizations’ goals, are best delivered by senior management or executives.
• Messages about what will change in people’s day to day work, like what the change will actually require work-wise and what the benefits to the individual and team will be, are best delivered by their own manager.

This raises another weakness with our original approach: not only are we relying on the sporadic instead of the systemic, we are sending these messages through the wrong people.

Maybe we’ll get lucky and already have Change Management

We’ve established the need for a strategy to help move stakeholders through analytics change, and that the communication in that strategy is best delivered by people in specific roles. But do we need to take this on ourselves?

Reinventing the wheel is a waste of time, and trying to do someone else’s job can start a turf war, so step one is to take advantage of the Change Management investments you already have access to.

If you are in-house, maybe there are Change Practitioners somewhere in or around HR just wishing that the project teams in the company would integrate with them more closely, and you are off and running. Or you might be with an org that has never heard of Change Management and doesn’t like the sound of it, in which case you might need to be more hands on.

On the agency side, this can be a bit trickier since you are working through a point of contact and sponsors that may or may not have the appetite and relationships to secure the Change Management resources you want to integrate with.

I’m handling it by making it clear that I’m enthusiastic to integrate with a prospective client’s Change Practitioners, and that my Change Practitioner certification means I’m not just winging it in that regard.

If a client answers that they don’t have a Change Office or Practitioner, I’ll offer to supply some elements they would usually provide.

Up Next: Crafting an analytics stakeholder communication strategy without the benefit of experienced Change Practitioners

So what do we do if our or the client’s organisation doesn’t have Change Management professionals to allocate to us? Ok, now we have to figure out at least some minimal plan if we want to see people get the full value our solution can deliver.

The next post will look at exactly that. If you want me to hurry up and post it, or you have any thoughts or questions, please let me know in the comments below.

The post Upgraded analytics tools, trained analytics users: same old questions? Change Management explains why appeared first on Informed Iteration.

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.

One of the main ways people expend effort on analytics without having an impact, or at least, having less of an impact than they could, is failing to understand the business goals of what they are tracking and reporting on. Or, losing sight of them along the way.

And this isn’t just a personal observation of mine. I asked around among some leading voices in the analytics industry about what problems most hold back analytics teams from having an impact. Not aligning what we are doing to the underlying business goals was a recurring theme.

In this post, we’ll look at why it can happen, and what we can do to better align our analytics work to business goals.

It seems obvious that we’d need to understand exactly what someone is trying to accomplish if we are going to give that person the right data and recommendations to help them succeed. Unfortunately, with all of the moving pieces that go into everything from gathering data through to presenting it, it’s very easy to lose the forest for the trees. This can happen for several reasons, but major ones are overreliance on tools, and overreliance on processes.

Don’t Let the Tool Do the Work

One major pitfall that can cause analytics work to become misaligned from business goals is an over-reliance on the metrics and reports automatically provided by analytics tools.

Loren Hadley, who has a wonderful understanding of how to help organizations succeed with data, had the following to say about why the right metrics aren’t always included:

It’s often what does my tool give me? CRM systems and analytics tools (I’m looking at you GA) tend to provide what seems meaningful and is easy to calculate without much context. Not that they are bad metrics in any way. Just that they may over promise. I don’t fault marketers for reaching for this or what an agency did 4 years ago. I’d just like to help them make sure they are focusing on what really matters.

– Loren Hadley

It’s very easy to let automatically gathered and calculated metrics, that are presented prominently in the pre-generated reports offered by analytics tools, get the lion’s share of the attention. Most businesses don’t really live or die based on the total number of people who come to their website or how many pages they look at, but tools put a lot of emphasis on users, visits, and views, so it often gets more prominence than it needs in reporting.

Engagement rate is another metric that people like to use, even though remembering what it actually represents off the top of your head can be tricky, let alone educating stakeholders on it. Some might argue that the point is to give an idea of what portion of traffic is engaged. I’d argue back that the threshold to be considered an engaged visitor is too low for a lot of use cases, and that a more tailored approach to measuring engagement would be useful.

Tools will inherently push us towards defaults instead of the specificity that will enhance our ability to really support decision making, and we need to guard against that. Processes, on the other hand, can either hurt or help us align our work to business goals.

Process: Finding Your Groove vs Getting Stuck in a Rut

We all know that we can’t afford to reinvent the wheel for every ask that comes in. We use repeatable processes for efficiency and reliability, and rightly so. The right processes serve as crucial guidelines to keep things understandable and on track. Overly restrictive processes, or an overreliance on processes, however, can lead people to just repeat what’s worked before.

If your website/app has a lot of funnels, you may get into the swing of things and have a process you follow when setting up tracking and reporting for a new funnel. That process can help you be efficient when planning, tracking, and creating reporting for each new funnel that comes your way. You need to know where the funnel is, what the steps to track are, and establish technical elements like is the funnel a single page app. And you’d certainly be wasting a lot of time to start the reports or dashboards from scratch every time.

The danger is deciding that the system will work as is for every funnel we are asked to track. If we assume that completion rate is the primary KPI for anything we do involving a funnel, our reporting for some funnels won’t be telling a very useful story. Maybe one project is to modify a funnel to introduce a “You may also want to consider” element to the checkout.

Completion rate is still very important, but trying to figure out if this change is working or not means considering at least average order value. And you’ll want information on interactions with the new element, and changes to items in the cart, so that you can segment metrics based on different behaviors.

Another funnel is to open a support ticket, and success for the business looks very different here. Ideally, a content recommender will show the user some help content that resolves their problem without having to open a ticket.

Analysis, reporting, and by extension, tracking, on this funnel are going to be different than how we handle purchase checkouts. Or at least they should be. Treating a funnel drop out as success doesn’t account for people who just get fed up and leave.

We can ask that the funnel be set up with distinct steps so we can clearly track people who drop out while being shown help content, as opposed to those who drop out after indicating that they still have an issue and want to contact support. Now we can start to tell the difference between someone dropping out because they solved their problem, and someone dropping out because our contact form has issues.

Without going further into the example rabbit hole, we see how getting too comfortable with treating similar asks as identical can lead to reporting and analysis that isn’t aligned to business goals.

Making Analytics Discovery Processes That Align to Business Goals

An overreliance on an inflexible process can lead us right past crucial information we need to make sure that the analysis we eventually provide will be valuable. But, we can also adapt our processes to make sure that we gather that information before we make any other decisions.

I’ve written about this a bit before, when discussing requirement gathering for analytics projects using the 5 Ws. The difference is that in that post I tried to look at all the information you’d want to bring together when figuring out what will go into fulfilling a request. And yes, “Why” was presented first. But with five more years of experience under my belt, I feel like the Why questions deserve a deep dive.

You Need to Know Why They Are Doing It If You Want to Help

If you’ll allow an anecdote, I lived in a bit of a rough neighborhood while in university. One day I was out jogging, and a very large friend of mine happened to spot me from a nearby balcony.

He looked concerned, and shouted “Are you running on purpose?”

It took me a second to grasp his meaning, and I answered “Yup – I’m just working out. No one is chasing me!”

My friend, understanding that I was running to improve my health, and not fleeing danger, encouraged me to keep it up. Had someone been chasing me, this friend was the type who would have raced downstairs to help.

Point being, knowing what someone is doing isn’t good enough to render the right assistance. You have to know why they are doing it.

Make “Why” Questions a Discovery Conversation Priority

To fully understand the goals of a project, especially a larger one, you can’t just ask people what they are and write down the answers. You need to ask the right questions to get people talking about their goals, and have a conversation. A conversation both about their project, and about how analytics can support it in succeeding. And conversations are arguably the most important part of your job.

An analytics leader whose LinkedIn posts are laden with insight, Tris J Burns, recently shared the following:

The most powerful analysis tool we can ever hope to master and possess is:

→ CONVERSATION (use your words)

Every analysis must begin and end with conversation.

We use conversation to understand the problem we are hoping to solve.

We use conversation to gather the initial data points, whether it be to gather context on the problem at hand, or to gather highly valuable qualitative data

And finally, we use conversation to deliver the insight, recommended action and estimated business impact of the analysis we’ve performed.

– Tris J Burns

If you don’t like having conversations about analytics with people that don’t know as much about analytics as you, you are going to have a hard time figuring out how to best help them with data.

We’ll tackle the first two use cases of conversation here, and talk more about recommendations towards the end.

Why Are You Doing It?

I start every discovery with “Why are you doing it?”

If I already have a pretty good idea of why based on what I know going in, I’ll confirm that understanding and ask stakeholders to expand if I missed any points or nuances. Note that we are talking about why they are doing the underlying work, not why they want analytics for it. If someone asks for analytics help with a funnel, for now, we ask why the funnel exists, not why they want help analyzing it.

With that broad understanding in place, I move on to defining what the desired outcomes are, in two contexts.

What does success with this feature/asset look like for the end user?

What did the user come here to do? Get information? Buy something? Return something? Apply for a job? Post an ad or message? What does a successful outcome for the individual end-user involve?

What does success with this project look like for you?

This is where we get more specific about why we are doing this project. If the point of updating the checkout funnel is to reduce the exit rate on the shipping step, this is where we get into “what is the rate currently?” and “is there a target improvement we are trying to achieve or threshold we want to reach?”

Analytics Discovery Continued: Questions About Questions

By now, we have a good high level understanding of what people are trying to achieve, and depending on our knowledge of the business and stakeholders, we could start planning a solution. But we’d not have as much detail as we could benefit from. And, we’d be missing a chance to understand and manage expectations.

Liz Oke, a stellar marketing strategist, wisely suggests the question:

“What do you want your analytics to answer?”

– Liz Oke

In some cases, particularly with stakeholders that are reasonably data-savvy, this will yield some great ideas you can include in your solution with little modification. In other situations, you’ll be able to have important conversations about what questions will be possible and useful to answer.

What Inexperienced Stakeholders Want Answered

People who don’t really know what’s possible with analytics will generally give one of two types of answer:

“I don’t know, I was hoping you could tell us what would be most helpful.”

This can be a very good situation to be in, in that you are being trusted to recommend what analytics can do for the stakeholders. As long as you have the right domain expertise around what the business does, you can lead them in the right direction. If you aren’t sure if your domain knowledge is sufficient, ask the stakeholders questions until it is.

“I have no idea, but it would be cool if we could know this thing YOU’VE NEVER DREAMED OF INCLUDING BEFORE.”

These can be frustrating, but they can also be incredibly fun. A lot of the time, it’s just a matter of interpreting the desires of someone who isn’t used to analytics jargon and doing a bit of translation. Sometimes, though, the ask will be for something you’ve never considered reporting on before.

The temptation here is to dismiss it as an impossible ask from someone that doesn’t understand the limitations of the technology. And that might be the right response, in the end. But before we throw out every crazy-sounding   idea a stakeholder has, we do them, and ourselves, a disservice, by not at least giving the idea some thought.

People who don’t know what to expect from analytics, but know the business well, don’t have the same habits and biases baked into their ideas that we do. And that can be a fantastic source of outside the box thinking on what analytics can do for the organization.

Is the idea actually impossible because it’s asking for something that is more magic than technology?  Or, does it seem impossible because it’s asking for something our tools don’t already do, or maybe more personally, something that you’ve never done before?

Depending on how valuable the information would be, and the resources available, maybe you need to think about extending the abilities of yourself or your tools, or adding a new tool to your stack.

What Semi-Experienced Stakeholders Want Answered

This is the stakeholder that has been exposed to analytics enough to understand what is possible in a technical sense, and get comfortable with some common measurements. But, they have trouble focussing on what they actually need in a business sense. Instead of focusing on their own business priorities, they put on their analytics hat and try to think of everything that might be useful.

If they are used to seeing it in the tools, they’ll ask for it. If they are used to seeing it in dashboards and reports, they’ll ask for it. If it was useful to them in a completely different context, they may very well, still, ask for it.

This is, in many ways, the “overreliance on tools and what we did in the past” problem, but this time it is coming from the stakeholders instead of our team. Which is entirely forgivable, as it’s not their job to avoid these issues, it’s ours.

Let’s look at some techniques to help us eliminate, or at least deprioritize, the questions that are less relevant.

Prioritizing Requirements In Analytics Discovery

Veteran voice of the analytics community, Jim Sterne, has a great method to help discern idle curiosity and old habits from the burning questions that will have an impact:

Dive into their goals and find out what they will change based on the results being above or below expectations.

– Jim Sterne

If someone has a laundry list of things they want to know, you can get a feel for how important each item is by asking stakeholders what they will do with that information. If someone insists that engagement rate (or anything else) be reported prominently, ask them what they will do if that metric were to increase or decrease by 10% – Nothing?

Ok, what about 20% – Still nothing? What about 30%, 40%, 50%?

If something can change drastically and it wouldn’t elicit a response from the stakeholders, it stands to reason that reporting on it won’t have an impact on the business. No action is being taken based on the information.

You can use this to help the stakeholders prioritize their questions in terms of value to them. Maybe you’ve only got enough resources to get to the most important ones. Or maybe you have plenty of resources, and they’ve asked for really basic stuff that’s built into the tools and won’t even use that many resources.

Either way, you need to help them focus on what’s important, both right now through prioritization, and down the road by making them analysis and dashboards that focus on those priorities.

Moving Forward

It may seem like we are skipping a lot in the middle, but solution design and implementation depend too much on the specifics of the project to get into here. And, to be fair, we have laid the foundation we need to be successful in doing those things in a way that will lead to having an impact on business decisions.

As long as you design a solution that delivers on what stakeholders want to know, as we established in the questions above, you can follow that map. Especially with a larger project, though, you can get lost in technical, documentation, or taxonomy details along the way, so it’s good to revisit the summaries you made of your discovery notes periodically.

I make it a point to do this when I move to the visualization, and again when I move to the analysis, phases of a project. Especially if it was a longer timeline, I want to make sure I remember what the point of all the work to get here was. It would certainly be unfortunate to have done everything right up until that point, then drop the ball when actually sharing the output.

Wrapping It Up

Before we can call it a day, we need to finish strongly. We need to make sure that what we get back into the hands of our users is actually going to help them achieve the goals we asked about on day 1.

Jason Thompson is not just a renowned analytics leader, but someone who often reminds us that we are human beings first, and analytics professionals second. He also had a fantastic response to my LinkedIn post asking about what prevents analytics teams from making an impact:

The biggest issue I observe in analytics teams that are struggling to make an impact comes down to struggling to move beyond data collection and reporting.

To make a true impact, analytics teams must be about more than capturing data, sharing numbers, and observing trends. To make a true impact, analytics teams must not only do meaningful analysis but must make informed business recommendations based on that analysis.

Here is some data we collected

Here is a chart attached to some data we collected

The chart line for the data we collected goes up and down

When we increase paid search budgets, the line goes up

Our analysis shows a strong correlation at a 28-day lag which highlights a monthly cycle in user buying behavior. This means for some high-value purchases, customers may take up to a month from their first visit to finalize their decision and place an order. Recognizing that customers may take several weeks to decide on a purchase we should test nurturing campaigns that present return website visitors, specifically entering into our web store, valuable information and potential incentives through a 28-day decision window…

Like most things, this is a people issue.

– Jason Thomson, 33 Sticks

The point isn’t that analysis needs to be complicated, the point is that it needs to lead to recommendations that will help the business achieve its goals. Especially in predominantly self-serve analytics environments, it’s easy to overlook that we need to make the output focused on the business questions at hand.

Go back to those discovery summaries and remember why you are collecting this data in the first place. Even in self-serve environments, we need to provide guidance and help people find the deeper insights they won’t get from looking at an automated report or dashboard.

Don’t just be a conduit for data. Where can you use what you know about the reasons for individual projects, and the business overall, to turn the data into actionable recommendations?

How do you keep your analytics work aligned to stakeholder goals and your recommendations relevant? Leave a comment and let me know!

The post Making Analytics Useful: Align to Business Goals 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.

There was a lot of info I wasn’t able to squeeze into my talk for the 2019 AB Testing Summit, including proper reference or sourcing. I’ve supplied that info here, along with a few comments I hope will be useful to those looking to do further reading about Bayesian AB Testing in Marketing.

Also, if you have a question that won’t fit in Twitter, please leave a comment and we can have a more detailed discussion that will be easier for people with similar questions in the future to find.

You can find the slides here.

Introduction to Bayesian Methods in Marketing

As a first look at Bayes Theorem, you could do a lot worse than An Intuitive (and Short) Explanation of Bayes’ Theorem

We almost immediately get into considering where Bayesian Priors come from and the validity of these processes, which is hotly debated. By extension, we need to consider several sources to get an idea an informed perspective.

If you don’t read any other source I provide, 5 Reasons to Go Bayesian in AB Testing – Debunked is probably the fastest way to get see a well argued perspective that diverges from the generally accepted hype. If you want to learn more, the author, Georgi Georgiev, is knowledgeable and prolific. There are several other great articles and whitepapers that explain how Bayesian methods may not always live up to the accompanying spin, which were immensely useful in building my understanding and preparing this talk. We’ll mention some more of his work later, but the one blog link above and two following white papers offer a good overview of the contention.

• Issues with Current Bayesian Approaches to A/B Testing in Conversion Rate Optimization
• The Google Optimize Statistical Engine and Approach

The overwhelming majority of discussion about Bayesian methods in AB testing was dismissed as coming from sources with a clear conflict of interest paired with an almost complete lack of transparency, and in some cases, presented with total incoherence. The pro-Bayesian materials we looked at that were useful were from referred journals or technical whitepapers with a high degree of transparency, for which the vendors should be commended.

• Bayesian Statistics and Marketing – Published back in 2003, this lays a lot of the groundwork about how Bayesian methods work and why they are useful to marketers, even though it predates the prevalence of AB testing that online businesses enjoy today.
• Bayesian A/B Testing at VWO
• The New Stats Engine (at Optimizely)
• If you know where I can get my hands on a Google Optimize white paper let me know.

We also looked at a non-Bayesian modern CRO tool that claims to deliver similar advantages of those claimed by Bayesian tools. We wanted to establish if the claimed advantages of Bayesian tools are only possible with Bayesian tools, or if non-Bayesian methods that are appropriately advanced and customized for CRO can deliver them as well. It may not be a huge surprise that this method was created by the aforementioned Georgi Georgiev.

• Efficient A/B Testing in Conversion Rate Optimization: The AGILE Statistical Method

Introducing Bayes Visually With Python

Introduction to Bayesian Inference is a great first look at how doing your own Bayesian analysis could work, and even if that isn’t your goal, it provides a very helpful visual interpretation to how Bayes works in marketing.

The 3d graphs were based on, like most of the code holding the internet together, a Stack Overflow answer.

Ease of Explanation

The Part to Ignore

Sorry, but I’m going to include a bit of a rant that I didn’t have time for in the talk. Skip to the TLDR if you’d like.

The whole “frequentist methods are ridiculous because [some variety of absurd claims about how frequentists aren’t allowed to discuss results or use their brains except in the strictest possible interpretation of the math they use]” such as those included by Google in their Optimize documentation are a text book example of fallacious “straw man” arguments.

Simply put, you make up a version of your enemy that doesn’t reflect reality, but completely supports your argument, then argue against that instead of what the actual enemy says.

This argument has been raised and conclusively shut down repeatedly, perhaps most devastatingly  by A “Bayesian Bear” rejoinder practically writes itself… where a mathematician gives a hilarious example of what happens if you make a Bayesian straw man to compare to the Frequentist one made by unscrupulous Bayesians.

TLDR: If you hold mathematicians to the strictest possible requirements of their assumptions and definitions, the only people who will understand are other mathematicians, and even they will think you are a jerk that is just wasting people’s time. For Bayesians to pretend Frequentist methods are the only part of statistics facing this issue reduces the credence we can give other claims made by this particular subset of Bayesian proponents.

The Part That Is Interesting, But Still Kind of Esoteric

Initially I didn’t fully absorb the importance of the debate, but the aforementioned Georgi Georgiev was kind enough to have an email chat with me and I was able to understand more of the difference in positions.

Bayesians assume that their best guess of the probability, is the probability.

Frequentists figure out how unlikely an outcome would be if the experiment were repeated a very large number of times. It’s still up to the user to decide what this result means in their real world situation.

Using a Bayesian tool doesn’t just mean trusting that the priors are chosen in a way that will work with your data, it also means trusting that the method is generating an actual probability. For people who think about these things deeply, that can be a pretty big leap of faith.

To quote Georgi: “Frequentist methods give you data and uncertainty and make it crystal clear that the decision-making part is up to you, and cannot be purely data-driven.”

Now, it’s still up to us as practitioners to decide how to explain what level of detail to stakeholders, and not everyone at a meeting about what creative to go with is going to be up for a talk about p-values. For people who are, though, it actually opens up a fascinating area of discussion and introspection.

We build human assumptions, often based on qualitative inputs, into the tools and methods we use to gather and report on data – but we often consider the results to be purely quantitative.

And we didn’t need to make a big AI project to run into that issue – even a little old t-test is an opportunity to see to what level we separate our assumption and interpretation from the data itself.

Optional Stopping and Bayesian Suitability for CRO

There’s a lot of material out there about optional stopping, but here are some excellent reads on the topic that go deeper than your average blog post without turning into heavy math and coding.

• Bayesian AB Testing is Not Immune to Optional Stopping Issues
• How Not To Run an A/B Test
• Is Bayesian A/B Testing Immune to Peeking? Not Exactly

Faster CRO Results

Information about specific products comes from either the aforementioned whitepapers or website site documentation accessed over the month of May 2019. Note that at some points while speaking (and I think even one slide), I use loss control and error control interchangeably, which is inaccurate. Loss control and error control are very different things.

Recommended Non-Bayesian Products

Optimizely, VWO, and Google Optimize, even once the hype is taken away, all make compelling cases to any org without the data science resources to do their own modelling. There are some non-Bayesian alternatives, however, that allow users to compare Bayesian tool results to traditional or more advanced frequentist menthods, for free or very little investment.

Google Analytics users can take advantage of Stéphane Hamels’ DaVinci Tools. This Chrome extension, even in its free version, makes a million and one quality of life improvements to the Analytics UI, as well as adding some useful features. One of these is the ability to take a t-test by clicking a few times on any Google Analytics report. If you also use Optimize, your experiment data is already in GA in a format that makes this very easy.

For a more sophisticated approach, have a look at the Agile A/B Testing Calculator included with Georgi Georgiev’s Analytics Toolkit. It’s very inexpensive, and Google users can connect it to Analytics/Optimize easily.

Sorry for the Google-centric view but it’s what I spend most of my time on. If there are other tools out there you feel provide a good way to double check what the Bayesian “Big Three” are recommending, I’d love to hear about it.

Please let me know in the comments or on Twitter, or reach out with any other questions or comments!

The post Bayesian AB Testing in Marketing Reading List appeared first on Informed Iteration.

Mix in a couple Radical Analytics principals from Stéphane Hamel, and you end up with a pretty good way of looking at how to best help our users with their requests.

Why – Understand It Like It Was Your Own

As the requirement recipient, you are the bridge between the person that understands the problem, and the org’s analytics resources. That means you need to understand the problem, and what your org can do with analytics. The good news is that you’ll build an ever greater understanding of your team, resources, and tools by virtue of working with them.

The even better news is that the user request side of things will be a never ending series of often totally unforeseen and fascinating topics that will keep your work interesting. It’s crucial to your performance that you understand what users are after – specifically what people want to do and why. Unforeseen questions can often be handled by someone that gets the “why” of a request without having to make that round trip to the original user.

Asking why is a very powerful  business tool, even formalized in the 5 Why method, which you might want to consider using. Getting people to talk about why they are doing something gets them away from talking about what they want you to do, and focuses the conversation on their activities and goals. That leaves room for you and your team to add value by considering solutions the user wouldn’t know about. More on this in the next section.

What – Never Ask, Alway Propose

People might try to tell you what analytics solutions they think they need, or even how to do what they think they need, instead of telling you what they are trying to accomplish. Remember that you and the analytics team can figure out how to track, report, and analyze just about anything, but you can only do a good job of that if you know what the analytics user is trying to do, and why.

Depending on the ask, goal, and need, the solution might be obvious to both of you. If it’s not, present some options you can discuss. The point is to get people talking about solutions without inviting them, let alone forcing them, to think of a solution without your help. You are the one that knows about using analytics to help people succeed at marketing – don’t rely on your users to take the lead.

This principle comes from the Never Ask, Always Propose, part of the Radical Analytics series by Stéphane Hamel. The series is a fantastic look at things that are wrong with our industry, and what we can do about it. I enjoy doing analytics more now that I’m applying it.

Note that you don’t have to come up with great options on the spot. You can let someone know you’ll get back to them and give yourself a chance to do some research or talk to your team. If you are just spitballing ideas on the spot, make sure you tell people that, and avoid promising something you aren’t sure you can deliver.

Who – The Good, The Bad, and The Ugly

We aren’t going to categorize user requests with those three terms, and certainly not the users making them! They are just to break down reasons it’s important to consider and pass along who is asking for the analytics work.

The Good

Understanding who is asking is often the first step to understanding why they want to do something, and a crucial part of scoping a question. The quality of communication you have with a person is greatly influenced by how well you know them. Sometimes, someone on your team will have a relationship with the asker, or at least experience working with them, and can leverage to find a better solution. Of course, in a larger org, you’ll need to keep track of this just so you remember who to tell when something is done.

The Bad

Who do you reach out to if there’s something to clear up, or a deadline that will be missed? Perhaps more importantly, who does whoever is working on that ticket reach out to when they get your auto-repsonder about recovering from surgery for the next couple weeks?

The Ugly

Different people in your org have different levels of ability and inclination to make you and the rest of the analytics team happy or miserable. As much as it can hurt people like us, who value transparency and accuracy, it is in your interest to take this into account when prioritizing who’s stuff gets done first, and how to frame your response. Faking report results to humour a CxO is unethical. Doing something you don’t think is the best technical solution, use of resources, methodology, etc, once your politely but clearly disclosed objections are noted, overruled, or ignored, is part of working with others.

Before you run off to get the “c-suite buy-in” often presented as a silver bullet to every analytics problem, Stéphane’s Radical Analytics lets some of the air out of that myth, and presents a great, sustainable strategy for analytics pros to grow influence in an organization.

Where – Online Is a Big Place

Make sure you clearly understand the scope and targeting that are called for. Very often, people (including me) with decades of experience working in places that have dozens of websites, a bunch of social media accounts, several agency partners, and huge numbers of campaigns, will refer to whichever piece of the puzzle they happen to be thinking of as “the site/account/agency/campaign.”

Are the new content and forms we need to track going up on all the properties? Or just on the English part of the US site for now? Or it’s actually going on a new subdomain?

It’s incredibly easy for someone working hard on something to leave out a detail that is obvious to them, but unknown outside the people really tucked in to that project. Help avoid misunderstandings by double checking on context.

A standard request form or ticket format can help make sure this is clear in every case. Don’t use it as an excuse to avoid a conversation though: it’s there to make sure all the important stuff is covered, not to allow the important stuff to be glossed over and assumed.

When – Preferably Before the Campaign Ends

People are usually pretty good about letting you know when they need something. Unfortunately, depending on resources and culture, not every ask will get done, and it can take a lot of diplomacy to help users understand when their needs can’t be the priority. Try not to leave people empty handed: if new interactive dashboards aren’t in the cards for this quarter, can you at least get the data into a custom report to tide them over?

A lot less thought and discussion goes into how long something will be needed, which is almost as important. Tags that only needs to be around for a short campaign or promotional event don’t require the same degree of thinking about maintenance consequences. It might get added in a faster, simpler way than if the team has to worry about how the tags will have to behave as the site and analytics solution evolve.

Something needed now that doesn’t need to last a long time is usually ok, and something that needs to last a long time but isn’t needed right now is usually ok. Trying to get something that requires long term planning done in a hurry is where you run into problems.

Consider a phased approach if the priority and timelines justify it, particularly if your org or team use Agile. Get a temporary and easily reversible solution in place quickly, then make a new request out of making a long term solution.

Sometimes, it’s a lot easier to wait and do something as part of a larger update or new build. Sometimes, when you go back and ask the stakeholder how things are working out and if there’s anything they want tweaked while you set up the long term solution, you find out that the campaign was a bust and they don’t need the tracking anymore.

Either way, the user got what they needed while your analytics team judiciously conserved resources, and kept the tag container from turning into martech’s answer to the Mutter Museum of Medical Oddities.

How – That’s 6 Questions and You Don’t Start with W

You’re right, we’re done! How is a different thing entirely, in that it’s not up to business to figure out how you are going to implement their requirements for you. That doesn’t mean you should be dismissive if they mention something technical: the last thing you want is a culture where people don’t tell you stuff because they are worried you’ll be frustrated with their lack of understanding.

With less analytics knowledge, they are even less able to determine what is obvious to everyone and what has to be mentioned. And it’s not like we’re 100% accurate when we are deciding what to assume and what to ask. You’ll usually fair better in an environment where people freely mention their concerns and don’t get a bunch of eye rolling in response.

Be reassuring about stuff that is obvious, and be thankful when people give you info that turns on a light bulb. Outright tell them how that info is useful and changes things, without getting technical. Over time, you’ll build a shared concept of what is par for the course and doesn’t need discussion, vs what might be out of left field and require some extra notes.

Let me know in the comments if you have any questions about how this could work in your organization, or if you have some tips to share about how you better understand your users’ requirements.

The post The Five Ws of Analytics Business Requirements appeared first on Informed Iteration.

Why Didn’t You Check With Us First?

It’s usually obvious that your first step to analytics happiness would be talking to your analytics person, team, or agency, depending on your scale and situation. There is one exception I see a lot, though, when people are working with advertising agencies. And, it’s not an unreasonable one in the slightest. After all, if an ad agency is going to do your campaign reporting for you, why would you bug the analytics team to look at this first? We just need to add the tags the agency sends over, it will take us a few minutes.

Right?

Not quite. A lot can go wrong with this kind of ask.

What Goes Wrong

Less Functionality

The agency running the campaign generally has no idea how your analytics are set up, and it’s almost never a matter of just sticking the tags in. It’s like telling a mechanic who hasn’t seen your car about the weird noise it makes and buying the part they recommend, then asking your regular mechanic to install it without telling them what is wrong with the car. Depending on the complexity of the part, the complexity of the situation, and blind luck, your car could be in the shop for a while, and you might end up with a surprising bill.

Similarly, your tracking might not be in place by the time you need it, or even be feasible from a technical standpoint.

Less Priority

There’s a whole team, if not a whole organization, of people asking for analytics help and functionality improvement. Anything you need just for your channel/campaign is hard to make time for against asks that improve capabilities across channels/campaigns. Giving the analytics team a chance to understand your goals and challenges with you means they can fit that into the rest of the organization’s needs and strategy, then build a solution in that framework. If the first time I hear about something is tagging instructions from an agency, it’s an abstract mystery competing for attention with more clearly motivated requests.

Less, or No, Consistency

Different agencies, different channels with the same agency, even different channels in your own organization, each supplying their own highly specific tagging requirements without asking analytics for guidance, makes a big mess. You end up with lots of duplication of effort and ongoing data inconsistency that makes comparison very difficult and report automation largely impossible.

But You Just Tell Us To Get the Tags From the Agency Anyway

I know, a lot of the time, when you ask us about this stuff, we ask you to have the agency send over tags. Sometimes, the chat we have with you gives us all we need to know: This is something simple, and we really can just drop in the tags. A lot of the time, based on what we learned from you about what you need to do, and what we know about tags for that channel, we know that we’ll be able to figure it out in a reasonable time frame. In some cases, literally the only part of the tags that we use as is are account or event ids, and we push the information in a totally different way.

The tag examples have value, but it’s the context you provide that makes this work.

If the analytics team knows what you want to achieve and how the agency wants to do it, we can usually figure out something that works. If we just have tagging instructions with nothing but “can you add this for the new campaign” as context, we’re going to ask why. It’s one of our more annoying habits, but we need to figure out if what we are being asked to do is going to do what you think it will, without doing anything you haven’t predicted.

Good Analytics Pros Ask Why a Lot

I’m not the originator of that idea, but I can’t for the life of me remember where I heard it. I’ll gladly update with a source if someone can help me remember in the comments.

It’s very true: we might ask you why several times, and again, we aren’t just being difficult. We need to see how this fits into the bigger organizational and analytics picture so that we can line it up with other priorities, or why it deserves special attention as its own priority.

Remember that it’s like talking to developers in IT, or any other skilled professional: they should not need to be told how to do things. You might tell a surgeon about allergies, your medical history, current condition: what and why type information that you know best. If you tell a surgeon how to do your appendectomy, you are being ridiculous. If you don’t trust the surgeon to know how to do it, you need to find a different surgeon, not hope you can walk them through it.

The same goes for your analytics team and tagging. We figure out how to tag all kinds of stuff, all day long, for our entire careers. The part we need help with is understanding what you are doing and why.

That understanding is a key requirement of helping you with reports and analyses that really unlock insight.

The post Can You Just Slap These Tags on the Site? appeared first on Informed Iteration.

There are ways to have meetings be more productive, or even avoid them entirely, even if you aren’t the one calling them. We can still use the chart (and the HBR.org source article)  as we’ll be applying similar methods. More accurately, we’ll try to get the meeting caller to apply them, or allow you to use them.

Depending on your relationship with the meeting caller, sending them the flowchart in a Reply All captioned “do this first and get back to me” is probably not a good strategy. Let’s look for ways to present the flowchart questions differently.

Have You Thought Through This Situation?

Again, I wouldn’t recommend sending that to your client or boss when they ask for a meeting. You’ll have to do some detective work. If the meeting has a solid agenda, you can see what’s up for discussion. You can take each point and run it through the flowchart questions.

If there’s no agenda and no clear purpose for the meeting, then ask for an agenda or clarification about what they want to cover at the meeting. Remind people that you are asking so that you can be prepared for the meeting – don’t make it look like a challenge to their decision to have a meeting.

By asking questions so that you can prepare, yes, you’ll be able to prepare, but you will also force the meeting caller to think about the situation, which may make for a more efficient meeting.

Do You Need Outside Input to Make Progress?

Looking at the agenda, is there anything you can more or less solve and explain without having to discuss it in real time with everyone at the meeting? Note it for the next step.

Does Moving Forward Require a Real-Time Conversation?

So there are some points on the agenda you think can be handled outside the meeting. Is it best explained by email, or do you need to do a phone call, video conference, or screenshare?

If people call a meeting, they’ll usually be more satisfied by a call or one on one meeting than an email.

Does this Require a Meeting?

Anything left that people couldn’t cover on a call? So you might need a meeting… but there might still be ways to make it shorter, or at least have fewer people there for the whole thing.

Does anything on the agenda look like it really only requires a subset of the whole invite list? Consider suggesting to move it to the beginning or end of the meeting, or even breaking it off into a separate meeting. That way, the other people who don’t need to be at that part of the meeting can be productively working on something else. And present it that way: “Can we talk about Jane and Anurag’s project first so that they can leave and have more time to work on it before the weekend,” will make fewer waves than “Can we talk about Jane and Anurag’s project first so that they can leave and we don’t waste their time?”

We might still have a meeting to go to, but at least it will be a shorter meeting, and we have already begun to prepare for it. Over time, we might even get meeting callers to start using these methods without coaxing.

What tricks do you use to get out of meetings? Share them in the comments! I’d prefer if you shared productivity enhancing methods like the ones above, but if you have a hilarious anecdote about going to absurd lengths to shirk responsibility, I won’t stop you.

Finally, the flow chart got into my Twitter feed via Christopher Berry, who is a fountain of brilliant tweets on data, organizational behavior, election behavior, etc., so go follow him.

Summary: How to Get People to Call Fewer Meetings

1. If the meeting has a solid agenda, you can see what’s up for discussion.
2. If there’s no agenda and no clear purpose for the meeting, ask for an agenda or clarification about what they want to cover. Remind people that you are asking so that you can be prepared – don’t make it look like a challenge to their decision to have a meeting.
3. Looking at the agenda or topic, is there anything you can solve and explain without having to discuss it in real time with everyone at the meeting? Note it for the next step.
4. Is it best explained by email, or do you need to do a phone call, video conference, or screenshare? If people call a meeting, they’ll usually be more satisfied by a call or one on one meeting than an email..
5. Does anything on the agenda look like it really only requires a subset of the whole invite list? Consider suggesting to move it to the beginning or end of the meeting, or even breaking it off into a separate meeting. That way, the people who don’t need to be at that part of the meeting can be productively working on something else.

The post Get Other People to Call Fewer Meetings appeared first on Informed Iteration.

Perhaps you’ve done this many times before, in all kinds of formats, and have learned a little bit here and there over a long time, but are still far from calling yourself a coder. Maybe you’ve been running into a similar obstacle to the one I’ve hit, so I’ll share what is working for me:

I’ve learned to love Yak Shaving.

There’s the Easy Way

How to Code courses can be broadly divided into two camps. In the first, you go to a cozy environment the course creators have made, and it makes it easy for you to focus on the concepts in the course. Great! This kind of course gives us an understanding of what a developer does to make things work. It helps us understand things better and communicate better when we are working with developers.

But we aren’t learning to be developers. Our code is stuck in this little bubble that made it easy for us to learn. If we are going to reap all the benefits of learning to code, we need to be able to get our code to where it can do more than go through an automatic marker. This leaves the second type of course, where you have to install all of the stuff a developer uses to work in that language. Instead of a cozy, ready to go environment, you have to make your own.

And the Better Way

Making things in an environment we make ourselves is great, because we are learning to do things with similar or identical tools to what professional developers use. We can study and test all kinds of things, and can get as good as we want, or as good as we need for the job we want, in countless areas of programming.

But it’s also like starting a vacation in the woods with cottage blueprints and a heap of lumber.

And the blueprints are for Mac, but your clearing in the woods is Windows. Then you get bit by a weird bug. You Google up something about a patch that requires more knowledge of your OS and of the language you are trying to learn than you’ll know at the end of the course, let alone the beginning.

Whatever help system is setup, from TA to volunteer forum respondent to the 1-800 number on the metaphorical blueprints, will probably say “Yeah we can’t do support on local environments, but if you run thingYouWantToLearn in Linux on a VM it will work just fine,” which is great if you already know how to set up an environment on a Virtual Machine.

Note that there is a third way, that’s comparatively new, that changes this paradigm. I’ll do a future blog post on it. For now, we’re going to do things the tried and true way.

Sometimes, Usually the 20th Time or So, You Catch A Break

At this point, you already put a lot of time into learning about running an environment on your main operating system, and you’re being asked to learn a new, different, and complicated sounding process. This will involve putting a second ton of time into learning something that is completely unrelated to your goal. And the first assignment is due, so you drop out before the impact on your marks/schedule/work/sanity gets any more significant.

I’d love to say I broke this pattern out of my increasing wisdom, maturity, or dedication, but it might be a lot simpler than that. The last time I was learning to program, I was enjoying the course a lot, and got pretty far in, before I found the crazy bug that stopped me in my tracks, I didn’t want to drop out, and was far enough ahead to look into this VM solution.

It also helped that, this time around, a friend and brilliant coder, Nick Kenyeres, https://www.knicklabs.com/ was the one that told me to go this route. Below, I share the resources he shared and some others I found helpful, in the order you’ll need them to make your own development environment on a Virtual Machine.

For now though, there is a much bigger step you can take, that will shift your whole mindset on learning to code.

Doing Stuff Unrelated To Coding So That You Can Code Is a Core Part of Coding

Instead of feeling like the time I put into the peripheral setup of taking coding courses is a waste, I now accept that this is in itself part of process, not just of learning to code, but being a developer. When we do this, we are joining real programmers in something so common that they have a name for it.

We are Yak Shaving.

I’d heard this thrown around and thought it meant doing any series of menial tasks, but I came across some similar meanings with important nuances.

In one meaning of the term, if you can’t code something until you do seemingly unrelated task A, and can’t do A (install the software you are trying to learn) until you are done seemingly unrelated task B (make the right development environment), until you are done C (choose the best version of Linux for your environment), and so on and so forth, you are Yak Shaving.

And for now, I say we should be proud to shave the yak.

Maybe down the road we can get frustrated about having to do all this other stuff instead of actual coding, but I’ve suddenly gotten very excited about upping my Yak Shaving game. For the time being, getting better at making an environment where I can create and test code, and managing, sharing, and implementing that code, are as important to me as getting better at any given language.

Tips & Resources for Introductory Yak Shaving

Here are some resources and tips that helped me overcome some of the first Yak Shaving humps.

Until you are reasonably confident in your VM creation and management skills, stick to self-paced courses. If you need to stop and redo something, or do something new, you can take all the time you need to get back on track.

Avoid analysis paralysis. A lot of course providers rightly want to be platform agnostic, so they’ll tell you to set up “a Virtual Machine” running “Linux” or, even more confusing, “any Unix-like operating system.” Deciding which Virtual Machine to use, and even worse, which Linux, are complicated questions that involve a lot of personal preference. If you have no idea where to start, try the latest Long Term Support (LTS) version of Ubuntu running in the latest version of VirtualBox.

You’ll also want to set up a Shared Folder if you want to move files between the VM and your physical computer. Newer versions of VirtualBox make this a point and click affair.

We can’t point and click forever though. You can’t make very much of your virtual Linux environment unless you are using the BASH prompt in the terminal. There are some solid tutorials about this on Youtube, but I found a course that covers it inadvertently.

Yak Shaving Your Github

Another practice peripheral to coding is using a version control system, so that you can work with other coders, without breaking each other’s work. Git is a popular one, and by using the online GitHub service, you can learn how to use it while backing up what you make on your virtual machine. As you have more impressive pieces of code to put on there, you can use it as a portfolio of what you’ve learned, and eventually, what you’ve worked on.

I grabbed a Stack Skills Learn to Code bundle through the Boing Boing Store for $20, which includes “Git Complete Mastery with GitHub.” While I don’t feel that I’m a complete master by any means, I can do the basics, and I couldn’t before. Also, while learning Git(hub) stuff in this course, you learn a lot of basics about moving and copying files and directories in the terminal.

Looking for that course on it’s own, it’s on a variety of sites, at prices between $15 and $210, so grab the bundle, or shop around.

I hope that helps you get into, and take pride in, your Yak Shaving. Let me know in the comments if you run into any hurdles or have some advice to share about overcoming your learning to code challenges.

The post Learning to Code 1: Introductory Yak Shaving appeared first on Informed Iteration.