If you’re running Google Ads scripts on your accounts, they might not be doing what they’re supposed to be doing. The reason is because of campaign experiments. Although they’re great for testing out changes to your campaigns in a controlled environment, they can cause unexpected and undesirable behaviour from your scripts.
Fortunately, you can use scripts with campaign experiments in your account without any issues at all, but only if you know how to select your campaigns properly.
You can get even more control by using an undocumented feature which I discuss below.
After scouring the internet for more information, the only resource I could find on this topic was this 342 word blog post, therefore I decided to write the following guide. By the end of this post, you’ll not only know why the problem is caused, but also the really simple way to fix it.
Why campaign experiments are the same as normal campaigns
Campaign experiments are pretty much the same things as campaigns. The major difference is that they’re temporary. They allow you to see results of changes before actually applying those changes to a live campaign.
Once you’ve set up a campaign experiment, as far as Google Ads is concerned, it’s a campaign.
Even in the API, your campaign experiments will be returned in reports such as CAMPAIGN_PERFORMANCE_REPORT and will even be selected by selectors such as AdWordsApp.campaigns().
It looks like a campaign, it acts like a campaign – it’s a campaign.
Except when it’s not.
Why campaign experiments are completely different to normal campaigns
Campaign experiments are always enabled. Always. They can’t die. They’re like Deadpool.
Even if you end a campaign experiment, it’s still enabled. Why? Because someone at Google thought this was a good idea.
There are a couple of caveats that come with campaign experiments:
- You can’t change the name
- There’s no way to change the status either (although you can finish them)
- Start and end dates can’t be modified
- The budget has to stay the same too
- You can’t pause them…because they’re always enabled
You also can’t use labels on campaign experiments, but that’s not that as big a deal. Most importantly, if your script looks for enabled campaigns, campaign experiments will show up too.
For example, if you create a budget script to pause all enabled campaigns once exceeding a certain amount of spend, it’ll attempt to pause your indestructible campaign experiments. Best case scenario? The script does nothing. Worst case scenario? Everything breaks.
How to use scripts with campaign experiments without breaking everything
When selecting campaigns in scripts, we usually use the .withCondition() method in order to specify which campaigns we want. What is in the script documentation is the three statuses of campaign experiments.
.withCondition(“CampaignExperimentType = EXPERIMENT”)
These are the experiment campaigns themselves. (The ones which are causing all of the trouble!)
.withCondition(“CampaignExperimentType = DRAFT”)
These are draft campaigns which aren’t eligible or running yet.
.withCondition(“CampaignExperimentType = BASE”)
These are what you and I would refer to as “normal” campaigns. These are the campaign experiments that aren’t experiments.
Below I’ll show you a simple bit of code that uses this. You can copy and paste it into your scripts to solve all of your headaches.
The really useful feature that Google never mentioned
There’s also a further way to filter campaign experiments. Unfortunately, I can’t see anything written about it in the Google API. It looks like it’s completely undocumented.
.withCondition(“ServingStatus = SERVING”)
This finds campaign experiments which are eligible.
.withCondition(“ServingStatus = ENDED”)
This finds all of your campaign experiments which have ended.
.withCondition(“ServingStatus = PENDING”)
Pending campaign experiments will be picked up by this method.
.withCondition(“ServingStatus = SUSPENDED”)
If you want to find the suspended campaign experiments, use this.
.withCondition(“ServingStatus = NONE”)
This is the catch-all for campaign experiments which don’t fit into any of the above categories.
Use the above conditions and you can get even more control over your campaign experiments.
How to solve the errors in your scripts
If you’re using scripts with campaign experiments, here’s a nice code snippet that can eliminate any potential errors occurring in your scripts.
Wherever you see this in your code:
.campaigns()
.withCondition("Status = ENABLED")
…replace it with this:
.campaigns()
.withCondition("Status = ENABLED")
.withCondition("CampaignExperimentType = BASE");
That’s it.
That one little change means that your scripts will only act on “normal” campaigns and leave campaign experiments alone.
Since campaign experiments are dependent on the underlying campaigns anyway, there’s rarely a situation when you’d need to directly affect them. If you do, you can use the undocumented feature I mentioned earlier to select exactly what you’re looking for.
Don’t be caught out
If you have campaign experiments in your account – whether they’re running or not – they may be causing your scripts to malfunction. A simple find and replace with the code above will save you a lot of hassle.
At Impression, we create bespoke scripts to run across our clients’ accounts. We have to be on top of these things. However, if you’re using any script at all, you do too! Make sure you don’t get caught out!
To find out more about how Impression uses scripts to manage accounts, click here.
